一份完整的亿级消息中心架构方案

目标

技术目标: 上行到消息队列api吞吐量10000条/秒，下发第三方平台1000条/秒（仅平台自身处理能力，第三方看第三方处理能力极限指标为准）；保证消息中心100%高可用。

业务目标: 对接新需求，明确消息中心的负责人（架构组），及时响应业务处理或者反馈。

产品目标: 支持消息处理状态查询，简单的消息规范消息对接（初级开发5分钟实现接入成本），规范化消息模板办理。

需求原型

功能需求

支持阿里云短信，微信公众号，app推送，统一站内信，企业微信（应用，个人）等第三方推送。包含消息模板管理,账户管理,消息搜索,批量消息发送等。

技术方案

业务部署交互图

业务核心逻辑交互图

概要设计描述

1. rocketmq 设计正常消息队列(正常投递消息)，重试消息队列（支持多种延迟机制,发送失败重试的消息），发送结果消息队列（发送超限或者成功的消息）。
2. es 同步以上三种队列的消息，以最终一致性（最晚时间戳校验）保持消息信息最新。
3. mysql 仅支持管理模板，账号等基础管理功能。

底层框架设计、运维层面描述

1. 统一网关: spring cloud gateway/kong，仅做api层面的路由支持。
2. 基础框架: 选定jar包版本,es,rocketmq,实时报警,性能监控 对这些接口做二次封装，es支持sql模式插入查询；rocketmq做底层实现剥离。参考: bsf 统一基础框架 https://gitee.com/yhcsx/csx-bsf-all
3. 业务框架: 标准输入输出http rpc等业务框架工具或协议层面支持。
4. 服务高可用：k8s&docker 及devops 线上一体化部署的支持,要做到一键发布,一键回滚,滚动发布,不停机发版。