Dubbo-go 團隊近期發布了 Dubbo-go v1.5.1，Dubbo-go 是 Apache Dubbo 項目的 Go 實現。
根據團隊的介紹，雖然 v1.5.1 是 v1.5 的一個子版本，但相比於 v1.5.0， 社區還是投入了很大人力添加了如下重大改進。
在新模型 release 後，團隊發現 Provider 每個 URL 發布元數據都會註冊 ServiceInstance，影響性能需要優化。
優化方案是： 去除 ServiceDiscoveryRegistry 中註冊 ServiceInstance 的代碼，在 config_loader 中的loadProviderConfig 方法的最後註冊 ServiceInstance 具體步驟： 1、獲取所有註冊的 Registry，過濾出 ServiceDiscoveryRegistry，拿取所有 ServiceDiscovery。 2、創建 ServiceInstance。 3、每個 ServiceDiscovery 註冊 ServiceInstance。
保證 Provider 在註冊成功之後，才暴露元數據信息。
基於 Seata 擴展實現。通過增加過濾器，在服務端接收 xid 並結合 seata-golang 達到支持分布式事務的目的。 從而使 Dubbo-go 在分布式場景下，讓用戶有更多的選擇，能適應更多的個性化場景。
開發團隊在 dubbo-samples 中給出了 事務測試用例 。
對於多註冊中心訂閱的場景，選址時的多了一層註冊中心集群間的負載均衡：
在 Cluster Invoker 這一級，支持的選址策略有：
該版本在傳輸鏈路的安全性上做了嘗試，對於內置的 Dubbo getty Server 提供了基於 TLS 的安全鏈路傳輸機制。
為儘可能保證應用啟動的靈活性，TLS Cert 的指定通過配置文件方式，具體請參見 Dubbo-go 配置讀取規則與 TLS 示例：
本次路由功能重點支持了 動態標籤路由 和 應用/服務級條件路由。
標籤路由通過將某一個或多個服務的提供者劃分到同一個分組，約束流量只在指定分組中流轉，從而實現流量隔離的目的，可以作為藍綠髮布、灰度發布等場景的能力基礎。
標籤主要是指對 Provider 端應用實例的分組，目前有兩種方式可以完成實例分組，分別是動態規則打標和靜態規則打標，其中動態規則相較於靜態規則優先級更高，而當兩種規則同時存在且出現衝突時，將以動態規則為準。
可隨時在服務治理控制臺下發標籤歸組規則
# 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"] ...
可以在 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 中的值將會在一次完整的遠程調用中持續傳遞，得益於這樣的特性，只需要在起始調用時，通過一行代碼的設置，達到標籤的持續傳遞。
Key明確規則體作用到哪個應用。必填。enabled=true 當前路由規則是否生效，可不填，預設生效。force=false 當路由結果為空時，是否強制執行，如果不強制執行，路由結果為空的路由規則將自動失效，可不填，預設為 false。runtime=false 是否在每次調用時執行路由規則，否則只在提供者地址列表變更時預先執行並緩存結果，調用時直接從緩存中獲取路由結果。如果用了參數路由，必須設為 true，需要注意設置會影響調用的性能，可不填，預設為 false。priority=1 路由規則的優先級，用於排序，優先級越大越靠前執行，可不填，預設為 0。tags 定義具體的標籤分組內容，可定義任意n（n>=1）個標籤並為每個標籤指定實例列表。必填 request.tag=tag1 時優先選擇 標記了 tag=tag1 的 provider。若集群中不存在與請求標記對應的服務，默認將降級請求 tag 為空的 provider；如果要改變這種默認行為，即找不到匹配 tag1 的 provider 返回異常，需設置request.tag.force=true。request.tag 未設置時，只會匹配 tag 為空的 provider。即使集群中存在可用的服務，若 tag 不匹配也就無法調用，這與約定 1 不同，攜帶標籤的請求可以降級訪問到無標籤的服務，但不攜帶標籤/攜帶其他種類標籤的請求永遠無法訪問到其他標籤的服務。可以在路由規則配置中配置多個條件路由及其粒度
Sample:
# dubbo router yaml configure filerouterRules: - 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 "]
Dubbo-go 處於一個比較穩定成熟的狀態。目前新版本正處於往雲原生方向的嘗試，應用服務維度註冊是首先推出的功能，這是一個和之前模型完全不一樣的新註冊模型。該版本是朝雲原生邁進新一步的關鍵版本。除此之外，包含在該版本也有一些之前提到的優化。
下一個版本 v1.5.2，本次的關注重點以通信模型改進為主，除此之外，與 2.7.x 的兼容性、易用性及質量保證也是本次關注的信息。
在服務發現，會支持更加多的方式，如：文件、Consul。 從而使 Dubbo-go 在服務發現場景下，讓用戶有更多的選擇，能適應更多的個性化場景。
另外 易用性及質量保證，主要關注的是 samples 與自動化構建部分。可降低用戶上手 Dubbo-go 的難度，提高代碼質量。
目前下一個版本正在緊鑼密鼓的開發中，具體規劃及任務清單，都已經在 Github 上體現。
更多信息：https://github.com/apache/dubbo-go/releases/tag/v1.5.1