Spring Cloud -Hoxton.RELEASE(十三):灰度发布-Gateway

灰度发布

首先使用Gateway自带的WeightRoutePredicateFactory(权重路由断言工厂)来实现简单的灰度发布需求。
这里用上一章《Spring Cloud -Hoxton.RELEASE(十二):动态路由-Gateway》)的代码做示范

权重断言

修改gateway项目的application.yml为:

server:
port: 5432

spring:
application:
name: gdr-gateway
cloud:
nacos:
discovery:
server-addr: localhost:8848
gateway:
routes:
- id: gdr-client1
uri: lb://gdr-client1
predicates:
- Path=/gdr-client1/**
filters:
- StripPrefix=1
- id: canary-client-v1
uri: https://www.baidu.com
predicates:
- Path=/canary-client
#权重断言(第一个参数为group(组),第二个参数为weight(权重))(该路由权重为70%)
- Weight=canary-client,70
- id: canary-client-v2
uri: https://www.bing.com
predicates:
- Path=/canary-client
#相同请求权重配置的group(组)必须相同
- Weight=canary-client,30

management:
endpoints:
web:
exposure:
include: info,health,refresh,gateway

重启gateway项目并访问http://localhost:5432/canary-client,在数十次访问之后,可以得出大概符合配置的权重的结论。

使用权重断言做灰度的不足以及改进方案

权重灰度的问题

通过上面的权重灰度示例,我们似乎找到了解决灰度发布需求的方法,但是还是存在一些问题,下面用两个实际示例来说明:

  1. 接口灰度,因为每次请求的时候都会根据权重随机分配理由,结果刷新一下页面数据就可能变的不一样了,用户茫然不知所措。
  2. 资源灰度,客户端每次进入首页都会根据权重随机分配进行资源更新(或者不更新),结果每次都有可能下载热更包更新或者回退,浪费资源不说,每次回去首页客户端的ui或功能都有可能发生变动,实在是不够友好。
    上面两个示例已经很说明基于权重的灰度存在的问题了,即灰度状态是不稳定的并且用户无法选择退出。

权重灰度的改进思路

方案分为两段式的,即第一段下发版本,第二段基于版本进行灰度。
其中第一段有两种做法:

  1. 基于权重进行版本接口灰度,即在用户登陆或者进入客户端首页时候获取版本信息并保存
  2. 先在现有用户群里面筛选符合条件的用户集合(这个过程可以是自动也可以是用户主动申请),然后发送包含确认链接的邮件,等用户请求这个链接确认参与灰度测试之后(或者省略这个确认过程),将该用户标识添加到灰度测试组,然后在用户访问资源的时候根据组别获取版本信息并保存(说起来感觉更像是做公测)
    我们这里采用第一种方式做说明。

🕊了