Dubbo 3.0.0正式發(fā)布：應用級服務注冊，跨語言的RPC協(xié)議、更好支持Kubernetes！
背景
ALIWARE
自從 Apache Dubbo 在 2011 年開源以來，在一眾大規(guī)模互聯(lián)網(wǎng)、IT公司的實踐中積累了大量經(jīng)驗后，Dubbo 憑借對 Java 用戶友好、功能豐富、治理能力強等優(yōu)點在過去取得了很大的成功，成為國內(nèi)外熱門主流的 RPC 框架之一。
但隨著云原生時代的到來，以 Apache Dubbo、Spring Cloud 等為代表的 Java 微服務治理體系面臨了許多新的需求，包括期望應用可以更快的啟動、應用通信的協(xié)議穿透性可以更高、能夠?qū)Χ嗾Z言的支持更加友好等。例如Spring 也在今年推出了其基于 GraalVM 的 Spring Native Beta 解決方案，擁有毫秒級啟動的能力、更高的處理性能等優(yōu)化提升。
這樣的背景對下一代 Apache Dubbo 提出了兩大要求：一是要保留已有的開箱即用和落地實踐背景下積累的優(yōu)點，這也是眾多開發(fā)者所期望的；二是盡可能地遵循云原生思想，能更好的復用底層云原生基礎設施并且更貼合云原生的微服務架構(gòu)。
擁抱云原生
ALIWARE
在如今的大背景下，Apache Dubbo 3 選擇全面擁抱云原生，將 Dubbo 的架構(gòu)升級，提出了全新的服務發(fā)現(xiàn)模型、下一代 RPC 協(xié)議和云原生基礎設施適配等優(yōu)化方案。
1、全新服務發(fā)現(xiàn)模型（應用級服務發(fā)現(xiàn)）
以 Dubbo 原有的設計，存儲在注冊中心中的數(shù)據(jù)會在很大程度上存在重復的內(nèi)容，這其實浪費了一部分的存儲。而當整個集群的規(guī)模足夠大的時候，由于服務注冊發(fā)現(xiàn)是服務維度的，注冊中心的數(shù)據(jù)量就會爆發(fā)式地增長。
當前同樣是微服務治理工具的 Spring Cloud 和 gRPC 都是基于應用級的服務發(fā)現(xiàn)，如果仍使用接口級別的注冊方式，Dubbo 就很難和他們進行互通。但假如 Dubbo 也可以像 Spring Cloud 一樣以服務級注冊，那么在異構(gòu)體系下將可以很輕松地工作起來。
應用級服務發(fā)現(xiàn)機制是 Apache Dubbo 面向云原生走出的重要一步，它幫 Apache Dubbo 打通了與其他微服務體系之間在地址發(fā)現(xiàn)層面的鴻溝，也成為 Apache Dubbo 適配 Kubernetes Native Service 等基礎設施的基礎。
基于應用級服務發(fā)現(xiàn)，注冊中心的數(shù)據(jù)將被重新組織，注冊中心的壓力大大減輕。同時，由于地址量減少了，應用自身的內(nèi)存消耗也可以大幅降低。
在一般情況下，應用中存儲的地址量可以降低約一半，針對上游應用大規(guī)模部署的場景（比如部署了 1000 個節(jié)點、提供了 50 個服務）甚至可以達到 95% 以上，這對于核心應用的內(nèi)存壓力環(huán)境帶來的優(yōu)化是巨大的。
2、下一代 RPC 協(xié)議 —— Triple
在云原生時代，Dubbo RPC 協(xié)議主要面臨兩個挑戰(zhàn)：
1、生態(tài)不互通，Dubbo 協(xié)議基于二進制流定制了與 RPC 強綁定的核心語義，包括協(xié)議頭、標志位、請求 ID 以及請求/響應數(shù)據(jù)等。而對于越來越多的云原生治理設施，要讓他們都 “讀” 懂 Dubbo 的二進制 “語義” 并不容易。
2、由于協(xié)議設計的問題，Dubbo 協(xié)議的協(xié)議頭已無法再承載更多的元數(shù)據(jù)信息。而對于 Mesh 等網(wǎng)關型組件，如果想要對數(shù)據(jù)進行治理就需要對完整的數(shù)據(jù)包進行解析才能獲取到必要的元數(shù)據(jù)信息（如 RPC 上下文），從性能到易用性方面都會面臨挑戰(zhàn)。
在支持已有的功能和解決存在的問題的前提下，Apache Dubbo 3 提出了下一代 RPC 協(xié)議——Triple。
基于 Tripe 協(xié)議，我們期望可以解決這些問題：
1、跨語言互通的問題。傳統(tǒng)的多語言多 SDK 模式和 Mesh 化跨語言模式都需要一種更通用易擴展的數(shù)據(jù)傳輸格式；
2、提供更完善的請求模型。除了 Request/Response 模型，還應該支持 Streaming 和 Bidirectional；
3、易擴展、穿透性高。包括但不限于 Tracing / Monitoring 等支持，也應該能被各層設備識別，網(wǎng)關設施等可以識別數(shù)據(jù)報文，對 Service Mesh 部署友好，降低用戶理解難度；
4、支持 Java 用戶無感知升級。不需要定義繁瑣的 IDL 文件，僅需要簡單的修改協(xié)議名便可以輕松升級到 Triple 協(xié)議。
基于這些期望，我們覺得 HTTP/2 作為底層通信協(xié)議，使用 protobuf 作為序列化協(xié)議的組合是最合理的，這套組合方案也是 gRPC 協(xié)議使用的方案。所以對于 Triple 協(xié)議來說，我們可以基于 gRPC 協(xié)議進行演變，以滿足 Apache Dubbo 已有的優(yōu)秀特性，這同時也保證了在生態(tài)系統(tǒng)上新協(xié)議和 gRPC 是能夠互通和共享的。
3、云原生設施接入
針對于 Kubernetes 的場景， Apache Dubbo 3 為此做了兩方面的接入：
一是原生支持與 Kubernetes Pod 生命周期對齊，基于 Dubbo QoS 機制，Kubernetes 能夠感知到運行在 Pod 容器中的 Dubbo 應用當前是什么狀態(tài)，而且得益于 Dubbo SPI 機制用戶可以自定義探針檢測的維度，實現(xiàn)框架和業(yè)務的生命周期都達到統(tǒng)一。
第二是 Dubbo 也將支持接入 Kubernetes Native Service 體系，原生支持基于 Kubernetes API Server 和 DNS 的服務發(fā)現(xiàn)體系，實現(xiàn)部署架構(gòu)下的服務概念與 Dubbo 中的服務概念進行對齊。
而對于 Service Mesh 體系，如果應用使用 Apache Dubbo 2 想要部署以 Mesh 方式部署，需要使用 Sidecar 對 Dubbo 流量進行攔截，而同時由于 Dubbo 本身是具有一定的治理能力的，從應用來說會多做了很多無用的事情，從集群的角度來說會造成調(diào)用的紊亂。
基于此，Apache Dubbo 3 提出了兩種部署模式，一種是配合 Sidecar 部署的 Thin SDK 模式、另一種是直接接入控制面的 Proxyless Mesh 模式。
除了部署架構(gòu)的接入，在 Apache Dubbo 3 中還定義了一套面向云原生流量治理，支持傳統(tǒng) SDK、Mesh 場景的統(tǒng)一治理規(guī)則。
Apache Dubbo 3 期望使用這一套規(guī)則，便可以實現(xiàn)如金絲雀發(fā)布、A/B測試等豐富的路由語義，只需要配置一套規(guī)則，寫入統(tǒng)一的控制面，就可以統(tǒng)一地控制所有集群。這樣無論使用 Kubernetes 直接部署、亦或者是 Mesh 場景下使用 Thin SDK 或 Proxyless 混合部署甚至是用戶直接手動部署集群均可以被同一套規(guī)則所控制，實現(xiàn)定義一次，到處使用的目標。
未來展望
ALIWARE
Apache Dubbo 3.0.0 是捐給 Apache 后的一個里程碑版本，代表著 Apache Dubbo 全面擁抱云原生的一個重要節(jié)點。
在 2021 年 11 月我們會發(fā)布 Apache Dubbo 3.1 版本，屆時我們會帶來 Apache Dubbo 在 Mesh 場景下部署的實現(xiàn)與實踐。
在 2022 年 3 月我們會發(fā)布 Apache Dubbo 3.2 版本，在這個版本中我們將帶來全新的大規(guī)模應用部署下智能流量調(diào)度機制，提高系統(tǒng)穩(wěn)定性與資源利用率。
Apache Dubbo 3 目前已經(jīng)和阿里巴巴集團內(nèi)部的 RPC 框架實現(xiàn)了融合，期望用它來解決內(nèi)部落地問題，做到技術棧統(tǒng)一。未來，Apache Dubbo 3 將大規(guī)模落地阿里集團，承載 618、雙十一等復雜業(yè)務場景。
社區(qū)衷心地希望歡迎大家向社區(qū)提交 issue 和 PR，社區(qū)的同學會盡快進行 review 和回復。另外，社區(qū)會盡可能保證一個較短的發(fā)版周期，及時對已有的問題進行修復。
同時在 Apache Dubbo 3 開始，社區(qū)也會采用更開放的態(tài)度對待生產(chǎn)環(huán)境下的定制需求，我們歡迎大家將自己的定制化實現(xiàn)貢獻給開源社區(qū)，dubbo-spi-extensions 倉庫未來會對這些定制化進行支持。
往期推薦
關注我回復「加群」，加入Spring技術交流群