一、dubbo整體架構

其中Service 和 Config 層為 API，對應服務提供方來說是使用ServiceConfig來代表一個要發布的服務配置對象，對應服務消費方來說ReferenceConfig代表了一個要消費的服務的配置對象。可以直接初始化配置類，也可以通過 spring 解析配置生成配置類。
proxy 服務代理層：擴展接口為 ProxyFactory，dubbo實現的SPI主要JavassistProxyFactory（默認使用）和JdkProxyFactory，用來對服務提供方和服務消費方的服務進行代理。
registry 注冊中心層：封裝服務地址的注冊與發現，擴展接口為 Registry , RegistryService,Dubbo提供的擴展接口實現為ZookeeperRegistry，RedisRegistry，MulticastRegistry，DubboRegistry。
擴展接口RegistryFactory，dubbo提供的擴展接口實現DubboRegistryFactory，DubboRegistryFactory，RedisRegistryFactory，ZookeeperRegistryFactory。
cluster 路由層：封裝多個提供者的路由及負載均衡，并橋接注冊中心，
擴展接口為 Cluster , Directory , Router ,LoadBalance。
monitor 監控層：RPC 調用次數和調用時間監控，擴展接口為 MonitorFactory , Monitor , MonitorService。
protocol 遠程調用層：封將 RPC 調用，擴展接口為 Protocol , Invoker , Exporter。
exchange 信息交換層：封裝請求響應模式，同步轉異步，擴展接口為 Exchanger , ExchangeChannel ,ExchangeClient , ExchangeServer
transport 網絡傳輸層：抽象 mina 和 netty 為統一接口擴展接口為 Channel , Transporter , Client , Server , Codec
serialize 數據序列化層：可復用的一些工具，擴展接口為 Serialization ,ObjectInput , ObjectOutput , ThreadPool

二、dubbo服務發布原理

　　首先 ServiceConfig 類拿到對外提供服務的實際類 ref(如：UserServiceImpl),然后通過 ProxyFactory 類的 getInvoker 方法使用 ref 生成一個AbstractProxyInvoker 實例，到這一步就完成具體服務到 Invoker 的轉化。

　　接下來就是 Invoker 轉換到 Exporter 的過程。Dubbo 處理服務暴露的關鍵就在 Invoker 轉換到 Exporter 的過程，上圖中的紅色部分。

　　Dubbo 協議的 Invoker 轉為 Exporter 發生在 DubboProtocol 類的 export 方法，它主要是打開創建一個Netty Server 偵聽服務，并接收客戶端發來的各種請求，通訊細節由 Dubbo 自己實現，然后注冊服務到服務注冊中心

三、dubbo消費原理

　　首先 ReferenceConfig 類的 init 方法調用 Protocol 的 refer 方法生成 Invoker 實例(如上圖中的紅色部分)，這是服務消費的關鍵。接下來把Invoker 轉換為客戶端需要的接口。

　　dubbo協議的invoker轉換為客戶端需要的接口是發生在DubboProtocol的refer方法，他主要是創建一個netty client 鏈接服務提供者，通訊細節由 Dubbo 自己實現。

四、dubbo原理總結

節點角色說明：

Provider: 暴露服務的服務提供方。
Consumer: 調用遠程服務的服務消費方。
Registry: 服務注冊與發現的注冊中心。
Monitor: 統計服務的調用次調和調用時間的監控中心。
Container: 服務運行容器。

調用關系說明：

服務容器負責啟動，加載，運行服務提供者。
服務提供者在啟動時，向注冊中心注冊自己提供的服務。
服務消費者在啟動時，向注冊中心訂閱自己所需的服務。
注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數據給消費者。
服務消費者，從提供者地址列表中，基于軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

registry(configServer)

　　注冊中心，和每個Server/Client之間會作一個實時的心跳檢測（因為它們都是建立的Socket長連接），比如幾秒鐘檢測一次。收集每個Server提供的服務的信息，每個Client的信息，整理出一個服務列表

　　當某個Server不可用，那么就更新受影響的服務對應的serverAddressList，即把這個Server從serverAddressList中踢出去（從地址列表中刪除），同時將推送serverAddressList給這些受影響的服務的clientAddressList里面的所有Client

　　新加一個Server時，由于它會主動與ConfigServer取得聯系，而ConfigServer又會將這個信息主動發送給Client，所以新加一個Server時，只需要啟動Server，然后幾秒鐘內，Client就會使用上它提供的服務

consumer(client)

　　調用服務的機器，每個Client啟動時，主動與ConfigServer建立Socket長連接，并將自己的IP等相應信息發送給ConfigServer。
　　Client在使用服務的時候根據服務名稱去ConfigServer中獲取服務提供者信息（這樣ConfigServer就知道某個服務是當前哪幾個Client在使用），Client拿到這些服務提供者信息后，與它們都建立連接，后面就可以直接調用服務了，當有多個服務提供者的時候，Client根據一定的規則來進行負載均衡，如輪詢，隨機，按權重等。
　　一旦Client使用的服務它對應的服務提供者有變化（服務提供者有新增，刪除的情況），ConfigServer就會把最新的服務提供者列表推送給Client，Client就會依據最新的服務提供者列表重新建立連接，新增的提供者建立連接，刪除的提供者丟棄連接

provider(server)

　　真正提供服務的機器，每個Server啟動時，主動與ConfigServer建立Scoket長連接，并將自己的IP，提供的服務名稱，端口等信息直接發送給ConfigServer，ConfigServer就會收集到每個Server提供的服務的信息。

優點：

只要在Client和Server啟動的時候，ConfigServer是好的，服務就可調用了，如果后面ConfigServer掛了，那只影響ConfigServer掛了以后服務提供者有變化，而Client還無法感知這一變化。
Client每次調用服務是不經過ConfigServer的，Client只是與它建立聯系，從它那里獲取提供服務者列表而已
調用服務-負載均衡：Client調用服務時，可以根據規則在多個服務提供者之間輪流調用服務。
服務提供者-容災：某一個Server掛了，Client依然是可以正確的調用服務的，當前提是這個服務有至少2個服務提供者，Client能很快的感知到服務提供者的變化，并作出相應反應。
服務提供者-擴展：添加一個服務提供者很容易，而且Client會很快的感知到它的存在并使用它。

總結

以上是生活随笔為你收集整理的Dubbo工作流程的全部內容，希望文章能夠幫你解決所遇到的問題。

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