作者|泮圣偉、董建凱

服務框架就像鐵路的鐵軌一樣，是互通的基礎，只有解決了服務框架的互通，才有可能完成更高層的業務互通，所以用相同的標準統一，合二為一并共建新一代的服務框架是必然趨勢。

Dubbo3.0 是 Dubbo2.0 與 HSF 融合而來，是阿里經濟體面向內部業務、商業化、開源的唯一標準服務框架。

阿里巴巴服務框架的選擇與實踐

Dubbo 和 HSF 在阿里巴巴的實踐

Dubbo 和 HSF 都是阿里巴巴目前在使用的微服務 RPC 框架。

Dubbo 則在 2011 年開源后，迅速成為業界廣受歡迎的微服務框架產品，在國內外均有著廣泛應用。Dubbo 項目誕生于 2008 年，起初只在一個阿里內部的系統使用；2011 年，阿里 B2B 決定將整個項目開源，僅用了一年時間就收獲了來自不同行業的大批用戶；2014 年，由于內部團隊調整，Dubbo 暫停更新；2017 年 9 月，Dubbo 3.0 重啟開源，在 2019 年 5 月由 Apache 孵化畢業，成為第二個由阿里巴巴捐獻至 Apache 畢業的項目。

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

對于集團內的需求而言，穩定和性能是核心，因此，當時選型了在電商這種高并發場景久經考驗的 HSF 做為新一代服務框架核心。隨后，HSF 推出了 2.0 的版本，并針對 HSF 之前版本的主要問題進行重構改造，降低了維護成本，進一步提高了穩定性和性能。HSF2.0 解決了通訊協議支持不透明，序列化協議支持不透明等框架擴展性問題。基于 HSF2.0 的 Java 版本，集團內也演進出了 CPP/NodeJs/PHP 等多語言的客戶端。由于 HSF 還兼容了 Dubbo 的協議，原有的 Dubbo 用戶可以平滑地遷移到新版本上，所以 HSF 推出后很快就在集團全面鋪開，部署的 server 數量達到數十萬，基本完成了阿里巴巴內部微服務框架的統一，并經歷了多年雙十一零點流量洪峰的驗證。

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

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

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

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

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

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

HSF 和 Dubbo 面臨的挑戰

微服務框架是基礎組件，大部分公司在早期選型或業務發展到一定規模的時候都需要確定使用某一個框架。而一個穩定高效的自研框架通常需要較長時間的迭代來打磨優化。所以大部分公司初期都會傾向于使用開源組件。對阿里云而言，這就帶來了一個問題：內部使用的是 HSF 框架，而云上的用戶大部分都是使用的開源 Dubbo 框架，兩種框架在協議、內部模塊抽象、編程接口和功能支持上都存在差異。

如何能讓使用了 HSF 的阿里集團內部組件的最優實踐和前沿技術更簡單直接地輸出到云上，這是每一個做技術商業化的同學都會遇到和必須解決的問題。其實我們也有過一些探索，云上微服務最早推的是 HSF 框架，閉源組件在云上輸出的時候，對于許多用戶而言，遇到問題后無從排查，整個服務框架對于他們來說是一個黑盒的組件。我們發現這并不是一個很好的產品化方向，在云上輸出的時候，我們必須選擇擁抱開源的方式，主推 Dubbo 與 Spring Cloud 框架。

同時在集團內也因為同時存在 HSF 與 Dubbo 框架而導致的不少問題。原有部門或公司的技術棧如何更快地融入到現有技術體系是一個繞不開的問題。一個典型的例子就是 2019 年加入阿里巴巴的考拉?？祭耙恢笔褂?Dubbo 作為微服務框架，基于 Dubbo 構建了大規模的微服務應用，遷移的成本高，風險也大。需要集團和考拉的基礎架構部門耗費較長的時間進行遷移前調研、方案設計，確保基本可行后再開始改動。從分批灰度上線，再到最終全量上線。這種換血式的改動不僅需要耗費大量人力，時間跨度也很長，會影響到業務的發展和穩定性。同時由于歷史原因，集團內部始終存在著一定數量的 Dubbo 用戶。為了更好的服務這部分用戶，HSF 框架對 Dubbo 進行了協議層和 API 層的兼容。但這種兼容僅限于互通，隨著 Dubbo 開源社區的多年發展，這種基礎的兼容在容災、性能和可迭代性方面，都有著較大的劣勢，同時很難對齊 Dubbo 的服務治理體系。在穩定性方面也存在風險，更無法享受到集團技術發展和 Dubbo 社區演進的技術紅利。

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

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

三位一體戰略下服務框架的最終選擇 Dubbo3.0

Dubbo3.0 在原有功能集與 API 完全兼容的前提下，同時具備了以下幾大面臨云原生挑戰下的新特性

• 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 的統一治理規則應用云原生流量治理功能。

服務框架在阿里云商業化方向上的演進思路

對于微服務框架來說，由于關聯到客戶的業務代碼，要做商業化還是有非常大的挑戰的。

首先，遷移成本上來說，希望把降低遷移成本為 0，最開始我們在云上售賣的是 HSF + EDAS Container 這一套的架構，因此客戶在上云的時候，不得不對自己的業務代碼進行改造，另外，由于代碼不開源，排查問題也是一個非常頭疼的問題，后來，我們發現客戶大多數的微服務框架都會選擇開源的 Dubbo/Spring Cloud，但是客戶有自建的注冊中心，如果要上云還需要把自己的注冊中心遷移到 MSE 注冊中心上，這個過程需要用戶對代碼做改造才行，一般來說會采用雙注冊的方案，在云上我們發現推動客戶做代碼改造，包括 SDK 的升級是一件非常難的事情，很多客戶的 Dubbo 版本還停留在 4-5 年的版本，不僅需要研發、測試、運維都來關注，還需要排期支持，這個動作會耗費大量的人力資源，同時面臨許多穩定性的挑戰。光是這一步就會阻擋住許多的客戶了，為了解決客戶 SDK 升級的問題，我們在想，能不能不要遷移注冊中心呢，最好是代碼一行也不用改，部署到云上來，但我們又需要提供同等的服務治理能力，因此，我們提出了基于 Java Agent 字節碼增強的技術，幫助用戶不改一行代碼使用云產品，對客戶做到了隨時可上可下，沒有綁定，讓客戶比較放心的上云產品，同時我們還提供了能力更強的面運維的托管的注冊中心。

對于商業化中微服務框架的選擇，我們選擇的態度一直是擁抱開源。

我們還需要在開源微服務框架的基礎上提供差異化的服務治理能力，傳統開源微服務框架在 K8s 上的問題在上云的過程中逐步暴露出來。通過一系列和客戶的交流，我們總結出了客戶的云原生下進行微服務治理的幾大痛點，主要包括微服務發布過程中的無損上下線，標簽路由，服務鑒權，離群實例摘除，全鏈路灰度等等，我們通過 Java Agent 技術實現了在用戶不改代碼的情況下，解決了上述問題，通過客戶交流，收集需求，落到產品，給客戶 demo 驗證這個模式跑通了正向的循環，功能不斷豐富中。除了Java Agent，對于多語言的場景我們使用 Service Mesh、WASM 等技術，同樣支持客戶無需修改一行代碼，就具備于 Java 應用一致的服務治理能力與體驗。

同時在Java Agent 的選擇上我們也有過一些嘗試跟選擇，一開始我們使用閉源開發的 Java Agent，每個云產品都有一個對應的 Java Agent，這樣會導致 Java Agent 過多以及Agent沖突等問題，同時由于我們自己維護的 Java Agent 又是閉源的。踩過一些坑后，我們決定使用 Arthas One Agent 重構服務治理體系的 Agent，將治理相關的 Agent 合成一個，同時我們底座的 Java Agent 也使用擁抱開源的策略，我們使用開源的 Arthas One Agent。

Dubbo3.0 順應了這個方向，通過 Dubbo3.0 + Java Agent 將集團技術發展和 Dubbo 社區演進、以及商業化實踐的技術紅利不斷且持續地輸出給云上的客戶。

服務治理無縫支持 Dubbo3.0

阿里云上微服務治理相關的三種解決方案：MSE(微服務引擎，提供微服務治理的能力)、EDAS(全生命周期托管的應用平臺)、SAE(具備彈性伸縮能力的Serverless 應用平臺)，EDAS 與 SAE 均深度集成了 MSE 服務治理能力；其中 MSE 所有的服務治理能力都是開箱即用，支持近五年來市面上所有開源 Dubbo、Spring Cloud 框架，包括 Dubbo 3.0 您無需修改一行代碼與配置，您只需將您的 Dubbo 3.0 的應用接入 EDAS/MSE/SAE。包括微服務發布過程中的無損上下線能力，對齊了微服務與 K8S POD 的生命周期；標簽路由能力弱化了對 IP 的綁定依賴，服務鑒權，離群實例摘除，全鏈路灰度，服務 Mock、服務監控、服務契約等等。

如何將一個 HSF 應用無縫升級成 Dubbo 3.0 應用

三位一體是阿里巴巴“自研”、“開源”、“商業化”采用統一技術體系，在此技術方向下，Dubbo3.0 的設計與落地實現了 HSF/Dubbo 的技術統一，在集團內也正在快速推廣落地中。同時 EDAS Container 4.x版本，正是 Dubbo3.0 的商業化輸出形式之一。

如果您的應用在 EDAS 或者 SAE 上，使用的是 HSF + EDAS Container 這一套的架構，用戶只需升級容器版本至 4.x 就可以便捷的將 HSF 應用升級為 Dubbo 3.0 應用。升級之后，HSF 應用可沿用原有開發方式，還可以使用 EDAS/SAE 為 Dubbo 應用提供的更加完善的服務治理功能。同時您的HSF應用也將會具備 Dubbo 3.0 的各種新特性、應用級服務發現、Triple 協議等。

Java 微服務 Proxyless Mesh 架構

在異構微服務場景下，隨著 ServiceMesh 方案的普及，原先微服務應用如何在 Service Mesh 微服務架構中與其他 Mesh 節點進行互通以及治理能力對齊成了困擾用戶的問題。開源 Spring Cloud / Dubbo 框架在MSE微服務引擎上無需增加 Envoy，同時也無需修改任何一行代碼就可以與 Mesh 架構互通。

Dubbo3.0 的大規模生產實踐案例

Dubbo3.0 在落地的過程中，我們具備許多大規模的實踐，考拉、釘釘等。

下面以釘釘為例介紹

背景

為了擁抱容器化、享受云上的福利，釘釘文檔在 2020 年啟動了上云戰役。目前已有 50% 的流量，跑在公有云集群。

業務挑戰

文檔的上云，分成了兩個階段。

第一階段，彈內（即阿里集團內網絡）和云上各有一個文檔集群：彈內集群承接存量業務；云上集群承接增量業務。彈內集群同時起了代理的功能：對彈內的上游服務來說，彈內集群代理了對文檔云上集群的調用；對云上集群來說，彈內服務代理了集團內下游的依賴。

第二階段，存量數據遷移到了云上，只保留云上集群。上游服務、下游依賴，都是通過 triple 協議直接調用。

目前我們處于第一階段。

在第一階段，我們有幾個訴求：

1、希望使用一套代碼，跑在彈內、云上兩個集群；
2、希望彈內集群繼續使用 HSF 協議；
3、希望云上使用開源的 RPC 協議；
4、希望云上、彈內集群，可以互通。

而 Dubbo 3.0，完美的契合我們的需求。

落地方案

1、雙集群

文檔目前有兩個集群。彈內集群暴露了 triple、hsf 雙協議，云上集群僅暴露 triple 協議。

彈內的版本號保持 1.0.0 不變，云上使用 1.0.0.ZJK 的版本號。

對上游服務來說，只有彈內一個集群，所有流量都是打到彈內集群。這樣上游業務無需做任何改造。

2、單元化路由

彈內服務，對到來的 HSF 請求進行攔截。如果解析出需要將請求路由到云上，則對云上服務發起一次 triple 調用。否則，繼續將請求交給彈內的服務。

3、下游依賴

文檔有一些對彈內服務的依賴，去除不掉。目前的做法，是文檔自己把下游服務做一次封裝，暴露出 triple 協議，供云上調用。

4、服務治理

服務互通完成了之后，就是開始看如何進行服務治理了。包括服務查詢、服務測試、服務壓測、服務限流、服務監控等。

4.1 MSE

服務查詢、服務測試、服務路由等，都是通過接入 MSE 完成的。這里要特別提一下 MSE 的服務測試。業務同學最開始是在本機 curl hsf 的 http 端口進行測試，非常麻煩，但是在接入 MSE 服務治理之后，就可以直接用 MSE 平臺的服務測試功能。服務測試即為用戶提供一個云上私網 Postman ，讓用戶能夠輕松調用自己的服務。用戶無需感知云上復雜的網絡拓撲結構，無需關系服務的協議，無需自建測試工具，只需要通過控制臺即可實現服務調用。支持 Dubbo 3.0 框架，以及 Dubbo 3.0 主流的 Triple 協議。

4.2 其他

由于云上使用了標準的 Dubbo 協議，Ahas、Arms 等中間件，都可以無縫的接入。

總結

釘釘文檔借助三位一體的紅利實現三個月內快速上云，通過云產品方式產品化標準化地解決了上云過程中遇到的問題，借助 Dubbo3.0 的云原生特性，以及 MSE 服務治理能力的快速接入與支持，快速完成服務框架從互通到治理的落地。

尾

自研、商用、開源的“三位一體”，使得我們在 雙11 中沉淀的核心技術可以直接給到客戶使用，省略了經過云上沉淀再輸出的過程，降低了客戶獲取 “雙11 同款技術引擎” 的門檻和成本，可幫助客戶快速邁入數字原生時代。Dubbo3.0 正是在這個戰略下的選擇，Dubbo3.0 和基于 Dubbo3.0 內核的 HSF 正在外部和內部齊頭并進，為阿里云上、集團內、以及開源的用戶提供最佳的用戶體驗，一起參與來打造最穩定的服務框架，在云原生時代下引領微服務的發展。

掃描下方二維碼加群（釘釘搜群號34754806）觀看本次直播回放，或者移步直播間觀看：
https://yqh.aliyun.com/live/detail/26399

阿里云 MSE 云產品已集成Dubbo微服務治理解決方案
點擊鏈接（https://www.aliyun.com/product/aliware/mse），即刻上手體驗！

總結

以上是生活随笔為你收集整理的Dubbo3.0｜阿里巴巴服务框架三位一体的选择与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

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