好久都沒有更新自己的blog了，加班多了，事情多了。每天回到自己蝸居的小房子都已經深夜10點多，加上自己最近身體確實不太好，總之，藉口多了很多。開頭廢話不能太多，還是直入正題。
簡介
在dubbo的官方網站上，是這樣來介紹的。DUBBO是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，是阿里巴巴SOA服務化治理方案的核心框架，每天爲2,000+個服務提供3,000,000,000+次訪問量支持，並被廣泛應用於阿里巴巴集團的各成員站點。從這樣一段介紹中，有這樣幾個值得我們關注的點，分佈式服務框架以及提供SOA的服務化治理。
原理
從這張圖中可以看到dubbo的整個從服務的發佈到訂閱消費的過程大致分爲5個步驟。
- start
container啓動，這裏的容器一般情況下直接是整合spring。再通過web容器來加載spring容器來啓動服務。
- register
將服務通過dubbo的url發佈到註冊中心的過程稱之爲register。
- subscribe
訂閱的過程其實也是對於消費者來說也是透明的，類似於spring的整個注入過程。通過在整合spring後的註冊中心地址來訂閱服務，有一個非常好的地方就是dubbo在訂閱的過程中，對於服務端的依賴是沒有的。就是說，在整個訂閱過程中，無論服務的啓動與否對於消費者來說都是沒有關係的。整個過程，從服務到消費是沒有耦合的。
- notify
這個過程對於註冊中心來說，是不斷的進行通信的。註冊中心有自己一套的健康管理計劃，不間斷的heartbeat來向消費者通知自己的服務註冊消息。
- invoke
其實對於dubbo的註冊中心來說，相當於一個紅娘的角色。在消費者和提供者之間提供服務的地址，最後來執行調用和被調用的其實還是服務的消費者和服務提供者。消費者通過註冊中心的地址能夠找到服務端的服務地址，這樣就可以直接調用服務的本身以此來直接調用服務。
- monitor
monitor來說，其實一個在線婚介所。由來支配各地的需求，這裏的服務併發比較集中，那麼相對來說就需要提供更多的服務節點來去更好的分發來自消費者的請求。並且能夠根據ip來分配被調用者的權重等相關的配置信息。
特點
Dubbo缺省協議，使用基於mina1.1.7+hessian3.2.1的tbremoting交互。
連接個數：單連接 連接方式：長連接 傳輸協議：TCP 傳輸方式：NIO異步傳輸 序列化：Hessian二進制序列化
適用範圍：傳入傳出參數數據包較小（建議小於100K），消費者比提供者個數多，單一消費者無法壓滿提供者，儘量不要用dubbo協議傳輸大文件或超大字符串。
適用場景：常規遠程服務方法調用
對於一個小成本的互聯網公司，或者是一個正在從傳統行業轉型的一個公司來說，使得分佈式變得不那麼遙不可及。門檻相對來說不那麼高，能夠算是一種分佈式的一種解決方案，但是成本來說也沒有那麼高。由於底層使用的還是netty的NIO框架，其實dubbo這種基於長連接的方式，註定dubbo在使用過程中，有一定的侷限性。比如： 由於這種長連接的方式，那麼就需要結合需求來儘量的在局域網使用dubbo的這種的通信方式。
另外基於這種組件的模式開發，組件的之間強依賴強耦合減少，不僅僅是組件之間在消費者和提供者之間也對應沒有了耦合。Dubbo缺省協議採用單一長連接和NIO異步通訊，使用於這種短消息但併發量較高的場景。
注：dubbo官網地址：http://dubbo.io/Home-zh.htm
