一、系统架构演进路径

1.1 单机单体架构（日请求<10万）

在业务发展初期，系统通常采用All-in-One架构设计。典型技术栈包含：

Web层：Nginx+PHP/Java单体应用
数据层：MySQL单库单表
缓存层：本地缓存（如Caffeine）
存储层：本地磁盘存储

该架构的优势在于开发效率高、部署简单，但存在明显瓶颈：

垂直扩展极限：单机CPU/内存/网络带宽存在物理上限
单点故障风险：任何组件故障都将导致全站不可用
资源利用率低：不同业务模块对计算/存储/IO需求不均衡

1.2 垂直拆分阶段（日请求10万-100万）

当QPS突破500时，系统开始出现性能瓶颈，此时需进行垂直拆分：

1.2.1 应用层拆分

按照业务领域划分独立服务，例如：

原始单体应用
├─ 用户服务
├─ 订单服务
├─ 支付服务
└─ 商品服务

每个服务拥有独立的进程空间和资源配额，通过RPC框架（如gRPC）进行通信。拆分后需重点解决：

服务发现：使用Zookeeper/Consul实现动态注册
负载均衡：基于Nginx或LVS实现流量分发
链路追踪：通过SkyWalking实现全链路监控

1.2.2 数据层拆分

采用主从复制+读写分离架构：

主库（写） → 从库1（读）
           → 从库2（读）

配置要点：

主从延迟监控：设置slave_net_timeout参数
读写分离策略：使用ProxySQL实现自动路由
故障转移方案：配置MHA（Master High Availability）

1.3 水平扩展阶段（日请求100万-1000万）

当QPS突破5000时，需通过水平扩展提升系统容量：

1.3.1 分布式服务架构

采用微服务架构设计，关键组件包括：

API网关：统一流量入口，实现限流、鉴权、路由
服务注册中心：维护服务实例元数据
配置中心：集中管理动态配置
分布式事务：采用SAGA模式或TCC模式

1.3.2 分布式缓存体系

构建多级缓存架构：

客户端缓存 → CDN缓存 → Redis集群 → 本地缓存

Redis集群配置建议：

集群规模：至少3主3从
分片策略：采用Hash Tag保证相关数据同槽
持久化：RDB+AOF混合模式
故障处理：设置cluster-require-full-coverage为no

1.3.3 分布式存储方案

对象存储+数据库分库分表组合方案：

冷数据：使用对象存储（如MinIO）
热数据：采用ShardingSphere进行分库分表
搜索需求：集成Elasticsearch实现复杂查询

分库分表策略选择：

// 水平分表示例（基于用户ID取模）
public class ShardingAlgorithm implements PreciseShardingAlgorithm<Long> {
    @Override
    public String doSharding(Collection<String> tableNames, PreciseShardingValue<Long> shardingValue) {
        long userId = shardingValue.getValue();
        int tableIndex = (int)(userId % tableNames.size());
        return "t_order_" + tableIndex;
    }
}

二、关键技术组件选型

2.1 消息队列选型

在千万级流量系统中，消息队列需满足：

高吞吐：单队列百万级TPS
低延迟：P99延迟<10ms
持久化：消息不丢失

主流方案对比：
| 特性 | Kafka | RocketMQ | RabbitMQ |
|——————|——————————-|——————————|—————————|
| 吞吐量 | 百万级 | 十万级 | 万级 |
| 延迟 | 5-10ms | 2-5ms | 0.1-1ms |
| 持久化 | 磁盘+内存 | 磁盘+内存 | 磁盘 |
| 适用场景 | 日志处理、流计算 | 金融交易、订单系统 | 轻量级消息通知 |

2.2 数据库优化方案

针对MySQL的优化措施：

连接池配置：HikariCP最佳实践

# HikariCP配置示例
spring.datasource.hikari.maximum-pool-size=20
spring.datasource.hikari.connection-timeout=30000
spring.datasource.hikari.idle-timeout=600000

SQL优化：使用EXPLAIN分析执行计划
索引策略：避免过度索引，定期分析无用索引
慢查询治理：设置long_query_time=1s，启用慢查询日志

2.3 容器化部署方案

采用Kubernetes实现弹性伸缩：

# HPA配置示例
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

三、容量规划与压测策略

3.1 容量评估模型

建立四维评估体系：

QPS计算：日活用户数 × 人均请求数 × 峰值系数
存储需求：单用户数据量 × 用户增长预测 × 冗余系数
网络带宽：平均请求大小 × QPS × 8 / 1024 / 1024 (Mbps)
连接数：并发用户数 × 平均连接数

3.2 全链路压测方案

实施步骤：

影子表构建：创建与生产环境结构相同的测试表
流量录制：使用GoReplay捕获真实流量
压测执行：逐步加压至预期流量的120%
性能分析：通过Prometheus+Grafana监控关键指标

关键监控指标：

系统层：CPU使用率、内存占用、磁盘IO
应用层：GC频率、线程池状态、连接数
网络层：TCP重传率、RTT延迟
业务层：成功率、响应时间、错误码分布

四、高可用保障体系

4.1 故障隔离设计

实施三层隔离策略：

进程级隔离：通过Pod资源限制防止单个容器资源耗尽
主机级隔离：使用cgroups限制CPU/内存使用
可用区隔离：跨AZ部署避免单点故障

4.2 熔断降级方案

采用Sentinel实现流量控制：

// 资源定义示例
Entry entry = null;
try {
    entry = SphU.entry("orderService");
    // 业务逻辑处理
} catch (BlockException e) {
    // 降级处理逻辑
} finally {
    if (entry != null) {
        entry.exit();
    }
}

4.3 灾备演练机制

建立三级演练体系：

单元测试：模拟单个服务故障
区域测试：模拟整个AZ故障
全站测试：模拟数据中心级故障

演练评估标准：

RTO（恢复时间目标）：<30秒
RPO（恢复点目标）：=0
业务影响范围：<5%

五、持续优化体系

建立PDCA优化循环：

Plan：制定性能优化目标（如P99延迟降低20%）
Do：实施优化措施（如缓存预热、连接池调优）
Check：通过压测验证优化效果
Act：将有效措施纳入基线配置

优化工具链：

性能分析：Arthas、JProfiler
链路追踪：SkyWalking、Zipkin
日志分析：ELK Stack
监控告警：Prometheus+Alertmanager

通过上述系统化的架构设计、技术选型和优化策略，可构建出具备千万级流量承载能力的高可用系统。实际实施时需结合业务特点进行针对性调整，并通过持续压测和优化不断提升系统容量上限。

如何构建支撑千万级流量的高可用系统架构