SLB负载均衡实践
SLB基础认知
负载均衡（Server Load Balancer，下文简称 SLB）的引入，可以降低单台云服务器 ECS（下文简称 ECS）出现异常时对业务的冲击，提升业务的可用性。同时，结合弹性伸缩服务，通过动态调整后端服务器，可以快速对业务进行弹性调整（扩容或缩容），以快速应对业务的发展。
组成部分
负载均衡服务由负载均衡实例、监听和后端服务器三个部分组成。
- 负载均衡实例 （Server Load Balancer Instance）
如果您想使用负载均衡服务，必须先创建一个负载均衡实例。一个负载均衡实例可以添加多个监听和后端服务器。
- 监听 （Listener）
在使用负载均衡服务前，您必须为负载均衡实例添加一个监听，指定监听规则和转发策略，并配置健康检查。
针对不同的需求，您可以单独配置四层（TCP/UDP）或七层（HTTP/HTTPS）监听。
- 后端服务器（Backend Server）
一组接收前端请求的ECS实例。您可以单独添加ECS实例到服务器池，也可以通过虚拟服务器组或主备服务器组来批量添加和管理。
默认后端服务器是在实例维度上维护的，即负载均衡实例下的所有监听都只能够将请求转发到相同ECS实例的相同端口上。虚拟服务器组功能实现了监听维度的转发。您可以针对不同的监听创建不同的虚拟服务器组，即负载均衡实例中的不同监听可以将请求转发到不同端口的后端服务器上。
此外，七层负载均衡服务支持域名、URL转发策略，可以将来自不同域名或者URL的请求转发给不同的后端服务器处理。
准备工作
- 两台部署了相关服务的ecs实例（作为后端服务器）
- 开通了SLB服务实例
SLB 使用最佳实践
接下来，结合 SLB 的产品特性与历史案例，从多个维度阐述使用 SLB 的最佳实践。
设计业务架构
注：内网环境下，不支持多可用区，只看图例的单边即可。
SLB 在公网环境下的典型业务架构如上图所示。基于多可用区特性，当主可用区出现异常时，SLB 会自动将流量切换到备可用区。但在实际的业务架构设计过程中，建议关注如下要点：
-
实例类型与计费方式
- 如果只用于内部服务分发，则创建私网实例即可。
- 按流量计费，适用于波峰波谷效应明显的业务。
- 按带宽计费，适用于带宽较为平稳的业务。
-
区域与多可用区
- 为了降低延迟，建议选择离您客户最近的地域进行 SLB 部署。
- 并非所有区域都支持多可用区特性（具体支持情况以您在控制台所见为准），请您结合业务情况选择合适的可用区。
- 在配合使用多可用区特性时，后端 ECS 也必须同时在相应的主备可用区部署，才能保障出现异常时，相应可用区有 ECS 能进行业务承载。
配置监听
如上图所示，SLB 支持创建多种协议监听，然后按转发策略，将前端业务请求转发到后端多种逻辑服务器集。在 SLB 服务配置的各主要步骤中，请关注如下要点。
选择监听协议
SLB 支持创建 TCP/UCP/HTTP/HTTPS 这 4 种协议的监听。您可参考以下表格，根据业务情况选择适合的协议创建监听：
| 协议类型 | 建议的应用场景 | 特性 |
|---|---|---|
| TCP | ●注重可靠性，对数据准确性要求高，速度可以相对较慢的场景； ●示例：文件传输、发送或接收邮件、远程登录、无特殊要求的 Web 应用 | ●面向连接的协议； ●在正式收发数据前，必须和对方建立可靠的连接； ●基于源地址会话保持，在网络层可直接看到来源地址； ●监听支持 TCP 和 HTTP 两种方式进行健康检查； ●转发路径短，所以性能比 7 层更好，数据传输速度更快 |
| HTTP | 需要对数据内容进行识别的应用，如 Web 应用、小的手机游戏等 | ●应用层协议，主要解决如何包装数据； ●基于 Cookie 会话保持；使用 X-Forward-For 获取源地址； ●监听只支持 HTTP 方式健康检查 |
| HTTPS | 有更高的安全性需求，需要加密传输的应用 | ●加密传输数据，可以阻止未经授权的访问； ●统一的证书管理服务，用户可以将证书上传到负载均衡，解密操作直接在负载均衡上完成 |
| UDP | ●关注实时性而相对不注重可靠性的场景； ●示例：视频聊天、金融实时行情推送 | ●面向非连接的协议； ●在数据发送前不与对方进行三次握手，直接进行数据包发送，不提供差错恢复和数据重传； ●可靠性相对低；数据传输快 |
补充说明
- 并非只要 Web 网站就必须使用 HTTP 协议。大部分没有特殊 HTTP 要求的 Web 网站，使用 TCP 监听 80 端口就可以满足业务需求。
- SLB 集群采用 LVS 和 Tengine 实现。其中 4 层监听（TCP/UDP）经过 LVS 后直接到达后端服务器，而 7 层监听（HTTP/HTTPS）经过 LVS 后，还需要再经过 Tengine 转发，最后达到后端服务器，由于比 4 层多了一个处理环节。因此，7 层监听的性能相对要差一些。
选择后端服务器集模式
SLB 后端服务器支持按 3 种逻辑创建服务器集。要点如下：
| 集合模式 | 配置权重 | 指定服务端口 | 服务器数量限制 | 其它特性 |
|---|---|---|---|---|
| 后端服务器 | 支持 | 不支持 | 无限制 | 创建监听时的默认映射服务器集 |
| 虚拟服务器组 | 支持 | 支持 | 无限制 | 有更大的灵活性 |
| 主备服务器组 | 支持 | 支持 | 2 台 | 只能在 TCP/UDP 监听上使用 |
建议
- 按业务逻辑创建不同的虚拟服务器组，然后创建相应的监听与之对应。
- 无论创建何种服务器集合，均结合 SLB 多可用区特性，同时加入位于不同可用区的服务器，以实现跨可用区容灾。
- 设置过多转发规则会增加业务维护的复杂度，建议尽量精简策略条目。
选择转发策略
权重代表相应服务器所承载的业务的相对占比，而非绝对值。当前 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）的健康检查无法关闭。
在配置健康检查时，注意如下要点：
-
根据业务情况合理选择 TCP 或 HTTP 模式健康检查
- TCP 模式健康检查只能检查端口的可用性，对 7 层 HTTP 状态无法感知。所以，Web 类 7 层业务建议配置 HTTP 模式健康检查。
- TCP 模式健康检查由于在连接建立后即主动发送 RST 断开连接，所以可能会导致业务层面认为是非正常中断，导致产生大量相关联的错误日志。该问题可以参阅 健康检查导致大量日志的处理 进行处理。
- 如果使用 HTTP 健康检查模式，建议合理调整后端日志配置，避免健康检查 HEAD 请求过多对 IO 性能造成影响。
- 合理配置健康检查间隔
根据实际业务需求配置健康检查间隔，避免因为健康检查间隔过长导致无法及时发现后端 ECS 出现问题。具体请参考：健康检查的相关配置，是否有相对合理的推荐值？ -
合理配置检查端口与检查 URL
- 对于 4 层 TCP 协议，由于虚拟服务器组可以由后端 ECS 不同的端口承载业务，因此在配置健康检查时不要设置检查端口，而应该"默认使用后端服务器的端口进行健康检查"。否则可能导致后端 ECS 健康检查失败。
- 对于 7 层 HTTP 协议，使用虚拟服务器组合转发策略时，确保健康检查配置策略中的 URL 在后端每台机器上都可以访问成功。
- 使用 HTTP 模式健康检查时，不要对根目录进行检查。建议配置为对某个静态页面或文件进行检查以降低对主页的冲击。但是，相应的，这可能会导致误判：健康检查 URL 虽然访问是正常的，但主页实际上已经出现异常。
-
UDP 健康检查
当前 UDP 协议健康检查可能存在服务真实状态与健康检查不一致的问题：- 如果后端 ECS 服务器是 Linux 服务器，在大并发场景下，由于 Linux 的防 ICMP 攻击保护机制，会限制服务器发送 ICMP 的速度。此时，即便服务已经出现异常，但由于无法向前端返回 “port XX unreachable” 报错信息，会导致负载均衡由于没收到 ICMP 应答进而判定健康检查成功，最终导致服务真实状态与健康检查不一致。
- 如果相应服务器非正常关机，由于也不会返回 “port XX unreachable” 报错信息。所以也会导致健康检查处于"正常"状态的误报。
选择与配置后端 ECS
在后端 ECS 的选择与配置时，注意如下要点：
- 在同一个服务器集中，同时加入不同可用区的服务器，以实现同城容灾
- 根据服务器规格的差异，配置与之成正比的权重
- SLB 后端最少配置两台以上 ECS，以避免单台 ECS 出现异常导致整个业务也出现异常
- 后端 ECS 建议无状态部署：即只用于计算，而数据调用与存储后连至后端的 OSS、RDS 等公共服务。这样可以无需为 ECS 之间的数据同步问题而困扰。
- 建议基于相同的镜像或自定义镜像创建后端 ECS 服务器，以保障配置的一致性。
- 后端 ECS 归属安全组及系统内部防火墙必须对 SLB 服务端地址段进行访问放行。
调整后端 ECS 的操作建议
新增后端服务器
在往 SLB 内新增服务器时，注意如下要点：
- 建议新增服务器时，将权重置零，在确保业务正常运行后，再调整权重使其上线。
- 如果业务是长连接，在新增服务器时，建议先将相应监听的调度算法修改为轮询模式，然后逐步调高新增服务器的权重，以降低对该新增服务器的过高冲击。
调整、维护业务和后端服务器
在后端 ECS 服务器的日常调整、维护过程中，注意如下要点：
- 选择合适的业务窗口，定期对后端 ECS 进行重启操作（操作前先创建快照进行备份），以便应用系统补丁，并主动触发、感知系统内部错误导致的服务器无法正常启动等问题。
-
业务更新或系统维护时建议的操作步骤：
1.将相应 ECS 的权重置零。此时，已建立的连接不受影响，新增连接不会再分发到该服务器。 2.周期性的在系统内通过 netstat/ss 等指令，确保已建立连接逐步自动断开，衰减置零。如果客户端有自动重连机制，则根据业务情况也可以忽略本步骤。 3.对服务器进行快照备份。 4.进行业务调整、服务器配置、重启等操作。 5.操作完毕后，确认业务重新正常上线。然后逐步调高服务器权重，使其重新上线。 6.逐一对服务器集内所有服务器按上述步骤进行维护。
移除服务器
如果确认服务器不再使用，不建议直接移除服务器。而是参阅前述步骤，将相应服务器权重置零。待已建立连接全部正常断开后，再移除该服务器。
负载均衡配置
本小节的主要内容：将两台服务器挂载到负载均衡的后端，这样，用户只需访问一个IP地址或域名，负载均衡服务器将会根据权重自动转发用户请求到相应的后端服务器上。
1. 通过如下步骤，查看阿里云负载均衡控制台：
1）点击左侧导航栏处的 云产品资源 查看资源信息，点击 一键复制url，用浏览器隐身窗口（或无痕模式）登录控制台，
2）输入实验提供的 子用户名称 和 子用户密码 ，完成后点击 登录 。登录阿里云管理控制台。
3）点击左侧导航栏的 产品与服务 ，下拉菜单中，在 弹性计算 条目下选择 负载均衡 。
2. 点击左侧的 实例管理 ，然后打开实验提供的实例，在实例列表页面，点击目标实例右侧的 点我开始配置 。
3. 通过负载均衡业务配置向导，配置负载均衡的 监听端口、后端服务器 和 健康检查 ：
1）在 协议&监听 页面，输入如下信息，完成后，点击 下一步 。
- 负载均衡协议：选择 HTTP
- 监听端口：设为 80
- 高级配置保持默认
2）在 后端服务器 页面，监听请求转发至 默认服务器组，在已添加服务器处点击 继续添加 。
3）在弹出的待添加服务器页面，在预先配置好的两台云服务器前打勾选择，然后点击下一步，之后再点击 添加；
4）在后端服务器界面的已添加服务器列表中，可以看到新增的两台云服务器，分别将 端口 设置为 80，并点击 下一步 。
说明：负载均衡器将会按照输入的权重比例分发请求。
5）在 健康检查 配置中，开启健康检查按钮为绿色 开启状态，点击 下一步。
6）在 配置审核 页面，确认上述配置操作正确，点击 提交；出现如下界面，提示配置成功后，点击 知道了；
7）此时，页面将显示一个状态为 运行中 的负载均衡监听实例，后端服务器组已添加完成两台ECS服务器，且 健康检查 的状态为 正常。
注意：通常等待1分钟左右健康检查状态变为正常，可点击右侧的 刷新 查看。
负载均衡验证
本小节主要内容如下：
- 验证负载均衡的工作原理；
- 验证通过配置不同后端服务器权重，将用户的请求按比例分发到不同后端服务器；
- 验证在一台后端服务器开启会话请求时，请求在会话开启的时间内只会分发到这一台服务器。
1. 此时，两台后端服务器的权重比例相同。通过如下步骤，验证负载均衡服务器是轮询访问后端云服务器ECS实例：
1）在控制台点击左侧 实例管理 ，在右侧页面中的红框处看到负载均衡的 服务地址（也就是 云产品资源 提供的 负载均衡 的 IP地址） ；
2）在浏览器中新建页面，并访问 负载均衡 的 服务地址 。界面显示的 后端服务器IP 为 云服务器ECS-1（或 云服务器ECS-2） 的 内网地址 。
说明：界面显示的地址为内网地址，这是因为负载均衡访问后端ECS实例，是通过内网访问的。
3）刷新 浏览页面，显示的 后端服务器IP 将发生变化，变为 云服务器ECS-2（或 云服务器ECS-1）的 内网地址 ；
4）重复刷新操作，观察 后端服务器IP 是在两个云服务器的 内网地址 间轮流更换。
5）如上结果证明：负载均衡会将用户的请求发送到后端不同的服务器进行处理。这样，可以减轻单台服务器的负载压力，从而确保业务的持续性。
2. 通过如下步骤，修改后端服务器权重，验证负载均衡向后端服务器发送请求的比例是按照权重的比例调整的。
1）返回 实例管理 页面，点击该实例的 默认服务器组 ；
2）选中 已添加的服务器 ，列表中，勾选下方的勾选框 ，然后点击 修改权重 ；
3）弹出对话框中，勾选 设置不同的权重 。
4）设置两个实例的 权重 分别为 30 ，90 。
说明：通过如上的权重配置，用户通过负载均衡访问的时候，1/4 的用户请求发送到一台后端服务器中，3/4 的请求发送到另一台后端服务器中。
5）完成如上配置后，点击 确定 ，生效配置信息。
6）返回已添加的服务器的页面，查看到两台 ECS实例 的权重分别为 30 和 90 ，并记录对应的 ECS实例 内网地址。
7）浏览器中，刷新多次负载均衡 服务地址 的页面，并记录页面显示的 后端服务器IP 。可以发现：每 4 次刷新，将有 3 次访问 权重 为 90 的 ECS实例，1 次访问权重为 30 的 ECS实例。
8）如上结果证明：用户可以根据实际情况调整负载均衡器的请求分发，一般将配置高的服务器设置的权重调高，配置较低的服务器设置的权重调低。这样可以避免在高并发时，配置较低的服务器因为压力较大服务异常的发生。
3. 执行以下步骤，开启负载均衡的 会话保持 功能。
1）点击左侧 监听 ，监听页面点击右侧的 配置 。
2） 配置监听页面的 高级配置 处，点击 修改 ；
3）开启 会话保持 ，超时时间 输入 180 （即 3 分钟）；完成后点击 下一步 。
4）下面的 后端服务器、健康检查 和 配置审核 页面都采用默认值 ，依次完成配置。
5）返回到 监听 页面 ，会话保持 状态 已开启 。
4. 再次在浏览器中输入 负载均衡 的 IP地址 ，多次刷新，发现在会话保持的超时时间内请求只会分发到某一台 ECS 上（究竟是哪一台 ECS 没有规定），时间超出后，重新按照权重比例分发。
5. 我们关闭开启 会话保持 的那台ECS 。默认服务器组页面，已添加的服务器中 ，点击目标ECS的的高亮部分（即 云服务器ID）。
6. 实例详情页面 ，点击右上角处的 【停止】 ，弹窗页面点击【确定 】关闭当前ECS。
等待1分钟左右，实例的状态变为 已停止 。
7. 返回负载均衡管理控制台，在默认服务器组页面中点击右上角的【刷新】，页面刷新后被停止的 ECS 的 状态 变为 已停止。
【监听】 页面，也出现 异常 提示 。
同样的，点击左上角的 【实例管理 】，返回负载均衡管理控制台主页面，异常 报警也会出现。
8. 再次刷新浏览器中 负载均衡 的 IP地址 ，此时，请求发送到 健康检查状态 为 正常 的ECS上。
9. 结果证明，当某一台 ECS 出现异常后，负载均衡会自动将请求发送到健康检查状态正常的 ECS 上。
