1.3.1　具有不可预测性、延迟不敏感性的工作负载

在生活中没有一成不变的事物变化才是常态。我们无法完美地预测或优化任何事情。许多工作负载都面临需求可变性的问题：需求并不是每时每刻都清晰的。根据可变性缓冲定律，我们可以通过以下三种方式来缓冲需求变化：

• 库存—提前生产好用来使用的东西（比如缓存）。

• 容量—多余的备用容量可以容纳更多的需求，而不会使实例急剧地扩/缩容（比如产生空闲实例）。

• 时间—使需求等待更长的时间。

这些都是有代价的。库存需要花钱来保持（RAM和磁盘空间不是免费的），容量需要花钱来保留（空闲的CPU仍然耗电），以及最著名的“时间就是金钱”，没有人喜欢无故地等待。

注意 库存、容量和时间确实是缓冲可变性的唯一选择。这是基本的数学推理。库存是不可或缺的，是产能利用率和需求的总和。容量是一个导数，即库存的变化率。时间就是时间。你可以重新排列术语，也可以更改它们的值，但不能逃脱数学的界限。唯一的选择是减少可变性，因此首先需要较少缓冲。

Knative的默认缓冲策略是时间。如果请求到来，但此时实例很少甚至为零，那么Knative就会通过增加实例并保持请求直到可以提供服务来响应请求。这种机制不错，但是扩容需要时间。这就是著名的“冷启动”问题。

冷启动重要吗？这取决于需求的性质。一方面，如果需求对延迟敏感，那么将实例缩容到零可能不适合这个场景。此时，可以通过设置使Knative保持最少数量的实例处于活动状态来解冷启动问题。另一方面，如果这是一个批处理作业或需要等待一段时间才能启动的后台进程，那么按时间缓冲是明智且有效的。就让实例缩容到零吧，将节省的时间花在其他有意义的事情上。

除了请求对延迟的敏感性，另一个需要考虑的因素是：请求的可预测性如何？请求量变动较大的场景需要更大的缓冲区、更多的库存、更多的存储容量，或者让请求等待更长的时间。没有其他选择。如果你不知道如何权衡，那么自动缩放器可以帮你解决这些负担（见图1.1）。在延迟敏感度性和高度可预测性的业务场景（例如Netflix或YouTube视频服务器）下，Knative可能不是一个很好的选择。在这种场景下，需要按计划来规划业务实例。

图1.1　在延迟敏感性和需求可预测性的不同场景中，Knative的最佳配置