后台系统是一个庞大的功能体系，及时的了解每个功能的使用状况，保障业务正常进行，是每个系统的重点。通常系统内会开发大量的监控功能(可视化的报表和非可视化的报表)来对这些业务进行监控，同时通知相应的负责人以及时了解业务和服务器状况。
常见的一些监控功能，如账号异常(账号异地登录、账号多次密码输入错误)、运营通知(活动上架、活动下架)、订单异常（订单堆积、派单堆积）、服务器异常（服务器宕机、CPU过载）、脚本异常（脚本卡死、进程过多）等等。
今天带大家来设计一个系统消息通知模块，通过简单的设置，完成个性化的消息发送，并且减轻后期代码的维护工作。
首先我们来看看常见消息发送功能是如何实现的以及它们的优缺点。
01、实现方式
1.直接触发
直接触发是将消息发送的逻辑和具体的业务代码逻辑写在一起，当满足条件时，直接触发消息发送功能。
- 优点：开发简单，如果功能封装好后，代码粘过来，十分钟功能基本就能完成；消息发送比较及时，消息发送逻辑和业务逻辑在一起，满足条件就会立即触发。
- 缺点：后期如果需要添加、编辑或删除接收人信息，就需要修改代码，维护起来比较麻烦。熟悉代码的人可能几分钟就搞定了，新人估计就得看半天代码了。
我参与过多个系统的开发，发现这么干的人还是挺多的。总结一下应该有以下几个原因：
- 写起来简单，因为发送逻辑一般都是封装好的，只需要粘代码，修改一下发送参数就完事
- 后台业务系统比较多，使用的编程语言比较多，如果各语言之间相互调用，需要对开发环境进行配置，维护成本太大
- 消息通知通常属于系统基础功能，产品经理基本上不会去关注，也就不会去统一规划这个功能，研发就自己随意发挥了
2、消息池
通过将所有消息先收集到一个消息池(如Mysql、Redis、Kafka等)中，然后再统一通过系统调度将消息发送给接收人。
- 优点：功能模块化，可以做到统一管理，代码的调用可以更简洁，后期维护成本可以降到最低。
- 缺点：消息会有延迟，消息池它是一个异步发送方式，消息的生产和发送是两个相互独立的过程；需要开发配置内容页面，开发量稍微大一点，但是后期能减轻更多的维护成本，我认为是非常值得的。
02、消息池模型
系统规划的目的就是让功能结构清晰，后期维护更轻松，所以上面第一种的实现方式就不讲了，主要讨论一下消息池功能是如何实现的。先来看一下消息池功能的模型图：
上面的模型主要分四层：
- 消息来源: 消息来源从开发角度来说，也称为消息生产者，它主要是指消息的生成方式和位置。在庞大的后台系统中，技术架构会划分出多个业务模块，各自的的业务模块都由不同的开发人员维护，不同的业务组使用的语言也各不相同，所以在完成相同功能时，书写方式也是各不相同，这个是没有办法统一的。
- 消息池: 主要作用是存储要发送内容信息，如消息内容，发送时间等。市面上常见的软件有Mysql、Redis、Kafka、RabbitMQ等，所以对消息数据的存储我们是可以做到统一的。
- 消息分发：主要作用是获取待发送的消息列表，并根据已设置的接收人信息，找到具体的接收人并发送消息。技术上通常会启动相应的任务程序持续的监控消息池，当消息池中有需要发送的数据，就执行相应业务逻辑。
- 接收人: 具体的消息接收人，接收人的接收方式有手机、邮箱或站内信。
03、字段整理
通过上面的分析，整理消息设置中所涉及的字段，如下：
- 消息名称: 明确说明消息内容。
- 唯一标识符: 系统内部相互调用唯一标示。
- 消息类型: 对消息内容进行归类。账号异常、服务器警告、数据库异常、运营通知、订单异常、脚本异常等。
- 接收方式: 接收消息的方式，可同时指定多种类型。如站内信、手机短信、邮箱等。
- 消息接受人: 指定接收消息的人，可同时指定多个接收人。
- 消息内容：列出具体的消息内容。
- 发送时间: 设置消息的发送时间。
04、原型设计
消息池功能中，消息生成功能是由代码在内部实现的逻辑，消息接受人信息则是在后台页面中维护的，原型页面如下：
消息设置列表
消息表单设置页
接收人列表
05、使用方法
功能我们设计好了。在业务中如何使用，我简单说一下：
1.需要各业务平台封装消息池调用功能,并开放一个接口，用来创建具体消息内容,如下：
2.在需要发送消息的业务里，调用上面的消息创建接口，如：
3.消息模块启动任务(如crontab、阻塞监听)监控消息池，如果有待发送消息，获取并组织消息内容，完成消息发送。
其中1、2两步需要在各自业务平台完成，第1步封装成公共功能，只用开发一次，第2步根据业务需要自行调用，就一行代码，是不是很简洁。剩余所有的功能都集中在消息模块，维护起来就比较方便了。
以上就是系统消息模块的设计，小伙伴有没有获得这个小技能，欢迎下方留言交流！
