Apache Dubbo 3.0.0 正式發佈 - 全面擁抱雲原生

簡介：一個新的里程碑！

1、背景

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

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

這樣的背景對下一代 Apache Dubbo 提出了兩大要求：一是要保留已有的開箱即用和落地實踐背景下積累的優勢，這也是衆多開發者所指望的；二是儘量地遵循雲原生思想，能更好的複用底層雲原生基礎設施而且更貼合雲原生的微服務架構。

2、擁抱雲原生

在現在的大背景下，Apache Dubbo 3 選擇全面擁抱雲原生，將 Dubbo 的架構升級，提出了全新的服務發現模型、下一代 RPC 協議和雲原生基礎設施適配等優化方案。

一、全新服務發現模型（應用級服務發現）

應用級註冊模型

以 Dubbo 原有的設計，存儲在註冊中心中的數據會在很大程度上存在重複的內容，這其實浪費了一部分的存儲。而當整個集羣的規模足夠大的時候，因爲服務註冊發現是服務維度的，註冊中心的數據量就會爆發式地增加。

當前一樣是微服務治理工具的 Spring Cloud 和 gRPC 都是基於應用級的服務發現，若是仍使用接口級別的註冊方式，Dubbo 就很難和他們進行互通。但假如 Dubbo 也能夠像 Spring Cloud 同樣以服務級註冊，那麼在異構體系下將能夠很輕鬆地工做起來。

異構下部署方案

應用級服務發現機制是 Apache Dubbo 面向雲原生走出的重要一步，它幫 Apache Dubbo 打通了與其餘微服務體系之間在地址發現層面的鴻溝，也成爲 Apache Dubbo 適配 Kubernetes Native Service 等基礎設施的基礎。

基於應用級服務發現，註冊中心的數據將被從新組織，註冊中心的壓力大大減輕。同時，因爲地址量減小了，應用自身的內存消耗也能夠大幅下降。

性能提高

在通常狀況下，應用中存儲的地址量能夠下降約一半，針對上游應用大規模部署的場景（好比部署了 1000 個節點、提供了 50 個服務）甚至能夠達到 95% 以上，這對於核心應用的內存壓力環境帶來的優化是巨大的。

二、下一代 RPC 協議 —— Triple

在雲原生時代，Dubbo RPC 協議主要面臨兩個挑戰：

一、生態不互通，Dubbo 協議基於二進制流定製了與 RPC 強綁定的核心語義，包括協議頭、標誌位、請求 ID 以及請求/響應數據等。而對於愈來愈多的雲原生治理設施，要讓他們都 「讀」 懂 Dubbo 的二進制 「語義」 並不容易。

二、因爲協議設計的問題，Dubbo 協議的協議頭已沒法再承載更多的元數據信息。而對於 Mesh 等網關型組件，若是想要對數據進行治理就須要對完整的數據包進行解析才能獲取到必要的元數據信息（如 RPC 上下文），從性能到易用性方面都會面臨挑戰。

Dubbo 協議通訊方式

在支持已有的功能和解決存在的問題的前提下，Apache Dubbo 3 提出了下一代 RPC 協議——Triple。

基於 Tripe 協議，咱們指望能夠解決這些問題：

一、跨語言互通的問題。傳統的多語言多 SDK 模式和 Mesh 化跨語言模式都須要一種更通用易擴展的數據傳輸格式；

二、提供更完善的請求模型。除了 Request/Response 模型，還應該支持 Streaming 和 Bidirectional；

請求模型示意圖

三、易擴展、穿透性高。包括但不限於 Tracing / Monitoring 等支持，也應該能被各層設備識別，網關設施等能夠識別數據報文，對 Service Mesh 部署友好，下降用戶理解難度；

四、支持 Java 用戶無感知升級。不須要定義繁瑣的 IDL 文件，僅須要簡單的修改協議名即可以輕鬆升級到 Triple 協議。

基於這些指望，咱們以爲 HTTP/2 做爲底層通訊協議，使用 protobuf 做爲序列化協議的組合是最合理的，這套組合方案也是 gRPC 協議使用的方案。因此對於 Triple 協議來講，咱們能夠基於 gRPC 協議進行演變，以知足 Apache Dubbo 已有的優秀特性，這同時也保證了在生態系統上新協議和 gRPC 是可以互通和共享的。

Triple 協議通訊方式

三、雲原生設施接入

針對於 Kubernetes 的場景， Apache Dubbo 3 爲此作了兩方面的接入：

一是原生支持與 Kubernetes Pod 生命週期對齊，基於 Dubbo QoS 機制，Kubernetes 可以感知到運行在 Pod 容器中的 Dubbo 應用當前是什麼狀態，並且得益於 Dubbo SPI 機制用戶能夠自定義探針檢測的維度，實現框架和業務的生命週期都達到統一。

第二是 Dubbo 也將支持接入 Kubernetes Native Service 體系，原生支持基於 Kubernetes API Server 和 DNS 的服務發現體系，實現部署架構下的服務概念與 Dubbo 中的服務概念進行對齊。

Kubernetes 架構下部署方案

而對於 Service Mesh 體系，若是應用使用 Apache Dubbo 2 想要部署以 Mesh 方式部署，須要使用 Sidecar 對 Dubbo 流量進行攔截，而同時因爲 Dubbo 自己是具備必定的治理能力的，從應用來講會多作了不少無用的事情，從集羣的角度來講會形成調用的紊亂。

基於此，Apache Dubbo 3 提出了兩種部署模式，一種是配合 Sidecar 部署的 Thin SDK 模式、另外一種是直接接入控制面的 Proxyless Mesh 模式。

Dubbo 3 在 Mesh 場景下部署架構

除了部署架構的接入，在 Apache Dubbo 3 中還定義了一套面向雲原生流量治理，支持傳統 SDK、Mesh 場景的統一治理規則。

Apache Dubbo 3 指望使用這一套規則，即可以實現如金絲雀發佈、A/B測試等豐富的路由語義，只須要配置一套規則，寫入統一的控制面，就能夠統一地控制全部集羣。這樣不管使用 Kubernetes 直接部署、亦或者是 Mesh 場景下使用 Thin SDK 或 Proxyless 混合部署甚至是用戶直接手動部署集羣都可以被同一套規則所控制，實現定義一次，處處使用的目標。

3、將來展望

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

在 2021 年 11 月咱們會發布 Apache Dubbo 3.1 版本，屆時咱們會帶來 Apache Dubbo 在 Mesh 場景下部署的實現與實踐。

在 2022 年 3 月咱們會發布 Apache Dubbo 3.2 版本，在這個版本中咱們將帶來全新的大規模應用部署下智能流量調度機制，提升系統穩定性與資源利用率。

Apache Dubbo 3 目前已經和阿里巴巴集團內部的 RPC 框架實現了融合，指望用它來解決內部落地問題，作到技術棧統一。將來，Apache Dubbo 3 將大規模落地阿里集團，承載 61八、雙十一等複雜業務場景。

社區衷心地但願歡迎你們向社區提交 issue 和 PR，社區的同窗會盡快進行 review 和回覆。另外，社區會盡量保證一個較短的發版週期，及時對已有的問題進行修復。

同時在 Apache Dubbo 3 開始，社區也會採用更開放的態度對待生產環境下的定製需求，咱們歡迎你們將本身的定製化實現貢獻給開源社區，dubbo-spi-extensions 倉庫將來會對這些定製化進行支持。

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。