产品选型
负载均衡的一般实现方式
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 上，影响性能。