北京沙龍報名 | 關於Dubbo開源的那些事兒

自從去年7月份阿里宣布重啟Dubbo維護以後，開源社區熱度最高的兩個問題：一是這次開源和以前有什麼不一樣的地方？二是阿里的Dubbo和Spring Boot、 Spring Cloud 是什麼關係？

2018年5月12日（周六），我們將在北京舉行Dubbo開發者沙龍暨第四屆阿里中間件性能挑戰賽技術行，為你答疑解惑。免費報名活動，名額有限，先到先得哦。

Dubbo是阿里巴巴自研的分散式服務框架，自2012年開源以來，深得開發人員的喜愛，並被廣泛用於服務化解決方案中。自去年阿里巴巴中間件團隊宣布重啟維護後，在社區引起極大的反響，目前在github上的star數增加至18000，並於2018年2月正式加入Apache孵化器進行孵化。本次沙龍，將為大家介紹近期Dubbo所完成的一些工作及未來規劃，並對第四屆中間件性能挑戰賽賽題「挑戰Dubbo Agent」做出詳細解讀。

還不了解Dubbo的童鞋，下面讓我們一起來深入學習。

Dubbo 的基本原理

簡單的說，Dubbo是基於Java的RPC框架。如圖所示，Dubbo工作分為4個角色，分別是服務提供者、服務消費者、註冊中心、和監控中心。

按照工作階段又分為部署階段和運行階段。其中部署階段在圖中以藍色的線來表示，代表服務註冊、服務訂閱的過程，而運行階段在圖中以紅色的線來表示，代表一次RPC的完整調用。部署階段中服務提供方在啟動時在制定的埠上暴露服務，並向註冊中心彙報自身的地址，服務調用方啟動時向註冊中心訂閱感興趣的地址。運行階段中註冊中心首先將地址列表推送給服務消費者，服務消費者從其中選取一個地址向對端發起調用。在這個過程中，服務消費者和服務提供者的運行狀態會上報給監控中心。

從Dubbo的整體架構圖來看，這張圖從左往右看，分為兩部分，左半邊藍色背景的部分代表服務消費者，右半邊綠色背景的部分代表服務提供者。從上往下看又分為九層。看左邊，九層按功能來劃分又被分為了三大類，分別是面向用戶的 biz，框架核心 RPC 以及負責遠程傳輸的 Remoting，看圖的右邊按面向人群又劃分為了兩類，上面兩層是面向用戶的API，而下面七層是面向擴展提供者的SPI。

圖中的線代表對象與對象之間不同的關係，紫色代表繼承、黑色代表依賴、藍色虛線代表服務註冊、服務訂閱的過程，也就是上面講的部署階段，紅色代表一次完整的RPC調用，也就是運行階段。順著紅色的線，可以體驗一次完整的 RPC 調用是如何進行的。

首先從圖的左邊開始，用戶從 Proxy 層發起一次RPC調用，Dubbo 從 Registry 層拿到服務的地址列表，再通過 Cluster 層選擇其中的一個作為目標地址，再流經Protocol 決定的執行鏈，最後將服務信息，包括要調用的服務名、方法名、參數等序列化，再經過應用協議編碼，通過 Transport 層發送到網路上。右邊的服務提供者從網路上收到數據以後，從下往上，依次通過應用協議解碼、反序列化得到要調用的服務信息，再經由執行鏈，最終通過 Invoker 找到目標服務的目標方法，執行並返回結果。

解讀完Dubbo的架構圖，再來看看架構圖中體現的設計原則。

Dubbo秉承高內聚、低耦合的設計，這一點體現在架構圖中九層的清晰劃分上，也體現在依賴的方向上。線條的方向永遠是從上指向下，沒有循環依賴和反向依賴的出現。Dubbo還有一個很重要的設計哲學就是平等對待第三方的擴展，即Dubbo內建的功能也是通過同樣的擴展機制提供出來的，第三方的擴展和內建功能可以相互取代。正是由於Dubbo將第三方擴展當成框架的一等公民，為未來基於這個機制建立生態帶來了可能性。

Dubbo 開源的現狀

從數據維度來看，去年7月重啟至今，Dubbo 在 github 上的 star 數增長了 77% ，達到了 1.8 萬，目前在 github java 類項目中排名 11 位，在去年開源中國舉辦的2017最受歡迎的開源項目中 Dubbo 和阿里巴巴其他三款軟體 fastjson、druid、rocketmq 共同入選。

從用戶來看，主要有3種類型，第一類是以阿里巴巴，滴滴，噹噹為代表的互聯網企業；第二類是向互聯網轉型的大型企業，其中有中國工商銀行、中國電信和中國人壽；第三類是使用Dubbo作為服務化方案的 ISV，如亞信，文思。這些企業中，有一些維護著自己的私有分支，有些企業的員工積极參与Dubbo的建設，在這次進入Apache孵化的過程中，噹噹、去哪兒、微店的員工成為了初始成員。5月12日，Dubbo將在北京車庫咖啡舉行首次線下沙龍。

Dubbo 未來規劃與進入 Apache 孵化

Dubbo 後續規劃主要圍繞技術趨勢與自身定位兩塊：從技術趨勢來看，主要包含3個方面：

第一方面：模塊化和元數據。通過這兩塊的優化來解決適應未來技術方向的問題，也就是微服務和雲原生，具體來說，目前 Dubbo 服務治理與網路傳輸耦合嚴重，通過進一步的模塊化工作可以為 Dubbo 成為服務網格中的數據面板做好準備，元數據目前即包含服務註冊信息，也包含服務配置信息，將兩者分離可以更清晰地分開註冊層和配置層，為適配微服務的註冊中心和配置中心打好基礎。

第二方面：如何將阿里在服務治理方面的經驗回饋給社區。其中包括了路由策略、大流量和大規模，在路由策略中阿里打算引入多機房路由、參數路由、灰度路由等策略，在大流量方面重點考慮熔斷、限流、隔離的支持，在大規模集群方面需要解決超大規模地址列表對CPU、內存帶來的壓力。

第三方面：增強非同步化。包括對 CompletableFuture 的支持以及跨進程 Reactive Stream 的預研，目前 Reactive Stream 在 Dubbo 3.0 中正在孵化，壓測表明這項技術對於提升 CPU 利用率和系統的吞吐率有極大幫助。

Dubbo進入Apache孵化的歷程，分為三個階段：準備階段、孵化階段和畢業階段。

目前Dubbo已經完成了第一個環節，之後就是在導師的指導下按照Apache的規範做版本迭代、運營社區、發展更多的committer，如果最終通過了成熟度評估，就可以順利畢業成為Apache的頂級項目。