即时通讯开发之IM系统的架构设计

目前我知晓的所有IM系统传输即时消息无外乎使用UDP、TCP、基于TCP的http这几种协议中的一种或几种。比如QQ主要采用UDP协议，MSN主要采用TCP协议，而且他们也都支持HTTP协议的代理模式。

 

我们该如何选择呢？

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

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

架构考量

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

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

 

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

服务端平台及技术选型

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

部分热点问题考量

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

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