IM系统架构设计之浅见

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

一.网络传输协议的选择

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

我们该如何选择呢？

• UDP协议实时性更好，但是如何处理安全可靠的传输并且处理不同客户端之间的消息交互是个难题，实现起来过于复杂；

• HTTP协议属于扩展支持，我们在产品的初始阶段可以不用支持；

• 那就非TCP协议莫属了，要考虑的同样也有很多，特别是如果有海量用户的需求。如何保证单机服务器高并发量，如何做到灵活，扩展的架构。

Tips: QQ 为什么采用 UDP 协议，而不采用 TCP 协议实现？

二.应该选择什么格式的数据协议

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

三.架构设计

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

架构考量：

• 由于采用可靠传输协议TCP，考虑到负载问题（短连接实现账号、关系链相关业务，长连接实现上线、信息推送）；

• 后台架构的灵活性、可扩展性，支持分布式部署――把网络层、业务逻辑层、数据层分离，网络层和业务层支持负载均衡策略、数据层支持分布式存储；

• 客户端SDK的易用性：把网络层、数据层分离、业务逻辑层分离；

后台架构简化图

架构示意图

架构细化图

说明

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

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

服务端平台及技术选型

• 系统开发平台： CentOS――Linux发行版的一种，稳定可靠、可定制优化、支持丰富；

• 网络支撑层： libevent――减小开发成本，增强稳定性；

• 缓存存储层： Redis――支持丰富的存储结构，支持分布式存储；

• 数据库： MySQL――最适合互联网的数据库，免授权、高效稳定、可控性高；

• 开发语言： C/C++；

部分热点问题考量

• 系统性能考量：

  • 编码角度：采用高效的网络模型，线程模型，I/O处理模型，合理的数据库设计和操作语句的优化；

  • 垂直扩展：通过提高单服务器的硬件资源或者网络资源来提高性能；

  • 水平扩展：通过合理的架构设计和运维方面的负载均衡策略将负载分担，有效提高性能；后期甚至可以考虑加入数据缓存层，突破IO瓶颈；

• 系统的高可用性：（防止单点故障）

  • 在架构设计时做到业务处理和数据的分离，从而依赖分布式的部署使得在单点故障时能保证系统可用。

  • 对于关键独立节点可以采用双机热备技术进行切换。

  • 数据库数据的安全性可以通过磁盘阵列的冗余配置和主备数据库来解决。

• Tips: 如果要支持web IM，请阅读《Web推送技术研究》
  

主要学习资料： 请自行google。

• 《1.4亿在线背后的故事》；

• 《BasicDB的架构演变》；

• 《微信之道－至简》；