【摘抄】

负载平衡器基础

AWS有3个负载均衡产品 - “经典负载均衡器”（CLB），“应用负载均衡器”（ALB）和“网络负载均衡器”（NLB）。

在引入ALB之前，“经典负载平衡器”被称为“弹性负载平衡器”（ELB），所以较旧的文档，工具和博客帖子可能仍然引用“ELB”。

自2009年以来，CLB一直存在，2016年有ALB，2017年NLB被添加到AWS。

CLB支持TCP和HTTP负载平衡。ALB只支持HTTP负载均衡。NLB支持TCP第4层负载平衡。

CLB和ALB可以选择处理单个SSL证书的终止。

所有人都可以选择执行活动的实例运行状况检查，如果它们变得不健康，可以将它们从目标池中移除。

CLB不支持复杂/基于规则的路由。ALB支持（当前很小的）一组基于规则的路由功能。NLB具有最广泛的路由选择。

CLB只能将流量转发到目标实例上的单个全局配置端口，而ALB则可以转发到每个实例配置的端口，从而更好地支持在具有动态端口分配（如ECS或Mesos）的共享集群上路由到服务。NLB支持同一IP上的多个端口; 通过IP地址注册目标，包括负载均衡器的VPC外的目标; ECS可以选择未使用的端口来安排任务，然后使用此端口注册目标组。

在EC2 Classic和VPC中支持CLB，而在VPC中仅支持ALB。

ALB可以定位RFC1918范围内的实例组和基于IP的目标组，允许您通过VPN或Direct Connect在本地目标上使用。

负载平衡器技巧

如果您对负载均衡没有意见，并且没有像请求的特定于应用程序的路由那样的复杂负载平衡需求，那么使用CLB或ALB进行负载平衡是合理的。

即使你根本不想考虑负载均衡，因为你的架构非常简单（比如只有一台服务器），无论如何都要在它前面加一个负载平衡器。这样可以让您在升级时更具灵活性，因为您不必更改任何传播缓慢的DNS设置，而且还可以让您更轻松地完成一些SSL终止操作。

CLB和ALB具有许多IP：在内部，AWS负载均衡器只是EC2内部托管的各个软件负载均衡器的集合，其中DNS负载平衡流量。该池可以包含多个IP，每个可用区至少一个，并且取决于流量级别。他们也支持SSL终止，非常方便。

扩展： CLB和ALB可以扩展到非常高的吞吐量，但扩展并不是即时的。如果您预计会突然遇到大量流量，那么加载测试可以提前进行扩展。您也可以联系亚马逊，让他们“预热”负载平衡器。

客户端IP：通常，如果服务器想要知道真正的客户端IP地址，负载平衡器必须以某种方式转发这些信息。CLB添加标准的X-Forwarded-For标题。当使用CLB作为HTTP负载均衡器时，可以从中获取客户端的IP地址。

部署时使用负载平衡器：一种常见的模式是在用最新版本转动一个新堆栈之后交换负载平衡器中的实例，使旧堆栈保持运行一两个小时，并且在出现问题时或者返回到旧堆栈撕下来。

负载平衡器陷阱和局限性

❗CLB和ALB 没有固定的外部IP，所有客户都能看到。对于大多数消费者应用程序来说，这并不重要，但是您的企业客户可能会想要这样做。每个用户的IP将会不同，并且随着时间的推移（在标准的EC2 IP范围内），单个客户端的变化将不可预测。同样，永远不要将CLB名称解析为IP，并将其作为A记录的值 - 它将工作一段时间，然后中断！

❗某些Web客户端或反向代理长时间缓存DNS查找，这对于CLB和ALB是有问题的，因为它们会更改IP。这意味着几分钟，几小时或几天后，客户端将停止工作，除非您禁用DNS缓存。注意Java的设置，并确保正确调整它们。另一个例子是nginx作为反向代理，通常只在启动时解析后端（尽管有办法解决这个问题）。

without在没有漫长的冷静期的情况下，客户之间的知识产权回收并不是闻所未闻的。所以作为一个客户端，如果你缓存一个IP而不使用SSL（来验证服务器），那么你可能会得到不仅仅是错误，而是来自完全不同的服务或公司的响应！

🔸作为CLB或ALB背后的服务运营商，后一种现象意味着您也可以看到其他公司客户的疑惑或错误请求。这对于使用后端API的客户端来说是最常见的（因为网页浏览器通常会在有限的时间内缓存）。

❗CLB和ALB需要一定的时间来扩大规模，并不能很好地处理突发性的交通高峰。因此，如果您预计会出现高峰，则需要通过逐渐增加流量来“预热”负载平衡器。

carefully仔细调整您的健康检查 - 如果您在决定何时删除某个实例以及保守地将其添加回池中时太积极，则您的负载平衡器所面临的服务可能无法在几秒钟或几分钟内无法访问。当自动调整程序配置为终止受管理负载平衡器标记为不健康的实例时，请特别小心。

❗CLBHTTPS侦听器不支持服务器名称指示（SNI）。如果您需要SNI，您可以通过提供具有主题备用名称（SAN）的证书或通过使用TCP侦听器并在您的后端终止SSL来解决此限制。

CLB

CLB基础知识

传统负载均衡器（以前称为弹性负载均衡器）是由Amazon管理和扩展的HTTP和TCP负载均衡器。

CLB提示

最佳实践： 如果大量使用CLB，并且具有更多详细信息，则必须阅读本文。

CLB问题和局限性

一般来说，CLB并不像一些负载平衡器那样“聪明”，并且没有传统的硬件负载平衡器所提供的奇特功能或精细控制。对于大多数涉及通过HTTP的会话应用程序或基于cookie的会话，或者SSL终止的常见情况，它们运行良好。

🔸默认情况下，CLB将拒绝将流量从一个可用区域（AZ）的负载均衡器路由到另一个可用区域的后端实例。这将导致503S如果在AZ的最后一个实例变得不可用，即使有在其他区域的健康情况。如果每个AZ运行少于两个后端实例，则几乎肯定要启用跨区域负载平衡。

🔸指导流量的复杂规则不受支持。例如，您不能根据URL中的正则表达式指定流量，如HAProxy提供。

Apex DNS名称：曾几何时，您无法将CLB分配给apex DNS记录（即http://example.com而不是http://foo.example.com），因为它需要成为A记录而不是CNAME。现在可以使用直接指向负载平衡器的Route 53别名记录。

🔸CLB 在内部使用HTTP保留。这可能会导致意想不到的副作用：来自不同客户端的请求（每个客户端都在它们自己的外部TCP连接中）可能会在内部端的相同TCP连接上结束。切勿假设同一个TCP连接上的多个请求来自同一个客户端！

🔸在同一子网内的CLB和后端实例之间的交通将有网络ACL计算（EC2 EC2的交通在同一个子网不会有网络ACL规则来评估）的规则。如果从应用于子网的网络ACL中删除默认的“0.0.0.0/0 ALLOW”规则，则必须添加允许在运行状况检查端口和任何侦听器端口上进行通信的规则。

截至2016年12月，VPC推出的CLB不支持IPv6寻址。在EC2-Classic中启动的CLB 通过“双栈”DNS名称支持IPv4和IPv6 。

ALB

ALB基础

WebSockets和HTTP / 2是现在支持。

��Internet协议版本6（IPv6）是现在支持。

��通过IP负载均衡是现在支持。

对应用负载平衡器在此之前，你被告知要使用TCP而不是HTTP作为协议，使其工作（如描述在这里），并用隐晦但有用的代理协议（更多关于这个），以通过TCP负载平衡器传递客户端的IP 。

ALB技巧

使用ALB通过动态端口分配（如ECS或Mesos）路由到托管在共享集群上的服务。

ALB支持基于HTTP主机的路由（发送“api.mydomain.com” - > {target-group-1}，“blog.mydomain.com” - > {target group 2}）的HTTP请求以及HTTP路径 -基于路由（发送HTTP请求为“/ API / *” - > {目标群-1}，“/博客/ *” - > {目标组2}）。

ALB问题和局限性

🔸ALB仅通过HTTPS支持HTTP / 2（不支持纯文本HTTP / 2）。

🔸ALB只支持外部客户端的HTTP / 2，而不支持内部资源（实例/容器）。

ALB支持HTTP路由，但不支持基于端口的TCP路由。

ALB目标组中的实例必须具有单个固定的健康检查端口（“EC2实例” - 级别健康检查），或者目标的健康检查端口必须与其应用程序端口（“应用程序实例” - 级别健康检查）相同， - 您无法配置与应用程序端口不同的每个目标健康检查端口。

ALB仅限VPC（它们不适用于EC2 Classic）

在目标群体中，如果没有健康的目标，所有的请求都会被路由到所有目标。例如，如果您将侦听程序指向包含具有较长初始化阶段（在此期间运行状况检查将失败）的单个服务的目标组，则请求将在启动时到达该服务。

📜尽管ALB 现在支持SNI，但它们仅支持每个Load Balancer 25个HTTPS证书。这个限制在这里没有描述，所以可能会有所变化。

摘自：https://zhuanlan.zhihu.com/p/31772948