在 Dubbo3.0 上服務治理的實踐

做者 | 十眠

Dubbo3.0 介紹

​

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

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

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

一、要保留已有開箱即用和落地實踐背景下帶來的好處，這也是衆多開發者所指望的；
二、儘量地遵循雲原生思想，能更好的複用底層雲原生基礎設施、貼合雲原生微服務架構。
​

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 就是這樣一個典型的產品」。
​

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

瞭解更多詳情：
https://www.aliyun.com/product/edas
​

• MSE

​

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

瞭解更多詳情：
https://www.aliyun.com/product/aliware/mse
​

• SAE

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

瞭解更多詳情：
https://www.aliyun.com/product/sae
​

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

一、完整的服務契約詳情

​

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

開源的 Swagger 已經作得比較不錯了，可是 MSE 的服務契約更加簡單高效。開源的 Swagger 只須要引入依賴，並在編碼的時候配置好 @API 註解，而後啓動一個 Swagger 的 Server 端就能看到詳情，美中不足的是沒有適配 Dubbo。
​

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

​

固然，若是應用自己已經接入了 Swagger，咱們也可以作到很好的兼容支持。最後咱們能夠簡單地看一下服務契約的效果，已經同時支持了 Spring Cloud 和 Dubbo 應用。
​

• 能夠詳細的查看應用註冊了哪些服務，以及這些服務的消費者有哪些；

​

• 能夠詳細地查看應用提供的全部微服務方法；

​

• 能夠詳細地查看應用提供的全部方法的返回值、參數的詳情；

​

• 服務測試、服務降級、服務鑑權這些功能，可以直接獲取服務契約的數據以便後續的治理規則配置。

​

二、全鏈路流量控制

 

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

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

 

咱們首先經過新建項目環境，給每一個項目環境都有惟一的一個項目標籤。當流量帶上這個項目標籤後會路由到該項目環境，不然會去主幹環境。項目環境隔離帶來的好處是每一個開發人員均可以有本身的項目環境，防止開發者們開發過程當中的互相影響。
​
 

如何實現全鏈路灰度？

​

咱們首先劃分出灰度的機器，而後對線上全部應用部署灰度版本，灰度流量所有進入灰度版本，正常流量進入生產版本。灰度版本只針對灰度流量驗證，有效減小風險。當咱們要灰度發佈 N 個應用，須要作到灰度流量在這 N 個應用的灰度版本之間路由。
​

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

​

**可是若是沒有全鏈路流量控制的這套機制，各類開發/灰度/生產環境都要進行邏輯或者物理隔離，這就須要部署N套整套的微服務架構，成本很是高。**​
​

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

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

咱們只需在 EDAS 控制檯建立以下全鏈路流量控制規則：
​

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

三、標籤路由

 

EDAS/MSE 服務治理提供了標籤路由的流量控制能力。每一個 pod/ecs 均可以打上標籤，標籤被識別後會在控制檯上展現，而後咱們能夠對標籤設置比例和內容規則。
​

能夠設置各個標籤的流量比例：

​

也能夠點擊流量規則設置各個標籤的內容流量規則：
​

若是有全鏈路訴求。上述 「是否透傳」 開關能夠用來透傳標籤。
​
 

四、開箱即用的服務測試

​

服務測試即爲用戶提供一個雲上私網 Postman ，讓用戶可以輕鬆調用本身的服務。用戶無需感知雲上覆雜的網絡拓撲結構，無需關係服務的協議，無需自建測試工具，只須要經過控制檯便可實現服務調用。支持 Dubbo 3.0 框架，以及 Dubbo 3.0 主流的 Triple 協議。

​

五、離羣實例摘除

​

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

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

在這裏，主要介紹一下離羣實例摘除。那什麼是離羣實例，在微服務集羣中出現間歇性的單機抖動（ load 極高、 CPU 短時沒法響應、線程池滿等），因爲這些個別節點的抖動會致使總體集羣的服務質量降低。這種狀況在雲上時常出現，特別是對於一些大客戶來講，這種能力極爲重要。爲了提升業務的穩定性，咱們須要一種自動化的方案當出現離羣實例時，能夠自動將其摘除，同時當其恢復健康後，又須要將其放回集羣繼續提供服務。
​

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

咱們只須要選擇框架類型與應用，而後配置容許的錯誤率下限便可。

六、服務鑑權

 

相比於開源的 Dubbo 3.0，MSE 提供了開箱即用的服務鑑權能力，保護你的敏感業務，能夠作到精準地控制服務調用的權限。

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

以下圖所示，MSE 用戶能夠對本身的服務進行權限管理，這裏以 Dubbo 爲例，下圖中配置代表，應用 cartservice 發佈的 com.alibabacloud.hipstershop.CartService 服務的 addItemToCart 的方法，只容許 frontend 這個應用調用。
​

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

七、服務 Mock

​

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

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

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

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

在開發的過程當中，相信咱們你們都到過，下游依賴方開發進度比較慢，致使本身的開發進度被 block 的狀況，在使用 微服務治理 Mock 功能以後，能夠經過固定地 Mock 某個返回值，從而使得開發的過程不須要依賴於下游依賴方的進度，同時還能夠靈活地在控制檯變動 Mock 的規則，從而達到快速開發的目的。
​

以下圖所示，當應用接入 MSE 以後，就能夠在控制檯中經過以下方式來提供服務 Mock 的功能。
​

八、服務監控

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

• 應用詳情
  ​

​

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

​

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

​

• 應用數據的統計分析
  ​

• 應用的調用拓撲分析

​

九、小結

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

不僅是 Dubbo3.0

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

一、微服務與K8s生命週期對齊

​

Pod 的生命週期與服務調度息息相關。
（https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/）
​

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

其實僅僅是作健康檢查其實不夠：由於出現上述場景的緣由可能有不少：
​

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

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

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

Readiness 檢查

​

MSE 會提供一個 Readiness 接口，該接口會在微服務啓動徹底就緒後，返回的 status 會成爲 200，不然返回 503。

Liveness 檢查

​

MSE 會提供一個 Liveness 接口，該接口在判斷微服務就緒後且服務狀態爲健康，返回的 status 會成爲 200，不然返回 503 。
咱們只需將相關配置配置在K8s提供的接口上便可。
​
 

二、無損上下線

​

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

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

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

三、服務並行註冊訂閱

​

Dubbo 默認服務註冊/訂閱行爲是串行執行，當您的 Dubbo 應用中服務數過多，該流程會變得很長，影響應用啓動時長，存在必定的穩定性風險；爲了應用能夠更快的啓動，MSE 會經過無侵入的方式加強你的微服務框架，只需加一個開關，就能開啓服務並行註冊與訂閱，大大減小應用啓動時長。
​
 

總結

​

Apache Dubbo 3.0.0 是捐給 Apache 後的一個里程碑版本，表明着 Apache Dubbo 全面擁抱雲原生的一個節點。
​

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

​

﹀
﹀
﹀
​

8月5日下午 15:00-16:00
​

來直播間圍觀 《Dubbo 3.0 服務治理最佳實踐》如何快速具有完整的服務治理能力

想探討更多相關內容，歡迎釘釘搜索羣號：34754806 ​