一套分布式IM即时通讯系统的技术选型和架构设计

引言

分布式IM即时通讯系统本质上就是对线上聊天和用户的管理。

针对聊天本身来说，最核心的需求就是：发送文字、图片、文件、语音、视频、消息缓存、消息存储、消息未读、已读、撤回，离线消息、历史消息、单聊、群聊，多端同步，以及其他一些需求。

对用户管理来说，存在的需求包含：添加好友、查看好友列表、删除好友、查看好友信息、创建群聊、加入群聊、查看群成员信息、退出群聊、修改群昵称、拉人进群、踢人出群、解散群聊、填写群公告、修改群备注以及其他用户相关的需求等。

为了更好的理解分布式IM即时通讯系统的设计，我站在架构师的角度，在充分了解系统需求、业务流程和技术流程后，从全局视角为系统设定方案目标，对技术方案进行选型，对系统进行总体架构设计和分层架构设计，并梳理清楚发送消息的交互链路、单聊和群聊的交互链路。希望对你有帮助。

方案目标

在进行技术选型与总体架构设计之前，需要明确一个事项，就是系统无论采用哪种方案，采用哪种架构设计都需要明确这种方案的业务目标、技术目标和架构目标，并在研发过程中不断评估系统的总体性能表现，发现系统瓶颈并不断进行优化。

总体上，我们搭建和开发的分布式IM即时通讯系统，需要满足如下方案目标。

具体是：

• 1）业务目标：满足需求设计篇章中的各类需求场景；
• 2）技术目标：支持无限扩容，百万用户同时在线聊天；
• 3）架构目标：高并发、高性能、高可用、可监控、可预警、可伸缩，支持无限扩展。

技术选型

在技术选型上，除了采用SpringBoot等基础框架外，也会采用容器化方案。

同时，考虑到为了尽量降低技术门槛，在整个分布式IM即时通讯系统的技术选型中，主要采用市面上比较流行的技术框架和方案。

具体选型如下所示：

• 1）开发框架：SpringBoot、SpringCloud、SpringCloud Alibaba、Dubbo；
• 2）缓存：Redis分布式缓存+Guava本地缓存；
• 3）数据库：MySQL、TiDB、HBase；
• 4）流量网关：OpenResty+Lua；
• 5）业务网关：SpringCloud Gateway + Sentinel；
• 6）持久层框架：MyBatis、Mybatis-Plus；
• 7）服务配置、服务注册与发现：Nacos；
• 8）消息中间件：RocketMQ；
• 9）网络通信：Netty；
• 10）文件存储：Minio；
• 11）日志可视化治理：ELK；
• 12）容器化管理：Swarm、Portainer；
• 13）监控：Prometheus、Grafana；
• 14）前端：Vue；
• 15）单元测试：Junit；
• 16）基准测试：JMH；
• 17）压力测试：JMeter。

初步架构设计

对于IM即时通讯系统来说，涵盖了即时通讯后端服务、大后端平台、SDK接入服务、OpenAI接入服务、大前端UI，我相信不少小伙伴多多少少能够画出IM即时通讯系统的架构图，大致如下图所示。

其实，这种这种架构设计也比较常见，在这种架构设计中，Kong/Openresty/Nginx只做负载均衡和反向代理，研发人员更多的是关注业务层和基础层的开发，流量比较小时，这种架构设计一般不会有什么问题。但是一旦流量比较大，用户调用后端平台的接口发送消息时，即时通讯SDK同步调用即时通讯服务的接口就会出现性能问题。

因为每个终端同时只能与一个IM即时通讯服务实例建立连接，如果大量的用户终端恰好都与一个IM即时通讯服务建立连接，那即时通讯SDK频繁同步调用同一个IM即时通讯服务的接口就会出现性能瓶颈。此时，出现性能瓶颈时，不仅仅会影响到IM即时通讯服务，也会对后端平台接收请求的业务造成一定的影响。

架构设计优化

既然上节图中所示的架构设计存在性能瓶颈，那我们如何进行优化呢？

为此我们在前图基础上进行了优化，优化后的架构如下图所示。

对比两图可以看出，在屏蔽掉技术实现细节的前提下，我们将对业务的校验和流量管控进行前置化，放大Kong/OpenResty/Nginx的职责，使得这些软件不仅具备反向代理和负载均衡的功能，还能实现限流、黑白名单、流量管控、业务校验等功能。

也就是说，在这种架构模式下，我们充分发挥了整个分布式IM即时通讯系统的入口职责，充分利用Kong/OpenResty/Nginx的高并发、高吞吐量的能力，尽量将大部分无效请求挡在整个系统之外。例如，用户在没登录系统的前提下，就尝试调用发送消息、添加好友、添加群组等等接口。这样会大大减轻后台平台的业务压力。

除了在Kong/OpenResty/Nginx中实现限流、黑白名单、流量管控、业务校验等功能外，我们还引入了业务网关集群，实现限流、降级、熔断、流控、校验、鉴权等功能，进一步保证下游系统的稳定性和安全。

为了解决大量用户终端恰好连接到同一个IM即时通讯服务实例，IM即时通讯SDK频繁调用同一个IM即时通讯服务实例的接口造成的性能问题。我们在IM即时通讯服务SDK与IM即时通讯服务之间引入了RocketMQ集群。

IM即时通讯服务集群中的每一个IM即时通讯服务实例在集群中都有一个唯一的ID，并且每个IM即时通讯服务实例在启动后，只会监听RocketMQ中与自身ID相关的Topic。这样每个IM即时通讯服务只会收到与自身ID相关的Topic中的消息，不会接收所有的消息。

当用户登录系统后，就会与IM即时通讯服务建立长连接，并且会以用户ID和终端为Key，以IM即时通讯服务的ID为value，将其存储到分布式缓存中。同时，会以用户ID和终端为Key，以用户终端与IM即时通讯服务建立的长连接为value，将其存储到IM即时通讯服务本地内存中。

当用户调用后端平台的接口发消息时，会带上目标用户的ID，并且在IM即时通讯SDK中会指定用户登录的终端设备，最终会通过IM即时通讯SDK向RocketMQ发送消息。

此时IM即时通讯SDK会根据目标用户ID和终端从分布式缓存中获取目标用户连接的IM即时通讯服务的ID，并向此ID相关的Topic发送消息。此时与目标用户建立长连接的IM即时通讯服务就会接收到RocketMQ中的消息，随后根据用户ID和终端从本地缓存中获取到与用户终端建立的长连接，并基于此长连接向用户推送消息。

另外，在实际实现中，为了避免大量用户同时只连接IM即时通讯服务集群中的某一个服务实例，会对用户连接的IP、浏览器指纹、手机设备等做Hash和取模运算，使其尽量均匀分布到集群中的每一个服务实例上。

那么问题来了，这种架构设计还有进一步优化的空间吗？

原文：http://www.52im.net/thread-4564-1-1.html / 来自：即时通讯网