测试策略总览：分层测试、灰度发布、混沌工程、全链路压测
大家好，我是这次课程的主讲。今天我们来聊聊分布式系统的测试策略总览。说实话，这个话题很大，但我会尽量把它讲透。
分布式系统的测试，跟单体应用完全是两码事。你想想看，一个请求过来，可能要经过十几个服务，每个服务又有多个实例。任何一个环节出问题，都可能引发雪崩效应。我在项目中就遇到过好几次，一个不起眼的超时配置，最后把整个集群搞垮了。
所以，我们需要一套组合拳。我个人习惯把这套组合拳分成四个维度：分层测试、灰度发布、混沌工程和全链路压测。它们不是孤立的，而是相互配合的。
一、分层测试：从单元到端到端
分层测试，说白了就是把测试拆成不同粒度。我见过很多团队，要么只做单元测试，要么只做端到端测试。其实都不对。
我建议的分层是这样的：
| 层级 | 目标 | 典型工具 | 我踩过的坑 |
|---|---|---|---|
| 单元测试 | 验证单个函数/方法 | JUnit, GoTest | mock 太多，反而测不出真实逻辑 |
| 集成测试 | 验证模块间交互 | Testcontainers, Docker Compose | 依赖外部服务，环境不稳定 |
| 组件测试 | 验证单个服务 | Spring Boot Test | 数据库状态没清理干净 |
| 端到端测试 | 验证完整业务流程 | Cypress, Selenium | 跑一次要半小时，太慢了 |
嗯，这里要注意。分层测试的核心是比例。我一般遵循「测试金字塔」原则：单元测试占 70%，集成测试占 20%，端到端测试占 10%。为什么？因为端到端测试太脆弱了。我曾经有一个项目，端到端测试动不动就挂，最后发现是测试数据被别的用例污染了。
二、灰度发布：让风险可控
灰度发布，说白了就是「小范围试错」。你想想看，一个新功能直接全量上线，万一出问题，那就是事故。但先放给 1% 的用户，就算炸了，影响也有限。
我经历过一次惨痛的教训。有一次我们上线了一个新的缓存策略，自测没问题，直接全量发布。结果呢？缓存穿透，数据库被打爆，整整恢复了 20 分钟。从那以后，我再也不敢不做灰度发布了。
灰度发布的常见策略：
- 按用户比例灰度： 比如 1%、5%、10%、50%、100%。适合功能验证。
- 按地域灰度： 先放一个机房，再逐步铺开。适合基础设施变更。
- 按用户标签灰度： 只给 VIP 用户或内部员工。适合体验类功能。
工具方面，我推荐用 Nacos 或 Apollo 做配置中心，结合 OpenResty 或 Kong 做流量路由。举个例子：
# Nacos 配置示例
gray.ratio=0.01 # 1% 的流量走新版本
gray.version=v2.0.1三、混沌工程：主动找茬
混沌工程，说白了就是「故意搞破坏」。你可能会问：「系统好好的，为什么要主动搞坏它？」
原因很简单：故障是迟早会发生的。与其等它来了手忙脚乱，不如提前演练。我记得 Netflix 的 Chaos Monkey 就是干这个的——随机杀掉生产环境的实例，看系统能不能扛住。
混沌工程的几个原则：
- 先小后大： 先搞一个实例，再搞一个机房。
- 先非核心后核心： 别一上来就搞支付服务。
- 有监控，有止损： 发现不对劲，立刻停止实验。
常见的混沌实验场景：
| 实验类型 | 具体操作 | 验证目标 |
|---|---|---|
| 实例故障 | 随机 kill 一个 Pod | K8s 能否自动恢复 |
| 网络延迟 | 给某个服务加 500ms 延迟 | 超时重试机制是否生效 |
| 资源耗尽 | 打满 CPU 或内存 | 限流降级是否触发 |
| 依赖故障 | 停掉数据库或 Redis | 熔断器是否打开 |
工具方面，我常用 Chaos Mesh（K8s 原生）和 Litmus。如果你用的是云服务，AWS 的 Fault Injection Simulator 也不错。
四、全链路压测：模拟真实流量
全链路压测，说白了就是「模拟双十一」。跟普通的压力测试不同，它要模拟真实的用户行为，覆盖整个调用链。
我参与过几次大促前的全链路压测，那场面真是...嗯，一言难尽。第一次压测时，系统直接挂了，因为有个服务的连接池配得太小。第二次压测，数据库 CPU 飙到 100%，发现是慢查询。第三次压测，Redis 内存爆了，原来是缓存 key 没设过期时间。
全链路压测的关键点：
- 流量模型要真实： 不能只压一个接口，要模拟用户的操作路径。
- 数据要隔离： 压测数据不能污染线上数据。我一般用影子表或打标的方式。
- 监控要全面： 压测期间，CPU、内存、网络、QPS、延迟、错误率，一个都不能少。
一个典型的压测流程：
- 准备阶段： 搭建压测环境，准备压测数据，配置监控大盘。
- 基线压测： 先压一个低并发，比如 100 QPS，看看系统表现。
- 逐步加压： 每次增加 20% 的并发，观察系统拐点。
- 极限压测： 压到系统扛不住为止，找到瓶颈。
- 恢复验证： 压测结束后，检查系统是否恢复正常。
工具方面，我推荐 JMeter（老牌）、Locust（Python 友好）和 Gatling（Scala 高性能）。如果是云原生环境，K6 也不错，支持 K8s 集成。
总结：四者如何配合？
这四个策略不是孤立的。我个人习惯这样用：
- 日常开发： 分层测试保证代码质量。
- 上线前： 全链路压测验证容量。
- 上线时： 灰度发布控制风险。
- 上线后： 混沌工程持续验证韧性。
你想想看，如果这四个都做好了，系统出大问题的概率会大大降低。当然，没有银弹。每个系统都有自己的特点，需要灵活调整。
好了，这一章就到这里。下一章我们会深入讲分层测试的具体实践，包括如何写高效的单元测试和集成测试。到时候我会分享一些我自己的代码模板。