2025年12月25日Evgeny · 高级系统工程师
高负载架构：如何构建不崩溃的系统
您的系统承载 100 个用户。明天媒体报道 — 来了 10 万人。大多数项目失败不是因为想法差，而是架构没有安全余量。高负载不是「百万美元的服务器」 — 而是各层互相卸力的设计。
垂直扩展 vs 水平扩展
Scale Up — 买更强的机器。Scale Out — 增加节点。实践中水平扩展更优：一个实例挂了 — 其余承接流量。前提：应用无状态，会话与缓存在外部 Redis，而非进程内存。
典型拓扑
客户端 → CDN → 负载均衡器
├── App #1 → Redis → PostgreSQL (master)
├── App #2 → Redis → PostgreSQL (replica)
└── App #3 → Kafka / RabbitMQ → workers
关键模式
- 负载均衡： Nginx、HAProxy、云 ALB — 轮询或最少连接。
- 数据库复制： 写主库，读从库（通常 80% 流量是 SELECT）。
- 缓存： Redis/Memcached 用于目录、资料、聚合 — cache-aside。
- 队列： 重任务（报表、邮件、图片缩放）— 进 Kafka/RabbitMQ，立即响应用户。
- 分片： 单库不够时 — 按键切分（区域、tenant_id）。
单体 vs 微服务
单体在起步阶段很方便。问题出现在：部署要几小时、一个模块拖垮支付、为单一功能却要扩展整台服务器。
微服务带来隔离与独立部署，但需要 API Gateway、可观测性、Kubernetes 与数据纪律（每服务独立库）。过早微服务化扼杀的公司，比峰值流量还多。
NineLab 原则： 从单体起步，按模块边界设计，以便日后拆分服务而无需「大爆炸」。详见何时真正需要微服务。
如何在峰值前验证
纸面架构扛不住成功广告带来的 DDoS。需要按真实用户路径设计负载场景 — 购物车、搜索、支付 API。参见如何进行压力测试与交钥匙负载测试服务。
结论： 高负载 = 负载均衡器、无状态代码、缓存、队列、无单点故障的数据库。百万 RPS 的系统如此支撑 — 我们亦如此为 B2B 与工业客户设计交钥匙高负载方案。
关于高负载架构的常见问题
无状态应用、热数据缓存、p95 监控与负载测试计划。 微服务与分片 — 仅在可量化的痛点出现时采用，而非「为未来预留」。
当单个 PostgreSQL/MySQL 实例在只读复制下仍触及磁盘与 CPU 上限， 且查询优化与缓存已用尽时。在此之前，复制与分区通常足够。
单体 + 水平扩展是合理的起点。微服务在团队独立、模块负载特征不同、 DevOps 成熟时才划算。
按真实用户路径设计负载场景，而非只测首页。k6/Locust + RED 指标； 必要时 — 由工程师做审计。
