【无标题】

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

优点：

1. 业务系统无需集成sdk,跟消息中心完全解耦；
2. 无需关注后续sdk升级等问题；
3. 消息中心不可用时，不影响业务系统正常消息发送；

缺点：

1. 使用成本高，新业务集成无法知道消息体包装是否正确，中间的调试排查成本高；
2. 业务系统需要引入mq等配置信息和组件，增加了业务系统的复杂度；
3. 不利于后期对mq的升级改造；

3.4.2 有sdk

优点：

1. 集成成本低，只要按照sdk接口封装消息调用即可，便于新手集成以及调试；
2. 业务系统无需关注消息处理方式，不需要引入mq组件；
3. 消息中心统一选择mq组件，方便后期升级改造；

缺点：

1. 业务方需要集成skd，跟消息中心耦合在一起；
2. 业务系统需要维护sdk的版本；
3. 消息中心服务不可用时，消息无法正常发送，造成消息丢失；

3.4.3 有mq

优点：

1. 处理延迟消息时无需借助其他方案，比如定时器或者轮询；
2. 削峰，有效保证消息中心能够始终稳定处理消息；
3. 有效保证处理的顺序性；

缺点：

1. 引入mq后，增加了复杂度；
2. 需要保证mq的可用性；

3.4.4 无mq

优点：

1. 降低了系统的复杂度；

缺点：

1. 需要保证消息中心的并发、高可用等各种复杂场景；

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的正常使用，所以说是一个迭代的过程。

最后感悟一下：所有的设计一定要根据公司和当前项目状况，你的设计很可能非常完美，但是不一定符合公司当前现状。