What's new in Dubbo-go v1.5.1

近期我們釋出了 Dubbo-go v1.5.1，雖然是 v1.5 的一個子版本，但相比於 v1.5.0， 社群還是投入了很大人力新增了如下重大改進。

更多資訊：https://github.com/apache/dubbo-go/releases/tag/v1.5.1

1 應用維度註冊模型

在新模型 release 後，我們發現 Provider 每個 URL 釋出後設資料都會註冊 ServiceInstance，影響效能需要優化。

我們的優化方案是： 去除 ServiceDiscoveryRegistry 中註冊 ServiceInstance 的程式碼，在 config_loader 中的 loadProviderConfig 方法的最後註冊 ServiceInstance 具體步驟： 1、獲取所有註冊的 Registry，過濾出 ServiceDiscoveryRegistry，拿取所有 ServiceDiscovery。 2、建立 ServiceInstance。 3、每個 ServiceDiscovery 註冊 ServiceInstance。

保證 Provider 在註冊成功之後，才暴露後設資料資訊。

2 支援基於 Seata 的事務

基於 Seata 擴充套件實現。通過增加過濾器，在服務端接收  xid 並結合 seata-golang 達到支援分散式事務的目的。 從而使 Dubbo-go 在分散式場景下，讓使用者有更多的選擇，能適應更多的個性化場景。

我們在 dubbo-samples 中給出了 事務測試用例 。

3 多註冊中心叢集負載均衡

對於多註冊中心訂閱的場景，選址時的多了一層註冊中心叢集間的負載均衡：

在 Cluster Invoker 這一級，我們支援的選址策略有：

• 指定優先順序
• 同 zone 優先
• 權重輪詢

3 傳輸鏈路安全性

該版本在傳輸鏈路的安全性上做了嘗試，對於內建的 Dubbo getty Server 提供了基於 TLS 的安全鏈路傳輸機制。

為儘可能保證應用啟動的靈活性，TLS Cert 的指定通過配置檔案方式，具體請參見 Dubbo-go 配置讀取規則與 TLS 示例：

4 路由功能增強

本次路由功能重點支援了 動態標籤路由 和 應用/服務級條件路由。

4.1 動態標籤路由

標籤路由通過將某一個或多個服務的提供者劃分到同一個分組，約束流量只在指定分組中流轉，從而實現流量隔離的目的，可以作為藍綠髮布、灰度釋出等場景的能力基礎。

標籤主要是指對 Provider 端應用例項的分組，目前有兩種方式可以完成例項分組，分別是動態規則打標和靜態規則打標，其中動態規則相較於靜態規則優先順序更高，而當兩種規則同時存在且出現衝突時，將以動態規則為準。

4.1.1 動態規則打標

可隨時在服務治理控制檯下發標籤歸組規則

# governance-tagrouter-provider應用增加了兩個標籤分組tag1和tag2
# tag1包含一個例項 127.0.0.1:20880
# tag2包含一個例項 127.0.0.1:20881
---
  force: false
  runtime: true
  enabled: true
  key: governance-tagrouter-provider
  tags:
    - name: tag1
      addresses: ["127.0.0.1:20880"]
    - name: tag2
      addresses: ["127.0.0.1:20881"]
 ...

4.1.2 靜態規則打標

可以在 server 配置檔案的 tag 欄位裡設定

services:
  "UserProvider":
    registry: "hangzhouzk"
    protocol : "dubbo"
    interface : "com.ikurento.user.UserProvider"
    loadbalance: "random"
    warmup: "100"
    tag: "beijing"
    cluster: "failover"
    methods:
    - name: "GetUser"
      retries: 1
      loadbalance: "random"

consumer  新增 tag 至 attachment 即可

ctx := context.Background()
attachment := make(map[string]string)
attachment["dubbo.tag"] = "beijing"
ctx = context.WithValue(ctx, constant.AttachmentKey, attachment)
err := userProvider.GetUser(ctx, []interface{}{"A001"}, user)

請求標籤的作用域為每一次 invocation，使用 attachment 來傳遞請求標籤，注意儲存在 attachment 中的值將會在一次完整的遠端呼叫中持續傳遞，得益於這樣的特性，我們只需要在起始呼叫時，通過一行程式碼的設定，達到標籤的持續傳遞。

4.1.3 規則詳解

格式

• Key明確規則體作用到哪個應用。必填。
• enabled=true 當前路由規則是否生效，可不填，預設生效。
• force=false 當路由結果為空時，是否強制執行，如果不強制執行，路由結果為空的路由規則將自動失效，可不填，預設為 false。
• runtime=false 是否在每次呼叫時執行路由規則，否則只在提供者地址列表變更時預先執行並快取結果，呼叫時直接從快取中獲取路由結果。如果用了引數路由，必須設為 true，需要注意設定會影響呼叫的效能，可不填，預設為 false。
• priority=1 路由規則的優先順序，用於排序，優先順序越大越靠前執行，可不填，預設為 0。
• tags 定義具體的標籤分組內容，可定義任意 n（n>=1）個標籤併為每個標籤指定例項列表。必填
  • name， 標籤名稱
• addresses， 當前標籤包含的例項列表

降級約定

1. request.tag=tag1 時優先選擇 標記了 tag=tag1 的 provider。若叢集中不存在與請求標記對應的服務，預設將降級請求 tag 為空的 provider；如果要改變這種預設行為，即找不到匹配 tag1 的 provider 返回異常，需設定request.tag.force=true。
2. request.tag 未設定時，只會匹配 tag 為空的 provider。即使叢集中存在可用的服務，若 tag 不匹配也就無法呼叫，這與約定 1 不同，攜帶標籤的請求可以降級訪問到無標籤的服務，但不攜帶標籤/攜帶其他種類標籤的請求永遠無法訪問到其他標籤的服務。

4.2 應用/服務級條件路由

您可以在路由規則配置中配置多個條件路由及其粒度

Sample:

# dubbo router yaml configure file
routerRules: 
  - scope: application
    key: BDTService
    priority: 1
    enable: false
    force: true
    conditions : ["host = 192.168.199.208 => host = 192.168.199.208 "]
  - scope: service
    key: com.ikurento.user.UserProvider
    priority: 1
    force: true
    conditions : ["host = 192.168.199.208 => host = 192.168.199.208 "]

4.2.1 規則詳解

各欄位含義

• scope 表示路由規則的作用粒度，scope 的取值會決定 key 的取值。必填。
  • service 服務粒度
  • application 應用粒度
• Key 明確規則體作用在哪個服務或應用。必填。
  • scope=service 時，key 取值為 [{group}/]{service}[:{version}] 的組合
  • scope=application 時，key 取值為 application 名稱
• enabled=true 當前路由規則是否生效，可不填，預設生效。
• force=false 當路由結果為空時，是否強制執行，如果不強制執行，路由結果為空的路由規則將自動失效，可不填，預設為 false。
• runtime=false 是否在每次呼叫時執行路由規則，否則只在提供者地址列表變更時預先執行並快取結果，呼叫時直接從快取中獲取路由結果。如果用了引數路由，必須設為 true，需要注意設定會影響呼叫的效能，可不填，預設為 false。
• priority=1 路由規則的優先順序，用於排序，優先順序越大越靠前執行，可不填，預設為 0。
• conditions 定義具體的路由規則內容。必填。

5 回顧與展望

Dubbo-go 處於一個比較穩定成熟的狀態。目前新版本正處於往雲原生方向的嘗試，應用服務維度註冊是首先推出的功能，這是一個和之前模型完全不一樣的新註冊模型。該版本是我們朝雲原生邁進新一步的關鍵版本。除此之外，包含在該版本也有一些之前提到的優化。

下一個版本 v1.5.2，本次的關注重點以通訊模型改進為主，除此之外，與 2.7.x 的相容性、易用性及質量保證也是本次關注的資訊。**

在服務發現，會支援更加多的方式，如：檔案、Consul。 從而使 Dubbo-go 在服務發現場景下，讓使用者有更多的選擇，能適應更多的個性化場景。

另外 易用性及質量保證，主要關注的是 samples 與自動化構建部分。可降低使用者上手 Dubbo-go 的難度，提高程式碼質量。

目前下一個版本正在緊鑼密鼓的開發中，具體規劃及任務清單 [1] ，都已經在 Github 上體現。

歡迎加入 dubbo-go 社群

有任何 dubbo-go 相關的問題，可以加我們的釘釘群 23331795 詢問探討，我們一定第一時間給出反饋。

[1] : https://github.com/apache/dubbo-go/projects/10