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

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

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

看到這個題目，你們可能會有幾個問題，好比，什麼是雲原生微服務？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 的歷史。

在 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 的開源現狀。

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

數據來源《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 ，讓咱們拭目以待。

從數據上看， Dubbo 目前有 33k stars 和 21k forks，分別位於 github java 項目前十和前三，用戶的承認帶來了社區的活躍，而活躍的社區則會以高頻率的版本更新帶來更多新的、有用的特性來彰顯其旺盛的活力。目前已經登記的 Dubbo 企業用戶超過了 200 個，其中有 30 多個企業成爲了 Dubbo 的生態合做夥伴。

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

從功能上看，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，這對於性能和跨語言都有着巨大的意義。

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

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

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

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

目前咱們能夠看到的幾個趨勢是 K8s 成爲資源調度的事實標準、Mesh 化成爲主流以及規模上的急速增加。這些趨勢的存在對 Dubbo 提出了更高的要求:

• 首先，用戶如何在 K8s 上更方便的部署和調用 Dubbo 服務是必需要解決的問題，要解決這個問題，統一的協議和數據交換格式是必須前提；

 

• 其次，Mesh 化的流行帶來了多元化問題，即原生 Dubbo 和 Mesh 化 Dubbo 如何共存，多語言的場景如何支持；

 

• 第三點，規模的增加會給整個 Dubbo 架構帶來更大的挑戰，不管是註冊中心等組件，仍是客戶端，都會有更多的數據和調用量。如何在保持穩定的前提下，提供更高效的服務是 Dubbo 演進的重中之重。

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

1. 下一代 RPC 協議

首先咱們從協議開始。

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

• 一是生態不互通，用戶很難直接理解二進制的協議；

• 第二是對 Mesh 等網關型組件不夠友好，須要完整的解析協議才能獲取到所須要的調用元數據，如一些 RPC 上下文，從性能到易用性方面都會面臨挑戰。

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

• 首先，協議須要解決跨語言互通的問題，傳統的多語言多 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 第二個內容是應用級註冊發現。

熟悉 Dubbo 的同窗都知道，Dubbo 目前的註冊發現都是接口級別的。也就是同一個應用發佈的多個服務會在註冊中心註冊多份數據，這些數據彼此獨立，方便進行服務化改造和接口遷移。爲何要提出應用級註冊發現呢？

主要有兩個緣由：

• 一是現有生態系統的互通，包括 Spring cloud 和 K8s 都是基於實例，也就是應用級別進行的註冊發現，Dubbo 要成爲鏈接異構系統最好用的 RPC 框架就須要支持實例粒度；

 

• 第二個緣由是從規模上看，更大規模的增加會帶來元數據的極速膨脹，這會給註冊中心和客戶端帶來更大的內存佔用。按照現有數據分析，若是升級到應用級註冊發現，以平均發佈 50 個服務的應用爲例，將減小 60% 的內存佔用和註冊中心數據。以發佈超過 10k 接口的平臺型應用爲例，這些數據可下降 90%。

能夠看到，應用級註冊發現帶來的優化是十分顯著的。因爲應用級註冊發現目前已經基本開發完畢，下面咱們能夠簡單介紹下它的原理。

首先要解決的一個問題是如何保證平滑遷移，用戶基於接口的配置怎麼映射到應用上去。

這裏咱們抽象出了元數據中心來管理接口到應用的映射以及應用級的元數據。在部署態，Dubbo 框架會自動上報這個關係到元數據中心。而運行態用戶側的配置和服務治理則經過這份映射關係從新將應用粒度映射到接口粒度。涉及到最核心的部分——選址也是分爲兩部分，應用級選址和接口級選址同時存在，方便進行服務治理。

3. K8s 雲原生支持

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

這裏主要包括兩部份內容：

• 一是須要對齊 K8s 的生命週期，可以讓 Dubbo 服務原生的在 K8s 體系內註冊和發現；

 

• 第二則是對 Mesh 的支持。上面在協議那裏咱們已經講到，新協議經過使用 HTTP2 進行 header / payload 分離解決了網關須要解析完整協議的問題。另一個問題則是服務註冊發現和治理，註冊發現須要 Dubbo 可以在 Mesh 的 xDS 體系內做爲數據面打通。治理則須要將原有的規則逐步遷移至基於  YAML 的剔除 IP 依賴的規則。最終的形態將是原生的 Dubbo 服務可以和基於 thin SDK 的 Dubbo + Mesh 完美互通和進行服務治理。
  

4. 柔性加強

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

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

• 一是在節點異常的狀況下，分佈式服務可以保持穩定，不出現雪崩等問題;

• 二是對於大規模的應用，可以以最佳態運行，提供較高的吞吐量和性能。

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

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

Dubbo3.0 路線圖

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

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

看了 roadmap ，你們能夠發現，Dubbo3.0 已是運行態。

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

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

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

- END -

「技術分享」某種程度上，是讓做者和讀者，不那麼孤獨的東西。歡迎關注個人微信公衆號：「Kirito的技術分享」

本文分享自微信公衆號 - Kirito的技術分享（cnkirito）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。