第三章 Dubbo配置實戰

• Dubbo都有哪些配置？提供了哪些功能？

3.1 啓動時檢查

3.1.1 作用

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

可以通過 check=“false” 關閉檢查，比如，測試時，有些服務不關心，或者出現了循環依賴，必須有一方先啓動。即使服務不可用，依然會創建代理對象。
另外，如果你的 Spring 容器是懶加載的，或者通過 API 編程延遲引用服務，請關閉 check，否則服務臨時不可用時，會拋出異常，拿到 null 引用，如果 check=“false”，總是會返回引用（代理對象的引用），當服務恢復時，能自動連上。

3.1.2 示例

通過 spring 配置文件

關閉某個服務的啓動時檢查 (沒有提供者時報錯)：
<dubbo:reference interface="com.foo.BarService" check="false" />
關閉所有服務的啓動時檢查 (沒有提供者時報錯)：
<dubbo:consumer check="false" />
關閉註冊中心啓動時檢查 (註冊訂閱失敗時報錯)：
<dubbo:registry check="false" />

通過 dubbo.properties

dubbo.reference.com.foo.BarService.check=false
dubbo.reference.check=false
dubbo.consumer.check=false
dubbo.registry.check=false

通過 -D 參數

java -Ddubbo.reference.com.foo.BarService.check=false
java -Ddubbo.reference.check=false
java -Ddubbo.consumer.check=false 
java -Ddubbo.registry.check=false

3.1.3 配置的含義

• dubbo.reference.check=false，強制改變所有 reference 的 check 值，就算配置中有聲明，也會被覆蓋。
• dubbo.consumer.check=false，是設置 check 的缺省值，如果配置中有顯式的聲明，如：<dubbo:reference check=“true”/>，不會受影響。
• dubbo.registry.check=false，前面兩個都是指訂閱成功，但提供者列表是否爲空是否報錯，如果註冊訂閱失敗時，也允許啓動，需使用此選項，將在後臺定時重試。

---

3.2 超時設置

方法調用超時時間(毫秒)
可以在多處設置timeout屬性值。記住優先級：1.方法級別 > 接口級別 > 全局配置（缺省配置） 2.級別一樣時，消費者 > 提供者 參考第二章

3.2.1 示例

在dubbo:reference（服務消費者引用服務配置。對應的配置類： org.apache.dubbo.config.ReferenceConfig）中設置timeout的值：

• 可選
• 缺省使用dubbo:consumer的timeout

dubbo:consumer（服務消費者缺省值配置。配置類： org.apache.dubbo.config.ConsumerConfig 。同時該標籤爲 dubbo:reference 標籤的缺省值設置。）中設置timeout的值：

• 可選
• 缺省值是1000
  

dubbo:service和dubbo:provider也可配置timeout值，它們的缺省值爲1000。

---

3.3 重試次數設置

遠程服務調用重試次數，不包括第一次調用，不需要重試請設爲0。

具體設置方式跟設置timeout的方式一樣。
retries缺省值爲2。
如果重試失敗，會去主動去其他機器請求服務。（失敗策略）
最終返回給調用方的錯誤日誌是最後一次請求所產生的錯誤異常結果。
冪等操作可以設置重試次數。

---

3.4 多版本

3.4.1 作用

當一個接口實現，出現不兼容升級時，可以用版本號過渡，版本號不同的服務相互間不引用。（一個接口多個實現，實現灰度發佈）
可以按照以下的步驟進行版本遷移：

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

3.4.2 示例

老版本服務提供者配置：
<dubbo:service interface=“com.foo.BarService” id=“..." version="1.0.0" />
新版本服務提供者配置：
<dubbo:service interface=“com.foo.BarService" id=“..." 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="*" />

---

3.5 本地存根

3.5.1 作用

• 提供方想在客戶端實現部分邏輯
• Stub放在API包中提供給客戶端

遠程服務後，客戶端通常只剩下接口，而實現全在服務器端，但提供方有些時候想在客戶端也執行部分邏輯，比如：做 ThreadLocal 緩存，提前驗證參數，調用失敗後僞造容錯數據等等，此時就需要在 API 中帶上 Stub，客戶端生成 Proxy 實例，會把 Proxy 通過構造函數傳給 Stub ，然後把 Stub 暴露給用戶，Stub 可以決定要不要去調 Proxy。

3.5.2 示例

Stub的實現:

package com.foo;  //API包
// 在 interface 旁邊放一個 Stub 實現，它實現 BarService 接口，並有一個傳入遠程 BarService 實例的構造函數
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 "容錯數據";
        }
    }
}

在 spring 配置文件中按以下方式配置：服務端和客戶端都可以配置stub參數，優先級規則同之前所講的配置一致
<dubbo:service interface="com.foo.BarService" stub="true" />
或
<dubbo:service interface="com.foo.BarService" stub="com.foo.BarServiceStub" />