一、SLB概念

负载均衡（Server Load Balancer）是将访问流量根据转发策略分发到后端多台云服务器（Elastic Compute Service，简称 ECS）的流量分发控制服务。

负载均衡服务通过设置虚拟服务地址，将位于同一地域的多台ECS实例虚拟成一个高性能、高可用的应用服务池；再根据应用指定的方式，将来自客户端的网络请求分发到云服务器池中。负载均衡服务是ECS面向多机方案的一个配套服务，需要同ECS结合使用。

负载均衡服务会检查云服务器池中ECS实例的健康状态，自动隔离异常状态的ECS实例，从而解决了单台ECS实例的单点问题，提高了应用的整体服务能力。在标准的负载均衡功能之外，负载均衡服务还具备TCP与HTTP抗DDoS攻击的特性，增强了应用服务的防护能力。

组成部分

负载均衡服务由负载均衡实例、监听和后端服务器三个部分组成。
负载均衡实例 （Server Load Balancer Instance）
如果您想使用负载均衡服务，必须先创建一个负载均衡实例。一个负载均衡实例可以添加多个监听和后端服务器。
监听 （Listener）
在使用负载均衡服务前，您必须为负载均衡实例添加一个监听，指定监听规则和转发策略，并配置健康检查。
针对不同的需求，您可以单独配置四层（TCP/UDP）或七层（HTTP/HTTPS）监听。
后端服务器（Backend Server）
一组接收前端请求的ECS实例。您可以单独添加ECS实例到服务器池，也可以通过虚拟服务器组或主备服务器组来批量添加和管理。
默认后端服务器是在实例维度上维护的，即负载均衡实例下的所有监听都只能够将请求转发到相同ECS实例的相同端口上。虚拟服务器组功能实现了监听维度的转发。您可以针对不同的监听创建不同的虚拟服务器组，即负载均衡实例中的不同监听可以将请求转发到不同端口的后端服务器上。
此外，七层负载均衡服务支持域名、URL转发策略，可以将来自不同域名或者URL的请求转发给不同的后端服务器处理。

二、使用限制

2.1 在 4 层（TCP 协议）服务中，不支持添加进后端云服务器池的 ECS 既作为 Real Server，又作为客户端向所在的 SLB 实例发送请求。因为，返回的数据包只在云服务器内部转发，不经过负载均衡，所以通过配置在 SLB 后端的 ECS 去访问其 VIP 是不通的。
2.2 仅支持 TCP/UDP（4 层） 和 HTTP/HTTPS（7 层） 这 4 种协议。
2.3 后端服务器仅支持 ECS，不支持第三方云服务器。
2.4 仅支持轮询（RR）、加权轮询（WRR）和最小加权连接数（WLC）这 3 中调度算法。
2.5 不支持 7 层 SSL Session 超时时间的调整。当前全局统一为 300s。
2.6 不支持 7 层 HTTP Keep-alive 超时时间的调整。当前配置为 15s。

说明：如果客户端访问 SLB HTTP 监听时使用长连接, 那么这条连接最长的空闲时间为 15 秒, 即如果超过 15 秒没有发送任何 HTTP 请求, 这条连接将会被 SLB 主动断开。如果您的业务可能会出现超过 15 秒的空闲, 需要从业务层面检测连接的断开并重新发起连接。

2.7 不支持转发超时时间的调整：

当前配置： TCP 900s，UDP 300s，HTTP 60s，HTTPS 60s
上述配置是指 SLB 服务端从后端接收数据并进行转发的超时时间，并非健康检查超时时间间隔。如果超时，通常会向客户端返回 504 错误码。

2.8 金融云 SLB 基于安全性考虑，仅允许开放特定的端口：80，443，2800-3300，6000-10000，13000-14000

三、SLB使用误区

3.1 SLB后端只添加一台ECS

用户在 SLB 后端只添加一台服务器时，虽然链路能跑通，客户端也能正常访问。但却失去了 SLB 消除 ECS 单点的基本能力。如果这台仅有的 ECS 出现异常，那边整个业务访问也会出现异常。

建议：至少在 SLB 后端加入两台以上 ECS。以便单一服务器出现异常时，业务还能持续正常访问。

3.2 后端 ECS 能正常访问，但 SLB 无法访问，则说明 SLB 出现了异常

用户通过 SLB 访问业务出现异常。但 hosts 绑定后端 ECS 的公网 IP 能正常访问。用户据此推断后端业务是正常的，是 SLB 服务端出现异常导致业务访问异常。

其实，由于负载均衡的数据转发和健康检查都是通过内网进行的。所以，从后端 ECS 的公网 IP 进行对比访问测试，并没有可比性，并不能反应真实访问情况。

建议：出现异常时，在后端 ECS 之间，通过内网 IP 做对比访问测试。

3.3 SLB 的 VIP 能 ping 通就说明配置是正常的

用户通过 ping SLB 的 VIP 地址来判断 SLB 服务的有效性。

其实，这种测试非常不可靠。因为 ping 响应是由 SLB 服务端直接完成的，与后端 ECS 无关。所以，正常情况下：

只要配置了任意监听，即便相应监听处于异常状态，SLB VIP ping 也是正常的。
相反，如果 SLB 没有配置任何监听，其 VIP 是 ping 不通的。

建议：对于 4 层服务，通过 telnet 监听端口进行业务可用性测试；
对于 7 层服务，通过实际的业务访问进行可用性测试。

3.4 已经调整了健康检查间隔，结果还会出现访问超时

用户反馈已经调大了健康检查的最大间隔时间，但客户端访还是由于访问超时收到 504 错误。

其实，虽然健康检查及业务转发都是由 SLB 服务端相同的服务器承载，但却是完全不同维度的处理逻辑。来自客户端的请求，经由 SLB 转发给后端 ECS 后，SLB 服务端会有接收数据的超时窗口。而另一方面，SLB 服务端持续的对后端 ECS 根据检查间隔配置进行健康检查。这两者之间没有直接关系，唯一的影响是在后端 ECS 健康检查失败后，SLB 不会再对其进行数据转发。

建议：客户端访问超时时，结合业务与 SLB 默认超时时间进行比对分析；健康检查超时时，结合健康检查与业务超时时间进行比对分析。

3.5 从后端日志看，健康检查间隔与监听配置的间隔时间不一致

用户反馈通过 SLB 后端 ECS 的业务日志进行统计分析，发现健康检查的间隔非常短，与之前在创建监听时配置的健康检查间隔时间不一致。

这个问题在文档 负载均衡健康检查原理浅析 有相关说明：LVS 集群内所有节点，都会独立、并行的遵循该属性去对后端 ECS 进行定期健康检查。由于各 LVS 节点的检查时间并不同步，所以，如果从后端某一 ECS 上进行单独统计，会发现来自负载均衡的健康检查请求在时间上并不会遵循上述时间间隔。

建议：如果健康检查频率过高对业务造成影响，可以参阅知识点 健康检查导致大量日志的处理 进行处理。

3.6 大量健康检查形成 DDoS 攻击，导致服务器性能下降

用户认为 SLB 服务端使用上百台机器进行健康检查，大量健康检查请求会形成 DDoS 攻击，造成后端 ECS 性能降低。

实际上，无论何种模式的健康检查，其规模均不足以达到类似于 DDoS 攻击的量级：SLB 集群会利用多台机器（假定为 M 个，个位数级别），对后端 ECS 的每个服务监听端口 （假定为 N 个） ，按照配置的健康检查间隔（假定为 O 秒，一般建议最少 2 秒）进行健康检查。以 TCP 协议健康检查为例，那么每秒由健康检查产生的 TCP 连接建立数为：M*N/O。

从该公式可以看出，M 和 N 都是固定的，而且值很小。所以，最终健康检查带来的每秒 TCP 并发请求数，主要取决于创建的监听端口数量。所以，除非有巨量的监听端口，否则由健康检查产生的连接请求，根本无法达到 SYN Flood 的攻击级别，实际对后端 ECS 的网络压力也极低。

建议： 如果健康检查频率过高对业务造成影响，可以参阅知识点 健康检查导致大量日志的处理 进行处理。

3.7 用户为了降低健康检查的影响，将健康检查间隔设置得很长

这样配置会导致当后端 ECS 出现异常时，负载均衡需要经过较长时间才能侦测到后端 ECS 出现不可用。尤其是当后端 ECS 间歇性不可用时，由于需要【连续多次】检测失败时才会移除异常 ECS。所以，检查间隔过长，会导致负载均衡集群可能根本无法发现后端 ECS 不可用。

3.8 移除服务器与权重置零的效果是一样的

移除服务器：已经建立的连接会一并中断，新建连接也不会再转发到该 ECS。
权重置零：已经建立的连接不会中断，直至超时或主动断开。新连接不会转到该 ECS。

建议：在业务调整或服务器维护时，提前将相应服务器的权重置零，直至连接持续衰减至零。操作完成后，再恢复权重配置，以降低对业务的影响。

3.9 单个连接就能达到监听配置的带宽峰值

SLB 在创建监听时可以指定带宽峰值。但用户通过单一客户端进行测试时，发现始终无法达到该峰值。

由于 SLB 是基于集群方式部署和提供服务的。所以，所有前端请求会被均分到集群内不同的 SLB 服务器上进行转发。相应的，在监听上设定的带宽峰值也会被平分后设定到各服务器。因此，单个连接下载的流量上限公式为：

单个连接下载峰值=设置的负载均衡总带宽/(N-1) 
*注：N 为流量转发分组个数，当前值一般为 4

假设在控制台上设置的带宽峰值为 10Mb，那么单个客户端可下载的最大流量为： 10/(4-1)≈3.33Mb

建议：建议在配置单个监听的带宽峰值时，根据实际的业务情况并结合上述实现方式设定一个较为合理的值，从而确保业务的正常对外服务不会受到影响和限制。

3.10 阿里云web应用防火墙（WAF）+SLB回话保持不生效

在流量入口为防护网址添加waf，waf作为反向代理在slb如果配置四层tcp/udp端口监听，可能存在后端web应用回话保持不生效，七层使用cookie可以解决，但是由于业务可能存在限制必须使用四层端口，此时可以在阿里后台提交工单申请开启waf回话保持缓存解决。

四、SLB最佳实践

4.1 业务架构

SLB 在公网环境下的典型业务架构如上图所示。基于多可用区特性，当主可用区出现异常时，SLB 会自动将流量切换到备可用区。但在实际的业务架构设计过程中，建议关注如下要点：

为了降低延迟，建议选择离您客户最近的地域进行 SLB 部署。
并非所有区域都支持多可用区特性（具体支持情况以您在控制台所见为准），请您结合业务情况选择合适的可用区。
在配合使用多可用区特性时，后端 ECS 也必须同时在相应的主备可用区部署，才能保障出现异常时，相应可用区有 ECS 能进行业务承载。

4.2 监听配置

如上图所示，SLB 支持创建多种协议监听，然后按转发策略，将前端业务请求转发到后端多种逻辑服务器集。在 SLB 服务配置的各主要步骤中，请关注如下要点。

选择监听协议

并非只要 Web 网站就必须使用 HTTP 协议。大部分没有特殊 HTTP 要求的 Web 网站，使用 TCP 监听 80 端口就可以满足业务需求。
SLB 集群采用 LVS 和 Tengine 实现。其中 4 层监听（TCP/UDP）经过 LVS 后直接到达后端服务器，而 7 层监听（HTTP/HTTPS）经过 LVS 后，还需要再经过 Tengine 转发，最后达到后端服务器，由于比 4 层多了一个处理环节。因此，7 层监听的性能相对要差一些。

按业务逻辑创建不同的虚拟服务器组，然后创建相应的监听与之对应。
无论创建何种服务器集合，均结合 SLB 多可用区特性，同时加入位于不同可用区的服务器，以实现跨可用区容灾。
设置过多转发规则会增加业务维护的复杂度，建议尽量精简策略条目。

选择转发策略

权重代表相应服务器所承载的业务的相对占比，而非绝对值。当前 SLB 支持 3 种转发策略，其使用场景及要点如下：

五、建议

• 在同一个服务器集中，同时加入不同可用区的服务器，以实现同城容灾
• 根据服务器规格的差异，配置与之成正比的权重
• SLB 后端最少配置两台以上 ECS，以避免单台 ECS 出现异常导致整个业务也出现异常
• 后端 ECS 建议无状态部署：即只用于计算，而数据调用与存储后连至后端的 OSS、RDS 等公共服务。这样可以无需为 ECS 之间的数据同步问题而困扰。
• 建议基于相同的镜像或自定义镜像创建后端 ECS 服务器，以保障配置的一致性。
• 后端 ECS 归属安全组及系统内部防火墙必须对 SLB 服务端地址段进行访问放行。