總結：Dubbo預設協議採用單一長連線和NIO非同步通訊，適合於小資料量大併發的服務呼叫，以及服務消費者機器數遠大於服務提供者機器數的情況。

Dubbo是基於RPC的SOA框架

作為RPC：支援各種傳輸協議，如dubbo,hession,json,fastjson，底層採用mina,netty長連線進行傳輸！典型的provider和cusomer模式!
作為SOA：具有服務治理功能，提供服務的註冊和發現！用zookeeper實現註冊中心！啟動時候服務端會把所有介面註冊到註冊中心，並且訂閱configurators,服務消費端訂閱provide，configurators,routers,訂閱變更時，zk會推送providers,configuators，routers,啟動時註冊長連線，進行通訊！proveider和provider啟動後，後臺啟動定時器，傳送統計資料到monitor（監控中心）！提供各種容錯機制和負載均衡策略！！

我們解釋以下這個架構圖：https://yq.aliyun.com/articles/38380

為更方便的理解可以看如下圖：

Consumer服務消費者，Provider服務提供者。Container服務容器。消費當然是invoke提供者了，invoke這條實線按照圖上的說明當然同步的意思了，多說一句，在實際呼叫過程中，Provider的位置對於Consumer來說是透明的，上一次呼叫服務的位置（IP地址）和下一次呼叫服務的位置，是不確定的。這個地方就是實現了軟負載。

服務提供者先啟動start，然後註冊register服務。

消費訂閱subscribe服務，如果沒有訂閱到自己想獲得的服務，它會不斷的嘗試訂閱。新的服務註冊到註冊中心以後，註冊中心會將這些服務通過notify到消費者。

Monitor這是一個監控，圖中虛線表明Consumer 和Provider通過非同步的方式傳送訊息至Monitor，Consumer和Provider會將資訊存放在本地磁碟，平均1min會發送一次資訊。Monitor在整個架構中是可選的（圖中的虛線並不是可選的意思），Monitor功能需要單獨配置，不配置或者配置以後，Monitor掛掉並不會影響服務的呼叫。

netty 是什麼？

“netty 是一個基於nio的客戶、伺服器端程式設計框架,netty提供非同步的,事件驅動的網路應用程式框架和工具,可以快速開發高可用的客戶端和伺服器。

netty是基於nio的,它封裝了jdk的nio,讓我們使用起來更加方法靈活。

二、dubbo原理？

I、初始化過程細節： 
上圖中的第一步start，就是將服務裝載容器中，然後準備註冊服務。和Spring中啟動過程類似，spring啟動時，將bean裝載進容器中的時候，首先要解析bean。所以dubbo也是先讀配置檔案解析服務。 
解析服務： 
1）、基於dubbo.jar內的Meta-inf/spring.handlers配置，spring在遇到dubbo名稱空間時，會回撥DubboNamespaceHandler類。 
2）、所有的dubbo標籤，都統一用DubboBeanDefinitionParser進行解析，基於一對一屬性對映，將XML標籤解析為Bean物件。 
在ServiceConfig.export 或者ReferenceConfig.get 初始化時，將Bean物件轉會為url格式，將所以Bean屬性轉成url的引數。 
然後將URL傳給Protocol擴充套件點，基於擴充套件點的Adaptive機制，根據URL的協議頭，進行不同協議的服務暴露和引用。

a、 只暴露服務埠

在沒有使用註冊中心的情況，這種情況一般適用在開發環境下，服務的呼叫這和提供在同一個IP上，只需要開啟服務的埠即可。 
即，當配置 or 
ServiceConfig解析出的URL的格式為： 
Dubbo：//service-host/com.xxx.TxxService?version=1.0.0 
基於擴充套件點的Adaptiver機制，通過URL的“dubbo：//”協議頭識別，直接呼叫DubboProtocol的export（）方法，開啟服務埠。

b、向註冊中心暴露服務：

和上一種的區別：需要將服務的IP和埠一同暴露給註冊中心。 
ServiceConfig解析出的url格式為： 
registry://registry-host/com.alibaba.dubbo.registry.RegistryService?export=URL.encode(“dubbo://service-host/com.xxx.TxxService?version=1.0.0”)

基於擴充套件點的Adaptive機制，通過URL的“registry：//”協議頭識別，呼叫RegistryProtocol的export方法，將export引數中的提供者URL先註冊到註冊中心，再重新傳給Protocol擴充套件點進行暴露： Dubbo：//service-host/com.xxx.TxxService?version=1.0.0

四、服務暴露和消費的詳細過程

（1）服務提供者暴露一個服務的詳細過程

服務提供者暴露服務的主過程：

首先ServiceConfig類拿到對外提供服務的實際類ref(如：HelloWorldImpl),然後通過ProxyFactory類的getInvoker方法使用ref生成一個AbstractProxyInvoker例項，

到這一步就完成具體服務到Invoker的轉化。接下來就是Invoker轉換到Exporter的過程。

Dubbo處理服務暴露的關鍵就在Invoker轉換到Exporter的過程(如上圖中的紅色部分)，下面我們以Dubbo和RMI這兩種典型協議的實現來進行說明：

Dubbo的實現：

Dubbo協議的Invoker轉為Exporter發生在DubboProtocol類的export方法，它主要是開啟socket偵聽服務，並接收客戶端發來的各種請求，通訊細節由Dubbo自己實現。

RMI的實現：

RMI協議的Invoker轉為Exporter發生在RmiProtocol類的export方法，
它通過Spring或Dubbo或JDK來實現RMI服務，通訊細節這一塊由JDK底層來實現，這就省了不少工作量。

（2）服務消費者消費一個服務的詳細過程

服務消費的主過程：

首先ReferenceConfig類的init方法呼叫Protocol的refer方法生成Invoker例項(如上圖中的紅色部分)，這是服務消費的關鍵。

接下來把Invoker轉換為客戶端需要的介面(如：HelloWorld)。

那麼分散式又是啥？

分散式服務顧名思義服務是分散部署在不同的機器上的，一個服務可能負責幾個功能，是一種面向SOA架構的，服務之間也是通過rpc來互動或者是webservice來互動的。邏輯架構設計完後就該做物理架構設計，系統應用部署在超過一臺伺服器或虛擬機器上，且各分開部署的部分彼此通過各種通訊協議互動資訊，就可算作分散式部署，生產環境下的微服務肯定是分散式部署的，分散式部署的應用不一定是微服務架構的，比如叢集部署，它是把相同應用複製到不同伺服器上，但是邏輯功能上還是單體應用。

微服務的區別

微服務相比分散式服務來說，它的粒度更小，服務之間耦合度更低，由於每個微服務都由獨立的小團隊負責，因此它敏捷性更高，分散式服務最後都會向微服務架構演化，這是一種趨勢， 不過服務微服務化後帶來的挑戰也是顯而易見的，例如服務粒度小，數量大，後期運維將會很難