解决方案
- 1、问题
- 2、设计
- 3、流程
看了大部分的消息中心解决方案，发现大家的中心思想都大差不差，区别基本都是在符合自身业务场景的做了一些定制化处理。本文为我对消息中心基本骨架的知识梳理，亦在帮助大家对消息中心设计有一个基本的理解。
1、问题
业务上可能会遇到的问题：
- 消息不支持配置化
- 消息不支持多语言
- 消息掌握能力（查看率、点击率、转化率等）
技术可能上遇到问题：
- 发送消息接口不统一（配置化后台、三方中间件、硬编码消息）
- 发送消息需要指定的参数过多
- 没有进行对外部接口的限流处理
- 消息数据管理分析（失败率、延迟率、一键撤回）
2、设计
可将消息中心抽象为三部分：
发送消息渠道部分：
- 消息渠道：针对不同渠道发送的消息，对渠道进行配置，如短信、邮件、钉钉消息、企微消息
发送消息记录部分：
- 消息场景：维护消息的场景类型，即对消息绑定一个场景，场景编码全局唯一，调用方指定场景编码用于定位具体消息
- 消息任务：消息中心接收到的上游传递的参数记录。由于一个消息场景可以被
- 消息记录：经过一系列处理后真实消息的发送记录，根据业务场景可扩展
发送消息模板配置部分：
- 消息基础模板：可用于处理公共样式，简化消息模板配置
- 消息模板：配置待发送消息的消息模板，参数值以占位符形式提供，消息模板在配置时需要绑定消息场景、以及消息渠道。
注意，由于一个消息场景可以被多个消息模板配置，所以上面提到的消息任务和消息记录不是一对一的
3、流程
上游指定消息场景中的消息编码和用户调用接口。消息中心接收到消息后，根据请求中的场景编码查询出所有配置的消息模板。每一个消息模板对应一条待发送得消息，在每一条要发送的消息中，首先完成对当前场景的规则的校验，校验通过后获取消息模板配置的渠道，发送具体的消息给对应得用户。
整体流程：
