业务量涨到一定程度，单台服务器迟早会遇到性能瓶颈，而且一台机器宕机，整个服务也跟着断。常见的解法是把请求分到多台后端服务器上，负载均衡就是负责这件事的组件。阿里云负载均衡（早期叫 SLB，现统一更名为 CLB）提供四层和七层的流量分发，适合搭建高可用、能弹性扩容的应用架构。下面结合一个电商的假设案例，讲讲选型、配置和日常运维时要留意的地方。
负载均衡到底解决什么问题
用户请求先到达负载均衡实例，再由它按策略转发到一台健康的后端服务器上。接入这一层以后，有三点变化比较直接：
- 吞吐能力：多台机器一起承接流量，节点越多，能处理的请求就越多。
- 单点故障：某台机器挂了，健康检查会把它摘掉，请求转给其他节点。
- 扩缩容：后端节点可以随时增减，前端入口地址不用改，业务代码基本无感。
配置前要先弄清的几个概念
四层还是七层
四层工作在传输层，按 IP 和端口转发，适合 TCP、UDP 这类协议简单、对延迟敏感的服务，比如游戏、数据库代理或长连接服务。七层工作在应用层，能识别 HTTP 和 HTTPS 请求的内容，可以按域名、URL 路径、请求头分流。网站和 API 基本都用七层。
调度算法怎么选
常见的调度算法有三种：
- 加权轮询：按权重依次分配。后端机器配置不一致时用它，让性能更强的机器多分担一些。
- 最少连接：优先发给当前连接数最少的节点。接口耗时差别大的时候，比轮询更稳。
- 源地址哈希：同一来源 IP 固定落到同一台机器，能做简单的会话保持。要注意，如果大量用户都从同一个 NAT 出口访问，请求会集中到少数节点上。
选哪种算法，还是要看业务的实际表现。拿不准的时候，先用加权轮询跑一段时间，再看各节点的负载曲线是否均匀，结果比猜测可靠。
健康检查的参数
健康检查会定时探测后端节点，连续失败到阈值就临时摘除，恢复后再加回来。检查路径、间隔、超时和失败次数，都要按接口的真实响应时间来定。比如接口平均响应 200 毫秒，超时设为 1 秒，连续 3 次失败才判定异常。这样不容易误摘，真正的故障也能较快发现。超时设得太短，接口偶尔抖一下就会被摘除，流量来回跳动，反而更乱。
一个电商大促的改造思路
假设有一家中型电商，平时访问量稳定，大促时会在短时间内涨到十倍以上。他们最早只有两台应用服务器直接对外提供服务，每次大促前都要手动加机器、改配置，而且常常因为某台机器变慢，整个站点跟着卡顿。
改造分三步走。第一步，在阿里云上创建一个公网七层负载均衡实例，把 HTTPS 证书托管在负载均衡上做 SSL 卸载，后端只处理明文 HTTP 请求，服务器省下了加解密的开销。第二步，按业务拆分转发规则：www 域名指向商品前台服务组，api 域名指向接口服务组，路径 /pay 单独指向支付服务组，不同业务之间互不干扰。第三步，给每个服务组配好健康检查和弹性伸缩组，接上云监控告警，后端平均 CPU 超过 70% 时自动扩容。
改完之后，大促前只需要调整伸缩组的最大实例数，入口配置不用再碰。有一次大促，某台应用节点因内存泄漏出现异常，健康检查约十秒内就把它摘掉了，用户基本没有感觉，运维人员随后再去处理这台机器。这个例子里，负载均衡的作用不只是分流，它还让系统在出问题时能自己兜住一部分。
配置时的几条实用建议
- 先定协议：Web 和 API 用七层，数据库、游戏这类非 HTTP 场景用四层。
- 规格留余量：按预估的并发连接数和每秒新建连接数选规格。大促或活动期间的峰值要单独算进去，别只看日常值。
- 超时要对齐：负载均衡的空闲超时应与后端应用的 Keep-Alive 时间保持一致。如果前者比后者短，连接会被提前断开，表现为偶发的 502 或连接重置，排查起来很费劲。
- 留好访问日志：5xx 排查和流量来源分析都要靠它。建议接入日志服务做长期保存，别只留在实例本身上。
- 跨可用区部署：后端节点分布在不同可用区，配合多可用区的负载均衡实例，单个机房出故障时的影响面会小很多。
上线之后盯什么
上线不是终点。日常重点看三类指标：每秒请求数和带宽的变化趋势，后端节点的健康状态，以及 4xx、5xx 错误率。错误率突然抬升时，先查三件事：有没有节点被误摘，证书是不是快过期了，转发规则之间有没有冲突。规则多了以后，两条规则同时匹配同一个请求，最终以哪条为准，要看优先级设置，这一点容易被忽略。
另外，故障切换流程最好定期演练一次。平时练熟了，真出事时才不会手忙脚乱。
