如何根据请求计数和内部进程自动缩放服务

Question

我有一个用来注册任务的服务。这些任务是异步的，使用状态管理引擎在后台执行。

状态管理引擎在服务中运行，并且一次执行4个并发任务。我有一个算法，根据等待执行的队列中等待的任务数自动缩放服务，我想编写一个算法，根据注册任务的请求数自动缩放服务，这样这些算法不会干扰彼此的缩放。

例如:如果服务已经根据队列中存在的任务数量进行了扩展，然后根据注册任务的请求进行扩展，则不应该进行伸缩。

有任何现实世界的例子，这种自动缩放发生吗？什么是实现这种依赖于两种不同场景的自动缩放的最佳方法？

任何参考或指导都会有帮助。

Answer 1

想想你的KPI吧。我敢打赌它们与95百分位数的延迟有关。也就是说，向Amazon主机发送更多美元的原因是为了让客户满意。

因此，定义并度量业务感兴趣的一些指标。

让我们在午夜检查这四项任务。你的顾客大多在睡觉，对吧？您可以扩展到较小数量的任务，没有人会注意到。这根本不重要。所以在计算资源上花更少的钱。

现在让我们来看看午餐时间的行为。客户到达的一个典型模型是泊松过程。这是无记忆的-客户的到来是相互独立的。我们希望估计到达强度：λλ。

兰博达将随着日间时间和日历季节的变化而变化.在高峰时间客户同时聚集在您的站点之前，您希望预测其流量的强度，并预先生成适当数量的服务器来满足他们的请求。

现在轮到黄铜钉了。在某个时间戳t，一个新的客户请求到达。我们让k服务器运行，可能默认为4。客户最重要的统计数据是:至少有一台服务器空闲的概率是多少？也就是说，空闲服务器将立即接收请求。

使用泊松模型或最近的服务器统计数据来估计新客户的服务时间是否会比第95百分位数延迟差，或者您的二语习得所要求的任何相关统计数据。如果延迟太高，表明新请求很有可能被“所有服务器都繁忙”所满足，那么就生成一个新的服务器。相反，如果延迟服务的概率很低(“许多服务器处于空闲状态”)，则关闭服务器。

为了在这个控制过程中保持稳定，您需要一点迟滞。高/低概率是一种方法。简单地等待控制动作之间的间隔，比如60秒，是另一种方法。如果λ lambda的估计是不可用的，那么像最近的队列深度这样的代理就很容易成为备用的。这样一种测度的指数平滑是直接的。同样，高/低滞后限制将有助于避免交替控制间隔要求+1服务器、-1、+1、-1、.的情况。