今天给大家分享一个比较完整的亿级消息中心的架构方案！设计目标技术目标：上行至消息队列API吞吐量10000条/秒，向第三方平台投递1000条/秒（仅为平台自身处理能力，第三方指代第三方处理能力极限指数）；保证消息中心100%高可用。业务目标：满足新需求，明确消息中心（架构组）负责人，及时响应业务处理或反馈。产品目标：支持消息处理状态查询、简单的消息规范消息对接（初级开发5分钟达到接入成本）、标准化的消息模板处理。需求原型需求原型如下图所示：功能需求：支持阿里云短信、微信公众号、应用推送、统一站消息、企业微信（应用、个人）等第三方推送。包括消息模板管理、账户管理、消息搜索、消息批量发送等技术方案业务部署交互图：业务核心逻辑交互图：技术选型①RocketMQ优势：性能好，单次吞吐可达每秒10万条，并行推送能力（消费能力）可以通过RocketMQ进行分区（分区细节需要设计）数量进行扩展。以上性能是亮点和优势。缺点：不支持部分功能。推送消息一旦进入RocketMQ队列，就无法撤回。很多数据库级别的功能特性（MQ不支持）在设计上会被抛弃。②ES优势：性能好，可以支持亿级数据量的关键词搜索，实时同步性能和吞吐量都不错。缺点：并发插入能力稍差。假设消息传递吞吐量高，需要批量同步消息，可以优化ES的吞吐量。如果使用高并发来同步ES，ES的承载能力可能会有问题（可以测试验证）。大纲设计说明RocketMQ设计了普通消息队列（消息的正常投递）、重试消息队列（支持多种延迟机制、发送失败重试消息）、发送结果消息队列（发送超限或成功消息）。ES同步上述三个队列的消息，使消息信息保持最新，最终一致性（最新时间戳验证）。MySQL只支持管理模板、账户等基本管理功能。底层框架设计、运维层面说明①统一网关：SpringCloudGateway/Kong，只支持API层面的路由。②基础框架：选择jar包版本、ES、RocketMQ、实时告警、性能监控，对这些接口进行二次打包。ES支持SQL模式插入查询；RocketMQ作为底层实现剥离。参考bsf统一基础框架：https://gitee.com/yhcsx/csx-bsf-all③业务框架：标准输入输出HttpRPC等业务框架工具或协议层支持。④服务高可用：支持K8s&Docker和DevOps在线集成部署，一键发布，一键回滚，滚动发布，不间断发布。作者：车江毅编辑：陶家龙来源：cnblogs.com/chejiangyi/p/14884931.html
