编辑导语：当你需要对消息系统进行重构时，如何做好服务端的搭建设计？首先，你需要明确有哪些模块，区别于客户端，服务端的面向对象、功能设计等层面也有所不同。本篇文章里，作者梳理了从0到1重构消息系统服务端的流程，一起来看一下。

在庞大的后台系统中，怎么搭建消息系统的服务端，本文将结合上一篇《如何从0-1重构建消息系统：客户端》简单整理此次重建的流程及功能设计，希望对大家有所帮助。

在设计和搭建服务端产品时，与客户端产品来说是具有一定的差异性，首先产品在目标用户上有明确的区分，客户端主要是面对普通用户，而服务端主要是公司内部人员使用；产品的功能设计上，客户端的交互设计和视觉体验相对于要求比较高，必须满足品牌传播等很多要求，而客户端要求功能流程清晰，交互简单明确，保障前端业务正常开展，数据流程闭环等要求。

一、重构背景

此次主要消息后台的重构，主要需要对APP的应用级的消息渠道：push推送、站内信的重构进行业务支撑，明确优化方向后，我们通业务侧的调研得出我们要重构的目标：

1. 消息管理-相关权限人可在消息系统后台创建系统自动触发消息和手动推送消息，并且这些消息可以推送给APP客户端、公众号的渠道用户；
2. 整合现有公司业务的推送消息类型、系统消息推送机制、消息模版（系统消息模版和手推消息模版）、消息推送，并且消息管理相关权限人可以进行管理操作；
3. 可以满足各种场景下的消息推送需求。

二、消息系统规划

消息系统的重构后，服务端主要由四大模块构成：

1. 消息类型管理；
2. 消息模版管理；
3. 系统触发管理；
4. 手动推送管理。

设计具体方案前，我们先来分析一下消息系统服务端的各模块的功能。

1. 消息类型管理

客户端进行重构的重要原因之一，由于业务的增加，造成消息类型不明确，消息等级错乱，所以我们首先对于消息中心进行了消息类型的划分，并采用了消息分类合并方式；所以在设计后台功能的时候，我们设计了消息类型管理模块了，主要作用：

• 为客户端的消息类型字段提供数据支撑；
• 随着业务的扩展和合并，运营可以在后台扩充消息类型，并且可以实现前后端类型的分离，方便管理；
• 可以很好地解决业务的扩展和合并的情况，导致前端技术需要重新对前端消息类型代码再次编写。

如策略部同事需要新增一个新业务，给用户提供市场上宏观经济信息，则需要添加二级消息「市场解读」，如果后台没有可配置的后台，则需要前端或者客户端技术在前端编写代码，进行发版解决。

2. 消息模版管理

大家可以理解为一个预编的消息池，里面保存了系统触发消息模版和手动推送消息模版，主要作用：

• 完整地记录了系统触发的消息的类型、内容等，业务同学可以在此模块中找到在系统中运行的任何一条系统触发消息，不需要技术同学再去扒代码找一条系统消息；
• 方便运营的同学在编写手推或者自动触发消息时，省去寻找相似类似业务的消息模版，大大节省了业务方同学在编写消息时的效率。

需要注意系统触发消息模版如果已经在使用，则不可以随意编辑，以免造成消息发送事故。

3. 系统触发管理

先解释一下此系统中什么叫做系统触发消息功能，将消息发送的逻辑写在业务流程逻辑代码中，当满足条件时，触发消息发送功能。

此模块主要进行系统触发的关键机制的查看，及时地记录每个部门或业务消息触发机制，可以避免随着部门和人员的业务更迭，造成触发机制的信息无法自知的想象，方便每个部门对系统触发消息及消息渠道的查看、记录。

如运营部门新增了直播业务，我们需要对整个业务流程进行分析，需要系统自动触发的消息机制有哪些，并且推动哪种渠道，及推动的消息类型有哪些。

1）当用户点击已预约以后，则系统会自动发送给用户一条预约成功的「站内信」，则后台记录触发机制为「用户点击预约直播按钮后」，发送的消息类型「站内信」，消息名称为「预约成功」提醒。

2）当开播前15分钟，系统会自动给成功预约本场直播的用户发送直播开始的「站内信」、「Push消息」，则后台记录的触发机制为「直播开始前15分钟，给所有预约成功用户发送观看开播提醒」，消息名称为「开播提醒」。

这就是一个完整的触发消息机制的记录。

需要注意的是，因为系统触发机制都是由技术编写在后台代码中，所以我们新的业务需要增加系统自动触发机制的时候，需要同步后台技术，需要技术进行代码实现，才可以运行触发条件。

4. 手动推送管理

此模块为手动推送消息的主要功能模块，运营和各业务部门的同学可以在此模块完成消息内容的编写或选取，消息类型的选择、发送渠道的配置、发送时间的选择、消息接受人的选择等主要推送机制的设置。

三、原型规划

通过结合对客户端、服务端功能的分析，我们开始对消息系统服务端主要模块的功能进行产品方案设计，以下笔者会一一讲解主要的功能构成。

功能结构图

1. 消息类型管理设计

消息类型列表

字段及功能说明

消息类型：主要对系统中所有消息进行分类整理，如果业务类型层级比较复杂，则可以在某一个业务类型一级消息下，再设计二级分类；并且可以对消息类型进行编辑，如更改消息类型名称、增加或删除消息类型。

需要注意的是我们在更改消息类型名称后，需要对以往原消息类型的历史消息进行继承，对已经有历史消息的消息类型不能进行删除。

2. 消息模版管理设计

手动推送消息模版列表

字段及功能说明

此模块分为系统触发消息模版管理和手动推送消息模版管理，系统触发模版中含有代码中包含的参数，这个是系统触发模版和手动推送模版需要做成两个管理版块的原因。

以手动推送消息模版列表为主要列举对象：

• 消息标题：显示消息的主标题。
• 消息摘要：对于消息内容的概括，根据客户端和渠道内容的要求，后台做字符、样式、位置等限制。
• 消息内容：根据客户端的要求，后台做字符、样式、位置等限制，如果渠道内容类型比较多，则可以不显示。
• 消息类型：消息在客户端显示归属的消息类型。
• 渠道内容推送：显示此条消息包含的消息渠道内容。
• 编辑时间：显示最后编辑消息时间。
• 消息编辑人：显示最后编辑人姓名。

需要注意在操作系统触发消息模版的时候，如果此条系统触发模版消息已经和系统触发机制关联，则无法进行删除和编辑。

3. 系统触发管理设计

系统触发机制列表

字段及功能说明

• 系统触发机制：将消息发送的逻辑写在业务流程逻辑代码中，当满足条件时，触发消息发送，此时的消息发送逻辑我们称其为系统触发机制，此处把代码中的触发机制反显出来；
• 系统触发消息模版：系统消息触发机制对应的消息模版，消息机制可以更换消息模版。

在禁用消息机制的时候，需要提醒业务方是否取消关联的系统消息模版。

4. 手动推送管理

手动推送消息列表

字段及功能说明

• 消息标题、消息摘要、消息内容、消息类型、渠道内容类型和消息模版管理一致，此处省略；
• 推送用户群体：此消息推送的用户类型；
• 用户数：推送用户的数量；
• 推送渠道：消息推送的具体端口及渠道；
• 推送人：记录最后发送此消息的人员；
• 推送时间：消息发送的时间记录；
• 推送状态：分为未发送、已测试发送、已发送三种状态；当消息未发送时，需要对消息进行测试发送后，发送按钮才可以被激活进行正式发送；当消息测试发送后，则可以进行正式发送；当消息发送后，可以对消息进行引用，再次使用此条消息进行发送。

推送机制

在消息模版管理的时候，我们已经简述了消息的主体部分编辑关键信息，在手动推送消息时，我们还需要对主体消息配置推送机制：

• 推送渠道：设计时需要考虑业务所覆盖的所有渠道，在此系统中则是需要针对此条消息的所属渠道内容进行配置；
• 推送方式：实时推送，点击推送按钮则可以发送；定时推送，可以选择具体的日期和时间发送消息；
• 推送用户：全体用户；自定义，主要针对业务方做定制化开发或手动上传用户信息；
• 消息发送参数：针对系统发送能力进行合理优化分配发送的机制；
• 测试用户：业务方对于新消息的线上测试检查是不可缺少的环节，需要配置的测试用户可以在此设置。

四、写在最后的话

本文作为「如何从0-1重构建消息系统：客户端」的姊妹篇，简单记录笔者在规划消息系统服务端时的一个思路。

服务端除了需要支持现在运行的客户端功能数据展示和数据流转，还需要对未来客户端业务功能扩容做研判，这样才能更好地支持客户端的用户体验和数据流转，提高开发效率。

以上就是笔者0-1重构消息系统的全部记录，希望对观看此文的诸位有所帮助和借鉴，如有不同意见，欢迎下方留言交流！

本文由@大大大大大浪 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议