目标
技术目标: 上行到消息队列api吞吐量10000条/秒,下发第三方平台1000条/秒(仅平台自身处理能力,第三方看第三方处理能力极限指标为准);保证消息中心100%高可用。
业务目标: 对接新需求,明确消息中心的负责人(架构组),及时响应业务处理或者反馈。
产品目标: 支持消息处理状态查询,简单的消息规范消息对接(初级开发5分钟实现接入成本),规范化消息模板办理。
需求原型
功能需求:
支持阿里云短信,微信公众号,app推送,统一站内信,企业微信(应用,个人)等第三方推送。
包含消息模板管理,账户管理,消息搜索,批量消息发送等。
技术方案
业务部署交互图
业务核心逻辑交互图
技术选型 |
优势 |
缺点 |
rocketmq |
【性能好】单个吞吐量能达10万/秒,并行推送能力(消费能力)可以通过rocketmq的分区(分区细节需要设计)数量进行扩展。性能上面是一个亮点和优势 |
【部分功能不支持】一旦进入rocketmq队列,推送消息不可撤回。很多数据库层面的功能特性(mq不支持)在设计上就会舍弃。 |
es |
【性能好】可以支撑上亿的数据量的关键词搜索,实时同步的性能和吞吐量都还可以。 |
【并发插入能力略差】假设消息下发吞吐量高,需要批量对消息进行同步,这样可以优化es吞吐量。高并发对es同步,es承载能力可能会出问题(可以投入测试进行验证)。 |
概要设计描述
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 线上一体化部署的支持,要做到一键发布,一键回滚,滚动发布,不停机发版。