编辑导语：当你需要对消息系统进行重构时，如何做好服务端的搭建设计？首先，你需要明确有哪些模块，区别于客户端，服务端的面向对象、功能设计等层面也有所不同。本篇文章里，作者梳理了从0到1重构消息系统服务端的流程，一起来看一下。
在庞大的后台系统中，怎么搭建消息系统的服务端，本文将结合上一篇《如何从0-1重构建消息系统：客户端》简单整理此次重建的流程及功能设计，希望对大家有所帮助。
在设计和搭建服务端产品时，与客户端产品来说是具有一定的差异性，首先产品在目标用户上有明确的区分，客户端主要是面对普通用户，而服务端主要是公司内部人员使用；产品的功能设计上，客户端的交互设计和视觉体验相对于要求比较高，必须满足品牌传播等很多要求，而客户端要求功能流程清晰，交互简单明确，保障前端业务正常开展，数据流程闭环等要求。
一、重构背景
此次主要消息后台的重构，主要需要对APP的应用级的消息渠道：push推送、站内信的重构进行业务支撑，明确优化方向后，我们通业务侧的调研得出我们要重构的目标：
二、消息系统规划
消息系统的重构后，服务端主要由四大模块构成：
设计具体方案前，我们先来分析一下消息系统服务端的各模块的功能。
1. 消息类型管理
客户端进行重构的重要原因之一，由于业务的增加，造成消息类型不明确，消息等级错乱，所以我们首先对于消息中心进行了消息类型的划分，并采用了消息分类合并方式；所以在设计后台功能的时候，我们设计了消息类型管理模块了，主要作用：
如策略部同事需要新增一个新业务，给用户提供市场上宏观经济信息，则需要添加二级消息「市场解读」，如果后台没有可配置的后台，则需要前端或者客户端技术在前端编写代码，进行发版解决。
2. 消息模版管理
大家可以理解为一个预编的消息池，里面保存了系统触发消息模版和手动推送消息模版，主要作用：
需要注意系统触发消息模版如果已经在使用，则不可以随意编辑，以免造成消息发送事故。
3. 系统触发管理
先解释一下此系统中什么叫做系统触发消息功能，将消息发送的逻辑写在业务流程逻辑代码中，当满足条件时，触发消息发送功能。
此模块主要进行系统触发的关键机制的查看，及时地记录每个部门或业务消息触发机制，可以避免随着部门和人员的业务更迭，造成触发机制的信息无法自知的想象，方便每个部门对系统触发消息及消息渠道的查看、记录。
如运营部门新增了直播业务，我们需要对整个业务流程进行分析，需要系统自动触发的消息机制有哪些，并且推动哪种渠道，及推动的消息类型有哪些。
1）当用户点击已预约以后，则系统会自动发送给用户一条预约成功的「站内信」，则后台记录触发机制为「用户点击预约直播按钮后」，发送的消息类型「站内信」，消息名称为「预约成功」提醒。
2）当开播前15分钟，系统会自动给成功预约本场直播的用户发送直播开始的「站内信」、「Push消息」，则后台记录的触发机制为「直播开始前15分钟，给所有预约成功用户发送观看开播提醒」，消息名称为「开播提醒」。
这就是一个完整的触发消息机制的记录。
需要注意的是，因为系统触发机制都是由技术编写在后台代码中，所以我们新的业务需要增加系统自动触发机制的时候，需要同步后台技术，需要技术进行代码实现，才可以运行触发条件。
4. 手动推送管理
此模块为手动推送消息的主要功能模块，运营和各业务部门的同学可以在此模块完成消息内容的编写或选取，消息类型的选择、发送渠道的配置、发送时间的选择、消息接受人的选择等主要推送机制的设置。
三、原型规划
通过结合对客户端、服务端功能的分析，我们开始对消息系统服务端主要模块的功能进行产品方案设计，以下笔者会一一讲解主要的功能构成。
功能结构图
1. 消息类型管理设计
消息类型列表
字段及功能说明
消息类型：主要对系统中所有消息进行分类整理，如果业务类型层级比较复杂，则可以在某一个业务类型一级消息下，再设计二级分类；并且可以对消息类型进行编辑，如更改消息类型名称、增加或删除消息类型。
需要注意的是我们在更改消息类型名称后，需要对以往原消息类型的历史消息进行继承，对已经有历史消息的消息类型不能进行删除。
2. 消息模版管理设计
手动推送消息模版列表
字段及功能说明
此模块分为系统触发消息模版管理和手动推送消息模版管理，系统触发模版中含有代码中包含的参数，这个是系统触发模版和手动推送模版需要做成两个管理版块的原因。
以手动推送消息模版列表为主要列举对象：
需要注意在操作系统触发消息模版的时候，如果此条系统触发模版消息已经和系统触发机制关联，则无法进行删除和编辑。
3. 系统触发管理设计
系统触发机制列表
字段及功能说明
在禁用消息机制的时候，需要提醒业务方是否取消关联的系统消息模版。
4. 手动推送管理
手动推送消息列表
字段及功能说明
推送机制
在消息模版管理的时候，我们已经简述了消息的主体部分编辑关键信息，在手动推送消息时，我们还需要对主体消息配置推送机制：
四、写在最后的话
本文作为「如何从0-1重构建消息系统：客户端」的姊妹篇，简单记录笔者在规划消息系统服务端时的一个思路。
服务端除了需要支持现在运行的客户端功能数据展示和数据流转，还需要对未来客户端业务功能扩容做研判，这样才能更好地支持客户端的用户体验和数据流转，提高开发效率。
以上就是笔者0-1重构消息系统的全部记录，希望对观看此文的诸位有所帮助和借鉴，如有不同意见，欢迎下方留言交流！
本文由@大大大大大浪 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
