Dubbo 學習筆記-有解無憂

分布式基礎理論

1. 什么是分布式系統？

分布式系統是若干獨立計算機的集合，這些計算機對于用戶來說就像單個系統

2. 應用架構演變

單一應用架構

當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本，適用于小型網站，小型管理系統
垂直應用架構

當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率，通過切分業務來實作各個模塊獨立部署，降低了維護和部署的難度，團隊各司其職更易管理，性能擴展也更方便，更有針對性
分布式服務架構

當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的回應多變的市場需求
流動計算架構

當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基于訪問壓力實時管理集群容量，提高集群利用率

3. RPC

RPC（Remote Procedure Call）是指遠程程序呼叫，是一種行程間通信方式，它是一種技術的思想，而不是規范，它允許程式呼叫另一個地址空間（通常是共享網路的另一臺機器上）的程序或函式，而不用程式員顯式編碼這個遠程呼叫的細節，即程式員無論是呼叫本地的還是遠程的函式，本質上撰寫的呼叫代碼基本相同

一次完整的 RPC 呼叫流程如下：

服務消費方（client）呼叫以本地呼叫方式呼叫服務
client stub接收到呼叫后負責將方法、引數等組裝成能夠進行網路傳輸的訊息體
client stub找到服務地址，并將訊息發送到服務端
server stub收到訊息后進行解碼
server stub根據解碼結果呼叫本地的服務
本地服務執行并將結果回傳給server stub
server stub將回傳結果打包成訊息并發送至消費方
client stub接收到訊息，并進行解碼
服務消費方得到最終結果

RPC框架的目標就是把 2~8 這些步驟都封裝起來，這些細節對用戶來說是透明的，不可見的

Dubbo 核心概念

1. 簡介

Apache Dubbo 是一款高性能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向介面的遠程方法呼叫，智能容錯和負載均衡，以及服務自動注冊和發現

2. 設計架構

相關組件說明如下：

服務提供者（Provider）：暴露服務的服務提供方，服務提供者在啟動時，向注冊中心注冊自己提供的服務
服務消費者（Consumer）: 呼叫遠程服務的服務消費方，服務消費者在啟動時，向注冊中心訂閱自己所需的服務，服務消費者，從提供者地址串列中，基于軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫
注冊中心（Registry）：注冊中心回傳服務提供者地址串列給消費者，如果有變更，注冊中心將基于長連接推送變更資料給消費者
監控中心（Monitor）：服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘發送一次統計資料到監控中心

呼叫關系說明如下：

服務容器負責啟動，加載，運行服務提供者
服務提供者在啟動時，向注冊中心注冊自己提供的服務
服務消費者在啟動時，向注冊中心訂閱自己所需的服務
注冊中心回傳服務提供者地址串列給消費者，如果有變更，注冊中心將基于長連接推送變更資料給消費者
服務消費者，從提供者地址串列中，基于軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫
服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘發送一次統計資料到監控中心

Dubbo 環境搭建

1. 安裝 Zookeeper

下載 zookeeper，網址：https://archive.apache.org/dist/zookeeper/

解壓，將 conf 下的 zoo_sample.cfg 復制一份改名為 zoo.cfg，注意如下配置

dataDir=./   臨時資料存盤的目錄（可寫相對路徑）
clientPort=2181   zookeeper的埠號

運行 zkServer.cmd 啟動 zookeeper，使用 zkCli.cmd 測驗

2. 安裝管理控制臺

下載 dubbo-admin，網址：https://github.com/apache/incubator-dubbo-ops

進入目錄，修改 src\main\resources\application.properties 指定 zookeeper 地址

打包 dubbo-admin，以 Jar 包形式運行，默認使用 root/root 登陸

3. 安裝監控中心

下載 dubbo-monitor，網址：https://github.com/apache/incubator-dubbo-ops

進入目錄，修改 src\main\resources\conf\dubbo.properties

dubbo.registry.address=zookeeper://127.0.0.1:2181 # 注冊中心地址
dubbo.jetty.port=8080 # http訪問埠號

打包 dubbo-monitor，找到解壓后的 assembly.bin 檔案，start.bat 啟動

在服務提供者和消費者的 xml 中配置以下內容，再次啟動服務提供和消費者啟動類

<!-- dubbo-monitor-simple 監控中心發現的配置-->
<dubbo:monitor protocol="registry"></dubbo:monitor>

監控中心即可捕獲到服務提供方和消費方資訊

Dubbo 開發

1. 創建服務提供和服務消費工程

假設有如下需求場景：訂單服務作為服務消費者，用戶服務作為服務提供者，訂單服務需要從用戶服務查詢用戶的所有識訓地址

基于上述要求，用戶服務作為服務提供方，要提供一個對應的介面，具體的實作和物體這里不詳細列出

/**
 * 用戶服務
 */ 
public interface UserService {
	/**
	 * 按照用戶id回傳所有的識訓地址
	 */
	public List<UserAddress> getUserAddressList(String userId);
}

訂單服務作為服務消費方，直接使用服務提供方的介面

public class OrderServiceImpl implements OrderService {
    
    public UserService userService;
    
    public void initOrder(String userID) {
        // 查詢用戶的識訓地址
        List<UserAddress> userAddressList = userService.getUserAddressList(userID);
    }
}

因為服務提供方和消費方用到了同樣的介面和物體，所以可以將服務介面，服務物體等單獨放在一個公共專案中，方便呼叫

2. 服務提供方配置

引入依賴

<!-- dubbo -->
<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>dubbo</artifactId>
    <version>2.6.2</version>
</dependency>
<!-- 注冊中心是 zookeeper,引入 zookeeper 客戶端 -->
<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-framework</artifactId>
    <version>2.12.0</version>
</dependency>

在 resource 檔案夾中創建 provider.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd
		http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">
    
    <!-- 1.指定當前服務/應用的名字(同樣的服務名字相同,不要和別的服務同名) -->
   <dubbo:application name="user-service-provider"></dubbo:application>
    <!-- 2.指定注冊中心的位置 -->
    <dubbo:registry protocol="zookeeper" address="127.0.0.1:2181"></dubbo:registry>
    <!-- 3.指定通信規則 -->
    <dubbo:protocol name="dubbo" port="20880"></dubbo:protocol>
    <!-- 4.暴露服務,讓別人呼叫ref指向服務的真正實作物件-->
    <dubbo:service interface="com.lemon.gmail.service.UserService" ref="userServiceImpl"></dubbo:service>
    <!-- 5.服務的實作-->
    <bean id="userServiceImpl" ></bean>
</beans>

3. 服務消費方配置

引入依賴

<!-- dubbo -->
<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>dubbo</artifactId>
    <version>2.6.2</version>
</dependency>
<!-- 注冊中心是 zookeeper,引入 zookeeper 客戶端 -->
<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-framework</artifactId>
    <version>2.12.0</version>
</dependency>

在 resource 檔案夾中創建 consumer.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-4.3.xsd
		http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd
		http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">

    <!-- 1.指定當前服務/應用的名字(同樣的服務名字相同，不要和別的服務同名) -->
    <dubbo:application name="order-service-consumer"></dubbo:application>
    <!-- 2.指定注冊中心的位置 -->
    <dubbo:registry address="zookeeper://127.0.0.1:2181"></dubbo:registry>
    <!-- 3.呼叫遠程暴露的服務,生成遠程服務代理 -->
    <dubbo:reference interface="com.yeeq.service.UserService" id="userService"></dubbo:reference>
</beans>

在當前 OrderServiceImpl 實作類中加上注解

@Service
public class OrderServiceImpl implements OrderService {
    
    @Autowired
    public UserService userService;
    
    public void initOrder(String userID) {
        // 查詢用戶的識訓地址
        List<UserAddress> userAddressList = userService.getUserAddressList(userID);
    }
}

Dubbo 整合 SpringBoot

1. 服務提供方

引入依賴

<dependency>
    <groupId>com.alibaba.boot</groupId>
    <artifactId>dubbo-spring-boot-starter</artifactId>
    <version>0.2.0</version>
</dependency>

介面和物體和之前一樣，配置 application.properties

dubbo.application.name=boot-user-service-provider
dubbo.registry.address=127.0.0.1:2181
dubbo.registry.protocol=zookeeper

dubbo.protocol.name=dubbo
dubbo.protocol.port=20880

# 連接監控中心
dubbo.monitor.protocol=registry

在啟動類加上注解

@EnableDubbo // 開啟基于注解的dubbo功能
@SpringBootApplication
public class BootProviderApplication {
    public static void main(String[] args) {
        SpringApplication.run(BootProviderApplication.class, args);
    }
}

2. 服務消費方

引入依賴

<dependency>
    <groupId>com.alibaba.boot</groupId>
    <artifactId>dubbo-spring-boot-starter</artifactId>
    <version>0.2.0</version>
</dependency>

介面和物體和之前一樣，配置 application.properties

server.port=8081
dubbo.application.name=boot-order-service-consumer
dubbo.registry.address=zookeeper://127.0.0.1:2181

# 連接監控中心 注冊中心協議
dubbo.monitor.protocol=registry

在啟動類加上注解

@EnableDubbo // 開啟基于注解的dubbo功能
@SpringBootApplication
public class BootConsumerApplication {
    public static void main(String[] args){
        SpringApplication.run(BootConsumerApplication.class,args);
    }
}

Dubbo 配置

1. 配置原則

JVM 啟動 -D 引數優先，這樣可以使用戶在部署和啟動時進行引數重寫，比如在啟動時需改變協議的埠
XML 次之，如果在 XML 中有配置，則 dubbo.properties 中的相應配置項無效
Properties 最后，相當于預設值，只有 XML 沒有配置時，dubbo.properties 的相應配置項才會生效，通常用于共享公共配置，比如應用名

2. 啟動檢查

Dubbo 會在啟動時檢查依賴的服務是否可用，不可用時會拋出例外，阻止 Spring 初始化完成，以便上線時能及早發現問題

以消費者為例，在 consumer.xml 中添加配置

<!-- 配置當前消費者的統一規則,開啟啟動檢查,默認true -->
<dubbo:consumer check="true"></dubbo:consumer>

3. 超時時間

由于網路或服務端不可靠，會導致呼叫出現一種不確定的中間狀態（超時），為了避免超時導致客戶端資源（執行緒）掛起耗盡，必須設定超時時間

<!-- 全域超時配置 -->
<dubbo:consumer timeout="5000" />

<!-- 指定介面以及特定方法超時配置 -->
<dubbo:reference interface="com.foo.BarService" timeout="2000">
    <dubbo:method name="sayHello" timeout="3000" />
</dubbo:reference>

Dubbo 消費端和服務端都可以設定，推薦在 Provider 上盡量多配置 Consumer 端屬性，原因如下：

一般來說，服務提供者比服務使用方更清楚服務性能引數，如呼叫的超時時間，合理的重試次數等等
在 Provider 配置后，Consumer 不配置則會使用 Provider 的配置值，即 Provider 配置可以作為 Consumer 的預設值，否則，Consumer 會使用 Consumer 端的全域設定，這對于 Provider 是不可控的，并且往往是不合理的

4. 重試次數

當出現呼叫失敗，一般會進行重試，但重試會帶來更長延遲，可通過 retries="2" 來設定重試次數（不含第一次）

<!-- 有三種方式配置 -->
<dubbo:service retries="2" />
<dubbo:reference retries="2" />
<dubbo:reference>
    <dubbo:method name="findFoo" retries="2" />
</dubbo:reference>

5. 多版本

當一個介面實作，出現不兼容升級時，可以用版本號過渡，版本號不同的服務相互間不參考

服務端配置

<!-- 老版本服務提供者配置 -->
<bean id="BarServiceImpl01"  />
<dubbo:service interface="com.foo.BarService" ref="BarServiceImpl01" version="1.0.0" />

<!-- 新版本服務提供者配置 -->
<bean id="BarServiceImpl02"  />
<dubbo:service interface="com.foo.BarService" ref="BarServiceImpl02" version="2.0.0" />

消費端配置

<!-- 使用老版本 -->
<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />
<!-- 使用新版本 -->
<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />
<!-- 如果不需要區分版本,可以按照以下的方式配置 -->
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />

6. 本地存根

遠程服務中，客戶端通常只剩下介面，實作全在服務端，但服務方有時候也想在客戶端執行部分邏輯，比如：做 ThreadLocal 快取，提前驗證引數，呼叫失敗后偽造容錯資料等等，此時就需要在 API 中帶上 Stub，客戶端生成 Proxy 實體，通過建構式把 Proxy 傳給 Stub，然后把 Stub 暴露給用戶，Stub 可以決定要不要去調 Proxy

消費端開發對應服務的本地存根

public class UserServiceStub implements UserService {
 
    private final IUserService userService;
 
    // 建構式傳入真正的遠程代理物件
    public UserServiceStub(IUserService userService){
        this.userService = userService;
    }
 
    @Override
    public String hello(String name) {
        if(name == null || "".equals(name)){
            return "validate param";
        }
        return userService.hello(name);
    }
}

設定存根配置

@Reference(version = "*",stub = "com.yeeq.stub.UserServiceStub")
private UserService userService;

Dubbo 高可用

1. Dubbo 的健壯性

監控中心宕掉不影響使用，只是丟失部分采樣資料
資料庫宕掉后，注冊中心仍能通過快取提供服務串列查詢，但不能注冊新服務
注冊中心對等集群，任意一臺宕掉后，將自動切換到另一臺
注冊中心全部宕掉后，服務提供者和服務消費者仍能通過本地快取通訊
服務提供者無狀態，任意一臺宕掉后，不影響使用
服務提供者全部宕掉后，服務消費者應用將無法使用，并無限次重連等待服務提供者恢復

2. Dubbo 集群下負載均衡

在集群負載均衡時，Dubbo 提供了多種均衡策略，預設為 random 隨機呼叫：

Random LoadBalance：隨機，按權重設定隨機概率
RoundRobin LoadBalance：輪循，按公約后的權重設定輪循比率
LeastActive LoadBalance：最少活躍呼叫數，相同活躍數的隨機，活躍數指呼叫前后計數差
ConsistentHash LoadBalance：一致性 Hash，相同引數的請求總是發到同一提供者

服務端和客戶端均可以設定

<!-- 服務級別 -->
<dubbo:service interface="..." loadbalance="roundrobin" />
<!-- 方法級別 -->
<dubbo:service interface="...">
    <dubbo:method name="..." loadbalance="roundrobin" />
</dubbo:service>

3. 服務降級

當服務器壓力劇增的情況下，根據實際業務情況及流量，對一些服務和頁面有策略的不處理或換種簡單的方式處理，從而釋放服務器資源以保證核心交易正常運作或高效運作，可以通過服務降級功能臨時屏蔽某個出錯的非關鍵服務，并定義降級后的回傳策略

向注冊中心寫入動態配置覆寫規則：

RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));

其中：

mock=force:return+null 表示消費方對該服務的方法呼叫都直接回傳 null 值，不發起遠程呼叫，用來屏蔽不重要服務不可用時對呼叫方的影響
mock=fail:return+null 表示消費方對該服務的方法呼叫在失敗后，再回傳 null 值，不拋例外，用來容忍不重要服務不穩定時對呼叫方的影響

4. 集群容錯

在集群呼叫失敗時，Dubbo 提供了多種容錯方案，默認為 failover 重試：

Failover Cluster：失敗自動切換，當出現失敗，重試其它服務器，通常用于讀操作，但重試會帶來更長延遲，可通過 retries="2" 來設定重試次數（不含第一次）
Failfast Cluste：快速失敗，只發起一次呼叫，失敗立即報錯，通常用于非冪等性的寫操作，比如新增記錄
Failsafe Cluster：失敗安全，出現例外時，直接忽略，通常用于寫入審計日志等操作
Failback Cluster：失敗自動恢復，后臺記錄失敗請求，定時重發，通常用于訊息通知操作
Forking Cluster：并行呼叫多個服務器，只要一個成功即回傳，通常用于實時性要求較高的讀操作，但需要浪費更多服務資源，可通過 forks="2" 來設定最大并行數
Broadcast Cluster：廣播呼叫所有提供者，逐個呼叫，任意一臺報錯則報錯，通常用于通知所有提供者更新快取或日志等本地資源資訊

按照以下示例在服務提供方和消費方配置集群模式

<!-- 兩種方式配置 -->
<dubbo:service cluster="failsafe" />
<dubbo:reference cluster="failsafe" />

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/458430.html

標籤：Java

上一篇：淺析AQS

下一篇：執行緒通信和8鎖問題