编辑导读：消息中心作为系统信息的集散地，是系统与用户之间对话的基础。本文作者梳理了B端产品的消息中心数据流逻辑，希望对你有帮助。

此文是本人从事产品经理工作以来，在设计B端企业内部系统消息中心相关功能时的一些思考，偏重数据流逻辑梳理，内容讨论展开多基于B端企业内部产品的消息场景。

一、定位、来源及作用

消息中心作为系统信息的集散地，是系统与用户之间对话的基础。通过这个集散地，系统可以向用户传达包括且不仅局限于以下信息：

• 企业文化
• 产品价值观
• 待办或事务提醒
• ……

特别地，针对IM类产品，消息更多是用户与用户之间的对话信息，此类不在这里讨论。

不同的系统，因其产品定位不同，其消息中心数据来源和作用也不相一致。一般系统的消息来源在大方向上可以分为2类，一类是站内消息，一类是站外消息。

• 站内消息：指系统本身触发的消息内容，涵盖系统公告、待办提醒等；用于向用户传达其在当前系统需要执行或知悉的信息，用户行为一般限制在当前系统内，不与外界系统产生信息交流或动作交互。当然，也有一些消息来源是站内，但用户需要在外界系统完成信息处理的，不过相对比较少。
• 站外消息：指外部系统通过当前系统分发机制给用户同步的提醒信息；用户在收到此类消息，正常都可以通过当前系统链接到对应外部系统去完成信息处理动作，用户行为不局限于当前系统内，会频繁与外界系统产生信息交流或动作交互。

例如，某司针对HRBP群体有一个工作台系统，用于处理HRBP工作事务，其消息中心定位是作为HRBP获取与其相关的工作事务通知提醒的信息集散地。所以该消息中心的消息来源便不仅有工作台本身，同时支持外部系统消息接入，如招聘系统接入招聘入职相关消息、360评估系统接入评估提醒相关消息等。用户可以通过这个系统获知所有工作相关的信息，并有针对性地对消息进行处理，而不再需要登录其他40+个HR相关系统获取信息。

所以，在开展消息中心设计之前，我们一定是需要明确这个功能的定位和数据范围，也就是梳理清楚战略层和范围层的内容，在这之后才能更好地完善功能逻辑和甄别需求。

二、消息流逻辑

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

我们可以看到，上述时序图涉及消息来源、消息中心、消息盒子和外部通知系统。

• 消息来源：含站内消息和站外消息，可以是当前系统本身的提醒或公告，也可以是外部其他系统的提醒。
• 消息中心：当前系统的底层逻辑，用以消息分发、请求外部通知的集中处理模块。
• 消息盒子：当前系统的消息中心外在表现，用以与用户交互和信息交流的功能模块；用户可以在消息盒子中查阅所有与其相关的消息。
• 外部通知：部分需强提醒或对时效性要求高的消息，会通过一些外部系统辅助消息及时快速触达，使得用户没有登录当前系统也能获知消息。此类外部通知系统多指邮件服务中心、短信服务中心、企业微信、飞书、钉钉等。

消息来源请求消息通知时，会向消息中心发送请求，请求中一般包含这些信息：来源标识ID、请求时间、接收对象ID、消息内容（标题+正文）、提醒方式等。消息中心可以理解为包含待发送池、已发送池两大数据表：

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

消息进入消息盒子，则可被用户所查阅。此时可以根据状态将消息分为2类，即未读消息和已读消息。用户重点关注会放在未读消息上，所以优先给用户呈现新触达的未读信息。2类消息之间转换也很简单，用户点击打开即为已读；逆操作（即已读变为未读）则看具体系统定位和用户需要，一般不会设置逆操作。

至此，消息流逻辑就基本梳理完成。特别地，消息中心在设计时尽量不要融入复杂逻辑，如定时发送、重复发送等，应尽量保持逻辑简单以支持大量的消息分发和保持其作为系统底层机制的包容性；而定时发送、重复发送等逻辑应归类于业务层逻辑，应由业务侧决定。

例如，某个少儿美术在线教育公司内部CRM客户管理系统，其业务上有众多重复提醒和定时发送提醒的逻辑，如给销售人员重复提醒某个销售任务没有完成，每周二、四晚定时提醒销售人员准备跟进体验课，等等。这些逻辑均是设置在业务层，由业务层判断是否需要触发提醒，如需要则向消息中心发出请求，传入相关参数进入消息队列排队发送。这样能保证消息中心简单而高效运转，不会因为复杂逻辑产生不必要的消息流问题（如无法兼容多种重发逻辑等）；也把运维的重心都偏移在业务层，使得不同业务消息互不影响。

三、总结

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

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

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

题图来自Unsplash，基于 CC0 协议