本文由微信技术团队分享，原题“十年前的微信消息收发架构长啥样？”，下文进行了排版和内容优化等。

1、引言

2023 年，微信及 WeChat 的 DAU（月活用户）达到 13.4 亿，微信已经是很多人工作、生活中不可或缺的一个环节。从 2011 年 1 月 21 日上线至今，微信已经走过了 13 个年头，其背后的技术基座与架构也发生了巨大的变化。这些变化背后，所折射的也正是中国互联网高速发展的黄金年代。

好的架构是迭代出来的，却也少不了良好的设计，本文将带大家回顾微信背后最初的也是最核心的IM消息收发技术架构，愿各位读者能从中获得启发。

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4636-1-1.html）

2、微信技术起步

微信诞生于 QQMail 团队，初始的整个微信后台架构都带着浓重的邮箱气息，消息收发架构作为微信最为核心的部分，同样是基于邮箱的存储转发机制演变而来。

微信定位为即时通讯IM软件，对消息的收发有2个基本的要求：

1）消息尽可能的实时送达；
2）不丢消息。

在邮箱的存储转发机制上做了改良后，微信的消息收发实现了以上2个基本要求。

3、消息发送架构

首先通过手机 A 给手机 B 发送一条微信消息来看消息发送的整体架构是怎样的（如下图所示）。

微信消息发送在整体架构上可以分为2个部分。

第一部分：手机A发送消息到服务器（上图中1、2、3部分）：

1）1 - 手机A发送发消息请求到接入层 ConnnectSvr；
2）2 - 接入层收到请求后，将请求转到逻辑层 SendSvr 进行处理；
3）3 - 逻辑层处理完各种逻辑（如反垃圾，黑名单等等）之后，将消息存入存储层 MsgStore。

第二部分：服务器发送通知到手机B（上图中4、5.1、5.2、6、7部分）：

1）4 - 逻辑层 SendSvr 将给手机 B 的新消息到达通知发送到通知处理服务器 PushSvr。

2）5.1 - PushSvr 查询手机 B 在接入层所在长连接的 ConnectSvr，并将通知发给该 ConnectSvr。

3）5.2 - PushSvr 发送一个 Push tips 给手机操作系统自建的第三方 Push 系统（如苹果的 APNsPush，微软的 WPPush，黑莓的 BBPush 等）。像苹果的 IOS 系统，在 APP 退出到后台10分钟后就会释放掉该 APP 所持有的所有资源（如 CPU，网络，内存等），导致之前建立的长连接通道也会一并断掉，此时通过5.1的方式进行通知是不可达的，所以还需要依赖与苹果自身的 apns 通道来达到实时通知的目的。

4）6 - 接入层 ConnnectSvr 通过手机 B 建立的长连接通道将新消息达到通知发送给手机 B。

5）7 - 第三方 Push 服务器通过自建的 Push 通过发送 Push tips 到手机 B。

4、消息接收架构

手机 B 在收到新消息到达通知后进行消息收取的整体架构如下图所示：

消息收取的流程主要分为3个步骤：

1）手机 B 发起收取消息的请求到接入层服务器 ConnnectSvr；
2）接入层服务器 ConnnectSvr 接到请求后转给逻辑层服务器 ReceiveSvr 进行处理；
3）ReceiveSvr 从存储层 MsgStore 中获取到需要下发的消息。

5、消息收发架构小结

在上述第4、5两节中分享的消息收发架构保障之下，微信可以保证手机 A 在发出消息 100ms 级别内让手机 B 收取到该条消息。

当然，对于退出后台的苹果 iOS 的微信用户，在苹果的 APNs 服务器正常的情况下，也可以保证在秒级别内通知到手机 B 点开 APP 进入前台来收取消息。

6、消息防丢失机制

虽然消息收发架构保证了消息收发双方能够及时收发消息，但该架构不能保证消息在传输过程中不发生丢弃。

当然为了达到任意一条消息都不丢的状态，最简单的方案是手机端对收到的每条消息都给服务器进行一次 ack 确认，但该方案在手机端和服务器之间的交互过多，并且也会遇到在弱网络情况下 ack 丢失等问题。

为了完美的做到消息不丢，微信消息系统对消息收发引入了 sequence 机制。

PS：感兴趣的话，以下是更多与IM消息送达保证有关的文章，可以一并阅读：

7、消息防丢失机制技术实现

7.1sequence 机制

1）每个用户都有42亿的 sequence 空间（从1到 UINT_MAX），从小到大连续分配；
2）每个用户的每条消息都需要分配一个 sequence；
3）服务器存储有每个用户已经分配到的最大 sequence；
4）手机端存储有已收取消息的最大 sequence。

PS：微信sequence序列号生成的具体算法和实现详见《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》。

7.2消息收取sequnece确认机制

当服务器和手机端都拥有了一个 sequence 之后，服务器和手机端之间就可以根据两者 sequence 的差异来收取消息，同时保证手机端未收取下去的消息最终能够收取下去。

具体流程如下图表示：

1）根据服务器和手机端之间 sequence 的差异，可以很轻松的实现增量下发手机端未收取下去的消息。

2）对于在弱网络环境差的情况，丢包情况发生概率是比较高的，此时经常会出现服务器的回包不能到达手机端的现象。由于手机端只会在确切的收取到消息后才会更新本地的 sequence，所以即使服务器的回包丢了，手机端等待超时后重新拿旧的 sequence 上服务器收取消息，同样是可以正确的收取未下发的消息。

3）由于手机端存储的 sequence 是确认收到消息的最大 sequence，所以对于手机端每次到服务器来收取消息也可以认为是对上一次收取消息的确认。一个帐号在多个手机端轮流登录的情况下，只要服务器存储手机端已确认的 sequence，那就可以简单的实现已确认下发的消息不会重复下发，不同手机端之间轮流登录不会收到其他手机端已经收取到的消息。

如上图4所示：假如手机 A 拿 Seq_cli = 100 上服务器收取消息，此时服务器的 Seq_svr = 150，那手机 A 可以将 sequence 为[101 - 150]的消息收取下去，同时手机 A 会将本地的 Seq_cli 置为150。

如上图5所示：手机 A 在下一次再次上来服务器收取消息，此时 Seq_cli = 150，服务器的 Seq_svr = 200，那手机 A 可以将 sequence为[151 - 200]的消息收取下去。

如上图6所示：假如原手机 A 用户换到手机 B 登录，并使用 Seq_cli = 120 上服务器收取消息，由于服务器已经确认 sequence <= 150 的消息已经被手机收取下去了，故不会再返回 sequence 为[121 - 150]的消息给手机 B，而是将 sequence 为[151 - 200]的消息下发给手机 B。

这里虽然 sequence 为[151 - 200]的消息有可能是被手机 A 和手机 B 都收取到，但由于手机 A 在收到 sequence 为[151 - 200]的消息时并没有给服务器进行确认或者这些消息手机 A 压根就没有收取到，所以为了防止消息丢失，sequence 为[的消息也是需要下发给手机 B 的。