负载均衡（SLB）使用最佳实践——一篇集合负载均衡主要内容的文章
条评论本文转自：https://yq.aliyun.com/articles/80055
可以加深目前生产环境和测试环境中nginx使用的理解。
负载均衡（SLB）使用最佳实践
摘要： 负载均衡（Server Load Balancer，下文简称 SLB）的引入，可以降低单台云服务器 ECS（下文简称 ECS）出现异常时对业务的冲击，提升业务的可用性。同时，结合弹性伸缩服务，通过动态调整后端服务器，可以快速对业务进行弹性调整（扩容或缩容），以快速应对业务的发展。
负载均衡（Server Load Balancer，下文简称 SLB）的引入，可以降低单台云服务器 ECS（下文简称 ECS）出现异常时对业务的冲击，提升业务的可用性。同时，结合弹性伸缩服务，通过动态调整后端服务器，可以快速对业务进行弹性调整（扩容或缩容），以快速应对业务的发展。
本文，会先对 SLB 的使用限制和常见误区进行说明，然后介绍 SLB 的使用最佳实践。
SLB 基础原理
在开始使用 SLB 之前，建议您务必阅读如下文章，了解 SLB 的相关基础原理：
SLB 使用限制
在使用 SLB 进行业务部署之前，请您务必了解 SLB 的相关使用限制，以免对后续使用造成困扰或对业务造成影响。
产品与业务规格限制
SLB 的相关资源或功能存在限制，部分可以通过提交工单申请调整。部分则没有例外，无法调整。详细说明，可以参阅 SLB 使用限制。
另外，后续阿里云会推出性能保障型实例，对实例性能提供保障，用户可配置和查询其具体的性能指标，并可查看其实时运行数据。相关说明可以参阅 产品文档。
技术限制
SLB 在技术层面还在逐步增强和完善，截止本文发稿，还存在如下技术限制：
SLB 常见误区
从历史案例看，用户在 SLB 的规划和使用过程中有很多常见误区。接下来逐一说明。
用户在 SLB 后端只添加一台服务器时，虽然链路能跑通，客户端也能正常访问。但却失去了 SLB 消除 ECS 单点的基本能力。如果这台仅有的 ECS 出现异常，那边整个业务访问也会出现异常。
建议：至少在 SLB 后端加入两台以上 ECS。以便单一服务器出现异常时，业务还能持续正常访问。
用户通过 SLB 访问业务出现异常。但 hosts 绑定后端 ECS 的公网 IP 能正常访问。用户据此推断后端业务是正常的，是 SLB 服务端出现异常导致业务访问异常。
其实，由于负载均衡的数据转发和健康检查都是通过内网进行的。所以，从后端 ECS 的公网 IP 进行对比访问测试，并没有可比性，并不能反应真实访问情况。
建议：出现异常时，在后端 ECS 之间，通过内网 IP 做对比访问测试。
用户通过 ping SLB 的 VIP 地址来判断 SLB 服务的有效性。
其实，这种测试非常不可靠。因为 ping 响应是由 SLB 服务端直接完成的，与后端 ECS 无关。所以，正常情况下：
建议：对于 4 层服务，通过 telnet 监听端口进行业务可用性测试；对于 7 层服务，通过实际的业务访问进行可用性测试。
用户反馈已经调大了健康检查的最大间隔时间，但客户端访还是由于访问超时收到 504 错误。
其实，虽然健康检查及业务转发都是由 SLB 服务端相同的服务器承载，但却是完全不同维度的处理逻辑。来自客户端的请求，经由 SLB 转发给后端 ECS 后，SLB 服务端会有接收数据的超时窗口。而另一方面，SLB 服务端持续的对后端 ECS 根据检查间隔配置进行健康检查。这两者之间没有直接关系，唯一的影响是在后端 ECS 健康检查失败后，SLB 不会再对其进行数据转发。
建议：客户端访问超时时，结合业务与 SLB 默认超时时间进行比对分析；健康检查超时时，结合健康检查与业务超时时间进行比对分析。
用户反馈通过 SLB 后端 ECS 的业务日志进行统计分析，发现健康检查的间隔非常短，与之前在创建监听时配置的健康检查间隔时间不一致。
这个问题在文档 负载均衡健康检查原理浅析 有相关说明：LVS 集群内所有节点，都会独立、并行的遵循该属性去对后端 ECS 进行定期健康检查。由于各 LVS 节点的检查时间并不同步，所以，如果从后端某一 ECS 上进行单独统计，会发现来自负载均衡的健康检查请求在时间上并不会遵循上述时间间隔。
建议：如果健康检查频率过高对业务造成影响，可以参阅知识点 健康检查导致大量日志的处理进行处理。
用户认为 SLB 服务端使用上百台机器进行健康检查，大量健康检查请求会形成 DDoS 攻击，造成后端 ECS 性能降低。
实际上，无论何种模式的健康检查，其规模均不足以达到类似于 DDoS 攻击的量级：SLB 集群会利用多台机器（假定为 M 个，个位数级别），对后端 ECS 的每个服务监听端口 （假定为 N 个） ，按照配置的健康检查间隔（假定为 O 秒，一般建议最少 2 秒）进行健康检查。以 TCP 协议健康检查为例，那么每秒由健康检查产生的 TCP 连接建立数为：
1 | M*N/O |
。
从该公式可以看出，M 和 N 都是固定的，而且值很小。所以，最终健康检查带来的每秒 TCP 并发请求数，主要取决于创建的监听端口数量。所以，除非有巨量的监听端口，否则由健康检查产生的连接请求，根本无法达到 SYN Flood 的攻击级别，实际对后端 ECS 的网络压力也极低。
建议： 如果健康检查频率过高对业务造成影响，可以参阅知识点 健康检查导致大量日志的处理进行处理。
用户为了降低健康检查对业务的影响，将检查间隔时间设置得很长。
这样配置会导致当后端 ECS 出现异常时，负载均衡需要经过较长时间才能侦测到后端 ECS 出现不可用。尤其是当后端 ECS 间歇性不可用时，由于需要【连续多次】检测失败时才会移除异常 ECS。所以，检查间隔过长，会导致负载均衡集群可能根本无法发现后端 ECS 不可用。
建议： 如果健康检查频率过高对业务造成影响，可以参阅知识点 健康检查导致大量日志的处理进行处理。
用户在进行业务调整时，认为直接将服务器从 SLB 后端移除，或将其权重置零即可，两者效果是一样的。
其实，两者有很大区别，相关操作对业务的影响也不一致：
建议：在业务调整或服务器维护时，提前将相应服务器的权重置零，直至连接持续衰减至零。操作完成后，再恢复权重配置，以降低对业务的影响。
误区：单个连接就能达到监听配置的带宽峰值
SLB 在创建监听时可以指定带宽峰值。但用户通过单一客户端进行测试时，发现始终无法达到该峰值。
由于 SLB 是基于集群方式部署和提供服务的。所以，所有前端请求会被均分到集群内不同的 SLB 服务器上进行转发。相应的，在监听上设定的带宽峰值也会被平分后设定到各服务器。因此，单个连接下载的流量上限公式为：
1 | 单个连接下载峰值=设置的负载均衡总带宽/(N-1) |
示例：
假设在控制台上设置的带宽峰值为 10Mb，那么单个客户端可下载的最大流量为：
1 | 10/(4-1)≈3.33Mb |
建议：建议在配置单个监听的带宽峰值时，根据实际的业务情况并结合上述实现方式设定一个较为合理的值，从而确保业务的正常对外服务不会受到影响和限制。
SLB 使用最佳实践
接下来，结合 SLB 的产品特性与历史案例，从多个维度阐述使用 SLB 的最佳实践。
设计业务架构
注：内网环境下，不支持多可用区，只看图例的单边即可。
SLB 在公网环境下的典型业务架构如上图所示。基于多可用区特性，当主可用区出现异常时，SLB 会自动将流量切换到备可用区。但在实际的业务架构设计过程中，建议关注如下要点：
配置监听
如上图所示，SLB 支持创建多种协议监听，然后按转发策略，将前端业务请求转发到后端多种逻辑服务器集。在 SLB 服务配置的各主要步骤中，请关注如下要点。
选择监听协议
SLB 支持创建 TCP/UCP/HTTP/HTTPS 这 4 种协议的监听。您可参考以下表格，根据业务情况选择适合的协议创建监听：
协议类型 建议的应用场景 特性 TCP ●注重可靠性，对数据准确性要求高，速度可以相对较慢的场景；
●示例：文件传输、发送或接收邮件、远程登录、无特殊要求的 Web 应用 ●面向连接的协议；
●在正式收发数据前，必须和对方建立可靠的连接；
●基于源地址会话保持，在网络层可直接看到来源地址；
●监听支持 TCP 和 HTTP 两种方式进行健康检查；
●转发路径短，所以性能比 7 层更好，数据传输速度更快 HTTP 需要对数据内容进行识别的应用，如 Web 应用、小的手机游戏等 ●应用层协议，主要解决如何包装数据；
●基于 Cookie 会话保持；使用 X-Forward-For 获取源地址；
●监听只支持 HTTP 方式健康检查 HTTPS 有更高的安全性需求，需要加密传输的应用 ●加密传输数据，可以阻止未经授权的访问；
●统一的证书管理服务，用户可以将证书上传到负载均衡，解密操作直接在负载均衡上完成 UDP ●关注实时性而相对不注重可靠性的场景；
●示例：视频聊天、金融实时行情推送 ●面向非连接的协议；
●在数据发送前不与对方进行三次握手，直接进行数据包发送，不提供差错恢复和数据重传；
●可靠性相对低；数据传输快
补充说明
SLB 后端服务器支持按 3 种逻辑创建服务器集。要点如下：
集合模式 配置权重 指定服务端口 服务器数量限制 其它特性 后端服务器 支持 不支持 无限制 创建监听时的默认映射服务器集 虚拟服务器组 支持 支持 无限制 有更大的灵活性 主备服务器组 支持 支持 2 台 只能在 TCP/UDP 监听上使用
建议
权重代表相应服务器所承载的业务的相对占比，而非绝对值。当前 SLB 支持 3 种转发策略，其使用场景及要点如下：
转发策略 算法说明 使用要点 加权轮询（WRR） 按比重轮流分配新增连接。 ●根据后端 ECS 规格的不同，配置相应的权重。
●如果是长连接业务，可能会导致老服务器的连接数持续增加， 而新加入服务器的连接数相对非常低，造成负载不均的假象。 加权最小连接数（WLC） ●在 SLB 服务端，实时统计与后端 ECS 已建立的 ESTABLISHED 状态连接数，来评估相应服务器的负载情况。
●按权重比例，将新增连接分配给活动连接数少的服务器，最终尽可能使服务器的已建立连接数与其权重成正例。 当前暂未实现新增服务器的过载保护或缓冲机制。所以，如果业务并发非常高，可能会导致新增服务器连接数陡增，对业务造成影响。建议新增服务器时，逐步调高权重。 轮询（RR） 按顺序逐一分发新增连接。 必须手工确保后端 ECS 的业务承载能力一致。
示例：假设有 100 个新增连接，则在不同的调度算法下，不同服务器的分配连接数示意如下：
服务器 权重 占比 加权轮询 加权最小连接数 轮询 A 50 50/
(100+50+50)
=25% 将 100/*25%=25 个连接分发给服务器 A 实时统计连接数，逐一将新增连接分配给活动连接数最少的服务器。最终使其新增连接数占比大致为 25% 不考虑权重，按顺序分发新增连接到服务器 A/B/C B 100 100/
(100+50+50)
=50% 将 100/*50%=50 个连接分发给服务器 B ↑ 同上，最终使其新增连接数占比大致为 50% ↑ 同上 C 50 50/
(100+50+50)=
25% 将 100/*25%=25 个连接分发给服务器 C ↑ 同上，最终使其新增连接数占比大致为 25% ↑ 同上 D 0 0/
(100+50+50)
=0% 服务器下线，不分配任何连接 ← 同左 ← 同左
健康检查用于实时探测后端 ECS 上的业务可用性，以避免新增连接被分发到异常服务器对业务造成影响。由于是 SLB 依赖的核心服务，所以 4 层协议（TCP/UCP）的健康检查无法关闭。
在配置健康检查时，注意如下要点：
- 合理配置健康检查间隔
根据实际业务需求配置健康检查间隔，避免因为健康检查间隔过长导致无法及时发现后端 ECS 出现问题。具体请参考：健康检查的相关配置，是否有相对合理的推荐值？
在后端 ECS 的选择与配置时，注意如下要点：
调整后端 ECS 的操作建议
在往 SLB 内新增服务器时，注意如下要点：
在后端 ECS 服务器的日常调整、维护过程中，注意如下要点：
如果确认服务器不再使用，不建议直接移除服务器。而是参阅前述步骤，将相应服务器权重置零。待已建立连接全部正常断开后，再移除该服务器。
常见问题的排查思路
SLB 在使用过程中的常见问题与排查思路可以参阅下列文档，本文不再详述：
典型案例
后端 ECS 负载不均
问题场景：
后端 ECS 规格均一致，但其中几台服务器的 PPS 一直非常高。而新加入的服务器，相对负载非常低。
业务高峰期，相关服务器健康检查异常，导致服务器下线，并进一步导致其它服务器负载升高，引发整个 SLB 后端出现雪崩式异常，业务受到严重影响。
排查思路：
应对措施：
以上步骤用于将负载逐步转移到新加入的服务器，并避免对新增服务器及异常服务器的冲击。
