我在AWS ALB后面有一个应用程序/目标，并希望对它将收到的TCP连接数设置一个硬性上限。
如果我理解正确，ALB目标可以是
或
理想情况下，我会将目标置于第三种状态，即说“不要杀了我，但不要将流量路由到我身上”＃34;到达连接上限时（因此我会产生更多目标以满足需求）。
没有这样的第三种状态，但还有另一种方法可以限制连接数吗？
答案 0 :(得分：1)
对这个问题本身有一个主要的误解，所以我会先解决这个问题
<块引用>ALB 目标可能 [...] 不健康——ALB 不会将流量路由到目标。此外，它会尽快清除/注销/重新启动目标（我在文档中找不到这个，但这是我观察到的行为）。
这不是真正正在发生的事情。
而 ALB 是一个负载均衡器：它会将请求路由到目标，根据一些您可以在一定程度上配置的路由逻辑。
它还将执行运行状况检查，用于从 ALB 的角度确定目标是健康还是不健康。
这是一个误解：当目标被认为不健康时，ALB 将唯一做的事情是它会停止向它发送新请求强>。仅此而已。
ALB 本身没有能力 (1) 取消注册或 (2) 重新启动目标。事实上，它本身会继续执行健康检查，每当目标恢复健康时，它就会再次开始发送流量。
你所描述的你观察到的行为也可能不是完全发生的事情。您说目标已注销并重新启动。除非您有一些令人难以置信的自定义（极不可能），否则目标不会重新启动，而是被替换了。这是一个巨大的差异。
让我们假设这是实际发生的行为。
发生这种情况的原因几乎可以肯定是有一个 AutoScaling Group 与 ALB 集成（这是 AWS 上最常见的设计之一）。 AutoScaling Group 可以将运行状况检查与 ALB 集成（即，目标运行状况的 ALB 报告由 ASG 使用）。当 ASG 确定某个实例运行状况不佳（例如，通过与 ALB 的集成）时，ASG 继续替换它，以便它将许多实例保持在健康状态（等于 DesiredCapacity）。
现在，回到问题 - 简而言之，在 ALB 级别，您无法对目标将接收的连接数设置硬上限。
实际上，您需要 (1) 首先防止这种饱和情况发生，以及 (2) 决定在 发生时做什么。
为防止这种情况发生，您需要确保始终有足够的实例来处理当前的流量，以及从检测到流量增加到新流量增加之间的预计流量增加实例可以启动并投入使用。例如，您可以根据每个目标上的平均连接数使用警报，并触发 AutoScaling（在执行该路由之前，确保“连接数”确实是最佳扩展指标非常重要） .检查您可以多快地将新实例投入使用，并检查您需要维持多少超额配置，以便您在检测到负载增加到新实例准备就绪之间有足够的时间。
当发生时该怎么办？您在这里主要有两个一般选择：
您的目标可以在可能“降级”的情况下接受和处理请求（即，您处理的请求比您的规范多，因此它们都可能变慢，或者由于下游问题而失败，等）；
或者您可以快速拒绝该请求（但仔细检查它不是 ALB 请求！您应该继续接受和处理这些请求）并向调用者返回一条错误消息（也称为减载）。
在任何一种情况下，您都应该决定是要“等待它结束”，还是开始添加新实例以处理额外负载的过程。这个决定通常归结为确定流量增加是持续的还是只是暂时的、短暂的高峰的可能性。
您不应该做的一件事就是为此目的进行健康检查。如果您拒绝来自 ALB 的运行状况检查请求，它会将实例归类为不健康，如果您有 ASG（您应该这样做），ASG 将终止该实例（导致剩余实例上的负载更多，而这个实例正在运行）替换）。此外，对于 ALB 来说，“我很健康但很饱” 的情况与 “我确实遇到了问题，我需要更换” 没有区别。< /p>
最后一点：请记住，ALB 并不是真正处理“连接”，而是“请求”（即，它是更高级别的抽象）。这意味着“连接数”现在可能是一个很好的扩展指标，因为 ALB 可以并且很可能会将来自许多客户端的请求多路复用为到目标的较少数量的连接。也就是说，如果 ALB 接收来自 10 个不同客户端的 TCP 连接，它可能只打开 5 个（或任何其他数量）到目标的连接，并仅通过这 5 个连接发送来自所有 10 个客户端的请求。