全链路灰度/泳道/特征流量路由

[GuangmingLuo]

Original from a request of registry-etcd user : Service Discovery based on tag (基于Tag过滤的服务发现能力) #10

Is your feature request related to a problem? Please describe.
当多个研发在同一个需求中开发多个服务时，为了避免弄脏基准环境，预期可以有能力部署多泳道开发环境。

Describe the solution you'd like
目前想到的是在基准环境中建立需求功能环境，并将被修改的工程使用“功能环境标”签作为Tag注册到ETCD。
在测试流量中注入”功能环境标签“，Client在做服务发现时候，可基于该标签对Tag进行过滤，找出该功能环境中的实例，进行访问。（若无该标签的实例，则访问基准环境）。

【特征】流量路由，顾名思义就是将具有某些属性特征的流量，路由到指定的目标。流量路由是流量治理中重要的一环，我们可以基于流量路由标准来实现各种场景，如全链路灰度、金丝雀发布、泳道等。

先不考虑 Service Mesh （sidecar）支持的场景，主要分为三个点：给一组 workload 打标，标签的全链路透传，基于标签路由：

1. workload 打标又分为 k8s 调用场景和传统注册中心场景

   • k8s调用场景，可以用yaml的label，参考openkruise的模式，调用k8s api进行label修改和更新 （打破了 k8s 的不可变基础设施的原则），扩容的实例默认不带打的标签
   • 传统注册中心场景，通过环境变量制定标签（环境变量在整个实例的生命周期不改变），框架或者sdk读取环境变量中的标签，然后put到注册中心去，服务发现的时候，就能发现带标签的实例

2. 全链路透传，可以借助otel的能力，通过baggage来实现；如果全链路都是 Kitex 服务，也可以使用 metainfo 。

3. 标签路由，直接由 RPC 框架实现标签匹配路由，没有标签匹配的情况可以fallback 到default标签的实例上。

[sczyh30]

Hi，OpenSergo 社区也在联合咱们社区一起设计流量路由与染色相关的 specification，近期社区细化了 流量路由 spec，涵盖 流量 match、target destination、router chain 的细节设计，欢迎社区结合实践中的场景来一起讨论和完善相关的 spec 及实现方式~