1 参考文档
产品参考：消息通知系统设计 | 人人都是产品经理 (woshipm.com)
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的正常使用，所以说是一个迭代的过程。
最后感悟一下：所有的设计一定要根据公司和当前项目状况，你的设计很可能非常完美，但是不一定符合公司当前现状。
