系统架构设计的演进

一、传统架构
并发量越来越大的时候，需要增加Tomcat集群的节点数量（服务器数量先增加后下降），但一般节点数量为5个左右，难以实现高数据的并发
集群:多个服务器做同一件事情，运行同一个工程

二、分布式架构
高并发时，按照功能把系统拆分成独立的功能，多个子系统相互协作才能完成业务流程，降低了模块间的耦合度，增加了部署的灵活性，系统交互使用远程通信（接口通信）
远程通信举例：dubbo通信、Mycat数据库集群、redis缓存、solr维护索引库、MQ消息队列用于实现解耦

三、基于SOA的架构
SOA：service oriented architectune面向服务架构
为了解决分布式架构的缺点（系统间远程通信导致接口开发增加工作量，各模块间有些通用的业务逻辑无法使用）
把工程拆成【服务层、表现层】，其中服务层中包含业务逻辑，只需对外提供服务即可；表现层只需处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

四、架构演化（从上到下）

• 初期网站架构：
  All in one，一台服务器，搞定应用程序、文件、数据库...
  特点：开发快、部署简单、成本低；
  瓶颈：CPU / 内存 / IO / 磁盘争用，单点故障

• 应用和数据分离：
  随着访问和数据量增大（拆：应用服务器、文件服务器、数据库服务器），需要各资源独立伸缩，降低相互影响
  应用服务器（无状态，便于扩展）
  文件服务器（图片、附件等静态资源）
  数据库服务器（独立高IO负载）

• 缓存数据以改善性能：
  将查询较多或改动不大的数据缓存起来
  适用场景：读多写少的数据（用户会话、配置信息）、热点数据（商品详情、排行榜）
  注意：缓存穿透、雪崩、击穿、一致性。

• 应用集群+负载均衡：
  并发量大，利用负载均衡器分散访问流量
  目的：解决单应用实例的并发上限

• 数据库读写分离：
  单个数据库无法满足业务需求
  结构：一主多从（Master 写，Slave 读）
  好处：减轻主库压力，提升读并发。
  难点：主从延迟（短时数据不一致）、读写路由（应用层/中间件如 ShardingSphere、MyCat）

• 部署CDN节点：
  通过CDN技术，保证用户访问每次都从最近的服务器获取数据，加速静态资源
  内容：图片、CSS、JS、视频等
  原理：边缘节点缓存，用户就近访问。
  效果：大幅降低源站带宽和延迟，缓解应用压力。

• 分布式数据库（分库分表）：
  单表数据规模庞大时进行数据库拆分，通常只采用业务分库
  触发条件：单表数据量达千万/亿级，或单库写压力过大。
  策略：水平分表（按hash / range）、业务分库（不同业务表放不同库）
  复杂度：跨库join、分页、分布式事务（最终一致性）；全局唯一ID（雪花算法、号段模式）；

• 非关系型数据库：
  PB或更高量级时，关系型数据库成为了瓶颈
  定位：并非替代关系库，而是解决关系库不擅长的场景
  常见组合：
  HBase / Cassandra：海量写入，列式存储
  MongoDB：文档型，schema 灵活
  Elasticsearch：全文检索、日志分析

• 微服务架构：
  Spring Cloud微服务解决方案，将业务拆分成不同的产品线，各个产品间互相通信
  优点：独立开发、独立部署、异构技术栈
  代价：分布式事务（Seata / Saga）、服务治理、运维复杂度（容器化 + K8s）
  关键组件：
  服务注册与发现：Eureka / Nacos / Consul
  配置中心：Spring Cloud Config / Nacos
  API 网关：Gateway / Zuul
  服务间通信：OpenFeign + Ribbon / Spring Cloud LoadBalancer
  熔断限流：Resilience4j / Sentinel
  链路追踪：Sleuth + Zipkin / SkyWalking

• 一句话总结架构演进的本质：每个阶段解决前一阶段的瓶颈，同时引入新的复杂性
  
  日志与监控通常会在“应用集群 → 微服务”之间自然催生：
  集中日志：ELK / Loki
  指标监控：Prometheus + Grafana
  告警：Alertmanager