摘要：?Dubbo 在過去一段時間疏于維護点待，去年阿里高調宣布重啟 Dubbo 開源之后，社區(qū)里問的最多的問題是，這次開源與上次有什么一樣茫因，還有就是 Dubbo 和 Spring Boot、Spring Cloud 是什么關系杖剪？希望通過這次Dubbo沙龍的分享能夠解答這些問題冻押。
本文章是根據朱勇老師在上海Dubbo沙龍的演講稿進行整理，意在為大家展示最真實盛嘿、最一手的沙龍技術干貨洛巢。
前言
大家好，非常榮幸有機會和大家做這個分享次兆。我先做個自我介紹稿茉，我叫朱勇，來自阿里巴巴中間件團隊芥炭，主要工作在應用容器狈邑、微服務、RPC幾個領域蚤认。我是 09 年加入阿里米苹，13年加入中間件團隊。
今天的話題是與 Dubbo 的開源現狀和未來規(guī)劃砰琢，我們知道蘸嘶，Dubbo 過去一段時間疏于維護良瞧，去年阿里高調宣布重啟 Dubbo 開源之后，社區(qū)里問的最多的問題是训唱，這次開源與上次有什么一樣褥蚯，還有就是 Dubbo 和 Spring Boot、Spring Cloud 是什么關系况增？希望通過這次的分享能夠解答這些問題赞庶。
這次分享包含以下幾個環(huán)節(jié)，Dubbo 基本原理澳骤、Dubbo 社區(qū)歧强、開源現狀、以及后續(xù)規(guī)劃幾個部分为肮。
Dubbo 工作原理
考慮到有些同學可能對 Dubbo 不太熟悉摊册，我先簡單介紹下 Dubbo 的工作原理和架構。簡單的說颊艳，Dubbo 是?基于 Java 的 RPC 框架茅特。Dubbo 工作分為 4 個角色，分別是服務提供者棋枕、服務消費者白修、注冊中心、和監(jiān)控中心重斑。按照工作階段又分為部署階段和運行階段兵睛。其中部署階段在圖中以藍色的線來表示，代表服務注冊绸狐、服務訂閱的過程卤恳，而運行階段在圖中以紅色的線來表示累盗，代表一次 RPC 的完整調用寒矿。部署階段中服務提供方在啟動時在指定的端口上暴露服務，并向注冊中心匯報自己的地址若债，服務調用方啟動時向注冊中心訂閱自己感興趣的服務符相。運行階段注冊中心先將地址列表推送給服務消費者，服務消費者選取一個地址向對端發(fā)起調用蠢琳。在這個過程中啊终，服務消費者和服務提供者的運行狀態(tài)會上報給監(jiān)控中心病梢。
其實绒怨，這里講的基本原理套用到任何一個成熟的服務框架都是合適的，但是 Dubbo 在框架設計上有著自己的設計哲學兵迅。
這里是 Dubbo 的整體架構圖泰讽。首先這張圖看起來很復雜例衍、信息量很大昔期。我先介紹一下這張圖的解讀方式。這張圖從左往右看佛玄，分為兩部分硼一，左半邊藍色背景的部分代表服務消費者，右半邊綠色背景的部分代表服務提供者梦抢。從上往下看又分為九層般贼。左邊九層按功能來劃分又被分為了三大類，分別是面向用戶的 Biz 層奥吩、框架核心 RPC 以及負責遠程傳輸的 Remoting哼蛆，右邊按面向人群又劃分為了兩類，上面兩層是面向用戶的 API圈驼，而下面七層是面向擴展提供者的 SPI人芽。圖中的線代表對象與對象之間不同的關系，紫色代表繼承绩脆；黑色代表依賴萤厅；藍色虛線代表服務注冊、服務訂閱的過程靴迫，也就是上面講的部署階段惕味；紅色代表一次完整的 RPC 調用，也就是運行階段玉锌。我們順著紅色的線名挥，來看下一次完整的 RPC 調用是如何進行的。首先從圖的左邊開始主守，服務消費者從 Proxy 層發(fā)起一次 RPC 調用禀倔，Dubbo 從 Registry 層拿到服務的地址列表，再通過 Cluster 層選擇其中的一個作為目標地址参淫，再流經 Protocol 決定的執(zhí)行鏈救湖，最后將服務信息，包括要調用的服務名涎才、方法名鞋既、參數等序列化，再經過應用協議編碼耍铜，通過 Transport 層發(fā)送到網絡上邑闺。右邊的服務提供者從網絡上收到數據以后，從下往上棕兼，依次通過應用協議解碼陡舅、反序列化得到要調用的服務信息，再經由執(zhí)行鏈伴挚，最終通過 Invoker 找到目標服務的目標方法靶衍，執(zhí)行并返回結果臂寝。解讀完 Dubbo 的架構圖，再來看看架構圖中體現的設計原則摊灭。Dubbo 秉承高內聚咆贬、低耦合的設計，這一點體現在架構圖中九層的清晰劃分上帚呼，并且也體現在依賴的方向上掏缎。黑色的線條的方向永遠是從上指向下，沒有循環(huán)依賴和反向依賴的出現煤杀。Dubbo 還有一個很重要的設計哲學就是平等對待第三方的擴展眷蜈，即 Dubbo 內建的功能也是通過同樣的擴展機制提供出來的，第三方的擴展和內建功能可以相互取代沈自。正是由于 Dubbo 將第三方擴展當成框架的一等公民酌儒，為未來基于這個機制建立生態(tài)帶來了可能性。這一點枯途，我們在后面規(guī)劃部分進一步展開忌怎。
Dubbo 社區(qū)
Dubbo 社區(qū)，我想從戰(zhàn)略酪夷、社區(qū)榴啸、生態(tài)和回饋四個方面講一講。首先阿里巴巴將開源提到了新的戰(zhàn)略高度晚岭，去年云棲大會上阿里云宣布了加大技術投入鸥印、擁抱開源的策略。阿里巴巴在開源領域耕耘多年坦报，目前在 Github 上有 150 多個開源項目库说，總 Star 數在 17 萬，并且 Alibaba 這個 Group 在全球的排名進入前十片择。這其中有不少我們大家耳熟能詳的項目潜的，包括 JStorm, RocketMQ, FastJson, Druid, Weex，當然還有我們 Dubbo构回。其中 JStorm 和 RocketMQ 成為 Apache 的頂級項目夏块，而 Weex 和 Dubbo 也正在 Apache 中孵化疏咐。社區(qū)方面纤掸，Dubbo 這兩年疏于維護，很多開發(fā)者提交的 Pull Request 和 Issue 沒有得到及時的解決浑塞，一些公司不得不維護 Dubbo 私有分支借跪，版本分化嚴重，導致社區(qū)無法?分享這些分支上的成果酌壕。我們希望改變這一點掏愁，讓整個社區(qū)都能享受到開源的好處歇由。一個活躍的社區(qū)將會產生一個繁榮的生態(tài)，而一個繁榮的生態(tài)將會普惠所有使用 Dubbo 的人果港，最終形成社區(qū)和生態(tài)共同發(fā)展的良性循環(huán)沦泌。另外在阿里內部，負責 Dubbo 的團隊就是負責服務框架的團隊辛掠，我們在大流量谢谦、大規(guī)模集群、服務治理領域有著豐富的實踐萝衩，這些會有計劃地回饋給社區(qū)回挽。
這里強調一點，為了打消社區(qū)對 Dubbo 未來發(fā)展的顧慮猩谊，我們做出了把 Dubbo 捐獻給 Apache 基金會的決定千劈，并且在2018新年之前，Dubbo 正式進入 Apache 孵化牌捷。Apache 認為?社區(qū)的重要性大于代碼墙牌，非常注重多樣性，強調一個項目需要有多個公司和個人貢獻者參與暗甥，避免被一家公司左右憔古，所以現在 Dubbo 的發(fā)展完全是按 Apache Way 社區(qū)化的方式來運作的；個人貢獻者的參與方式可以是多種形式淋袖，除了貢獻代碼外鸿市，還可以通過報 Issue、增強文檔即碗、參與郵件討論等方式焰情；只要讓社區(qū)看到你的貢獻，你就可以一步一步從 Contributor 成為 Committer剥懒，再從 Committer 成為 PMC Member内舟。所以希望?大家多參與 Dubbo 的社區(qū)互動，多分享你們在實踐中的經驗初橘，反饋碰到的問題验游，只有你們的參與，Dubbo 的未來才有可能成功保檐。
這里順便分享下 Dubbo 進入 Apache 孵化的歷程耕蝉，希望對其他要把自己的項目捐獻給 Apache 的小伙伴們有幫助。進入 Apache 分為三個階段夜只，準備階段垒在、孵化階段和畢業(yè)階段。準備階段需要做的事情有找到愿意幫助孵化的導師扔亥，向 Apache 提交進入孵化的申請场躯，經過導師們討論并投票谈为，如果通過的話就可以進入孵化。孵化階段分為兩大環(huán)節(jié)踢关，第一個環(huán)節(jié)是公司和個人簽署協議向 Apache 移交代碼和知識產權伞鲫，目前 Dubbo 已經完成了第一個環(huán)節(jié)。之后就是在導師的指導下按照?Apache 的規(guī)范?做版本迭代签舞、運營社區(qū)榔昔、發(fā)展更多的 Committer，如果最終通過了成熟度評估瘪菌，就可以順利畢業(yè)成為 Apache 的頂級項目撒会。
開源現狀
Dubbo 開源的現狀我打算從數據、用戶师妙、項目?三個維度分別闡述诵肛。數據方面是這樣，從去年七月份重啟開源默穴，到目前為止怔檩，Dubbo 在 Github 上的 Star 數增長了 115% 達到了 1.9+ 萬，目前在 Github Java 類項目中排名第 7 位蓄诽，在去年開源中國舉辦的 2017 最受歡迎的開源項目中 Dubbo 和阿里巴巴其他三款軟件 FastJson薛训、Druid、RocketMQ 共同入選仑氛。
用戶方面 Dubbo 的用戶主要分為三類乙埃，第一類是以阿里巴巴、滴滴锯岖、當當為代表的互聯網企業(yè)介袜，第二類是向互聯網轉型的大型企業(yè)，如中國工商銀行出吹、中國電信和中國人壽等遇伞，第三類是使用 Dubbo 作為服務化方案的 ISV，包括亞信和文思捶牢。在這些企業(yè)中鸠珠，有些維護著自己的私有分支，有些企業(yè)的員工積極參與 Dubbo 的建設秋麸，在這次進入 Apache 孵化的過程中渐排，我們邀請了當當、去哪兒竹勉、微店的員工成為初始成員飞盆，6月份剛剛發(fā)展了有贊的一位開發(fā)者成為 Dubbo Committer娄琉。今年我們打算在北上廣深次乓、以及杭州等地舉辦幾次 Dubbo 開發(fā)者沙龍吓歇，這是第二站。沙龍的主題是面向工程師的票腰，包括架構分析城看、源碼解讀、未來規(guī)劃杏慰、案例分析等內容测柠，沒能來到現場的也沒有關系，整個沙龍會全程通過網絡直播缘滥。
這幾個月我們在 Dubbo 上的工作?圍繞一個目標?進行的轰胁，就是如何才能重新贏得社區(qū)的信任。為此我們首先要打好基礎朝扼，包括重新建設了網頁和文檔赃阀，全面更新了三方的依賴，在打好基礎的前提下擎颖，我們又確立了版本發(fā)布策略榛斯，采取特性版本和維護版本并行，每個月至少發(fā)布一個版本的節(jié)奏搂捧，迄今為止驮俗，我們已經發(fā)布了 7 個維護版本和 2 個特性版本。在這些版本中允跑，我們重點考慮了社區(qū)呼聲最高的特性王凑，其中就有 Spring Boot 的支持和對 REST 服務的支持。
下面這些事情是我們已經在進行中的聋丝，絕大多數都是我們后面要講的規(guī)劃中的事項荤崇，比如核心增強中的異步 API、Metrics潮针、熔斷术荤，生態(tài)中的多語言客戶端、Dubbo Mesh每篷，還有對 Dubbo OPS 的增強瓣戚；這里特別提一下 Dubbo OPS，現在我們已經將 OPS 中對 WebX 的依賴去除焦读，并基于 Spring Boot 2.0 進行了重新適配子库，代碼已經合并到主干；接下來還會將原先 Dubbo Admin 以及 Dubbo Monitor 進行合并矗晃，同時會適配更多的注冊中心 Registry仑嗅；另外我們在社區(qū)發(fā)起了關于全新 Logo 及官網的討論，目的是想通過全新官網的建設，更好的將文檔仓技、博客鸵贬、活動等信息呈現給社區(qū)和開發(fā)者，新的官網在設計開發(fā)中脖捻，接下來會上線阔逼，請大家保持關注。
最后總結一下地沮，Dubbo 重啟開源的這幾個月總的來說是成功的嗜浮，背后主要有兩點原因，一是公司層面的支持摩疑，其中有工程師團隊的努力危融，也有宣傳運營上的投入；二是依托Dubbo 的群眾基礎雷袋，我們這幾個月的工作重新贏得了社區(qū)的信任专挪，大家也開始關注 Dubbo 的發(fā)展。下面我會從核心和生態(tài)兩部分談下 Dubbo 未來規(guī)劃的?思考片排。
未來規(guī)劃
首先聊下規(guī)劃的?整體思路寨腔。Dubbo 后續(xù)的規(guī)劃主要是要?解決好兩個問題。第一個問題是未來出現的技術趨勢哪些是和 Dubbo 緊密相關的率寡，如果 Dubbo 不跟隨迫卢，就有可能在未來被淘汰的問題，第二個問題是 Dubbo 本身定位的問題冶共，也就是只做框架夠不夠的問題乾蛤。
關于第一個問題，我們看到的是越來越多的應用從單體架構轉向微服務架構捅僵，微服務的理念也深入人心家卖，還有就是各大云廠商開始宣傳云原生的概念，一些應用也開始向云上遷移庙楚，我們認為?微服務和?云原生?這兩個技術趨勢上值得 Dubbo 關注的上荡。
第二個問題 Dubbo 自身的定位，Dubbo 核心要保持技術上的領先性馒闷，我們會重點關注性能酪捡、大流量、大規(guī)模集群領域的挑戰(zhàn)纳账，但是光有這樣是遠遠不夠的逛薇，在保持核心演進的同時，我們還需要圍繞 Dubbo 核心發(fā)展生態(tài)疏虫，將 Dubbo 做成一個服務化改造的整體方案永罚。
Dubbo 核心的規(guī)劃又?分為三塊啤呼，第一塊包括模塊化和元數據，通過這兩塊的優(yōu)化來解決適應未來技術方向的問題呢袱，也就是微服務和云原生官扣，具體來說，目前 Dubbo 服務治理與網絡傳輸耦合嚴重产捞，通過進一步的模塊化工作可以為 Dubbo 成為服務網格中的數據面板做好準備醇锚，元數據目前既包含服務注冊信息哼御，也包含服務配置信息坯临，將兩者分離可以更清晰的分開注冊層和配置層，為適配微服務的注冊中心和配置中心?打好基礎恋昼。第二塊是關于我們如何把阿里在服務治理方面的經驗回饋給社區(qū)看靠，其中包括了這里的路由策略、大流量和大規(guī)模液肌，在路由策略中我們打算引入多機房路由挟炬、參數路由、灰度路由等策略嗦哆，在大流量方面?重點考慮?熔斷谤祖、限流、隔離的支持老速，在大規(guī)模集群方面需要解決超大規(guī)模地址列表對 CPU粥喜、內存帶來的壓力，最后一塊是進一步的增強異步化橘券，包括對 CompletableFuture 的支持以及跨進程 Reactive Stream 的預研额湘，目前 Reactive Stream 在內部 Dubbo 3.0 中正在孵化，壓測表明這項技術對于提升 CPU 利用率和系統(tǒng)的吞吐率很有幫助旁舰。
回想一下剛才的架構圖锋华，除了上面的兩層，下面的七層都是可擴展的箭窜。Dubbo 生態(tài)的建設我們的思路是利用核心的擴展能力盡可能多的提供開箱即用的擴展實現毯焕。這里我們按照架構圖中的層次劃分歸納了每一層可能提供的擴展實現。其中藍黑色的代表 Dubbo 框架已經支持的磺樱，綠色部分代表這次重啟開源之后新加入以及正在進行中的芥丧，而橙色的部分代表我們計劃在未來加入的。從下往上坊罢，我們看下未來會加入的支持续担，我們在序列化層計劃加入對 Protobuf 的支持，在 Transport 層加入對 Http2 的支持活孩，在 Protocol 層加入對 gRPC 的支持物遇，在 Cluster、Router、Load Balance 代表的服務治理層計劃加入阿里對服務治理方面的實踐询兴，其中包括了熔斷乃沙、多機房路由、灰度路由诗舰，以及更豐富的負載均衡策略警儒。再往上通過元數據的優(yōu)化，我們可以更清晰的分開注冊層和配置層眶根，從而可以在注冊層加入更多的對微服務注冊中心的支持蜀铲，比如 Eureka，Consul属百，在配置層也可以開始支持配置的動態(tài)推送记劝，當然在這兩層我們也會提供對阿里體系中的注冊中心 Config Server、配置中心 Diamond 的支持族扰，這兩個產品就是后續(xù)郭平老師給大家分享的 Nacos厌丑。最頂上是對 API 的支持，我們會做對 Spring Cloud 的適配渔呵。
我們有了不斷向前演進的核心怒竿，豐富的擴展生態(tài)，我們還需要解決 Dubbo 服務與外界互通的問題扩氢。這里的互通有兩方面的含義耕驰。第一是 Dubbo 服務與外圍系統(tǒng)互通，第二是異構系統(tǒng)如何調用 Dubbo 服務的問題类茂。首先說下外圍系統(tǒng)對接的問題耍属，外圍系統(tǒng)也分為兩類，圖中草綠色部分包括了 Dubbo OPS巩检、Test Server厚骗、Mock Server、 Swagger Server兢哭，無非就是解決服務如何查詢领舰，服務治理規(guī)則如何配置，如何測試服務迟螺，開發(fā)階段如何解決上下游依賴冲秽，服務的 API 支持等問題，這些問題與 Dubbo 服務緊密相關矩父，我們計劃自己來提供這方面的支持锉桑。再看圖中橙色的部分，包括了服務注冊中心窍株、配置中心民轴、鑒權中心攻柠，鏈路追蹤和監(jiān)控中心，這些系統(tǒng)外面有很多開源和商業(yè)的選擇后裸，我們的思路是盡可能多的提供與他們的適配瑰钮，為用戶帶來開箱急用的體驗。值得一提的是微驶，這一塊的建設是雙向的浪谴，目前 Spring Cloud Sleuth 主動支持了 Dubbo。談到異構系統(tǒng)如何調用 Dubbo 服務因苹，本質上是多語言支持的問題苟耻。要解決多語言調用，無非有兩種做法容燕，一種是通過代理方式來調用梁呈，代理根據部署形式的不同又分為中心化的 API Gateway 方式婚度，和本地部署的 Sidecar 方式蘸秘，Sidecar 方式我們在下張片子里進一步討論，對于 API Gateway 方式蝗茁，只需要 Dubbo 服務可以按照 Json-RPC 或者 REST 的方式暴露服務就好醋虏。另一種調用方式就是原生語言客戶端，要支持的語言包括了常用的 Python哮翘，Node颈嚼，Php，Go 等等饭寺，這一塊的挑戰(zhàn)和工作量都很大阻课，我們的思路是和社區(qū)共建。目前千米網的同學已經開始把他們的 Node 和 Python 的客戶端貢獻給社區(qū)艰匙。Go 和 Php 的版本也會很快提供限煞。
規(guī)劃的最后部分我想聊聊 Dubbo Mesh，剛才談到互通問題的時候员凝，解決多語言調用的一種方式是通過 Sidecar署驻，談到 Sidecar 就不得不從云原生講起。目前各大云計算廠商開始定義云原生健霹，鼓勵用戶將應用往云上遷移旺上。云原生的定義每家都不太一樣，但是其中可以看到有這么兩個趨勢糖埋。一個是云計算場景里多語言支持是強訴求宣吱，基于單一語言的架構和方案會有很大的局限性；另一個是原來與應用共生的服務治理能力開始從應用中解耦出來瞳别，并下沉為平臺的基礎能力征候，這樣做的好處是應用開發(fā)更簡單钦听、應用更輕、多語言支持也變得容易倍奢，服務治理能力可以透明升級朴上。這一塊就是 Linkerd 率先提出的服務網格的概念。Dubbo 通過進一步的模塊化工作卒煞，可以把服務治理能力單獨剝離出來獨立部署痪宰，成為服務網格中的數據面版，我們稱之為 Dubbo Mesh畔裕，它負責接管由本地所有 RPC 流量衣撬，并負責與外圍的注冊中心、配置中心對接扮饶。在服務網格下具练，一次 RPC 調用就會變成，左邊草綠色的 Dubbo RPC 發(fā)起一次調用甜无，請求會發(fā)給和他部署在一起的 Dubbo Mesh扛点，Dubbo Mesh 又會把這個 RPC 請求轉發(fā)到對端的 Dubbo Mesh，對端的 Dubbo Mesh 又會將收到的請求發(fā)給和他部署在一起的 Dubbo RPC, 也就是圖中右邊的橙色部分岂丘。服務網格上我們非常關注的一個方向陵究，目前我們正在做技術選型，相信很快就會有大家見面奥帘。
最后總結一下铜邮，通過核心、擴展寨蹋、互通三方面的建設松蒜，我們相信 Dubbo 體系可以成為服務化改造的國內首選方案，并且能夠很好的適應微服務和云原生這兩個技術趨勢已旧。
