一、基础概念
1.1 什么是负载均衡
负载均衡（Load Balance）就是把流量（访问请求、工作任务）分摊到多台服务器或组件上去处理的过程。
1.2 为什么需要负载均衡
主要解决三个问题：
- 性能：单台机器能扛的并发有限，加机器才能提升吞吐。
- 高可用：避免单点故障，一台挂了流量还能转到别的机器。
- 扩展性：能水平加机器来分摊压力（分治思路）。
像淘宝、京东这类站点，访问量起来之后单机或单集群就扛不住了，得横向扩多台服务来分摊，这就要有个组件管流量怎么分，这个组件就是负载均衡。不同业务对分发算法的需求不一样，下面具体看。
二、负载均衡策略
2.1 轮询（Round Robin）
按请求顺序轮流分给后端，循环往复。
- 5 条请求过来，按顺序轮流分配。
- web-server1 拿到 1、4，web-server2 拿到 2、5，web-server3 拿到 3。
适合后端机器性能接近的场景，负载分配平均。缺点是某一台性能差或偶发故障会拖累整体。
2.2 加权轮询（Weighted Round Robin）
给不同后端设不同权重，按权重比例分配请求数。后端性能不均时用它，让强机器多扛活。
- 5 条请求，web-server1 权重 60% 拿到 1、2、3。
- web-server2 权重 20% 拿到 4，web-server3 权重 20% 拿到 5。
2.3 IP 哈希（IP Hash）
对客户端的 IP 取哈希，把请求固定分到某台机器，保证同一 IP 总落到同一台。需要保持会话（比如用户 session）的 Web 应用常用它。
- IP 192.168.0.99 哈希到 web-server1，流量 1、4 分给第 1 台。
- IP 192.168.0.96、192.168.0.98 哈希到 web-server3，流量 2、3 分给第 3 台。
缺点：容易造成负载不均。某个 IP 发了大量请求，它对应的机器会被打满，其他机器闲着。用之前要评估极端情况，我之前就在这踩过坑。
2.4 最少连接（Least Connections）
把新请求分给当前连接数最少的机器。适合长连接场景（WebSocket、FTP）。通过记录每台机器的活跃连接数来调度，避免部分机器过载。
- web-server1、2、3 连接数分别是 11、15、2，web-server3 相对空闲。
- 1、2、3 请求到来时，web-server3 持续空闲，请求就分给它。
对机器性能差异大的情况适应好。缺点是要实时统计连接数，每次请求都判断再分发，高并发时增加开销。
2.5 最短响应时间（Least Response Time）
实时监测每台机器的响应时间，把请求给响应最快的。适合对延迟敏感的业务。
- 优点：用户体验好、能动态调、扛得住高峰。
- 缺点：要持续监测算开销；受瞬时波动影响（某台一时变慢可能被临时排除）；只看响应时间，可能忽略 CPU、内存等其他指标，导致分配不够均衡。
实际里通常和最少连接结合着用。
2.6 其他策略
- DNS 负载均衡：按用户地理位置把请求解析到最近的服务器，适合全球范围，能提访问速度。
- 数据层负载均衡：数据和请求都要均衡，常见做法是按分库分表做分片哈希。
- 一致性哈希：节点扩缩容时只影响相邻分片，常用于缓存、有状态服务。
- 随机：简单随机，大样本下近似均衡，做兜底或压测用。
选策略时看实际场景、机器性能、网络状况，没有万能的。
三、按工作层级划分
3.1 四层负载均衡（L4）
在传输层（TCP/UDP）做分发，不解析应用内容，只按 IP + 端口转发。性能好、转发快，代表是 LVS。适合做最前端的流量入口。
3.2 七层负载均衡（L7）
在应用层（HTTP 等）做分发，能看 URL、Header、Cookie 等内容做精细路由。代表是 Nginx、HAProxy。功能多但开销比 L4 大。
四、具体技术方案（服务端）
4.1 Nginx
最常用的七层（HTTP）负载均衡 + 反向代理，也能用 stream 模块做四层（TCP/UDP）转发。核心是 upstream 定义后端池，再用 proxy_pass 转过去。
支持的负载均衡策略：
- 轮询（默认）：按序轮流。
- 加权轮询（weight）：强机器多分。
- ip_hash：按客户端 IP 做会话保持。
- least_conn：给连接数最少的机器。
- fair（第三方 nginx-upstream-fair）：按响应时间，快的多的。
- hash $request_uri（第三方）：按 URL 一致性哈希，常用在缓存。
配置示例：
http {
upstream backend {
# ip_hash; # 开启则按客户端 IP 会话保持
least_conn; # 也可改成 weight 轮询等其他策略
server 192.168.1.10:8080 weight=3 max_fails=2 fail_timeout=30s;
server 192.168.1.11:8080 weight=1;
server 192.168.1.12:8080 backup; # 备份节点，主节点全挂时才启用
}
server {
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
}
健康检查： 原生只支持被动检查（max_fails + fail_timeout，连续失败几次就临时摘掉）。主动检查要上 Nginx Plus 或第三方模块 nginx_upstream_check_module。
4.2 LVS
LVS（Linux Virtual Server，章文嵩发起）是内核态四层负载均衡，转发性能极高，轻松上百万并发。转发靠内核模块 ip_vs，用用户态工具 ipvsadm（新的是 ipvs）配置。
三种工作模式：
- NAT：请求和响应都过 Director。Real Server 网关指向 Director。好配，但 Director 容易成瓶颈，RS 不限系统。
- DR（最常用）：Director 只改目标 MAC 把请求转给 RS，响应由 RS 直接回客户端（三角路由，响应不过 Director）。要求 Director 和 RS 同二层/VLAN；RS 要把 VIP 绑 lo 并抑制 ARP。性能最好、没瓶颈。
- TUN（IP 隧道）：请求包 IP 封装后隧道发给 RS，RS 可跨网段/跨机房，响应直回。适合异地多活，RS 要支持隧道。
调度算法（跟第二章策略对应）： rr、wrr、lc、wlc（默认，加权最少连接）、lblc、dh、sh（源地址哈希，相当于 IP Hash 会话保持）、sed、nq 等。
典型组合： LVS-DR + Keepalived 是生产最常见的四层高可用方案，常做最前端入口，后面再接 Nginx/HAProxy 做七层。
4.3 HAProxy
高性能 TCP/HTTP 负载均衡 + 反向代理，七层调度、SSL 卸载、健康检查都很强，常当 API 网关、入口 LB。比 Nginx 更专注负载均衡本身，配置项更细。
调度算法（balance）：
- roundrobin：动态加权轮询，权重能运行时调，默认最常用。
- static-rr：静态加权轮询，权重不能运行时改。
- leastconn：连接数最少优先，适合长连接（MySQL、WebSocket）。
- source：按源 IP 哈希，相当于 IP Hash 做会话保持。
- uri / url_param / hdr()：按 URI、参数、请求头做哈希，用于缓存亲和。
- random：随机（可带权重）。
健康检查与高可用：
- 主动检查：option httpchk GET /health 定期探；check inter 2s 控频率，rise/fall 控判定阈值。
- 被动检查：option redispatch，后端挂了把会话重分发。
- 会话保持：cookie 注入（cookie SERVERID insert）或 source 算法。
- 统计页面：stats 模块看实时状态。
- 超时重试：timeout connect/server/client 和 retries 精细控制。
配置示例：
defaults
mode http
timeout connect 5s
timeout server 30s
frontend http_in
bind *:80
default_backend app
backend app
balance leastconn
option httpchk GET /health
server s1 192.168.1.10:8080 check inter 2s rise 2 fall 3
server s2 192.168.1.11:8080 check inter 2s rise 2 fall 3
4.4 Keepalived（高可用 / VIP 漂移）
这里的 Keepalive 指 Keepalived，基于 VRRP（虚拟路由冗余协议）做高可用，给负载均衡器（LVS/Nginx/HAProxy）做 VIP 漂移，消除 LB 自己的单点故障。
原理： 多台 Keepalived 组一个 VRRP 实例，靠心跳选 Master，Master 持有 VIP。Master 挂了或网络断了，Backup 超时后接管 VIP，业务基本无感。还能用 vrrp_script 对业务进程（比如 Nginx）做应用级健康检查，进程挂了就主动降优先级让出 VIP。
配置示例：
vrrp_instance VI_1 {
state MASTER # 备机改为 BACKUP
interface eth0
virtual_router_id 51 # 同一 VRRP 组需一致
priority 100 # 备机设低一些，如 90
advert_int 1 # 心跳间隔（秒）
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.1.100 # 对外提供服务的 VIP
}
}
常见组合： LVS + Keepalived（L4 高可用）、Nginx + Keepalived（L7 高可用）、HAProxy + Keepalived，都是经典一主一备 / 双主。
补充：HTTP Keep-Alive（连接复用）和 TCP keepalive（探活心跳）是另一回事，别和 Keepalived 的 VRRP 高可用搞混。
五、客户端负载均衡（微服务场景）
5.1 Dubbo
阿里的 RPC 微服务框架，负载均衡是客户端（消费者侧）负载均衡：消费者从注册中心（Nacos/Zookeeper 等）拉服务实例列表，本地选一个提供者调用，跟服务端 LB（Nginx 统一入口）思路不同。负载均衡和服务发现、集群容错是一体的。
内置策略（loadbalance 参数）：
- random（默认）：加权随机，大样本下近似均衡，最稳。
- roundrobin：加权轮询，严格按权重轮流。
- leastactive：最少活跃调用数优先，谁正在处理的请求少（响应快）就给谁，自动把流量从慢节点挪开，思路类似 Least Response Time / Least Connections。
- consistenthash：一致性哈希，相同参数的请求总落同一提供者，适合有状态服务或本地缓存亲和。
配置示例：
@DubboReference(loadbalance = "leastactive", cluster = "failover")
private OrderService orderService;
和集群容错配合： cluster（failover 失败重试、failfast 快速失败、failsafe 忽略、forking 并行）叠加在负载均衡之上，先由负载均衡选目标，再由 cluster 决定失败怎么处理。
5.2 Spring Cloud Feign
Feign（Spring Cloud OpenFeign）是声明式 HTTP 客户端：把对微服务的 REST 调用写成接口加注解，框架自动生成实现并发请求。它本身不做负载均衡，而是集成客户端负载均衡组件，把服务名解析成具体实例来调。
负载均衡演进：
- 早期：集成 Ribbon 做客户端负载均衡，配合服务发现（Eureka/Nacos/Consul）把服务名解析成多实例后轮询。
- Spring Cloud 2020.0（Ilford）之后：Ribbon 移除，改用 Spring Cloud LoadBalancer（基于 Reactor，默认 round-robin，可自定义 ReactorLoadBalancer）。
配置示例：
@FeignClient(name = "order-service") // name 即注册中心里的服务名
public interface OrderClient {
@GetMapping("/orders/{id}")
Order getOrder(@PathVariable("id") Long id);
}
调 order-service 时，LoadBalancer 先从注册中心拿该服务所有实例，按策略（默认轮询）选一个，再经 Feign 发 HTTP 请求。
自定义： 实现 ReactorLoadBalancer 注册成 @Bean，就能把默认轮询换成加权、一致性哈希等；也能通过 YAML 给每个服务指定负载均衡器配置类。
客户端 LB vs 服务端 LB： Feign + LoadBalancer 是客户端负载均衡，选择逻辑在调用方进程里，没有集中入口、没有额外一跳延迟，但配置分散在各消费者；服务端 LB（Nginx/LVS/HAProxy 统一入口）集中管控、对调用方透明。
六、特殊场景的负载均衡
6.1 DNS 负载均衡
按用户地理位置把请求解析到最近的服务器，适合全球范围，提访问速度。一般配合智能 DNS（GeoIP）做就近接入。
6.2 数据层负载均衡
数据和请求都要均衡，常见做法是按分库分表做分片哈希负载。难点在于数据和请求均衡要一起考虑，不能只管请求。
7.1 阶段一：资源筹备与合规基石（Level 1：资源与合规管理）
过程： 买 IPv6 段、租 IPv4 段、委托 LIR 注册 ASN（RIPE NCC 可查）、拿多个域名、完成 ICP 备案。
能落地的 ISP 功能：
- IP 资源管理（IPAM）：搞懂 RIR/LIR 体系，维护 Whois，管 IP 生命周期。
- 域名与合规：域名注册、DNSSEC、国内 ICP 备案流程，理解 GDPR、网络安全法对不同辖区的基础要求。
7.2 阶段二：单点网络服务与路由宣告（Level 2：基础 ISP 功能）
过程： 搭 DNS/NS、配 BGP 邻居、向上游 Transit 宣告 IPv4/IPv6 前缀、配反向解析。
能落地的 ISP 功能：
- BGP 路由运营：eBGP/iBGP、Prefix-list、AS-Path 操控、Maximum-prefix。
- 路由安全：RPKI + ROA 签发，IRR 里建 Route 对象，防路由劫持/泄漏。
- DNS 架构分离：权威 DNS 和递归 DNS 分离，配 PTR，防 Open Resolver 被拿去做 DDoS 放大。
7.3 阶段三：分布式骨干网与 Anycast 架构（Level 3：跨国网络雏形）
过程： 用海外 25 台（欧洲、日本、港澳）+ 国内 3 台（京沪蓉）构建底层互联，全网宣告相同 Anycast IP 段。
能落地的 ISP 功能：
- Anycast 路由调度：28 个节点同时宣告相同 /24（v4）或 /48（v6）前缀，靠 BGP 最短 AS-Path 和 IGP 度量做就近接入。
- BGP Communities 控制：向上游发特定 Community 精准控制路由在欧洲/日本/港澳的传播范围，做区域性流量牵引。
- 全球私有骨干网（Overlay）：用 WireGuard/VXLAN/IPsec 在 28 节点间建 Underlay 隧道，上面跑 iBGP/OSPF，造一张自己的跨国私有骨干。
7.4 阶段四：全局流量调度与边缘计算（Level 4：高级 ISP / CDN 功能）
过程： 结合已备案域名 + 全球节点，部署智能 DNS、全局负载均衡、边缘缓存、安全防护。
能落地的 ISP 功能：
- 智能 DNS 与 GSLB：搭支持 GeoIP 和延迟探测的权威 DNS（如 PowerDNS + 自研调度）。欧洲用户解析到欧洲节点，日本用户解析到日本节点。
- 边缘计算与 CDN 雏形：在港澳/日本/欧洲边缘节点部署 Nginx/Varnish，静态资源缓存到离用户最近的点，经私有骨干回源。
- Anycast DDoS 近源清洗：28 节点 Anycast 分摊攻击流量，结合 BGP Flowspec 在边缘/上游直接下发过滤规则，做 ISP 级自动化 DDoS 防护。
- 跨国链路优化：靠 BGP Local Preference 和 MED 选优质 Transit（如回国优化的 CN2/CMI/CU），降延迟。
7.5 阶段五：自动化运维与全球 NOC（Level 5：企业级运营能力）
过程： 建全球网络监控大屏、自动化配置流水线、全球路由透视。
能落地的 ISP 功能：
- 全球 NOC 监控：Prometheus + Grafana + Alertmanager + Loki，实时看 28 节点 BGP 状态、接口流量、Anycast 分布、跨国延迟热力图、DDoS 报表。
- 网络自动化与 IPAM：NetBox 当单一真相源管 IP/ASN/VLAN/机柜；Ansible/Terraform 自动下发 28 台配置并版本化。
- 全球 Looking Glass：所有节点部署，能从任意节点 Ping/Traceroute/MTR/看 BGP 表，快速排跨国故障。
- Abuse 自动化：建标准 abuse@ 邮箱和工单系统，对接威胁情报，恶意 IP 自动封禁拉黑。
7.6 终极形态：四种高级形态
打通上面所有阶段，这套架构最终可能演变成以下之一：
- 全球分布式边缘云 / 小型 CDN：对外或内部提供类 Cloudflare 边缘服务，用 Anycast + GSLB 做低延迟 Web 加速、API 网关、WebSocket 代理、边缘计算。
- 高可用 Anycast 基础设施提供商：专门提供高可用基础网络服务，比如企业级抗 DDoS 权威 DNS 托管、全球 NTP 时间同步、跨国企业合规接入网关。
- 跨国企业级 SD-WAN 与私有骨干网：把 28 节点包装成 SD-WAN 方案，服务跨国企业在欧洲/日本/港澳/大陆间建立安全低延迟智能选路的内网。
- 网络工程自动化与科研平台：做 BGP 收敛速度、跨国 TCP 拥塞控制（BBR）、IPv6 过渡（NAT64/DNS64/SRv6）、全球拓扑测量的科研实验平台。
7.7 核心合规与红线约束
涉及跨国节点、国内服务器、ICP 备案、独立 ASN，必须守住这些红线，否则法律和业务风险很大：
- 跨境数据与信道合规（国内红线）：国内节点（京沪蓉）严禁用于未经批准的跨境接入（不能做翻墙节点或非法跨境穿透网关）。合规用法：只做合法国内业务展示、内部网络管理、或有资质的企业内网回源。ICP 备案域名要解析到国内合法节点或合规境外节点。
- 电信业务经营资质（无牌商用红线）：没拿到相应国家/地区的电信牌照（国内 ISP/IDC/CDN 牌照、欧洲 ECS 等）前，严禁向公众或第三方公开卖带宽、IP、VPS、加速服务。合规用法：把网络定性为内部实验网、企业自用网、技术验证平台，不产生真实公众商业流水。
- 路由安全与 Abuse 响应（全球互联网红线）：严禁宣告不属于自己的 IP 前缀（防路由劫持）；严禁开放无限制的公共递归 DNS/NTP/SSDP（防 DDoS 放大）。合规用法：RIPE NCC 登记的 Abuse 邮箱要 24 小时有人响应，收到 Spamhaus 黑名单警告或上游 Abuse 投诉要在 SLA（通常 24 小时）内溯源封禁，否则 ASN 和 IP 段会被全球路由黑洞（Null Routing）封杀。