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

一、引言

经历过稍有些规模的IM系统开发的同行们都有体会，要想实现大规模并发IM（好比亿级用户和数十亿日消息量这样的规模），在架构设计上须要一些额外的考虑，尤为是要解决用户高并发、服务高可用，架构和实现细节上都须要不短期的打磨。

我在过往的工做经历里，亲手设计和实现了一套亿级用户量的IM，平台上线并通过6年多的验证，稳定性和可用性被验证彻底达到预期。

这套IM系统，从上线至今已6年有余，本人也已经离职创业近2年，但当初设计和开发这套系统时积累和收获了大量的第一手实践经验和技术心得。

所以，想借本文把当时的架构设计经历记录下来，做为同行交流和参考，但愿能提供一些启发，少走弯路。

本文已同步发布于“即时通信技术圈”公众号，欢迎关注。公众号上的连接是：点此进入。

二、系列文章

为了更好以进行内容呈现，本文拆分两了上下两篇。

本文是2篇文章中的第1篇：

《一套亿级用户的IM架构技术干货(上篇)：总体架构、服务拆分等》（本文）

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

本篇主要总结和分享这套IM架构的整体设计和服务拆分等。

三、原做者

本文基于邓昀泽的“大规模并发IM服务架构设计”一文进行的扩展和修订，感谢原做者的分享。

邓昀泽：毕业于北京航空航天大学，现蓝猫微会创始人兼CEO，曾就任于美团、YY语音、微软和金山软件等公司，有十多年研发管理经验。

四、技术指标

在这套IM系统的架构上，技术上咱们坚持高要求，通过数年的验证，也确实达到了设计预期。

这4大技术指标是：

具体解释就是：

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

五、架构拆分

从总体架构上来讲，亿级用户量的IM架构总体上偏复杂。

传统开源的IM服务喜欢把全部服务作到1-2个服务里（Connector+Service模型)，这样带来的问题比较严重。

传统开源的IM的问题主要体如今：

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

所以，我在作架构设计的时候尽可能追求微服务化。即把总体架构进行分拆为子系统，而后子系统内按照业务逻辑分拆为微服务。

系统拆分以下图：

4个子系统的职责是：

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

其中：信令系统和推送系统是基础设施，不仅是能够为IM业务服务，也能够承载其它相似的业务逻辑（好比客服系统）。

在部署层面：采用存储3核心机房，信令和推送节点按需部署的方式（国内业务推荐8-10个点）。实际上咱们只作了了北京3个机房，上海1个机房和香港一个机房的部署，就基本上知足了大陆+香港的业务需求。

下面将逐个介绍这4个子系统的细节方面。

六、IM业务系统

一说到IM，不少人脑海里跳出的第一个关键就是“即时通讯”，技术上理所固然的联想到了socket，也就是你们整天嘴上说的：“长链接”。换句话说，不少对IM不了解或了解的很少的人，认为IM里的全部数据交互、业务往来都是经过“长链接”来实现的，这样话，对于本文章中拆分出的“IM业务系统”就有点不理解了。

实际上，早期的IM（好比20年前的QQ、MSN、ICQ），确实全部数据基本都是经过“长链接”（也就是程序员所说的“socket”）实现。

但现在，移动端为主端的IM时代，IM系统不再是一个条“长链接”走天下。

如今，一个典型的IM系统数据往来一般拆分红两种服务：

• 1）socket长链接服务（也就是本文中的“推送服务”）；
• 2）http短链接服务（就是最经常使用的http rest接口那些，也就是本文中的“IM业务系统”）。

通俗一点，也也就如今的IM系统，一般都是长、短链接配合一块儿实现的。 

好比论坛里不少热门技术方案都是这样来作的，好比最典型的这两篇：《IM单聊和群聊中的在线状态同步应该用“推”仍是“拉”？》、《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》，文记里提到的“推”其实就是走的“长链接”、“拉”就上指的http短链接。

对于socket长链接服务就没什么好说，就是你们最常理解的那样。

IM业务系统详细来讲，就是专一处理IM相关的业务逻辑，好比：

• 1）维护用户数据：用户基本信息等；
• 2）维护好友关系：好友请求、好友列表、好友信息等；
• 3）维护群组信息：群建立、解散、成员管理等；
• 4）提供数据：离线拉取、历史记录同步；
• 5）其它逻辑：好比经过存储和推送系统，存储消息和发送通知；

按照微服务的原则，IM业务系统也被分拆为多个服务，好比：

• 1）GInfo服务：群组信息维护；
• 2）IM服务：处理1V1消息；
• 3）GIM服务：处理群组消息。

七、信令系统

7.1 基本状况

信令系统主要职责是3部分： 

 

1）维护用户在线状态：

由于用户规模庞大，必然是多个集群，每一个集群多台服务器为用户提供服务。

考虑到服务器运维的复杂性，咱们要假定任何一个集群，任何一个服务器均可能会挂掉，并且在这种状况下要可以继续为用户提供服务。

在这种状况下，若是用户A给用户B发消息，咱们须要知道用户B在哪一个服务器上，才能把消息正确推送给用户B。用户在哪一个信令服务，这个信息就是在线状态数据。

2）下行消息推送：

跟上一个职责有关，用户在线的时候，若是有其它用户给他发消息，那就最好不要走离线推送，而是走在线推送。

在线推送的最后一个环节，是把用户消息推送给用户设备，由于就须要知道用户登陆到哪一个服务器上。

3）业务分发：

信令服务不仅能够处理IM请求，也能够处理其它类型的业务请求。为了处理不一样的业务，就须要有分发能力。

具体作法是经过一个SVID（service id）来实现，不一样的业务携带不一样的SVID，信令服务就知道如何分发了。

用户经过登陆服务把数据（好比IM消息）发送到信令系统，信令系统根据SVID转发给IM系统。无论后台有多少个业务，用户只须要一条连接到信令。

7.2 服务拆分

信令系统为了实现以上这3个职责，同时要确保咱们服务可平行扩展的能力和稳定性，在实际的技术实现上，咱们实际上把信令服务分拆为3个服务模块。

以下图所示： 

下面将逐个介绍这3个子服务。

7.3 Login服务

Login服务主要负责维护用户长连接：

• 1）每一个用户一条连接到Login服务，并按时间发心跳包给Login服务；
• 2）服务定时检查用户连接状态和心跳包，好比发现2个心跳周期都没收到心跳，就认为用户掉线了（有假在线问题，有兴趣同窗可回贴讨论）。

Login服务收到用户登陆请求之后，验证uid/cookie，若是成功就把这个用户的登陆信息发送给online。

此过程主要记录的信息包含：

• 1）uid（用户id）；
• 2）Login服务器IP/Port；
• 3）Route服务器的IP/Port。

若是用户发送IM消息，先发送到Login，Login转发给Route，Route根据服务的类型（SVID），发现是IM协议就发送给后端的IM服务。

Login对并发要求比较高，通常要支持TCP+UDP+Websocket几种方式，单服务能够作到10-250万之间。从服务稳定性角度触发，建议是控制VM的CPU/内存，单服务器以20-50万为合适。

Login服务器自己没有状态，任何一个Login服务断掉，用户端检测到之后重连另外一个Login服务器就能够了，对总体服务可靠性基本没有影响。

7.4 Online服务

Online服务主要负责维护用户的在线信息：

• 1）若是用户掉线，Online服务里信息就是空；
• 2）若是用户在线，Online就能找到用户登陆在哪一个集群，哪一个Login服务器上。

Online业务相对简单：多个Login服务器会链接到Online，按期同步用户登陆和离线信息。

Online主要职责是：把用户状态信息存储在Redis集群里。所以也是无状态的，任何一个Online服务挂掉，不影响总体服务能力。

若是集群规模不大，用户规模也不大，Online服务也能够收到Login服务里去。

若是规模比较大，建议分拆出来，一方面简化Login的逻辑复杂度，同时避免写Redis的慢操做放在Login服务里。由于Login要同时处理50万以上的并发连接，不适合在循环里嵌入慢操做。

7.5 Route服务

Route服务的设计核心，是做为信令系统跟其它子系统的交互层。Route下接Login服务，能够接受用户业务信息（IM），也能够往用户推送下行消息。

多个后端业务系统能够接入到Route，按照服务类型（SVID, service id）注册。好比IM服务能够接入到Route, 注册SVID_IM。这样Login接收到SVID=SVID_IM的消息，转发给Route，Route就能够根据SVID转发给IM相关的服务。

Route简单的根据SVID作转发，不处理具体的业务逻辑，所以也是无状态的。一个信令集群能够有多个Route服务，任何服务挂了不影响总体服务能力。

八、推送系统

推送系统的核心任务：是接收到给用户发送下行消息的请求之后，去信令服务查询用户是否在线，若是在线走信令推送，若是不在线走离线推送（如iOS的APNS、华为推送、小米推送等）。

由于推送服务可能出现大规模并发蜂拥，好比大群激烈讨论的时候，会触发亿级的TPS。所以推送服务用Kafka作了削峰。

我在实际的技术实现上，将推送系统进行了以下细分： 

具体就是：

• 1）PushProxy：接受用户的推送请求，写入Kafka；
• 2）Kafka：缓存推送服务；
• 3）PushServer：从Kafka获取推送请求，判断用户是否在线；
• 4）PushWorker：真正推送给信令或者APNS，华为推送等。

这里一样，除了Kafka之外每一个服务都是无状态的，由于也能够实现平行扩展和容错，任何服务挂掉不影响总体服务可用性。

九、存储系统

存储服务主要是负责消息的存储和查询，由于消息量巨大，对存储服务的并发能力和存储量要求巨大。

为了平衡性能、空间和成本，存储服务按数据的热度进行了分级和区别对待。

具体是：

• 1）短时间消息(7天)：存储在Redis里；
• 2）近期消息(1-3个月)：存储在Mysql里，以备用户实时查询；
• 3）历史信息：存储在HBase里，做为历史数据慢查询。

同时，为了应对超大群的大量消息处理，存储服务在实际的技术实现上，也作了比较细的分拆。

存储服务具体拆分以下图：

具体的业务划分就是：

• 1）MsgProxy：负责接受IM子系统的存储请求，写入Kafka；
• 2）MsgWriter：从Kafka获取写请求，按需写入Redis和Mysql；
• 3）MsgReader：接受用户的消息查询请求，从Redis，Mysql或者HBase读数据；
• 4）运维工具：主要是数据库的运维需求。

消息队列（Kafka）在这里角色比较重要，由于对于高并发请求（100万人公众号），须要经过消息队列来作削峰和并行。

在具体部署上：多是3-4个MsgProxy，后端能够对应15个左右的MsgWriter。MsgWriter是比较慢的，须要同时操做多个数据库，还要保证操做的原子性。

十、本篇小结

本篇主要总结了这套亿级用户量IM系统的整体架构设计，为了高性能和横向扩展性，基于微信的理念将整个架构在实现上分红了4个子系统，分别是：IM业务系统、信令系统、推送系统、存储系统。

针对这4个子系统，在实际的技术应用层上，又进行了进一步的服务拆分和细化，使得整个架构伸缩性大大加强。

—— 下篇《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》稍后发布，敬请期待 ——

附录：相关文章

《浅谈IM系统的架构设计》

《简述移动端IM开发的那些坑：架构设计、通讯协议和客户端》

《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》（* 力荐）

《一套原创分布式即时通信(IM)系统理论架构方案》（* 力荐）

《从零到卓越：京东客服即时通信系统的技术架构演进历程》（* 力荐）

《蘑菇街即时通信/IM服务器开发之架构选择》

《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》

《微信后台基于时间序的海量数据冷热分级架构设计实践》

《移动端IM中大规模群消息的推送如何保证效率、实时性？》

《现代IM系统中聊天消息的同步和存储方案探讨》（* 力荐）

《以微博类应用场景为例，总结海量社交系统的架构设计步骤》

《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》（* 力荐）

《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》

《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》

《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》

《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》

《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》

《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》

《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》

《社交软件红包技术解密(八)：全面解密微博红包技术方案》

《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》（* 力荐）

《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》

《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》

《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》

《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》

《微信后台基于时间序的新一代海量数据存储架构的设计实践》

《一套亿级用户的IM架构技术干货(上篇)：总体架构、服务拆分等》

>> 更多同类文章 ……

 

本文已同步发布于“即时通信技术圈”公众号。

▲ 本文在公众号上的连接是：点此进入。同步发布连接是：http://www.52im.net/thread-3393-1-1.html