Dubbo+Zookeeper(二）Dubbo架構

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

一、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設計（當然，我是通過實際架構反推出來，手動狗頭）

二、Dubbo 核心概念

Dubbo 是阿里巴巴 2011年開源的一個基于 Java 的 RPC 框架，中間沉寂了一段時間，不過其他一些企業還在用 Dubbo 并自己做了擴展，比如當當網的 Dubbox，還有網易考拉的 Dubbok，

在 2018 年和 Dubbox 進行了合并，并且進入 Apache 范訓器，在 2019 年正式成為 Apache 頂級專案，

學習一門技術，如果有官網的話我們盡量從官網上學習：http://dubbo.apache.org/

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

• 面向介面代理的高性能RPC呼叫： 提供高性能的基于代理的遠程呼叫能力，服務以介面為粒度，為開發者屏蔽遠程呼叫底層細節，

• 智能負載均衡： 內置多種負載均衡策略，智能感知下游節點健康狀況，顯著減少呼叫延遲，提高系統吞吐量，

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

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

• 運行期流量調度： 內置條件、腳本等路由策略，通過配置不同的路由規則，輕松實作灰度發布，同機房優先等功能，

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

三、架構圖

我們先來看看架構圖：

架構分為5個節點：

服務提供者（ Provider ）：暴露服務的服務提供方，服務提供者在啟動時，向注冊中心注冊自己提供的服務，

服務消費者（ Consumer ）: 呼叫遠程服務的服務消費方，服務消費者在啟動時，向注冊中心訂閱自己所需的服務，服務消費者，從提供者地址串列中，基于軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫，

注冊中心（ Registry ）：注冊中心回傳服務提供者地址串列給消費者，如果有變更，注冊中心將基于長連接推送變更資料給消費者

監控中心（ Monitor ）：服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘發送一次統計資料到監控中心

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

他們的呼叫關系如下：

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

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

3. 服務消費者在啟動時，向注冊中心訂閱自己所需的服務，

4. 注冊中心回傳服務提供者地址串列給消費者，如果有變更，注冊中心將基于長連接推送變更資料給消費者，

5. 服務消費者，從提供者地址串列中，基于軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫，

6. 服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘發送一次統計資料到監控中心，

dubbo的架構非常清晰，也很容易理解，我們在學習的時候，先了解清楚架構情況，然后學會使用，然后再去看原始碼，了解基礎的代碼結構，

四、特性

Dubbo 架構具有以下幾個特點，分別是連通性、健壯性、伸縮性，

連通性：

• 注冊中心負責服務地址的注冊與查找，相當于目錄服務，服務提供者和消費者只在啟動時與注冊中心互動，注冊中心不轉發請求，壓力較小

• 監控中心負責統計各服務呼叫次數，呼叫時間等，統計先在記憶體匯總后每分鐘一次發送到監控中心服務器，并以報表展示

• 服務提供者向注冊中心注冊其提供的服務，并匯報呼叫時間到監控中心，此時間不包含網路開銷

• 服務消費者向注冊中心獲取服務提供者地址串列，并根據負載演算法直接呼叫提供者，同時匯報呼叫時間到監控中心，此時間包含網路開銷

• 注冊中心，服務提供者，服務消費者三者之間均為長連接，監控中心除外

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

• 注冊中心和監控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地快取了提供者串列

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

健壯性：

• 監控中心宕掉不影響使用，只是丟失部分采樣資料

• 資料庫宕掉后，注冊中心仍能通過快取提供服務串列查詢，但不能注冊新服務

• 注冊中心對等集群，任意一臺宕掉后，將自動切換到另一臺

• 注冊中心全部宕掉后，服務提供者和服務消費者仍能通過本地快取通訊

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

• 服務提供者全部宕掉后，服務消費者應用將無法使用，并無限次重連等待服務提供者恢復

伸縮性：

• 注冊中心為對等集群，可動態增加機器部署實體，所有客戶端將自動發現新的注冊中心

• 服務提供者無狀態，可動態增加機器部署實體，注冊中心將推送新的服務提供者資訊給消費者

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

標籤：其他

上一篇：Dubbo+Zookeeper(二）Dubbo架構

下一篇：聊一聊，面試為什么大廠鐘愛問原始碼，真的是（問）造火箭=＞（做）擰螺絲？如何讀原始碼？