公司的一個項目的分布式系統的服務管理，使用了阿裡的服務架構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來儲存服務注冊資訊，這真是很貼心的開源架構啊！