一、背景
自從 Apache Dubbo 在 2011 年開源以來，在一衆大規模網際網路、IT公司的實踐中積累了大量經驗後，Dubbo 憑借對 Java 使用者友好、功能豐富、治理能力強等優點在過去取得了很大的成功，成為國内外熱門主流的 RPC 架構之一。
但随着雲原生時代的到來，以 Apache Dubbo、Spring Cloud 等為代表的 Java 微服務治理體系面臨了許多新的需求，包括期望應用可以更快的啟動、應用通信的協定穿透性可以更高、能夠對多語言的支援更加友好等。例如Spring 也在今年推出了其基于 GraalVM 的 Spring Native Beta 解決方案，擁有毫秒級啟動的能力、更高的處理性能等優化提升。
這樣的背景對下一代 Apache Dubbo 提出了兩大要求：一是要保留已有的開箱即用和落地實踐背景下積累的優點，這也是衆多開發者所期望的；二是盡可能地遵循雲原生思想，能更好的複用底層雲原生基礎設施并且更貼合雲原生的微服務架構。
二、擁抱雲原生
在如今的大背景下，Apache Dubbo 3 選擇全面擁抱雲原生，将 Dubbo 的架構更新，提出了全新的服務發現模型、下一代 RPC 協定和雲原生基礎設施适配等優化方案。
1、全新服務發現模型（應用級服務發現）
應用級注冊模型
以 Dubbo 原有的設計，存儲在注冊中心中的資料會在很大程度上存在重複的内容，這其實浪費了一部分的存儲。而當整個叢集的規模足夠大的時候，由于服務注冊發現是服務次元的，注冊中心的資料量就會爆發式地增長。
目前同樣是微服務治理工具的 Spring Cloud 和 gRPC 都是基于應用級的服務發現，如果仍使用接口級别的注冊方式，Dubbo 就很難和他們進行互通。但假如 Dubbo 也可以像 Spring Cloud 一樣以服務級注冊，那麼在異構體系下将可以很輕松地工作起來。
異構下部署方案
應用級服務發現機制是 Apache Dubbo 面向雲原生走出的重要一步，它幫 Apache Dubbo 打通了與其他微服務體系之間在位址發現層面的鴻溝，也成為 Apache Dubbo 适配 Kubernetes Native Service 等基礎設施的基礎。
基于應用級服務發現，注冊中心的資料将被重新組織，注冊中心的壓力大大減輕。同時，由于位址量減少了，應用自身的記憶體消耗也可以大幅降低。
性能提升
在一般情況下，應用中存儲的位址量可以降低約一半，針對上遊應用大規模部署的場景（比如部署了 1000 個節點、提供了 50 個服務）甚至可以達到 95% 以上，這對于核心應用的記憶體壓力環境帶來的優化是巨大的。
2、下一代 RPC 協定 —— Triple
在雲原生時代，Dubbo RPC 協定主要面臨兩個挑戰：
1、生态不互通，Dubbo 協定基于二進制流定制了與 RPC 強綁定的核心語義，包括協定頭、标志位、請求 ID 以及請求/響應資料等。而對于越來越多的雲原生治理設施，要讓他們都 “讀” 懂 Dubbo 的二進制 “語義” 并不容易。
2、由于協定設計的問題，Dubbo 協定的協定頭已無法再承載更多的中繼資料資訊。而對于 Mesh 等網關型元件，如果想要對資料進行治理就需要對完整的資料包進行解析才能擷取到必要的中繼資料資訊（如 RPC 上下文），從性能到易用性方面都會面臨挑戰。
Dubbo 協定通信方式
在支援已有的功能和解決存在的問題的前提下，Apache Dubbo 3 提出了下一代 RPC 協定——Triple。
基于 Tripe 協定，我們期望可以解決這些問題：
1、跨語言互通的問題。傳統的多語言多 SDK 模式和 Mesh 化跨語言模式都需要一種更通用易擴充的資料傳輸格式；
2、提供更完善的請求模型。除了 Request/Response 模型，還應該支援 Streaming 和 Bidirectional；
請求模型示意圖
3、易擴充、穿透性高。包括但不限于 Tracing / Monitoring 等支援，也應該能被各層裝置識别，網關設施等可以識别資料封包，對 Service Mesh 部署友好，降低使用者了解難度；
4、支援 Java 使用者無感覺更新。不需要定義繁瑣的 IDL 檔案，僅需要簡單的修改協定名便可以輕松更新到 Triple 協定。
基于這些期望，我們覺得 HTTP/2 作為底層通信協定，使用 protobuf 作為序列化協定的組合是最合理的，這套組合方案也是 gRPC 協定使用的方案。是以對于 Triple 協定來說，我們可以基于 gRPC 協定進行演變，以滿足 Apache Dubbo 已有的優秀特性，這同時也保證了在生态系統上新協定和 gRPC 是能夠互通和共享的。
Triple 協定通信方式
3、雲原生設施接入
針對于 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 混合部署甚至是使用者直接手動部署叢集均可以被同一套規則所控制，實作定義一次，到處使用的目标。
三、未來展望
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 将大規模落地阿裡集團，承載 618、雙十一等複雜業務場景。
社群衷心地希望歡迎大家向社群送出 issue 和 PR，社群的同學會盡快進行 review 和回複。另外，社群會盡可能保證一個較短的發版周期，及時對已有的問題進行修複。
同時在 Apache Dubbo 3 開始，社群也會采用更開放的态度對待生産環境下的定制需求，我們歡迎大家将自己的定制化實作貢獻給開源社群，dubbo-spi-extensions 倉庫未來會對這些定制化進行支援。