Dubbo 是阿里巴巴 2011年開源的一個基于 Java 的 RPC 框架，它實現(xiàn)了面向接口的代理 RPC 調用，并且可以配合 ZooKeeper 等組件實現(xiàn)服務注冊和發(fā)現(xiàn)功能，并且擁有負載均衡、容錯機制等。

Consumer需要調用遠程服務的服務消費方

Registry注冊中心

Provider服務提供方

Container服務運行的容器

Monitor監(jiān)控中心

再說一下整體的流程，首先服務提供者?Provider 啟動然后向注冊中心注冊自己所能提供的服務。

服務消費者?Consumer 啟動向注冊中心訂閱自己所需的服務。然后注冊中心將提供者元信息通知給 Consumer， 之后 Consumer 因為已經從注冊中心獲取提供者的地址，因此可以通過負載均衡選擇一個 Provider 直接調用?。

之后服務提供方元數(shù)據(jù)變更的話注冊中心會把變更推送給服務消費者。

服務提供者和消費者都會在內存中記錄著調用的次數(shù)和時間，然后定時的發(fā)送統(tǒng)計數(shù)據(jù)到監(jiān)控中心。

總的而言 Dubbo 分為三層，如果每一層再細分下去，一共有十層。

大的三層分別為 Business（業(yè)務層）、RPC 層、Remoting，并且還分為 API 層和 SPI 層。

分為大三層其實就是和我們知道的網絡分層一樣的意思，只有層次分明，職責邊界清晰才能更好的擴展。

而分 API 層和 SPI 層這是 Dubbo 成功的一點，采用微內核設計+SPI擴展，使得有特殊需求的接入方可以自定義擴展，做定制的二次開發(fā)。

接下來咱們再來看看每一層都是干嘛的。

Service，業(yè)務層，就是咱們開發(fā)的業(yè)務邏輯層。

Config，配置層，主要圍繞 ServiceConfig 和 ReferenceConfig，初始化配置信息。

Proxy，代理層，服務提供者還是消費者都會生成一個代理類，使得服務接口透明化，代理層做遠程調用和返回結果。

Register，注冊層，封裝了服務注冊和發(fā)現(xiàn)。

Cluster，路由和集群容錯層，負責選取具體調用的節(jié)點，處理特殊的調用要求和負責遠程調用失敗的容錯措施。

Monitor，監(jiān)控層，負責監(jiān)控統(tǒng)計調用時間和次數(shù)。

Portocol，遠程調用層，主要是封裝 RPC 調用，主要負責管理 Invoker，Invoker代表一個抽象封裝了的執(zhí)行體，之后再做詳解。

Exchange，信息交換層，用來封裝請求響應模型，同步轉異步。

Transport，網絡傳輸層，抽象了網絡傳輸?shù)慕y(tǒng)一接口，這樣用戶想用 Netty 就用 Netty，想用 Mina 就用 Mina。

Serialize，序列化層，將數(shù)據(jù)序列化成二進制流，當然也做反序列化。

SPI（Service Provider Interface），是 JDK 內置的一個服務發(fā)現(xiàn)機制，它使得接口和具體實現(xiàn)完全解耦。我們只聲明接口，具體的實現(xiàn)類在配置中選擇。

具體的就是你定義了一個接口，然后在META-INF/services目錄下放置一個與接口同名的文本文件，文件的內容為接口的實現(xiàn)類，多個實現(xiàn)類用換行符分隔。