?

以下內容全文轉自 apache 官方 dubbo文檔：http://dubbo.apache.org/en-us/docs/dev/design.html

?

框架設計

?

圖片描述：

• 淺藍色背景的左側區域顯示服務用戶界面，淺綠色背景的右側區域顯示服務提供者界面，中心區域顯示兩個側面界面。
• 圖像從底部到頂部分為10層，這些層是單向依賴的。右側的黑色箭頭表示層之間的依賴關系，每層可以從上層剝離以重復使用，Service和Config層是API，其他層是SPI。
• 綠框是擴展接口，藍框是實現類，圖像僅顯示關聯層的實現類。
• 藍色虛線是初始化過程，啟動時為裝配鏈，方法調用過程為紅線，運行時調用鏈，繼承紫色三角箭頭，可將子類視為父類的同一節點，文本為lines是方法調用。

圖層描述

• config層：外部配置界面，ServiceConfig并且ReferenceConfig是圖層的中心，可以直接初始化配置類，也可以通過spring生成配置類。
• 代理層：服務接口的透明代理，生成客戶端Stub服務和服務器Skeletion of service，ServiceProxy是中心，擴展接口是ProxyFactory。
• 注冊表層：服務注冊表和發現的封裝，服務URL是中心，擴展接口是RegistryFactory，Registry和RegistryService。
• 簇層：muliple提供商和負載平衡，和橋接登記中心的簇的封裝，Invoker是中心，擴展接口是Cluster，Directory，Router，LoadBalance。
• 監控層：的RPC調用倍顯示器和呼叫執行時間，Statistics是中心，擴展接口是MonitorFactory，Monitor，MonitorService
• 協議層：RPC的封裝，Invocation并且Result是中心，擴展接口是Protocol，Invoker，Exporter
• 交換層：的請求和響應，同步傳輸異步封裝，Request并且Response是中心，擴展接口是Exchanger，ExchangeChannel，ExchangeClient，ExchangeServer
• 傳輸層：米娜和網狀的抽象，Message是中心，擴展接口是Channel，Transporter，Client，Server，Codec
• 序列化層：可重復使用的工具，擴展接口Serialization，ObjectInput，ObjectOutput，ThreadPool

關系描述

• 在RPC中，Protocol是核心層，它意味著您可以通過Protocol + Invoker + Exporter完成RPC調用，然后在Invoker的主進程中進行過濾。
• Consumer和Provider是抽象概念，只是希望您能更直觀地了解哪些類屬于客戶端和服務器端，不使用Client和Server的原因是Dubbo使用Provider，Consumer，Registry，Monitor劃分邏輯拓撲節點。場景，保持團結的概念。
• Cluster是外部概念，Cluster的目的是讓各種Invoker偽裝成一個Invoker，這樣我們只關注Invoker in Protocol層，添加Cluster或刪除Cluster不會影響其他層，因為我們不需要Cluster什么時候只有一個提供者。
• Proxy層封裝了所有接口的透明代理，在Invoker作為中心的其他層中，將Invoker轉換為接口，或者僅在暴露給用戶時將接口實現轉換為Invoker by Proxy。RPC仍然可以工作，甚至刪除代理層，但不是那么透明，使得遠程服務調用看起來不像本地服務調用。
• 遠程處理是Dubbo協議的實現，如果選擇RMI，您可以刪除遠程處理。Remoting分為Transport層和Exchange層，Transport層負責單向消息傳輸，它是Mina，Netty，Grizzly的抽象，它還可以擴展UDP傳輸。Exchange層在傳輸層上封裝了Request-Response語義。
• 實際上Registry和Monitor不在同一層，它們是獨立的節點，只是為了全局視圖而一層一層地繪制它們。

模塊包裝

模塊說明：

• dubbo-common模塊：包括Util類和通用模塊。
• dubbo-remoting模塊：是Dubbo協議實現，如果使用RMI for RPC則無需使用此模塊。
• dubbo-rpc模塊：各種協議的抽象，和動態代理，只有一對一的調用，不關心集群的管理。
• dubbo-cluster模塊：將許多服務提供者偽裝成一個提供者，包括負載平衡，容錯，路由等。群集的地址列表可以是靜態的，也可以是注冊表發送的。
• dubbo-registry模塊：基于注冊表發送地址的集群和各種注冊中心的抽象。
• dubbo-monitor模塊：服務呼叫時間統計，呼叫時間，呼叫鏈跟蹤服務。
• dubbo-config模塊：是Dubbo外部API，用戶使用Dubbo by Config，隱藏Dubbo的詳細信息。
• dubbo-container模塊：是一個Standlone容器，只需使用Main方法加載Spring，因為通常服務不需要Tomcat / JBoss功能。

包層根據層結構劃分，與層劃分的區別：

• 容器是服務容器，用于服務運行部署，未在映像中顯示。
• 協議層和代理層都放在RPC模塊中，它們是RPC模塊的核心，當只有1個提供者時，可以使用這2層完整的RPC調用。
• 傳輸層和交換層放置在遠程模塊中，用于RPC呼叫基礎通信。
• 序列化層放在通用模塊中，以便重用。

依賴關系

圖片描述：

• 圖像，協議，群集，代理，服務，容器，注冊表，監視器中的框表示層或模塊，藍調表示與業務交互，綠色表示僅與Dubbo的內部交互。
• 圖像，消費者，提供者，注冊表，監視器中的背景框表示部署邏輯拓撲節點。
• 調用圖像中的藍色虛線進行初始化，為運行時異步調用紅色虛線，并為運行時同步調用紅線。
• 圖像僅包含RPC層，不包括Remoting層，整個Remoting隱藏在Protocol層中。

調用鏈

展開整個設計地圖的紅色調用鏈：

公開服務順序

展開服務提供者公開服務的初始化鏈，在整個設計圖的左側，序列圖如下所示：

參考服務序列

展開服務使用者參考服務的初始化鏈，在整個設計圖的右側，序列圖如下所示：

領域模型

達博的核心領域模型：

• 協議是服務域，它是Invoker暴露和參考的主要功能入口，它負責Invoker的生命周期管理。
• Invoker是實體域，它是Dubbo的核心模型，所有其他模型都受到干擾，或轉換為它，它代表一個可執行文件，你可以通過調用invoke來調用它，它可以是一個本地實現，一個遠程實現，或者集群實現。
• 調用是會話域，它在調用進程中保存變量，例如方法名稱，參數等。

基本設計原則

• 使用Microkernel + Plugin設計模式，Microkernel只負責組裝插件，Dubbo的功能是通過擴展點實現的，這意味著Dubbo的所有功能都可以被用戶自定義擴展替換。
• 使用URL作為配置信息的startdard格式，所有擴展點都通過URL傳輸配置信息。

?