![頭圖.jpeg](https://ucc.alicdn.com/pic/developer-ecology/318f373ac8e744d1bd8bdc4e0329d247.jpeg)

作者 | 郭浩（項升）  阿里巴巴經濟體 RPC 框架負責人

> **導讀：**本文整理自作者於 2020 年雲原生微服務大會上的分享《Dubbo3.0 - 開啟下一代雲原生微服務》，主要介紹了關於思考 rpc 框架層面，功能演進的方向是什麼？以及怎麼更好地支援雲上的多語言開發的新思考。

**關注阿里巴巴雲原生公眾號，後臺回覆 【818】 即可獲取直播回看地址和大會 PPT 合集。**

看到這個題目，大家可能會有幾個問題，比如，什麼是雲原生微服務？Dubbo3.0 是什麼？和目前的 Dubbo2.0 有什麼區別？用了 Dubbo3.0 會帶來哪些業務視角的好處？後面的分享會對這些問題逐一解答。

這次分享分為以下幾個環節：

- Dubbo 的演進歷史
- Dubbo 的開源現狀
- 定義 Dubbo3.0 
- 分享 Dubbo 3.0 目前取得的一些成果

考慮到有些同學對 Dubbo 可能不太熟悉，在介紹背景之前，我先簡單介紹一下 Dubbo 是什麼。簡單地說，Dubbo 是基於 Java 的 RPC 框架。一個 RPC 框架至少由資料格式、傳輸協議和連線管理組成，這三點也是構成核心。Dubbo 能夠被廣泛應用主要有兩個原因：

- 一方面是較好的外掛機制支撐了多種擴充套件，這些擴充套件在不同業務場景和基礎架構中能分別發揮最大優勢；
- 另一方面不同於普通的 RPC 框架，Dubbo 的服務治理功能讓其在易用性方面脫穎而出，比如路由規則能夠支援靈活多樣的執行時動態路由，可以基於此功能實現灰度、ABTest、流量回放等功能。

# Dubbo 發展歷程

簡單介紹完 Dubbo，現在讓我們一起回顧一下 Dubbo 的歷史。

![1.PNG](https://ucc.alicdn.com/pic/developer-ecology/e7b8a0fd7c3c4b97b7d968010726271e.png)

在 2008 年，Dubbo 作為阿里巴巴內部 SOA 解決方案橫空出世。業務的急速發展帶來了強烈的服務化需求，只用了兩年的時間 dubbo 就在內部大面積落地，日均呼叫量超過了 30 億。經過落地過程中不斷的打磨，Dubbo 無論是在效能上還是在擴充套件性方面，都成為了當時遙遙領先的 RPC 框架。為了更好地回饋開發使用者和其他有服務化需求的公司，在 2011 年 Dubbo 選擇了開源，併發布了 2.0.7 版本作為開源的第一個正式版本。

開源後 Dubbo 蓬勃發展，社群活躍，獲得了開發者的一致好評。2017 年 9 月，阿里巴巴宣佈重啟 dubbo 的開源維護，重啟開源後，解決了積累很久的 pull request 和 Issue ，以及之前一些公司不得不開始自己維護 dubbo 的私有分支也逐步合入了主幹。同時，與社群進一步的互動，也會激發 dubbo 團隊對產品的靈感。

目前 Dubbo 團隊就是阿里巴巴內部負責服務框架的團隊，我們在大流量、大規模叢集、服務治理領域有著豐富的實踐，這些經驗已經在有序地回饋給社群。重啟開源後釋出的 2.7.x 版本帶了了很多新的特性，比如 JDK8 支援，完整的非同步支援，以及後設資料的精簡和抽象。在今年，我們啟動了另外一個新的歷程碑 —— Dubbo3.0，這也會帶領 Dubbo 走向下一個階段，即雲原生微服務。

# Dubbo 開源現狀

簡單介紹完 Dubbo 的歷史，下一步我們來走進 Dubbo 的開源現狀。

![2.PNG](https://ucc.alicdn.com/pic/developer-ecology/770dc34e0ed24c5fa15d9a822ef0742f.png)

Dubbo 目前有 57 位 committer 和 379 位 contributor 。根據 X-lab 開放實驗室最新發布的《2020 年微服務領域開源數字化報告》，Dubbo 的開源活躍度全球排名 693，在微服務框架中排名第五。整個社群蓬勃發展，來自外部的程式碼貢獻量已經超過來自阿里員工的貢獻量。也正是由於有這麼活躍的社群，Dubbo 目前支援 6 種語言和 30 多個生態專案。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/96e1a9e2cba341eb965fa4e40076cd03.png)
資料來源《2020 年微服務領域開源數字化報告》，阿里巴巴雲原生公眾號後臺回覆關鍵詞“微服務報告”獲取報告全文。

作為國內 RPC 框架的領跑者， Dubbo 也在被 Spring Cloud Sleuth、Zipkin、Envoy、Mosn 等標杆專案官方整合。Dubbo-go 子社群是社群演進的另一個探索和優秀實踐。Dubbo-go 子社群由官方引導，完全社群化運作和開發，前不久釋出的 Dubbo-go 1.5 版本在功能上已經完全對齊 Dubbo-java 2.7 版本，後續的 Dubbo3.0 也會包含 Dubbo-go 3.0 ，讓我們拭目以待。

![4.PNG](https://ucc.alicdn.com/pic/developer-ecology/2944949d5f824c6d81293f8ebfbe9fef.png)

**從資料上看**， Dubbo 目前有 33k stars 和 21k forks，分別位於 github java 專案前十和前三，使用者的認可帶來了社群的活躍，而活躍的社群則會以高頻率的版本更新帶來更多新的、有用的特性來彰顯其旺盛的活力。目前已經登記的 Dubbo 企業使用者超過了 200 個，其中有 30 多個企業成為了 Dubbo 的生態合作伙伴。

有了這些公司的幫助， Dubbo 在設計、開發、測試、灰度上線的整個流程都有了更強有力的保障。讓使用了 Dubbo 的應用跑的更快更穩定一直是 Dubbo 社群不變的追求。

![5.PNG](https://ucc.alicdn.com/pic/developer-ecology/6eed3eb235f44aa2be47d96dcb1d866f.png)

**從功能上看**，Dubbo 3.0 完成後的功能將涵蓋從開發人員直接接觸的 API 層到底層傳輸的完整鏈路。

API 層將包括基於 IDL 的完整資料交換格式打通，這會帶來兩方面的好處：

- 一是統一的 IDL 模型可以生成統一的 client stub 和 server stub，這些 stub 能直接進行非反射呼叫，會在效能上有很大的提升；
- 第二點是對非同步和 streaming 的原生支援能夠給使用者更多的選項，根據不同的業務場景選擇更方便的用法。

**第二層是對於註冊中心、後設資料中心和配置中心的擴充套件**。註冊中心和配置中心基本支援了所有業界主流的實現，後設資料中心是 Dubbo 2.7 新抽象出的元件，負責後設資料的存取。這裡的後設資料包括服務的呼叫配置，如超時時間，序列化方式，協議等，以及對服務方法簽名的抽象，方便 Dubbo 實現跨框架和跨語言呼叫。

**叢集層**是 Dubbo 的一個主要亮點，除了支援各種重試策略外，Dubbo 也提供了各種場景下的負載均衡器，比如隨機和權重。值得一提的是，Dubbo3.0 將帶來 pull-based 的自適應負載均衡，這將顯著提升分散式叢集的效能和效率。

再下一層是**協議層**，協議層是 RPC 框架的核心部分，一般分為應用層協議和傳輸層協議。應用層協議 Dubbo3.0 支援 GRPC / Redis / REST 等主流協議以及 Dubbo 原生的 Dubbo2.0 協議。傳輸層支援 HTTP / HTTP2 和一些自定義的協議如 RSOCKET。序列化方面，Dubbo 除了支援 hessian 、Java 外，還支援 protobuf，這對於效能和跨語言都有著巨大的意義。

![6.PNG](https://ucc.alicdn.com/pic/developer-ecology/5a86279fc30747feb6318316eb75ac12.png)

看完了 Dubbo 3.0-java 的功能圖，我們再來看一下 Dubbo-go 的功能圖。可以看到，從分層到實現， Dubbo-go 已經基本和 JAVA 對齊，後面的 3.0 版本也會和 JAVA 齊頭並進，共同邁向雲原生。

# Dubbo3.0-下一代雲原生微服務

介紹完了 Dubbo 的現狀，下面我們進入今天的主題：Dubbo3.0 -下一代雲原生微服務。

![7.PNG](https://ucc.alicdn.com/pic/developer-ecology/85b7a63d16b54d3db6ee147f35811c38.png)

**一個新架構或新技術的出現一定會伴隨特定的發展趨勢**。

目前我們可以看到的幾個趨勢是 **K8s 成為資源排程的事實標準、Mesh 化成為主流以及規模上的急速增長**。這些趨勢的存在對 Dubbo 提出了更高的要求:

- 首先，使用者如何在 K8s 上更方便的部署和呼叫 Dubbo 服務是必須要解決的問題，要解決這個問題，統一的協議和資料交換格式是必須前提；
- 其次，Mesh 化的流行帶來了多元化問題，即原生 Dubbo 和 Mesh 化 Dubbo 如何共存，多語言的場景如何支援；
- 第三點，規模的增長會給整個 Dubbo 架構帶來更大的挑戰，無論是註冊中心等元件，還是客戶端，都會有更多的資料和呼叫量。如何在保持穩定的前提下，提供更高效的服務是 Dubbo 演進的重中之重。

這些雲原生時代帶來的挑戰，促成了 Dubbo 的下一代定義。新協議、K8s 基礎架構支援、多語言支援和規模化支援四個子專案共同組成了 Dubbo3.0 。下面我們將走進 Dubbo3.0，看看具體有哪些新特性。

## 1. 下一代 RPC 協議

首先我們從協議開始。

![8.PNG](https://ucc.alicdn.com/pic/developer-ecology/534b2870375f468887f2af4a97d8516d.png)

大家可以看到，這是 Dubbo2.0 的協議。從功能上看， Dubbo2.0 提供了 RPC 的核心語義，包括協議頭、標誌位、請求 ID 以及請求/響應資料。在雲原生時代，2.0 協議主要面臨兩個挑戰：

- 一是生態不互通，使用者很難直接理解二進位制的協議；
- 第二是對 Mesh 等閘道器型元件不夠友好，需要完整的解析協議才能獲取到所需要的呼叫後設資料，如一些 RPC 上下文，從效能到易用性方面都會面臨挑戰。

那麼，在支援已有的功能和解決存在的問題的前提下，下一代的協議需要有哪些特性呢？

![9.PNG](https://ucc.alicdn.com/pic/developer-ecology/e3725680e82042248e31dbb8b9e90b24.png)

- 首先，協議需要解決跨語言互通的問題，傳統的多語言多 SDK 模式和 Mesh 化跨語言模式都需要一種更通用易擴充套件的資料傳輸格式；
- 其次，協議應該提供更完善的請求模型，除了 Request/Response 模型，還應該支援 Streaming 和 Bidirectional；
- 第三點，在效能上，新的協議應該保留 request Id 機制，以避免 HOL 帶來的效能損耗；
- 最後，新協議應該易擴充套件，包括但不限於 Tracing/ Monitoring 等支援，也應該能被各層裝置識別，降低使用者理解難度。

基於這些需求，HTTP2/protobuf 的組合是最符合的。提到這兩個，大家可能很容易想到 GRPC 協議。那新一代的協議和 GRPC 的關係是什麼呢？

- 首先，Dubbo 新協議是基於 GRPC 擴充套件的協議，這也保證了在生態系統上新協議和 GRPC 是能夠互通和共享的；
- 其次，在這個基礎上，Dubbo 新協議將更原生地支援 Dubbo 的服務治理，提供更大的靈活性；
- 在序列化方面，由於目前大多數應用方還沒有使用 Protobuf ，所以新協議會在序列化方面給予足夠的支援，平滑的適配現有序列化，方便遷移到 Protobuf；
- 在請求模型上，新協議將原生支援 Reactive，這也是 GRPC 協議所不具備的。

## 2. 應用級註冊發現

Dubbo3.0 第二個內容是應用級註冊發現。

![10.PNG](https://ucc.alicdn.com/pic/developer-ecology/abcae6f709db4d748172b71ca893a620.png)

熟悉 Dubbo 的同學都知道，Dubbo 目前的註冊發現都是介面級別的。也就是同一個應用釋出的多個服務會在註冊中心註冊多份資料，這些資料彼此獨立，方便進行服務化改造和介面遷移。為什麼要提出應用級註冊發現呢？

主要有兩個原因：

- 一是現有生態系統的互通，包括 Spring cloud 和 K8s 都是基於例項，也就是應用級別進行的註冊發現，Dubbo 要成為連線異構系統最好用的 RPC 框架就需要支援例項粒度；
- 第二個原因是從規模上看，更大規模的增長會帶來後設資料的極速膨脹，這會給註冊中心和客戶端帶來更大的記憶體佔用。按照現有資料分析，如果升級到應用級註冊發現，以平均釋出 50 個服務的應用為例，將減少 60% 的記憶體佔用和註冊中心資料。以釋出超過 10k 介面的平臺型應用為例，這些資料可降低 90%。

可以看到，應用級註冊發現帶來的最佳化是十分顯著的。由於應用級註冊發現目前已經基本開發完畢，下面我們可以簡單介紹下它的原理。

![11.PNG](https://ucc.alicdn.com/pic/developer-ecology/bc3dcbe04e44425badc9826af1e1340f.png)

首先要解決的一個問題是如何保證平滑遷移，使用者基於介面的配置怎麼對映到應用上去。

這裡我們抽象出了後設資料中心來管理介面到應用的對映以及應用級的後設資料。在部署態，Dubbo 框架會自動上報這個關係到後設資料中心。而執行態使用者側的配置和服務治理則透過這份對映關係重新將應用粒度對映到介面粒度。涉及到最核心的部分——選址也是分為兩部分，應用級選址和介面級選址同時存在，方便進行服務治理。

## 3. K8s 雲原生支援

Dubbo3.0 第三個內容是 K8s 雲原生支援。

![12.PNG](https://ucc.alicdn.com/pic/developer-ecology/ba8778b750d54737b6089b5ee944beae.png)

這裡主要包括兩部分內容：

- 一是需要**對齊 K8s 的生命週期**，能夠讓 Dubbo 服務原生的在 K8s 體系內註冊和發現；
- 第二則是**對 Mesh 的支援**。上面在協議那裡我們已經講到，新協議透過使用 HTTP2 進行 header / payload 分離解決了閘道器需要解析完整協議的問題。另外一個問題則是服務註冊發現和治理，註冊發現需要 Dubbo 能夠在 Mesh 的 xDS 體系內作為資料面打通。治理則需要將原有的規則逐步遷移至基於  YAML 的剔除 IP 依賴的規則。最終的形態將是原生的 Dubbo 服務能夠和基於 thin SDK 的 Dubbo + Mesh 完美互通和進行服務治理。

## 4. 柔性增強

Dubbo3.0 最後一部分是柔性增強。

![13.PNG](https://ucc.alicdn.com/pic/developer-ecology/45a33fd0a4614804b06e16b26dfdf5e0.png)

柔性增強要解決的問題有兩個：

- 一是在節點異常的情況下，分散式服務能夠保持穩定，不出現雪崩等問題;
- 二是對於大規模的應用，能夠以最佳態執行，提供較高的吞吐量和效能。

**從方法上看**，Dubbo3.0 的柔性增強會以面向失敗設計為理念，提供包括精準容量評估、自適應限流、自適應負載均衡的支援，自底向上的分步構建大規模可靠應用。從單一服務的視角看，服務是壓不垮的，穩定的。

**從分散式視角看**，複雜的拓撲不會帶來效能的下降，分散式負載均衡能夠以最優的方式動態分配流量，保證異構系統能夠根據執行時的準確服務容量合理分配請求，從而達到效能最優。

# Dubbo3.0 路線圖

介紹完了 Dubbo3.0 的主要內容，下面我們來看一下 roadmap。

![14.png](https://ucc.alicdn.com/pic/developer-ecology/614399773257485f85d010095372b22e.png)

在接下來的 9 月份，應用級註冊發現會同時在阿里巴巴內部和外部公司同時大規模落地。今年雙十一前會交付雲原生服務治理規則。到明年的 3 月份，開源側的新協議支援功能基本完備。明年的 6 月份，雲原生 K8s 的支援和 Mesh 支援功能完備，開始試點。柔性增強將在 2022 年的 3 月份全面落地，請拭目以待。

看了 roadmap ，大家可以發現，Dubbo3.0 已經是執行態。

![15.PNG](https://ucc.alicdn.com/pic/developer-ecology/d6d00d38dbde4439b067b3efd1d7e14c.png)

首先，基於 Dubbo3.0 核心的 HSF3.0 在阿里巴巴內部大規模落地，內外統一的路線不僅僅是對 Dubbo 質量的肯定，也是對社群使用者的保障和回饋。

後續我們會將內部的大規模高併發經驗繼續輸出到 Dubbo 開源側，也會以最高的質量來保證 Dubbo 的可靠演進。Dubbo 3.0 的應用級註冊發現功能也在內部和開源側同時灰度試點。在協議側，新協議已經在阿里巴巴和螞蟻的互通中得到廣泛應用，內部實踐的經驗將更好的服務開源側協議演進。

最後，歡迎大家參與 dubbo 的社群，分享你們在實踐中的經驗，反饋碰到的問題，攜手讓 Dubbo 發展得更好。

**關注阿里巴巴雲原生公眾號，後臺回覆 【818】 即可獲取直播回看地址和大會 PPT 合集。**

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/5i8PucCcKfFOq8MNQgrr1Q)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

Dubbo 3.0 - 開啟下一代雲原生微服務

相關文章