標籤：dubbo 服務管理
公司的一個項目的分布式系統的服務管理，使用了阿里的服務架構Dubbo，因此這裡準備對服務架構進行了介紹。
Dubbo服務架構可以使得java分布式系統之間進行解耦，使用一個服務註冊中心來統一管理服務的資訊，服務提供者提供註冊中心進行註冊，而服務消費者可以透明地訂閱和消費服務。並支援服務的路由、過濾、負載平衡等，支援多種通訊協議及NIO架構，是一個靈活性和擴充性非常棒的服務管理架構。
本文以github中目前的版本2.5.4的源碼來分析。
為了支援更靈活的擴充性，當前dubbo拆分了非常多的project，下面以官網的總體模組圖來說明各個模組的作用。
模組說明：
- dubbo-common 公用邏輯模組，包括Util類和通用模型。
- dubbo-remoting 遠程通訊模組，相當於Dubbo協議的實現，如果RPC用RMI協議則不需要使用此包。
- dubbo-rpc 遠程調用模組，抽象各種協議，以及動態代理，只包含一對一的調用，不關心叢集的管理。
- dubbo-cluster 叢集模組，將多個服務提供者偽裝為一個提供方，包括：負載平衡, 容錯，路由等，叢集的地址清單可以是靜態配置的，也可以是由註冊中心下發。
- dubbo-registry 註冊中心模組，基於註冊中心下發地址的叢集方式，以及對各種註冊中心的抽象。
- dubbo-monitor 監控模組，統計服務調用次數，調用時間的，調用鏈跟蹤的服務。
- dubbo-config 配置模組，是Dubbo對外的API，使用者通過Config使用Dubbo，隱藏Dubbo所有細節。
- dubbo-container 容器模組，是一個Standlone的容器，以簡單的Main載入Spring啟動，因為服務通常不需要Tomcat/JBoss等Web容器的特性，沒必要用Web容器去載入服務。
整體上按照分層結構進行分包，與分層的不同點在於：
- container為服務容器，用於部署運行服務，沒有在層中畫出。
- protocol層和proxy層都放在rpc模組中，這兩層是rpc的核心，在不需要叢集時(只有一個提供者)，可以只使用這兩層完成rpc調用。
- transport層和exchange層都放在remoting模組中，為rpc調用的通訊基礎。
- serialize層放在common模組中，以便更大程度複用。
下面是更詳細的Project關係圖，依賴關係線有點亂。整個模組是從上到下傳遞依賴的。
可以看到，每個模組都實現了多種擴充機制，供使用者選擇，比如服務註冊庫registry實現了zookeeper、multicast、redis等多種機制，而我們選擇了zookeeper來儲存服務註冊資訊，這真是很貼心的開源架構啊！
