【架构设计】互联网架构项目架构演进以及三高设计概述

news2024/11/18 10:46:39

（1）单体应用架构（1千UV以下）

在这里插入图片描述

优点：易于测试，便于集成，对小型项目友好。

缺点：启动时间长，依赖庞大，单机性能瓶颈明显，资源容易出现争夺。

（2）应用数据分离架构（5千UV）

在这里插入图片描述

优点：易于测试，便于集成，对小型项目友好。

缺点：启动时间长，依赖庞大，单机性能瓶颈明显，资源容易出现争夺。

（3）应用集群架构（1万UV）

在这里插入图片描述

优点：避免应用程序单点故障，提高应用处理能力。

缺点：链路存在单点故障-网关-数据库，单机性能瓶颈明显。

（4）应用集群缓存架构（5万UV）

在这里插入图片描述

优点：热点数据缓存，提高性能。

缺点：增加维护成本，包括缓存穿透/击穿/雪崩等问题。

（5）应用集群+读写分离架构（10万UV）

在这里插入图片描述

优点：读写分离，提高数据库性能和可用性。

缺点：增加维护成本，数据量激增单库容易瓶颈。

（6）微服务化-分库分表架构（100万UV）

在这里插入图片描述

优点：易开发、理解和维护独立的部署和启动，数据库性能提升。

缺点：分布式系统-分布式事务问题，管理多个微服务，服务治理问题。

（7）多元化业务-数据异构架构（500万UV）

在这里插入图片描述

优点：数据源多样化，业务性能提升明显，系统复用性高，支撑更高并发+海量数据。

缺点：运维复杂增高，链路分析复杂和技术广度+深度大。

在这里插入图片描述

（1）什么是高并发？

（2）什么是高可用？

（3）什么是高性能？

（4）如何做到高并发-高性能技术？

系统架构
- 无状态业务-水平扩展（Scale Out），只要增加服务器数量，就能线性扩充系统性能
- 架构的难点是难做到全链路的水平扩展
【负载均衡】思想
- 节点轮询、随机、加权轮询、节点固定hash
  - 网络 DNS解析轮询
  - 网关分发请求后端服务
  - 应用服务内部RPC负载均衡
  - 数据存储-分库分表-负载分发
【缓存】思想
- 本地缓存/分布式缓存
  - 前端浏览器缓存静态资源
  - 网络DNS解析缓存
  - 应用程序内存缓存/分布式缓存
  - 数据存储Mysql Query Cache
【池化复用】思想
- 线程池/对象池/连接池/内存池
  - java线程池技术
  - Jdbc/Redis/HttpClient连接池
  - SpringIOC容器对象池
【异步】思想
- 多线程/消息队列
  - 前端ajax异步请求
  - RocketMQ/Kafka 同步双写-异步刷盘
  - 应用程序多线程异步处理
【预处理-惰性更新】思想
- 定时任务/懒加载
  - 运营后台报表数据，定时任务提前计算好
  - Mybatis懒加载
【分而治之】思想
- Mater-worker
  - Hadoop中的MapReduce
  - JDK. Fork/Join Framework
  - 消息队列的广播消息
  - 归并排序算法

（4）如何做到高可用技术？

（冗余集群化 + 自动故障转移failover)

集群架构
- 将多个相同的应用程序集中起来提供同一种服务，某个节点故障不影响系统
- 可以横向扩展性增加节点提高并发处理能力
  - 微服务集群
  - Redis集群/Kafka集群/Nginx集群
  - Nacos集群/Mysql集群/ZK集群
熔断降级
- 保险丝，熔断服务，为了防止整个系统故障，抛弃一些非核心的接口和数据，返回兜底数据
限流
- 当访问频率或者并发请求超过其承受范围的时候，考虑限流来保证接口的可用性
- 漏斗模型，不管流量多大均匀的流入容器，令牌桶算法，漏桶算法
隔离
- 服务和资源互相隔离，比如网络资源，机器资源，线程资源等，不会因为某个服务的资源不足而抢占其他服务的资源
多活架构
- 同城双活-双机房
  - 两个机房部署在同城，物理距离较近，两个机房用「专线」网络连接，比单个机房内延迟要大一些，但整体的延迟是可以接受的
- 参考
  - 同机房：0.1ms
  - 同城双机房：1ms（100公里内）
  - 北京到广州：55ms
异地多活-两地三中心
- 两地是指 2 个城市，三中心是指有 3 个机房，其中 2 个机房在同一个城市
- 同时提供服务，第 3 个机房部署在异地，只做数据灾备