- 灰度发布
- nepxion关于同步的实现逻辑
- 异步实现思路
- 优点
- 缺点
- 细节实现
灰度发布
灰度发布又叫金丝雀发布,允许将新功能的发布后让部分用户先使用,如果功能正常,再切换为全量用户, 国内目前使用最多的是nepxion这个框架
我们公司从2019年就开始引入了该框架,最直接的变化就是:
- 不必为新功能的发布而熬夜通宵
- 因新功能引入的事故数量明显下降
然而框架目前支持了同步调度的灰度发布,并没有对异步消费的信息实现灰度 , 随着灰度在全公司的普及后, 对消费者进行灰度的需求就越来越强烈
nepxion关于同步的实现逻辑
先将同步灰度调度进行简单梳理:
- 同步调度的前提 -- 服务全部注册在同一个注册中心中 -- 服务注册时可以标识出当前服务是灰度实例还是正常实例,如eureka服务注册时允许自定义扩展metadata -- 无论是RestTemplate还是Feign,都必须通过服务名进行调度
- 调用的过程 -- 服务发现允许实例感知到注册中心中注册的其他实例,包括实例的元信息 -- 通过loadbalance进行服务之前调用时会进入进行灰度的拦截器中,serviceName→ip:port这里会有进行实例的过滤 -- 返回服务名对应的服务实例地址,调用http请求
对于消费者的灰度目前并没有直接提供,可能作者处于商业原因,或者对于现有的一些方案并不满意,没有达到自己的期望值.
异步实现思路
- 灰度consumer不与mq建立连接,但是会暴露一个web接口
- 非灰度实例才会与mq建立通道, 消息消费时首先经过一层切面, 切面中会对消息体判断,非灰度直接消费,灰度则调用灰度实例的web接口
优点
- 简单
- 能够充分利用原有框架的逻辑,如果原有框架发生任何问题,因为灰度判断相同,因此直接适配
缺点
- mq会实现可靠投递,但是web并不保证可靠消费呀
- 目前项目是一个平台的产品,那么问题来了,什么样的用户会首先拿来灰度? 答案是不重要的商户,因此因web调用导致消息丢失(概率很低)可以接受,也做了日志记录
细节实现
虽然代码写完并且已经在部分项目组使用了,但作为公司资产,还是不提供代码了, 只提及一些细节实现
- 灰度实例暴露一个web接这里直接使用springmvc的handlerMapping接口(实际参照了spring-boot-actuator的部分代码),扫描所有@RabbitHandler;可以按照队列的名字作为web的url;实现会很简单, 项目的代码中并不需要做改动
- 消费者在转发web接口后,可以发送一个成功/失败的事件,这样子就避免了部分项目认为所有消息都不可丢失的问题
- spring-rabbit并没有找到和mebmvc一样一个本地线程变量存放请求,也没有webmvc那样有一个前置处理(这个有) 后置处理(这个没有)这种搭配, 因此这里将要对于发送的消息,限定一个数据结构,将诸如上游的header等灰度依赖的参数包装进去.这里会对代码有一定侵入性.比如:
/**
* 上游request的header信息
*/
private final Map<String, String> headers = new HashMap<>();
/**
* 额外信息
*/
private Map<String, Object> extraData;
/**
* 实际要发送的信息
*/
private T data;
