散布式IM即时通讯系统实质上就是对线上聊天和用户的控制，针对聊天自身来说，最**的需求就是：发送文字、表情、图片、文件、语音、视频、信息缓存、信息存储、信息未读、已读、撤回，离线信息、历史信息、单聊、群聊，多端同步，对接OpenAI大模型，以及其余一些需求。
对用户控制来说，存在的需求蕴含：减少朋友、检查还有列表、删除朋友、检查朋友信息、创立群聊、参与群聊、检查群成员信息、@群成员、分开群聊、修正群昵称、拉人进群、踢人出群、遣散群聊、填写群通告、修正群备注以及其余用户关系的需求等。
注：拿小本子记载下，后续可以写到简历上的整合了OpenAI大模型的散布式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即时通讯系统的性能、可用性和弹性伸缩才干，咱们可以对散布式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即时通讯系统后，会从后端平台拉取历史（离线）信息，并经过用户在线的流程，向用户推送信息。
好了，看到这里，你明白如何设计一个高度可裁减的散布式IM即时通讯系统了吗？连忙拿本子记载下你学到的常识，将其整顿到简历上吧！
十一、如何写简历形容
大局部简历上都会有名目形容局部，也就是要求写你所阅历的名目，关于某个详细的名目来说，普通可以从名目形容、所经常使用的技术以及你在名目中的职责三个方面启动引见。