浅谈IM系统的架构设计

JackJiang · 3 年前

前言

除去QQ、微信这样的即时通讯聊天工具，还有许多细分行业的IM，比如淘宝阿里旺旺、网易泡泡、YY语音......。恰巧公司产品也要开发一款基于我们自己行业的类IM系统，很有幸我担当了这个产品的架构师，核心代码编写、实现者。下面把我近年来从技术上我对IM系统（即时消息的传输，不包括语音，视频，文件的传输）的理解和设计分享出来，浅薄之见，望大家别见笑，欢迎给出批评意见。

另外，以下几篇有关IM实际动手开发的文章也值得一读，有兴趣可以看看：

选择困难症1：网络传输协议的选择

目前我知晓的所有IM系统传输即时消息无外乎使用UDP、TCP、基于TCP的http这几种协议中的一种或几种。比如QQ主要采用UDP协议，MSN主要采用TCP协议，而且他们也都支持HTTP协议的代理模式。更多资料，请参加这篇文章《即时通讯等通信软件的网络协议和端口收集整理》。

我们该如何选择呢？

UDP协议实时性更好，但是如何处理安全可靠的传输并且处理不同客户端之间的消息交互是个难题，实现起来过于复杂；
HTTP协议属于扩展支持，我们在产品的初始阶段可以不用支持；
那就非TCP协议莫属了，要考虑的同样也有很多，特别是如果有海量用户的需求。如何保证单机服务器高并发量，如何做到灵活，扩展的架构。

（即时通讯网注：还可参考相关文章《为什么QQ用的是UDP协议而不是TCP协议？》、《移动端即时通讯协议选择：UDP还是TCP？，更多类似文章：http://www.52im.net/forum.php?mod=collection&action=view&ctid=18》。）

择困难症2：数据通信格式（协议）的选择

二进制格式？文本格式？这个话题转到这篇文章《如何选择即时通讯应用的数据传输格式》，从我们当前的需求和产品周期上我觉得选择JSON形式的数据协议是最好的。

（即时通讯网注：IM的数据传输格式的选择是个头疼的问题，比如这篇文章跟本文的意见相左《强列建议将Protobuf作为你的即时通讯应用数据传输格式，更多类似文章：http://www.52im.net/forum.php?mod=collection&action=view&ctid=18》）

架构设计

首先我们来提炼一下一个IM系统的主要需求，包括账号，关系链，在线状态显示，消息交互......。

1架构考量

由于采用可靠传输协议TCP，考虑到负载问题（短连接实现账号、关系链相关业务，长连接实现上线、信息推送）；
后台架构的灵活性、可扩展性，支持分布式部署——把网络层、业务逻辑层、数据层分离，网络层和业务层支持负载均衡策略、数据层支持分布式存储；
客户端SDK的易用性：把网络层、数据层分离、业务逻辑层分离。

后台架构简化图：

架构示意图：

架构细化图：

说明：
从架构细化图中可以看出对于上线服务由于建立的是TCP长连接，对于单台服务器往往由于硬件资源、系统资源、网络资源的限制无法做到海量用户的同时在线，所以设计为根据服务器负载支持多服务器上线，同时由于多服务器上线造成了对整个系统交互（不同的客户端的交互，协作部门应用服务和客户的交互）的分割，引入消息转发服务器作为粘合点。另外对于多服务器上线造成的统一账户信息（在线状态，消息）数据的分割，引入统一的数据层（内存存储层：session、状态信息存储、消息队列存储；数据库：账号信息存储）做到业务和数据的分离，也就做到了支持分布式部署。参见我的这篇文章《构建高性能服务的考量》。

对于部分业务服务：做到网络层、业务层、数据层的完全分离。首先对于TCP短连接来说不会如长连接那般消耗资源，即使后期遇到海量的并发访问请求依然可以从容的通过负载均衡策略和数据分布式部署策略进行解决。参见我的这篇文章《服务端架构中的“网关服务器”》。

2服务端平台及技术选型

系统开发平台：
CentOS——Linux发行版的一种，稳定可靠、可定制优化、支持丰富。
网络支撑层：
libevent——减小开发成本，增强稳定性。
缓存存储层：
Redis——支持丰富的存储结构，支持分布式存储。
数据库：
MySQL——最适合互联网的数据库，免授权、高效稳定、可控性高。
开发语言：
C/C++。

3部分热点问题考量

主要是有关系统性能方面的考量：

编码角度：
采用高效的网络模型，线程模型，I/O处理模型，合理的数据库设计和操作语句的优化；
垂直扩展：
通过提高单服务器的硬件资源或者网络资源来提高性能；
水平扩展：
通过合理的架构设计和运维方面的负载均衡策略将负载分担，有效提高性能；后期甚至可以考虑加入数据缓存层，突破IO瓶颈；
系统的高可用性：
防止单点故障；
在架构设计时做到业务处理和数据的分离，从而依赖分布式的部署使得在单点故障时能保证系统可用。
对于关键独立节点可以采用双机热备技术进行切换。
数据库数据的安全性可以通过磁盘阵列的冗余配置和主备数据库来解决。

4主要学习资料

《1.4亿在线背后的故事》
《微信之道－至简》

全站即时通讯技术资料分类

2 楼: lovesnowfish · 3 年前

学习中

3 楼: dsperson · 2 年前

加油咯⛽️

4 楼: pigo残 · 2 年前

能说说MQ在IM架构中的使用方式么

5 楼: shukaka · 2 年前

大家都在做IM服务吗

6 楼: dusuijiang · 2 年前

学习中

7 楼: SylvanasTeemo · 2 年前

来学习一下！

8 楼: xy521174 · 2 年前

慢慢看

9 楼: bearly · 2 年前

xuexile

10 楼: littleboyer · 2 年前

架构很好，可是具体实现好难啊，没有一定积累很难产品化

11 楼: 四毛钱_ijnei · 2 年前

学习

12 楼: ichampion · 2 年前

引用：pigo残发表于 2017-07-27 10:28
能说说MQ在IM架构中的使用方式么

按照我的理解就是：一般的TCP/IP通信可能出现丢包，也不一定能保证消息顺序发送，MQ就是解决这个问题的。不知道对不对。

13 楼: ichampion · 2 年前

博主好，如你所说，将未成功发送的消息或离线消息暂存到消息队列。
1、此时客户端上线，而服务端有在线消息和离线消息都要推给客户端，如何保证这两种消息的时序性？
2、服务端如何判断消息送达，判断客户端是否在线不能保证消息必达；如果用回调+延时判断转发失败，那是不是要用一个队列来管理回调函数？这样在高并发的情况下是否会对系统性能产生影响？

14 楼: JackJiang · 2 年前

引用：ichampion 发表于 2018-02-01 16:09
博主好，如你所说，将未成功发送的消息或离线消息暂存到消息队列。
1、此时客户端上线，而服务端有在线消 ...

有个概念你可能分的不清。
现在主流的IM中，离线消息和实时消息走的是不同的通道，离线消息是在登陆时通过http短连接“拉”过来的（这种体验你可以在你换手机时，微信首次登陆时，你能看到消息或数据的加载有个加载百分比的显示，能明显感觉出来。平时你如果有群的话，你启动app时会看到未读数一直在往上加，这表示微信在分页加载这些数据，但肯定不会是通过实时通道“推”，真如你所考虑的——这太奢侈了，而且性能一定会有影响）。

你可以参考一下论坛的IM干货系列文章：

15 楼: ichampion · 2 年前

引用：JackJiang 发表于 2018-02-01 17:37
有个概念你可能分的不清。
现在主流的IM中，离线消息和实时消息走的是不同的通道，离线消息是在登陆时通 ...

我知道是“拉”取消息，我的意思是：打个比方，我微信上线了，这时候我会从服务端获取离线消息（比如是我朋友约我星期六玩），但是很巧的是，在我拉取消息的时候，这个朋友想确认一下我星期六是否有空，又给我发了信息，此时我是在线的，应该由服务端push过来。那客户端是不是要做消息时间的判断来显示消息呢？否则的话，可能他实时的消息显示在前，离线的消息显示在后。但是客户端做时间判断的话，可能出现一种情况就是我实时的消息显示了，结果离线消息过来以后，在当前的消息之前又冒出来几条消息。这样的场景在微信中好像不存在。

16 楼: JackJiang · 2 年前

引用：ichampion 发表于 2018-02-02 09:08
我知道是“拉”取消息，我的意思是：打个比方，我微信上线了，这时候我会从服务端获取离线消息（比如是我 ...

离线消息一定是无条件插到聊天列表的前面的，因为这次拉的消息肯定比你刚才收到的实时消息要老，不用判断时间都可以做到。

17 楼: ichampion · 2 年前

引用：JackJiang 发表于 2018-02-02 10:40
离线消息一定是无条件插到聊天列表的前面的，因为这次拉的消息肯定比你刚才收到的实时消息要老，不用判断 ...

我就卡在这一步，离线消息如何无条件插到列表前面？如果我的离线消息里面有一张图片（或者说离线消息体量比较大），那这个时候，实时的消息已经push过来了，之后我收到了图片并且转码完成要显示了，如您所说，不判断时间的话，怎么让图片显示在它该显示的地方呢？

18 楼: jecelyin · 1 年前

学习学习了

19 楼: ckcsb · 1 年前

良心教程，学习下

20 楼: 妮子 · 4 个月前

引用：ichampion 发表于 2018-02-02 10:50
我就卡在这一步，离线消息如何无条件插到列表前面？如果我的离线消息里面有一张图片（或者说离线消息体量 ...

客户端应该会有对每个会话的消息做merge吧

本文目录

前言

选择困难症1：网络传输协议的选择

择困难症2：数据通信格式（协议）的选择