Dubbo整體架構圖(來源於http://dubbo.apache.org/books/dubbo-dev-book/design.html)如下：
* 圖中左邊淡藍背景的為服務消費方使用的接口，右邊淡綠色背景的為服務提供方使用的接口，位於中軸線上的為雙方都用到的接口。
* 圖中從下至上分為十層，各層均為單向依賴，右邊的黑色箭頭代表層之間的依賴關系，每一層都可以剝離上層被復用，其中，Service 和 Config 層為 API，其它各層均為 SPI
* 圖中綠色小塊的為擴展接口 ,藍色小塊為實現類，圖中只顯示用於關聯各層的實現類。
* 圖中藍色虛線為初始化過程,，即啟動時組裝鏈, 紅色實線為方法調用過程,，即運行時調時鏈，紫色三角箭頭為繼承，可以把子類看作父類的同一個節點，線上的文字為調用的方法。
各層說明：
* 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、Export,。
* Exchanger 信息交換層，封裝請求響應模式，以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的, 然后在 Invoker 的主過程上 Filter 攔截點
： * 圖中的Provider和Consumer是抽象的概念，只是想讓看圖者更直觀的了解哪些分類是分屬於客戶端於服務端，不用Client和Server的原因是Dubbo在很多場景下都使用Provider,Register,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語義。
* Register和Monitor實際上算一層，而是一個獨立的節點，只是為了全局的概覽，用層的方式畫在一起。
模塊分包
模塊說明：
- dubbo-common 公共邏輯模塊：包括 Util 類和通用模型。
- dubbo-remoting 遠程通訊模塊：相當於 Dubbo 協議的實現，如果 RPC 用 RMI協議則不需要使用此包
- dubbo-rpc 遠程調用模塊：抽象各種協議，以及動態代理，只包含一對一的調用，不關心集群的管理。
- dubbo-cluster 集群模塊：將多個服務提供方偽裝為一個提供方，包括：負載均衡, 容錯，路由等，集群的地址列表可以是靜態配置的，也可以是由注冊中心
- dubbo-registry 注冊中心模塊：基於注冊中心下發地址的集群方式，以及對各種注冊中心的抽象。
- dubbo-monitor 監控模塊：統計服務調用次數，調用時間的，調用鏈跟蹤的服務。
- dubbo-config 配置模塊: 是 Dubbo 對外的 API，用戶通過 Config 使用D ubbo，隱藏 Dubbo 所有細節。
- dubbo-container 容器模塊：是一個 Standlone 的容器，以簡單的 Main 加載 Spring 啟動，因為服務通常不需要 Tomcat/JBoss 等 Web 容器的特性，沒必要用Web 容器去加載服務。整體上按照分層結構進行分包，與分層的不同點在於：
- container 為服務容器，用於部署運行服務，沒有在層中畫出。
- protocol 層和 proxy 層都放在 rpc 模塊中，這兩層是 rpc 的核心，在不需要集群也就是只有一個提供者時，可以只使用這兩層完成 rpc 調用。
- transport 層和 exchange 層都放在 remoting 模塊中，為 rpc 調用的通訊基礎。
- serialize 層放在 common 模塊中，以便更大程度復用。
依賴關系
圖例說明：
- 圖中小方塊 Protocol, Cluster, Proxy, Service, Container, Registry, Monitor 代表層或模塊，藍色的表示與業務有交互，綠色的表示只對 Dubbo 內部交互。
- 圖中背景方塊 Consumer, Provider, Registry, Monitor 代表部署邏輯拓撲節點。
- 圖中藍色虛線為初始化時調用，紅色虛線為運行時異步調用，紅色實線為運行時同步調用。
- 圖中只包含 RPC 的層，不包含 Remoting 的層，Remoting 整體都隱含在 Protocol 中。
調用鏈
展開總設計圖的紅色調用鏈，如下：
暴露服務時序
展開總設計圖左邊服務提供方暴露服務的藍色初始化鏈，時序圖如下:
引用服務時序
展開總設計圖右邊服務消費方引用服務的藍色初始化鏈，時序圖如下：
領域模型
在 Dubbo 的核心領域模型中
- Protocol 是服務域，它是 Invoker 暴露和引用的主功能入口，它負責 Invoker 的生命周期管理。
- Invoker 是實體域，它是 Dubbo 的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起 invoke 調用，它有可能是一個本地的實現，也可能是一個遠程的實現，也可能一個集群實現。
- Invocation 是會話域，它持有調用過程中的變量，比如方法名，參數等。
基本設計原則
- 采用 Microkernel + Plugin 模式，Microkernel 只負責組裝 Plugin，Dubbo 自身的功能也是通過擴展點實現的，也就是 Dubbo 的所有功能點都可被用戶自定義擴展所替換。
- 采用 URL 作為配置信息的統一格式，所有擴展點都通過傳遞 URL