分佈式服務Dubbo的前世此生

SOA與服務治理

SOA（面向服務的體系結構）概念由來已久，在10多年前便開始進入到咱們廣大軟件開發者的視線中。SOA是一種粗粒度、鬆耦合服務架構，服務之間經過簡單、精肯定義接口進行通信，不涉及底層編程接口和通信模型。SOA能夠看做是B/S模型、Web Service技術以後的天然延伸。

服務治理，也稱爲SOA治理，是指用來管理SOA的採用和實現的過程。如下是在2006年時IBM對於服務治理要點的總結：

• 服務定義（服務的範圍、接口和邊界）
• 服務部署生命週期（各個生命週期階段）
• 服務版本治理（包括兼容性）
• 服務遷移（啓用和退役）
• 服務註冊中心（依賴關係）
• 服務消息模型（規範數據模型）
• 服務監視（進行問題肯定）
• 服務全部權（企業組織）
• 服務測試（重複測試）
• 服務安全（包括可接受的保護範圍）

限於當時的技術發展水平，廣大軟件設計與開發人員對於SOA和服務治理的技術認知還主要停留在Web Service和ESB總線等技術和規範上，並無真正在軟件開發中得以充分落地。

Dubbo開源

直到2011年10月27日，阿里巴巴開源了本身的SOA服務化治理方案的核心框架Dubbo，服務治理和SOA的設計理念開始逐漸在國內軟件行業中落地，並被普遍應用。

Dubbo做爲阿里巴巴內部的SOA服務化治理方案的核心框架，在2012年時已經天天爲2000+個服務提供3,000,000,000+次訪問量支持，並被普遍應用於阿里巴巴集團的各成員站點。Dubbo自2011年開源後，已被許多非阿里系公司使用，其中既有當當網、網易考拉等互聯網公司，也有中國人壽、青島海爾等傳統企業。

Dubbo簡介

Dubbo是一個高性能服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案，使得應用可經過高性能RPC實現服務的輸出和輸入功能，和Spring框架能夠無縫集成。

做爲一個分佈式服務框架，以及SOA治理方案，Dubbo其功能主要包括：高性能NIO通信及多協議集成，服務動態尋址與路由，軟負載均衡與容錯，依賴分析與服務降級等。Dubbo最大的特色是按照分層的方式來架構，使用這種方式可使各個層之間解耦合（或者最大限度地鬆耦合）。從服務模型的角度來看，Dubbo採用的是一種很是簡單的模型，要麼是提供方提供服務，要麼是消費方消費服務，因此基於這一點能夠抽象出服務提供方（Provider）和服務消費方（Consumer）兩個角色。

Dubbo包含遠程通信、集羣容錯和自動發現三個核心部分。提供透明化的遠程方法調用，實現像調用本地方法同樣調用遠程方法，只需簡單配置，沒有任何API侵入。同時具有軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，下降成本，減小單點。能夠實現服務自動註冊與發現，再也不須要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，而且可以平滑添加或刪除服務提供者。

下圖來自Dubbo官網，描述了服務註冊中心、服務提供方、服務消費方、服務監控中心之間的調用關係，具體以下圖所示：

節點角色說明：

調用關係說明：

1. 服務容器負責啓動，加載，運行服務提供者。
2. 服務提供者在啓動時，向註冊中心註冊本身提供的服務。
3. 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。
4. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。
5. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。
6. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。 Dubbo整體架構

Dubbo框架設計共劃分了10層，最上面的Service層是留給實際使用Dubbo開發分佈式服務的開發者實現業務邏輯的接口層。圖中左邊淡藍背景的爲服務消費方使用的接口，右邊淡綠色背景的爲服務提供方使用的接口，位於中軸線上的爲雙方都用到的接口。

各層說明：

• Config配置層：對外配置接口，以ServiceConfig、ReferenceConfig爲中心，能夠直接初始化配置類，也能夠經過Spring解析配置生成配置類。
• Proxy服務代理層：服務接口透明代理，生成服務的客戶端Stub和服務器端Skeleton，以ServiceProxy爲中心，擴展接口爲ProxyFactory。
• Registry註冊中心層：封裝服務地址的註冊與發現，以服務URL爲中心，擴展接口爲RegistryFactory、Registry、RegistryService。
• Cluster路由層：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker爲中心，擴展接口爲Cluster、Directory、Router、LoadBalance。
• Monitor監控層：RPC調用次數和調用時間監控，以Statistics爲中心，擴展接口爲MonitorFactory、Monitor、MonitorService。
• Protocol遠程調用層：封將RPC調用，以Invocation、Result爲中心，擴展接口爲Protocol、Invoker、Exporter。
• Exchange信息交換層：封裝請求響應模式，同步轉異步，以Request、Response爲中心，擴展接口爲Exchanger、ExchangeChannel、ExchangeClient、ExchangeServer。
• Transport網絡傳輸層：抽象MINA和Netty爲統一接口，以Message爲中心，擴展接口爲Channel、Transporter、Client、Server、Codec。
• Serialize數據序列化層：可複用的一些工具，擴展接口爲Serialization、ObjectInput、ObjectOutput、ThreadPool。

模塊分包

各模塊說明：

• dubbo-common公共邏輯模塊：包括Util類和通用模型。
• dubbo-remoting遠程通信模塊：至關於Dubbo協議的實現，若是RPC用 RMI協議則不須要使用此包。
• dubbo-rpc遠程調用模塊：抽象各類協議，以及動態代理，只包含一對一的調用，不關心集羣的管理。
• dubbo-cluster集羣模塊：將多個服務提供方假裝爲一個提供方，包括：負載均衡、容錯、路由等，集羣的地址列表能夠是靜態配置的，也能夠是由註冊中心下發。
• dubbo-registry註冊中心模塊：基於註冊中心下發地址的集羣方式，以及對各類註冊中心的抽象。
• dubbo-monitor監控模塊：統計服務調用次數、調用時間的、調用鏈跟蹤的服務。
• dubbo-config配置模塊：是Dubbo對外的API，用戶經過Config使用Dubbo，隱藏Dubbo全部細節。
• dubbo-container容器模塊：是一個Standlone的容器，以簡單的Main加載Spring啓動，由於服務一般不須要Tomcat/JBoss等Web容器的特性，不必用Web容器去加載服務。

協議支持

• Dubbo協議（默認協議）
• Hessian協議
• HTTP協議
• RMI協議
• WebService協議
• Thrift協議
• Memcached協議
• Redis協議

註冊中心

（1）Multicast註冊中心：

Multicast註冊中心不須要啓動任何中心節點，只要廣播地址同樣，就能夠互相發現。組播受網絡結構限制，只適合小規模應用或開發階段使用。組播地址段：224.0.0.0 - 239.255.255.255。

（2）ZooKeeper註冊中心（推薦）：

ZooKeeper是Apacahe子項目，是一個樹型的目錄服務，支持變動推送，適合做爲Dubbo服務的註冊中心，可用於生產環境。

對上圖流程說明以下：

1. 服務提供者（Provider）啓動時，向/dubbo/com.foo.BarService/providers目錄下寫入URL。
2. 服務消費者（Consumer）啓動時，訂閱/dubbo/com.foo.BarService/providers目錄下的URL，向/dubbo/com.foo.BarService/consumers目錄下寫入本身的URL。
3. 監控中心（Monitor）啓動時，訂閱/dubbo/com.foo.BarService目錄下的全部提供者和消費者URL。

（3）Redis註冊中心：

阿里內部並無採用Redis作爲註冊中心，而是使用本身實現的基於數據庫的註冊中心，即：Redis註冊中心並無在阿里內部長時間運行的可靠性保障，此Redis橋接實現只爲開源版本提供，其可靠性依賴於Redis自己的可靠性。

（4）Simple註冊中心：

Simple註冊中心自己就是一個普通的Dubbo服務，能夠減小第三方依賴，使總體通信方式一致。只是簡單實現，不支持集羣，可做爲自定義註冊中心的參考，但不適合直接用於生產環境。

遠程通訊與信息交換

遠程通訊須要指定通訊雙方所約定的協議，在保證通訊雙方理解協議語義的基礎上，還要保證高效、穩定的消息傳輸。Dubbo繼承了當前主流的網絡通訊框架，主要包括以下幾個：

• Mina
• Netty（默認）
• Grizzly

中止維護

從2012年10月23日Dubbo2.5.3發佈後，在Dubbo開源將滿一週年之際，阿里基本中止了對Dubbo的主要升級。只在以後的2013年和2014年更新過2次對Dubbo2.4的維護版本，而後中止了全部維護工做。Dubbo對Srping的支持也停留在了Spring 2.5.6版本上。

分支出現

在阿里中止維護和升級Dubbo期間，噹噹網開始維護本身的Dubbo分支版本Dubbox，支持了新版本的Spring，並對外開源了Dubbox。同時，網易考拉也維護了本身的獨立分支Dubbok，惋惜並未對外開源。

重獲新生

通過多年漫長的等待，隨着微服務的火熱興起，在國內外開發者對阿里再也不升級維護Dubbo的吐槽聲中，阿里終於開始從新對Dubbo的升級和維護工做。在2017年9月7日，阿里發佈了Dubbo的2.5.4版本，距離上一個版本2.5.3發佈已經接近快5年時間了。在隨後的幾個月中，阿里Dubbo開發團隊以差很少每個月一版本的速度開始快速升級迭代，修補了Dubbo老版本多年來存在的諸多bug，並對Spring等組件的支持進行了全面升級。

分支合併

在2018年1月8日，Dubbo 2.6.0版本發佈，新版本將以前噹噹網開源的Dubbo分支Dubbox進行了合併，實現了Dubbo版本的統一整合。

Dubbo與Spring Cloud

阿里巴巴負責主導了 Dubbo 重啓維護的研發工程師劉軍在接受採訪時表示：當前因爲 RPC協議、註冊中心元數據不匹配等問題，在面臨微服務基礎框架選型時Dubbo與Spring Cloud是隻能二選一，這也是爲何你們老是拿Dubbo和SpringCloud作對比的緣由之一。Dubbo以後會積極尋求適配到Spring Cloud生態，好比做爲Spring
Cloud的二進制通訊方案來發揮Dubbo的性能優點，或者Dubbo經過模塊化以及對http的支持適配到Spring Cloud。

將來展望

2018年1月8日，Dubbo創始人之一梁飛在Dubbo交流羣裏透露了Dubbo 3.0正在動工的消息。Dubbo 3.0內核與Dubbo2.0徹底不一樣，但兼容Dubbo 2.0。Dubbo 3.0將以Streaming爲內核，再也不是Dubbo時代的RPC，可是RPC會在Dubbo3.0中變成遠程Streaming對接的一種可選形態。Dubbo 3.0將支持可選Service Mesh，多加一層IPC，這主要是爲了兼容老系統，而內部則會優先嚐試內嵌模式。代理模式Ops可獨立升級框架，減小業務侵入，而內嵌模式能夠帶業務測試、部署節點少、穩定性檢測方便。同時，能夠將Dubbo3.0啓動爲獨立進程，由dubbo-mesh進行IPC，路由、負載均衡和熔斷機制將由獨立進程控制。

在此我向你們推薦一個架構學習交流羣。交流學習羣號：478030634 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，目前受益良多

總結

從 Dubbo 新版本的路線規劃上能夠看出，新版本的Dubbo在原有服務治理的功能基礎上，將全面擁抱微服務和Service Mesh。同時，考慮到在阿里雲已經有了Dubbo的商業版本，在將來一段時間內，Dubbo的更新與維護應該不會再長時間中斷。在咱們進行服務治理以及微服務架構設計時，新版本Dubbo對咱們廣大開發者來講都將會是一個不錯的選擇。