SpringBoot | 第二十九章：Dubbo的整合和使用
一點知識
對於沒有接觸過Dubbo的同學，可以先了解下相關知識。
Dubbo簡介
Dubbo 是阿里巴巴公司一個開源的高效能服務框架，致力於提供高效能和透明化的 RPC 遠端服務呼叫方案，以及 SOA 服務治理方案，使得應用可通過高效能 RPC 實現服務的輸出、輸入功能和 Spring 框架無縫整合。Dubbo 包含遠端通訊、叢集容錯和自動發現三個核心部分。
它提供透明化的遠端方法呼叫，實現像呼叫本地方法一樣呼叫遠端方法，只需簡單配置，沒有任何 API 侵入。同時它具備軟負載均衡及容錯機制，可在內網替代 F5 等硬體負載均衡器，降低成本，減少單點。它可以實現服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於介面名查詢服務提供者的 IP 地址，並且能夠平滑新增或刪除服務提供者。
2011 年末，阿里巴巴在 GitHub 上開源了基於 Java 的分散式服務治理框架 Dubbo，之後它成為了國內該類開源專案的佼佼者，許多開發者對其表示青睞。同時，先後有不少公司在實踐中基於 Dubbo 進行分散式系統架構。目前在 GitHub 上，它的 fork、star 數均已破萬。
Dubbo核心功能:
- 遠端通訊，提供對多種基於長連線的 IO/">NIO 框架抽象封裝，包括多種執行緒模型，序列化，以及“請求-響應”模式的資訊交換方式。
- 叢集容錯，提供基於介面方法的透明遠端過程呼叫，包括多協議支援，以及軟負載均衡，失敗容錯，地址路由，動態配置等叢集支援。
- 自動發現，基於註冊中心目錄服務，使服務消費方能動態的查詢服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
Dubbo架構
- 服務提供者 - 啟動時在指定埠上暴露服務，並將服務地址和埠註冊到註冊中心上
- 服務消費者 - 啟動時向註冊中心訂閱自己感興趣的服務，以便獲得服務提供方的地址列表
- 註冊中心 - 負責服務的註冊和發現，負責儲存服務提供方上報的地址資訊，並向服務消費方推送
- 監控中心 - 負責收集服務提供方和消費方的執行狀態，比如服務呼叫次數、延遲等，用於監控
- 執行容器 - 負責服務提供方的初始化、載入以及執行的生命週期管理
部署階段
- 服務提供者在指定埠暴露服務，並向註冊中心註冊服務資訊。
- 服務消費者向註冊中心發起服務地址列表的訂閱。
執行階段
- 註冊中心向服務消費者推送地址列表資訊。
- 服務消費者收到地址列表後，從其中選取一個向目標服務發起呼叫。
- 呼叫過程服務消費者和服務提供者的執行狀態上報給監控中心。
呼叫關係說明
- 服務容器負責啟動，載入，執行服務提供者。
- 服務提供者在啟動時，向註冊中心註冊自己提供的服務。
- 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
- 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
- 服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。
- 服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。
Dubbo特點
Dubbo 架構具有以下幾個特點，分別是連通性、健壯性、伸縮性、以及向未來架構的升級性。
連通性
- 註冊中心負責服務地址的註冊與查詢，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心互動，註冊中心不轉發請求，壓力較小
- 監控中心負責統計各服務呼叫次數，呼叫時間等，統計先在記憶體彙總後每分鐘一次傳送到監控中心伺服器，並以報表展示
- 服務提供者向註冊中心註冊其提供的服務，並彙報呼叫時間到監控中心，此時間不包含網路開銷
- 服務消費者向註冊中心獲取服務提供者地址列表，並根據負載演算法直接呼叫提供者，同時彙報呼叫時間到監控中心，此時間包含網路開銷
- 註冊中心，服務提供者，服務消費者三者之間均為長連線，監控中心除外
- 註冊中心通過長連線感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者
- 註冊中心和監控中心全部宕機，不影響已執行的提供者和消費者，消費者在本地快取了提供者列表
- 註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者
健壯性
- 監控中心宕掉不影響使用，只是丟失部分取樣資料
- 資料庫宕掉後，註冊中心仍能通過快取提供服務列表查詢，但不能註冊新服務
- 註冊中心對等叢集，任意一臺宕掉後，將自動切換到另一臺
- 註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地快取通訊
- 服務提供者無狀態，任意一臺宕掉後，不影響使用
- 服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復
伸縮性
- 註冊中心為對等叢集，可動態增加機器部署例項，所有客戶端將自動發現新的註冊中心
- 服務提供者無狀態，可動態增加機器部署例項，註冊中心將推送新的服務提供者資訊給消費者
升級性
當服務叢集規模進一步擴大，帶動IT治理結構進一步升級，需要實現動態部署，進行流動計算，現有分散式服務架構不會帶來阻力。下圖是未來可能的一種架構：
節點角色說明
| 節點 | 角色說明 |
|---|---|
| Deployer | 自動部署服務的本地代理 |
| Repository | 倉庫用於儲存服務應用釋出包 |
| Scheduler | 排程中心基於訪問壓力自動增減服務提供者 |
| Admin | 統一管理控制檯 |
| Registry | 服務註冊與發現的註冊中心 |
| Monitor | 統計服務的呼叫次數和呼叫時間的監控中心 |
大家可訪問官網文件： ofollow,noindex" target="_blank">http://dubbo.apache.org/zh-cn/docs/user/quick-start.html ，裡面有詳細說明和使用說明的。這裡就不再闡述了。
Dubbo整合和使用
基於官方的incubator-dubbo-spring-boot-project專案，在SpringBoot中整合起來很簡單。
注意：由於本系列還是使用1.5.x版本進行講解，所以使用的版本為0.1.x。若使用SpringBoot2.x的同學，可以使用0.2.x版本。
這裡為了方便，直接建立了一個介面工程，spring-boot-dubbo-api。
IHelloService.java
服務提供者
建立一個spring-boot-dubbo-provider工程。 0.引入pom依賴。
注意：這裡直接選用了redis作為註冊中心使用。預設是zookeeper。
1.編寫介面實現類。 HelloServiceImpl.java
說明下：這裡的@Service是包路徑com.alibaba.dubbo.config.annotation.Service下的註解類，其指定了介面版本、協議id、註冊中心id等基本資訊。這裡注意還是版本號有用，因為會一個介面多版本共存問題，所以一般上都會設定版本資訊的。 2.設定配置檔案資訊，新增dubbo相關資訊，比如註冊中心型別，地址等。
注意：這裡為了方便，直接使用了Redis作為了註冊中心。對於redis連線相關配置引數，可以通過dubbo.registry.parameters.xxx的形式來進行設定，由於parameters是個Map物件，所以新增的key是不會進行大小寫轉換的，填寫了什麼就是什麼。具體的registry配置物件，可以檢視com.alibaba.dubbo.config.RegistryConfig類。而對於redis相關引數配置，可以檢視com.alibaba.dubbo.registry.redis.RedisRegistry類。
其他的註冊中心，也是類似的，大家可在包com.alibaba.dubbo.registry找到都要的註冊中心配置類。
3.啟動類編寫。
DubboProviderApplication.java
4.啟動應用，可以訪問下redis服務，可以看見已經有服務列表資訊了。
服務消費者
建立spring-boot-dubbo-consumer工程。 0.引入pom依賴
1.配置檔案添加註冊中心及服務版本相關資訊
2.啟動類編寫
DubboConsumerApplication.java
3.編寫一個restapi介面服務，進行服務呼叫。
4.啟動應用，訪問： http://127.0.0.1:9696/hello?name=oKong ，可以看見服務呼叫成功了。
監控後臺
官方監控預設支援了zookeeper。而且官方文件也說了，對於redis橋接實現只為開源版本提供，其可靠性依賴於 Redis 本身的可靠性。建議大家還是使用zookeeper吧,redis還是作為快取使用吧。
監控臺地址： https://github.com/apache/incubator-dubbo-ops 大家可自行安裝說明進行編譯執行下。
新的監控介面：
加入了Apache孵化器後，介面都是英文的了。。。還是原來的看的舒服呀！
