作者|泮聖偉、董建凱
服務框架就像鐵路的鐵軌一樣，是互通的基礎，只有解決了服務框架的互通，才有可能完成更高層的業務互通，所以用相同的標準統一，合二為一併共建新一代的服務框架是必然趨勢。
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/d...
阿里雲 MSE 雲產品已整合Dubbo微服務治理解決方案
點選連結（https://www.aliyun.com/produc...），即刻上手體驗！