一份完整的亿级消息中心架构方案！-技术圈

“

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

图片来自 Pexels

设计目标

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

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

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

需求原型

需求原型如下图：

功能需求：

技术方案

业务部署交互图：

业务核心逻辑交互图：

技术选型

①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

推荐阅读：

世界的真实格局分析，地球人类社会底层运行原理