簡介： HSF 和 Dubbo 的融合是大勢所趨。為了能更好的服務內外用戶，也為了兩個框架更好發展，Dubbo 3.0 和以 Dubbo 3.0 為內核適配集團內基礎架構生態的 HSF 3 應運而生。

作者 | 郭浩

Dubbo 和 HSF 都是阿里巴巴目前在使用的微服務 RPC 框架。HSF 在阿里巴巴使用更多，承接了內部從單體應用到微服務的架構演進，支撐了阿里歷年雙十一的平穩運行；Dubbo 則在 2011 年開源后，迅速成為業界廣受歡迎的微服務框架產品，在國內外均有著廣泛應用。
自 2008 年 5 月發布第一個版本 1.1 后，經歷數年迭代，HSF 從一個基礎的 RPC 框架逐漸演變成為日支撐十萬億級別調用的易于擴展的微服務框架。內部場景中，用戶既可以選擇少量配置輕松接入微服務體系，獲取高性能的穩定服務調用。也可以按照自身業務需求，對 HSF 進行擴展，獲取整條鏈路的能力增強。

Dubbo 項目誕生于 2008 年，起初只在一個阿里內部的系統使用；2011 年，阿里 B2B 決定將整個項目開源，僅用了一年時間就收獲了來自不同行業的大批用戶；2014 年，由于內部團隊調整，Dubbo 暫停更新；2017 年 9 月，Dubbo 3 重啟開源，在 2019 年 5 月由 Apache 孵化畢業，成為第二個由阿里巴巴捐獻至 Apache 畢業的項目。

Dubbo 和 HSF 在阿里巴巴的實踐

2008 年的時候，集團內部淘系主要使用的服務框架是 HSF， 而 B2B 使用的則是 Dubbo。二者獨立，各行其道，彼此不通。隨著業務飛速發展，跨語言、跨平臺、跨框架的需求日益明顯，不同業務間彼此互聯互通的呼聲越來越高，而且很快演變成為幾乎整個集團的需求。即淘系可以調用 B2B 的服務，反之亦然。

服務框架就像鐵路的鐵軌一樣，是互通的基礎，只有解決了服務框架的互通，才有可能完成更高層的業務互通，所以用相同的標準統一，共建新一代的服務框架是必然趨勢。也就是最終的框架需要同時兼容 HSF1.x 和 Dubbo (包括 1.x 和 2.x) 的協議。對于集團內的需求而言，穩定和性能是核心，因此，當時選型了在電商這種高并發場景久經考驗的 HSF 做為新一代服務框架核心。隨后，HSF 推出了 2.0 的版本，并針對 HSF 之前版本的主要問題進行重構改造，降低了維護成本，進一步提高了穩定性和性能。HSF 2.0 解決了通訊協議支持不透明，序列化協議支持不透明等框架擴展性問題。基于 HSF 2.0 的 Java 版本，集團內也演進出了 CPP/NodeJs/PHP 等多語言的客戶端。

由于兼容了 Dubbo 的協議，原有的 Dubbo 用戶可以平滑地遷移到新版本上，所以 HSF 推出后很快就在集團全面鋪開，部署的 server 數量達到數十萬，基本完成了阿里巴巴內部微服務框架的統一，并經歷了多年雙十一零點流量洪峰的驗證。

下一代微服務的挑戰和機遇

然而，業務的發展和框架自身的迭代使得兩個框架從協議層的簡單兼容已經無法滿足需要。隨著云計算的不斷發展和云原生理念的廣泛傳播，微服務的發展有著以下趨勢：

1、K8s 成為資源調度的事實標準，Service Mesh 從提出到發展至今已經逐漸被越來越多用戶所接受。屏蔽底層基礎設施成為軟件架構的一個核心演進目標，無論是阿里巴巴還是其他企業用戶，所面臨的問題都已經從是否上云變為如何平滑穩定地低成本遷移上云。

2、由于上云路徑的多樣以及由現有架構遷移至云原生架構的過渡態存在，部署應用的設施靈活異變，云上的微服務也呈現出多元化的趨勢。跨語言、跨廠商、跨環境的調用必然會催生基于開放標準的統一協議和框架，以滿足互通需求。

3、端上對后臺服務的訪問呈爆炸性的趨勢增長，應用的規模和整個微服務體系的規模都隨之增長。

這些趨勢也給 HSF 和 Dubbo 帶來了新的挑戰。

第一，上云對內部閉源組件帶來了沖擊。微服務框架是基礎組件，大部分公司在早期選型或業務發展到一定規模的時候都需要確定使用某一個框架。而一個穩定高效的自研框架通常需要較長時間的迭代來打磨優化。所以，大部分公司初期都會傾向于使用開源組件。對阿里云而言，這就帶來了一個問題：內部使用的是 HSF 框架，而云上的用戶大部分都是使用的開源 Dubbo 框架，兩種框架在協議、內部模塊抽象、編程接口和功能支持上都存在差異。如何能讓使用了 HSF 的阿里集團內部組件的最優實踐和前沿技術更簡單直接地輸出到云上，這是每一個做技術商業化的同學都會遇到和必須解決的問題。

第二，原有部門或公司的技術棧如何更快地融入到現有技術體系是一個繞不開的問題。一個典型的例子就是 2019 年加入阿里巴巴的考拉。考拉之前一直使用 Dubbo 作為微服務框架，基于 Dubbo 構建了大規模的微服務應用，遷移的成本高，風險也大。需要集團和考拉的基礎架構部門耗費較長的時間進行遷移前調研、方案設計，確保基本可行后再開始改動。從分批灰度上線，再到最終全量上線。這種換血式的改動不僅需要耗費大量人力，時間跨度也很長，會影響到業務的發展和穩定性。

第三，由于歷史原因，集團內部始終存在著一定數量的 Dubbo 用戶。為了更好的服務這部分用戶，HSF 框架對 Dubbo 進行了協議層和 API 層的兼容。但這種兼容僅限于互通，隨著 Dubbo 開源社區的多年發展，這種基礎的兼容在容災、性能和可迭代性方面，都有著較大的劣勢，同時很難對齊 Dubbo 的服務治理體系。在穩定性方面也存在風險，更無法享受到集團技術發展和 Dubbo 社區演進的技術紅利。

產生這些問題的根本原因是閉源的 HSF 無法直接用于廣大云上用戶和外部其他用戶，而開源產品對閉源產品的挑戰會隨著開源和云的不斷發展愈演愈烈。越早解決這個問題，阿里巴巴和外部企業用戶的云原生遷移成本越低，產生的價值也就越大。

最簡單直接的方式是將 HSF 也開源出去。但這又會面臨兩個新問題。第一， Dubbo 是阿里較早開源的明星產品，如果 HSF 也開源，這兩個同類框架的關系和適用場景如何劃分，不僅外部用戶會有疑惑，重復開源也不利于品牌建設。第二，國內外現有的 Dubbo 用戶如果想上阿里云，則需要使用基于 HSF 的現有解決方案，需要花費巨大精力將所有用到 Dubbo 的應用遷移到 HSF，成本和穩定性都是不得不考慮的問題 。以上兩點原因說明目前已經不是開源 HSF 的最好時機。

既然 HSF 不能走出去，那剩下的解決方式就是讓 Dubbo 走進來。內部采用核心融合的方式，基于 Dubbo 內核重新構建 HSF 框架。

品牌建設上，融合可以使 Dubbo 現有的廣泛影響力得以持續發展，Dubbo 在集團內大規模落地后，會產生良好的原廠品牌示范效應，外部用戶也會有更多的信心在進行微服務框架選型時選擇 Dubbo。同時，目前已經使用 Dubbo 的用戶也有更充分的理由不斷追隨版本演進，享受阿里巴巴開源帶來的技術紅利。

工程實踐上，使用 Dubbo 重構 HSF 這種從內部重新統一的可行性更高，遷移的復雜度可控，能夠逐步地有序實現。內部完善的測試流程和豐富的場景是對 Dubbo 最好的功能回歸測試。內外統一也是兼顧商業化和內部支持的最好方式。在重構的過程中，不斷完善功能，提高性能，擁抱更新的更云原生的技術棧，這也是提升集團內部用戶體驗的最佳方式。

因此，HSF 和 Dubbo 的融合是大勢所趨。為了能更好的服務內外用戶，也為了兩個框架更好發展，Dubbo 3.0 和以 Dubbo 3.0 為內核適配集團內基礎架構生態的 HSF 3 應運而生。

下一代云原生微服務

首先總體上介紹一下 Dubbo 3.0 。

• Dubbo 3.0 支持全新的服務發現模型，Dubbo 3.0 嘗試從應用模型入手，優化存儲結構，對齊云原生主流設計模型，避免在模型上帶來的互通問題。新模型在數據組織上高度壓縮，能有效提高性能和集群的可伸縮性。
  

• Dubbo 3.0 提出了下一代 RPC 協議 —— Triple。這是一個基于 HTTP/2 設計的完全兼容 gRPC 協議的開放性新協議，由于是基于 HTTP/2 設計的，具有極高的網關友好型和穿透性；完全兼容 gRPC 協議是的天然在多語言互通方面上具有優勢。
  

• Dubbo 3.0 面向云原生流量治理，提出了一套能夠覆蓋傳統 SDK 部署、Service Mesh 化部署、VM 虛擬機部署、Container 容器部署等場景的統一治理規則，支持一份規則治理大部分場景，大大降低流量治理治理成本，使得異構體系下全局流量治理變得可能。
  

• Dubbo 3.0 將提供接入 Service Mesh 的解決方案，面向 Mesh 場景，Dubbo 3.0 提出了兩種接入方式，一種是 Thin SDK 模式，部署模型和當前 Service Mesh 主流部署場景完全一樣，而 Dubbo 將進行瘦身，屏蔽掉與 Mesh 相同的治理功能，僅保留核心的 RPC 能力；第二種是 Proxyless 模式，Dubbo 將接替 Sidecar 的工作職責，主動與控制面進行通信，基于 Dubbo 3.0 的統一治理規則應用云原生流量治理功能。
  

1、應用級注冊發現模型

應用級注冊發現模型的原型最早在 Dubbo 2.7.6 版本提出，經過數個版本的迭代最終形成了 Dubbo 3.0 中的穩定模型。在 Dubbo 2.7 及以前版本中，應用進行服務注冊和發現時，都是以接口為粒度，每個接口都會對應在注冊中心上的一條數據，不同的機器會注冊上屬于當前機器的元數據信息或者接口級別的配置信息，如序列化、機房，單元、超時配置等。所有提供此服務的服務端在進行重啟或者發布時，都會在接口粒度獨立的變更。

舉個例子，一個網關類應用依賴了上游應用的 30 個接口，當上游應用在發布時，就有 30 個對應的地址列表在進行機器上線和下線。以接口作為注冊發現第一公民的模型是最早的 SOA 或微服務的拆分方式，提供了靈活的根據單一服務單一節點獨立動態變更的能力。隨著業務的發展，單一應用依賴的服務數在不斷增多，每個服務提供方的機器數量也由于業務或容量原因不斷增長。客戶端依賴的總服務地址數上漲迅速，注冊中心等相關依賴組件的壓力倍增。

我們注意到了微服務模型發展的兩個趨勢：首先，隨著單體應用拆分為多微服務應用的基本完成，大規模的服務拆分和重組已經不再是痛點，大部分接口都只被一個應用提供或者固定幾個應用提供。其次，大量的用于標志地址信息的 URL 都是存在極大冗余的，如超時時間，序列化，這些配置變更頻率極低，卻在每個 URL 中都出現。所以應用級注冊發現應運而生。

應用級服務發現以應用作為注冊發現的基本維度。和接口級的主要區別是，一個應用提供了 100 個接口，按照接口級粒度需要在注冊中心上注冊 100 個節點，如果這個應用有 100 臺機器，那每次發布，對于它的客戶端都是 10000 個虛擬節點的變更。而應用級注冊發現則只需要 1 個節點， 每次發布只變更 100 個虛擬節點。對于依賴服務數多、機器多的應用而言，是幾十到上百分之一數量級的規模下降。內存占用上也會至少下降一半。

最后，由于這個新的服務發現與 Spring Cloud、Service Mesh 等體系下的服務發現模型是一致的，因此 Dubbo 可以從注冊中心層面與其他體系下的節點實現互發現，實現異構微服務體系的互聯互通。

2、下一代 RPC 協議——Triple

作為 RPC 框架最基礎的能力還是完成跨業務進程的服務調用，將服務組成鏈、組成網，這其中最核心的載體就是協議。Dubbo 2.0 提供了 RPC 的核心語義，包括協議頭、標志位、請求 ID 以及請求 / 響應數據，他們被按照一定的順序以二進制數據的方式組合在一起。

在云原生時代，Dubbo 2.0 協議主要面臨兩個挑戰。一是生態不互通，用戶很難直接理解二進制的協議。第二是對 Mesh 等網關型組件不夠友好，需要完整的解析協議才能獲取到所需要的調用元數據，如一些 RPC 上下文，從性能到易用性方面都會面臨挑戰。同時，老版本 Dubbo 2.0 RPC 協議的設計與實現，已在實踐中被證實在?些?面限制了業務架構的發展，?如從終端設備到后端服務的交互、微服務架構中多語言的采用、服務間的數據傳輸模型等。那么，在支持已有的功能和解決存在的問題的前提下，下一代的協議需要有哪些特性呢？

首先，新協議應該易擴展，包括但不限于 Tracing/ Monitoring 等支持，也應該能被各層設備識別，降低用戶理解難度。

其次，協議需要解決跨語言互通的問題，傳統的多語言多 SDK 模式和 Mesh 化跨語言模式都需要一種更通用易擴展的數據傳輸格式。

最后，協議應該提供更完善的請求模型，除了 Request/Response 模型，還應該支持 Streaming 和 Bidirectional 等模型。

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

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

3、原生接入 Service Mesh

如何讓 Dubbo 在 Service Mesh 體系下落地，社區開發團隊調研眾多方案，最終確定了最適合 Dubbo 3.0 的兩種形態的 Mesh 方案。

?種是經典的基于 Sidecar 的 Service Mesh，另?種是無 Sidecar 的 Proxyless Mesh。對于 Sidecar Mesh 方案，其部署方式和當前主流 Service Mesh 部署方案一致，Dubbo 3.0 的重點是盡量給業務應用提供完全透明的升級體驗，這不止是編程視角的無感升級，還包括通過 Dubbo 3.0 輕量化、Triple 協議等，讓整個調用鏈路上的損耗與運維成本也降低到最低。這個方案也被稱為 Thin SDK 方案，而 Thin 的地方就是在去除所有不需要的組件。Proxyless Mesh 部署方案則是 Dubbo 3.0 規劃的另?種 Mesh 形態，目標是不需要啟動 Sidecar，由傳統 SDK 直接與控制面交互。

我們設想這對以下?種場景會?常適用 Proxyless Mesh 部署方案：

一是業務方期望升級 Mesh 方案，但卻無法接受由于 Sidecar 進行流量劫持所帶來的性能損耗，這種情況常見于核心業務場景；

二是期望降低由于部署 Sidecar 帶來的運維成本，降低系統復雜度；三是遺留系統升級緩慢，遷移過程漫長，多種部署架構?期共存。

最后是，多種部署環境，這里的多種部署環境包括了如 VM 虛擬機、Container 容器等多種部署方式，也包括了多種類型應用混合部署，例如 Thin SDK 與 Proxyless 方案混合部署，對性能敏感應用部署 Proxyless 模式，對于周邊應用采用 Thin SDK 部署方案，多種數據面共同由統一控制面進行調度。

將這兩種形態統籌來看，在不同的業務場景、不同的遷移階段、不同的基礎設施保障情況下， Dubbo 都會有 Mesh ?案可供選擇。

4、柔性服務增強

云原生帶來了技術標準化的重大變革，如何讓應用在云上更簡單地創建和運行，并具備可彈性擴展的能力，是所有云原生基礎組件的核心目標。借助云原生技術帶來的彈性能力，應用可以在極短時間內擴容出一大批機器以支撐業務需要。比如為了應對零點秒殺場景或者突發事件，應用本身往往需要數千甚至數萬的節點數來以滿足用戶的需要，但是在擴容的同時也帶來了許多在云原生場景下集群大規模部署的問題。比如由于集群節點極多導致的節點異常頻發、服務容量受多種客觀因素影響導致節點服務能力不均等。

Dubbo 期待基于一種柔性的集群調度機制來解決這些問題。這種機制主要解決的問題有兩個方面：一是在節點異常的情況下，分布式服務能夠保持穩定，不出現雪崩等問題；二是對于大規模的應用，能夠以最佳態運行，提供較高的吞吐量和性能。從單一服務視角看，Dubbo 期望的目標是對外提供一種壓不垮的服務，即是在請求數特別高的情況下，可以通過選擇性地拒絕一些的請求來保證總體業務的正確性、時效性。

從分布式視角看，要盡可能降低因為復雜的拓撲、不同節點性能不一導致總體性能的下降，柔性調度機制能夠以最優的方式動態分配流量，使異構系統能夠根據運行時的準確服務容量合理分配請求，從而達到性能最優。

5、業務收益

對業務而言，可能更關心的是升級到 Dubbo 3.0 能帶來哪些收益。總結提煉出兩大關鍵詞，分別是應用自身的性能穩定性的提升以及云原生的原生接入。

• 性能與穩定性方面，Dubbo 3.0 會著力關注大規模集群部署的場景，通過優化數據存儲方式，來降低單機資源損耗，同時可以在應對超大規模集群的水平擴容的時候，保證整個集群的穩定性。另外，在 Dubbo 3.0 提出了柔性服務的概念，也能夠在一定程度上有效保證和提高全鏈路總體可靠性和資源的利用率。
  

• 第二是關于云原生方面，Dubbo 3.0 是 Dubbo 全面擁抱云原生的里程碑版本，當前 Dubbo 在國內外有基數巨大的用戶群體，隨著云原生時代的到來，這些用戶上云的需求越來越強烈，Dubbo 3.0 將提供完整可靠的解決方案、遷移路徑與最佳實踐幫助企業實現云原生轉型，享受云原生帶來的紅利。
  

從已經落地的結果上看，Dubbo 3.0 能?幅降低框架帶來的額外資源消耗，提升系統資源利用率。從單機視?，Dubbo 3.0 能節省約 50% 的內存占?；從集群視角，Dubbo3 能?持百萬實例數的大規模集群，為未來更大規模的業務擴容打下基礎；Dubbo3 對 Reactive Stream 等通信模型的支持，在大文件傳輸、流式等業務場景下能帶來整體吞吐量的?幅提升。

架構方面，Dubbo 3.0 給業務架構升級帶來了更多可能性。Dubbo 原來的協議在?定程度上束縛了微服務接??式的，舉個例子，移動端、前端業務要接入 Dubbo 后端服務，需要經過網關層的協議轉換，再比如，Dubbo 只?持 request-response 模式的通信，這使得?些需要流式傳輸或反向通信的場景?法得到很好的支持。

在云原生轉型過程中，業務最關心的就是改動和穩定性，能不能不改代碼或者少改代碼就能升級到云原生環境，在業務上云過程的選型中至關重要。Dubbo 3.0 給業務側云原?生升級帶來了整體的解決方案。不論是底層基礎設施升級帶動業務升級，還是為解決業務痛點而進行的主動升級，Dubbo 3.0 所提供的云原生解決方案都能幫助產品快速升級，進入云原生時代。

6、現狀和 Roadmap

內部使用上，Dubbo 3.0 已經在考拉業務的數百應用的數萬節點中全面落地，大量應用使用 Dubbo 3.0 輕松完成應用上云，目前正在電商核心應用中大規模試點和逐步落地，以及開啟應用級注冊發現、Triple 協議等新特性。開源用戶和商業化應用目前也在從原有的 HSF2 或 Dubbo 2.0 遷移至 Dubbo 3.0 ，服務框架團隊和社區正在整理和編寫相關遷移的最佳實踐，一段時間后這些文檔就會和大家見面。

Dubbo 3.0 作為捐給 Apache 后的一個里程碑版本已經在今年 6 月份正式發布了，這也代表著 Apache Dubbo 全面擁抱云原生的一個節點。在 2021 年 11 月我們會發布 Dubbo 3.1 版本，屆時會帶來 Dubbo 在 Mesh 場景下部署的最佳實踐。

2022 年 3 月會發布 Dubbo 3.2 版本，這個版本將帶來服務柔性的全面支持，在大規模應用部署下實現智能流量調度，提高系統穩定性與資源利用率。

回顧過去，Dubbo 和 HSF 在阿里巴巴和微服務框架的發展的不同階段都起到了至關重要的作用。立足現在，放眼未來，Dubbo 3.0 和基于 Dubbo 3.0 內核的 HSF 正在外部和內部齊頭并進，做最穩定高性能的微服務框架，給用戶最好的使用體驗，繼續在云原生時代引領微服務的發展。

作者介紹：郭浩，阿里巴巴服務框架負責人，Dubbo 3.0 架構師，專注分布式系統架構

﹀

﹀

﹀

【提交評測抽天貓精靈】

2021 云原生編程挑戰賽正式啟動評測，選手報名后提交評測，后臺每周都將抽取 10 個獲獎隊伍贈送天貓精靈 1 個。點擊下方鏈接立即報名！

https://tianchi.aliyun.com/competition/entrance/531923/introduction

原文鏈接：https://developer.aliyun.com/article/790307?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的Dubbo 和 HSF 在阿里巴巴的实践：携手走向下一代云原生微服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。