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

摘要： 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 體系可以成為服務化改造的國內首選方案，并且能夠很好的適應微服務和云原生這兩個技術趨勢。

原文鏈接