负载均衡是现代Web架构的基石，而ELB（Elastic Load Balancing）作为云平台上的托管负载均衡服务，能够让跨可用区高可用与弹性伸缩这两件事变得简单。不过简单不等于随便配，不少团队在上线后才发现健康检查误判、扩容不及时等问题。本文从架构设计讲到具体配置，把关键参数和常见坑点一次性说清楚。
一、为什么跨可用区高可用是架构刚需
可用区（Availability Zone）是同一地域内电力和网络相互独立的物理分区。单可用区部署意味着一台物理设备故障、一次机房维护，都可能导致服务完全不可用。跨可用区部署的本质，是把故障域从地域级别缩小到可用区级别，配合ELB的健康检查与自动摘除机制，实现故障时流量在数秒内切换。
要实现这一点，ELB侧需要满足两个条件：第一，ELB本身必须是多可用区的，即在创建时选择至少两个子网，每个子网位于不同的可用区；第二，后端服务器要在各可用区内均匀分布，避免出现一个可用区挂了8台、另一个可用区只挂2台的失衡情况——这种失衡在故障切换时会导致剩余节点瞬间过载。
以AWS的Application Load Balancer为例，创建时指定多个子网的命令如下：
aws elbv2 create-load-balancer \ --name my-alb \ --subnets subnet-aaaaaaa1 subnet-bbbbbbb2 \ --security-groups sg-0123456789abcdef0 # 两个子网分别位于不同的可用区，ELB会在每个可用区分配一个负载均衡节点
这里有一个容易被忽略的细节：跨可用区流量分发（Cross-Zone Load Balancing）。开启后，ELB会把流量均匀分到所有后端服务器上，而不管服务器在哪个可用区；不开启时，流量只在同一可用区内的后端之间分发。经典负载均衡器（CLB）默认关闭且仅在跨可用区开启时对ALB生效，而ALB默认是开启的，Network Load Balancer则默认关闭。如果后端分布在三个可用区但某个可用区实例很少，关闭跨可用区分发会造成明显的流量倾斜，这一点在NLB场景要特别留意。
二、健康检查配置：高可用的关键阀门
健康检查决定了哪些节点能接流量。配置得过严，网络抖动一下就误判节点下线；配置得过松，真正死掉的进程还在接请求，用户体验直接崩坏。核心参数包括检查路径、间隔、超时、健康阈值和不健康阈值。
检查路径建议指向一个轻量的专用端点，比如/healthz，这个端点只做存活探测，不要连数据库、不要查缓存，否则后端依赖故障时会引发全量节点被摘除的雪崩。间隔和阈值的组合决定了故障检测时间，计算公式为：故障检测时间 ≈ 不健康阈值 × 检查间隔。例如间隔10秒、不健康阈值3次，故障节点会在30秒左右被摘除。对于高并发服务，可以缩短到间隔5秒、阈值2次，把切换时间压缩到10秒内。
典型的健康检查配置示例：
aws elbv2 create-target-group \ --name my-tg \ --protocol HTTP \ --port 8080 \ --vpc-id vpc-0abc123 \ --health-check-protocol HTTP \ --health-check-path /healthz \ --health-check-interval-seconds 10 \ --health-check-timeout-seconds 5 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 3
另一个高频踩坑点是返回码。默认情况下2xx被视为健康，如果健康端点做了重定向，返回301或302就会被判为不健康。可以通过--matcher HttpCode=200,301显式声明可接受的状态码，避免误判。同时建议给健康检查配置专门的响应内容匹配，比如返回体中包含ok字段，双重校验比单纯依赖状态码可靠得多。
三、弹性伸缩：三种模式的选型与配置
有了高可用底座，接下来解决容量问题。弹性伸缩的核心是Auto Scaling组配合伸缩策略，策略分三种：目标追踪、步进伸缩和预测伸缩，选型不当会导致要么扩容慢半拍，要么成本失控。
目标追踪是最省心的方式，你告诉系统期望的指标水位，系统自动计算需要扩多少台。比如设定CPU目标值为60%，指标超过60%就扩容，低于则缩容。它的优势是不需要手动维护扩容规则，适合流量模式相对规律的业务：
aws autoscaling put-scaling-policy \
--auto-scaling-group-name my-asg \
--policy-name cpu-target-tracking \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{
"TargetValue": 60.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ASGAverageCPUUtilization"
}
}'
步进伸缩适合流量突增剧烈的场景，比如秒杀、大促。它根据指标偏离程度执行不同力度的动作，CPU超过70%加2台，超过90%加5台，扩容幅度随告警严重程度递增，比目标追踪响应更快。而预测伸缩基于历史流量数据用机器学习提前扩容，对每日、每周呈现明显周期性的业务（比如在线教育的高峰在晚间）效果最好，通常与目标追踪组合使用，预测部分兜底基线容量，目标追踪处理突发。
无论用哪种模式，冷却时间都不能忽视。冷却时间内伸缩组不会执行新的扩容活动，默认300秒。设得太短，会导致上一轮扩容的实例还没完成预热就触发下一轮，过度扩容；设得太长，突发流量来不及响应。另外配合ELB时一定要配置实例预热时间，新实例注册到目标组后需要接收预热时长的流量加权，避免刚启动、JVM还没热身完毕的实例被打垮。
四、落地时的几个实战建议
第一，伸缩组的最小容量至少等于可用区数量。比如三个可用区、最小容量设为3，保证每个可用区至少一台实例，否则高可用无从谈起。第二，缩容保护策略要配合连接排空，实例被终止前给ELB一段时间完成存量请求，ALB默认300秒，长连接业务要适当调大。第三，弹性伸缩依赖的指标维度要选对，CPU利用率对计算密集型服务有效，但IO密集型服务CPU常年不高，应该改用请求计数或自定义业务指标（如队列长度）作为伸缩信号。
第四，定期做故障演练。手动把某个可用区的实例全部终止，观察ELB摘除节点、伸缩组补充容量的整个链路是否符合预期。没有经过演练验证的高可用架构，只能算是纸面上的高可用。把跨可用区分发、健康检查、伸缩策略、预热时间这四项配置梳理成检查清单，每次上线前过一遍，系统的稳定性就有了实实在在的保障。