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 就是這樣一個典型的産品"。
——阿裡巴巴合夥人、阿裡雲智能基礎産品事業部 進階研究員 蔣江偉
了解更多詳情：
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 ，都是開箱即用的能力。
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 的生命周期與服務排程息息相關。
（
https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/）
如果微服務沒有實作其接口，當部署架構 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 。
﹀
8月5日下午 15:00-16:00
來直播間圍觀《Dubbo 3.0 服務治理最佳實踐》如何快速具備完整的服務治理能力
想探讨更多相關内容，歡迎釘釘掃碼或搜尋群号：34754806