今天给大家分享一份较为完整的份完方案亿级消息中心的架构方案!  

设计目标

技术目标：上行到消息队列 API 吞吐量 10000 条/秒，下发第三方平台 1000 条/秒(仅平台自身处理能力，整的中心第三方看第三方处理能力极限指标为准);保证消息中心 100% 高可用。亿级 业务目标：对接新需求，消息明确消息中心的架构负责人(架构组)，及时响应业务处理或者反馈。份完方案 产品目标：支持消息处理状态查询，整的中心简单的亿级消息规范消息对接(初级开发 5 分钟实现接入成本)，规范化消息模板办理。消息

需求原型

需求原型如下图：

功能需求：

支持阿里云短信，架构微信公众号，份完方案App 推送，整的中心统一站内信，亿级企业微信(应用，消息个人)等第三方推送。架构 包含消息模板管理，账户管理，消息搜索，批量消息发送等。

技术方案

业务部署交互图：

业务核心逻辑交互图：

技术选型

①RocketMQ

优势：性能好，源码下载单个吞吐量能达 10 万/秒，并行推送能力(消费能力)可以通过 RocketMQ 的分区(分区细节需要设计)数量进行扩展。性能上面是一个亮点和优势。 缺点：部分功能不支持，一旦进入 RocketMQ 队列，推送消息不可撤回。很多数据库层面的功能特性(MQ 不支持)在设计上就会舍弃。

②ES

优势：性能好，可以支撑上亿的数据量的关键词搜索，实时同步的性能和吞吐量都还可以。 缺点：并发插入能力略差，假设消息下发吞吐量高,需要批量对消息进行同步，这样可以优化 ES 吞吐量。高并发对 ES 同步，ES 承载能力可能会出问题(可以投入测试进行验证)。

概要设计描述

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

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

①统一网关：Spring Cloud Gateway/Kong，仅做 API 层面的路由支持。

②基础框架：选定 jar 包版本，ES，RocketMQ，实时报警，性能监控，对这些接口做二次封装，ES 支持 SQL 模式插入查询;RocketMQ 做底层实现剥离。

参考 bsf 统一基础框架：

https://gitee.com/yhcsx/csx-bsf-all 

③业务框架：标准输入输出 Http RPC 等业务框架工具或协议层面支持。

④服务高可用：K8s&Docker 及 DevOps 线上一体化部署的支持，要做到一键发布，一键回滚，滚动发布，不停机发版。

作者：车江毅

编辑：陶家龙

出处：cnblogs.com/chejiangyi/p/14884931.html