Dubbo靜態規則打標的方法是什么

本篇內容主要講解“Dubbo靜態規則打標的方法是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Dubbo靜態規則打標的方法是什么”吧!

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靜態規則打標的方法是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！