我到处了解到用于扩展我们的webapp的不同方法，包括使用本地请求计数器进行缩放。在下面，他们写了这种方法的缺点，并补充说，每个实例几乎同时会达到阈值，并且
因此每个实例都需要一个新实例，从而导致大量的
实例，即使数量只增加了一个


我很想知道是否有解决此问题的方法或任何解决方法？

评论

是的，不要使用本地计数器，而要使用中央系统来处理总负载并相应地扩展。我对您的追求一无所知，您的报价对我来说绝对清楚。您能详细说明一下您缺少什么吗？
如果您为实例命名时要创建所请求的号码，那么该怎么办？因此当您尝试创建“ instance_5”时，该名称已被使用并且无法创建？

#1 楼

使用以下组件可以轻松解决该问题：


在为您的Web应用提供服务的实例上，可以继续监视传入请求的数量–以及您认为合适的任何其他内容。
发布监视系统收到的请求数。如果尚未实施，此步骤将提高您的监视能力，并将帮助您监视每台主机上的负载以及主机平衡。
从传入请求中，推断出所需的估计Webaspp服务器数量服务于该工作负载，以及实际数量与估计所需数量之间的差额。在您描述的情况下，估计数量似乎只是最近一段时间内传入请求总数的标量函数。在其他系统上或一段时间之后，可以实施更精细的策略。监视这些数量和差异可以减轻自动缩放策略的可追溯性，并监视其响应性。
最后一次实现自动缩放本身，这实际上只是从监视系统中读取一些数字并将其写入缩放系统。


#2 楼

一种可能的方法是允许此类实例根据本地请求计数器对新实例提出要求，但与其直接对这些要求做出反应，不如将它们集中到一个中央实例创建逻辑中。

该逻辑将立即对第一个需求做出反应，还启动“冷静”倒数计时器。在计时器仍处于活动状态时收到的任何后续需求都将被认为是由触发第一个需求的相同流量高峰引起的，因此将被忽略。

可以使用类似的逻辑来逐渐关闭空闲状态例如，如果本地计数器保持在最低水平以下。

注意：本地计数器将需要以漏斗方式操作或定期重置以使这种方法可行-这样才能满足需求如果流量仍然很高，则重复此操作。

另一种可能的方法是只发布本地计数器。中央逻辑部分将定期收集和汇总这些本地计数器值，以便决定启动新实例或关闭现有实例。

这种方法的优点是缺少单个全局计数器，这将需要写访问锁定（以防止损坏），这将限制可伸缩性。

分片计数器中的模式详细信息中介绍了此方法。