阅读 1302

网站消息通知设计

通知系统是一个成熟的 web 网站或者 app 最基本的功能,比如微博、知乎、掘金等。当然今天本文要讨论的不是这种大网站、大流量的通知系统,而是一般用户量的网站或者应用。

通知系统的组成

一个通知系统主要由:通知来源、通知控制、通知方式、通知模板和通知的目标五个部分组成。 后面详细介绍各个组成的作用。组成结构如下图所示:

通知来源

通知来源是指触发本次通知事件的源头,一般包括以下三种情况:

  1. 用户事件触发:当其他用户对某个对象执行了评论、@、点赞、留言等动作,都需要对对象拥有者进行通知。这是最常见的需要通知的场景。
  2. 满足系统的规则后自动触发:比如被系统封号、等级提升、获得勋章时,理论上都应该对用户进行通知。
  3. 管理员触发:管理员主动向全网或者某个用户发送通知,比如发送公告等。

通知控制

通知控制用来进行权限控制、黑白名单过滤、用户接收消息频率控制、内容审查等。总之控制和过滤相关的都放在这里。

通知模板

通知模板用来与数据模型结合并最终展示给用户,类似 MVC 模式中的 V,可以是纯文本也可以是 Velocity 之类的模板。引入通知模板主要是为了满足以下三点:

  1. 不同通知方式通知的展示方式可以不同;
  2. 通知的展示与通知的模型数据分离;
  3. 通知模板可配。

通知方式

常见的有站内信、邮件、短信、工作通知(钉钉、企业微信)等。其中像邮件、短信和工作通知都是基于第三方应用的,用的时候顶多在他们提供的接口上做一层封装就可以了,所以没什么可以讲的。而站内信往往则需要网站或者应用自己设计和开发,所以很多网上介绍通知系统都只是介绍站内信的设计。

通知系统的分层

本文设计的通知系统流程图如下,主要分为业务层、数据模型层、控制层、分发层、视图层和发送层。分层可以降低各个模块之间的耦合,每一层只做自己该做的事。

业务层

该层与业务相关,属于通知系统中的通知来源部分。是调用通知系统服务的调用方,放在这里为了后面讲解业务与通知系统的解耦。

数据模型层

相信很多写 web 后台的程序员对 MVC 模式很熟悉,这一层相当于 MVC 模式中的 M 层,主要负责收集模型数据的。该层理论上划分为通知系统的通知来源。该层的数据模型与上层业务紧密关联,不同的业务场景需要不同的通知数据。

控制/过滤层

即通知控制,用来进行权限控制、黑白名单过滤、用户接收消息频率控制、内容审查等。

分发层

不同的业务往往需要不同的方式发送通知消息,比如事件通知要进行站内信通知、而被封号往往会选择邮件或者短信通知。消息到达分发层后,根据业务的不同选择不同的发送策略。如果需要将发送的消息记录进行存储也可以放在这层。

视图层

本层与数据模型层关系很大,数据到这一层后会与模板结合组成要发送的内容。

发送层

主要是调用短信、邮件、工作通知和站内信等接口将消息发送出去。我们将在第三部分讲解该层中的站内信设计。

以上分层建议采用框架的方式将所有流程编排好,每层都采用接口或者抽象类的方式调用。每层都有一些基类和固定接口,一旦有新的业务来只需要继承这些基类并实现相应接口就可以了。

结尾

本文通知系统设计就讲到这里,虽然简单但也是经验之谈吧。笔者在设计这块的时候也是慢慢演化过来的。一开始业务少、功能简单,直接将所有代码垒在一起。后期增加功能改动非常之大,几乎等于重构。采用这种设计后,如果需要新增业务,只需要新增一些类,流程就可以自动 run 起来。

关注下面的标签,发现更多相似文章
评论