文章 07
扩展前先找瓶颈：缓存、队列、CDN 与实例何时有效
沿请求路径从浏览器追踪到数据库与外部服务，修复真正受限的层，而不是猜测性加资源。
15 分钟 Tech Lead、后端、DevOps 与平台团队 2026-07-17
概览信息图
用户
CDN
API
数据库
Trace ID: 8f2a... Query wait 620ms
示例场景
从系统使用者开始
增加应用服务器后系统仍然缓慢
团队因应用 CPU 高而增加实例，但所有请求都在等待同一条无索引查询且连接池已满。扩展错误的层增加了成本，却没有改善响应时间。
面向业务与一般用户的摘要
扩展前先找瓶颈：缓存、队列、CDN 与实例何时有效
01
从追踪与指标开始，而不是先选技术。
02
缓存、队列、CDN 与水平扩展解决不同问题。
03
每项优化都需要前后证据与依赖失败时的降级方案。
动态扩展说明
深入阅读前，先了解各阶段如何连接
选择阶段，查看发生了什么、需要检查哪些证据，以及一个决策如何影响下一阶段。
步骤 01 / 03
01 / 请求路径
按层拆分时间
从 DNS/CDN、网络、Web/App、API、缓存、数据库与外部服务开始。用 trace ID 连接同一请求的日志与指标，定位等待位置。仅看总体 CPU 不够。
需要检查的证据
- 浏览器与网络时间
- 按端点 API 时长
- 数据库查询与锁
- 缓存命中/未命中
深入说明
逐项说明如何应用于真实场景
每一部分都连接业务影响与 Tech Lead 需要检查的内容，包括示例、证据与限制。
01 / 请求路径
01按层拆分时间
从 DNS/CDN、网络、Web/App、API、缓存、数据库与外部服务开始。用 trace ID 连接同一请求的日志与指标，定位等待位置。仅看总体 CPU 不够。
- 浏览器与网络时间
- 按端点 API 时长
- 数据库查询与锁
- 缓存命中/未命中
- 队列深度与等待时间
- 外部 API 超时/错误
02 / 选择合适模式
02每种技术以不同方式转移或分担负载
CDN 缩短静态内容交付，缓存减少重复计算，队列把非即时任务移出请求路径，更多实例分担无状态工作。它们不会自动修复错误查询、锁、慢依赖或不合适的数据模型。
03 / 故障路径
03良好扩展必须考虑组件故障
定义超时、重试上限、幂等、限流与优雅降级，避免一个依赖触发全系统重试风暴。队列需死信处理，缓存需明确失效与回退。
面向 Tech Lead 的详情
仅对安全操作使用指数退避与抖动重试；创建数据的交易需要幂等键。
行动前检查清单
01
使用请求追踪
02
分层采集指标
03
用证据确认瓶颈
04
定义前后对比
05
设计超时/重试
06
测试依赖故障
参考资料
数字与示例用于建立讨论框架，决策前应以真实系统及其限制进行验证。
- 审阅者
- SIS Engineering
- 最后审阅
- 2026-07-17