4. 负载均衡跨可用区：ALB/NLB的跨可用区部署、会话保持、健康检查
聊到多可用区架构，负载均衡器绝对是绕不开的核心组件。我经常跟团队说，负载均衡就是流量的交通枢纽，它要是挂了，整个应用就瘫痪了。所以跨可用区部署负载均衡，是容灾的第一道防线。
今天咱们就深入聊聊ALB和NLB的跨可用区部署、会话保持和健康检查。这三个点，说白了就是解决三个问题：流量怎么分发、用户会话怎么保持、后端挂了怎么办。
核心观点：ALB/NLB本身是区域级服务，但它的节点是部署在具体可用区里的。跨可用区部署，就是让负载均衡器在每个可用区都跑一个节点，这样单个可用区挂了，流量还能从其他节点走。
4.1 跨可用区部署：让负载均衡器也“多活”
我记得刚接触AWS的时候，有个同事问我：“ALB不是区域级的吗？为什么还要手动启用跨可用区？” 这个问题问得好。ALB确实是区域级服务，但它的计算节点是分布在各可用区的。默认情况下，你创建ALB时只选了2个可用区，那它就只在2个可用区部署节点。
我建议你至少选3个可用区。为什么？你想想看，如果只选2个，其中一个挂了，剩下那个要扛所有流量。万一那个也扛不住呢？选3个以上，容错空间就大多了。
具体操作上，ALB和NLB略有不同：
| 特性 | ALB (应用型) | NLB (网络型) |
|---|---|---|
| 跨可用区节点 | 自动在每个子网部署节点 | 每个可用区至少一个节点 |
| 跨可用区流量 | 默认启用，可关闭 | 默认启用，可关闭 |
| 最佳实践 | 启用跨可用区，均匀分布流量 | 启用跨可用区，避免单点 |
| 成本影响 | 跨可用区流量不额外收费 | 跨可用区流量按标准收费 |
我的经验：NLB的跨可用区流量会收费，这个坑我踩过。有一次客户说NLB费用异常高，查了半天发现是跨可用区流量太大。后来我们把同可用区的后端实例尽量放在一起，费用就降下来了。
4.2 会话保持：别让用户“掉线”
会话保持，也叫粘性会话。说白了就是同一个用户的请求，始终打到同一台后端服务器上。为什么需要这个？因为很多应用把用户状态存在本地内存里，比如购物车、登录状态。如果每次请求都打到不同服务器，用户就得反复登录，体验极差。
ALB支持两种会话保持方式：
- 基于Cookie的粘性：ALB自己生成一个Cookie（AWSALB），或者用你自定义的Cookie。每次请求带上这个Cookie，ALB就知道该转发给谁。
- 基于应用程序的粘性：你的应用自己生成Cookie，ALB只负责读取和转发。
NLB的会话保持稍微不同。NLB工作在四层，它基于源IP做会话保持。同一个源IP的请求，会始终转发到同一个目标组里的同一个目标。
注意：NLB的源IP会话保持有个局限——如果用户通过NAT网关访问，所有用户都显示同一个源IP，那就没法区分了。这种情况下，我建议你改用ALB，或者让客户端带上自定义的Cookie。
我曾经遇到过一个案例：某电商平台大促期间，用户频繁掉线。排查发现是会话保持没配好，用户的请求在多个后端之间乱跳。后来我们启用了ALB的基于Cookie的粘性，问题就解决了。嗯，这里要注意，会话保持会降低负载均衡的均匀性，因为某些“粘性”用户可能一直打在同一台机器上。所以如果后端实例性能差异大，要谨慎使用。
4.3 健康检查：自动剔除“病号”
健康检查是负载均衡的“体检医生”。它定期向后端实例发送探测请求，如果发现某个实例不健康，就自动把它从转发列表中剔除。等它恢复健康了，再重新加回来。
ALB和NLB的健康检查配置项差不多，但细节上有差异：
| 配置项 | ALB | NLB |
|---|---|---|
| 协议 | HTTP/HTTPS/GRPC | TCP/HTTP/HTTPS |
| 路径 | 必须指定（如 /health） | HTTP模式需指定路径 |
| 间隔 | 默认30秒，可调 | 默认10秒，可调 |
| 超时 | 默认5秒 | 默认10秒 |
| 健康阈值 | 默认5次成功 | 默认3次成功 |
| 不健康阈值 | 默认2次失败 | 默认3次失败 |
我个人的习惯是，健康检查的路径一定要用轻量级的接口。比如专门写一个 /health 接口，只检查应用的核心依赖（数据库、缓存等）是否正常。千万别用首页，因为首页可能加载很多静态资源，响应慢，容易误判。
举个例子，一个典型的健康检查配置：
# ALB 健康检查配置示例
HealthCheckProtocol: HTTP
HealthCheckPort: 8080
HealthCheckPath: /health
HealthCheckIntervalSeconds: 30
HealthCheckTimeoutSeconds: 5
HealthyThresholdCount: 3
UnhealthyThresholdCount: 2避坑指南：我曾经遇到过一个问题——健康检查一直失败，但后端应用明明在正常运行。查了半天发现是安全组没放行健康检查的流量。ALB的健康检查是从它自己的IP段发起的，你得确保安全组允许这些IP访问后端端口。这个坑，我至少见过三次。
4.4 核心逻辑：一张图看懂
下面这张图展示了ALB/NLB跨可用区部署的核心逻辑。你可以看到，负载均衡器在每个可用区都有节点，流量先到节点，然后根据健康检查结果转发到健康的后端实例。
4.5 实战建议：三步走
- 选好可用区：至少3个，分布在不同物理位置。我建议用
us-east-1a、us-east-1b、us-east-1c这种组合。 - 配好健康检查：路径用
/health，间隔30秒，超时5秒。阈值设3次成功、2次失败，这样既灵敏又不会误判。 - 决定是否启用会话保持：如果应用是无状态的，可以关掉。如果有状态，用ALB的基于Cookie的粘性，别用NLB的源IP粘性（除非你清楚它的局限）。
最后说一句：负载均衡的跨可用区部署，是容灾架构的基石。你想想看，如果连流量入口都是单点的，后面再多的多活设计都是白搭。所以，先把ALB/NLB的跨可用区部署搞定，再谈其他的。
公众号:蓝海资料掘金营，微信deep3321