- 每个项目单独部署一整套系统，注册中心也单独部署，优点是实现简单，缺点是机器资源占用太多；
在消费方应用中通过硬编码或者配置文件的方式指定调用的接口机器ip和端口，优点也是实现简单，缺点是依赖配置复杂。此方案在简单的依赖中可以使用，但在依赖复杂的环境中较难实施；
- 通过逻辑上的分组将请求正确的路由，优点是逻辑清晰机器资源占用少，缺点是实现困难。此方案也正是本文需要探讨的方案。
如果使用的是dubbo，那么在dubbo 2.6.6版本之后提供了一个标签路由（tag router）功能来解决此问题。标签路由通过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，可以作为蓝绿发布、灰度发布等场景的能力基础。
它与dubbo的version、group机制有什么区别？dubbo的version与group是静态的路由，如果URL中带了不匹配的version，在上图代码中的invokers就根本不存在该服务提供者；而tag路由是动态的，就算带了不匹配的tag，也是会放在invokers中，每次调用时都执行一次路由逻辑。
consumer dubbo.tag=tag1 时优先选择标记了tag=tag1的provider。若集群中不存在与请求标记对应的服务，默认将降级请求 tag为空的provider；如果要改变这种默认行为，即找不到匹配tag1的provider返回异常，需设置request.tag.force=true；
consumer dubbo.tag未设置时，只会匹配tag为空的provider。即使集群中存在可用的服务，若tag不匹配也就无法调用，这与约定1不同，携带标签的请求可以降级访问到无标签的服务，但不携带标签/携带其他种类标签的请求永远无法访问到其他标签的服务。
标签路由的“bug”
经过测试发现，consumer端的dubbo.tag通过dubbo的attachment 携带给provider端，但是 attachment有一个特点是在dubbo请求完成会把attachment中保存的值清空，也就是说consumer第一次dubbo请求会带dubbo.tag，第二次请求不会带。
基于dubbo标签路由打造并行测试环境
翻看了标签路由在github上的PR，能看出作者也是知道这个问题的，而且提出建议通过servlet 过滤器(在web环境下)，或者定制的 SPI 过滤器设置 dubbo.tag。由此我们想到利用dubbo的SPI机制扩展filter来填充attachment，在provider接收到请求时将dubbo.tag存起来，每次发起调用时再将tag塞回attachment。
还是以开头的例子，两个项目同时测试，则需要两个tag，需求1定义tag为green，需求2定义tag为red
- 首先需要一套部署ABCD的稳定环境，即没有打tag的环境，其次再创建新的应用A、C，并打上tag=green，创建新应用A、B、E并打上tag=red，让稳定环境与新创建的机器都注册到一个注册中心；
其次在请求发起处将tag塞入attachements，这一步通常是网关或者调用工具来完成；
- provider端接收到请求将请求中的tag存在ThreadLocal（EnvContext）中；
- 第一次调用将执行tag路由选择，当调用完成并执行完ConsumerContextFilter之后再将tag塞回attachements，以便将tag传递给下一次调用；
最后本次调用完毕，DubboTagProviderFilter会清除存储的tag信息，不污染下一次请求。
-----
欢迎扫码关注我的公众号“捉虫大师”，一个找bug小能手，专注后端，bug分析，源码分析。
