分层架构 IM 系统之系统消息功能逻辑设计与实现

IM 消息中除了点对点的私信消息和群消息外，还有由 “系统” 发给用户的 “系统消息”。

系统消息通常包括两类：一类是由系统单独发给一个用户的私信系统消息，比如用户下单或支付后，系统会发消息通知到用户；一类是由系统群发给很多用户的广播系统消息，比如通知本周所有在平台下单的用户来领取奖品之类的。

广播系统消息，因为需要短时群发大量消息，会对系统瞬时产生很高的负载，这是 IM 系统设计的关键；根据广播消息的量级不同，广播系统消息的落地方案也会有所不同。

今天我们基于 IM 系统的分层架构，分析私信系统消息和广播系统消息的处理逻辑。

一、私信系统消息

私信系统消息处理流程与点对点的私信处理流程类似，但更简单许多，见下图。

IM 系统消息对实时性和可靠性的要求不高，而且系统消息经常需要进行业务迭代，所以这一部分业务需要放在 Extlogic 服务中进行处理。

• 当业务平台需要向用户推送私信系统消息时，就向 MQ 发送一条消息，比如，当用户被关注了、用户支付了等事件被触发；“平台业务” 是整个的业务系统，比如，电商系统、外卖系统等；IM 可以被看做是整个业务系统能链接到终端用户的通道工具，MQ 对平台业务系统和 IM 系统进行了解耦；

• Extlogic 作为下游服务，对 MQ 进行消费；Extlogic 拿到一条消息后，首先进行落库处理，即通过调用数据访问层 Das 写 “云系统消息库” 和 “联系人库” ；这里需要注意，在点对点的私信消息处理中，写消息库和联系人库是分别需要写两条，这里只写一条即可，毕竟 “系统” 不是 用户，不需要站在 “系统” 的维度进行存储；

• 系统消息落库成功以后，Extlogic 访问路由层 Router ，获取用户在线数据，如果用户离线，则结束