# 《分布式IM系统》总体架构-第01节：分布式IM即时通讯系统总体方案目标与架构设计
作者：冰河
星球：http://m6z.cn/6aeFbs (opens new window)
博客：https://binghe.gitcode.host (opens new window)
文章汇总：https://binghe.gitcode.host/md/all/all.html (opens new window)
源码获取地址：https://t.zsxq.com/0dhvFs5oR (opens new window)
课程视频：https://t.zsxq.com/144pEihGb (opens new window)
沉淀，成长，突破，帮助他人，成就自我。
- 本节难度：★★★☆☆
- 本节重点：梳理分布式IM即时通讯系统的总体方案目标、技术选型与架构设计，从总体上理解分布式IM即时通讯系统的方案目标、技术选型和架构设计，并从全局视角了解分布式IM即时通讯系统的分层设计和架构思想，并能够将其灵活应用到自身实际项目中。
- 课程视频：https://t.zsxq.com/144pEihGb (opens new window)
大家好，我是冰河~~
在前面的文章中，我们梳理了分布式IM即时通讯系统的需求和业务流程，并且对分布式IM即时通讯系统的技术流程进行了梳理和总结。所以，不管是从业务角度，还是从技术角度，我们都大致了解了分布式IM即时通讯系统的执行流程。接下来，就可以对分布式IM即时通讯系统制定方案目标和进行总体架构设计了。
# 一、前言
相信很多有一定工作经验的小伙伴都有这样的体会，接到新的任务后，如果不做全面的需求分析、系统分析和架构设计，一上来就开始干代码，十有八九会在开发中途发现自己写的代码功能不太符合实际需求，或者突然发现某个功能有更好的实现方式，只是自己一开始没完全搞懂需求，根本没想到会有更好的实现方式。
更多的时候，想将原有的代码推倒重来，按照更优的方案来完成相应的需求任务开发，但是，此时发现时间根本来不及了，只能在原有的代码上苦苦支撑。最终，原本设想的功能完善、支持高并发、高性能、高可用和高可扩展的代码，却变成了一坨坨“屎山”。
# 二、本章诉求
作为系统架构师和研发人员，在充分了解系统需求，业务流程和技术流程后，就需要需要为系统设定方案目标，对技术方案进行选型，对系统进行总体架构设计和分层架构设计。从全局视角充分理解分布式IM即时通讯系统的方案目标、技术选型、总体架构和分层架构，以指导后续分布式IM即时通讯系统的具体实现。
# 三、方案目标
在进行技术选型与总体架构设计之前，需要明确一个事项，就是系统无论采用哪种方案，采用哪种架构设计都需要明确这种方案的业务目标、技术目标和架构目标，并在研发过程中不断评估系统的总体性能表现，发现系统瓶颈并不断进行优化。
总体上，我们搭建和开发的分布式IM即时通讯系统，需要满足如下方案目标。
- 业务目标：满足需求设计篇章中的各类需求场景。
- 技术目标：发送消息接口：1W+TPS，好友列表，群列表，会话列表、群成员：5W+QPS，支持5W+用户同时在线。
- 架构目标：高并发、高性能、高可用、可监控、可预警、可伸缩。
# 四、技术选型
在技术选型上，除了采用SpringBoot等基础框架外，也会采用容器化方案。同时，考虑到为了尽量降低技术门槛，在整个分布式IM即时通讯系统的技术选型中，主要采用市面上比较流行的技术框架和方案，具体选型如下所示。
- 开发框架：SpringBoot、SpringCloud、SpringCloud Alibaba、Dubbo。
- 缓存：Redis分布式缓存+Guava本地缓存。
- 数据库：MySQL、TiDB、HBase。
- 流量网关：OpenResty+Lua。
- 业务网关：SpringCloud Gateway + Sentinel。
- 持久层框架：MyBatis、Mybatis-Plus。
- 服务配置、服务注册与发现：Nacos。
- 消息中间件：RocketMQ。
- 网络通信：Netty。
- 文件存储：Minio。
- 日志可视化治理：ELK。
- 容器化管理：Swarm、Portainer。
- 监控：Prometheus、Grafana。
- 前端：Vue。
- 单元测试：Junit。
- 基准测试：JMH。
- 压力测试：JMeter。
# 五、系统初步架构设计
对于IM即时通讯系统来说，结合我们前面在需求设计篇章中梳理的功能需求，业务流程和技术流程，我相信不少小伙伴多多少少能够画出IM即时通讯系统的架构图，大致如图1-1所示。
其实，这种这种架构设计也比较常见，在这种架构设计中，Kong/Openresty/Nginx只做负载均衡和反向代理，研发人员更多的是关业务层和基础层的开发，流量比较小时，这种架构设计一般不会有什么问题。但是一旦流量比较大时，用户调用后端平台的接口发送消息时，即时通讯SDK同步调用即时通讯服务的接口就会出现性能问题。
因为在前面的文章中，我们已经分析了每个用户同时只能与一个IM即时通讯服务实例建立连接，如果大量的用户终端恰好都与一个IM即时通讯服务建立连接，那即时通讯SDK频繁同步调用同一个IM即时通讯服务的接口就会出现性能瓶颈。此时，出现性能瓶颈时，不仅仅会影响到IM即时通讯服务，也会对后端平台接收请求的业务造成一定的影响。
# 六、系统架构设计优化
既然图1-1所示的架构设计存在性能瓶颈，那我们如何进行优化呢？为此我们在如1-1的基础上进行了优化，优化后的架构如图1-2所示。
# 查看完整文章
加入冰河技术 (opens new window)知识星球，解锁完整技术文章、小册、视频与完整代码
