AWS弹性负载均衡（ELB）详解：CLB、ALB、NLB和GWLB的对比与选择

AWS弹性负载均衡（ELB）详解：CLB、ALB、NLB和GWLB的对比与选择

引用

CSDN

1.

https://blog.csdn.net/weixin_52574459/article/details/142551404

AWS弹性负载均衡（ELB）是AWS云服务中用于分配应用程序流量的重要组件。它提供了多种类型的负载均衡器，以满足不同场景下的需求。本文将详细介绍AWS ELB的各种类型及其特点，帮助读者更好地理解如何选择和使用这些服务。

ELB类型

CLB-Classic Load Balancer

• 优势：价格便宜，容易上手
• 劣势：效果没有NLB/ALB好

ALB-Application Load Balancer

• 适用场景：非常适用于微服务和基于容器的应用程序（例如：Docker和Amazon ECS）
• 功能特点：
• 具有端口映射功能，可重定向到ECS中的动态端口
• 支持基于Host和Path的转发
• 支持粘性会话
• 性能比CLB好
• 支持按比例的流量转发
• 可编辑安全组
• 负载均衡算法：默认算法为轮询算法，还可以使用最少未完成请求算法

"最少未完成请求"算法，也称为"Least Outstanding Requests"算法。当一个新请求到达负载均衡器时，它会将新请求分发给当前负载最轻的服务器，以最大程度地平衡负载，从而避免某些服务器过载，而其他服务器却处于空闲状态。

Good to know:

• 固定Fixed hostname (xxx.region.elb.amazonaws.com)
• The application servers don’t see the IP of the client directly
• The true IP of the client is inserted in the headerX-Forwarded-For请求标头可自动添加并帮助您识别客户端的 IP 地址
• We can also get Port
• X-Forwarded-Port 请求标头可帮助您识别客户端与您的负载均衡器连接时所用的目标端口)
• (X-Forwarded-Proto 请求标头可帮助您识别客户端与您的负载均衡器连接时所用的协议 (HTTP 或 HTTPS))

NLB-Network Load Balancer

• 优势：
• 性能最好，每秒支持百万次请求
• 不需要预热（ALB和CLB流量大的话需要预热扩充负债均衡服务节点）
• NLB的ip地址不会改变（CLB和ALB会随着时间改变）
• NLB可以分配固定弹性ip，ALB不能
• 特点：
• 无状态：NLB是无状态的，不会将请求粘滞在特定的后端实例上，适用于无状态应用
• NLB has one static IP per AZ, and supports assigning Elastic IP（helpful for whitelisting specific IP）
• NLB are used for extreme performance, TCP or UDP traffic
• Target Groups：
• EC2 instances
• IP Addresses – must be private IPs
• Application Load Balancer

GWLB-Gateway Load Balancer

用于路由流量到多个目标（例如，虚拟机、容器、EC2 实例）以提高可用性和扩展性。GWLB 主要用于处理流量，例如 VPN、NAT（网络地址转换）、防火墙、代理和其他网络服务。以下是 Gateway Load

GWLB 是专为处理网络层流量而设计的，而不是应用层协议。它主要用于处理传输层的流量，例如 TCP 和 UDP。典型的用途包括在 AWS 中设置网络架构，以便处理传输层的网络流量，如 VPN 连接、NAT 网关、防火墙、代理等。 GWLB 可以帮助实现高可用性和可扩展性，以满足网络流量的需求。

对比

注：

1. WebSocket是一种支持双向通信的网络协议，它允许在单个TCP连接上进行全双工通信。WebSocket通常用于实现实时的双向通信，如在线聊天应用、实时游戏等。
2. HTTP/2是HTTP协议的新版本，它在HTTP/1.1的基础上进行了改进，提供了更高的性能和效率。可以加速网页加载并减少网络延迟。
3. ALB和NLB选择和区别当客户的业务基于HTTP/HTTPS/Websocket时候，优先考虑使用ALB。NLB可以处理7层的流量，但NLB不解析7层的协议，不会对协议进行处理。如果选择了ALB，则处理不了4层的流量，主要取决于选择的负载均衡器类型。

Sticky Sessions (Session Affinity)-粘性会话、会话保持

确保在会话期间将来自用户的所有请求发送到相同的实例中。这通常通过在用户的浏览器中设置一个特定的 Cookie 来实现。

• 可以通过实现粘性会话，确保同一客户端始终被重定向到负载均衡器后面的同一实例。
• 这适用于经典负载均衡器和应用程序负载均衡器。
• 用于粘性会话的"cookie"具有您可控制的过期日期。
• 使用案例：确保用户不会丢失其会话数据。
• 启用粘性会话可能会导致后端 EC2 实例之间的负载不均衡。

Cookie 类型

• 1.Application-based Cookies
• 自定义 Cookie
• 由目标生成
• 这些 Cookie 是由负载均衡器的目标（即后端服务器实例）生成的。
• 每个目标组（Target Group）可以定义一个自定义的 Cookie 名称，以便满足应用程序的需求。
• 不要使用AWSALB、AWSALBAPP或AWSALBTG（这些由 ELB 保留使用）
• 应用程序 Cookie
• 由负载均衡器生成
• Cookie 名称为AWSALBAPP
• 2.持续时间Duration-based Cookies

Cross-Zone Balancing

Cross-Zone Balancing允许ASG在跨越多个AZ时，尽量均匀地分布实例，以确保各个可用区的负载相对平衡。

• Application Load Balancer
• Always on(can’t be disabled)
• No charges for inter AZ data
• Network Load Balancer
• Disabled by default
• You pay charges ($) for inter AZ data if enabled
• Classic Load Balancer
• Disabled by default
• No charges for inter AZ data if enabled

SSL – client到LB的加密

a SSL certificate allows traffic between yourclientsand yourload balancerto be encrypted intransit

SNI

Server Name Indication

SNI解决了将多个SSL证书加载到一个Web服务器的问题（用于提供多个网站）。

• 它是一个“较新”的协议，要求客户端在初始SSL握手中指示目标服务器的主机名。
• 然后服务器将查找正确的证书或返回默认证书。
• SNI仅适用于ALB和NLB（新一代负载均衡器），以及CloudFront。
• 不适用于CLB（旧一代负载均衡器）

connection draining & deregistration delay

用于确保在服务节点从负载均衡器中移除时，已有的连接能够平滑地处理完毕而不会立即中断。

1. CLB———Connection Draining（连接逐出）：当需要从负载均衡器上移除一个服务节点时，connection draining 是一种机制，用于逐渐关闭正在进行的连接。负载均衡器不再将新的连接分发给该节点，而是允许已有的连接完成其请求，然后逐渐关闭连接。这样可以避免中断正在进行的操作或导致数据丢失。
2. ALB & NLB———Deregistration Delay（注销延迟）：deregistration delay 是指在将一个服务节点从负载均衡器中注销（或移除）之前，等待一段时间的延迟。在此期间，负载均衡器仍然将一部分流量转发到该节点，以确保现有的连接有足够的时间完成，并且新的连接不会立即被拒绝。这个延迟时间允许连接逐渐被关闭，确保服务平稳过渡。