Dubbo3.0 介紹

自從 Apache Dubbo 在 2011 年開源以來，經過多年一眾大規模互聯網、IT 公司的實踐積累了大量經驗，Dubbo 憑著對 Java 用戶友好、功能豐富、治理能力強等優點在過去取得了很大的認可，成為國內外流行主流的 RPC 框架之一。

但隨著云原生時代的到來，對以 Apache Dubbo、Spring Cloud 等為代表的 Java 微服務治理體系提出了新的要求，包括期望應用可以更快的啟動、應用通信的協議穿透性可以更高、能夠對多語言的支持更加友好等。比如 Spring 在今年也推出了其基于 GraalVM 的 Spring Native Beta 解決方案，擁有毫秒級啟動的能力、更高的處理性能等。

這樣的背景對下一代 Apache Dubbo 提出了兩大要求：

1、要保留已有開箱即用和落地實踐背景下帶來的好處，這也是眾多開發者所期望的；

2、盡可能地遵循云原生思想，能更好的復用底層云原生基礎設施、貼合云原生微服務架構。

Dubbo 3.0 是在云原生背景下誕生的，使用 Dubbo 構建的微服務遵循云原生思想，能更好的復用底層云原生基礎設施、貼合云原生微服務架構。這體現在：

服務支持部署在容器、Kubernetes 平臺，服務生命周期可實現與平臺調度周期對齊；
支持經典 Service Mesh 微服務架構，引入了 Proxyless Mesh 架構，進一步簡化 Mesh 的落地與遷移成本，提供更靈活的選擇；
作為橋接層，支持與 SpringCloud、gRPC 等異構微服務體系的互調互通。
在云原生大背景下，Apache Dubbo 3.0 選擇全面擁抱云原生，對 Dubbo 架構升級，提出了全新的服務發現模型、下一代 RPC 協議和云原生基礎設施適配等。

Dubbo3.0 商業版

下面我先介紹阿里云上微服務治理相關的三款云產品：EDAS、MSE、SAE。

EDAS

阿里云 aPaaS 產品，一站式部署發布平臺，同時它是一艘航母，具備微服務治理、監控、壓測、限流降級等一系列能力，同時它也是一個 AIOps 平臺。

EDAS 3.0 作為分布式架構、數字化轉型上云的首選在線業務應用托管平臺，在微服務治理、應用發布變更以及智能運維等多個維度為用戶應用提供智能化、自動化的解決方案。

"在 PaaS 層面，我們始終擁抱開源技術，并保持和社區版本兼容的時效性；在企業特性上，例如服務治理、應用監控等方面，我們提供一個穩定成熟的產品，來降低企業構建互聯網化應用的門檻，例如企業級應用服務 EDAS 3.0 就是這樣一個典型的產品"。

——阿里巴巴合伙人、阿里云智能基礎產品事業部 高級研究員 蔣江偉

MSE

微服務引擎（Micro Service Engine，簡稱 MSE）是一個面向業界主流開源微服務生態的一站式微服務平臺， 幫助微服務用戶更穩定、更便捷、更低成本的使用開源微服務技術構建微服務體系。提供注冊中心、配置中心全托管（兼容 Nacos/ZooKeeper/Eureka）、網關（兼容 Zuul/Kong/Spring Cloud Gateway）和無侵入的開源增強服務治理能力。

SAE

Serverless 應用引擎（簡稱 SAE）是首款面向應用的 Serverless PaaS，提供成本更優、效率更高的一站式應用托管方案。支持 Spring Cloud/Dubbo/HSF 應用零改造上云，提供監控診斷、自動構建鏡像、Java 全鏈路加速、多發布策略、秒級自動彈性等能力，支持 Jenkins/云效/插件等部署應用，還能通過 Docker 鏡像部署任何語言的應用。

以上三款云產品所有的服務治理能力開箱即用，支持近五年來市面上所有開源 Dubbo、Spring Cloud 框架，包括 Dubbo 3.0；以下的所有能力無需修改一行代碼與配置，您只需將您的 Dubbo 3.0 的應用接入 EDAS/MSE/SAE ，都是開箱即用的能力。

1、完整的服務契約詳情

在治理的過程中，服務契約是所有功能的原材料。在進行測試驗證其可用性的時候，需要知道服務提供的方法，并根據方法參數自動填充模板，進而進行測試；在配置流量規則時候，需要能知道方法的參數，從而根據流量特征來進行流量規則配置；在進行服務降級、服務鑒權等配置的時候，需要根據方法的具體名稱和參數類型，來給不同的方法在不同的參數或者返回值的時候進行不同的降級/鑒權策略。

開源的 Swagger 已經做得比較不錯了，但是 MSE 的服務契約更加簡單高效。開源的 Swagger 只需要引入依賴，并在編碼的時候配置好 @API 注解，然后啟動一個 Swagger 的 Server 端就能看到詳情，美中不足的是沒有適配 Dubbo。

考慮到要讓用戶不修改任何代碼配置就能使用，且老舊版本的應用代碼和鏡像也得支持。因為如果需要開發的話，會因為侵入性比較大會影響迭代效率，我們還是選擇了 Agent 方案，這樣可以做到無需修改任何代碼和配置，只需要將應用接入 One Agent，就可以在 MSE 控制臺看到微服務的詳情。

當然，如果應用本身已經接入了 Swagger，我們也能夠做到很好的兼容支持。最后我們可以簡單地看一下服務契約的效果，已經同時支持了 Spring Cloud 和 Dubbo 應用。

可以詳細的查看應用注冊了哪些服務，以及這些服務的消費者有哪些；
可以詳細地查看應用提供的所有微服務方法；
可以詳細地查看應用提供的所有方法的返回值、參數的詳情；
服務測試、服務降級、服務鑒權這些功能，能夠直接獲取服務契約的數據以便后續的治理規則配置。

2、全鏈路流量控制

在微服務場景下，想讓流量精確命中到整個鏈路上的某一個應用的灰度版本，想要控制流量在整條鏈路上完整且精確地按照預期流轉，目前開源并沒有提供這樣的能力。但是我們常會碰到以下的場景，導致我們不得不去面對全鏈路流量控制的這個訴求。

如何做到項目/測試環境隔離？

我們首先通過新建項目環境，給每個項目環境都有唯一的一個項目標簽。當流量帶上這個項目標簽后會路由到該項目環境，否則會去主干環境。項目環境隔離帶來的好處是每個開發人員都可以有自己的項目環境，防止開發者們開發過程中的互相影響。

如何實現全鏈路灰度？

我們首先劃分出灰度的機器，然后對線上所有應用部署灰度版本，灰度流量全部進入灰度版本，正常流量進入生產版本。灰度版本只針對灰度流量驗證，有效減少風險。當我們要灰度發布 N 個應用，需要做到灰度流量在這 N 個應用的灰度版本之間路由。

下面這張圖很好地說明使用流量控制讓我們的開發同學在開發環境 1 和開發環境 2 各自部署各自的應用，可以實現環境隔離與全鏈路灰度的能力。

但是如果沒有全鏈路流量控制的這套機制，各種開發/灰度/生產環境都要進行邏輯或者物理隔離，這就需要部署N套整套的微服務架構，成本非常高。

可以看到上圖的基于全鏈路流量控制的方案才是更加合理的部署方案設計，我們提供了開箱即用全鏈路流量控制的能力，下面以電商架構中的下單場景為例介紹全鏈路流控功能。

客戶下單后流量從入口應用（或者微服務網關）進來，調用交易中心，交易中心再調用商品中心，商品中心調用下游的庫存中心。交易中心和商品中心各有兩個新版本（1和2）在運行，需要對這兩個新版本進行灰度驗證。此時在入口應用（或者微服務網關）上期望將滿足特定流控規則的請求流量路由到新版本，其余流量全部路由到線上（正式）版本。

我們只需在 EDAS 控制臺創建如下全鏈路流量控制規則：

同時我們還提供了流量控制的監控大盤，可以實時查看各個應用的 qps 指標，來確認流量走向是否符合預期。

3、標簽路由

EDAS/MSE 服務治理提供了標簽路由的流量控制能力。每個 pod/ecs 都可以打上標簽，標簽被識別后會在控制臺上展示，然后我們可以對標簽設置比例和內容規則。

可以設置各個標簽的流量比例：

也可以點擊流量規則設置各個標簽的內容流量規則：

如果有全鏈路訴求。上述 "是否透傳" 開關可以用來透傳標簽。

4、開箱即用的服務測試

服務測試即為用戶提供一個云上私網 Postman ，讓用戶能夠輕松調用自己的服務。用戶無需感知云上復雜的網絡拓撲結構，無需關系服務的協議，無需自建測試工具，只需要通過控制臺即可實現服務調用。支持 Dubbo 3.0 框架，以及 Dubbo 3.0 主流的 Triple 協議。

5、離群實例摘除

在微服務架構中，當服務提供者的應用實例出現異常時，服務消費者無法及時感知，會影響服務的正常調用，進而影響消費者的服務性能甚至可用性。

在上圖的示例場景中，系統包含 4 個應用，A、B、C 和 D，其中應用 A 會分別調用應用 B、C 和 D。當應用 B、C 或 D 的某些實例異常時（如圖中應用 B、C 和 D 標識的各有 1個和 2 個異常實例），如果應用 A 無法感知，會導致部分調用失敗；如果業務代碼寫的不夠優雅，有可能影響應用 A 的性能甚至整個系統的可用性。

在這里，主要介紹一下離群實例摘除。那什么是離群實例，在微服務集群中出現間歇性的單機抖動（ load 極高、 CPU 短時無法響應、線程池滿等），由于這些個別節點的抖動會導致整體集群的服務質量下降。這種情況在云上時常出現，特別是對于一些大客戶來說，這種能力極為重要。為了提高業務的穩定性，我們需要一種自動化的方案當出現離群實例時，可以自動將其摘除，同時當其恢復健康后，又需要將其放回集群繼續提供服務。

一句話總結：提供了業務單點異常自愈能力。

我們只需要選擇框架類型與應用，然后配置允許的錯誤率下限即可。

6、服務鑒權

相比于開源的 Dubbo 3.0，MSE 提供了開箱即用的服務鑒權能力，保護你的敏感業務，可以做到精準地控制服務調用的權限。

當我們的業務發展后，我們的服務還會遇到權限控制的需求：比如優惠券部門的某個應用，同時包含了優惠券查詢接口和優惠券發放接口，對于優惠券查詢接口來說，默認公司內部的所有應用都有權限調用的；但優惠券發放接口只有客服和運營部門的某些應用才有權限調用。

如下圖所示，MSE 用戶可以對自己的服務進行權限管理，這里以 Dubbo 為例，下圖中配置表明，應用 cartservice 發布的 com.alibabacloud.hipstershop.CartService 服務的 addItemToCart 的方法，只允許 frontend 這個應用調用。

精準的權限管理，可以讓你更好地管理微服務調用的權限，保證業務的合規性，保障數據的安全。

7、服務 Mock

相比于開源 Dubbo 3.0 服務 Mock 能力，MSE 提供的是開箱即用的完整解決方案。

當您遇到業務高峰期，發現下游的服務提供者遇到性能瓶頸，甚至影響業務時。您可以通過服務 Mock 實現服務降級，對部分的服務消費者進行降級操作，讓不重要的業務方不進行真實地調用，直接返回 Mock 的結果，將寶貴的下游服務提供者資源保留給重要的業務調用方使用，從而提升整體服務的穩定性。

開源已有的 Sentinel、Hystrix 等開源的熔斷降級，主要是對不穩定的弱依賴服務調用進行熔斷降級，暫時切斷不穩定調用，避免局部不穩定因素導致整體的雪崩。熔斷降級作為保護自身的手段，通常在服務消費端進行配置。

服務降級功能既支持在服務調用報錯時候進行降級，同時也支持在服務調用正常時也開啟，這樣可以很好地保護服務提供者，將有限的資源更多地分配給關鍵的服務消費者。

在開發的過程中，相信我們大家都到過，下游依賴方開發進度比較慢，導致自己的開發進度被 block 的情況，在使用 微服務治理 Mock 功能之后，可以通過固定地 Mock 某個返回值，從而使得開發的過程不需要依賴于下游依賴方的進度，同時還可以靈活地在控制臺變更 Mock 的規則，從而達到快速開發的目的。

如下圖所示，當應用接入 MSE 之后，就可以在控制臺中通過如下方式來提供服務 Mock 的功能。

8、服務監控

對于Dubbo應用線上監控以及診斷能力是必不可少的能力，我們提供了以下完整且開箱即用的應用監控能力，可以讓應用的運維變得輕松高效。

應用詳情

應用依賴服務以及應用實例/狀態碼統計

應用的系統信息與慢調用次數監控

應用數據的統計分析

應用的調用拓撲分析

小結

EDAS/MSE/SAE 服務治理中心是商業化版的 Dubbo Admin，但不止于此，我們通過無侵入方式增強市面上 Dubbo/Spring Cloud 等框架的全部版本，提供了一站式完整的微服務治理能力的解決方案。

不只是 Dubbo3.0

同時，EDAS/MSE/SAE 服務治理也將 Dubbo 3.0 一些優秀的設計以及能力通過無侵入服務治理能力普惠到 Dubbo 2.x 以及 Spring Cloud 框架。

1、微服務與K8s生命周期對齊

Pod 的生命周期與服務調度息息相關。

如果微服務沒有實現其接口，當部署架構 K8s 化，在應用的 縮容、擴容、重啟、新版本發布 這些過程中，會出現影響業務的錯誤，所以要配置好微服務在 K8s 環境下的健康檢查。

其實僅僅是做健康檢查其實不夠：因為出現上述場景的原因可能有很多：

1、應用的下線過程中：應用提供者正常收到 kill 信號，提供者處理完在途請求再停止，注冊中心感知提供者下線，消費者收到下線通知，消費者刷新調用列表 等等這些過程中，都可能出現錯誤和延遲。

2、應用上線過程中也可能出問題：服務還未注冊訂閱完成Pod的健康檢查已經就緒，Dubbo 還沒準備好大流量就進來了，數據庫/Redis 建立連接導致初次請求失敗，JVM 類加載出現鎖導致啟動緩慢，健康檢查寫的有問題導致滾動發布過程中沒有一個健康的節點等等。

上述的階段，都有可能出現問題，這些問題都是需要解決和保證的。這個可以通過開源的方式一個個去解決，比如調整注冊中心的配置，調整連接池的配置，調整鏡像打包文件，自己寫代碼實現在途請求處理完的邏輯等等。也可以選擇使用 MSE 方案，不需要修改代碼，只需要接入 MSE 即可， 只需要接入一次，接入過程在 5 分鐘之內。

Readiness 檢查

MSE 會提供一個 Readiness 接口，該接口會在微服務啟動完全就緒后，返回的 status 會成為 200，否則返回 503。

Liveness 檢查

MSE 會提供一個 Liveness 接口，該接口在判斷微服務就緒后且服務狀態為健康，返回的 status 會成為 200，否則返回 503 。

我們只需將相關配置配置在K8s提供的接口上即可。

2、無損上下線

若您的應用沒有具備無損下線的能力，您的任何應用在發布的過程中會造成短暫的服務不可用，短時間內業務監控會出現大量 io 異常報錯。如果您的業務沒做好事務，那么還會引起數據不一致的問題，您需要緊急手動訂正錯誤數據。每次發布，您需要發告示停機發布，否則您的用戶會出現一段時間服務不可用，會對用戶產品體驗造成影響。

對于任何一個線上應用，如何在服務更新部署過程中保證業務無感知是開發者必須要解決的問題，即從應用停止到重啟恢復服務這個階段不能影響正常的業務請求，目前開源的框架均不能很好地解決這個問題。

當您的應用接入MSE/EDAS/SAE 后，將通過無侵入的方式自動增強 Dubbo 和 Spring Cloud 流量的無損下線能力。微服務治理中心將無損下線的能力整合在 K8S 的生命周期中，對 ACK 集群中的應用進行部署、回滾、縮容等操作時，會自動實現無損下線的效果。

3、服務并行注冊訂閱

Dubbo 默認服務注冊/訂閱行為是串行執行，當您的 Dubbo 應用中服務數過多，該流程會變得很長，影響應用啟動時長，存在一定的穩定性風險；為了應用可以更快的啟動，MSE 會通過無侵入的方式增強你的微服務框架，只需加一個開關，就能開啟服務并行注冊與訂閱，大大減少應用啟動時長。

總結

Apache Dubbo 3.0.0 是捐給 Apache 后的一個里程碑版本，代表著 Apache Dubbo 全面擁抱云原生的一個節點。

EDAS/MSE/SAE 服務治理能力也在隨著云原生微服務的發展以及 Dubbo 的演進而不斷豐富，隨著客戶大規模上云后，一些云原生場景下微服務的痛點也不斷浮出水面，我們致力于無侵入的微服務治理增強，在解決客戶痛點的過程中保證云上客戶的業務永遠在線，使得云原生微服務的架構升級更加 easy 。