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

本次要分享的是一套一级用户的即时通讯I'M架构技术干货上片，包括整体架构、服务拆分等。想实现大规模并发I'M在架构设计上需要一些额外的考虑，尤其是要解决用户高并发服务高可用架构和实践细节上都需要不短时间的打磨。我在过往的工作经历里，亲手设计和实现了一套一级用户量的I'M平台上线，并经过6年多的验证，稳定性和可用性被验证完全达到预期。这套I'M系统从上线至今已6年有余，本人也已经离职创业近两年，但当初设计和开发这套系统时，积累和收获了大量的第一手实践经验和技术心得，因此想借此把当时的架构设计经历记录下来，作为同行交流和参考，希望能提供一些启发，少走弯路。一技术指标在这套I'M系统的架构上，技术上我们坚持高要求，经过数年的验证，也确实达到了设计预期，这四大技术指标是高可靠、高可用、实时性、有序性。二、架构拆分。从整体架构上来说，一级用户量的I'M架构整体上偏复杂，传统开源的I'M服务喜欢把所有服务做到1~2的服务里及connector+service模型，这样带来的问题比较严重。传统开源的I'M的问题主要体现在，一、服务代码复杂，难以持续开发和运维，二、单业务逻辑出问题，可能会影响到其他逻辑，导致服务的全面不可用。因此。

我在做架构设计的时候，尽量追求微服物化，即把整体架构进行分叉为子系统，然后子系统内按照业务逻辑分叉为微服务。4个子系统的职责是因业务系统、心灵系统、推送系统、存储系统。三I'M业务系统一说到I'M，很多人脑海里跳出的第一个关键就是即时通信技术上理所当然的联想到了second，也就是大家成天嘴上说的长连接。换句话说，很多对I'M不了解或了解的不多的人认为I'M里的所有数据交互、业务往来都是通过长连接来实现的。这样话，对于本文章中拆分出的I'M业务系统就有点不理解了。实际上早期的I'M，比如20年前的QQ man s CQ, 确实所有数据基本都是通过长连接，也就是程序员所说的second实现。但如今移动端主端的I'M时代，I'M系统再也不是一个条长连接走天下。现在一个典型的I'M系统数据往来通常拆分成两种服务，一、second长连接服务，也就是本文中的推送服务2、HTTP短连接服务，就是最常用的http rest接口，那些也就是本文中的I'M业务系统，通俗一点也就现在的I'M系统通常都。

市长短连接配合一起实现的四心令系统。系令系统主要职责是三部分，维护用户在线状态、下行消息推送、业务分发。系令系统为了实现以上这三个职责，同时要确保我们服务可平行扩展的能力和稳定性。在实际的技术实现上，我们实际上把心灵服务分成为三个服务模块，Loging服务、online服务、root服务。五、推送系统。推送系统的核心任务是接收到给用户发送下行消息的请求以后，去新令服务查询用户是否在线，如果在线走心令推送，如果不在线走离线推送，如iOS的appens、华为推送、小米推送等。因为推送服务可能出现大规模并发疯忧，比如大群激烈讨论的时候会触发一级的TBS，因此推送服务用KA特做了削风。

六存储系统存储服务主要是负责消息的存储和查询，因为消息量巨大，对存储服务的并发能力和存储量要求巨大。为了平衡性能、空间和成本，存储服务按数据的热度进行了分级和区别对待，具体是以短期消息7天存储在微Dis里，2、近期消息1~3个月存储在MYSQL里，以备用户实时查询，3、历史信息存储在h base类，作为历史数据慢查询。