本文轉自：阿里巴巴中間件
自從去年7月份阿里宣佈重啟Dubbo開源以來，開源社區熱度最高的兩個問題：一是這次開源和以前有什麼不一樣的地方？二是阿里的Dubbo和Spring boot、 Spring cloud 是什麼關係？
阿里巴巴高級技術專家，Dubbo開源項目負責人羅毅在Qcon全球軟件開發者大會上分享了Dubbo的現狀與未來規劃，以及Dubbo進入Apache孵化的歷程。
Dubbo的基本原理
簡單的說，Dubbo是基於Java的RPC框架。如圖所示，Dubbo工作分為4個角色，分別是服務提供者、服務消費者、註冊中心和監控中心。
Dubbo 工作原理
按照工作階段又分為部署階段和運行階段。其中部署階段在圖中以藍色的線來表示，代表服務註冊、服務訂閱的過程，而運行階段在圖中以紅色的線來表示，代表一次RPC的完整調用。部署階段中服務提供方在啟動時在制定的端口上暴露服務，並向註冊中心彙報自身的地址，服務調用方啟動時向註冊中心訂閱感興趣的地址。運行階段中註冊中心首先將地址列表推送給服務消費者，服務消費者從其中選取一個地址向對端發起調用。在這個過程中，服務消費者和服務提供者的運行狀態會上報給監控中心。
Dubbo 整體架構圖
從Dubbo的整體架構圖來看，從左往右分為兩部份，左半邊藍色背景的部分代表服務消費者，右半邊綠色背景的部分代表服務提供者。從上往下看又分為九層，左邊九層按功能來劃分又被分為了三大類，分別是面向用戶的 biz，框架核心 RPC 以及負責遠程傳輸的 Remoting，圖的右邊按面向人群又劃分為了兩類，上面兩層是面向用戶的API，而下面七層是面向擴展提供者的SPI。
圖中的線代表對象與對象之間不同的關係，紫色代表繼承、黑色代表依賴、藍色虛線代表服務註冊、服務訂閱的過程，也就是上面講的部署階段，紅色代表一次完整的RPC調用，也就是運行階段。順著紅色的線，可以體驗一次完整的 rpc 調用是如何進行的。
首先從圖的左邊開始，用戶從 Proxy 層發起一次RPC調用，Dubbo 從 Registry 層拿到服務的地址列表，再通過 Cluster 層選擇其中的一個作為目標地址，再流經 Protocol 決定的執行鏈，最後將服務信息，包括要調用的服務名、方法名、參數等序列化，再經過應用協議編碼，通過 Transport 層發送到網絡上。右邊的服務提供者從網絡上收到數據以後，從下往上，依次通過應用協議解碼、反序列化得到要調用的服務信息，再經由執行鏈，最終通過 Invoker 找到目標服務的目標方法，執行並返回結果。
解讀完Dubbo的架構圖，再來看看架構圖中體現的設計原則。Dubbo秉承高內聚、低耦合的設計，這一點體現在架構圖中九層的清晰劃分上，也體現在依賴的方向上。線條的方向永遠是從上指向下，沒有循環依賴和反向依賴的出現。Dubbo還有一個很重要的設計哲學就是平等對待第三方的擴展，即Dubbo內建的功能也是通過同樣的擴展機制提供出來的，第三方的擴展和內建功能可以相互取代。正是由於Dubbo將第三方擴展當成框架的一等公民，為未來基於這個機制建立生態帶來了可能性。
重啟開源的緣由
Dubbo重啟開源的緣由主要有四個方面：戰略、社區、生態和回饋。
首先阿里巴巴將開源提到了新的戰略高度，去年雲棲大會上阿里雲宣佈了加大技術投入、擁抱開源的策略。阿里巴巴在開源領域耕耘多年，目前在 GitHub 上有 150 個開源項目，總 star 數超過 19 萬 ，在全球的排名前十。這其中有不少大家耳熟能詳的項目，包括 jstorm, rocketmq, fastjson, druid, weex，當然還有 Dubbo。其中 jstorm 和 rocketmq 成為 apache 的頂級項目，而 weex 和 dubbo 也正在 apache 中孵化。阿里，尤其是阿里雲，有意願成為一家科技公司，保持在開源上的領先，打造技術影響力，並最終幫助到企業的生意。
從社區來看，這兩年由於疏於維護，社區提交的 pull request 和問題沒有得到及時的解決，一些公司不得不開始自己維護dubbo的私有分支，版本分化嚴重，社區無法分享這些分支上的工作。所以，Dubbo希望與社區進一步的互動，同時激發 Dubbo 團隊的產品靈感。
眾所周知，一個活躍的社區必將產生一個繁榮的生態，而一個繁榮的生態將會普惠所有使用 Dubbo 的人，更重要的是，其中收益最大的將會是Dubbo本身，畢竟很多有趣的想法單單靠單一團隊的力量是無法提供的，需要開發者們共同推動。目前Dubbo團隊就是阿里巴巴內部負責服務框架的團隊，在大流量、大規模集群、服務治理領域有著豐富的實踐，未來也將回饋給社區。
Dubbo 開源的現狀
從數據維度來看，7月重啟至今，Dubbo 在 github 上的 star 數增長了 115%，超過了1.9 萬，目前在 GitHub java 類項目中排名 7 位，在去年開源中國舉辦的2017最受歡迎的開源項目中 Dubbo 和阿里巴巴其他三款軟件 fastjson、druid、rocketmq 共同入選。
從用戶來看，主要有3種類型，第一類是以阿里巴巴，滴滴，噹噹為代表的互聯網企業；第二類是向互聯網轉型的大型企業 ，其中有中國工商銀行、中國電信和中國人壽；第三類是使用dubbo作為服務化方案的 ISV，如亞信，文思。這些企業中，有一些維護著自己的私有分支，有些企業的員工積極參與Dubbo的建設，在這次進入apache孵化的過程中，噹噹、去哪兒、微店的員工成為了初始成員。今年我們將在北上廣深、及杭州舉辦幾場Dubbo開發者沙龍，將為工程師們分享架構分析、源碼解讀、未來規劃、案例分析等內容，最近的一次將在6月23日上海浦東創新港舉行。
如何才能重新贏得社區的信任成為Dubbo重啟開源的重要目標，為此重新建設了網頁和文檔，全面更新了三方的依賴，在打好基礎的前提下，又確立了版本發佈策略，採取特性版本和維護版本並行，每個月至少發佈一個版本。迄今為止，已經發布了7個維護版本和2個特性版本。在這些版本中，重點考慮了社區呼聲最高的特性，其中就有 對spring boot 和對 REST 服務的支持。最後，為了打消社區對Dubbo未來發展的顧慮，阿里做出了將Dubbo捐獻給Apache基金會的決定。
Dubbo的未來規劃
Dubbo 後續規劃主要圍繞技術趨勢與自身定位兩塊：從技術趨勢來看，主要包含3個方面：
第一方面：模塊化和元數據。通過這兩塊的優化來解決適應未來技術方向的問題，也就是微服務和雲原生，具體來說，目前 Dubbo 服務治理與網絡傳輸耦合嚴重，通過進一步的模塊化工作可以為 Dubbo 成為服務網格中的數據面板做好準備。元數據目前既包含服務註冊信息，也包含服務配置信息，將兩者分離可以更清晰的分開註冊層和配置層，為適配微服務的註冊中心和配置中心打好基礎。
第二方面：如何將阿里在服務治理方面的經驗回饋給社區。其中包括了路由策略、大流量和大規模，在路由策略中阿里打算引入多機房路由、參數路由、灰度路由等策略，在大流量方面重點考慮熔斷、限流、隔離的支持，在大規模集群方面需要解決超大規模地址列表對CPU、內存帶來的壓力。
第三方面：增強異步化。 包括對 CompletableFuture 的支持以及跨進程 Reactive Stream 的預研，目前 Reactive Stream 在 Dubbo 3.0 中正在孵化，壓測表明這項技術對於提升 CPU 利用率和系統的吞吐率有極大幫助。
從生態建設來看，就是利用核心的擴展能力盡可能多的提供開箱即用的擴展實現。按照架構圖中的層次劃分歸納了每一層可能提供的擴展實現。其中藍黑色的代表Dubbo框架已經支持的，綠色部分代表這次重啟開源之後新加入的，而橙色的部分代表我們計劃在未來加入的。從下往上，未來在序列化層計劃加入對 Protobuf 的支持，在 Transport 層加入對 HTTP2 的支持，在 Protocol 層加入對 gRPC 的支持，在 cluster、router、loadbalance 代表的服務治理層計劃加入阿里對服務治理方面的實踐。
再往上通過元數據的優化，可以更清晰的分開註冊層和配置層，從而可以在註冊層加入更多的對微服務註冊中心的支持，比如 eureka，consule，在配置層也可以開始支持配置的動態推送，在這兩層會提供對阿里體系中的註冊中心 config server、配置中心 diamond 的支持。最頂上是對 API 的支持，對 Spring Cloud 的適配。
生態建設的另一方面是要解決 dubbo 服務與外界互通的問題。這裡的互通有兩方面的含義。第一是 Dubbo 服務與外圍系統互通，第二是異構系統如何調用Dubbo服務的問題。
外圍系統也分為兩類，圖中草綠色部分包括了 Dubob admin, test server, mock server, swagger server，無非就是解決服務如何查詢，服務治理規則如何配置，如何測試服務，開發階段如何解決上下游依賴，服務的 API 支持等問題，這些問題與Dubbo服務緊密相關，後續計劃提供這方面的支持。
從圖中橙色的部分來看，包括了服務註冊中心、配置中心、鑑權中心，鏈路追蹤和監控中心，這些系統也有很多開源和商業的選擇，Dubbo的思路是儘可能多的提供適配性來為用戶帶來開箱即用的體驗。
值得一提的是，這一塊的建設是雙向的，目前 spring cloud sleuth 主動支持了 Dubbo。談到異構系統如何調用Dubbo服務，本質上是多語言支持的問題。要解決多語言調用，無非有兩種做法，一種是通過代理方式來調用，代理根據部署形式的不同又分為中心化的 api gateway 方式和本地部署的 sidecar 方式。對於 api gateway 方式，只需要 Dubbo 服務可以按照 json-rpc 或者 rest 的方式暴露服務就好。另一種調用方式就是原生語言客戶端，要支持的語言包括了常用的 python，node，php，go 等等。
通過核心、生態、互通三方面的建設，Dubbo體系可以成為服務化改造的國內首選方案，並且能夠很好的適應微服務，雲原生這兩個技術趨勢。
最後從雲原生來看，Dubbo Mesh成為了重點。目前各大雲計算廠商開始定義雲原生，鼓勵用戶將應用往雲上遷移。雲原生的定義每家都不太一樣，但是其中可以看到有這麼兩個趨勢。一個是雲計算場景裡多語言支持是強訴求，基於單一語言的架構和方案會有很大的侷限性，這可能也是 Spring Cloud 體系的短板，另一個是原來與應用共生的服務治理能力開始從應用中解耦出來，並下沉為平臺的基礎能力，這樣做的好處是應用開發更簡單、應用更輕、多語言支持也變得容易。這一塊就是 linkerd 率先提出的服務網格的概念。
Dubbo 通過進一步的模塊化工作，可以把服務治理能力單獨剝離出來獨立部署，成為服務網格中的數據面板，被稱之為 Dubbo mesh，它負責接管由本地所有rpc流量，並負責與外圍的註冊中心、配置中心對接。在服務網格下，一次RPC調用就會變成， 左邊草綠色的 Dubbo rpc 發起一次調用，請求會發給和部署在一起的 Dubbo mesh，Dubbo mesh 又會把這個 rpc 請求轉發到對端的 Dubbo mesh，對端的 Dubbo mesh 又會將收到的請求發給對端的 Dubbo rpc, 也就是圖中右邊的橙色部分。
Dubbo進入apache孵化的歷程，分為三個階段：
準備階段、孵化階段和畢業階段。
Apache 孵化階段
準備階段，要找到願意幫助孵化的導師，向apache提交進入孵化的申請，經過導師們討論並投票，如果通過的話就可以進入孵化。孵化階段分為兩大環節，第一個環節是公司和個人簽署協議向apache移交代碼和知識產權，目前Dubbo已經完成了第一個環節，之後就是在導師的指導下按照apache的規範做版本迭代、運營社區、發展更多的committer，如果最終通過了成熟度評估，就可以順利畢業成為apache的頂級項目。
阿里巴巴中間件是阿里巴巴集團最強悍的技術部門之一，支持集團99%以上的大規模應用及世界最大電商交易場景——雙11；擁有Apache Dubbo、Apache RocketMQ等頂級開源項目；為政府央企、智能製造、新金融等眾多領域提供領先的PaaS雲服務。
給你小心心，pick一下中間件小姐姐，關注我的公眾號吧！
閱讀更多 友盟 的文章
