簡介： 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
在雲原生時代，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
⼀種是經典的基於 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 作為捐給 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 架構師，專注分布式系統架構
原文鏈接
本文為阿里雲原創內容，未經允許不得轉載。