负载均衡 on IT 运维小秋

产品选型

chenwx716@139.com — Thu, 02 Mar 2023 10:30:00 +0800

负载均衡的一般实现方式

1. 七层实现

如 nginx, HAProxy，traefik，硬件负载均衡器;

一般承载协议：HTTP, HTTPS, WS等

优点: 功能丰富, 灵活方便, 插件支持；如果不是性能和协议不满足，几乎不用考虑别的方式。

2. 四层实现

承载协议：TCP, UDP

实现：如 lvs, 硬件负载均衡器

优点: 性能好，稳定性高

3. 三层实现

一般靠交换机或路由器等网络设备去实现；

采用等价路由, 流量镜像, 源 IP HASH 等方式, 在网络层按 IP 地址进行分发；

特别大流量时可以考虑 OSPF+LVS 技术栈。

4. 二层负载

原理: 后端多个服务器配置相同的 IP 地址，LB 通过改写数据帧的 MAC 地址来和后端通信

例如：交换机的端口聚合

5. DNS 负载均衡

通过 DNS 服务器给客户端响应不同的 IP 地址或多个IP地址的方式, 以达到负载均衡的效果；
在单个入口性能达到瓶颈时, 非常有效;

如果使用智能 DNS, 还可以做到如:

不同区域的用户请求不同地址, 做到区域划分, 就近访问, 提高不同区域的响应性能;
也可以将静态资源解析到 CDN, 动态资源解析到主入口;
配合健康检查做故障转移, 早期的DNS服务一般不支持探活，但目前很多也开始支持了，例如某些厂家推的全局DNS。

缺点: 使用 DNS 就绕不过去客户端缓存问题, 于是配置更新生效的时间就不稳定;

6. 客户端负载均衡

方法一: 客户端有一个IP或域名列表，随机或其它方式选择一个目标地址进行请求；

方法二: 客户端先请求或监听某个接口, 获取一个 ip 列表, 然后再发起请求。

7. 基础网络协议

ipv6 的任播(Anycast):
通过路由寻址协议，可以把包发给最近或响应最好的一台设备上；

IPv4 的组播：
例如多个后端节点监听同一个组播地址, 但根据源IP hash 来决定自己是否处理这个包，也达到了类似效果。

选型时功能要求

1. 核心要求

性能需求
稳定性要求: 有没有经过大厂考验
协议支持; 如 TCP，UDP，HTTP，HTTPS，WebSocket 等
负载均衡算法支持
健康检查策略: 主动检查和被动检查
有没有扩展为 API 网关或业务网关的规划
动态服务发现功能
热更新: 如配置热更新，以及程序自身的热更新

2. 辅助功能要求

https协议支持程度, ssl 卸载，ssl 算法调整
安全性要求: 黑白名单, 动态黑白名单
扩展性，插件支持
多节点管理方便程度

3. 管理类功能

http 重定向 https: 避免进入到应用内再进行重定向
添加 XFF 头
修改请求 url
丰富的日志输出
监控需求, 有些是带监控面板, 有些是暴露了一些指标供外部采集；

按业务场景选择

业务量较低

更需要关注功能丰富而非性能，日 PV 小于 1000 万时, 推荐 nginx, traefix 等 7 层组件;

业务量中等时

需要开始考虑性能, 可以考虑 lvs+nginx;

业务量很高时

分拆入口: 如 DNS 多 IP 地址轮询, 或者二级域名 image.wait.com voide.wait.com, 或用户分区;
不能拆入口时: 网络层处理流量负载(如ospf), 硬件负载设备处理业务负载;

业务量特别大

基于网络层的地址多路由; 即同一个 IP 地址不同区域解析到不同服务器上，例如泛播

常用产品分析

nginx

一般业务场景足够, 高性能;
功能丰富, 成熟, 通用度高

haproxy

早期的产品, 支持四层和七层, 功能丰富
除非特定生态, 现在一般不用

traefik

特点在于动态发现后端服务变更
适合容器化场景

lvs

更适合做 4 层的负载
属于内核级, 性能好, 稳定高, 资源使用率低, 没有多余的流量产生,
有一个 fullnat 模块, 增加了 local address

ospf+lvs

先在交换机上进行一次流量负载

端口聚合

单台主机和交换机之间, 通过端口聚合, 可以扩大带宽并且线路冗余

优化项

服务器直接返回请求
用户的请求进来时需要穿越多层负载, 为避免响应的包也回溯多层,
可以将响应包由后端直接回给用户，不从 LB 再过一次, 提高性能。
适合大文件下载的场景;

例如 cilium 的 DSR模式, lvs 的 DR 模型, 某些硬件负载均衡器的三角模型
增加上游服务数量
一般来说增加服务数量而不是让每个服务处理更多的通信, 可以得到更低的延迟, 和更高吞吐量
关于 ssl 卸载
加密解密是很耗CPU的，如果有https大文件下载场景, 最好不要把 ssl 卸载放在 lb 上，影响性能。

负载均衡算法

chenwx716@139.com — Thu, 02 Mar 2023 10:30:00 +0800

负载均衡算法

说明事项

不同模型下对于代理后面的的服务器叫法不一样, 有时候叫上游(nginx), 有时候叫后端，有的又叫 RS(lvs 的 RealServer)，还有直接叫 server 的，大家知道是同一个东西就行。

简单分类

静态算法, 固定分发策略
动态算法(根据状态的不同分配方式由所变化)

静态算法

1. RR (Round-Robin) 轮询

轮流请求后端服务

优点：简单，性能高
特点: 不记录当前连接的状态，是一种无状态调度
缺点: 如果后端资源配置不一样, 容易造成负载不平衡

2. WRR (Weighted Round-Robin) 加权轮询

在 RR 的基础上，可以增加或减少分配给某个后端应用的流量比例;

场景: 应对后台服务性能不一致的场景, 性能好的服务器多处理一点流量;

例如: A=1, B=2;

则请求 1 给 A, 请求 2,3 给 B, 请求 4 给 A, 请求 5,6 给 B

3. random 随机算法

轮询算法实际上还是按列表环进行顺序分配;

而全随机算法, 在数据量足够大的场景下, 能达到均衡分布;

4. ip hash (Source Hashing)

区分2种场景

使用源ip地址进行 hash, 一般是处理进来的流量, 源地址散列, 或源地址 HASH, 简称 SH
使用目的ip地址进行 hash, 一般是处理出去的流量, Destination Hashing 简称 DH

根据这个请求的源地址进行 hash, 然后从地址列表中找出一个服务器来; 类似与取模运算；

优点: 同一个客户端IP的请求始终会落到一个后端节点，便于 cookie 与 session 进行会话绑定；
缺点: 后端新增或减少一个节点时，将有 1/n 流量始终不可用, 如果重启或重载配置, 则原来映射关系就会全部重新排。

5. 一致性哈希

简单理解: 划一个圈, 每个节点占一个范围；

如果有新增服务器, 就圈内找最合适的一个节点, 将它的一部分范围转交给新节点;
也可以是两个相邻节点各出让一部分
如果是某各节点故障, 就把它原来的这个范围, 给它相邻的两个节点进行瓜分；

优点: 可以在客户端实现
缺点: 节点变化时需要操作的内容有些多, 适合在客户端实现, 而不是 LB

6. 序列分配

根据键的序列进行分配; 如 ID 为 1-1000 分到 A 节点, 1001-2000 分配到 B 节点

7. 取模分配

对 key 和节点数进行取模计算后分配到相应节点

动态算法

1. 最小连接数(Least-Connection ) 简称 LC

对当前与后端服务器的连接进行统计, 谁少就把新连接给谁;

适合场景: 下载类的服务，小文件下载连接释放得快

2. 加权最少链接(Weighted Least-Connection) 简称 WLC

在 LC 的基础上增加了权重, 权重高的可以承受更多连接

3. 最快响应模式

传递连接给那些响应最快的服务器

4. 其它算法

还有一些 lvs 的不常用算法, 比较复杂，特定场景下可能有用

LBLC(局部性的最少链接): 先去目标ip的最近调度服务器, 如果不可用, 再使用 lc 算法;

LBLCR(带复制的基于局部性最少链接): 比较复杂。先去一个目标服务器小组, 按lc算法选一个节点; 如果节点不可用再选;
SED(最短期望延迟),
NQ(Never Queue)
最快响应模式

5. 自定义控制

如根据监控系统内的 CPU 使用率和连接数,当前大事务量等, 来改变注册中心内配置的权重
劣势: 实现复杂
优点: 非常灵活

获取真实源IP地址

chenwx716@139.com — Sat, 25 Feb 2023 12:30:00 +0800

一般来说普通 http 场景，推荐使用 xff 头的方式获取IP，

如果是 tcp 或 udp，先看是否支持 proxy protocol 协议，然后再考虑 lvs。

简述

从 xxf 头部获取
四层从 proxy protocol 协议或者 tcp option 字段
三层使用透明模型
自定义规则, 需要客户端支持

一、从应用层获取

1. http协议规范的xff头部

如 http 协议约定, X-FORWARD-FOR 头部用于存放源IP地址

如 nginx 一般配置

1
2

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

优点: 对网络架构要求低, 配置简便

缺点: 容易被伪造

2. 业务程序自行实现

即程序自行实现, 例如 client 端将源IP插入到报文正文内某字段, 再带到 server 端。

优点: 对网络架构无要求, 只要网络可通即可, 只要安全做好, 不容易被伪造

缺点: 需要改造旧的客户端和服务器

二、从四层获取(TCP/IP 也就是端口这一层)

1. tcp option 字段

原理: 在 4 层报文的 option 字段里增加源 IP 信息, 比如 tcp option, udp option，即 L4 的 toa 模式；

注:
toa 是指在 tcp option 里增加源 IP 信息；
uoa 是指在 udp option 里增加源 IP 信息；

实现: lvs-fullnat(只支持 toa), iqiyi/dpvs(支持 toa 和 uoa);

后端应用程序也要加载 toa, uoa 模块, 是用于替换后端应用程序获取 IP 时的系统接口的钩子。

优点: 对网络架构要求低。

缺点: lvs-fullnat 需要编译内核, 且多年未更新;
iqiyi/dpvs 功能强大, 但需要 dpdk 的支持;
而且都需要后端程序需要加载 toa/uoa 模块, 且只支持 linux 系统。

2. proxy protocol 协议支持

原理:
即在三次握手结束后的第一个数据包的头部插入一段数据, 记录着源IP地址, 这段数据在 4 层末尾和 7 层开头之间。

这项协议最早是 haproxy 开发推广的, 目前主流 proxy 应该是都支持了；

目前有 v1(明文)和 v2(二进制)两个版本；

优点: 网络侧不需要改造什么, 只要应用软件支持即可。

限制条件:

需要负载均衡器和后端同时开启 proxy protocol 协议，不能只开一侧；
支持此协议的后端应用比较少;
已知支持此协议的软件: haproxy, nginx, apache、traefik、squid、mysql等,
已经支持的 LB 还得看支持什么版本，如阿里云的CLB只支持V2版本，
nginx 早期只支持 v1 版本，1.13.11+ 才支持 v2 版本。

nginx 配置示例

插入配置
server {
    listen              12345;
    proxy_pass          backend.example.com:8080;
    proxy_protocol      on;
}

接收配置
server {
    listen 80   proxy_protocol;
    listen 443  ssl proxy_protocol;

    real_ip_header  proxy_protocol;
    proxy_set_header X-Forwarded-For $proxy_protocol_addr;
}

三、从三层获取(IP层)

1. 转发模式

如果 LB 采用一次连接模式, 即只转发包，非代理模式时, 可以在网络层不对源 IP 做修改, 直接将数据包转发给后端, 当后端接收到数据的时候, 源 IP 就是真实 IP。

实现: LVS-DR, LVS-NAT, LVS-TUNNEL 模式;

优点: 逻辑简单, 当负载均衡器故障切换的时候, 从客户端到后端的 tcp 连接不会中断

缺点: 对网络架构有要求, 例如

LVS-TUNNEL 比较特别, 走的是隧道, 在原有数据包的开头封装了 IP 头, 当后端收到数据的时候, 将封装的 IP 头进行解封装, 获得的就是原始数据包，当然包括真实的 client IP。但是要后端也支持 ip 隧道。

DR 模式, 要求后端配 VIP, 并且回包要能直接回到客户机;

NAT 模式, 要求回包经过负载均衡器;

2. 代理模式

如果 LB 采用二次连接模式, 如 haproxy 的透明模式。

是指负载均衡器和后端会重新进行三次握手, 但保持数据包的源 IP 为真实 IP，类似于 F5 的透明模式。

实现原理: haproxy(开启 tproxy 透明代理模式)+ iptables(fwmark 打标记)+ 策略路由这 3 者组合才能实现。

优点: 可以实现 L7 层(如 HTTP/HTTPS)的负载均衡, 而一次连接方式主要是实现 L4 层的负载均衡。

缺点: 配置最复杂, 同时要求回包经过负载均衡器

代理的一次连接和二次连接模式

一次连接: 负载均衡器对数据包仅做转发, 而不对后端重新发起三次握手,类似交换机

二次连接: 和一次连接相对应, 在 tcp 转发时候, 对后端重新进行了三次握手,代理模式

可以通过对比源端口是否有改变来简单判断是一次连接还是二次连接,

端口没改变, 可以理解为一次连接, 有改变就是二次连接