很多团队第一次接触云上流量分发时，注意力往往放在服务器数量上，负载均衡本身的配置反而被忽略。同样是三台应用服务器，监听规则、健康检查和调度算法填得是否得当，服务稳定性会差很多。本文以一个电商站点的改造为例，说明阿里云负载均衡配置中几个关键项该怎么填，适合正在搭建或优化架构的同学参考。
改造前的状况
这个站点原本由一台公网ECS直接对外提供服务。大促期间，单机CPU长期满载，进程一旦崩溃，用户会直接看到502错误。运维同学曾在前面手动加了一层Nginx做转发，但Nginx本身成了单点，证书更新还要登录每台机器逐一操作，维护起来很费劲。
后来团队决定把入口统一交给负载均衡实例，后端保留三台ECS，分布在两个可用区。
创建实例时要先想清楚的三件事
在控制台创建负载均衡实例时，有三个选项最好提前定下来：
- 实例网络类型：面向互联网的业务选公网类型；内部服务之间相互调用则选私网类型，省掉不必要的公网带宽开销。
- 主备可用区：开启多可用区部署后，单个机房故障时实例可以自动切换，对可用性的帮助很直接。
- 计费方式：流量波动大的站点可以考虑按流量计费；带宽比较稳定的业务，按带宽计费更合适。
这次改造选了公网类型，开启主备可用区，计费方式为按流量计费。原因很简单，活动期间的流量峰值是平时的数倍，按流量算更划算。
监听规则怎么设
监听决定实例接收哪种协议的请求，以及把请求转发到哪个端口。这次配置了两条监听：
- HTTP 80端口：只负责接收请求并跳转到HTTPS，不承载业务流量。
- HTTPS 443端口：绑定证书，把请求转发到后端服务器组的8080端口。
证书可以在证书管理服务里统一上传或申请，绑定到监听之后，续期时只需替换证书，后端机器一台都不用动。对要维护多台服务器的团队来说，这一步能省下大量重复操作。
调度算法和后端服务器
后端服务器可以放进虚拟服务器组统一管理。常见的调度算法有三种，各自适合的场景不同：
- 加权轮询：后端机器配置接近时用，最简单，也最容易预测。
- 加权最小连接：请求处理时长差异大时用，连接少的机器会优先接新请求。
- 源地址哈希：需要同一个来源IP固定落到同一台机器时用。
这次三台ECS配置相同，选了加权轮询，权重都设为100。之后给新扩容的机器放量时，把它的权重从10逐步调高，观察负载情况，再决定是否继续加。新机器刚上线时流量一下子涌进去，很容易出问题，这个小习惯能避开不少麻烦。
健康检查是最容易被忽略的一项
健康检查决定负载均衡会不会把请求发给一台已经出故障的机器。很多人保留默认配置就直接上线，结果应用卡死了，进程还在监听端口，检查照样通过，用户请求却持续失败。
检查路径最好单独设计一个轻量接口，比如/healthz。这个接口要真实检查数据库连接等关键依赖，只返回200是不够的。检查间隔、超时时间和不健康阈值则要结合业务的响应时间来定。这次的设置是间隔5秒、超时3秒、连续3次失败才摘除节点。这样故障能很快被发现，网络抖动也不至于把正常节点误摘掉。
会话保持和访问控制
用户登录后，如果会话落在不同服务器上，就容易出现频繁掉线。这次开启了基于cookie的会话保持，让同一用户在一段时间内访问同一台后端。不过会话保持会削弱负载的均衡程度，只在确实需要的场景下开启，别顺手就打开。
后台管理入口则通过访问控制设置IP白名单，只允许办公网段访问，减少暴露面。
上线后怎么验证
配置完成后，可以按下面几步检查：
- 逐台停掉一台后端服务，看健康检查能否在设定时间内摘除这台节点，同时用户访问是否基本无感。
- 用curl携带Host头访问HTTP地址，确认返回的是301跳转到HTTPS。
- 查看负载均衡的监控指标，重点关注活跃连接数和后端异常状态码，判断流量是否分布均匀。
如果所有后端都显示异常，先看两处。一是安全组有没有放行负载均衡的回源网段，二是健康检查路径是否返回了预期的状态码。首次配置时，这两类问题最常见。
结果
改造之后，站点在活动期间没有再因为单机故障出现整体中断，证书也改为集中管理。整套配置里，监听、健康检查和调度策略需要互相对得上，其中任何一项填错，都会影响最终效果。正式上线前，建议先用真实流量做一次小范围灰度，确认没问题后再逐步放量。
