全链路灰度发布框架（整体方案）

新服务

后端微服务n

后端微服务1

gateway

共用中间件数据

数据库灰度方案：前提条件：数据表字段只能新增，不能修改、删除；涉及修改的可在老字段上增加备注，标明弃用日期（删除的字段同理），然后新增字段。1、使用 新版本schema2、使用脚本进行数据同步（脚本需要支持到字段级别），只能对表数据进行同步，无法对数据结构同步。无需支持双向同步，只需要将数据从线上schema同步到灰度schema3、数据表的字段从数据库实时读取，并利用这读取到的字段进行同步。4、脚本按任务定时执行，直到上线后的一天，上线时直接切服务。

前端服务标识：请示头传递 version=v2.0

前端静态资源1

XXL-JOB:前提条件：定时任务中不涉及重要的业务，重要的业务禁止使用定时任务调度，考虑使用代理进行替换。实现方式：1、新版本涉及修改原定时任务的，直接新增，新版本上线后，将老版本的定时任务关闭。2、新版本新增的定时任务，直接新增即可。3、新版本需要删除老的定时任务的，在新版本上线测试阶段，新版内的代码注释，新版本正式上线后，删除调度任务。

前端静态资源3

同步老库存在的结构数据

中间件数据

说明：线上用户流量与新功能内测流量区分标识：内网IP 和 外网IP/版本标识【可以只开放部分地区新功能体验，根据IP来进行分流】

底层支持

入口流量（这里指通过NAT网关、WAF等前置安全设备后的流量）

前端静态资源2

后端微服务2

查询schema 内的表及字段

Redis : 前提条件：Redis 中存放的都是基础数据，如果查不到，各服务会自动新增数据到Redis中实现方式：新版本涉及到的新键值，直接新增即可，不存在新旧版本兼容的问题。

new_database_1

Python 脚本

线上用户流量

database_1

数据库实例

new_database_2

根据查询出来的结构获取数据

前端服务标识：请示头传递 version=v1.0

新功能内测流量

RocketMQ：前提条件：一个消费组只允许订阅一个topic实现方式：1、消息体中带上版本号；2、各版本服务消费和自己版本号匹配的消息及之前版本的消息；3、如果老版本服务消费到新版本的消息，消息不处理，直接存储在新版本消息表中（此处需要设计表结构，需要考虑是否按业务区分不同的表？）；4、新版本服务订阅表数据（Debezium/Canal 实现实时监听表数据的变化）实时消费，消费完之后物理删除数据，消费失败的数据进行10次重试，10次重试之后还是失败，放入死信数据表。

数据库

database_2

老服务