本文为冰河《分布式IM系统》的学习笔记，非本人创作

项目地址：binghe.gitcode.host/md/all/all.…

方案目标当然是与架构设计密切关联的，你要做一款什么样的产品，承载多大的流量，都直接决定了如何进行技术选型

而问题的解决最终还是在技术选型，你怎么保证你选的就是最合适的呢？你的判断是否会有误？或者是否有更优的选择而你不知道呢？

这部分的内容可能只能留给以后的自己了，增强知识的广度的同时，还要不断追问：「为什么？」

引用一段大佬的话吧：

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

我的评价是：一个字都不敢改

来看方案目标：

• 业务目标：满足前面章节中各类需求场景

• 技术目标：

  • 即时通讯服务：1W+TPS
  • 后端平台服务：5W+TPS
  • 同时在线：5W+

• 架构目标：高并发、高性能、高可用、可监控、可预警、可伸缩

技术选型

💡 照搬了，但是以后的自己，希望你能自己选出来

• 开发框架：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 即时通讯服务上，SDK 对其频繁调用，就会出现瓶颈

💡 为什么会这样呢？是负载均衡没有做好吗

改进架构设计

改进方案如下：

差别显而易见，在入口处，加上了限流、黑白名单、流量控制和业务校验

后面把对应的代码中的模块贴进来

同时对业务进一步的保护，加入限流、降级、熔断、流控、校验、鉴权等功能来保证下游稳定

同上

容器化架构设计

（怎么还能改进…）增加的能力都在右边了

救救孩子吧，学不完了

DDD分层

代码架构按照 DDD 来分层，seckill 项目有，去学吧