前言
在上一篇介绍了自定义实现网关灰度方案
Discovery 框架比较成熟的开源框架，可以参考里面实现方案。Discovery实现了Eureka、Nacos等等注册中心灰度，以及通过redis、Nacos、Etcd来实现配置中心（为了网关动态配置）还有类似apm全链路变量传递功能，以及改写fegin、resttemplate负载均衡
Discovery
官网
逻辑架构图
个人理解
打标过程
| 打标类型 | 操作 |
|---|---|
| 主动打标 | 自身带上特定的header，比如说postman请求的时候自动带上灰度标识 |
| 被动打标 | 流量经过网关的时候，判断req符合什么条件，给它打标，然后再路由 |
网关路由
| 协议 | 操作 |
|---|---|
| lb | 就是在loadBalance选择serverInstance的时候判断，对应注册中心里面的服务的metaData标识，然后将他们过滤，然后再进行负载算法 |
| http | 可以通过不同域名来实现负载，比如说灰度用户->网关->灰度路由->灰度pod |
需要重写代码
- Fegin、restTemplate负载需要重写
- 全链路需要把变量传递下去（apm是最基础部分就体现在这里）
- 实现网关动态配置（灰度开始跟灰度结束都需要用到）
源码解读（网关路由相关）
AbstractGatewayStrategyRouteFilter
各种标识
这两个方法就是疯狂往header头塞数据
把exchange塞到context里头，方便后续拿到
我相信读者跟我一样闷逼，为啥塞一堆header但是网关怎么根据header来路由呢？直到......
DiscoveryEnabledAdapter
DiscoveryEnabledAdapter这个类Ribbon路由规则器，网关在gateway比较旧的版本是采用ribbon来进行负载均衡
注意点！！！
网关在gateway比较旧的版本是采用ribbon来进行负载均衡，所以在新版的话是采用loadbalance来实现，可以看下初探灰度发布系列--AB Test以及栗子
它的实现类是DefaultDiscoveryEnabledAdapter
DefaultDiscoveryEnabledAdapter
com.nepxion.discovery.plugin.strategy.adapter.DefaultDiscoveryEnabledAdapter#applyVersion
serviceId为何物？
PredicateBasedRuleDecorator
com.nepxion.discovery.plugin.framework.decorator.PredicateBasedRuleDecorator#getServerList
在这里就需要用到上面那个apply，会将所有serverId符合条件的筛选出来
到这里我们就懂了，其实就是负载的时候，apply去筛选符合条件的serverInstance然后进行路由
总结
跟我之前写的自定义灰度方案，思想是一样的，不外乎是一个协议lb，然后拿到serverList，然后根据metaData以及header来路由
当然在新版gateway版本已经不采用ribbon来转发了，这个要注意下，好像能给社区提个issue，美滋滋~
给社区提issue
来着大佬的回复：
开源版本只兼容gateway版本，想要好东西加钱，哈哈
当然大家可以参照我这篇来改
