通知系统是一个成熟的 web 网站或者 app 最基本的功能，比如微博、知乎、掘金等。当然今天本文要讨论的不是这种大网站、大流量的通知系统，而是一般用户量的网站或者应用。
通知系统的组成
一个通知系统主要由：通知来源、通知控制、通知方式、通知模板和通知的目标五个部分组成。 后面详细介绍各个组成的作用。组成结构如下图所示：
通知来源
通知来源是指触发本次通知事件的源头，一般包括以下三种情况：
- 用户事件触发：当其他用户对某个对象执行了评论、@、点赞、留言等动作，都需要对对象拥有者进行通知。这是最常见的需要通知的场景。
- 满足系统的规则后自动触发：比如被系统封号、等级提升、获得勋章时，理论上都应该对用户进行通知。
- 管理员触发：管理员主动向全网或者某个用户发送通知，比如发送公告等。
通知控制
通知控制用来进行权限控制、黑白名单过滤、用户接收消息频率控制、内容审查等。总之控制和过滤相关的都放在这里。
通知模板
通知模板用来与数据模型结合并最终展示给用户，类似 MVC 模式中的 V，可以是纯文本也可以是 Velocity 之类的模板。引入通知模板主要是为了满足以下三点：
- 不同通知方式通知的展示方式可以不同；
- 通知的展示与通知的模型数据分离；
- 通知模板可配。
通知方式
常见的有站内信、邮件、短信、工作通知(钉钉、企业微信)等。其中像邮件、短信和工作通知都是基于第三方应用的，用的时候顶多在他们提供的接口上做一层封装就可以了，所以没什么可以讲的。而站内信往往则需要网站或者应用自己设计和开发，所以很多网上介绍通知系统都只是介绍站内信的设计。
通知系统的分层
本文设计的通知系统流程图如下，主要分为业务层、数据模型层、控制层、分发层、视图层和发送层。分层可以降低各个模块之间的耦合，每一层只做自己该做的事。
业务层
该层与业务相关，属于通知系统中的通知来源部分。是调用通知系统服务的调用方，放在这里为了后面讲解业务与通知系统的解耦。
数据模型层
相信很多写 web 后台的程序员对 MVC 模式很熟悉，这一层相当于 MVC 模式中的 M 层，主要负责收集模型数据的。该层理论上划分为通知系统的通知来源。该层的数据模型与上层业务紧密关联，不同的业务场景需要不同的通知数据。
控制/过滤层
即通知控制，用来进行权限控制、黑白名单过滤、用户接收消息频率控制、内容审查等。
分发层
不同的业务往往需要不同的方式发送通知消息，比如事件通知要进行站内信通知、而被封号往往会选择邮件或者短信通知。消息到达分发层后，根据业务的不同选择不同的发送策略。如果需要将发送的消息记录进行存储也可以放在这层。
视图层
本层与数据模型层关系很大，数据到这一层后会与模板结合组成要发送的内容。
发送层
主要是调用短信、邮件、工作通知和站内信等接口将消息发送出去。我们将在第三部分讲解该层中的站内信设计。
以上分层建议采用框架的方式将所有流程编排好，每层都采用接口或者抽象类的方式调用。每层都有一些基类和固定接口，一旦有新的业务来只需要继承这些基类并实现相应接口就可以了。
结尾
本文通知系统设计就讲到这里，虽然简单但也是经验之谈吧。笔者在设计这块的时候也是慢慢演化过来的。一开始业务少、功能简单，直接将所有代码垒在一起。后期增加功能改动非常之大，几乎等于重构。采用这种设计后，如果需要新增业务，只需要新增一些类，流程就可以自动 run 起来。
