dubbo的詳細介紹

1.背景

　　隨着互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已沒法應對，分佈式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。

 

2.架構

　　單一應用架構
　　　　當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。
　　　　此時，用於簡化增刪改查工做量的 數據訪問框架(ORM) 是關鍵。

　　垂直應用架構
　　　　當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。
　　　　此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。

　　分佈式服務架構
　　　　當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
　　　　此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵。

　　流動計算架構
　　　　當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。
　　　　此時，用於提升機器利用率的 資源調度和治理中心(SOA) 是關鍵。

 

3.dubbox

　　dubbox是dubbo的擴展，主要在dubbo的基礎上進行了一下的改進　　

　　一、支持REST風格遠程調用（HTTP + JSON/XML)：基於很是成熟的JBoss RestEasy框架，在dubbo中實現了REST風格（HTTP + JSON/XML）的遠程調用，以顯著簡化企業內部的跨語言交互，同時顯著簡化企業對外的Open API、無線API甚至AJAX服務端等等的開發。事實上，這個REST調用也使得Dubbo能夠對當今特別流行的「微服務」架構提供基礎性支持。 另外，REST調用也達到了比較高的性能，在基準測試下，HTTP + JSON與Dubbo 2.x默認的RPC協議（即TCP + Hessian2二進制序列化）之間只有1.5倍左右的差距，詳見文檔中的基準測試報告。

　　二、支持基於Kryo和FST的Java高效序列化實現：基於當今比較知名的Kryo和FST高性能序列化庫，爲Dubbo默認的RPC協議添加新的序列化實現，並優化調整了其序列化體系，比較顯著的提升了Dubbo RPC的性能，詳見文檔中的基準測試報告。

　　三、支持基於Jackson的JSON序列化：基於業界應用最普遍的Jackson序列化庫，爲Dubbo默認的RPC協議添加新的JSON序列化實現。

　　四、支持基於嵌入式Tomcat的HTTP remoting體系：基於嵌入式tomcat實現dubbo的HTTP remoting體系（即dubbo-remoting-http），用以逐步取代Dubbo中舊版本的嵌入式Jetty，能夠顯著的提升REST等的遠程調用性能，並將Servlet API的支持從2.5升級到3.1。（注：除了REST，dubbo中的WebServices、Hessian、HTTP Invoker等協議都基於這個HTTP remoting體系）。

　　五、升級Spring：將dubbo中Spring由2.x升級到目前最經常使用的3.x版本，減小版本衝突帶來的麻煩。

　　六、升級ZooKeeper客戶端：將dubbo中的zookeeper客戶端升級到最新的版本，以修正老版本中包含的bug。

　　七、支持徹底基於Java代碼的Dubbo配置：基於Spring的Java Config，實現徹底無XML的純Java代碼方式來配置dubbo

　　八、調整Demo應用：暫時將dubbo的demo應用調整並改寫以主要演示REST功能、Dubbo協議的新序列化方式、基於Java代碼的Spring配置等等。
　　九、修正了dubbo的bug 包括配置、序列化、管理界面等等的bug。

 

4.Dubbo框架

　　

　　一、Provider:暴露服務的服務提供方。 Consumer: 調用遠程服務的服務消費方。

　　二、Registry:服務註冊與發現的註冊中心。 Monitor: 統計服務的調用次調和調用時間的監控中心。

　　三、Container: 服務運行容器

 

5.Dubbo的調用關係

　　一、服務容器負責啓動，加載，運行服務提供者。 
　　二、服務提供者在啓動時，向註冊中心註冊本身提供的服務。 
　　三、服務消費者在啓動時，向註冊中心訂閱本身所需的服務。 
　　四、註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。 
　　五、服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。 
　　六、服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

 

6.Dubbo特色

　　http://www.cnblogs.com/juncaoit/p/7567657.html

 

7.Dubbo調用方式

• 異步調用

　　基於NIO的非阻塞實現並行調用，客戶端不須要啓動多線程便可完成並行調用多個遠程服務，相對多線程開銷較小

　　

　　

• 本地調用

　　本地調用，使用了Injvm協議，是一個僞協議，它不開啓端口，不發起遠程調用，只在JVM內直接關聯，但執行Dubbo的Filter鏈。

　　Define injvm protocol:

　　　　<dubbo:protocol name="injvm" />

　　Set default protocol:

　　　　<dubbo:provider protocol="injvm" />

　　Set service protocol:

　　　　<dubbo:service protocol="injvm" />

　　Use injvm first:（服務暴露與服務引用都須要聲明injvm=「true」）

　　<dubbo:consumer injvm="true" .../> 　　<dubbo:provider injvm="true" .../> 　　或 　　<dubbo:reference injvm="true" .../> 　　<dubbo:service injvm="true" .../>

8.Dubbo支持的註冊中心

• Multicast註冊中心
• Zookeeper註冊中心
• Redis註冊中心
• Simple註冊中心

　　Multicast：不須要啓動任何中心節點，只要廣播地址同樣，就能夠互相發現

　　　　　　　組播受網絡結構限制，只適合小規模應用或開發階段使用。

　　　　　　　組播地址段: 224.0.0.0 - 239.255.255.255

　　Zookeeper：是Apacahe Hadoop的子項目，是一個樹型的目錄服務，支持變動推送，適合做爲Dubbo服務的註冊中心，工業強度較高

　　　　　　　 只需搭一個原生的Zookeeper服務器，

　　　　　　　並將Provider和Consumer裏的dubbo.properties中的dubbo.registry.addrss的值改成zookeeper://127.0.0.1:2181便可使用
　　　　　　　阿里內部並無採用Zookeeper作爲註冊中心，而是使用本身實現的基於數據庫的註冊中心，即：Zookeeper註冊中心並無在阿里
內部長時間運行的可靠性保障，其可靠性依賴於Zookeeper自己的可靠性。

　　　　　　　ZooKeeper集羣由一組Server節點組成，這一組Server節點中存在一個角色爲Leader的節點，其餘節點都爲Follower。當客戶端Client鏈接到ZooKeeper集羣，而且執行寫請求時，這些請求會被髮送到Leader節點上，而後Leader節點上數據變動會同步到集羣中其餘的Follower節點。

　　　　　　　　

　　　　流程說明：

• • 服務提供者啓動時
    • 　　向/dubbo/com.foo.BarService/providers目錄下寫入本身的URL地址。
  • 服務消費者啓動時
    • 　　訂閱/dubbo/com.foo.BarService/providers目錄下的提供者URL地址。
    • 　　並向/dubbo/com.foo.BarService/consumers目錄下寫入本身的URL地址。
  • 監控中心啓動時
    • 　　訂閱/dubbo/com.foo.BarService目錄下的全部提供者和消費者URL地址。

　　　　支持如下功能：

• • 　　當提供者出現斷電等異常停機時，註冊中心能自動刪除提供者信息。
  • 　　當註冊中心重啓時，能自動恢復註冊數據，以及訂閱請求。
  • 　　當會話過時時，能自動恢復註冊數據，以及訂閱請求。
  • 　　當設置<dubbo:registry check="false" />時，記錄失敗註冊和訂閱請求，後臺定時重試。
  • 　　可經過<dubbo:registry username="admin" password="1234" />設置zookeeper登陸信息。
  • 　　可經過<dubbo:registry group="dubbo" />設置zookeeper的根節點，不設置將使用無根樹。
  • 　　支持*號通配符<dubbo:reference group="*" version="*" />，可訂閱服務的全部分組和全部版本的提供者

　　　　在provider和consumer中增長zookeeper客戶端jar包依賴

　　　　支持zkclient和curator兩種Zookeeper客戶端實現

　　Simple註冊中心：

　　　　註冊中心自己就是一個普通的Dubbo服務，能夠減小第三方依賴，使總體通信方式一致。

　　

9.Dubbo支持的遠程通訊協議

• Mina
• Netty
• Grizzly

 　

10.Dubbo支持的遠程調用協議

• Dubbo協議
• Hessian協議
• HTTP協議
• RMI協議
• WebService協議
• Thrift協議
• Memcached協議
• Redis協議

　　在通訊過程當中，不一樣的服務等級通常對應着不一樣的服務質量，那麼選擇合適的協議即是一件很是重要的事情。

 

11.Dubbo的容錯

　　在集羣調用失敗時，Dubbo提供了多種容錯方案，缺省爲failover重試。

• Failover Cluster
  失敗自動切換，當出現失敗，重試其它服務器。(缺省)
  一般用於讀操做，但重試會帶來更長延遲。
  可經過retries=「2」來設置重試次數(不含第一次)。

• Failfast Cluster
  快速失敗，只發起一次調用，失敗當即報錯。
  一般用於非冪等性的寫操做，好比新增記錄。

• Failsafe Cluster
  失敗安全，出現異常時，直接忽略。
  一般用於寫入審計日誌等操做。

• Failback Cluster
  失敗自動恢復，後臺記錄失敗請求，定時重發。
  一般用於消息通知操做。

• Forking Cluster
  並行調用多個服務器，只要一個成功即返回。
  一般用於實時性要求較高的讀操做，但須要浪費更多服務資源。
  可經過forks=「2」來設置最大並行數。

• Broadcast Cluster
  廣播調用全部提供者，逐個調用，任意一臺報錯則報錯。(2.1.0開始支持)
  一般用於通知全部提供者更新緩存或日誌等本地資源信息。

 

12.負載均衡

 　　

13.源碼結構

　　

　　各個模塊之間的關係：

　　

• 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 容器模塊，是一個Standalone的容器，以簡單的Main加載Spring啓動，由於服務一般不須要Tomcat/JBoss等Web容器的特性，不必用Web容器去加載服務。