客户端|如何从0-1重构建消息系统：服务端量子|大数据|量子技术|量子计

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

文章插图
在庞大的后台系统中，怎么搭建消息系统的服务端，本文将结合上一篇《如何从0-1重构建消息系统：客户端》简单整理此次重建的流程及功能设计，希望对大家有所帮助。
在设计和搭建服务端产品时，与客户端产品来说是具有一定的差异性，首先产品在目标用户上有明确的区分，客户端主要是面对普通用户，而服务端主要是公司内部人员使用；产品的功能设计上，客户端的交互设计和视觉体验相对于要求比较高，必须满足品牌传播等很多要求，而客户端要求功能流程清晰，交互简单明确，保障前端业务正常开展，数据流程闭环等要求。
一、重构背景此次主要消息后台的重构，主要需要对APP的应用级的消息渠道：push推送、站内信的重构进行业务支撑，明确优化方向后，我们通业务侧的调研得出我们要重构的目标：

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

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

消息类型管理；
消息模版管理；
系统触发管理；
手动推送管理。

文章插图
设计具体方案前，我们先来分析一下消息系统服务端的各模块的功能。
1. 消息类型管理客户端进行重构的重要原因之一，由于业务的增加，造成消息类型不明确，消息等级错乱，所以我们首先对于消息中心进行了消息类型的划分，并采用了消息分类合并方式；所以在设计后台功能的时候，我们设计了消息类型管理模块了，主要作用：

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

如策略部同事需要新增一个新业务，给用户提供市场上宏观经济信息，则需要添加二级消息「市场解读」，如果后台没有可配置的后台，则需要前端或者客户端技术在前端编写代码，进行发版解决。
2. 消息模版管理大家可以理解为一个预编的消息池，里面保存了系统触发消息模版和手动推送消息模版，主要作用：

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

需要注意系统触发消息模版如果已经在使用，则不可以随意编辑，以免造成消息发送事故。
3. 系统触发管理先解释一下此系统中什么叫做系统触发消息功能，将消息发送的逻辑写在业务流程逻辑代码中，当满足条件时，触发消息发送功能。