近期咱们公布了 dubbo-go v1.5.1，尽管是 v1.5 的一个子版本，但相比于 v1.5.0，社区还是投入了很大人力增加了如下重大改良。

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 上体现。

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