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個層：

服務接口層（Service）：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的接口和實現。

配置層（Config）：對外配置接口，以ServiceConfig和ReferenceConfig為中心，可以直接new配置類，也可以通過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。Protocol是服務域，它是Invoker暴露和引用的主功能入口，它負責Invoker的生命周期管理。Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起invoke調用，它有可能是一個本地的實現，也可能是一個遠程的實現，也可能一個集群實現。

信息交換層（Exchange）：封裝請求響應模式，同步轉異步，以Request和Response為中心，擴展接口為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

網絡傳輸層（Transport）：抽象mina和netty為統一接口，以Message為中心，擴展接口為Channel、Transporter、Client、Server和Codec。

數據序列化層（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來解決。

你可能也喜歡:

阿里P8架構師談：從單體架構、到SOA、再到微服務的架構設計詳解

阿里P8架構師談：Spring Cloud與Dubbo的詳細比較

阿里P8架構師談：雙11秒殺系統如何設計？

阿里P8架構師談：分布式Session共享的4類技術方案，與優劣勢比較

阿里P8架構師談：分布式架構設計(文章合集）

阿里P8架構師談：微服務Dubbo和SpringCloud架構設計、優劣勢比較

---

總結

以上是生活随笔為你收集整理的阿里P8架构师谈：Dubbo的详细介绍、设计思路、以及4大适用场景的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。