Dubbo在開發中的一些常用配置

介紹Dubbo在開發中的一些常用配置，文中內容主要參考dubbo文檔配置和示例兩節，詳細可移步訪問  傳送站

1. 屬性配置方法及加載順序

屬性常用配置方法主要有三種：

第一種是通過啟動時在虛擬機參數中加上相關信息

第二種也是最常用的是通過xml方式配置，隨着springboot和dubbo的集成，這種方式在springboot項目中表現為通過application.properties來配置，兩者優先級相同；

第三種是在classpath 根目錄下的創建 dubbo.properties，dubbo啟動時，如果沒有其他配置文件，會自動加載該配置。

2. 啟動檢查

Dubbo 缺省會在啟動時檢查依賴的服務是否可用，不可用時會拋出異常，阻止 Spring 初始化完成，以便上線時，能及早發現問題，默認 check="true"。

可在xml和properties文件中進行配置，以顯式關閉啟動檢查

<!-- 關閉所有服務的啟動時檢查 (沒有提供者時報錯) -->
<dubbo:consumer check="false" />

dubbo.consumer.check=false

3. 超時設置 & 配置覆蓋關系

由於網絡或服務端不可靠，會導致調用出現一種不確定的中間狀態（超時）。為了避免超時導致客戶端資源（線程）掛起耗盡，必須設置超時時間。缺省使用<dubbo:consumer>的timeout，目前默認為1000。

Dubbo消費端

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

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

Dubbo服務端

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

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

通過上面的配置，我們可能產生疑惑，如果多方都配置了屬性，那么會以哪個為准？這就涉及到配置覆蓋關系

以 timeout 為例，顯示了配置的查找順序，其它 retries, loadbalance, actives 等類似：

• 方法級優先，接口級次之，全局配置再次之。
• 如果級別一樣，則消費方優先，提供方次之。

其中，服務提供方配置，通過 URL 經由注冊中心傳遞給消費方。

建議由服務提供方設置超時，因為一個方法需要執行多長時間，服務提供方更清楚，如調用的超時時間，合理的重試次數，等等；如果一個消費方同時引用多個服務，就不需要關心每個服務的超時設置。另外，在服務提供方配置后，消費方不配置則會使用服務提供方的配置值，即服務提供方配置可以作為消費方的缺省值。否則，消費方會使用消費方的全局設置，這對於服務提供方是不可控的，並且往往是不合理的。

4. 重試次數

失敗自動切換，當出現失敗，重試其它服務器，但重試會帶來更長延遲。可通過 retries="2" 來設置重試次數(不含第一次)。

<!--針對服務提供方 -->
<dubbo:service retries="2" />
<!-- 針對服務消費方 -->
<dubbo:reference retries="2" />
<!-- 針對方法 -->
<dubbo:reference>
    <dubbo:method name="findFoo" retries="2" />
</dubbo:reference>

5. 多版本

當一個接口實現，出現不兼容升級時，可以用版本號過渡，版本號不同的服務相互間不引用。

可以按照以下的步驟進行版本遷移：

0. 在低壓力時間段，先升級一半提供者為新版本
1. 再將所有消費者升級為新版本
2. 然后將剩下的一半提供者升級為新版本

老版本服務提供者配置：

<dubbo:service interface="com.foo.BarService" version="1.0.0" />

新版本服務提供者配置：

<dubbo:service interface="com.foo.BarService" 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。

服務提供方（服務消費方也可配置）

<dubbo:service interface="com.foo.BarService" stub="com.foo.BarServiceStub" />

業務邏輯放在Stub類中實現

package com.foo;
public class BarServiceStub implements BarService { 
    private final BarService barService;
    
    // 構造函數傳入真正的遠程代理對象
    public (BarService barService) {
        this.barService = barService;
    }
 
    public String sayHello(String name) {
        // 此代碼在客戶端執行, 你可以在客戶端做ThreadLocal本地緩存，或預先驗證參數是否合法，等等
        try {
            return barService.sayHello(name);
        } catch (Exception e) {
            // 你可以容錯，可以做任何AOP攔截事項
            return "容錯數據";
        }
    }
}