分佈式服務治理框架Dubbo

前言

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，說了一些理論，我們快速開始吧！

QuickStart 

這裏我將爲你們演示一個訂單服務調用商品服務的Demo。

商品服務：ProductService

咱們先來看看商品服務的工程結構：

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，到這裏，商品服務已經就緒了！

訂單服務：OrderService

先看依賴：

注意訂單服務須要依賴product-api。

看dubbo配置：

消費者啓動：

消費者運行結果：

看Zookeeper：

在Zookeeper中看得很清楚，接口將以目錄節點的形式建立，providers下面就是接口協議，分機器，分協議，從而能夠實現負載均衡！

dubbo-admin管控臺

如同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端，最後確定是要走線程池進行調用的，那麼咱們根據不一樣場景能夠對線程池進行定製麼？