上篇一套亿级用户的IM架构技术干货：整体架构、服务拆分等 _IM架构

1、引言经历过稍有些规模的IM系统开发的同行们都有体会，要想实现大规模并发IM（比如亿级用户和数十亿日消息量这样的规模），在架构设计上需要一些额外的考虑，尤其是要解决用户高并发、服务高可用，架构和实现细节上都需要不短时间的打磨。
我在过往的工作经历里，亲手设计和实现了一套亿级用户量的IM，平台上线并经过6年多的验证，稳定性和可用性被验证完全达到预期。
这套IM系统，从上线至今已6年有余，本人也已经离职创业近2年，但当初设计和开发这套系统时积累和收获了大量的第一手实践经验和技术心得。
因此，想借本文把当时的架构设计经历记录下来，作为同行交流和参考，希望能提供一些启发，少走弯路。

文章插图

2、系列文章为了更好以进行内容呈现，本文拆分两了上下两篇。
本文是2篇文章中的第1篇：

《一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等》（本文）
《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等（稍后发布...）》

本篇主要总结和分享这套IM架构的总体设计和服务拆分等。
3、原作者本文基于邓昀泽的“大规模并发IM服务架构设计”一文进行的扩展和修订，感谢原作者的分享。
邓昀泽：毕业于北京航空航天大学，现蓝猫微会创始人兼CEO，曾就职于美团、YY语音、微软和金山软件等公司，有十多年研发管理经验。
4、技术指标在这套IM系统的架构上，技术上我们坚持高要求，经过数年的验证，也确实达到了设计预期。
这4大技术指标是：

文章插图

具体解释就是：

1）高可靠：确保不丢消息；
2）高可用：任意机房或者服务器挂掉，不影响服务；
3）实时性：不管用户在哪里，在线用户消息在1秒内达到（我们实际是75%消息可以做到120ms）；
4）有序性：确保用户消息的有序性，不会出现发送和接受的乱序。

5、架构拆分从整体架构上来说，亿级用户量的IM架构整体上偏复杂。
传统开源的IM服务喜欢把所有服务做到1-2个服务里（Connector+Service模型)，这样带来的问题比较严重。
传统开源的IM的问题主要体现在：

1）服务代码复杂，难以持续开发和运维；
2）单一业务逻辑出问题，可能会影响到其它逻辑，导致服务的全面不可用。

因此，我在做架构设计的时候尽量追求微服务化。即把整体架构进行分拆为子系统，然后子系统内按照业务逻辑分拆为微服务。
系统拆分如下图：

文章插图

4个子系统的职责是：

1）IM业务系统：服务IM相关的业务逻辑（比如好友关系、群关系、用户信息等）；
2）信令系统：负责用户登录，用户在线状态的维护，以及在线用户的下行推送；
3）推送系统：负责消息的在线推送和离线推送；
4）存储系统：负责消息和文件的存储和查询；

其中：信令系统和推送系统是基础设施，不只是可以为IM业务服务，也可以承载其它类似的业务逻辑（比如客服系统）。
在部署层面：采用存储3核心机房，信令和推送节点按需部署的方式（国内业务推荐8-10个点）。实际上我们只做了了北京3个机房，上海1个机房和香港一个机房的部署，就基本上满足了大陆+香港的业务需求。
下面将逐个介绍这4个子系统的细节方面。
6、IM业务系统一说到IM，很多人脑海里跳出的第一个关键就是“即时通信”，技术上理所当然的联想到了socket，也就是大家成天嘴上说的：“长连接” 。换句话说，很多对IM不了解或了解的不多的人，认为IM里的所有数据交互、业务往来都是通过“长连接”来实现的，这样话，对于本文章中拆分出的“IM业务系统”就有点不理解了。
实际上，早期的IM（比如20年前的QQ、MSN、ICQ），确实所有数据基本都是通过“长连接”（也就是程序员所说的“socket”）实现。
但如今，移动端为主端的IM时代，IM系统再也不是一个条“长连接”走天下。
现在，一个典型的IM系统数据往来通常拆分成两种服务：