摘要：今天的話題是與的開源現(xiàn)狀和未來規(guī)劃，我們知道，過去一段時(shí)間疏于維護(hù)，去年阿里高調(diào)宣布重啟開源之后，社區(qū)里問的最多的問題是，這次開源與上次有什么一樣，還有就是和是什么關(guān)系希望通過這次的分享能夠解答這些問題。

摘要： Dubbo 在過去一段時(shí)間疏于維護(hù)，去年阿里高調(diào)宣布重啟 Dubbo 開源之后，社區(qū)里問的最多的問題是，這次開源與上次有什么一樣，還有就是 Dubbo 和 Spring Boot、Spring Cloud 是什么關(guān)系？希望通過這次Dubbo沙龍的分享能夠解答這些問題。

本文章是根據(jù)朱勇老師在上海Dubbo沙龍的演講稿進(jìn)行整理，意在為大家展示最真實(shí)、最一手的沙龍技術(shù)干貨。

前言
大家好，非常榮幸有機(jī)會(huì)和大家做這個(gè)分享。我先做個(gè)自我介紹，我叫朱勇，來自阿里巴巴中間件團(tuán)隊(duì)，主要工作在應(yīng)用容器、微服務(wù)、RPC幾個(gè)領(lǐng)域。我是 09 年加入阿里，13年加入中間件團(tuán)隊(duì)。

今天的話題是與 Dubbo 的開源現(xiàn)狀和未來規(guī)劃，我們知道，Dubbo 過去一段時(shí)間疏于維護(hù)，去年阿里高調(diào)宣布重啟 Dubbo 開源之后，社區(qū)里問的最多的問題是，這次開源與上次有什么一樣，還有就是 Dubbo 和 Spring Boot、Spring Cloud 是什么關(guān)系？希望通過這次的分享能夠解答這些問題。

這次分享包含以下幾個(gè)環(huán)節(jié)，Dubbo 基本原理、Dubbo 社區(qū)、開源現(xiàn)狀、以及后續(xù)規(guī)劃幾個(gè)部分。

Dubbo 工作原理
考慮到有些同學(xué)可能對 Dubbo 不太熟悉，我先簡單介紹下 Dubbo 的工作原理和架構(gòu)。簡單的說，Dubbo 是 基于 Java 的 RPC 框架。Dubbo 工作分為 4 個(gè)角色，分別是服務(wù)提供者、服務(wù)消費(fèi)者、注冊中心、和監(jiān)控中心。按照工作階段又分為部署階段和運(yùn)行階段。其中部署階段在圖中以藍(lán)色的線來表示，代表服務(wù)注冊、服務(wù)訂閱的過程，而運(yùn)行階段在圖中以紅色的線來表示，代表一次 RPC 的完整調(diào)用。部署階段中服務(wù)提供方在啟動(dòng)時(shí)在指定的端口上暴露服務(wù)，并向注冊中心匯報(bào)自己的地址，服務(wù)調(diào)用方啟動(dòng)時(shí)向注冊中心訂閱自己感興趣的服務(wù)。運(yùn)行階段注冊中心先將地址列表推送給服務(wù)消費(fèi)者，服務(wù)消費(fèi)者選取一個(gè)地址向?qū)Χ税l(fā)起調(diào)用。在這個(gè)過程中，服務(wù)消費(fèi)者和服務(wù)提供者的運(yùn)行狀態(tài)會(huì)上報(bào)給監(jiān)控中心。

其實(shí)，這里講的基本原理套用到任何一個(gè)成熟的服務(wù)框架都是合適的，但是 Dubbo 在框架設(shè)計(jì)上有著自己的設(shè)計(jì)哲學(xué)。

這里是 Dubbo 的整體架構(gòu)圖。首先這張圖看起來很復(fù)雜、信息量很大。我先介紹一下這張圖的解讀方式。這張圖從左往右看，分為兩部分，左半邊藍(lán)色背景的部分代表服務(wù)消費(fèi)者，右半邊綠色背景的部分代表服務(wù)提供者。從上往下看又分為九層。左邊九層按功能來劃分又被分為了三大類，分別是面向用戶的 Biz 層、框架核心 RPC 以及負(fù)責(zé)遠(yuǎn)程傳輸?shù)?Remoting，右邊按面向人群又劃分為了兩類，上面兩層是面向用戶的 API，而下面七層是面向擴(kuò)展提供者的 SPI。圖中的線代表對象與對象之間不同的關(guān)系，紫色代表繼承；黑色代表依賴；藍(lán)色虛線代表服務(wù)注冊、服務(wù)訂閱的過程，也就是上面講的部署階段；紅色代表一次完整的 RPC 調(diào)用，也就是運(yùn)行階段。我們順著紅色的線，來看下一次完整的 RPC 調(diào)用是如何進(jìn)行的。首先從圖的左邊開始，服務(wù)消費(fèi)者從 Proxy 層發(fā)起一次 RPC 調(diào)用，Dubbo 從 Registry 層拿到服務(wù)的地址列表，再通過 Cluster 層選擇其中的一個(gè)作為目標(biāo)地址，再流經(jīng) Protocol 決定的執(zhí)行鏈，最后將服務(wù)信息，包括要調(diào)用的服務(wù)名、方法名、參數(shù)等序列化，再經(jīng)過應(yīng)用協(xié)議編碼，通過 Transport 層發(fā)送到網(wǎng)絡(luò)上。右邊的服務(wù)提供者從網(wǎng)絡(luò)上收到數(shù)據(jù)以后，從下往上，依次通過應(yīng)用協(xié)議解碼、反序列化得到要調(diào)用的服務(wù)信息，再經(jīng)由執(zhí)行鏈，最終通過 Invoker 找到目標(biāo)服務(wù)的目標(biāo)方法，執(zhí)行并返回結(jié)果。解讀完 Dubbo 的架構(gòu)圖，再來看看架構(gòu)圖中體現(xiàn)的設(shè)計(jì)原則。Dubbo 秉承高內(nèi)聚、低耦合的設(shè)計(jì)，這一點(diǎn)體現(xiàn)在架構(gòu)圖中九層的清晰劃分上，并且也體現(xiàn)在依賴的方向上。黑色的線條的方向永遠(yuǎn)是從上指向下，沒有循環(huán)依賴和反向依賴的出現(xiàn)。Dubbo 還有一個(gè)很重要的設(shè)計(jì)哲學(xué)就是平等對待第三方的擴(kuò)展，即 Dubbo 內(nèi)建的功能也是通過同樣的擴(kuò)展機(jī)制提供出來的，第三方的擴(kuò)展和內(nèi)建功能可以相互取代。正是由于 Dubbo 將第三方擴(kuò)展當(dāng)成框架的一等公民，為未來基于這個(gè)機(jī)制建立生態(tài)帶來了可能性。這一點(diǎn)，我們在后面規(guī)劃部分進(jìn)一步展開。

Dubbo 社區(qū)
Dubbo 社區(qū)，我想從戰(zhàn)略、社區(qū)、生態(tài)和回饋四個(gè)方面講一講。首先阿里巴巴將開源提到了新的戰(zhàn)略高度，去年云棲大會(huì)上阿里云宣布了加大技術(shù)投入、擁抱開源的策略。阿里巴巴在開源領(lǐng)域耕耘多年，目前在 Github 上有 150 多個(gè)開源項(xiàng)目，總 Star 數(shù)在 17 萬，并且 Alibaba 這個(gè) Group 在全球的排名進(jìn)入前十。這其中有不少我們大家耳熟能詳?shù)捻?xiàng)目，包括 JStorm, RocketMQ, FastJson, Druid, Weex，當(dāng)然還有我們 Dubbo。其中 JStorm 和 RocketMQ 成為 Apache 的頂級項(xiàng)目，而 Weex 和 Dubbo 也正在 Apache 中孵化。社區(qū)方面，Dubbo 這兩年疏于維護(hù)，很多開發(fā)者提交的 Pull Request 和 Issue 沒有得到及時(shí)的解決，一些公司不得不維護(hù) Dubbo 私有分支，版本分化嚴(yán)重，導(dǎo)致社區(qū)無法 分享這些分支上的成果。我們希望改變這一點(diǎn)，讓整個(gè)社區(qū)都能享受到開源的好處。一個(gè)活躍的社區(qū)將會(huì)產(chǎn)生一個(gè)繁榮的生態(tài)，而一個(gè)繁榮的生態(tài)將會(huì)普惠所有使用 Dubbo 的人，最終形成社區(qū)和生態(tài)共同發(fā)展的良性循環(huán)。另外在阿里內(nèi)部，負(fù)責(zé) Dubbo 的團(tuán)隊(duì)就是負(fù)責(zé)服務(wù)框架的團(tuán)隊(duì)，我們在大流量、大規(guī)模集群、服務(wù)治理領(lǐng)域有著豐富的實(shí)踐，這些會(huì)有計(jì)劃地回饋給社區(qū)。

這里強(qiáng)調(diào)一點(diǎn)，為了打消社區(qū)對 Dubbo 未來發(fā)展的顧慮，我們做出了把 Dubbo 捐獻(xiàn)給 Apache 基金會(huì)的決定，并且在2018新年之前，Dubbo 正式進(jìn)入 Apache 孵化。Apache 認(rèn)為 社區(qū)的重要性大于代碼，非常注重多樣性，強(qiáng)調(diào)一個(gè)項(xiàng)目需要有多個(gè)公司和個(gè)人貢獻(xiàn)者參與，避免被一家公司左右，所以現(xiàn)在 Dubbo 的發(fā)展完全是按 Apache Way 社區(qū)化的方式來運(yùn)作的；個(gè)人貢獻(xiàn)者的參與方式可以是多種形式，除了貢獻(xiàn)代碼外，還可以通過報(bào) Issue、增強(qiáng)文檔、參與郵件討論等方式；只要讓社區(qū)看到你的貢獻(xiàn)，你就可以一步一步從 Contributor 成為 Committer，再從 Committer 成為 PMC Member。所以希望 大家多參與 Dubbo 的社區(qū)互動(dòng)，多分享你們在實(shí)踐中的經(jīng)驗(yàn)，反饋碰到的問題，只有你們的參與，Dubbo 的未來才有可能成功。

這里順便分享下 Dubbo 進(jìn)入 Apache 孵化的歷程，希望對其他要把自己的項(xiàng)目捐獻(xiàn)給 Apache 的小伙伴們有幫助。進(jìn)入 Apache 分為三個(gè)階段，準(zhǔn)備階段、孵化階段和畢業(yè)階段。準(zhǔn)備階段需要做的事情有找到愿意幫助孵化的導(dǎo)師，向 Apache 提交進(jìn)入孵化的申請，經(jīng)過導(dǎo)師們討論并投票，如果通過的話就可以進(jìn)入孵化。孵化階段分為兩大環(huán)節(jié)，第一個(gè)環(huán)節(jié)是公司和個(gè)人簽署協(xié)議向 Apache 移交代碼和知識產(chǎn)權(quán)，目前 Dubbo 已經(jīng)完成了第一個(gè)環(huán)節(jié)。之后就是在導(dǎo)師的指導(dǎo)下按照 Apache 的規(guī)范 做版本迭代、運(yùn)營社區(qū)、發(fā)展更多的 Committer，如果最終通過了成熟度評估，就可以順利畢業(yè)成為 Apache 的頂級項(xiàng)目。

開源現(xiàn)狀
Dubbo 開源的現(xiàn)狀我打算從數(shù)據(jù)、用戶、項(xiàng)目 三個(gè)維度分別闡述。數(shù)據(jù)方面是這樣，從去年七月份重啟開源，到目前為止，Dubbo 在 Github 上的 Star 數(shù)增長了 115% 達(dá)到了 1.9+ 萬，目前在 Github Java 類項(xiàng)目中排名第 7 位，在去年開源中國舉辦的 2017 最受歡迎的開源項(xiàng)目中 Dubbo 和阿里巴巴其他三款軟件 FastJson、Druid、RocketMQ 共同入選。

用戶方面 Dubbo 的用戶主要分為三類，第一類是以阿里巴巴、滴滴、當(dāng)當(dāng)為代表的互聯(lián)網(wǎng)企業(yè)，第二類是向互聯(lián)網(wǎng)轉(zhuǎn)型的大型企業(yè)，如中國工商銀行、中國電信和中國人壽等，第三類是使用 Dubbo 作為服務(wù)化方案的 ISV，包括亞信和文思。在這些企業(yè)中，有些維護(hù)著自己的私有分支，有些企業(yè)的員工積極參與 Dubbo 的建設(shè)，在這次進(jìn)入 Apache 孵化的過程中，我們邀請了當(dāng)當(dāng)、去哪兒、微店的員工成為初始成員，6月份剛剛發(fā)展了有贊的一位開發(fā)者成為 Dubbo Committer。今年我們打算在北上廣深、以及杭州等地舉辦幾次 Dubbo 開發(fā)者沙龍，這是第二站。沙龍的主題是面向工程師的，包括架構(gòu)分析、源碼解讀、未來規(guī)劃、案例分析等內(nèi)容，沒能來到現(xiàn)場的也沒有關(guān)系，整個(gè)沙龍會(huì)全程通過網(wǎng)絡(luò)直播。

這幾個(gè)月我們在 Dubbo 上的工作 圍繞一個(gè)目標(biāo) 進(jìn)行的，就是如何才能重新贏得社區(qū)的信任。為此我們首先要打好基礎(chǔ)，包括重新建設(shè)了網(wǎng)頁和文檔，全面更新了三方的依賴，在打好基礎(chǔ)的前提下，我們又確立了版本發(fā)布策略，采取特性版本和維護(hù)版本并行，每個(gè)月至少發(fā)布一個(gè)版本的節(jié)奏，迄今為止，我們已經(jīng)發(fā)布了 7 個(gè)維護(hù)版本和 2 個(gè)特性版本。在這些版本中，我們重點(diǎn)考慮了社區(qū)呼聲最高的特性，其中就有 Spring Boot 的支持和對 REST 服務(wù)的支持。

下面這些事情是我們已經(jīng)在進(jìn)行中的，絕大多數(shù)都是我們后面要講的規(guī)劃中的事項(xiàng)，比如核心增強(qiáng)中的異步 API、Metrics、熔斷，生態(tài)中的多語言客戶端、Dubbo Mesh，還有對 Dubbo OPS 的增強(qiáng)；這里特別提一下 Dubbo OPS，現(xiàn)在我們已經(jīng)將 OPS 中對 WebX 的依賴去除，并基于 Spring Boot 2.0 進(jìn)行了重新適配，代碼已經(jīng)合并到主干；接下來還會(huì)將原先 Dubbo Admin 以及 Dubbo Monitor 進(jìn)行合并，同時(shí)會(huì)適配更多的注冊中心 Registry；另外我們在社區(qū)發(fā)起了關(guān)于全新 Logo 及官網(wǎng)的討論，目的是想通過全新官網(wǎng)的建設(shè)，更好的將文檔、博客、活動(dòng)等信息呈現(xiàn)給社區(qū)和開發(fā)者，新的官網(wǎng)在設(shè)計(jì)開發(fā)中，接下來會(huì)上線，請大家保持關(guān)注。

最后總結(jié)一下，Dubbo 重啟開源的這幾個(gè)月總的來說是成功的，背后主要有兩點(diǎn)原因，一是公司層面的支持，其中有工程師團(tuán)隊(duì)的努力，也有宣傳運(yùn)營上的投入；二是依托Dubbo 的群眾基礎(chǔ)，我們這幾個(gè)月的工作重新贏得了社區(qū)的信任，大家也開始關(guān)注 Dubbo 的發(fā)展。下面我會(huì)從核心和生態(tài)兩部分談下 Dubbo 未來規(guī)劃的 思考。

未來規(guī)劃
首先聊下規(guī)劃的 整體思路。Dubbo 后續(xù)的規(guī)劃主要是要 解決好兩個(gè)問題。第一個(gè)問題是未來出現(xiàn)的技術(shù)趨勢哪些是和 Dubbo 緊密相關(guān)的，如果 Dubbo 不跟隨，就有可能在未來被淘汰的問題，第二個(gè)問題是 Dubbo 本身定位的問題，也就是只做框架夠不夠的問題。

關(guān)于第一個(gè)問題，我們看到的是越來越多的應(yīng)用從單體架構(gòu)轉(zhuǎn)向微服務(wù)架構(gòu)，微服務(wù)的理念也深入人心，還有就是各大云廠商開始宣傳云原生的概念，一些應(yīng)用也開始向云上遷移，我們認(rèn)為 微服務(wù) 和 云原生 這兩個(gè)技術(shù)趨勢上值得 Dubbo 關(guān)注的。

第二個(gè)問題 Dubbo 自身的定位，Dubbo 核心要保持技術(shù)上的領(lǐng)先性，我們會(huì)重點(diǎn)關(guān)注性能、大流量、大規(guī)模集群領(lǐng)域的挑戰(zhàn)，但是光有這樣是遠(yuǎn)遠(yuǎn)不夠的，在保持核心演進(jìn)的同時(shí)，我們還需要圍繞 Dubbo 核心發(fā)展生態(tài)，將 Dubbo 做成一個(gè)服務(wù)化改造的整體方案。

Dubbo 核心的規(guī)劃又 分為三塊，第一塊包括模塊化和元數(shù)據(jù)，通過這兩塊的優(yōu)化來解決適應(yīng)未來技術(shù)方向的問題，也就是微服務(wù)和云原生，具體來說，目前 Dubbo 服務(wù)治理與網(wǎng)絡(luò)傳輸耦合嚴(yán)重，通過進(jìn)一步的模塊化工作可以為 Dubbo 成為服務(wù)網(wǎng)格中的數(shù)據(jù)面板做好準(zhǔn)備，元數(shù)據(jù)目前既包含服務(wù)注冊信息，也包含服務(wù)配置信息，將兩者分離可以更清晰的分開注冊層和配置層，為適配微服務(wù)的注冊中心和配置中心 打好基礎(chǔ)。第二塊是關(guān)于我們?nèi)绾伟寻⒗镌诜?wù)治理方面的經(jīng)驗(yàn)回饋給社區(qū)，其中包括了這里的路由策略、大流量和大規(guī)模，在路由策略中我們打算引入多機(jī)房路由、參數(shù)路由、灰度路由等策略，在大流量方面 重點(diǎn)考慮 熔斷、限流、隔離的支持，在大規(guī)模集群方面需要解決超大規(guī)模地址列表對 CPU、內(nèi)存帶來的壓力，最后一塊是進(jìn)一步的增強(qiáng)異步化，包括對 CompletableFuture 的支持以及跨進(jìn)程 Reactive Stream 的預(yù)研，目前 Reactive Stream 在內(nèi)部 Dubbo 3.0 中正在孵化，壓測表明這項(xiàng)技術(shù)對于提升 CPU 利用率和系統(tǒng)的吞吐率很有幫助。

回想一下剛才的架構(gòu)圖，除了上面的兩層，下面的七層都是可擴(kuò)展的。Dubbo 生態(tài)的建設(shè)我們的思路是利用核心的擴(kuò)展能力盡可能多的提供開箱即用的擴(kuò)展實(shí)現(xiàn)。這里我們按照架構(gòu)圖中的層次劃分歸納了每一層可能提供的擴(kuò)展實(shí)現(xiàn)。其中藍(lán)黑色的代表 Dubbo 框架已經(jīng)支持的，綠色部分代表這次重啟開源之后新加入以及正在進(jìn)行中的，而橙色的部分代表我們計(jì)劃在未來加入的。從下往上，我們看下未來會(huì)加入的支持，我們在序列化層計(jì)劃加入對 Protobuf 的支持，在 Transport 層加入對 Http2 的支持，在 Protocol 層加入對 gRPC 的支持，在 Cluster、Router、Load Balance 代表的服務(wù)治理層計(jì)劃加入阿里對服務(wù)治理方面的實(shí)踐，其中包括了熔斷、多機(jī)房路由、灰度路由，以及更豐富的負(fù)載均衡策略。再往上通過元數(shù)據(jù)的優(yōu)化，我們可以更清晰的分開注冊層和配置層，從而可以在注冊層加入更多的對微服務(wù)注冊中心的支持，比如 Eureka，Consul，在配置層也可以開始支持配置的動(dòng)態(tài)推送，當(dāng)然在這兩層我們也會(huì)提供對阿里體系中的注冊中心 Config Server、配置中心 Diamond 的支持，這兩個(gè)產(chǎn)品就是后續(xù)郭平老師給大家分享的 Nacos。最頂上是對 API 的支持，我們會(huì)做對 Spring Cloud 的適配。

我們有了不斷向前演進(jìn)的核心，豐富的擴(kuò)展生態(tài)，我們還需要解決 Dubbo 服務(wù)與外界互通的問題。這里的互通有兩方面的含義。第一是 Dubbo 服務(wù)與外圍系統(tǒng)互通，第二是異構(gòu)系統(tǒng)如何調(diào)用 Dubbo 服務(wù)的問題。首先說下外圍系統(tǒng)對接的問題，外圍系統(tǒng)也分為兩類，圖中草綠色部分包括了 Dubbo OPS、Test Server、Mock Server、 Swagger Server，無非就是解決服務(wù)如何查詢，服務(wù)治理規(guī)則如何配置，如何測試服務(wù)，開發(fā)階段如何解決上下游依賴，服務(wù)的 API 支持等問題，這些問題與 Dubbo 服務(wù)緊密相關(guān)，我們計(jì)劃自己來提供這方面的支持。再看圖中橙色的部分，包括了服務(wù)注冊中心、配置中心、鑒權(quán)中心，鏈路追蹤和監(jiān)控中心，這些系統(tǒng)外面有很多開源和商業(yè)的選擇，我們的思路是盡可能多的提供與他們的適配，為用戶帶來開箱急用的體驗(yàn)。值得一提的是，這一塊的建設(shè)是雙向的，目前 Spring Cloud Sleuth 主動(dòng)支持了 Dubbo。談到異構(gòu)系統(tǒng)如何調(diào)用 Dubbo 服務(wù)，本質(zhì)上是多語言支持的問題。要解決多語言調(diào)用，無非有兩種做法，一種是通過代理方式來調(diào)用，代理根據(jù)部署形式的不同又分為中心化的 API Gateway 方式，和本地部署的 Sidecar 方式，Sidecar 方式我們在下張片子里進(jìn)一步討論，對于 API Gateway 方式，只需要 Dubbo 服務(wù)可以按照 Json-RPC 或者 REST 的方式暴露服務(wù)就好。另一種調(diào)用方式就是原生語言客戶端，要支持的語言包括了常用的 Python，Node，Php，Go 等等，這一塊的挑戰(zhàn)和工作量都很大，我們的思路是和社區(qū)共建。目前千米網(wǎng)的同學(xué)已經(jīng)開始把他們的 Node 和 Python 的客戶端貢獻(xiàn)給社區(qū)。Go 和 Php 的版本也會(huì)很快提供。

規(guī)劃的最后部分我想聊聊 Dubbo Mesh，剛才談到互通問題的時(shí)候，解決多語言調(diào)用的一種方式是通過 Sidecar，談到 Sidecar 就不得不從云原生講起。目前各大云計(jì)算廠商開始定義云原生，鼓勵(lì)用戶將應(yīng)用往云上遷移。云原生的定義每家都不太一樣，但是其中可以看到有這么兩個(gè)趨勢。一個(gè)是云計(jì)算場景里多語言支持是強(qiáng)訴求，基于單一語言的架構(gòu)和方案會(huì)有很大的局限性；另一個(gè)是原來與應(yīng)用共生的服務(wù)治理能力開始從應(yīng)用中解耦出來，并下沉為平臺的基礎(chǔ)能力，這樣做的好處是應(yīng)用開發(fā)更簡單、應(yīng)用更輕、多語言支持也變得容易，服務(wù)治理能力可以透明升級。這一塊就是 Linkerd 率先提出的服務(wù)網(wǎng)格的概念。Dubbo 通過進(jìn)一步的模塊化工作，可以把服務(wù)治理能力多帶帶剝離出來獨(dú)立部署，成為服務(wù)網(wǎng)格中的數(shù)據(jù)面版，我們稱之為 Dubbo Mesh，它負(fù)責(zé)接管由本地所有 RPC 流量，并負(fù)責(zé)與外圍的注冊中心、配置中心對接。在服務(wù)網(wǎng)格下，一次 RPC 調(diào)用就會(huì)變成，左邊草綠色的 Dubbo RPC 發(fā)起一次調(diào)用，請求會(huì)發(fā)給和他部署在一起的 Dubbo Mesh，Dubbo Mesh 又會(huì)把這個(gè) RPC 請求轉(zhuǎn)發(fā)到對端的 Dubbo Mesh，對端的 Dubbo Mesh 又會(huì)將收到的請求發(fā)給和他部署在一起的 Dubbo RPC, 也就是圖中右邊的橙色部分。服務(wù)網(wǎng)格上我們非常關(guān)注的一個(gè)方向，目前我們正在做技術(shù)選型，相信很快就會(huì)有大家見面。

最后總結(jié)一下，通過核心、擴(kuò)展、互通三方面的建設(shè)，我們相信 Dubbo 體系可以成為服務(wù)化改造的國內(nèi)首選方案，并且能夠很好的適應(yīng)微服務(wù)和云原生這兩個(gè)技術(shù)趨勢。

原文鏈接