初探-Discovery开源框架-gateway灰度方案

5,856 阅读2分钟

前言

在上一篇介绍了自定义实现网关灰度方案

Discovery 框架比较成熟的开源框架,可以参考里面实现方案。Discovery实现了Eureka、Nacos等等注册中心灰度,以及通过redis、Nacos、Etcd来实现配置中心(为了网关动态配置)还有类似apm全链路变量传递功能,以及改写fegin、resttemplate负载均衡

Discovery

官网

逻辑架构图

image.png

个人理解

打标过程

打标类型操作
主动打标自身带上特定的header,比如说postman请求的时候自动带上灰度标识
被动打标流量经过网关的时候,判断req符合什么条件,给它打标,然后再路由

网关路由

协议操作
lb就是在loadBalance选择serverInstance的时候判断,对应注册中心里面的服务的metaData标识,然后将他们过滤,然后再进行负载算法
http可以通过不同域名来实现负载,比如说灰度用户->网关->灰度路由->灰度pod

需要重写代码

  1. Fegin、restTemplate负载需要重写
  2. 全链路需要把变量传递下去(apm是最基础部分就体现在这里)
  3. 实现网关动态配置(灰度开始跟灰度结束都需要用到)

源码解读(网关路由相关)

AbstractGatewayStrategyRouteFilter

image.png

各种标识

image.png

image.png

这两个方法就是疯狂往header头塞数据

image.png

把exchange塞到context里头,方便后续拿到

我相信读者跟我一样闷逼,为啥塞一堆header但是网关怎么根据header来路由呢?直到......

DiscoveryEnabledAdapter

DiscoveryEnabledAdapter这个类Ribbon路由规则器,网关在gateway比较旧的版本是采用ribbon来进行负载均衡

注意点!!!

网关在gateway比较旧的版本是采用ribbon来进行负载均衡,所以在新版的话是采用loadbalance来实现,可以看下初探灰度发布系列--AB Test以及栗子

它的实现类是DefaultDiscoveryEnabledAdapter

DefaultDiscoveryEnabledAdapter

image.png

image.png

com.nepxion.discovery.plugin.strategy.adapter.DefaultDiscoveryEnabledAdapter#applyVersion

image.png

serviceId为何物?

image.png

PredicateBasedRuleDecorator

com.nepxion.discovery.plugin.framework.decorator.PredicateBasedRuleDecorator#getServerList

image.png

image.png

在这里就需要用到上面那个apply,会将所有serverId符合条件的筛选出来

到这里我们就懂了,其实就是负载的时候,apply去筛选符合条件的serverInstance然后进行路由

总结

跟我之前写的自定义灰度方案,思想是一样的,不外乎是一个协议lb,然后拿到serverList,然后根据metaData以及header来路由

当然在新版gateway版本已经不采用ribbon来转发了,这个要注意下,好像能给社区提个issue,美滋滋~

给社区提issue

来着大佬的回复:

image.png

开源版本只兼容gateway版本,想要好东西加钱,哈哈

当然大家可以参照我这篇来改