| Service |
業務層。包括業務代碼的接口與實現，即開發者實現的業務代碼 |
| config |
配置層。主要圍繞ServiceConfig（暴露的服務配置）和ReferenceConfig（引用的服務配置）兩個實現類展開，初始化配置信息。可以理解爲該層管理了整個Dubbo的配置 |
| proxy |
服務代理層。在Dubbo中，無論生產者還是消費者，框架都會生成一個代理類，整個過程對上層是透明的。當調用一個遠程接口時，看起來就像是調用了一個本地的接口一樣，代理層會自動做遠程調用並返回結果，即讓業務層對遠程調用完全無感 |
| registry |
註冊層。負責Dubbo框架的服務註冊於發現。當有新的服務加入或舊服務下線時，註冊中心都會感知並通知給所有訂閱方。整個過程不需要人工參與 |
| cluster |
集羣容錯層。該層主要負責：遠程調用失敗時的容錯策略（如失敗重試、快速失敗）；選擇具體調用節點時的負載均衡策略（如隨機、一致性Hash等）；特殊調用路徑的路由策略（如某個消費者只會調用某個IP的生產者） |
| monitor |
監控層。這一層主要負責監控統計調用次數和調用時間等 |
| protocol |
遠程調用層。封裝RPC調用具體過程，Protocol是Invoker暴露（發佈一個服務讓別人可以調用）和引用（引用一個遠程服務到本地）的主功能入口，它負責管理Invoker的整個生命週期。Invoker是Dubbo的核心模型，框架中所有其他模型都向它靠攏，或者轉換成它，它代表一個可執行體。允許向它發起invoke調用，它可能是執行一個本地的接口實現，也可能是一個遠程的實現，還可能一個集羣實現 |
| exchange |
信息交換層。建立Request-Response模型，封裝請求響應模式，如把同步請求轉換爲異步請求 |
| transport |
網絡傳輸層。把網絡傳輸抽象爲統一的接口，如Mina和Netty雖然接口不一樣，但是Dubbo在它們上面又封裝了統一的接口。用戶也可以根據其擴展接口添加更多的網絡傳輸方式 |
| Serialize |
序列化層。如果數據要通過網絡進行發送，則需要先做序列化，變成二進制流。序列化層負責管理整個框架網絡傳輸時的序列化/反序列化工作 |
