作者 | 郭浩
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