Dubbo是一個高性能，基于Java的RPC框架，由阿里巴巴開源。一個分布式的服務框架?？梢詫崿FSOA（面向服務的架構）架構。Dubbo使用的公司：京東、當當、阿里巴巴、中國電信等等。

分布式服務架構的由來

以下式架構演變過程：

早期，電信只有座機的時候，系統只有一個打電話的功能和一個計費的功能。因為業務單一，所以只有一個系統。

單一業務的單體式架構

后來，電信業務豐富起來了。新增了“短信”、“寬帶”、“手機流量”等業務功能。按照常規做法，也只會在原有的“打電話”單一業務系統的基礎上，多添加幾個業務功能模塊而已。所有的業務功能（““電話”、“短信”、“寬帶”、“手機流量””）都還是在一個項目內部。如下圖：

多業務單體式架構

多業務模式下的單體架構，當業務不斷擴張、系統內部的業務功能模塊越來越多，會導致如下問題：

1、會導致業務功能模塊的耦合度太高、不利于擴展和維護，以及推廣。

2、再者程序中存在一個魔性的數字：65535（16bit最大值）限制，（因為調用方法的指令容量只有16bit，65535正好是16bit能容納的最大數字）。重復的方法數太多，會加速達到這個上限。（比如Android應用65535很容易就上限了）。

比如淘寶、天貓、阿里巴巴三個項目都需要用到支付，設想，將淘寶、天貓、阿里巴巴三個項目整合成一個項目的三個業務功能模塊，將會比較雜亂。所以，出現了淘寶、天貓、阿里巴巴三個獨立的項目，類似下圖：

垂直架構

通過一步一步演變，架構已經成為如圖所示的垂直式架構。但是大家都發現了其中的計費功能出現了4次。這樣肯定不利于項目的維護和統一配置。（并且上圖的計費只是眾多可能重復模塊中的一員）。所以不得不將多個項目都要使用的相同模塊獨立出來，共享給業務功能使用。這樣，就演變成如下圖架構：

如圖所示，計費被單獨提煉出來成為一個獨立的app，共其他app共同使用。圖中“其他”模塊用來代替千千萬萬類似計費的模塊。

這樣一來，每一個方塊就是一個獨立的應用。這樣解決了業務復雜度，將業務模塊化、獨立化，方便共享和擴展。這樣的架構帶給我們需要解決的問題如下：

1、各個獨立app之間的通信問題怎么解決？

2、怎么做到統一調度、協調處理。

3、如果計費模塊是并發最大的模塊，但是其他模塊并發不是很大。則需要對計費進行負載均衡，怎么實現？

架構演變過程

什么是RPC？

RPC（Remote Procedure Call Protocol）遠程過程調用協議。服務器A調用服務器B上的方法的一種技術。Dubbo就是一個RPC框架，實現了遠程過程調用。

dubbo主要的三個要素：1、接口的遠程調用2、負載均衡。3、服務自動注冊和發現

dubbo默認每次只訪問一個服務器，需要主從配合完成數據同。

dubbo:registry cluster="replicate"address="redis://192.168.72.188:6379"/

以上就是動力節點小編介紹的"Dubbo分布式服務框架"，希望對大家有幫助，想了解更多可查看Dubbo教程，如有疑問，請在線咨詢，有專業老師隨時為您服務。