1 参考文档
2 消息中心目标职责
- 消息中心仅作为消息发送使用,跟业务没有任何关系,涉及到业务部分有业务系统自行处理;
- 消息中心的功能只有消息生产、消息展示、消息推送、消息维护等相关功能;
- 业务系统想要引用消息,需要先按照消息中心的统一规范注册,消息中心会按照消息类型判断是否需要扩展;
3 设计方案
3.1 方案1:提供sdk没有MQ
3.2 方案2:提供sdk,借助MQ
3.3 方案3:不提供sdk,借助MQ
3.4 比较
3.4.1 无sdk
优点:
- 业务系统无需集成sdk,跟消息中心完全解耦;
- 无需关注后续sdk升级等问题;
- 消息中心不可用时,不影响业务系统正常消息发送;
缺点:
- 使用成本高,新业务集成无法知道消息体包装是否正确,中间的调试排查成本高;
- 业务系统需要引入mq等配置信息和组件,增加了业务系统的复杂度;
- 不利于后期对mq的升级改造;
3.4.2 有sdk
优点:
- 集成成本低,只要按照sdk接口封装消息调用即可,便于新手集成以及调试;
- 业务系统无需关注消息处理方式,不需要引入mq组件;
- 消息中心统一选择mq组件,方便后期升级改造;
缺点:
- 业务方需要集成skd,跟消息中心耦合在一起;
- 业务系统需要维护sdk的版本;
- 消息中心服务不可用时,消息无法正常发送,造成消息丢失;
3.4.3 有mq
优点:
- 处理延迟消息时无需借助其他方案,比如定时器或者轮询;
- 削峰,有效保证消息中心能够始终稳定处理消息;
- 有效保证处理的顺序性;
缺点:
- 引入mq后,增加了复杂度;
- 需要保证mq的可用性;
3.4.4 无mq
优点:
- 降低了系统的复杂度;
缺点:
- 需要保证消息中心的并发、高可用等各种复杂场景;
3.5 结论
- 消息中心1.0用方案1设计,等业务扩展后再用方案2模式;
- 延迟消息推送可以借助mq来处理;
4 消息类型配置
4.1 消息分类
说明:用于在消息中心里面展示的一级消息分类
- 非空字段:类型名称、图标、删除标识、显示标识
- 初始数据:未删除、不显示
- 排序规则:降序
4.2 展示端
说明:定义不用的展示端用于区别每个展示端需要拉取什么样的消息分类,例如:企业端和专家端的消息一级分类就有区别
非空字段:端名称、端编码
4.3 展示端与消息分类
它们两为聚合关系非前绑定,又是多对多关系。所以这里引用关联表处理
5 业务系统使用-sdk方式
5.1 sdk方法
5.1.1 发送方式
- 单个发送消息(可以考虑去掉)
- 批量发送消息
5.1.2 撤回方式
- 单个消息撤回(可以考虑去掉)
- 批量消息撤回
5.1.3 发送形式
- 短信
- 站内信
- 极光推送
5.2 消息内容
名称 | 类型 | 是否必选 | 备注 |
---|---|---|---|
消息类型 | 是 | 1:系统公告,2:政府公告,3:专家问答,4:暂定 | |
发送人类型 | 1:admin-user,2:government-user,3:user | ||
发送人id | id | ||
发送人名称 | 个人名称或者单位名称 | ||
发送时间 | 为Null 则立即发送,传时间则按时间发送 | ||
接收人id | id | ||
接收人手机号 | 手机号 | ||
消息标题 | |||
消息体 | 100个字符 | ||
消息图片 | |||
触发渠道 | Null 则默认站内信,1:站内信,2:短信,3:电话,4:其他 | ||
操作反馈类型 | 1:无,2:详情,3:站内跳转,4:外链 | ||
操作反馈内容 | 无:不跳转,详情:id,站内跳转:请求连接,外链:对应的外链连接 | ||
重要性 | Null则默认为1,1:低(未读显示点),2:中(未读显示数字),3:高 |
6 消息处理
6.1 数据表字典
6.2 核心功能
6.2.1 1.0 直接落库
延迟推送消息借助mq处理
6.2.2 2.0 借助MQ处理
消息生产
统一接收业务系统推送过来的消息,并全部往mq服务中push,考虑到后期并发等问题这里不做落库处理;
- 短信
- 极光推送
- 站内的
消息发送流程:
消息消费
统一从mq中pull消息并进行计算,落库处理
备注:
考下延迟消息处理方案:轮询,再往mq发送延迟消息
落库计算和发送渠道是2部分
-
短信
-
极光推送
-
站内
7 消息管理
消息类型列表接口
根据端标识来展示消息类型列表
列表中要包含:类型信息+最新消息+未读数量
消息类型下消息列表分页接口
查询消息类型下的所有消息,需要分页展示、排序
未读数量接口-总合计
查询用户所有未读的消息合计
已读接口
修改消息阅读状态
删除接口
消息逻辑删除
总结
每种方案都有特殊场景需要,具体选择哪种还要看当前项目实际场景来;
如果是着急用消息中心,并发量和处理能力没有要求,则可以选择方案1有开发周期短,接入成本低优势;
如果业务对消息中心要求高,承载的责任大,并发量大等场景,则选择用方案2,借助MQ来处理;
如果还有一些复杂的场景,或者老项目使用,老项目又无法集成当前消息中心的sdk,则直接考虑用方案3;
我在使用时,是先通过方案1实现了消息中心的基本功能,确保当前消息中心承载着应有的功能职责。随着业务系统的发展和消息发送量的增加通过方案2对消息中心进行升级,不影响sdk的正常使用,所以说是一个迭代的过程。
最后感悟一下:所有的设计一定要根据公司和当前项目状况,你的设计很可能非常完美,但是不一定符合公司当前现状。