微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗

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

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消息送达保证有关的文章，可以一并阅读：理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨融云技术分享：全面揭秘亿级IM消息的可靠投递机制从客户端的角度来谈谈移动端IM的消息可靠性和送达机制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 的。

8、本文小结

以上简单文字描述的就是微信最初的IM消息收发的架构。该架构实现了即时通讯软件对消息收发所需的两个基本要求：
1）消息尽可能的实时送达 ；
2）不丢消息。
以上：是 2014 年微信古早时期的消息收发架构的基本介绍，时过境迁，微信的消息收发架构已经发生了巨大的变化，但我们还是可以从中看到技术演变的价值与力量。程序员最大的成就与幸福，或许就是自己的代码跑在千万人的设备上，默默支撑着海量的需求。

9、参考资料

[1] iOS的推送服务APNs详解：设计思路、技术原理及缺陷等
[2] 了解iOS消息推送一文就够：史上最全iOS Push技术详解
[3] 消息推送技术干货：美团实时消息推送服务的技术演进之路
[4] 微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）
[5] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等
[6] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等[7] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等
[8] 从新手到专家：如何设计一套亿级消息量的分布式IM系统
[9] 一套分布式IM即时通讯系统的技术选型和架构设计
[10] 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制
[11] IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递[12] IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总[13] 零基础IM开发入门(一)：什么是IM系统？
[14] 理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨[15] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

10、微信团队的其它文章

《微信七年回顾：历经多少质疑和差评，才配拥有今天的强大》
《前创始团队成员分享：盘点微信的前世今生——微信成功的必然和偶然》
《即时通讯创业必读：解密微信的产品定位、创新思维、设计法则等》《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》《那些年微信开发过的鸡肋功能，及其带给我们的思考》
《读懂微信：从1.0到7.0版本，一个主流IM社交工具的进化史》
《同为IM社交产品中的王者，QQ与微信到底有什么区别》
《还原真实的腾讯：从最不被看好，到即时通讯巨头的草根创业史》《社交应用教父级人物的张小龙和马化腾的同与不同》
《专访马化腾：首次开谈个人经历、管理心得、技术创新、微信的诞生等》
《一文读懂微信之父张小龙：失败天才、颠覆者、独裁者、人性操控师》
《微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结》《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》《微信团队分享：微信支付代码重构带来的移动端软件架构上的思考》《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》《微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路》
《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》
《IM全文检索技术专题(四)：微信iOS端的最新全文检索技术优化实践》
《微信团队分享：微信后台在海量并发请求下是如何做到不崩溃的》《微信Windows端IM消息数据库的优化实践：查询慢、体积大、文件损坏等》
《微信技术分享：揭秘微信后台安全特征数据仓库的架构设计》
《IM跨平台技术学习(九)：全面解密新QQ桌面版的Electron内存优化实践》
《企业微信针对百万级组织架构的客户端性能优化实践》
《揭秘企业微信是如何支持超大规模IM组织架构的——技术解读四维关系链》
《微信团队分享：详解iOS版微信视频号直播中因帧率异常导致的功耗问题》
《微信团队分享：微信后端海量数据查询从1000ms降到100ms的技术实践》
《大型IM工程重构实践：企业微信Android端的重构之路》
《IM技术干货：假如你来设计微信的群聊，你该怎么设计？》

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