使用 ELB 和 EC2 Auto-Scaling 支持 AWS 工作负载_aws 负载均衡器 控制ec2 并发访问量

弹性负载均衡器

弹性负载均衡器（通常称为 ELB）的主要功能是通过在目标资源组中均匀分布这些请求来帮助管理和控制到一组目标的入站请求流。这些目标可能是一组 EC2 实例、AWS Lambda 函数、一系列 IP 地址，甚至是容器。ELB 中定义的目标可以位于不同的可用区 (AZ) 以提供额外的弹性，也可以全部放置在单个 AZ 内。

让我们从一个典型场景来看这个问题。例如，假设您刚刚创建了一个新应用程序，该应用程序当前驻留在您环境中的单个 EC2 实例上，并且该实例正在被多个用户访问。在此阶段，您的架构可以从逻辑上总结如下。

如果您熟悉架构设计和最佳实践，那么您会意识到使用单实例方法并不理想；尽管如此，它肯定会起作用并为您的用户提供服务。然而，这种基础设施布局带来了一些挑战。例如，您的应用程序所在的一个实例可能会失败 - 可能是由于硬件或软件故障。如果发生这种情况，您的应用程序将关闭并且用户无法使用。

此外，如果您遇到流量突然激增，您的实例可能由于其性能限制而无法处理额外的负载。为了加强您的基础设施并帮助解决这些挑战，例如不可预测的流量峰值和高可用性，您应该在设计中引入弹性负载均衡器和运行应用程序的其他实例，

正如您在此设计中所看到的，AWS Elastic Load Balancer 充当接收来自用户的传入流量的点，并将流量均匀地分布在更多实例中。默认情况下，ELB 具有高可用性，因为它是 AWS 托管服务，可确保弹性，因此我们无需这样做。尽管看起来 ELB 是单点故障，但 ELB 实际上由 AWS 管理的多个实例组成。此外，在这种情况下，我们现在有三个实例运行我们的应用程序。

现在让我回顾一下我们之前讨论过的挑战。如果这三个实例中的任何一个出现故障，ELB 将根据定义的指标自动检测故障，并将所有流量转移到其余两个运行状况良好的实例。此外，如果您遇到流量激增，那么运行应用程序的其他实例将帮助您应对额外的负载。

使用 ELB 的众多优点之一是它由 AWS 管理，并且根据定义，它是有弹性的。这意味着随着传入流量的增加和减少，它将自动扩展以满足您的传入流量。如果您是系统管理员或自行运行自己的负载均衡器的 DevOps 工程师，那么您需要担心扩展负载均衡器并强制执行高可用性。借助 AWS ELB，您只需单击几下即可创建负载均衡器并启用动态扩展。

根据您的流量分配要求，可以使用三种 AWS Elastic Load Balancer：

1. 首先，应用程序负载均衡器：它为运行 HTTP 或 HTTPS 协议的 Web 应用程序提供了灵活的功能集。应用程序负载均衡器在请求级别运行。它还提供针对应用程序架构的高级路由、TLS 终止和可见性功能，允许您将流量路由到同一 EC2 实例上的不同端口。
2. 接下来是网络负载均衡器：它用于为您的应用程序提供超高性能，同时保持非常低的延迟。它在连接级别运行，将流量路由到 VPC 内的目标。它还能够每秒处理数百万个请求。
3. 最后，经典负载均衡器：这主要用于在现有 EC2 经典环境中构建并在连接和请求级别运行的应用程序。

现在让我谈谈 AWS Elastic Load Balancer 的组件及其背后的一些原理。

监听器：对于每个负载均衡器，无论使用哪种类型，都必须至少配置一个监听器。侦听器定义如何根据设置为条件的端口和协议将入站连接路由到目标组。根据您选择的 ELB，监听器本身的配置略有不同。

目标组：目标组只是您希望 ELB 将请求路由到的一组资源，例如一组 EC2 实例。您可以为 ELB 配置多个不同的目标组，每个目标组与不同的侦听器配置和关联规则相关联。这使您能够根据请求类型将流量路由到不同的资源。

规则：规则与您在 ELB 中配置的每个侦听器相关联，它们帮助定义传入请求如何路由到哪个目标组。

正如您所看到的，您的 ELB 可以包含一个或多个侦听器，每个侦听器可以包含一个或多个规则，每个规则可以包含多个条件，并且规则中的所有条件都等于一个操作。示例规则如下所示，其中 IF 语句类似于条件，而 THEN 语句充当满足所有条件时的操作。

根据 ELB 响应请求的侦听器，基于优先级列表的规则将关联包含这些条件和操作。如果请求来自 10.0.1.0/24 网络范围（条件 1）并尝试执行 HTTP PUT 请求（条件 2），则该请求将被发送到标题为“Group1”的目标组（操作）。

运行状况检查： ELB 关联针对目标组中定义的资源执行的运行状况检查。这些运行状况检查允许 ELB 使用特定协议联系每个目标以接收响应。如果在设定的阈值内没有收到响应，则 ELB 会将目标标记为不健康并停止向目标发送流量。

内部或面向互联网的 ELB：有两种不同的方案可用于您的弹性负载均衡器：内部或面向互联网。

• 面向互联网：顾名思义，定义为面向互联网的 ELB 节点可通过互联网访问，因此除了内部 IP 地址外，还具有可解析为其公共 IP 地址的公共 DNS 名称以及。这允许 ELB 在将流量分发和路由到目标组之前为来自互联网的传入请求提供服务，在本例中目标组可能是一组接收 HTTP 或 HTTPs 请求的 Web 服务器。当您面向互联网的 ELB 与其目标组通信时，它将仅使用内部 IP 地址，这意味着您的目标组不需要公共 IP 地址。
• 内部ELB：内部ELB只有内部IP地址。这意味着它只能处理源自您的 VPC 本身的请求。例如，您可能在公共子网中的 Web 服务器和私有子网中的应用程序服务器之间有一个内部负载均衡器。

ELB 节点：在 ELB 的创建过程中，您需要定义希望 ELB 在哪个可用区中运行。对于每个选定的 AZ，将在该 AZ 内放置一个 ELB 节点。因此，您需要确保有一个 ELB 节点与要将流量路由到的可用区关联。如果没有关联的 AZ，ELB 将无法将流量路由到 AZ 内的任何目标，即使这些目标是在目标组内定义的。这是因为 ELB 使用这些节点将流量分配给您的目标组。

跨区域负载平衡：根据您选择的 ELB 选项，您可以选择在您的环境中启用和实施跨区域负载平衡。

假设您为 ELB 激活了两个可用区域，每个关联的负载均衡器接收相同数量的流量。一个 AZ 有 6 个目标，另一个 AZ 有 4 个，如下所示。当禁用交叉负载负载均衡时，其关联 AZ 中的每个 ELB 将仅将其流量分配给该 AZ 内的目标。正如我们从图像中看到的，这导致可用区域中每个目标的流量分布不均匀。

启用跨区域负载均衡后，无论关联的可用区中有多少个目标，ELB 都会在所有目标之间均匀分配所有传入流量，确保跨可用区的每个目标均匀分布。

EC2 自动扩展

那么EC2 Auto Scaling到底是什么？简而言之，自动扩展是一种机制，可让您自动增加或减少 EC2 资源，以满足基于自定义定义的指标和阈值的需求。

让我们看一下如何在实践中使用 EC2 Auto Scaling 的示例。假设您有一个 EC2 实例充当 Web 服务器，通过互联网接收来自公共用户的请求。随着请求（需求）的增加，实例上的负载也会增加，并且需要额外的处理能力来处理额外的请求；因此，CPU 利用率也会增加。为了避免实例上的 CPU 资源耗尽（这会导致最终用户体验到性能不佳），您需要部署另一个 EC2 实例来负载平衡需求并处理增加的请求。

通过自动扩展，您可以配置一个指标，以便在 CPU 利用率达到第一个实例的 75% 时自动启动第二个实例。通过均匀地负载平衡流量，可以减少对每个实例的需求，并减少第一个 Web 服务器因 CPU 使用率过高而出现故障或速度变慢的可能性。同样，当您的 Web 服务器的需求减少时，您的 CPU 利用率也会减少，因此您也可以设置一个指标来缩减。在此示例中，您可以将自动扩展配置为在 CPU 利用率降至 20% 时自动终止您的 EC2 实例之一，因为由于需求减少而不再需要该实例。缩减资源规模可帮助您优化 EC2 队列的成本，因为您只需在资源运行时付费。

通过这些可自定义和定义的指标，您可以轻松自动增加（横向扩展）和减少（缩减）EC2 队列的规模。这有很多优点，以下是一些关键点：

• 自动化 - 因为这提供了基于自定义阈值的自动配置。您的基础设施可以弹性地配置所需的资源，以防止您的运营团队手动部署和删除资源来满足基础设施上的需求。
• 更高的客户满意度 - 如果您始终能够在需求增加时在环境中配置足够的容量，那么您的最终用户不太可能遇到性能问题，这将有助于保留用户。
• 降低成本 - 能够在需求下降时自动减少您拥有的资源量，您将不再为这些资源付费。您只需在 EC2 资源启动并运行时为其付费，这是基于每秒的。