本文章是根據朱勇老師在上海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 體系可以成為服務化改造的國內首選方案，並且能夠很好的適應微服務和雲原生這兩個技術趨勢。

--------------------- 本文來自 阿里云云棲社群 的CSDN 部落格 ，全文地址請點選：https://blog.csdn.net/yunqiinsight/article/details/80927484?utm_source=copy