直接触发是将消息发送的逻辑和具体的业务代码逻辑写在一起

后台系统是一个庞大的功能体系，及时的了解每个功能的使用状况，保障业务正常进行是每个系统的重点。通常系统内会开发大量的监控功能(可视化的报表和非可视化的报表)来对这些业务进行监控，同时通知相应的负责人以及时了解业务和服务器状况。

常见的一些监控功能，如账号异常(账号异地登录、账号多次密码输入错误)、运营通知(活动上架、活动下架)、订单异常（订单堆积、派单堆积）、服务器异常（服务器宕机、CPU过载）、脚本异常（脚本卡死、进程过多）等等。

今天带大家来设计一个系统消息通知模块，通过简单的设置，完成个性化的消息发送，并且减轻后期代码的维护工作。首先我们来看看常见消息发送功能是如何实现的以及它们的优缺点。

01 实现方式

1.1 直接触发

直接触发是将消息发送的逻辑和具体的业务代码逻辑写在一起，当满足条件时，触发消息发送功能。

• 优点：开发简单，如果功能封装好后，代码粘过来，十分钟功能基本就能完成；消息发送比较及时，消息发送逻辑和业务逻辑在一起，满足条件就会立即触发。
• 缺点：后期如果需要添加、编辑或删除接收人信息，就需要修改代码，维护起来比较麻烦。熟悉代码的人可能几分钟就搞定了，新人估计就得看半天代码了。

我参与过多个系统的开发，发现这么干的人还是挺多的。总结一下应该有以下几个原因：

1. 写起来简单，因为发送逻辑一般都是封装好的，只需要粘代码，修改一下发送参数就完事
2. 一般后台业务系统比较多，使用的编程语言比较多，各语言之间相互调用需要配置基础服务，成本太大
3. 消息通知通常属于系统基础功能，产品经理基本上不会去关注，也就不会去统一规划这个功能，技术就自己随意发挥了^_^

1.2 消息池

通过将所有消息先收集到一个消息池(如Mysql、Redis、Kafka等)中，然后再统一通过系统调度将消息发送给接收人。

• 优点：功能模块化，可以做到统一管理，代码的调用可以更简洁，后期维护成本可以降到最低。
• 缺点：消息会有延迟，消息池它是一个异步发送方式，消息的生产和发送是两个相互独立的过程；需要开发配置内容页面，开发量稍微大一点，但是后期能减轻更多的维护成本，我认为是非常值得的。

02 消息池模型

系统规划的目的就是让功能结构清晰，后期维护更轻松，所以上面第一种的实现方式就不讲了，主要讨论一下消息池功能是如何实现的。先来看一下消息池功能的模型图：

上面的模型主要分四层：

• 消息来源: 消息来源从开发角度来说，也称为消息生产者，它主要是指消息的生成方式和位置。在庞大的后台系统中，技术架构会划分出多个业务模块，各自的的业务模块都由不同的开发人员维护，不同的业务组使用的语言也各不相同，所以在完成相同功能时，书写方式也是各不相同，这个是没有办法统一的。
• 消息池: 主要作用是存储要发送内容信息，如消息内容，发送时间等。市面上常见的软件有Mysql、Redis、Kafka、RabbitMQ等。所以对消息数据的存储我们是可以做到统一的。
• 消息分发：主要作用是获取待发送的消息列表，并根据已设置的接收人信息，找到具体的接收人并发送消息。技术上通常会启动相应的任务程序持续的监控消息池，当消息池中有需要发送的数据，就执行相应业务逻辑。
• 接收人: 具体的消息接收人，接收人的接收方式有手机、邮箱或站内信。

03 功能分析

设计具体功能前先来分析一下消息通知都涉及哪些功能。

3.1 消息类型

在系统运行过程中，会涉及到许多业务功能的监控，如订单业务中，订单支付是否有未成功、订单分配是否有堆积的情况、派单功能是有堆积情况；再如运营业务中，商品运营活动已经设置上线时间，到点上线后需要及时通知运营人员上线是否成功，避免影响活动效果。

为了能够及时让维护人员了解问题，通常都对消息进行归类，如账号异常、服务器警告、数据库异常、运营通知、订单异常、脚本异常等。

3.2 紧急程度

系统中对于不同类型的消息，根据重要程度会划分出不同的级别。如系统每日报表任务，由于数据量比较大，要求并不是很高，延迟一天通常都可以接受， 所以都是晚上3 ~ 5点之间由脚本自动运行导出后放在服务器上，第二天早上8点发系统通知，再由需求人自行导出就可以了，这类消息属于一般程度；

但是对于服务器宕机这种情况，就必须立即通知负责人进行处理，以免给企业带来更多的损失，这类消息属于紧急程度。

3.3 接收方式

消息接收方式通常就三种：站内信、手机短信、邮箱。不同的接收方式作用有所不同：

• 站内信：站内信是系统内部功能，研发人员可以随意设置，消息内容可以写的比较详细；但是时效性比较差，取决于接收人什么时候登陆系统。
• 邮箱：消息内容可以写的比较详细，时效性也比较差，但是邮件确实必发的功能，因为可以作为尽职调查的凭证。
• 手机短信：短信功能一般都由第三放平台提供，所以发送内容长度有所限制，内容需要简洁，最大特点就是及时。

3.4 发送时间

对于系统中的消息，比较紧急的如订单支付异常、数据库宕机异常它们需要及时发送，还有一些不重要的，比如上面说的各种任务报表，晚上3、4点生成好后，系统也不会发送消息，一般会设置好时间，等到早上8、9点才会开始发送通知，还有一些任务需要每个几小时就得发送一次。

3.5 唯一标示

唯一标示主要用于代码开发。在测试环境和正式生产环境由于测试导致数据库ID不一致，所以开发时没有办法通过对应的ID调用消息，就需要设计一个唯一标识符供开发人员使用，一般标示符命名根据具体的业务点来命名。

3.6 消息接收人

由于员工岗位的变动，后台需要设置相应的接收人维护界面，可以自由的添加、删除多个消息接收人。

04 原型设计

系统消息基本就上面这些功能，有需要的可以自己再扩展。下面给出部分原型设计图：

功能整理：