Dubbo開源現狀與將來規劃

摘要： Dubbo 在過去一段時間疏於維護，去年阿里高調宣佈重啓 Dubbo 開源以後，社區裏問的最多的問題是，此次開源與上次有什麼同樣，還有就是 Dubbo 和 Spring Boot、Spring Cloud 是什麼關係？但願經過此次Dubbo沙龍的分享可以解答這些問題。

本文章是根據朱勇老師在上海Dubbo沙龍的演講稿進行整理，意在爲你們展現最真實、最一手的沙龍技術乾貨。

前言
你們好，很是榮幸有機會和你們作這個分享。我先作個自我介紹，我叫朱勇，來自阿里巴巴中間件團隊，主要工做在應用容器、微服務、RPC幾個領域。我是 09 年加入阿里，13年加入中間件團隊。

今天的話題是與 Dubbo 的開源現狀和將來規劃，咱們知道，Dubbo 過去一段時間疏於維護，去年阿里高調宣佈重啓 Dubbo 開源以後，社區裏問的最多的問題是，此次開源與上次有什麼同樣，還有就是 Dubbo 和 Spring Boot、Spring Cloud 是什麼關係？但願經過此次的分享可以解答這些問題。

此次分享包含如下幾個環節，Dubbo 基本原理、Dubbo 社區、開源現狀、以及後續規劃幾個部分。

Dubbo 工做原理
考慮到有些同窗可能對 Dubbo 不太熟悉，我先簡單介紹下 Dubbo 的工做原理和架構。簡單的說，Dubbo 是 基於 Java 的 RPC 框架。Dubbo 工做分爲 4 個角色，分別是服務提供者、服務消費者、註冊中心、和監控中心。按照工做階段又分爲部署階段和運行階段。其中部署階段在圖中以藍色的線來表示，表明服務註冊、服務訂閱的過程，而運行階段在圖中以紅色的線來表示，表明一次 RPC 的完整調用。部署階段中服務提供方在啓動時在指定的端口上暴露服務，並向註冊中心彙報本身的地址，服務調用方啓動時向註冊中心訂閱本身感興趣的服務。運行階段註冊中心先將地址列表推送給服務消費者，服務消費者選取一個地址向對端發起調用。在這個過程當中，服務消費者和服務提供者的運行狀態會上報給監控中心。

其實，這裏講的基本原理套用到任何一個成熟的服務框架都是合適的，可是 Dubbo 在框架設計上有着本身的設計哲學。

這裏是 Dubbo 的總體架構圖。首先這張圖看起來很複雜、信息量很大。我先介紹一下這張圖的解讀方式。這張圖從左往右看，分爲兩部分，左半邊藍色背景的部分表明服務消費者，右半邊綠色背景的部分表明服務提供者。從上往下看又分爲九層。左邊九層按功能來劃分又被分爲了三大類，分別是面向用戶的 Biz 層、框架核心 RPC 以及負責遠程傳輸的 Remoting，右邊按面向人羣又劃分爲了兩類，上面兩層是面向用戶的 API，而下面七層是面向擴展提供者的 SPI。圖中的線表明對象與對象之間不一樣的關係，紫色表明繼承；黑色表明依賴；藍色虛線表明服務註冊、服務訂閱的過程，也就是上面講的部署階段；紅色表明一次完整的 RPC 調用，也就是運行階段。咱們順着紅色的線，來看下一次完整的 RPC 調用是如何進行的。首先從圖的左邊開始，服務消費者從 Proxy 層發起一次 RPC 調用，Dubbo 從 Registry 層拿到服務的地址列表，再經過 Cluster 層選擇其中的一個做爲目標地址，再流經 Protocol 決定的執行鏈，最後將服務信息，包括要調用的服務名、方法名、參數等序列化，再通過應用協議編碼，經過 Transport 層發送到網絡上。右邊的服務提供者從網絡上收到數據之後，從下往上，依次經過應用協議解碼、反序列化獲得要調用的服務信息，再經由執行鏈，最終經過 Invoker 找到目標服務的目標方法，執行並返回結果。解讀完 Dubbo 的架構圖，再來看看架構圖中體現的設計原則。Dubbo 秉承高內聚、低耦合的設計，這一點體如今架構圖中九層的清晰劃分上，而且也體如今依賴的方向上。黑色的線條的方向永遠是從上指向下，沒有循環依賴和反向依賴的出現。Dubbo 還有一個很重要的設計哲學就是平等對待第三方的擴展，即 Dubbo 內建的功能也是經過一樣的擴展機制提供出來的，第三方的擴展和內建功能能夠相互取代。正是因爲 Dubbo 將第三方擴展當成框架的一等公民，爲將來基於這個機制創建生態帶來了可能性。這一點，咱們在後面規劃部分進一步展開。

Dubbo 社區
Dubbo 社區，我想從戰略、社區、生態和回饋四個方面講一講。首先阿里巴巴將開源提到了新的戰略高度，去年雲棲大會上阿里雲宣佈了加大技術投入、擁抱開源的策略。阿里巴巴在開源領域耕耘多年，目前在 Github 上有 150 多個開源項目，總 Star 數在 17 萬，而且 Alibaba 這個 Group 在全球的排名進入前十。這其中有很多咱們你們耳熟能詳的項目，包括 JStorm, RocketMQ, FastJson, Druid, Weex，固然還有咱們 Dubbo。其中 JStorm 和 RocketMQ 成爲 Apache 的頂級項目，而 Weex 和 Dubbo 也正在 Apache 中孵化。社區方面，Dubbo 這兩年疏於維護，不少開發者提交的 Pull Request 和 Issue 沒有獲得及時的解決，一些公司不得不維護 Dubbo 私有分支，版本分化嚴重，致使社區沒法 分享這些分支上的成果。咱們但願改變這一點，讓整個社區都能享受到開源的好處。一個活躍的社區將會產生一個繁榮的生態，而一個繁榮的生態將會普惠全部使用 Dubbo 的人，最終造成社區和生態共同發展的良性循環。另外在阿里內部，負責 Dubbo 的團隊就是負責服務框架的團隊，咱們在大流量、大規模集羣、服務治理領域有着豐富的實踐，這些會有計劃地回饋給社區。

這裏強調一點，爲了打消社區對 Dubbo 將來發展的顧慮，咱們作出了把 Dubbo 捐獻給 Apache 基金會的決定，而且在2018新年以前，Dubbo 正式進入 Apache 孵化。Apache 認爲 社區的重要性大於代碼，很是注重多樣性，強調一個項目須要有多個公司和我的貢獻者參與，避免被一家公司左右，因此如今 Dubbo 的發展徹底是按 Apache Way 社區化的方式來運做的；我的貢獻者的參與方式能夠是多種形式，除了貢獻代碼外，還能夠經過報 Issue、加強文檔、參與郵件討論等方式；只要讓社區看到你的貢獻，你就能夠一步一步從 Contributor 成爲 Committer，再從 Committer 成爲 PMC Member。因此但願 你們多參與 Dubbo 的社區互動，多分享大家在實踐中的經驗，反饋碰到的問題，只有大家的參與，Dubbo 的將來纔有可能成功。

這裏順便分享下 Dubbo 進入 Apache 孵化的歷程，但願對其餘要把本身的項目捐獻給 Apache 的小夥伴們有幫助。進入 Apache 分爲三個階段，準備階段、孵化階段和畢業階段。準備階段須要作的事情有找到願意幫助孵化的導師，向 Apache 提交進入孵化的申請，通過導師們討論並投票，若是經過的話就能夠進入孵化。孵化階段分爲兩大環節，第一個環節是公司和我的簽署協議向 Apache 移交代碼和知識產權，目前 Dubbo 已經完成了第一個環節。以後就是在導師的指導下按照 Apache 的規範 作版本迭代、運營社區、發展更多的 Committer，若是最終經過了成熟度評估，就能夠順利畢業成爲 Apache 的頂級項目。

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

用戶方面 Dubbo 的用戶主要分爲三類，第一類是以阿里巴巴、滴滴、噹噹爲表明的互聯網企業，第二類是向互聯網轉型的大型企業，如中國工商銀行、中國電信和中國人壽等，第三類是使用 Dubbo 做爲服務化方案的 ISV，包括亞信和文思。在這些企業中，有些維護着本身的私有分支，有些企業的員工積極參與 Dubbo 的建設，在此次進入 Apache 孵化的過程當中，咱們邀請了噹噹、去哪兒、微店的員工成爲初始成員，6月份剛剛發展了有讚的一位開發者成爲 Dubbo Committer。今年咱們打算在北上廣深、以及杭州等地舉辦幾回 Dubbo 開發者沙龍，這是第二站。沙龍的主題是面向工程師的，包括架構分析、源碼解讀、將來規劃、案例分析等內容，沒能來到現場的也沒有關係，整個沙龍會全程經過網絡直播。

這幾個月咱們在 Dubbo 上的工做 圍繞一個目標 進行的，就是如何才能從新贏得社區的信任。爲此咱們首先要打好基礎，包括從新建設了網頁和文檔，全面更新了三方的依賴，在打好基礎的前提下，咱們又確立了版本發佈策略，採起特性版本和維護版本並行，每月至少發佈一個版本的節奏，迄今爲止，咱們已經發布了 7 個維護版本和 2 個特性版本。在這些版本中，咱們重點考慮了社區呼聲最高的特性，其中就有 Spring Boot 的支持和對 REST 服務的支持。

下面這些事情是咱們已經在進行中的，絕大多數都是咱們後面要講的規劃中的事項，好比核心加強中的異步 API、Metrics、熔斷，生態中的多語言客戶端、Dubbo Mesh，還有對 Dubbo OPS 的加強；這裏特別提一下 Dubbo OPS，如今咱們已經將 OPS 中對 WebX 的依賴去除，並基於 Spring Boot 2.0 進行了從新適配，代碼已經合併到主幹；接下來還會將原先 Dubbo Admin 以及 Dubbo Monitor 進行合併，同時會適配更多的註冊中心 Registry；另外咱們在社區發起了關於全新 Logo 及官網的討論，目的是想經過全新官網的建設，更好的將文檔、博客、活動等信息呈現給社區和開發者，新的官網在設計開發中，接下來會上線，請你們保持關注。

最後總結一下，Dubbo 重啓開源的這幾個月總的來講是成功的，背後主要有兩點緣由，一是公司層面的支持，其中有工程師團隊的努力，也有宣傳運營上的投入；二是依託Dubbo 的羣衆基礎，咱們這幾個月的工做從新贏得了社區的信任，你們也開始關注 Dubbo 的發展。下面我會從核心和生態兩部分談下 Dubbo 將來規劃的 思考。

將來規劃
首先聊下規劃的 總體思路。Dubbo 後續的規劃主要是要 解決好兩個問題。第一個問題是將來出現的技術趨勢哪些是和 Dubbo 緊密相關的，若是 Dubbo 不跟隨，就有可能在將來被淘汰的問題，第二個問題是 Dubbo 自己定位的問題，也就是隻作框架夠不夠的問題。

關於第一個問題，咱們看到的是愈來愈多的應用從單體架構轉向微服務架構，微服務的理念也深刻人心，還有就是各大雲廠商開始宣傳雲原生的概念，一些應用也開始向雲上遷移，咱們認爲 微服務 和 雲原生 這兩個技術趨勢上值得 Dubbo 關注的。

第二個問題 Dubbo 自身的定位，Dubbo 核心要保持技術上的領先性，咱們會重點關注性能、大流量、大規模集羣領域的挑戰，可是光有這樣是遠遠不夠的，在保持核心演進的同時，咱們還須要圍繞 Dubbo 核心發展生態，將 Dubbo 作成一個服務化改造的總體方案。

Dubbo 核心的規劃又 分爲三塊，第一塊包括模塊化和元數據，經過這兩塊的優化來解決適應將來技術方向的問題，也就是微服務和雲原生，具體來講，目前 Dubbo 服務治理與網絡傳輸耦合嚴重，經過進一步的模塊化工做能夠爲 Dubbo 成爲服務網格中的數據面板作好準備，元數據目前既包含服務註冊信息，也包含服務配置信息，將二者分離能夠更清晰的分開註冊層和配置層，爲適配微服務的註冊中心和配置中心 打好基礎。第二塊是關於咱們如何把阿里在服務治理方面的經驗回饋給社區，其中包括了這裏的路由策略、大流量和大規模，在路由策略中咱們打算引入多機房路由、參數路由、灰度路由等策略，在大流量方面 重點考慮 熔斷、限流、隔離的支持，在大規模集羣方面須要解決超大規模地址列表對 CPU、內存帶來的壓力，最後一塊是進一步的加強異步化，包括對 CompletableFuture 的支持以及跨進程 Reactive Stream 的預研，目前 Reactive Stream 在內部 Dubbo 3.0 中正在孵化，壓測代表這項技術對於提高 CPU 利用率和系統的吞吐率頗有幫助。

回想一下剛纔的架構圖，除了上面的兩層，下面的七層都是可擴展的。Dubbo 生態的建設咱們的思路是利用核心的擴展能力盡量多的提供開箱即用的擴展實現。這裏咱們按照架構圖中的層次劃分概括了每一層可能提供的擴展實現。其中藍黑色的表明 Dubbo 框架已經支持的，綠色部分表明此次重啓開源以後新加入以及正在進行中的，而橙色的部分表明咱們計劃在將來加入的。從下往上，咱們看下將來會加入的支持，咱們在序列化層計劃加入對 Protobuf 的支持，在 Transport 層加入對 Http2 的支持，在 Protocol 層加入對 gRPC 的支持，在 Cluster、Router、Load Balance 表明的服務治理層計劃加入阿里對服務治理方面的實踐，其中包括了熔斷、多機房路由、灰度路由，以及更豐富的負載均衡策略。再往上經過元數據的優化，咱們能夠更清晰的分開註冊層和配置層，從而能夠在註冊層加入更多的對微服務註冊中心的支持，好比 Eureka，Consul，在配置層也能夠開始支持配置的動態推送，固然在這兩層咱們也會提供對阿里體系中的註冊中心 Config Server、配置中心 Diamond 的支持，這兩個產品就是後續郭平老師給你們分享的 Nacos。最頂上是對 API 的支持，咱們會作對 Spring Cloud 的適配。

咱們有了不斷向前演進的核心，豐富的擴展生態，咱們還須要解決 Dubbo 服務與外界互通的問題。這裏的互通有兩方面的含義。第一是 Dubbo 服務與外圍系統互通，第二是異構系統如何調用 Dubbo 服務的問題。首先說下外圍系統對接的問題，外圍系統也分爲兩類，圖中草綠色部分包括了 Dubbo OPS、Test Server、Mock Server、 Swagger Server，無非就是解決服務如何查詢，服務治理規則如何配置，如何測試服務，開發階段如何解決上下游依賴，服務的 API 支持等問題，這些問題與 Dubbo 服務緊密相關，咱們計劃本身來提供這方面的支持。再看圖中橙色的部分，包括了服務註冊中心、配置中心、鑑權中心，鏈路追蹤和監控中心，這些系統外面有不少開源和商業的選擇，咱們的思路是儘量多的提供與他們的適配，爲用戶帶來開箱急用的體驗。值得一提的是，這一塊的建設是雙向的，目前 Spring Cloud Sleuth 主動支持了 Dubbo。談到異構系統如何調用 Dubbo 服務，本質上是多語言支持的問題。要解決多語言調用，無非有兩種作法，一種是經過代理方式來調用，代理根據部署形式的不一樣又分爲中心化的 API Gateway 方式，和本地部署的 Sidecar 方式，Sidecar 方式咱們在下張片子裏進一步討論，對於 API Gateway 方式，只須要 Dubbo 服務能夠按照 Json-RPC 或者 REST 的方式暴露服務就好。另外一種調用方式就是原生語言客戶端，要支持的語言包括了經常使用的 Python，Node，Php，Go 等等，這一塊的挑戰和工做量都很大，咱們的思路是和社區共建。目前公里網的同窗已經開始把他們的 Node 和 Python 的客戶端貢獻給社區。Go 和 Php 的版本也會很快提供。

規劃的最後部分我想聊聊 Dubbo Mesh，剛纔談到互通問題的時候，解決多語言調用的一種方式是經過 Sidecar，談到 Sidecar 就不得不從雲原生講起。目前各大雲計算廠商開始定義雲原生，鼓勵用戶將應用往雲上遷移。雲原生的定義每家都不太同樣，可是其中能夠看到有這麼兩個趨勢。一個是雲計算場景裏多語言支持是強訴求，基於單一語言的架構和方案會有很大的侷限性；另外一個是原來與應用共生的服務治理能力開始從應用中解耦出來，並下沉爲平臺的基礎能力，這樣作的好處是應用開發更簡單、應用更輕、多語言支持也變得容易，服務治理能力能夠透明升級。這一塊就是 Linkerd 率先提出的服務網格的概念。Dubbo 經過進一步的模塊化工做，能夠把服務治理能力單獨剝離出來獨立部署，成爲服務網格中的數據面版，咱們稱之爲 Dubbo Mesh，它負責接管由本地全部 RPC 流量，並負責與外圍的註冊中心、配置中心對接。在服務網格下，一次 RPC 調用就會變成，左邊草綠色的 Dubbo RPC 發起一次調用，請求會發給和他部署在一塊兒的 Dubbo Mesh，Dubbo Mesh 又會把這個 RPC 請求轉發到對端的 Dubbo Mesh，對端的 Dubbo Mesh 又會將收到的請求發給和他部署在一塊兒的 Dubbo RPC, 也就是圖中右邊的橙色部分。服務網格上咱們很是關注的一個方向，目前咱們正在作技術選型，相信很快就會有你們見面。

最後總結一下，經過核心、擴展、互通三方面的建設，咱們相信 Dubbo 體系能夠成爲服務化改造的國內首選方案，而且可以很好的適應微服務和雲原生這兩個技術趨勢。

原文連接