http://songfeng-123.iteye.com/blog/2306832

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

       Remoting: 網路通訊框架，實現了 sync-over-async 和 request-response 訊息機制.
       RPC: 一個遠端過程呼叫的抽象，支援負載均衡、容災和叢集功能
       Registry: 服務目錄框架用於服務的註冊和服務事件釋出和訂閱

連通性說明

       註冊中心負責服務地址的註冊與查詢，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心互動，註冊中心不轉發請求，壓力較小；監控中心負責統計各服務呼叫次數，呼叫時間等，統計先在記憶體彙總後每分鐘一次傳送到監控中心伺服器，並以報表展示。

服務提供者向註冊中心註冊其提供的服務，並彙報呼叫時間到監控中心，此時間不包含網路開銷；服務消費者向註冊中心獲取服務提供者地址列表，並根據負載演算法直接呼叫提供者，同時彙報呼叫時間到監控中心，此時間包含網路開銷。
       註冊中心，服務提供者，服務消費者三者之間均為長連線，監控中心除外；註冊中心通過長連線感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者；註冊中心和監控中心全部宕機，不影響已執行的提供者和消費者，消費者在本地快取了提供者列表；註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者。

健狀性說明

       監控中心宕掉不影響使用，只是丟失部分取樣資料；資料庫宕掉後，註冊中心仍能通過快取提供服務列表查詢，但不能註冊新服務。

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

伸縮性說明

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

       以上內容是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無法監控和審計訊息日誌傳輸兩方面的問題。