内容简介

1. 负载均衡的一般实现方式
2. 选型功能要求
3. 一些优化项

负载均衡的一般实现方式

1. 七层实现

软件如 nginx, HAProxy，traefik，并且硬件负载均衡器都支持的;

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

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

特殊用法: 通过网关服务进行 http 重定向到不同地址

2. 传输层(OSI 四层)

承载协议：TCP, UDP
实现：如 lvs, 硬件负载均衡器
优点: 性能好，稳定性高

3. 网络层(OSI 三层)

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

采用等价路由, 流量镜像, 源 IP HASH 等方式, 在网络层按 IP 地址进行分发；
特别大流量时可以考虑 OSPF+LVS 技术栈。

4. 二层负载

原理: 后端多个服务器配置相同的 IP 地址，LB 通过改写数据帧的 MAC 地址来和后端通信
例如：交换机的端口聚合

5. DNS 负载均衡

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

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

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

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

6. 客户端负载均衡

方法一: 客户端有一个IP列表，随机或其它方式选择一个 ip 进行请求；
方法二: 客户端先请求或监听某个接口, 获取一个 ip 列表, 然后再发起请求。

7. 基础网络协议

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

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

选型功能要求

1. 一般要求

1. 性能要求
2. 稳定性要求: 有没有经过大厂考验
3. 协议支持; 如 TCP，UDP，HTTP，HTTPS，WebSocket 等
4. 负载均衡算法支持
5. 是否需要支持对后端的健康检查
6. 有没有扩展为 API 网关或业务网关的规划

2. 辅助要求

1. ssl 卸载，ssl 算法调整
2. 监控需求, 有些是带监控面板, 有些是暴露了一些指标供外部采集；
3. 安全性要求: 黑白名单, 动态黑白名单
4. 服务动态发现: 新增节点和下线节点能否自动识别；
5. 热更新: 如配置热更新，以及程序自身的热更新
6. 扩展性，插件支持

3. 一些小功能

1. http 重定向 https: 避免进入到应用内再进行重定向
2. 添加 XFF 头
3. 修改请求 url
4. 丰富的日志输出

优化项

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

   实现: 如 lvs 的 DR 模型, 某些硬件负载均衡器的 三角模型；
   PS：以前管理 array 设备的时候, 看到有这个模式, 只不过没有去实测试过；

2. 增加上游服务数量
   一般来说增加服务数量而不是让每个服务处理更多的通信, 可以得到更低的延迟, 和更高吞吐量

3. 关于 ssl 卸载, 加密解密是很耗CPU的，如果有大文件下载场景, 最好不要把 ssl 卸载放在 lb 上，影响性能。参考我的故障合集中的案例1。
   故障合集-外部系统故障