互联网工程通常 是如何做到弹性扩缩容的 这套散布式IM即时通讯系统

散布式IM即时通讯系统实质上就是对线上聊天和用户的控制，针对聊天自身来说，最外围的需求就是：发送文字、图片、文件、语音、视频、信息缓存、信息存储、信息未读、已读、撤回，离线信息、历史信息、单聊、群聊，多端同步，以及其余一些需求。

对用户控制来说，存在的需求蕴含：参与好友、检查好友列表、删除好友、检查好友信息、创立群聊、参与群聊、检查群成员信息、分开群聊、修正群昵称、拉人进群、踢人出群、遣散群聊、填写群通告、修正群备注以及其余用户相关的需求等。

一、前言

为了能够让小同伴们更好的理遣散布式IM即时通讯系统的设计，咱们站在架构师的角度，在充沛了解系统需求，业务流程和技术流程后，从全局视角为系统设定打算指标，对技术打算启动选型，对系统启动总体架构设计和分层架构设计，并梳理分明发送信息的交互链路、单聊和群聊的交互链路。以繁难各位小同伴将散布式IM即时通讯系统写到自己的简历中，增强自己的竞争力。

二、打算指标

在启动技术选型与总体架构设计之前，须要明白一个事项，就是系统无论驳回哪种打算，驳回哪种架构设计都须要明白这种打算的业务指标、技术指标和架构指标，并在研发环节中始终评价系统的总体性能体现，发现系统瓶颈并始终启动提升。

总体上，咱们搭建和开发的散布式IM即时通讯系统，须要满足如下打算指标。

三、技术选型

在技术选型上，除了驳回SpringBoot等基础框架外，也会驳回容器化打算。同时，思考到为了尽量降落技术门槛，在整个散布式IM即时通讯系统的技术选型中，重要驳回市面上比拟盛行的技术框架和打算，详细选型如下所示。

四、系统初步架构设计

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

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

由于每个终端同时只能与一个IM即时通讯服务虚例树立衔接，假设少量的用户终端恰恰都与一个IM即时通讯服务树立衔接，那即时通讯SDK频繁同步伐用同一个IM即时通讯服务的接口就会产生性能瓶颈。此时，产生性能瓶颈时，不只仅会影响到IM即时通讯服务，也会对后端平台接纳恳求的业务形成肯定的影响。

五、系统架构设计提升

既然图1-1所示的架构设计存在性能瓶颈，那咱们如何启动提升呢？为此咱们在如1-1的基础上启动了提升，提升后的架构如图1-2所示。

对比图1-1和图1-2可以看出，在屏蔽掉技术成功细节的前提下，咱们将对业务的校验和流量管控启动前置化，加大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和取模运算，使其尽量平均散布到集群中的每一个服务虚例上。

那么疑问来了：这种架构设计还有进一步提升的空间吗？

六、容器化架构设计

为进一步增强散布式IM即时通讯系统的性能、可用性和弹性伸缩才干，咱们可以对散布式IM即时通讯系统启动容器化架构设计，如图1-3所示。

可以看到，咱们对散布式IM即时通讯系统的架构设计启动了进一步提升，驳回了容器化架构设计。在原有架构的基础上，咱们启动了如下改良和提升。

（1）基础撑持服务

基础撑持服务会由各种基础两边件、数据存储服务、以及监控服务虚现，蕴含：MySQL数据库、TiDB数据库、HBase、Redis缓存、RocketMQ信息队列、Prometheus监控和Portainer容器控制等基础两边件成功，基础撑持服务会对整个散布式IM即时通讯系统提供最基础的数据、传输、监控和容器控制等服务。

（2）容器化

在容器化层面，会经过Docker、Swarm和Portainer成功，其中，会基于Swarm和Portainer对容器化启动控制。

（3）其余基础性性能成功

除了上述分层架构外，关于树立散布式IM即时通讯系统来说，还要思考意外监控、服务注册与发现、可视化、服务升级与兜底数据、服务限流、服务容灾、容量规划与扩缩容和全链路压测等。

七、DDD分层业务架构设计

在散布式IM即时通讯系统中，不论是大后端平台，还是IM即时通讯服务，咱们都会对业务层的代码驳回分层业务架构，这里，可以自创DDD的分层架构思维，将代码总体上分红展现层、运行层、畛域层和基础设备层四个档次，但是，思考到散布式IM即时通讯系统的不凡性，又不会严厉依照DDD的准则来设计代码分层，详细依照如图1-4所示。

可以看到，散布式IM即时通讯系统会自创DDD的设计思维，但是不会齐全依照DDD的形式启动设计。

（1）展现层

展现层，也叫做用户UI层，是DDD设计的最下层，对外提供API接口，接纳客户端恳求，解析参数，前往结果数据，并对意外启动处置。

（2）运行层

运行层，也叫做Application层，运行层重要处置容易变动的业务场景，可对相关的事情、调度和其余聚合操作启动相关的处置。

（3）畛域层

畛域层，也叫做Domain层，畛域层可以说是DDD设计的精髓所在，它是将业务系统中相对不变的局部形象进去封装成畛域模型。

在散布式IM即时通讯系统的设计中，畛域层基本不会依赖其余层，也不会依赖基础设备层，这里是与DDD设计存在区别的中央。

（4）基础设备层

基础设备层，也叫做Infrastructure层，基础设备层会对其余各层提供通用的基础才干，在散布式IM即时通讯系统中，就包括了缓存、通用工具类、信息、系统的耐久化机制等。

八、发送信息交互链路

在散布式IM即时通讯系统中，咱们疏忽掉其余一些细节信息，重点关注下发送信息的交互链路逻辑。不论是单聊还是群聊，最终都须要经过IM即时通讯服务将信息推送给用户的终端。此时发送信息的流程如图1-5所示。

可以看到，用户在散布式IM即时通讯系统发送信息时，不论是单聊还是群聊，最终的信息都会推送到用户登录的终端设备上。假定此时用户A给用户B发送信息，或许用户A和用户B在同一个群组，用户A向群组发送信息，用户B接纳信息的重要流程如下。

（1）用户A调用后端平台的接口向用户B发送信息，并且发送的信息中会带有用户B的ID以及终端信息。

（2）后端平台将信息缓存起来，并且会将信息异步写入信息库。

（3）后端平台从Redis中失掉用户B衔接的IM即时通讯服务的ID。

（4）后端平台失掉到用户B衔接的IM即时通讯服务的ID后，会向RocketMQ中用户B衔接的IM即时通讯服务ID对应的Topic发送信息。

（5）IM即时通讯服务会监听自身服务ID对应的RocketMQ中Topic的信息，此时，用户B衔接的IM即时通讯服务会接纳到信息。

（6）IM即时通讯服务接纳到信息后，会依据用户B的ID以及终端信息从缓存中失掉用户B与IM即时通讯服务树立的衔接，并且经过这个衔接向用户B推送信息。

要成功如上发送信息的流程，前提是要满足如下条件。

（1）后端平台满足散布式条件，可随时横向裁减。

（2）IM即时通讯服务满足散布式条件，可随时横向裁减。

（3）每个启动的IM即时通讯服务虚例在集群中都有一个惟一的ID。

（4）每个IM即时通讯服务，都只监听自身ID对应的RocketMQ中Topic的信息。

（4）用户登录散布式IM即时通讯系统后，会与IM即时通讯服务树立长衔接，并且会依据用户ID和所在的终端缓存长衔接，同时会依据用户ID和所在的终端将衔接的IM即时通讯服务的ID缓存到Redis。

（6）用户发送信息时，会依据指标用户的ID和终端从Redis中失掉IM即时通讯服务的ID，进而向IM即时通讯服务的ID对应的RocketMQ的Topic发送信息。

（7）对应的IM即时通讯服务监听并接纳到RocketMQ信息后，会依据指标用户的ID和终端从缓存中失掉到用户的衔接信息，向指标用户推送信息。

九、单聊交互链路

单聊就是在散布式IM即时通讯系统中，一个用户间接与另外一个用户聊天，也就是一对一的聊天。在这种场景下，很有或许单聊的两个用户中，产生用户不在线的状况。

例如，用户A给用户B发送信息时，用户B或许不在线。此时，咱们就须要将用户A向用户B发送的信息存储起来。其实，在咱们成功的散布式IM即时通讯系统中，无论把用户B能否在线，都会存储信息记载。当用户B登录系统后，将信息同步给用户B，如图1-6所示。

可以看到，用户A向用户B发送信息时，假设用户B在线，就可以依照发送信息的交互链路向用户B发送信息了。假设用户B不在线，此时就不可向用户B反常推送信息。当用户B登录散布式IM即时通讯系统后，就会调用后端平台的接口拉取一切未读信息，并经过用户B在线流程向用户B推送信息。

十、群聊交互链路

群聊就是在散布式IM即时通讯系统中，多个用户在同一个群组中启动聊天，此时在发送信息时，咱们可以经过群组ID找出群内一切在线的用户，将信息即时发送给在线的用户。那些未在线的用户就依照单聊未在线的用户启动处置，如图1-7所示。

可以看到，群聊的交互链路流程如下所示。

（1）用户调用后端平台的接口向群组发送信息。

（2）后端平台将信息缓存并异步写入信息库。

（3）由于是向群组发送信息，群里有多个用户，此时就会从Redis中失掉一切用户衔接的IM即时通讯服务ID列表。

（4）对用户依照服务ID分组，将相反服务ID下的用户分在同一个逻辑分组里，繁难后续推送信息，并且会记载未在线的用户列表。

（5）循环向每个服务ID对应的RocketMQ中的Topic发送信息。

（6）广播处置未在线用户的未读信息ID。

（7）IM即时通讯服务会监听自身服务ID对应的Topic，会随时接纳推送到自身服务的信息。

（8）当IM即时通讯服务接纳到信息后，此时用户掉线，或许用户不在线，向用户推送信息就会失败，或许未查问到用户与IM即时通讯服务树立的衔接，就不会向用户推送信息。

（9）当用户登录散布式IM即时通讯系统后，会从后端平台拉取历史（离线）信息，并经过用户在线的流程，向用户推送信息。