dubbo是alibaba開源的分布式服務框架，它最大的特點是按照分層的方式來架構，使用這種方式可以使各個層之間解耦合（或者最大限度地鬆耦合）。從服務模型的角度來看，dubbo採用的是一種非常簡單的模型，要麼是提供方提供服務，要麼是消費方消費服務，所以基於這一點可以抽象出服務提供方（provider）和服務消費方（consumer）兩個角色。關於註冊中心、協議支援、服務監控等內容，詳見後面描述。
總體架構
dubbo的總體架構，如圖所示：
dubbo框架設計一共劃分了10個層，而最上面的service層是留給實際想要使用dubbo開發分布式服務的開發者實現業務邏輯的介面層。圖中左邊淡藍背景的為服務消費方使用的介面，右邊淡綠色背景的為服務提供方使用的介面， 位於中軸線上的為雙方都用到的介面。
下面，結合dubbo官方文件，我們分別理解一下框架分層架構中，各個層次的設計要點：
配置層（config）：對外配置介面，以serviceconfig和referenceconfig為中心，可以直接new配置類，也可以通過spring解析配置生成配置類。
服務**層（proxy）：服務介面透明**，生成服務的客戶端stub和伺服器端skeleton，以serviceproxy為中心，擴充套件介面為proxyfactory。
服務註冊層（registry）：封裝服務位址的註冊與發現，以服務url為中心，擴充套件介面為registryfactory、registry和registryservice。可能沒有服務註冊中心，此時服務提供方直接暴露服務。
集群層（cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以invoker為中心，擴充套件介面為cluster、directory、router和loadbalance。將多個服務提供方組合為乙個服務提供方，實現對服務消費方來透明，只需要與乙個服務提供方進行互動。
監控層（monitor）：rpc呼叫次數和呼叫時間監控，以statistics為中心，擴充套件介面為monito***ctory、monitor和monitorservice。
遠端呼叫層（protocol）：封將rpc呼叫，以invocation和result為中心，擴充套件介面為protocol、invoker和exporter。protocol是服務域，它是invoker暴露和引用的主功能入口，它負責invoker的生命週期管理。invoker是實體域，它是dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它代表乙個可執行體，可向它發起invoke呼叫，它有可能是乙個本地的實現，也可能是乙個遠端的實現，也可能乙個集群實現。
資訊交換層（exchange）：封裝請求響應模式，同步轉非同步，以request和response為中心，擴充套件介面為exchanger、exchangechannel、exchangeclient和exchangeserver。
網路傳輸層（transport）：抽象mina和netty為統一介面，以message為中心，擴充套件介面為channel、transporter、client、server和codec。
資料序列化層（serialize）：可復用的一些工具，擴充套件介面為serialization、 objectinput、objectoutput和threadpool。
從上圖可以看出，dubbo對於服務提供方和服務消費方，從框架的10層中分別提供了各自需要關心和擴充套件的介面，構建整個服務生態系統（服務提供方和服務消費方本身就是乙個以服務為中心的）。
根據官方提供的，對於上述各層之間關係的描述，如下所示：
從上面的架構圖中，我們可以了解到，dubbo作為乙個分布式服務框架，主要具有如下幾個核心的要點：
服務定義
服務是圍繞服務提供方和服務消費方的，服務提供方實現服務，而服務消費方呼叫服務。
服務註冊
對於服務提供方，它需要發布服務，而且由於應用系統的複雜性，服務的數量、型別也不斷膨脹；對於服務消費方，它最關心如何獲取到它所需要的服務，而面對複雜的應用系統，需要管理大量的服務呼叫。而且，對於服務提供方和服務消費方來說，他們還有可能兼具這兩種角色，即既需要提供服務，有需要消費服務。
通過將服務統一管理起來，可以有效地優化內部應用對服務發布/使用的流程和管理。服務註冊中心可以通過特定協議來完成服務對外的統一。dubbo提供的註冊中心有如下幾種型別可供選擇：
服務監控
無論是服務提供方，還是服務消費方，他們都需要對服務呼叫的實際狀態進行有效的監控，從而改進服務質量。
遠端通訊與資訊交換
遠端通訊需要指定通訊雙方所約定的協議，在保證通訊雙方理解協議語義的基礎上，還要保證高效、穩定的訊息傳輸。dubbo繼承了當前主流的網路通訊框架，主要包括如下幾個：
服務呼叫
下面從dubbo官網直接拿來，看一下基於rpc層，服務提供方和服務消費方之間的呼叫關係，如圖所示：
上圖中，藍色的表示與業務有互動，綠色的表示只對dubbo內部互動。上述圖所描述的呼叫流程如下：
服務提供方發布服務到服務註冊中心；
服務消費方從服務註冊中心訂閱服務；
服務消費方呼叫已經註冊的可用服務
接著，將上面抽象的呼叫流程圖展開，詳細如圖所示：
註冊/登出服務
服務的註冊與登出，是對服務提供方角色而言，那麼註冊服務與登出服務的時序圖，如圖所示：
服務訂閱/取消
為了滿足應用系統的需求，服務消費方的可能需要從服務註冊中心訂閱指定的有服務提供方發布的服務，在得到通知可以使用服務時，就可以直接呼叫服務。反過來，如果不需要某乙個服務了，可以取消該服務。下面看一下對應的時序圖，如圖所示：
協議支援
dubbo支援多種協議，如下所示：
在通訊過程中，不同的服務等級一般對應著不同的服務質量，那麼選擇合適的協議便是一件非常重要的事情。你可以根據你應用的建立來選擇。例如，使用rmi協議，一般會受到防火牆的限制，所以對於外部與內部進行通訊的場景，就不要使用rmi協議，而是基於http協議或者hessian協議
dubbo服務提供方
dubbo服務消費方
Dubbo 分布式服務
隨著網際網路的發展，應用的規模不斷擴大，常規的垂直應用架構已無法應對，分布式服務架構以及流動計算架構勢在必行，亟需乙個治理系統確保架構有條不紊的演進。垂直應用架構 分布式服務架構 流動計算架構 在大規模服務化之前，應用可能只是通過rmi或hessian等工具，簡單的暴露和引用遠端服務，通過配置服務的...
Dubbo分布式服務子系統的劃分
一 劃分子系統的策略 按照系統的業務模組的獨立性劃分 二 劃分時服務子系統的數量的控制 過多 可能劃分過細，破壞業務子系統的獨立性，部署維護工作量大，獨立程序占用記憶體多 過少 沒能很好的解耦，開發維護不好分工，公升級維護影響面大 三 服務子系統劃分要注意的地方 3.1 不要出現a服務中的sql需要...
dubbo分布式服務子系統的劃分
1 將系統中獨立的業務模組抽取出來，按業務的獨立性進行 垂直劃分，抽象出基礎服務層。2 基礎服務為上游業務的功能實現提供支撐，基礎服務應用 本身無狀態，可隨著系統的負荷靈活伸縮來提供服務能力。過多 可能劃分過細，破壞業務子系統的獨立性 如 支付訂單 退款訂單，使用者 賬戶 部署維護工作量大，獨立程序...