消费者灰度实现思路

• 灰度发布
• nepxion关于同步的实现逻辑
• 异步实现思路
  • 优点
  • 缺点
• 细节实现

灰度发布

灰度发布又叫金丝雀发布,允许将新功能的发布后让部分用户先使用,如果功能正常,再切换为全量用户, 国内目前使用最多的是nepxion这个框架

我们公司从2019年就开始引入了该框架,最直接的变化就是:

1. 不必为新功能的发布而熬夜通宵
2. 因新功能引入的事故数量明显下降

然而框架目前支持了同步调度的灰度发布,并没有对异步消费的信息实现灰度 , 随着灰度在全公司的普及后, 对消费者进行灰度的需求就越来越强烈

nepxion关于同步的实现逻辑

先将同步灰度调度进行简单梳理:

1. 同步调度的前提 -- 服务全部注册在同一个注册中心中 -- 服务注册时可以标识出当前服务是灰度实例还是正常实例,如eureka服务注册时允许自定义扩展metadata -- 无论是RestTemplate还是Feign,都必须通过服务名进行调度
2. 调用的过程 -- 服务发现允许实例感知到注册中心中注册的其他实例,包括实例的元信息 -- 通过loadbalance进行服务之前调用时会进入进行灰度的拦截器中,serviceName→ip:port这里会有进行实例的过滤 -- 返回服务名对应的服务实例地址,调用http请求

对于消费者的灰度目前并没有直接提供,可能作者处于商业原因,或者对于现有的一些方案并不满意,没有达到自己的期望值.

异步实现思路

1. 灰度consumer不与mq建立连接,但是会暴露一个web接口
2. 非灰度实例才会与mq建立通道, 消息消费时首先经过一层切面, 切面中会对消息体判断,非灰度直接消费,灰度则调用灰度实例的web接口

优点

1. 简单
2. 能够充分利用原有框架的逻辑,如果原有框架发生任何问题,因为灰度判断相同,因此直接适配

缺点

1. mq会实现可靠投递,但是web并不保证可靠消费呀
   • 目前项目是一个平台的产品,那么问题来了,什么样的用户会首先拿来灰度? 答案是不重要的商户,因此因web调用导致消息丢失(概率很低)可以接受,也做了日志记录

细节实现

虽然代码写完并且已经在部分项目组使用了,但作为公司资产,还是不提供代码了, 只提及一些细节实现

1. 灰度实例暴露一个web接这里直接使用springmvc的handlerMapping接口(实际参照了spring-boot-actuator的部分代码),扫描所有@RabbitHandler;可以按照队列的名字作为web的url;实现会很简单, 项目的代码中并不需要做改动
2. 消费者在转发web接口后,可以发送一个成功/失败的事件,这样子就避免了部分项目认为所有消息都不可丢失的问题
3. spring-rabbit并没有找到和mebmvc一样一个本地线程变量存放请求,也没有webmvc那样有一个前置处理(这个有)+后置处理(这个没有)这种搭配, 因此这里将要对于发送的消息,限定一个数据结构,将诸如上游的header等灰度依赖的参数包装进去.这里会对代码有一定侵入性.比如:

    /**
     * 上游request的header信息
     */
    private final Map<String, String> headers = new HashMap<>();
    /**
     * 额外信息
     */
    private Map<String, Object> extraData;

    /**
     * 实际要发送的信息
     */
    private T data;