談Dubbo服務框架

Dubbo 是阿里巴巴公司開源的一個高性能優秀的服務框架，使得應用可通過高性能的 RPC 實現服務的輸出和輸入功能，可以和 Spring框架無縫集成。它最大的特點是按照分層的方式來架構，使用這種方式可以使各個層之間解耦合（或者最大限度地松耦合）。從服務模型的角度來 看，Dubbo采用的是一種非常簡單的模型，要么是提供方提供服務，要么是消費方消費服務，所以基于這一點可以抽象出服務提供方（Provider）和服 務消費方（Consumer）兩個角色。主要核心部件：

• Remoting: 網絡通信框架，實現了 sync-over-async 和 request-response 消息機制.
• RPC: 一個遠程過程調用的抽象，支持負載均衡、容災和集群功能
• Registry: 服務目錄框架用于服務的注冊和服務事件發布和訂閱
</ul>

連通性說明

注冊中心負責服務地址的注冊與查找，相當于目錄服務，服務提供者和消費者只在啟動時與注冊中心交互，注冊中心不轉發請求，壓力較小；監控中心負責統計各服務調用次數，調用時間等，統計先在內存匯總后每分鐘一次發送到監控中心服務器，并以報表展示。

服務提供者向注冊中心注冊其提供的服務，并匯報調用時間到監控中心，此時間不包含網絡開銷；服務消費者向注冊中心獲取服務提供者地址列表，并根據負載算法直接調用提供者，同時匯報調用時間到監控中心，此時間包含網絡開銷。

注冊中心，服務提供者，服務消費者三者之間均為長連接，監控中心除外；注冊中心通過長連接感知服務提供者的存在，服務提供者宕機，注冊中心將立即 推送事件通知消費者；注冊中心和監控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表；注冊中心和監控中心都是可選的，服務消 費者可以直連服務提供者。

健狀性說明

監控中心宕掉不影響使用，只是丟失部分采樣數據；數據庫宕掉后，注冊中心仍能通過緩存提供服務列表查詢，但不能注冊新服務。

注冊中心對等集群，任意一臺宕掉后，將自動切換到另一臺；注冊中心全部宕掉后，服務提供者和服務消費者仍能通過本地緩存通訊。服務提供者無狀態，任意一臺宕掉后，不影響使用；服務提供者全部宕掉后，服務消費者應用將無法使用，并無限次重連等待服務提供者恢復。

伸縮性說明

注冊中心為對等集群，可動態增加機器部署實例，所有客戶端將自動發現新的注冊中心；服務提供者無狀態，可動態增加機器部署實例，注冊中心將推送新的服務提供者信息給消費者。

以上內容是Dubbo主頁提供的一些簡單介紹，對于Dubbo的詳細架構分析和介紹網上也有專門的文章說明，在此不再詳細描述，只是對Dubbo本身的一些架構思路和使用場景再做些簡單總結。

對于Dubbo分布式服務框架可以看到，對于實現系統內的完全組件化獨立開發相當有好處，在這個之前我們往往使用的方法是利用OSGI軟總線方式 來實現內部的組件化開發和獨立部署。而Dubbo框架可以更加容易的實現這點，即將邏輯層的方法很容易暴露為遠程可以調用的各種類型的服務。即組件完全獨 立部署，而組件之間的交互只能夠通過服務代理層暴露出來的服務進行交互，而這些服務都在服務注冊中心進行注冊。

對于注冊中心和監控中心，這里有一個高可靠性設計，即即使兩者都宕機無法訪問，也不會影響到服務的正常消費和調用，這個設計相當重要，直接降低了 本身服務框架和業務系統組件之間的強耦合性。當然注冊中心本身也有內置的基于zookeeper的分布式協調機制和機器本身的動態心跳檢測。

Dubbo分布式服務框架同傳統的ESB一個重點區別就是對于實際的消息流不會走在Dubbo上面，即前面我有文章談到過的對于服務的調用基本上 是兩次調用模式。即第一次調用首先從注冊中心獲取到動態的服務調用地址，第二次調用即服務的提供端和消費端直接握手，以解決消息流不需要在dubbo上傳 遞的問題。這樣做的好處就是dubbo本身不會有太大的消息傳輸和性能壓力，但是缺點就是dubbo無法對消息傳輸日志進行詳細的審計，這個只有留個各個 業務系統自己去完成。

由于是二次握手，因此很容易實現完全的一種分布式服務架構模式，而且這種分布式集群不需要借助任何的集群軟件和負載均衡設備。這是Dubbo框架 的另外一個重要優點，即在服務注冊中心本身有一個請求分配機制，可以在獲取服務訪問地址的時候動態的根據各種分配策略將服務請求分配到不同的服務端提供地 址上面。即將所有的服務提供端IP地址，提供服務地址都需要配置到服務注冊中心，服務注冊中心根據某種負載均衡算法進行服務請求的平均分配。由于本身服務 的無狀態性，因此也不需要有專門的服務狀態和會話保持機制。

應用的心跳檢測是一個重要內容，注意這里不僅僅是服務器本身的心跳檢查，而可能是到服務是否可用的心跳檢測，只有實現這個層面的心跳，服務注冊和 管理中心才可能在服務提供端無法訪問的時候動態分配其它可訪問的服務提供地址，形成一種高可用性架構模式。對于心跳檢測現在常用的方法仍然是基于 socket的長連接和狀態監聽機制來實現。但是對于tcp keepalive心跳檢測機制最大的問題還是在于無法很好的檢測服務本身是否可用的問題，這個問題得到解決才是根本。

注意在dubbo里面有兩個重要的模塊，一個是dubbo-cluster 集群模塊，將多個服務提供方偽裝為一個提供方，包括：負載均衡、容錯、路由等，集群的地址列表可以是靜態配置的，也可以是由注冊中心下發。另外一個是 dubbo-registry 注冊中心模塊，基于注冊中心下發地址的集群方式，以及對各種注冊中心的抽象。要注意到這兩個模塊對應的服務注冊中心和服務監控中心對服務本身的實際調用和 消息傳輸是完全解耦的，這也是dubbo本身實現高可用性和高可靠性的一個基礎。

dubbo當前的實現機制在設計ESB類服務總線的時候很多思路也可以借鑒，即其對集群的實現思路，對監控中心和服務注冊中心的實現思路。通過這 種思路的實現可以將ESB服務總線徹底設計為一種全分布式高擴展性的分布式服務總線架構模式。這將同時解決到ESB總線本身的分布式集群擴展和傳統 dubbo無法監控和審計消息日志傳輸兩方面的問題。

</div> 原文 http://blog.sina.com.cn/s/blog_493a84550102vlie.html