Dubbo入門

開始時間：2022-03-09

課程連結：Dubbo入門

分布式

單一應用架構

當網站流量很小時， 應用規模小時， 隻需一個應用，将所有功能都部署在一起，以減少部署伺服器數量和成本。

這種結構的應用适合小型系統，小型網站，或者企業的内部系統，使用者較少，請求量不大，對請求的處理時間沒有太高的要求。 将所有功能都部署到一個伺服器，簡單易用。

缺點：

1、性能擴充比較困難

2、不利于多人同時開發

3、不利于更新維護

4、整個系統的空間占用比較大

分布式應用架構

将核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，分布式系統将服務作為獨立的應用，實作服務共享和重用。

分布式系統

分布式系統是若幹獨立計算機（伺服器） 的集合，這些計算機對于使用者來說就像單個相關系統， 分布式系統（distributed system）是建立在網絡之上的伺服器端一種結構。分布式系統中的計算機可以使用不同的作業系統，可以運作不同應用程式提供服務（微服務），将服務分散部署到多個計算機伺服器上。

如果某些業務需要更多的伺服器，那就再加上幾台伺服器。維護更加友善

例如我們自己寫的Servlet，部署在Tomcat上，

如果隻有一個Project，那麼處理的時候url傳遞不需要寫完整路徑名

但如果我有不同的project，每個project中布置在一個Tomcat上，在一個project中調用另一個project的Servlet就需要加完整路徑名了。

微服務之間的通路，使用Dubbo來實作。

Remote Procedure Call（RPC協定）

RPC 【Remote Procedure Call】 是指遠端過程調用， 是一種程序間通信方式，是一種技術思想，而不是規範。 它允許程式調用另一個位址空間（網絡的另一台機器上）的過程或函數，而不用開發人員顯式編碼這個調用的細節。

調用本地方法和調用遠端方法一樣。

RPC 的特點

1. 簡單：使用簡單，建立分布式應用更容易。
2. 高效：調用過程看起來十厘清晰，效率高。
3. 通用：程序間通訊的方式，有通用的規則。

RPC原理

左邊是client用戶端，右邊是server服務端

• client 調用遠端服務，調用client stub将方法和參數組裝成可以進行網絡傳輸的消息體（序列化的過程）
• client stub找到提供遠端服務的位址，并将消息發送過去
• server stub接受到client stub發過來的資料，然後進行反序列化，根據反序列化中的方法，參數等資訊調用本地方法

• server stub調用方法，拿到執行結果後，将結果序列化發送回client

  client的stub再反序列化為Java對象，得到最終結果

Dubbo

Dubbo 是一個分布式服務架構，緻力于提供高性能和透明化的 RPC 遠端服務調用方案、 服務治理方案。

三大核心能力：

• 面向接口的遠端方法調用，（遠端調用）
• 智能容錯和負載均衡，（負載均衡）
• 服務自動注冊和發現（服務管理）

面向接口代理：調用接口的方法，在 A 伺服器調用 B 伺服器的方法， 由 dubbo 實作對 B 的調用，無需關心實作的細節（透明），就像 MyBatis 通路 Dao 的接口，可以操作資料庫一樣。不用關心 Dao 接口方法的實作。

Dubbo基本架構

• Container： 服務運作容器，負責加載、運作服務提供者。必須。
• Provider：提供服務，比如我寫了一個Servlet，那麼這個就是提供者，并向注冊中心注冊自己提供的服務 必須。
• Registry：相當于目錄服務，服務提供者有很多家，注冊中心傳回服務提供者位址清單給消費者，如果有變更，注冊中心将基于長連接配接推送變更資料給消費者 非必須。
• Consumer：消費者，選擇調用遠端服務的服務消費方， 服務消費者在啟動時，向注冊中心訂閱自己所需的服務， 服務消費者，從提供者位址清單中，基于軟負載均衡算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。必須。
• Monitor：監控中心，服務消費者和提供者，在記憶體中累計調用次數和調用時間，定時每分鐘發送一次統計資料到監控中心 非必須

底層的實作還是通過了動态代理機制

調用端通路服務提供端的代理對象，代理對象再通路服務端的對象

代理是由Dubbo架構建立的。

Dubbo協定

預設端口号20880 （阿裡巴巴0）

采用單一長連接配接和異步通信，适合于小資料量大并發的服務調用，或者是消費者機器數遠大于服務提供者機器數（淘寶本身就是）

網絡通信預設使用的是netty

不适合用于傳送大資料量的服務，比如傳檔案和視訊

長連接配接：建好通道，大家都用這一個，适合傳資料量小的資料

短連接配接：随用随建，适合資料量大的資料（用了就釋放）

spring配置檔案中寫

使用公共接口作為獨立項目

假設一個公司做生活服務類業務，A部門負責天氣資訊，B部門負責影視咨詢，需要在公司網站同時提供兩種服務，作為網站（公共服務部門）開發人員需要使用A和B兩個小組不同服務内容。使用A組和B組兩個服務提供者的接口。

這裡就不貼代碼了，僅僅描述主要步驟

公共部門

設定dubboInterface包，建立實體類beans包：電影和天氣對象，定義實體類需要實作序列化接口

建立service包用來定義接口

定義好接口後，我們需要把整個包打包成一個jar包（存放好接口資訊）

Provider

建立dubbointerfaceImpl包，用來實作接口（實際中應該是兩個部門分别實作接口，這裡寫成一個project）

Provider實作步驟：

建立web應用-導入jar包（這裡沒有用maven配置）主要需要的幾個包時

• dubbo架構的實作jar：dubbo-2.5.3.jar
• 網絡通信的jar：netty.jar
• 動态代理的相關jar：Javassist.jar
• spring相關的jar
• 加入接口的定義jar:dubboInterface.jar
• 定義服務的實作類
• 定義spring的配置檔案：聲明服務名稱；暴露服務提供者的接口；聲明服務接口的實作類對象；

我們寫dubbo的配置檔案

聲明服務名稱

通路服務的協定名稱，端口

暴露服務提供者的接口，消費者就調用此接口的方法

<dubbo:service interface="BUPT.service.WeatherService"
ref="weatherService" registry="N/A"/>
           

聲明服務接口的實作類對象

在電影的工程中再重複上面的聲明

• 定義測試類
• 修改web.xml，注冊spring的監聽器
• 導出接口和相關的類為一個jar包，供給消費者使用

消費者

步驟：

建立Java項目

導入jar包：

dubbo架構的實作jar：dubbo-2.5.3.jar

網絡通信的jar：nett.jar

動态代理相關jar：javassist.jar

spring相關的jar：spring-*.jar

服務提供者接口的定義jar：05-dubboInterface.jar

定義spring配置檔案：consume.xml

聲明服務的名稱

<dubbo:reference interface="BUPT.service.WeatherService"
                     id="remoteWeatherService" url="dubbo://localhost:20880"/>
           

聲明要用的服務

<bean id="invokeService" class="BUPT.client.InvokeService">
<property name="remoteWs" ref="remoteWeatherService"/>
</bean>
           

常用标簽

提供者是dubbo:service

消費者是dubbo:reference

公用标簽

A、 配置應用資訊

B、 配置注冊中心

注冊中心

• 對于服務提供方，它需要釋出服務，而且由于應用系統的複雜性，服務的數量、類型也不斷膨脹；
• 對于服務消費方，它最關心如何擷取到它所需要的服務，而面對複雜的應用系統，需要管理大量的服務調用。
• 而且，對于服務提供方和服務消費方來說，他們還有可能兼具這兩種角色，即需要提供服務，有需要消費服務。
• 通過将服務統一管理起來，可以有效地優化内部應用對服務釋出使用的流程和管理。服務注冊中心可以通過特定協定來完成服務對外的統一。

注冊中心工作方式

運作順序：注冊中心-dubbo服務（向注冊中心進行登記：IP、端口、服務名稱【接口名】）-消費者通路注冊中心，服務訂閱（登記）-注冊中心将對應服務的資訊發送給消費者-消費者拿到位址（負載均衡機制）-消費者通路dubbo具體服務

注冊中心每一段時間會發送請求驗證dubbo是否工作，若沒有響應，則認為dubbo不能用，會删除對應的dubbo服務登記資訊。然後推送新的dubbo服務資訊和有問題的dubbo資訊推送給消費者，消費者就可以通路新的，可用的dubbo服務位址

zookeeper的使用

provider端

我們安裝好zookeeper後，找到兩個jar包

zkclient以及zookeeper兩個jar包

拷貝到對應的目錄下

然後在spring的配置檔案中，還需要聲明注冊中心的位置

暴露服務提供者的接口，現在有了注冊中心

<dubbo:service interface="BUPT.service.WeatherService"
ref="weatherService"/>
           

消費者端

添加相關jar包

配置檔案中聲明注冊中心的位址

配置參考位置

<dubbo:reference interface="BUPT.service.WeatherService"
                     id="remoteWeatherService" 
           

由于有了zookeeper，是以不需要再加上url位址了

負載均衡

• 叢集是一種計算機系統，是一種伺服器結構。把一組多個計算機，包括硬體和軟體組織在一個網絡中。互相連接配接起來共同完成某個工作。對使用者來說使用的是一個計算機，叢集對使用者是透明的。
• 負載均衡:負載均衡是以叢集為前提的。英文名稱為Load Balance，其意思就是将負載(工作任務）進行平衡、分攤到多個操作單元上進行執行。

當通路量增大，單個處理單元滿足不了負載需求，網絡應用流量将要出現瓶頸時，負載均衡才能起到作用。負載均衡就是為了避免單個伺服器響應同一請求，容易造成伺服器當機、崩潰等問題

負載均衡兩層含義：

• 首先，單個重負載的工作配置設定到多台伺服器做并行處理，每個伺服器處理結束後，将結果彙總，傳回給使用者，系統處理能力大幅度提高，這是叢集(cluster）技術帶來的優勢。
• 第二層含義是:大量的并發通路或資料流量分擔到多台伺服器分别處理==，減少使用者等待響應的時間==。每個通路配置設定給不同的伺服器處理。

Dubbo負載均衡政策

Random LoadBalance

Dubbo預設采用的一種負載均衡政策。

随機，按權重設定随機機率。

在一個截面上碰撞的機率高，但調用量越大分布越均勻，而且按機率使用權重後也比較均勻，有利于動态調整提供者權重。

比如伺服器有10台，那麼Dubbo随機生成1-10的數字，将業務配置設定到對應數字的伺服器上進行處理

RoundRobin LoadBalance

權重輪詢負載均衡，按公約後的權重設定輪詢比率。

第一個請求分給1，第二個分給2，第三個分給3，這樣輪着來

但存在慢的提供者累積請求問題

比如我一直分，1,4,7,10都在1上，2,5,8,11都在2上，3,6,9,12都在3上

但是2伺服器性能不行，處理太慢，久而久之，2 上面積累的請求就越來越多。

三台伺服器性能差不多的時候，可以用輪循方式

LeastActive LoadBalance

最少活躍調用數，相同活躍數的随機，活躍數指調用前後計數差。

使慢的提供者收到更少請求，因為越慢的提供者的調用前後計數差會越大。

比如1-3伺服器，給1了10個請求，5分鐘處理了9個，還剩一個

給2了10個，5分鐘處理了2個，還剩8個

給3了10個，5分鐘處理完了，還剩0個

那麼就給2少一點請求，給3多一些請求

ConsistentHash LoadBalance

一緻性 Hash，相同參數的請求總是發到同一提供者。

當某一台提供者挂時，原本發往該提供者的請求，基于虛拟節點，平攤到其它提供者，不會引起劇烈變動。算法參見: http://en.wikipedia.org/wiki/Consistent_hashingo

預設隻對第一個參數 Hash,如果要修改,請配置

配置方式

<dubbo:service interface="..." loadbalance="roundrobin" />
或
<dubbo:reference interface="..." loadbalance="roundrobin"/>

           

随機:

輪詢:

loadbalance=”roundrobin"
           

最少活躍:

loadbalance=" leastactive”
           

一緻性Hash:

面試考點

服務之間的調用為啥不直接用 HTTP 而用 RPC？

參考JavaGuide

RPC 隻是一種概念、一種設計，就是為了解決 不同服務之間的調用問題, 它一般會包含有 傳輸協定 和 序列化協定 這兩個。

但是，HTTP 是一種協定，RPC架構可以使用 HTTP協定作為傳輸協定或者直接使用TCP作為傳輸協定，使用不同的協定一般也是為了适應不同的場景。

使用 HTTP請求 當然可以，但是可能會比較慢而且一些優化做的并不好。

結束時間：2022-03-10