Dubbo是什麼？

Dubbo是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。

簡單的說，dubbo就是個服務框架，如果沒有分佈式的需求，其實是不需要用的，只有在分佈式的時候，才有dubbo這樣的分佈式服務框架的需求，並且本質上是個服務調用的東東，說白了就是個遠程服務調用的分佈式框架（告別Web Service模式中的WSdl，以服務者與消費者的方式在dubbo上註冊）。

其核心部分包含:

1. 遠程通訊:

提供對多種基於長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。

2. 集群容錯:

提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。

3. 自動發現

基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

Dubbo能做什麼？

1.透明化的遠程方法調用

就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。

2.軟負載均衡及容錯機制

可在內網替代F5等硬件負載均衡器，降低成本，減少單點。

3. 服務自動註冊與發現

不再需要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，並且能夠平滑添加或刪除服務提供者。

Dubbo採用全spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置即可，Dubbo基於Spring的Schema擴展進行加載。

Dubbo的架構和設計思路

Dubbo框架具有極高的擴展性，主要採用微核+插件體系，並且文檔齊全，很方便二次開發，適應性極強。

Dubbo的總體架構，如圖所示：

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

Dubbo框架設計一共劃分了10個層：

1. 服務接口層（Service）：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的接口和實現。
2. 配置層（Config）：對外配置接口，以ServiceConfig和ReferenceConfig為中心，可以直接new配置類，也可以通過spring解析配置生成配置類。
3. 服務代理層（Proxy）：服務接口透明代理，生成服務的客戶端Stub和服務器端Skeleton，以ServiceProxy為中心，擴展接口為ProxyFactory。
4. 服務註冊層（Registry）：封裝服務地址的註冊與發現，以服務URL為中心，擴展接口為RegistryFactory、Registry和RegistryService。可能沒有服務註冊中心，此時服務提供方直接暴露服務。
5. 集群層（Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker為中心，擴展接口為Cluster、Directory、Router和LoadBalance。將多個服務提供方組合為一個服務提供方，實現對服務消費方來透明，只需要與一個服務提供方進行交互。
6. 監控層（Monitor）：RPC調用次數和調用時間監控，以Statistics為中心，擴展接口為MonitorFactory、Monitor和MonitorService。
7. 遠程調用層（Protocol）：封將RPC調用，以Invocation和Result為中心，擴展接口為Protocol、Invoker和Exporter。Protocol是服務域，它是Invoker暴露和引用的主功能入口，它負責Invoker的生命週期管理。Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起invoke調用，它有可能是一個本地的實現，也可能是一個遠程的實現，也可能一個集群實現。
8. 信息交換層（Exchange）：封裝請求響應模式，同步轉異步，以Request和Response為中心，擴展接口為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
9. 網絡傳輸層（Transport）：抽象mina和netty為統一接口，以Message為中心，擴展接口為Channel、Transporter、Client、Server和Codec。
10. 數據序列化層（Serialize）：可複用的一些工具，擴展接口為Serialization、 ObjectInput、ObjectOutput和ThreadPool。

和淘寶HSF相比，Dubbo的特點是什麼？

1. Dubbo比HSF的部署方式更輕量

HSF要求使用指定的JBoss等容器，還需要在JBoss等容器中加入sar包擴展，對用戶運行環境的侵入性大，如果你要運行在Weblogic或Websphere等其它容器上，需要自行擴展容器以兼容HSF的ClassLoader加載，而Dubbo沒有任何要求，可運行在任何Java環境中。

2. Dubbo比HSF的擴展性更好，很方便二次開發

一個框架不可能覆蓋所有需求，Dubbo始終保持平等對待第三方理念，即所有功能，都可以在不修改Dubbo原生代碼的情況下，在外圍擴展，包括Dubbo自己內置的功能，也和第三方一樣，是通過擴展的方式實現的，而HSF如果你要加功能或替換某部分實現是很困難的，比如支付寶和淘寶用的就是不同的HSF分支，因為加功能時改了核心代碼，不得不拷一個分支單獨發展，HSF現階段就算開源出來，也很難複用，除非對架構重寫。

3. HSF依賴比較多內部系統

比如配置中心，通知中心，監控中心，單點登錄等等，如果要開源還需要做很多剝離工作，而Dubbo為每個系統的集成都留出了擴展點，並已梳理幹清所有依賴，同時為開源社區提供了替代方案，用戶可以直接使用。

4. Dubbo比HSF的功能更多

除了ClassLoader隔離，Dubbo基本上是HSF的超集，Dubbo也支持更多協議，更多註冊中心的集成，以適應更多的網站架構。

Dubbo適用於哪些場景？

1.RPC分佈式服務

當網站變大後，不可避免的需要拆分應用進行服務化，以提高開發效率，調優性能，節省關鍵競爭資源等。

比如：為了適用不斷變化的市場需求，以及多個垂直應用之間數據交互方便，我們把公共的業務抽取出來作為獨立的模塊，為其他的應用提供服務，系統逐漸依賴於抽象和rpc遠程服務調用。

2.配置管理

當服務越來越多時，服務的URL地址信息就會爆炸式增長，配置管理變得非常困難，F5硬件負載均衡器的單點壓力也越來越大。

3.服務依賴

當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關係。

4.服務擴容

接著，服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？等等……

在遇到這些問題時，都可以用Dubbo來解決。

以上就是Dubbo的講解，以下是阿里P8架構師談架構設計18精講。

領取方法

關注+轉發後，私信關鍵詞 【架構】即可學習！

重要的事情說三遍，轉發、轉發、轉發後再發私信，才可以拿到哦！

閱讀更多 優知學院 的文章

關鍵字: 架構師 技術 分佈式服務