看了大部分的消息中心解决方案，发现大家的中心思想都大差不差，区别基本都是在符合自身业务场景的做了一些定制化处理。本文为我对消息中心基本骨架的知识梳理，亦在帮助大家对消息中心设计有一个基本的理解。

1、问题

业务上可能会遇到的问题：

1. 消息不支持配置化
2. 消息不支持多语言
3. 消息掌握能力（查看率、点击率、转化率等）

技术可能上遇到问题：

1. 发送消息接口不统一（配置化后台、三方中间件、硬编码消息）
2. 发送消息需要指定的参数过多
3. 没有进行对外部接口的限流处理
4. 消息数据管理分析（失败率、延迟率、一键撤回）

2、设计

可将消息中心抽象为三部分：

发送消息渠道部分：

1. 消息渠道：针对不同渠道发送的消息，对渠道进行配置，如短信、邮件、钉钉消息、企微消息

发送消息记录部分：

1. 消息场景：维护消息的场景类型，即对消息绑定一个场景，场景编码全局唯一，调用方指定场景编码用于定位具体消息
2. 消息任务：消息中心接收到的上游传递的参数记录。由于一个消息场景可以被
3. 消息记录：经过一系列处理后真实消息的发送记录，根据业务场景可扩展

发送消息模板配置部分：

1. 消息基础模板：可用于处理公共样式，简化消息模板配置
2. 消息模板：配置待发送消息的消息模板，参数值以占位符形式提供，消息模板在配置时需要绑定消息场景、以及消息渠道。

注意，由于一个消息场景可以被多个消息模板配置，所以上面提到的消息任务和消息记录不是一对一的

3、流程

上游指定消息场景中的消息编码和用户调用接口。消息中心接收到消息后，根据请求中的场景编码查询出所有配置的消息模板。每一个消息模板对应一条待发送得消息，在每一条要发送的消息中，首先完成对当前场景的规则的校验，校验通过后获取消息模板配置的渠道，发送具体的消息给对应得用户。

整体流程：