IM系统架构设计之浅见

IM系统架构设计之浅见

背景:除去大名鼎鼎的QQ这款即时聊天工具,还有不少瓜分行业的IM,比如Taobao阿里旺旺、微博泡泡、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瓶颈;

系统的高可用性:(制止单点故障)

  • 在架构设计时做到事情处理和数量的分开,从而借助分布式的配备使得在单点故障时能保证系统可用。

  • 对于首要独立节点能够使用双机热备技术拓展切换。

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

重在学习资料: 请自行google。

《1.4亿在线背后的故事》;

《BasicDB的架构衍变》;

《微信之道-至简》;

深信阅读之后,总会诱发的!

欢迎………….

网站地图xml地图