蘑菇街即时通讯/IM服务器开发之架构选择

1、前言

IM服务器开发，从功能抽象的角度看可能非常简单，可以认为是管理大量的客户端连接和在不同的客户端之间传递消息，但具体到实现细节就比较复杂了。打个不恰当的比喻，OS的功能抽象也非常简单，无非是进程间的调度和硬件资源的管理，但要是自己去实现一个，一般人也就只能呵呵了。

由于IM服务器里面的内容比较多，这个可以是一个系列的内容，所以这里只介绍服务器的架构以及为什么选择这样的架构。

（移动端即时通讯/IM 学习和讨论QQ群：http://www.52im.net/portal.php?mod=topic&topicid=2）

2、设计原则

我们的设计原则是保持简单，可以做一定的扩容，无单点故障。很多时候开发人员常犯的错误是过度设计和提前优化，"When in doubt, use brute force", 有时简单的方案才是最好的方案。

架构设计需要考虑到服务器的业务逻辑和预计的用户量，比如同样的IM服务器设计，最高并发在线人数百万和千万的肯定有很大的不同， 如果按千万级别来设计一个只有百万级别的系统，增加的复杂度和工作量是非常可观的。

3、蘑菇街的方案

目前我们的IM服务器架构设计的单机并发连接10万用户，总并发用户量可以达百万级，对于这样规模的服务器后台，可以采用很简单的架构来处理。有一个DispatchServer来分配客户端到一个消息服务器，消息服务器之间的数据交互通过一个中心的RouteServer来转发，和数据持久化层之间的交互由DBProxy服务器来处理。

由于IM消息服务器和客户端之间交互非常频繁，但处理单个数据包的逻辑比较简单，没有IO或CPU密集型的操作，所以消息服务器采用单线程来处理，这样比较简单，没有死锁，竞争条件，出现问题非常好定位。

4、为何要分离出一个DBProxy服务器

分离出一个DBProxy服务器的的理由是，由于要操作DB和Redis，一个请求的回复会比较耗时，但是交互非常简单，一个请求对应一个回复，与消息服务器之间的长连接一般很稳定，不太需要处理太多的断连，所以这个可以用多线程的来处理大的IO等待。而且由于DBProxy服务器之间不需要交互，这样可以随着业务量的增加，添加很多实例来分散每个DBProxy的压力。

6、DispatchServer和RouteServer的逻辑

DispatchServer和RouteServer的逻辑都非常简单，而且可以启动多个实例，这样就不存在单点故障。两个DispatchServer或两个RouteServer之间的状态同步是通过消息服务器来实现的，比如用户上下线时，需要把这个状态通知所有的DispatchServer和RouteServer。

7、支持TCP长连接和HTTP长轮询两种接入方式

消息服务器支持TCP长连接和HTTP长轮询两种接入方式，目前的消息服务器承担了接入和业务逻辑处理两种角色，一般业界的做法是把这两种功能分解开，有一个接入服务器来处理客户端的接入，然后客户端的请求被分配到不同的业务逻辑处理服务器来处理，比如登陆服务器，状态通知服务器，好友管理服务器等。

但这样运维起来比较麻烦，对于百万量级的IM来说，这样有点过度设计的感觉，所以我们把这些功能融合在一个消息服务器里面实现，但这样的缺点是，更新一个业务功能时，需要把重启消息服务器，这样客户端会有一个重新连接服务器的过程。以后可以调研是不是可以把业务逻辑写成动态加载库，这样修改业务逻辑时，只要Reload动态库就可以了。

8、写在最后

搭建这些只是开了一个头，以后可以做很多有挑战性的技术，比如用分布式的消息存储方案代替现在的MySQL，用分布式的小文件系统存储系统代替现在依赖蘑菇街主站的图片存储方案，用一些Unsupervised Learning的算法对用户消息进行分析，来获取一些用户的profile信息。

附录：更多IM架构设计文章

《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《现代IM系统中聊天消息的同步和存储方案探讨》
《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《WhatsApp技术实践分享：32人工程团队创造的技术神话》
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》
《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《以微博类应用场景为例，总结海量社交系统的架构设计步骤》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
《社交软件红包技术解密(八)：全面解密微博红包技术方案》
《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》
《即时通讯新手入门：一文读懂什么是Nginx？它能否实现IM的负载均衡？》
《即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》
《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》
《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》
《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》
《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》
《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》
《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
《微信后台基于时间序的新一代海量数据存储架构的设计实践》
《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》
《IM开发基础知识补课(十)：大型IM系统有多难？万字长文，搞懂异地多活！》
《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》
《一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等》
《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》
《从新手到专家：如何设计一套亿级消息量的分布式IM系统》
《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》
《融云技术分享：全面揭秘亿级IM消息的可靠投递机制》
《IM开发技术学习：揭秘微信朋友圈这种信息推流背后的系统设计》
《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》
《阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践》
《阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践》
《阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化》
《基于实践：一套百万消息量小规模IM系统技术要点总结》
>> 更多同类文章 ……

（原文链接：http://mogu.io/im-server-develop-01-8）

辛苦楼主，👍👍👍

这样的文章写了跟没写有啥区别啊

引用：quinn_he 发表于 2022-01-17 13:40
这样的文章写了跟没写有啥区别啊

别站在上帝视角来说话，6年前网上就找不到几篇关于IM方面的架构设计文章，有人分享已经很不错了，何况当时的这个大佬还写了完整的开源TeamTalk分享出来（《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》。