IM系统架构设计之浅见
背景：除去大名鼎鼎的QQ这款即时聊天工具，还有许多细分行业的IM，比如淘宝阿里旺旺、网易泡泡、YY语音......。恰巧公司产品也要开发一款基于我们自己行业的类IM系统，很有幸我担当了这个产品的架构师，核心代码编写、实现者。下面我近年来从技术上我对IM系统（即时消息的传输，不包括语音，视频，文件的传输）的理解和设计分享出来，浅薄之见，望大家别见笑，欢迎给出批评意见。
一.网络传输协议的选择
我们该如何选择呢？
UDP协议实时性更好，但是如何处理安全可靠的传输并且处理不同客户端之间的消息交互是个难题，实现起来过于复杂；
HTTP协议属于扩展支持，我们在产品的初始阶段可以不用支持；
那就非TCP协议莫属了，要考虑的同样也有很多，特别是如果有海量用户的需求。如何保证单机服务器高并发量，如何做到灵活，扩展的架构。
二.应该选择什么格式的数据协议
三.架构设计
首先我们来提炼一下一个IM系统的主要需求，包括账号，关系链，在线状态显示，消息交互......。
架构考量：
由于采用可靠传输协议TCP，考虑到负载问题（短连接实现账号、关系链相关业务，长连接实现上线、信息推送）；
后台架构的灵活性、可扩展性，支持分布式部署——把网络层、业务逻辑层、数据层分离，网络层和业务层支持负载均衡策略、数据层支持分布式存储；
客户端SDK的易用性：把网络层、数据层分离、业务逻辑层分离；
后台架构简化图
架构示意图
架构细化图
说明
服务端平台及技术选型
系统开发平台： CentOS——Linux发行版的一种，稳定可靠、可定制优化、支持丰富；
网络支撑层： libevent——减小开发成本，增强稳定性；
缓存存储层： Redis——支持丰富的存储结构，支持分布式存储；
数据库： MySQL——最适合互联网的数据库，免授权、高效稳定、可控性高；
开发语言： C/C++；
部分热点问题考量
系统性能考量：
-
编码角度：采用高效的网络模型，线程模型，I/O处理模型，合理的数据库设计和操作语句的优化；
-
垂直扩展：通过提高单服务器的硬件资源或者网络资源来提高性能；
-
水平扩展：通过合理的架构设计和运维方面的负载均衡策略将负载分担，有效提高性能；后期甚至可以考虑加入数据缓存层，突破IO瓶颈；
系统的高可用性：（防止单点故障）
-
在架构设计时做到业务处理和数据的分离，从而依赖分布式的部署使得在单点故障时能保证系统可用。
-
对于关键独立节点可以采用双机热备技术进行切换。
-
数据库数据的安全性可以通过磁盘阵列的冗余配置和主备数据库来解决。
主要学习资料： 请自行google。
《1.4亿在线背后的故事》；
《BasicDB的架构演变》；
《微信之道－至简》；
相信阅读之后，总会启发的！
欢迎.............