我们服务的流量并非完全可预测。为了帮助保持服务略微过度配置，并提前警告流量增加导致的任何性能下降，我们维护了一种“连续缓冲负载生成器”。这会在用户流量之上对我们的生产 API 产生恒定的负载。如果我们发现服务正在降级，它会自动关闭，理想情况下，我们有一点时间来找出问题并扩大规模，然后自然用户流量与导致服务降级的增加流量相匹配。一旦服务再次稳定，缓冲负载就会重新打开。
虽然我们一直将这种持续的流量生成称为“持续负载测试”，但这似乎是一种令人困惑的措辞，很难与“实际”负载测试区分开来（我将其称为实验，具有明确的开始和结束、负载模式以及最后的二进制通过/失败结果）。我几乎想称之为“金丝雀流量”，因为我们会发送额外的流量来在用户遇到问题之前警告我们，但这与业内对金丝雀含义的普遍理解不太相符。
这是在负载平衡、自动扩展等基础上的附加策略。我们并不是想在这里取代任何行业标准的流量管理步骤。
我怀疑这是一个不知道如何用 Google 搜索正确词语的情况，因此：
- 如果这是其他地方使用的模式，那么它叫什么？
- 或者说，如果没有人这样做，那为什么不呢？我完全愿意相信，通过其他类型的测试或监控可以更好地获得这一结果。
答案1
综合或主动监测是模拟应用程序实际执行操作的人工负载的术语。在测量应用程序性能的背景下。
模拟实际负载非常棒。但是，在生产中消耗大量资源并不高效，只会消耗资源。更重要的是，自动禁用机制对于保持良好的性能至关重要。相反，应始终将负载限制在最低水平，并继续测量响应时间和错误率。永远不要停止测量，因为性能下降会显示事件对用户的影响。
实际负载生成器非常适合测试和容量规划。在测试环境中配置不同的计算实例大小，并推动负载直至其失效。作为高可用性测试或滚动升级的一部分，临时添加一些负载以验证原本空闲的系统。
决定什么响应时间目标是。了解每秒多少请求是安全的。在可操作的阈值处设置自动扩展或警报。
衡量服务水平目标，并了解限制，将为您提供进行适当容量规划的工具。而不会人为地消耗您的缓冲容量。