分佈式的幾件小事（二）dubbo的工做原理

時間 2019-11-08

標籤分佈式幾件小事 dubbo 原理欄目系統架構简体版

原文原文鏈接

1.dubbo的工做原理

①總體設計spring

圖例說明：緩存

圖中左邊淡藍背景的爲服務消費方使用的接口，右邊淡綠色背景的爲服務提供方使用的接口，位於中軸線上的爲雙方都用到的接口。服務器
圖中從下至上分爲十層，各層均爲單向依賴，右邊的黑色箭頭表明層之間的依賴關係，每一層均可以剝離上層被複用，其中，Service 和 Config 層爲 API，其它各層均爲 SPI。網絡
圖中綠色小塊的爲擴展接口，藍色小塊爲實現類，圖中只顯示用於關聯各層的實現類。架構
圖中藍色虛線爲初始化過程，即啓動時組裝鏈，紅色實線爲方法調用過程，即運行時調時鏈，紫色三角箭頭爲繼承，能夠把子類看做父類的同一個節點，線上的文字爲調用的方法。負載均衡

②dubbo的十層架構說明異步

service 接口層 ：給服務提供者、服務消費者去實現。ide
config 配置層 ：對外的配置接口，以ServiceConfig，REferenceConfig爲中心，能夠直接初始化配置類。也能夠經過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，Exportor。
exchange信息交換層 ：封裝請求響應模式，同步轉異步，以Request，Response爲中心，擴展接口爲Exchanger，ExchangeChannel，ExchangeClient，ExchangeServer。
transport網絡傳輸層:抽象mina和netty爲統一接口，以Message爲中心，擴展接口爲Channel，Transporter，Client，Server,Codec。
serialize數據序列化層 ：能夠複用的一些工具，擴展接口爲Serialization，ObjectInput，ObjectOutput，ThreadPool。

③關係說明

在RPC中，Protocol是核心層，也就是隻要有Protocol+Invoker+Exporter就能夠完成非透明的RPC調用，而後在Invoker的過程上Filter攔截點。
圖中的Consumer和Provider是抽象概念，只是想讓看圖者更直觀的瞭解哪些類分屬於客戶端與服務器端，不用 Client 和 Server 的緣由是 Dubbo 在不少場景下都使用 Provider, Consumer, Registry, Monitor 劃分邏輯拓普節點，保持統一律念。
Cluster是外圍概念，全部cluster的目的是將多個Invoker假裝成一個Invoker，這樣其餘人只要關注Protocol層Invoker便可，加上Cluster或者去掉Cluster對其餘層都不會形成影響，由於只有一個提供者時，是不須要Cluster的。
Proxy層封裝了全部接口的透明化代理，而在其它層都以Invoker爲中心，只有暴露給用戶使用時，才用Proxy將Invoker轉爲接口，或者將接口實現爲Invoker，也就是去掉Proxy層的RPC是能夠run的，只是不那麼透明，不那麼看起來向本地服務同樣調用遠程服務。
Remoting實現是dubbo協議的實現，若是你選擇RMI協議，整個Remoting都用不上，Remoting內部再劃分爲transport傳輸層和exchange交換層，Transport層只負責單向消息傳輸，是對mina，netty，Grizzly的抽象，它能夠擴展UDP傳輸，二Exchange層是在傳輸層之上封裝了Request-Response語義。
Registry和Monitor實際上不算一層，而是一個獨立的節點，只是爲了全局概覽，用層的方式畫在了一塊兒。