Amazon EC2 负载均衡器

Question

我想知道 Amazon 应用程序负载平衡 (ALB) 和经典负载平衡 (CLB) 之间的主要区别。我已经搜索过，但他们只给出了示例，例如经典负载均衡只包含相同的内容，但应用程序负载均衡可以包含不同的内容并与目标组分组。

ALB 有一些特性（例如，基于主机的路由、基于路径的路由），但我的问题是为什么我们使用 ALB 而不是经典的负载平衡。请提供两者的用例。

Answer 1

ALB

应用程序负载均衡器 (Elastic Load Balancer V2) 可让您根据更复杂的标准/规则（特别是 URL 路径）将流量引导至 EC2 实例。您可以让尝试访问“/signup”的用户转到一组实例，让尝试访问“/homepage”的用户转到另一组实例。与经典 ELB 相比，ALB 在应用程序级别（OSI 第 7 层）检查流量。例如，在这个级别可以解析 URL 路径。

ELB/经典

经典负载均衡器使用 TCP 级别的信息（OSI 第 4 层传输）统一路由流量。它会以“循环”方式向每个实例发送请求，或者利用粘性会话并将每个用户/客户端发送到他们最初登陆的同一个实例。

为什么选择 ALB 而不是 ELB？

如果您决定以这样一种方式构建系统，即每条路径都有自己的一组实例或自己的服务，那么您可以使用 ALB。所以 /signup、/login、/info 等都通过一个负载均衡器，该负载均衡器固定到您的域名 https//mysite.com，但不同的 EC2 实例正在为每个实例提供服务。 ALB 仅支持 HTTP/HTTPS。如果您的系统使用其他协议，则必须使用 ELB/Classic 负载均衡器。 Websockets HTTP/2 目前仅在 ALB 上受支持。

您可能会选择 ALB 而不是 ELB 的另一个原因是，还有一些额外的新功能尚未添加到 ELB，或者可能永远不会添加。正如迈克尔在下面指出的那样，经典负载均衡器不支持 AWS WAF，但在 ALB 上却支持。我进一步扩展了其他功能。

为什么选择 ELB 而不是 ALB？

从架构上讲，将每个请求发送到同一组实例，然后在您的应用程序内部将请求委托给某些函数/类/方法等的某些路径，这要简单得多...这基本上是大多数应用程序开始的单体设计出为。对于大多数工作负载而言，将流量专用于某些实例组（ALB 方法）会浪费 EC2 的能力。您将有一些实例做大量工作，而其他实例几乎没有使用。

与 ALB 类似，经典 ELB 的一些功能还没有出现在 ALB 上。我在下面展开。

更新 - 更多关于功能差异的信息

从产品的角度来看，它们的不同之处在于与它们的操作方式无关的其他方面，更多的是一些尚未出现的功能。

HTTP 到 HTTPS 重定向 - 例如，在 ALB 中，每个目标组（您分配特定路由的实例组）目前只能处理一个协议，因此如果您要实现 HTTP 到HTTPS 重定向这至少需要两个实例。使用 ELB，您可以在单个实例上处理 HTTP 到 HTTPS 的重定向。我想 ALB 很快就会有这个功能。 https://forums.aws.amazon.com/thread.jspa?threadID=247546

一个负载均衡器上的多个 SSL 证书 - 使用 ALB，您可以为不同的域分配多个 SSL 证书。尽管已请求该功能，但这在经典负载均衡器上是不可能的。对于经典负载均衡器，您可以使用通配符证书，但这不是一回事。 ALB 使用 SNI 服务器名称标识来实现这一点，因为这尚未添加到经典 ELB 功能集中。