作者 | 陸龜
來源 | 阿里巴巴云原生公眾號(hào)

本文整理自作者在3月20日云原生中間件 Meetup 上海站的分享。回復(fù)關(guān)鍵字“中間件”可以獲取視頻錄播地址和 PPT。

就在今天，Dubbo 社區(qū)剛剛發(fā)布了 3.0 的首個(gè)預(yù)覽版本 - 3.0.0.preview。

https://github.com/apache/dubbo/releases/tag/3.0.0.preview

本文將和讀者一起解讀 Dubbo3 的首個(gè) preview 版本：一方面，我們將深入分析 ?Dubbo3 云原生變革的核心理念；另一方面，我們將逐個(gè)解讀 preview 版本的核心功能。

做過微服務(wù)開發(fā)的開發(fā)者相信對(duì) Dubbo 都不陌生，Dubbo 是一款能幫助我們快速解決微服務(wù)開發(fā)、通信以及流量治理的框架。相比于之前只限定在 Java 語言范圍內(nèi)，Dubbo 的多語言版本在這兩年呈現(xiàn)了良好的發(fā)展勢(shì)頭，其中，Dubbo Go 語言版本在功能、穩(wěn)定性各個(gè)方面都已非常完備，其它幾種主流的多語言版本在社區(qū)也有提供。

云原生視角的微服務(wù)變革

Dubbo 主要解決微服務(wù)開發(fā)、運(yùn)行域問題，它和微服務(wù)的編程、通信、流量治理等密切關(guān)聯(lián)，因此，在探尋 Dubbo3 的云原生變革之前，我們先嘗試從云原生視角觀察云原生基礎(chǔ)設(shè)施帶給微服務(wù)架構(gòu)和實(shí)踐的變革，進(jìn)而總結(jié)出 Dubbo 這樣一個(gè)和微服務(wù)實(shí)踐密切相關(guān)的框架所面臨的變革與挑戰(zhàn)。

微服務(wù)在讓業(yè)務(wù)開發(fā)演進(jìn)更靈活、快捷的同時(shí)，也帶來了一些它獨(dú)有的特征和需求：如微服務(wù)之后組件數(shù)量越來越多，如何解決各個(gè)組件的穩(wěn)定性，如何快速的水平擴(kuò)容等。

這些訴求，尤其是運(yùn)維、交付相關(guān)訴求，如微服務(wù)組件的生命周期、網(wǎng)絡(luò)、通用服務(wù)綁定、服務(wù)狀態(tài)管理等，并不應(yīng)該是開發(fā)人員關(guān)注的重點(diǎn)，因?yàn)樗鼈円呀?jīng)完全脫離了業(yè)務(wù)邏輯，開發(fā)人員更愿意專注在有業(yè)務(wù)價(jià)值組件上，但這個(gè)層次的訴求卻是實(shí)現(xiàn)微服務(wù)交付的關(guān)鍵能力。開發(fā)者期望由底層基礎(chǔ)設(shè)施來提供此類能力支持，而處于不同階段發(fā)展的基礎(chǔ)設(shè)施卻不一定具備這樣的能力，因此，在微服務(wù)軟件架構(gòu)和底層基礎(chǔ)設(shè)施之間就出現(xiàn)了一條鴻溝，我們需要有組件能填補(bǔ)這一鴻溝，讓微服務(wù)組件能更好的接入底層基礎(chǔ)設(shè)施。

這里從一個(gè)更抽象的層面，嘗試用兩條發(fā)展曲線演示了軟件架構(gòu)訴求與底層基礎(chǔ)設(shè)施能力豐富度之間的關(guān)系。總體上，兩者之間的發(fā)展關(guān)系可拆分為兩個(gè)階段。

在第一個(gè)階段，軟件架構(gòu)（這條紅色的線）從單體應(yīng)用、到面向服務(wù)的軟件架構(gòu)、再到微服務(wù)架構(gòu)，快速演進(jìn)，從而也提出了上文我們講到的對(duì)基礎(chǔ)設(shè)施對(duì)交付的訴求，這個(gè)時(shí)候基礎(chǔ)設(shè)施層還多是以定制化的方式來滿足軟件架構(gòu)的訴求，如過往的集中化的 ESB、各個(gè)不同的 PaaS 平臺(tái)等。

第二個(gè)階段，是從容器、Kubernetes 為代表的基礎(chǔ)產(chǎn)品的出現(xiàn)開始，藍(lán)線與紅線之間的增長(zhǎng)速度被快速拉近，以云原生技術(shù)為代表的底層基礎(chǔ)設(shè)施豐富度得到了極大改善，它們不再只是被動(dòng)的滿足微服務(wù)開發(fā)的訴求，而是開始抽象更多的軟件訴求到底層的基礎(chǔ)設(shè)施，將它們下沉為基礎(chǔ)能力，并開始以統(tǒng)一的、標(biāo)準(zhǔn)化的形式向上輸出以滿足微服務(wù)對(duì)交付、運(yùn)維等的訴求，不僅如此，通過更深入的主動(dòng)創(chuàng)新、持續(xù)的向上釋放能力，底層基礎(chǔ)設(shè)施還開始反過來影響微服務(wù)的開發(fā)、接入方式，如 sidecar、dapr 等模型。

Dubbo3 的云原生變革

通過上文云對(duì)原生基礎(chǔ)設(shè)施演進(jìn)給傳統(tǒng)微服務(wù)帶來變革的分析，我們得出，以 Dubbo 為代表的微服務(wù)開發(fā)框架，應(yīng)重點(diǎn)在以下方向突破與變革。

• 更多的微服務(wù)組件及能力正下沉到以 Kubernetes 為代表的基礎(chǔ)設(shè)施層。傳統(tǒng)微服務(wù)開發(fā)框架應(yīng)剔除一些冗余機(jī)制，積極的適配到基礎(chǔ)設(shè)施層以做到能力復(fù)用；微服務(wù)框架生命周期、服務(wù)治理等能力應(yīng)更好地與 Kubernetes 服務(wù)編排機(jī)制融合。

• 以 Service Mesh 為代表微服務(wù)架構(gòu)給微服務(wù)開發(fā)帶來的新的選擇，但由于 Mesh 架構(gòu)本身的復(fù)雜性，其距離大規(guī)模生產(chǎn)落地還有一段距離。我們相信，基于 ServiceMesh 的體系會(huì)逐步從孵化器走向成熟期，會(huì)有越來越多的企業(yè)采用 Service Mesh技術(shù)，但在未來在很長(zhǎng)一段時(shí)間內(nèi)，基于服務(wù)框架的傳統(tǒng)微服務(wù)體系還將是主流，長(zhǎng)期仍將占據(jù)半壁江山。

我們不妨回想一下，在云原生基礎(chǔ)設(shè)施能力被充分釋放前，圍繞 Dubbo 構(gòu)建微服務(wù)時(shí)，它給微服務(wù)開發(fā)提供了哪些能力？或者我們期望它提供哪些能力？

Dubbo2 提供了包括服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、流量治理等相當(dāng)豐富的能力，當(dāng)然還包括微服務(wù)最需要的遠(yuǎn)程通信能力，這些能力很好地解決了微服務(wù)的訴求。

而在云原生架構(gòu)之下，我們需要重新審視，Dubbo2 的哪些能力是冗余的，是需要接入基礎(chǔ)設(shè)施的？哪些能力是已經(jīng)不適合云原生時(shí)代的，需要被重構(gòu)的？

首先，是接入云原生基礎(chǔ)設(shè)施后，一些能力出現(xiàn)了重復(fù)，像服務(wù)定義、服務(wù)注冊(cè)、甚至是服務(wù)治理能力在不同層面基礎(chǔ)設(shè)施中出現(xiàn)了重復(fù)，需要 Dubbo3 作出適配與調(diào)整，以更好的解放業(yè)務(wù)開發(fā)效率，利用好這些基礎(chǔ)能力。

其次，是 Dubbo 在微服務(wù)架構(gòu)中的最基本的能力：RPC 遠(yuǎn)程通信。通信協(xié)議和數(shù)據(jù)傳輸格式的標(biāo)準(zhǔn)化應(yīng)該算是 Dubbo2 面臨的又一重要挑戰(zhàn)，在云原生背影下，協(xié)議、數(shù)據(jù)定義、傳輸格式的標(biāo)準(zhǔn)化和穿透能力成為更需要優(yōu)先考慮的指標(biāo)，縱然私有協(xié)議具有更高效、靈活的潛力，但考慮到云原生下多語言、組件間互通、網(wǎng)關(guān)等代理設(shè)備友好性、避免廠商鎖定等訴求，在 Dubbo3 中私有協(xié)議都應(yīng)該被摒棄，轉(zhuǎn)而擁抱基于 HTTP/2 的更通用的協(xié)議，采用跨語言的更通用的數(shù)據(jù)定義和傳輸格式。

最后，是關(guān)于服務(wù)治理能力，Dubbo 的服務(wù)治理能力應(yīng)該充分結(jié)合底層基礎(chǔ)設(shè)施的特點(diǎn)，比如之前綁定 ip 的流量過濾方案在地址不固定的 Kubernetes 平臺(tái)就已不再適用，另外，流量治理也要充分的與調(diào)度平臺(tái)的灰度發(fā)布、動(dòng)態(tài)擴(kuò)縮容能力整合起來；考慮到未來微服務(wù)可能會(huì)有多種不同的部署形態(tài)（下文會(huì)講到），Dubbo3 應(yīng)該制定一種能適用于各種部署形態(tài)的路由規(guī)則。

從云原生視角來說，Dubbo3 的核心能力基本上也就成圍繞以上幾點(diǎn)分析展開的，主要涉及：抽象全新的服務(wù)發(fā)現(xiàn)模型、定義下一代的更能用的 RPC 協(xié)議與數(shù)據(jù)傳輸格式、服務(wù)治理能力重構(gòu)等。接下來，我們就看看 3.0 preview 中這些能力的具體實(shí)現(xiàn)。

Preview 版本功能速覽

就在今天，Dubbo?3.0.0.preview?版本正式通過了?Apache?社區(qū)投票并完成了正式發(fā)布，作為?3.0?的首個(gè)發(fā)布版本，代表了社區(qū) 3.0 版本的全面啟動(dòng)，也展示了未來 3.0 的發(fā)展方向。當(dāng)然，我們要意識(shí)到?preview?版本還遠(yuǎn)未達(dá)到生產(chǎn)可用，它只是為了讓大家快速、方便了解?Dubbo3?的一個(gè)預(yù)覽版本，離正式版本甚至?alpha?版本還有一段時(shí)間要走，具體大家可關(guān)注文后的 Dubbo Roadmap。

以下 preview 版本發(fā)布的幾個(gè)核心特性：

• 全新的服務(wù)發(fā)現(xiàn)模型

• 下一代基于 HTTP/2 的 RPC 協(xié)議：Triple

• 服務(wù)治理重構(gòu)：全新路由規(guī)則

• 性能提升

  • 百萬節(jié)點(diǎn)級(jí)水平擴(kuò)容

  • 調(diào)用鏈路 QPS 性能提升

在 preview 以上能力中，特別值得注意的是得益于 Dubbo3 與 HSF 的融合，Dubbo3 的整體性能也有望得到大幅提升。

Preview 版本是從架構(gòu)層面對(duì) Dubbo 的一次全面升級(jí)，接下來，社區(qū)一方面會(huì)從功能完善度、穩(wěn)定性等幾個(gè)方面繼續(xù)增強(qiáng) 3.0 版本，并將在 6 月份發(fā)布首個(gè)穩(wěn)定版本，另一方面社區(qū)將兌現(xiàn)更多新的功能。首先，接下來即將交付的是 Kubernetes Service 集成，而 Proxyless Mesh、基于反壓的智能流量調(diào)度等功能正在前期的調(diào)研或開發(fā)階段。

下面，我們就選取以上三個(gè)核心功能，深入了解它們的實(shí)現(xiàn)機(jī)制。

1. 全新服務(wù)發(fā)現(xiàn)模型

下圖是 Dubbo2 的服務(wù)發(fā)現(xiàn)模型：Provider 注冊(cè)服務(wù)地址，Consumer 經(jīng)過注冊(cè)中心協(xié)調(diào)并發(fā)現(xiàn)服務(wù)地址，進(jìn)而對(duì)地址發(fā)起通信，這是被絕大多數(shù)微服務(wù)框架的經(jīng)典服務(wù)發(fā)現(xiàn)流程。而 Dubbo2 的特殊之處在于，它把 “RPC 接口”的信息也融合在了地址發(fā)現(xiàn)過程中，而這部分信息往往是和具體的業(yè)務(wù)定義密切相關(guān)的。

而在接入云原生基礎(chǔ)設(shè)施后，基礎(chǔ)設(shè)施融入了微服務(wù)概念的抽象，容器化微服務(wù)被編排、調(diào)度的過程即完成了在基礎(chǔ)設(shè)施層面的注冊(cè)。如下圖所示，基礎(chǔ)設(shè)施即承擔(dān)了注冊(cè)中心的職責(zé)，又完成了服務(wù)注冊(cè)的動(dòng)作，而 “RPC 接口”這部分信息，由于與具體的業(yè)務(wù)相關(guān)，不可能也不適合被基礎(chǔ)設(shè)施托管。

在這樣的場(chǎng)景下，對(duì) Dubbo3 的服務(wù)注冊(cè)發(fā)現(xiàn)機(jī)制提出了兩個(gè)要求：

Dubbo3 需要在原有服務(wù)發(fā)現(xiàn)流程中抽象出通用的、與業(yè)務(wù)邏輯無關(guān)的地址映射模型，并確保這部分模型足夠合理，以支持將地址的注冊(cè)行為和存儲(chǔ)委托給下層基礎(chǔ)設(shè)施；

Dubbo3 特有的業(yè)務(wù)接口同步機(jī)制，是 Dubbo3 需要保留的優(yōu)勢(shì)，需要在 1 中定義的新地址模型之上，通過框架內(nèi)的自有機(jī)制予以解決。

這樣設(shè)計(jì)的全新的服務(wù)發(fā)現(xiàn)模型，在架構(gòu)兼容性、可伸縮性上都給 Dubbo3 帶來了更大的優(yōu)勢(shì)。

在架構(gòu)兼容性上，如上文所述，Dubbo3 復(fù)用下層基礎(chǔ)設(shè)施的服務(wù)抽象能力成為了可能；另一方面，如 Spring Cloud 等業(yè)界其它微服務(wù)解決方案也沿用這種模型，在打通了地址發(fā)現(xiàn)之后，使得用戶探索用 Dubbo 連接異構(gòu)的微服務(wù)體系成為了一種可能。

Dubbo3 服務(wù)發(fā)現(xiàn)模型更適合構(gòu)建可伸縮的服務(wù)體系，這點(diǎn)要如何理解？這里先舉個(gè)簡(jiǎn)單的例子，來直觀的對(duì)比 Dubbo2 與 Dubbo3 在地址發(fā)現(xiàn)流程上的數(shù)據(jù)流量變化：假設(shè)一個(gè)微服務(wù)應(yīng)用定義了 100 個(gè)接口（Dubbo 中的服務(wù)），則需要往注冊(cè)中心中注冊(cè) 100 個(gè)服務(wù)，如果這個(gè)應(yīng)用被部署在了 100 臺(tái)機(jī)器上，那這 100 個(gè)服務(wù)總共會(huì)產(chǎn)生 100 * 100 = 10000 個(gè)虛擬節(jié)點(diǎn)；而同樣的應(yīng)用，對(duì)于 Dubbo3 來說，新的注冊(cè)發(fā)現(xiàn)模型只需要 1 個(gè)服務(wù)（只和應(yīng)用有關(guān)和接口無關(guān)）， 只注冊(cè)和機(jī)器實(shí)例數(shù)相等的 1 * 100 = 100 個(gè)虛擬節(jié)點(diǎn)到注冊(cè)中心。在這個(gè)簡(jiǎn)單的示例中，Dubbo 所注冊(cè)的地址數(shù)量下降到了原來的 1 / 100，對(duì)于注冊(cè)中心、訂閱方的存儲(chǔ)壓力都是一個(gè)極大的釋放。更重要的是，地址發(fā)現(xiàn)容量徹底與業(yè)務(wù) RPC 定義解藕開來，整個(gè)集群的容量評(píng)估對(duì)運(yùn)維來說將變得更加透明：部署多少臺(tái)機(jī)器就會(huì)有多大負(fù)載，不會(huì)像 Dubbo2 一樣，因?yàn)闃I(yè)務(wù) RPC 重構(gòu)就會(huì)影響到整個(gè)集群服務(wù)發(fā)現(xiàn)的穩(wěn)定性。

2. 下一代通信協(xié)議：Triple

我們將 Dubbo3 的新協(xié)議命名為 Triple，有代表第 3 代協(xié)議的意思。在云原生背景下，Triple 協(xié)議需要解決兩大問題：

• 通信協(xié)議和數(shù)據(jù)傳輸格式的標(biāo)準(zhǔn)化問題。這涉及到 RPC 協(xié)議、數(shù)據(jù)定義、數(shù)據(jù)傳輸?shù)拳h(huán)節(jié)，未來可移植性、不被廠商鎖定會(huì)成為每個(gè)上云企業(yè)用戶的訴求，組件內(nèi)的私有協(xié)議和特有數(shù)據(jù)格式，必然會(huì)成為很多用戶選型的顧慮。

• 穿透性、通用性問題。在 Mesh 等架構(gòu)設(shè)想下，微服務(wù)甚至所有組件的通信都要經(jīng)過 sidecar 代理轉(zhuǎn)發(fā)，理論上，Sidecar 是要透明的轉(zhuǎn)發(fā)流量的（收到什么就轉(zhuǎn)發(fā)什么），起碼 payload 不應(yīng)該是 Sidecar 關(guān)注的；而 Sidecar 在某些時(shí)候也需要感知流量?jī)?nèi)容的，因?yàn)樗谛┳隽髁康恼{(diào)度，這個(gè)時(shí)候，Triple 就要做到足夠通用 – 讓所有的 Sidecar 都能在預(yù)期的地方取到其關(guān)注的元數(shù)據(jù)，而不用解析整個(gè) payload。

除了以上兩個(gè)核心問題，Triple 協(xié)議還需要被設(shè)計(jì)用來支持更多的業(yè)務(wù)語義。

• 協(xié)議應(yīng)該提供更完善的請(qǐng)求模型，除了 Request/Response 模型，還應(yīng)該支持 Streaming 和 Bidirectional。

• 在性能上，新的協(xié)議應(yīng)該保留 request Id 機(jī)制，以避免 HOL 帶來的性能損耗。

• 新協(xié)議應(yīng)該易于擴(kuò)展，包括但不限于 Tracing、Monitoring、BackPressure 等支持。

基于以上需求，Triple 協(xié)議是完全基于 HTTP/2 之上構(gòu)建的，另外，Triple 協(xié)議將會(huì)做到完全兼容 gRPC 協(xié)議；在服務(wù)定義、數(shù)據(jù)格式定義以及傳輸格式上，Triple 將更增加對(duì) Protobuf 的支持。

3. 統(tǒng)一的路由規(guī)則

Dubbo3 會(huì)對(duì)服務(wù)治理規(guī)則進(jìn)行全面的重構(gòu)，以更好的適應(yīng)云原生基礎(chǔ)設(shè)施的變革。

當(dāng)前的 3.0 preview 版本提供了一個(gè)重構(gòu)后的路由規(guī)則機(jī)制原型，雖然當(dāng)前版本的實(shí)現(xiàn)還需要繼續(xù)增強(qiáng)，但從設(shè)計(jì)理念上，我們可以解讀出：Dubbo3 期望提供一種跨平臺(tái)、跨語言、跨多種部署架構(gòu)的通用路由規(guī)則。

隨著微服務(wù)對(duì)治理需求的挖掘，Dubbo2 路由規(guī)則除了在語義表達(dá)上不能涵蓋所有場(chǎng)景之外，更為重要的是，其基于特定語言、特定主機(jī) ip 的過濾機(jī)制，已不再適應(yīng)底層調(diào)度平臺(tái)的工作機(jī)制，Dubbo3 需要引入一種全新設(shè)計(jì)的路由規(guī)則。而對(duì)于“跨多種部署架構(gòu)” 這個(gè)點(diǎn)，我們?cè)O(shè)想未來以 Dubbo 構(gòu)建的微服務(wù)會(huì)有三種部署架構(gòu)：傳統(tǒng) SDK、基于 Sidecar 的 Service Mesh以及脫離 Sidecar 的 Service Mesh，這三種部署形態(tài)都將由 Dubbo3 統(tǒng)一的路由規(guī)則進(jìn)行治理。

• 基于 Sidecar 的 Service Mesh，經(jīng)典的 Mesh 架構(gòu)，獨(dú)立的 sidecar 運(yùn)行時(shí)接管所有的流量。

• 脫離 Sidecar 的 Service Mesh，變種 Mesh 架構(gòu)，沒有 sidecar 運(yùn)行時(shí)，富 SDK 直接通過 xDS 與控制面通信，我們將在后續(xù)發(fā)布關(guān)于 Proxyless 模式更詳細(xì)的解讀。

實(shí)踐中的 Dubbo3

云原生微服務(wù)變革在各大廠商內(nèi)部早已展開，相比于當(dāng)前開源社區(qū)的?preview?版本，Dubbo3 在阿里巴巴的開發(fā)與實(shí)踐已經(jīng)在逐步鋪開：部分功能已經(jīng)在阿里巴巴的部分業(yè)務(wù)線上得到了規(guī)模化驗(yàn)證（考拉），并且更多的功能和業(yè)務(wù)線也將進(jìn)入試點(diǎn)、推廣階段（餓了么、釘釘?shù)?#xff09;。有一點(diǎn)是值得特別提及的是：在接下來阿里巴巴的微服務(wù)架構(gòu)升級(jí)戰(zhàn)略中，Dubbo3 將成為阿里巴巴經(jīng)濟(jì)體未來唯一的標(biāo)準(zhǔn)服務(wù)框架，它將逐步在所有業(yè)務(wù)線取代 HSF 和 Dubbo2，并且我們期待在接下來的 1-2 年 Dubbo3 內(nèi)能覆蓋大多數(shù)重要的業(yè)務(wù)線。

說在這里，有必要提一下阿里巴巴的微服務(wù)框架演進(jìn)歷程。大概在 2011 年，阿里巴巴開源了 Dubbo2 這一款服務(wù)框架并獲得極大成功，在 Dubbo2 開源不久，在阿里巴巴內(nèi)部又發(fā)展出了一款全新的服務(wù)框架 – HSF，兩者在設(shè)計(jì)理念上是高度相似的，而經(jīng)過這么些年的發(fā)展，HSF 得以跟隨阿里巴巴的業(yè)務(wù)系統(tǒng)更快速的成長(zhǎng)，由其是在大集群、大流量治理下展現(xiàn)出了更好的性能和穩(wěn)定性。在阿里云原生微服務(wù)戰(zhàn)略下，整合各個(gè)優(yōu)秀的框架并發(fā)展統(tǒng)一品牌的 Dubbo3 被納入發(fā)展規(guī)劃，在此背景下，Dubbo3 實(shí)現(xiàn)了Dubbo2 與 HSF 的融合，并將推動(dòng)實(shí)現(xiàn)內(nèi)、外技術(shù)棧的統(tǒng)一。

除了阿里之外，工商銀行等標(biāo)桿用戶也已啟動(dòng)了對(duì) Dubbo3 項(xiàng)目的試點(diǎn)。從社區(qū)角度來說，preview 預(yù)覽版本的發(fā)布只是開始，未來隨著阿里巴巴、工商銀行等更多標(biāo)桿用戶的全面落地，將推動(dòng)項(xiàng)目更快、更高質(zhì)量的發(fā)展，助力項(xiàng)目保持持續(xù)的創(chuàng)新能力和社區(qū)生命力。

未來規(guī)劃（Roadmap）

以下是 Dubbo3 的 Roadmap，截止此文發(fā)稿，社區(qū)已經(jīng)完成了 3.0 preview 版本的發(fā)布。

在 6 月份，我們期望能迎來 Dubbo3 的首個(gè)社區(qū)正式版本。

隨后，一直到下半年的 11 月份，我們將重點(diǎn)投入在對(duì) Kubernetes、ServiceMesh 架構(gòu)的支持上，中間當(dāng)然也包括了對(duì)服務(wù)治理規(guī)則的全面重構(gòu)。

在此之后，我們將開始在服務(wù)柔性上的嘗試，以期提供一種能更高效的利用資源且能提高系統(tǒng)穩(wěn)定性的流量高度機(jī)制。

本文開篇關(guān)于云原生微服務(wù)變革部分思想引自阿里云高級(jí)技術(shù)專家、CNCF TOC 張磊 《Microservices - A Cloud Native View》一文分享。

點(diǎn)擊直達(dá)GitHub 查看 Dubbo 3.0.0.preview：https://github.com/apache/dubbo/releases/tag/3.0.0.preview

總結(jié)

以上是生活随笔為你收集整理的透过 3.0 Preview 看 Dubbo 的云原生变革的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。