06 | 全链路压测：系统整体容量保障的“核武器”（下）

作者回复: 说的非常好！低调用量≠低风险

作者回复: 你好，全链路压测不适合长时间的压测测试或稳定性测试，主要原因有两点： 1.全链路压测一般在生产环境的低峰期实施，如果时间过长，压测工作跨越到高峰期，容易造成不必要的风险。 2.全链路压测会产生大量的数据，也需要投入人力持续值守和监控，成本比较高，不适合长时间执行。 除此之外，绝大多数服务容量的瓶颈都发生在高并发和高吞吐量的场景下，对于需要进行长时间压测来检测的问题（如：内存泄露、GC问题、磁盘容量瓶颈等），一般在线下测试环境进行测试也已经足够了，即便线下测试不完整，这些问题也可以通过简单的线上监控提前感知到，因此在这些问题上引入全链路压测的性价比并不高。

作者回复: 回答的不错！对外部依赖的第三方接口调用处理不好，很容易成为全链路压测场景失真的一个因素。改进这一点的策略就是尽可能仿真，比如针对支付场景，我们可以mock支付回调，并按照真实回调的响应时间设置一定的延时，甚至可以制造一些波动，来尽可能逼近实际情况。

作者回复: 总结的很好，尤其是最后一点，非常考验功底

作者回复: 你好，这里的标准本身没有问题，1k/s指的是异常量（即每秒抛出1k次异常），异常量的制定标准需要参考流量（不是网速），没有严格的标准，一般来说是一个经验值。

作者回复: 这是一个很好的思考方向，狭义的压测执行期间的无人值守，在技术上的难度并不大，由压测平台按照预置的策略去自动化施压，并对接外部监控系统（指标需要提前设置），在识别到风险时主动熔断压测或变更策略，完全可以做到不需要人的干预。风险在于对接的监控指标的完备性，但一般互联网公司的NOC团队都是随时处于值班状态的，可以兜底风险。 广义的说，我们还希望能做到压测全流程的无人值守，包括压测前（准备压测脚本&数据）和压测后（分析结果&输出风险项）的低人力甚至无人力投入，这就有很大的难度了。业内是有一些实践的，比如通过埋点的方式自动从流量入口梳理链路；包括类似于你提到的通过定期采集线上各接口的流量数据，去反向对齐压测时各接口的压力配比，等等，都是在朝着这个方向努力。