Dubbo 路由规则之标签路由

前言

你们好，今天开始给你们分享 — Dubbo 专题之 Dubbo 路由规则之标签路由。在前一个章节中咱们介绍了 Dubbo 路由规则之标签路由，以及咱们也例举了常见的使用场景而且进行了源码解析来分析其实现原理，同时知道 Dubbo 中标签路由其本质上是经过过滤器对服务提供者列表进行规则的匹配，若是匹配不上则过滤掉服务提供者。那接下来咱们解析讨论标签路由，什么是标签路由呢？有什么使用场景呢？下面就让咱们快速开始吧！

1. 标签路由简介

首先小伙伴能够经过《Dubbo 路由规则之条件路由》回归一下什么是路由规则？下面咱们主要讨论什么标签路由：

上图中咱们能够看到有两个机房分别是机房A、机房B，其中机房 A 只能访问到 Service A 和 Service B ，而机房B 只能访问到 Service C 和 Service D。要实现上面这种场景咱们就须要用到标签路由。从机房 A 发起的调用携带标签 TAG_A 访问到 Service A 和 Service B，而从机房 B 发起的调用携带 TAG_B Service C 和 Service D 。那什么是标签路由呢？

• 标签路由：以服务提供者应用为粒度配置路由规则，经过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，能够做为蓝绿发布、灰度发布等场景的能力基础。标签主要是指对Provider端应用实例的分组，目前有两种方式能够完成实例分组，分别是动态规则打标和静态规则打标，其中动态规则相较于静态规则优先级更高，而当两种规则同时存在且出现冲突时，将以动态规则为准。

2. 使用方式

下面咱们简单的讨论下标签路由的使用方式：

2.1 标签路由

• 动态规则打标，可随时在服务治理控制台下发标签归组规则

  # demo-provider应用增长了两个标签分组tag1和tag2
  # tag1包含一个实例 127.0.0.1:20880
  # tag2包含一个实例 127.0.0.1:20881
  ---
    force: false
    runtime: true
    enabled: true
    key: demo-provider
    tags:
      - name: tag1
        addresses: ["127.0.0.1:20880"]
      - name: tag2
      addresses: ["127.0.0.1:20881"]

• 静态打标

  <dubbo:provider tag="tag1"/>

或者

<dubbo:service tag="tag1"/>

或者

java -jar xxx-provider.jar -Ddubbo.provider.tag={the tag you want, may come from OS ENV}

Tips：消费端经过编程的方式使用 RpcContext.getContext().setAttachment(CommonConstants.TAG_KEY,"TAG_A")请求标签的做用域为每一次 invocation，使用 attachment 来传递请求标签，注意保存在 attachment 中的值将会在一次完整的远程调用中持续传递，得益于这样的特性，咱们只须要在起始调用时，经过一行代码的设置，达到标签的持续传递。

• 字段说明：

编号	字段名称	说明	必填
1	scope	路由规则的做用粒度，scope的取值会决定key的取值。 service 服务粒度 application 应用粒度。	必填
2	Key	明确规则体做用在哪一个接口服务或应用。 scope=service时， key取值为[{group}:]{service}[:{version}]的组合 scope=application时， key取值为application名称 。	必填
3	enabled	enabled=true 当前路由规则是否生效，，缺省生效。	可不填
4	force	force=false 当路由结果为空时，是否强制执行，若是不强制执行， 路由结果为空的路由规则将自动失效，缺省为 false。	可不填
5	runtime	runtime=false 是否在每次调用时执行路由规则， 不然只在提供者地址列表变动时预先执行并缓存结果， 调用时直接从缓存中获取路由结果。若是用了参数路由，必须设为 true， 须要注意设置会影响调用的性能，缺省为 false。	可不填
6	priority	priority=1 路由规则的优先级，用于排序，优先级越大越靠前执行，缺省为 0。	可不填
7	tags	定义具体的标签分组内容，可定义任意n（n>=1）个标签并为每一个标签指定实例列表。其中name为标签名称	必填

2.2 降级约定

• request.tag=tag1 时优先选择标记了tag=tag1 的 provider。若集群中不存在与请求标记对应的服务，默认将降级请求 tag为空的provider；若是要改变这种默认行为，即找不到匹配tag1的provider返回异常，需设置request.tag.force=true。
• request.tag未设置时，只会匹配tag为空的provider。即便集群中存在可用的服务，若 tag 不匹配也就没法调用，这与约定1不一样，携带标签的请求能够降级访问到无标签的服务，但不携带标签/携带其余种类标签的请求永远没法访问到其余标签的服务。

Tips： 2.6.x 版本以及更早的版本请使用 老版本路由规则，自定义路由参考 路由扩展

3. 使用场景

从上面的简单介绍咱们能够大体了解到，标签路由经过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的。咱们平常工做中经常使用的场景有：蓝绿发布、灰度发布等场景的能力基础等。

4. 示例演示

咱们以获取图书列表为例进行实例演示，其中咱们会启动两个服务提供者配置两个端口：20880、20881，而后分别指定两个服务标签为：TAG_A、TAG_B。项目结构图以下：

这里咱们使用动态打标的方式全部 XML 中的配置维持之前案例的配置，咱们主要看看 Dubbo Admin 中的配置：

# demo-provider 应用增长了两个标签分组 TAG_A 和 TAG_B
# TAG_A 包含一个实例 127.0.0.1:20880
# TAG_B 包含一个实例 127.0.0.1:20881
force: true
enabled: true
runtime: false
tags:
 - name: TAG_A
   addresses: [192.168.0.1:20880]
 - name: TAG_B
   addresses: [192.168.0.2:20881]

以上动态打标配置表示：当消费端指定标签为 TAG_A 时调用 127.0.0.1:20880 服务提供者，标签为 TAG_B 时调用 127.0.0.1:20881 服务。

Tips： 小伙伴经过在消费端动态切换标签 TAG_A和 TAG_A来查看效果，服务端只需启动一个端口为20880的服务便可。

5. 实现原理

根据前面的介绍咱们知道在消费端调用远程服务时经过路由规则进行服务的过滤，那么咱们经过源码简单的分析下这个处理过程。这里咱们直接看到路由规则的调用核心代码`org.apache.dubbo.rpc.cluster.
RouterChain#route`核心方法以下：

public List<Invoker<T>> route(URL url, Invocation invocation) {
        List<Invoker<T>> finalInvokers = invokers;
        for (Router router : routers) {
            finalInvokers = router.route(finalInvokers, url, invocation);
        }
        return finalInvokers;
    }

下面展现了咱们运行过程当中的路由规则：

其中TagRouter就是咱们的标签路由核心代码以下：

/**
     *
     * 标签路由
     *
     * @author liyong
     * @date 4:48 PM 2020/11/29
     * @param invokers
     * @param url
     * @param invocation
     * @exception
     * @return java.util.List<org.apache.dubbo.rpc.Invoker<T>>
     **/
    @Override
    public <T> List<Invoker<T>> route(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException {
        if (CollectionUtils.isEmpty(invokers)) {
            return invokers;
        }

        // 这里由于配置中心可能更新配置，全部使用另一个常量引用（相似复制）
        final TagRouterRule tagRouterRuleCopy = tagRouterRule;
        //若是动态规则不存在或无效或没有激活，使用静态标签
        if (tagRouterRuleCopy == null || !tagRouterRuleCopy.isValid() || !tagRouterRuleCopy.isEnabled()) {
            //处理静态标签
            return filterUsingStaticTag(invokers, url, invocation);
        }

        List<Invoker<T>> result = invokers;
        //获取上下文中Attachment的标签参数，这个参数由客户端调用时候写入
        String tag = StringUtils.isEmpty(invocation.getAttachment(TAG_KEY)) ? url.getParameter(TAG_KEY) :
                invocation.getAttachment(TAG_KEY);

        // 若是存在传递标签
        if (StringUtils.isNotEmpty(tag)) {
            //经过传递的标签找到动态配置对应的服务地址
            List<String> addresses = tagRouterRuleCopy.getTagnameToAddresses().get(tag);
            // 经过标签分组进行过滤
            if (CollectionUtils.isNotEmpty(addresses)) {
                //获取匹配地址的服务
                result = filterInvoker(invokers, invoker -> addressMatches(invoker.getUrl(), addresses));
                //若是返回结果不为null 或者 返回结果为空可是配置force=true也直接返回
                if (CollectionUtils.isNotEmpty(result) || tagRouterRuleCopy.isForce()) {
                    return result;
                }
            } else {
                //检测静态标签
                result = filterInvoker(invokers, invoker -> tag.equals(invoker.getUrl().getParameter(TAG_KEY)));
            }
            //若是提供者没有配置标签 默认force.tag = false 表示能够访问任意的提供者 ，除非咱们显示的禁止
            if (CollectionUtils.isNotEmpty(result) || isForceUseTag(invocation)) {
                return result;
            }
            else {
                //返回全部的提供者，不须要任意标签
                List<Invoker<T>> tmp = filterInvoker(invokers, invoker -> addressNotMatches(invoker.getUrl(),
                        tagRouterRuleCopy.getAddresses()));
                //查找提供者标签为空
                return filterInvoker(tmp, invoker -> StringUtils.isEmpty(invoker.getUrl().getParameter(TAG_KEY)));
            }
        } else {
            //返回全部的 addresses
            List<String> addresses = tagRouterRuleCopy.getAddresses();
            if (CollectionUtils.isNotEmpty(addresses)) {
                result = filterInvoker(invokers, invoker -> addressNotMatches(invoker.getUrl(), addresses));
                // 1. all addresses are in dynamic tag group, return empty list.
                if (CollectionUtils.isEmpty(result)) {
                    return result;
                }
            }
           //继续使用静态标签过滤
            return filterInvoker(result, invoker -> {
                String localTag = invoker.getUrl().getParameter(TAG_KEY);
                return StringUtils.isEmpty(localTag) || !tagRouterRuleCopy.getTagNames().contains(localTag);
            });
        }
    }

上面的代码中把主要的流程进行注释，请小伙伴自行进行代码调试查看。

6. 小结

在本小节中咱们主要学习了 Dubbo 中路由规则之标签路由以及使用方式。同时也分析了标签路由规则实现的原理：若是消费端传递标签则和配置的动态规则和静态规则进行匹配，若是消费端未传递标签则使用服务提供端的本地配置的静态标签和动态配置标签进行匹配。

Tips： 动态规则相较于静态规则优先级更高，而当两种规则同时存在且出现冲突时，将以动态规则为准。

本节课程的重点以下：

1. 理解 Dubbo 标签路由
2. 了解了标签路由使用方式
3. 了解标签路由实现原理
4. 了解标签路由使用场景

做者

我的从事金融行业，就任过易极付、思建科技、某网约车平台等重庆一流技术团队，目前就任于某银行负责统一支付系统建设。自身对金融行业有强烈的爱好。同时也实践大数据、数据存储、自动化集成和部署、分布式微服务、响应式编程、人工智能等领域。同时也热衷于技术分享创立公众号和博客站点对知识体系进行分享。关注公众号： 青年IT男 获取最新技术文章推送！

博客地址： http://youngitman.tech

微信公众号：