添加筆者微信15934876140獲取網盤視頻教程
1.背景
隨着互聯網的發展,網站應用的規模不斷擴大,常規的垂直應用架構已無法應對,分佈式服務架構以及流動計算架構勢在必行,亟需一個治理系統確保架構有條不紊的演進。
2.架構
單一應用架構
當網站流量很小時,只需一個應用,將所有功能都部署在一起,以減少部署節點和成本。
此時,用於簡化增刪改查工作量的 數據訪問框架(ORM) 是關鍵。
垂直應用架構
當訪問量逐漸增大,單一應用增加機器帶來的加速度越來越小,將應用拆成互不相干的幾個應用,以提升效率。
此時,用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
分佈式服務架構
當垂直應用越來越多,應用之間交互不可避免,將核心業務抽取出來,作爲獨立的服務,逐漸形成穩定的服務中心,使前端應用能更快速的響應多變的市場需求。
此時,用於提高業務複用及整合的 分佈式服務框架(RPC) 是關鍵。
流動計算架構
當服務越來越多,容量的評估,小服務資源的浪費等問題逐漸顯現,此時需增加一個調度中心基於訪問壓力實時管理集羣容量,提高集羣利用率。
此時,用於提高機器利用率的 資源調度和治理中心(SOA) 是關鍵。
3.dubbox
dubbox是dubbo的擴展,主要在dubbo的基礎上進行了一下的改進
1、支持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倍左右的差距,詳見文檔中的基準測試報告。
2、支持基於Kryo和FST的Java高效序列化實現:基於當今比較知名的Kryo和FST高性能序列化庫,爲Dubbo默認的RPC協議添加新的序列化實現,並優化調整了其序列化體系,比較顯著的提高了Dubbo RPC的性能,詳見文檔中的基準測試報告。
3、支持基於Jackson的JSON序列化:基於業界應用最廣泛的Jackson序列化庫,爲Dubbo默認的RPC協議添加新的JSON序列化實現。
4、支持基於嵌入式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體系)。
5、升級Spring:將dubbo中Spring由2.x升級到目前最常用的3.x版本,減少版本衝突帶來的麻煩。
6、升級ZooKeeper客戶端:將dubbo中的zookeeper客戶端升級到最新的版本,以修正老版本中包含的bug。
7、支持完全基於Java代碼的Dubbo配置:基於Spring的Java Config,實現完全無XML的純Java代碼方式來配置dubbo
8、調整Demo應用:暫時將dubbo的demo應用調整並改寫以主要演示REST功能、Dubbo協議的新序列化方式、基於Java代碼的Spring配置等等。
9、修正了dubbo的bug 包括配置、序列化、管理界面等等的bug。
4.Dubbo框架
1、Provider:暴露服務的服務提供方。 Consumer: 調用遠程服務的服務消費方。
2、Registry:服務註冊與發現的註冊中心。 Monitor: 統計服務的調用次調和調用時間的監控中心。
3、Container: 服務運行容器
5.Dubbo的調用關係
1、服務容器負責啓動,加載,運行服務提供者。
2、服務提供者在啓動時,向註冊中心註冊自己提供的服務。
3、服務消費者在啓動時,向註冊中心訂閱自己所需的服務。
4、註冊中心返回服務提供者地址列表給消費者,如果有變更,註冊中心將基於長連接推送變更數據給消費者。
5、服務消費者,從提供者地址列表中,基於軟負載均衡算法,選一臺提供者進行調用,如果調用失敗,再選另一臺調用。
6、服務消費者和提供者,在內存中累計調用次數和調用時間,定時每分鐘發送一次統計數據到監控中心。
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容器去加載服務。