系统架构图

cache

DocumentDB

存储层

客户端

应用层

push message

app-center

Redis

kafka消息消费(部分)

message

user

第二阶段：灰度部分标的；双系统同时都存在推送消息行为；1. 修改rancher配置，基于标的取模值的配置，灰度部分标的至新盯盘系统；并逐步放大，校验消息发送结果；

网络层

推送消息

kafka消息消费

data-platform

calculate

第一阶段：发布盯盘新系统服务，关闭真正消息推送；ng流量切至新系统1. 新盯盘系统服务发布，包括Service/Cache/Calculate/Message四个模块；2. 计算/消息模块消费kafka消息（同data-platform一样），但消息模块关闭消息推送开关，但放开灰度部分用户；日志记录的方式打印消息内容；通过比对用户收到的消息与日志记录的消息比对是否逻辑正常；3. 通过线上数据的正常流程，评估Redis内存/JVM/CPU等性能指标，得出资源评估结果；包括：Redis内存大小、各服务JVM 内存大小、实例数；4. 老系统修改并发布，基于标的取模的方式灰度部分标的；当前阶段所有标的计算/消息都走老系统；

service

kafka消息消费（部分）

第三阶段：完成灰度；只有新盯盘系统推送消息；老系统只维护Redis1. 修改rancher配置，所有标的计算/消息都走新盯盘系统；2. 此时NG流量切换至新盯盘系统；3. 修改盯盘老系统并发布，关闭所有kafka消息、job任务入口，仅保留Redis数据维护相关工作；4. 系统稳定运行一周后，停掉老的data-platform服务，清理consul配置；迁移并清理user/data-platform盯盘库；Redis清理老的盯盘系统key;