一、系统演进阶段与核心挑战

当系统日请求量从10万级跃升至千万级时，架构设计需经历三个关键阶段：单机架构、垂直拆分、分布式集群。每个阶段的核心矛盾与解决方案截然不同：

1. 单机架构阶段（<10万请求/日）

2. 垂直拆分阶段（10万-100万请求/日）
当单机性能达到极限时，垂直拆分成为必然选择。其核心逻辑是将单体应用按业务维度拆分为多个子系统：

拆分维度：
- 业务边界：用户中心、订单系统、支付系统等
- 数据特性：读写比例（如商品库读多写少可单独部署）
- 访问频次：高频服务（如API网关）与低频服务分离
技术实现：
- 服务隔离：通过Nginx反向代理实现流量分发
- 数据分库：按业务拆分MySQL实例（如用户库、订单库）
- 独立部署：每个子系统拥有独立服务器资源

典型架构：

graph TD
  A[客户端] --> B[Nginx负载均衡]
  B --> C[用户服务]
  B --> D[商品服务]
  B --> E[订单服务]
  C --> F[用户数据库]
  D --> G[商品数据库]
  E --> H[订单数据库]

二、分布式集群阶段（百万级以上请求）

当垂直拆分后的系统仍无法满足需求时，需进入分布式集群阶段。此阶段的核心挑战在于：

1. 水平扩展能力

无状态服务设计：
- 关键原则：服务实例不存储会话状态
- 实现方式：通过JWT/Session共享实现状态外置
- 优势：可随时增减实例应对流量波动
负载均衡策略：
- 四层负载：LVS/HAProxy基于IP哈希
- 七层负载：Nginx基于URI的轮询算法
- 智能调度：根据服务器负载动态调整权重
案例：某视频平台通过动态权重算法，在促销期间将流量倾斜至新服务器，提升30%处理能力

2. 数据分片与读写分离

数据库分片方案：
- 水平分片：按用户ID哈希分1024库（如用户ID%1024）
- 垂直分片：大表拆分为基础表+扩展表
- 分布式中间件：使用ShardingSphere等实现透明分片
读写分离实践：
- 主从架构：1主多从，写主读从
- 异步复制：牺牲少量一致性换取性能提升
- 强制路由：通过Hint管理器指定读写实例
性能对比：
| 方案 | 写入TPS | 读取TPS | 一致性 |
|——————|————-|————-|————|
| 单机MySQL | 5000 | 20000 | 强 |
| 读写分离 | 5000 | 80000 | 最终 |
| 分库分表 | 20000 | 500000 | 最终 |

3. 异步化与消息队列

典型场景：
- 订单创建后通知库存系统
- 日志收集与实时分析
- 耗时操作（如图片压缩）异步处理
消息队列选型：
- Kafka：高吞吐、持久化，适合大数据场景
- RabbitMQ：轻量级、灵活路由，适合微服务
- RocketMQ：金融级可靠性，适合交易系统
避坑指南：
- 避免消息堆积：设置合理的消费者数量
- 防止重复消费：实现幂等性处理
- 监控消息延迟：设置告警阈值（如>100ms）

千万级流量系统必须建立完善的高可用机制：

1. 容灾设计

2. 限流降级

3. 监控告警

千万级流量系统设计是持续演进的过程，需要结合业务特性选择合适的技术方案。建议从垂直拆分入手，逐步引入分布式组件，最终构建具备弹性扩展能力的高可用架构。在实际实施过程中，应重点关注数据一致性、服务治理和运维自动化等关键环节，确保系统在流量激增时仍能保持稳定运行。