360秒收问答采集伪原创程序( 此文逻辑梳理，内容讨论展开多基于B端企业内部产品的消息场景)

　　360秒收问答采集伪原创程序(

此文逻辑梳理，内容讨论展开多基于B端企业内部产品的消息场景)

　　本文是我担任产品经理以来对B端企业内部系统消息中心相关功能设计的一些思考。

　　一、位置、来源和作用

　　消息中心作为系统信息的分发中心，是系统与用户对话的基础。通过该配送中心，系统可以与用户交流包括但不限于以下信息：

　　特别是对于 IM 产品来说，消息更多是用户之间的会话信息，这里不做讨论。

　　不同的系统，由于其产品定位不同，其消息中心的数据源和功能不一致。一般来说，系统中的信息来源一般可以分为两类，一类是站内消息，一类是站外消息。

　　例如，某公司有HRBP组工作台系统，用于处理HRBP工作事务，其消息中心定位为HRBP获取相关工作事务通知和提醒的信息分发中心。因此，消息中心的消息源不仅是工作台本身，还支持外部系统消息访问，如招聘系统访问招聘及入职相关消息，360测评系统访问测评提醒相关消息等。用户可以通过该系统获取所有工作相关信息，并有针对性地处理消息，而不是登录其他40+人力资源相关系统获取信息。

　　因此，在进行消息中心的设计之前，一定要明确这个功能的定位和数据范围，也就是理清策略层和范围层的内容，才能更好的完善功能逻辑并确定需求。

　　二、消息流逻辑

　　无论是站内消息还是站外消息，消息数据进入消息中心后，都会通过其分发机制触发给相关用户，用户可以在前台的消息框中查看具体的消息内容——终端系统；如果涉及到转发外部系统提醒，如邮件中心或短信中心等，消息中心会向相应系统发起请求，并触发短信或邮件给用户。请参见下面的时序图：

　　我们可以看到，上面的时序图涉及到消息源、消息中心、消息框和外部通知系统。

　　当消息源请求消息通知时，它会向消息中心发送请求。请求中一般收录以下信息：源ID、请求时间、收件人ID、消息内容（标题+正文）、提醒方式等。消息中心可以理解为包括待发送池的两个数据表和发送池：

　　消息源信息会先进入待发送队列，形成消息队列，遵循先进先出的规则。消息中心会根据每条消息中携带的接收者ID分发消息，即将消息发送到对应用户的消息箱；同时根据提醒方式判断是否调用外部通知系统激活其他提醒方式。外部通知系统一般都有固定的消息模板和提醒逻辑。消息中心需要将提醒对象、应用模板ID和对应的模板参数同步到外部通知系统，外部通知系统判断并触发消息模板进行通知。

　　消息进入消息框，用户可以查看。此时，消息可以根据状态分为两类，即未读消息和已读消息。用户将关注未读消息，因此新的未读消息将首先呈现给用户。两种消息之间的转换也很简单。用户点击打开阅读；反向操作（即读变为未读）取决于具体的系统定位和用户需求。一般不设置反向操作。

　　至此，消息流逻辑基本梳理完毕。尤其是消息中心在设计中尽量不要融入复杂的逻辑，如定时发送、重复发送等，尽量保持逻辑简单，以支持大量消息分发，并保持其包容性。系统的底层机制；等逻辑应归入业务层逻辑，由业务方决定。

　　比如某少儿艺术在线教育公司内部CRM客户管理系统，其业务中有很多重复提醒和定时提醒逻辑，比如每周重复提醒销售人员某项销售任务没有完成二、星期四 提醒销售人员准备晚上的后续体验课，等等。这些逻辑都设置在业务层，业务层决定是否需要触发提醒。如有必要，向消息中心发送请求，并将相关参数传入消息队列进行排队传输。这样可以保证消息中心的简单高效运行，不会因为复杂的逻辑（如不兼容多次重传逻辑等）而出现不必要的消息流问题；

　　三、总结

　　消息中心是B端产品系统的基本功能。一个包容性强、设计合理的消息中心，可以更好地支持系统与用户的对话，传达我们想告诉用户的信息。在消息中心的设计之初，需要在规范数据范围之前确认系统定位和功能定位，从而实现产品的功能价值，满足业务需求。消息流逻辑也需要尽可能的梳理清楚，使其成为系统的基础服务，不能与业务逻辑强融合，保证良好的包容性，避免返工。

　　以上是个人工作过程中的一些经验总结和思考。仍有不足之处，正在努力中。

　　本文由@qunzi原创 发表 每个人都是产品经理，未经允许禁止转载

　　题图来自Unsplash，基于CC0协议