性能提升是我们追求的一个目标，合理的设计和实现有助于应对较多的复杂场景。有时，可能一个小小的改动点就能带来意想不到的效果。在本文中，将简单的介绍下标签路由的优化点。
标签路由
路由规则在发起一次RPC调用前起到过滤目标服务器地址的作用，过滤后的地址列表，将作为消费端最终发起RPC调用的备选地址。
Dubbo一般包含两类路由机制：
- 条件路由。支持以服务或者
Consumer应用为粒度配置路由规则。 - 标签路由。以
Provider应用为粒度配置路由规则。
标签路由通过将某一个或者多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，从而实现流量隔离的目的，可以作为蓝绿发布、灰度发布等场景的能力基础。
在标签路由中，请求标签的作用域为每一次invocation，使用attachment来传递请求标签，注意保存在attachment中的值将会在一次完整的远程调用中持续传递。
客户端获取invoker列表时，需调用org.apache.dubbo.rpc.cluster.directory.AbstractDirectory#doList方法，本文选择RegistryDirectory#doList的具体实现方法进行解析。
其中红线部分是根据路由机制过滤获取invoker列表。
遍历所有的路由规则进行过滤，本文只分析其中的标签路由TagRouter。
在具体路由过滤时，会根据设置的规则设置不同的过滤策略。
比如，在标签路由中首先会通过动态标签过滤，根据标签获取地址列表，然后根据地址列表匹配要需要的invokes。
最终都会调用filterInvoker方法执行过滤规则。
这里涉及到了一个性能优化点。
上述的红色区域是后续新增的代码，较早的代码不包含上述红色区域。
为什么后续又添加红色区域代码呢？
首先看下一位大佬提出的问题。
之所以会这样，是因为Collectors.toList()会创建一个新的List存储过滤的结果。
如果根据过滤规则没有过滤掉任何一个invoker，仍然和原先的内容一致，实际我们需要额外再创建一个新的List，所以加入了后续代码，当没有发生变化时，直接返回原先的List。这样操作有助于减少内存。
具体的解释可以参考下面的图片。
