Dubbo+Zookeeper(二）Dubbo架構

上次更新博客已是一年前，這一年發生了不少事，並不順利，甚至有些痛苦，不過無論怎樣，不要中止學習，只有學習才能讓你變強，應對更多不安定。

1、RPC概念

Dubbo服務是一個RPC框架，那咱們首先就要先理解什麼叫作RPC， Remote Procedure Call 即遠程過程調用。

遠程過程調用相對的是本地過程調用，本地過程調用就不用說了，簡單理解成本地方法調用函數便可，而遠程調用是指調用另外一個地址空間（一般是共享網絡的另外一臺機器上）的過程或函數。而不用程序員顯式編碼這個遠程調用的細節。即程序員不管是調用本地的仍是遠程的函數，本質上編寫的調用代碼基本相同。

RPC的基本架構圖以下：

 

 RPC框架就是圖中的client stub 和說server stub，服務間要相互調用，須要先創建鏈接。當客戶端調用client stub，可能須要傳遞參數，而在網絡間傳遞，須要進行序列化，序列化徹底後將須要調用的消息發送給server stub，服務端收到信息後，先反序列化，而後再調用本地服務，調用完本地服務後，返回處理結果，結果也須要進行序列化，序列化完成以後再返回消息，而client stub 收到消息，也須要再次反序列化，再轉換成調用結果，這就是一個完整的RPC過程，如圖所示：

 

 

RPC 框架就是要實現像那小助手同樣的東西，目的就是讓咱們使用遠程調用像本地調用同樣簡單方便，而且解決一些遠程調用會發生的一些問題 ，對於咱們來講是無感知的。

在示例圖中咱們也能夠看出，RPC的核心模塊就是通信，序列化。

那若是讓咱們來設計一個RPC框架，咱們的設計思路應該是怎麼樣的呢？

首先從服務調用者開始，這是一個消費方，咱們要消費一個服務，那麼這種服務應該是一個接口形式的，這個接口通常是一個公用jar包來定義，當我知道須要調用什麼接口時，具體的實現不須要清楚，這些都應該是框架代理來作的，我只須要帶接口和參數便可。

消費方不須要知道其中細節，不須要知道要調用那臺服務器上的服務，這個時候應該有一個註冊中心，這個註冊中心有點相似公司大樓的前臺物業，他負責指引來客人找到找入駐本棟大樓的公司，每一個公司相似服務提供者，公司入駐大大樓後，將本身的樓層和門牌號告訴前臺，前臺把公司的狀況貼在前臺指引，那麼當有人要找到公司提供服務時，能夠直接經過門牌找到想要去的公司，而這個公司搬走後，前臺物業又將此公司去掉，消費者須要的服務器是能夠直接找到對應公司。

固然，若是你直接告訴了客戶你的具體位置，那麼客戶能夠不須要去註冊中心找你，也就是註冊中心能夠不須要。

那做爲服務提供者，你要告訴別人你公司能提供的服務器，去實現對應的接口 ，而後暴露出去，也就是去向註冊中心註冊本身，暴露本身所能提供的服務。 而後有消費者請求過來須要處理，提供者須要用和消費者協商好的協議來處理這個請求，而後作反序列化。

面對衆多的服務，精細化的監控和方便的運維必不可少。 這個時候咱們須要監控運維 ，也就是監控中心，固然若是你要這麼莽，就是不須要監控，固然也是能夠的。

到此，咱們能想到的架構就是如此，接下里咱們就來看看dubbo設計（固然，我是經過實際架構反推出來，手動狗頭）

2、Dubbo 核心概念

Dubbo 是阿里巴巴 2011年開源的一個基於 Java 的 RPC 框架，中間沉寂了一段時間，不過其餘一些企業還在用 Dubbo 並本身作了擴展，好比噹噹網的 Dubbox，還有網易考拉的 Dubbok。

在 2018 年和 Dubbox 進行了合併，而且進入 Apache 孵化器，在 2019 年正式成爲 Apache 頂級項目。

學習一門技術，若是有官網的話咱們儘可能從官網上學習：http://dubbo.apache.org/

首先咱們要知道Dubbo有哪些特性：

• 面向接口代理的高性能RPC調用： 提供高性能的基於代理的遠程調用能力，服務以接口爲粒度，爲開發者屏蔽遠程調用底層細節。

• 智能負載均衡： 內置多種負載均衡策略，智能感知下游節點健康情況，顯著減小調用延遲，提升系統吞吐量。

• 服務自動註冊與發現： 支持多種註冊中心服務，服務實例上下線實時感知。

• 高度可擴展能力： 遵循微內核+插件的設計原則，全部核心能力如Protocol、Transport、Serialization被設計爲擴展點，平等對待內置實現和第三方實現。

• 運行期流量調度： 內置條件、腳本等路由策略，經過配置不一樣的路由規則，輕鬆實現灰度發佈，同機房優先等功能。

• 可視化的服務治理與運維： 提供豐富服務治理、運維工具：隨時查詢服務元數據、服務健康狀態及調用統計，實時下發路由策略、調整配置參數。

3、架構圖

咱們先來看看架構圖：

 

 

架構分爲5個節點：

服務提供者（ Provider ）：暴露服務的服務提供方，服務提供者在啓動時，向註冊中心註冊本身提供的服務。

服務消費者（ Consumer ）: 調用遠程服務的服務消費方，服務消費者在啓動時，向註冊中心訂閱本身所需的服務，服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。

註冊中心（ Registry ）：註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者

監控中心（ Monitor ）：服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心

服務運行容器 （ Container ） ：負責啓動，加載，運行服務提供者

他們的調用關係以下：

1. 服務容器負責啓動，加載，運行服務提供者。

2. 服務容器負責啓動，加載，運行服務提供者。

3. 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。

4. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。

5. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。

6. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

dubbo的架構很是清晰，也很容易理解，咱們在學習的時候，先了解清楚架構狀況，而後學會使用，而後再去看源碼，瞭解基礎的代碼結構。

4、特性

Dubbo 架構具備如下幾個特色，分別是連通性、健壯性、伸縮性。

連通性：

• 註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小

• 監控中心負責統計各服務調用次數，調用時間等，統計先在內存彙總後每分鐘一次發送到監控中心服務器，並以報表展現

• 服務提供者向註冊中心註冊其提供的服務，並彙報調用時間到監控中心，此時間不包含網絡開銷

• 服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，同時彙報調用時間到監控中心，此時間包含網絡開銷

• 註冊中心，服務提供者，服務消費者三者之間均爲長鏈接，監控中心除外

• 註冊中心經過長鏈接感知服務提供者的存在，服務提供者宕機，註冊中心將當即推送事件通知消費者

• 註冊中心和監控中心所有宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表

• 註冊中心和監控中心都是可選的，服務消費者能夠直連服務提供者

健壯性：

• 監控中心宕掉不影響使用，只是丟失部分採樣數據

• 數據庫宕掉後，註冊中心仍能經過緩存提供服務列表查詢，但不能註冊新服務

• 註冊中心對等集羣，任意一臺宕掉後，將自動切換到另外一臺

• 註冊中心所有宕掉後，服務提供者和服務消費者仍能經過本地緩存通信

• 服務提供者無狀態，任意一臺宕掉後，不影響使用

• 服務提供者所有宕掉後，服務消費者應用將沒法使用，並沒有限次重連等待服務提供者恢復

伸縮性：

• 註冊中心爲對等集羣，可動態增長機器部署實例，全部客戶端將自動發現新的註冊中心

• 服務提供者無狀態，可動態增長機器部署實例，註冊中心將推送新的服務提供者信息給消費者

好了，Dubbo架構咱們有了基礎的瞭解，接下來，咱們開始實際例子的開發。