您好,登錄后才能下訂單哦!
Dubbo是一個被國內很多互聯網公司廣泛使用的開源分布式服務治理框架,是一個非常全面的SOA基礎框架,當當網在Dubbo基礎上新增了一些功能,并將其命名為Dubbox(Dubbo eXtensions)。
為什么需要Dubbo?
以前所有的業務處理,都在一個系統當中;
接著,這個大系統按照業務領域劃分為N個業務系統;
各個業務系統之間不可避免需要交互,采用什么呢?HTTP的方式?WebService?...
我們將面臨很多URL的管理,服務之間的調用鏈,依賴關系,服務的負載均衡、監控等等
Dubbo是什么?
Dubbo本質上就是一個分布式服務調用的東西,高性能透明化的RPC調用方案 + SOA服務治理方案。
Dubbo的架構:
第一,Dubbo有一個注冊中心Registry的概念,服務的提供者Provider將服務注冊到Registry,消費者Consumer需要從Registry中發現、監聽到服務的變動;
第二,Provider需要運行在Container容器中,另外Dubbo提供Monitor來對服務的調用次數以及調用時間進行監控。
第三,常用的Registry有Zookeeper,Redis等;博主將采用Zookeeper作為注冊中心。(可以參考:《分布式利器Zookeeper(一)》)
OK,說了一些理論,咱們快速開始吧!
這里我將為大家演示一個訂單服務調用商品服務的Demo。
我們先來看看商品服務的工程結構:
ProductService工程,下面分為2個Module:一個是product-api,一個是product-service。要知道,所謂的發布服務,就是將接口對外暴露,生產者和消費者都是需要引用接口的,所以在這里接口將在product-api中提供。
在product-service模塊中依賴product-api并實現接口:
注意Product需要實現序列化Serializable接口。
從XML中你可以發現,我們需要在product-service模塊中依賴dubbo、Zookeeper、Curator。(我這里就不貼XML呢)
每一個服務都有一個Name,其實也可以指定Owner。
注冊中心采用Zookeeper,客戶端采用Curator框架。
Dubbo其實是支持很多協議,上述指明了是采用Dubbo協議,對外的服務端口是20880。
我們需要發布服務,就是向Zookeeper注冊,告訴我們對外提供的接口是什么,以及該接口對應的服務實現是什么。
啟動商品服務:
這種啟動方式到底做了些什么?從哪里讀取的配置文件?啟動又是怎么回事呢?
我們稍微來看一看源碼:
看SpringContainer如何啟動:
OK,到這里,商品服務已經就緒了!
先看依賴:
注意訂單服務需要依賴product-api。
看dubbo配置:
消費者啟動:
消費者運行結果:
看Zookeeper:
在Zookeeper中看得很清楚,接口將以目錄節點的形式創建,providers下面就是接口協議,分機器,分協議,從而可以實現負載均衡!
如同rocketmq一樣,dubbo也提供給了dubbo-admin.war,直接部署到Tomcat下,并修改下dubbo.properties指定好注冊中心地址即可。
透明化的遠程調用,如同調用本地方法一樣,只需要簡單配置,沒有任何API侵入!
我們可以平滑的增加、減少機器,消費者能夠動態的查找到服務提供方,使得我們的服務避免了單點問題,強大的容錯機制以及軟負載能力(要知道硬件負載器F5是很貴的)。
dubbo和Spring結合緊密,透明化的接入應用!
本篇博客不可能將Dubbo全部的特性、配置都講解完,因此這里提出一些問題,來和大家一起思考學習:
1.A服務依賴B服務,如果B服務沒有啟動或者禁用,A服務是否能夠啟動?Dubbo是否會替我們做服務依賴調用檢查呢?
2.我們是否可以繞開注冊中心,直接調用呢?
3.考慮這樣一種情況,如果A調用B,出現了網絡抖動,調用異常,這個時候dubbo是否會替我們重試調用?如果dubbo有重試機制,那么是否意味著存在重復調用?如果我們的服務是一個對數據庫的操作,那么這種重試機制是否會造成影響或是問題?我們應該如何處理?(好像想起了RocketMQ的一些事情....哈哈)
4.dubbo提供了哪些負載均衡的機制?可以具體到每一個方法么?
5.服務的調用,到了Server端,最后肯定是要走線程池進行調用的,那么我們根據不同場景可以對線程池進行定制么?
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。