负载均衡是分布式系统的流量入口，将请求合理分配到后端服务器，提升系统吞吐与可用性。在微服务架构中，网关到服务层再到应用层的每个环节都需要负载均衡的支撑。本文从基础算法到高级策略，从数学原理到生产实践，全面解析负载均衡技术。
1. 负载均衡层次
| 层次 | 技术 | 特点 |
|---|---|---|
| DNS 层 | DNS 轮询、GeoDNS | 简单、成本低、TTL 延迟 |
| 网关层 | Nginx、HAProxy、ALB/CLB | 七层/四层、灵活 |
| 服务层 | Spring Cloud LB、Client-Side LB | 服务发现集成 |
| 应用层 | 自定义路由 | 业务逻辑驱动 |
在 DNS 层，负载均衡通过域名解析返回不同的 IP 地址条目来实现，这种方案对客户端完全透明，但受到 DNS 缓存（通常为 300 秒到 24 小时不等）的限制，因此无法做到快速故障切换。网关层位于 DNS 之后，是请求到达应用服务前最关键的环节，Nginx 和 HAProxy 是业界最常用的两个七层网关，各自具备极为丰富的负载均衡策略。服务层负载均衡发生在微服务之间调用时，常见于 Service Mesh 架构中的 Sidecar 代理或框架内置的客户端负载均衡器。应用层则是最贴近业务的一层，通常基于用户 ID、订单号等业务字段做自定义路由。
2. 基础算法
2.1 轮询 (Round Robin)
轮询算法以固定顺序依次将请求分配给每台服务器，是负载均衡中最简单也最常用于学习和对比的算法。
class RoundRobinBalancer:
"""基本轮询负载均衡器。"""
def __init__(self, servers):
self.servers = servers
self.index = 0
def get_server(self):
server = self.servers[self.index]
self.index = (self.index + 1) % len(self.servers)
return server
if __name__ == "__main__":
servers = ["server-a", "server-b", "server-c"]
lb = RoundRobinBalancer(servers)
for _ in range(6):
print(lb.get_server())
优点：绝对公平，实现简单，时间复杂度为 O(1)，空间复杂度为 O(1)。
缺点：完全不考虑服务器实际负载差异，当某台服务器处理速度远慢于其他节点时会出现排队。
适用场景：后端服务器硬件配置完全一致、请求处理时间较均匀的场景。
2.2 加权轮询 (Weighted Round Robin)
当后端服务器性能不一致时，给能力强、配置高的节点更高的权重，让其在单位时间内处理更多请求，这就是加权轮询的设计理念。
朴素实现：按权重复制服务器列表。
class WeightedRoundRobin:
"""朴素加权轮询：按权重展开列表。"""
def __init__(self, servers_with_weights):
self.servers = []
for server, weight in servers_with_weights:
self.servers.extend([server] * weight)
self.index = 0
def get_server(self):
server = self.servers[self.index]
self.index = (self.index + 1) % len(self.servers)
return server
if __name__ == "__main__":
sw = [("server-a", 5), ("server-b", 3), ("server-c", 2)]
lb = WeightedRoundRobin(sw)
dist = {"server-a": 0, "server-b": 0, "server-c": 0}
for _ in range(100):
dist[lb.get_server()] += 1
print(dist)
朴素加权轮询的缺点是当权重差异极大时，列表膨胀导致内存和调度效率下降。
平滑加权轮询 (Nginx 算法)：业界广泛采用 Nginx 的平滑加权轮询，通过动态维护当前权重来选择服务器，避免流量突刺。
class SmoothWeightedRoundRobin:
"""
平滑加权轮询：Nginx 内核实现原理。
数学思想：每次所有节点 current += weight，选择 current 最大者，当选者再减去 total_weight。
该算法保证在一个调度周期内每台服务器的请求分布尽可能平滑。
"""
def __init__(self, servers):
# servers = [{"server": "a", "weight": 5, "current": 0}, ...]
self.servers = servers
self.total_weight = sum(s["weight"] for s in servers)
def get_server(self):
best = None
for s in self.servers:
s["current"] += s["weight"]
if best is None or s["current"] > best["current"]:
best = s
best["current"] -= self.total_weight
return best["server"]
if __name__ == "__main__":
servers = [
{"server": "server-a", "weight": 5, "current": 0},
{"server": "server-b", "weight": 3, "current": 0},
{"server": "server-c", "weight": 2, "current": 0},
]
lb = SmoothWeightedRoundRobin(servers)
dist = {}
for _ in range(100):
s = lb.get_server()
dist[s] = dist.get(s, 0) + 1
print(dist)
平滑加权轮询的时间复杂度为 O(n)（n 为服务器数量），空间复杂度为 O(n)，因为仅需维护当前权重数组。
2.3 随机 (Random)
import random
def random_select(servers):
return random.choice(servers)
def weighted_random(servers_with_weights):
"""
加权随机选择，别名法（Alias Method）的前身实现。
时间复杂度：O(n) 预处理 + O(log n) 查询（二分查找）。
"""
total = sum(w for _, w in servers_with_weights)
r = random.uniform(0, total)
cumulative = 0
for server, weight in servers_with_weights:
cumulative += weight
if r <= cumulative:
return server
def weighted_random_fast(servers_with_weights):
"""
加权随机选择，更高效的二分查找版本。
"""
import bisect
servers = [s for s, _ in servers_with_weights]
weights = [w for _, w in servers_with_weights]
prefix = [sum(weights[:i + 1]) for i in range(len(weights))]
total = prefix[-1]
r = random.uniform(0, total)
idx = bisect.bisect_left(prefix, r)
return servers[idx]
if __name__ == "__main__":
sw = [("server-a", 5), ("server-b", 3), ("server-c", 2)]
dist = {}
for _ in range(1000):
s = weighted_random(sw)
dist[s] = dist.get(s, 0) + 1
print(dist)
在算法理论中，随机选择具有良好的均摊特性。当请求数量 N 趋近无穷时，朴素随机选择等价于轮询；在 N 较小时，随机选择比轮询更能避免同分布下可能出现的请求扎堆问题。
2.4 最少连接 (Least Connections)
class LeastConnectionsBalancer:
"""最少连接负载均衡器。"""
def __init__(self, servers):
self.connections = {s: 0 for s in servers}
def get_server(self):
return min(self.connections, key=self.connections.get)
def acquire(self, server):
self.connections[server] += 1
def release(self, server):
self.connections[server] = max(0, self.connections[server] - 1)
if __name__ == "__main__":
servers = ["server-a", "server-b", "server-c"]
lb = LeastConnectionsBalancer(servers)
# 模拟并发场景
lb.acquire("server-a")
lb.acquire("server-a")
lb.acquire("server-b")
for _ in range(5):
print("select ->", lb.get_server())
最少连接算法在每次调度时选择当前活跃连接数最少的后端节点。其时间复杂度为 O(n)，空间复杂度为 O(n)。该算法最适合长连接场景（如 WebSocket、TCP 长连接、gRPC HTTP/2 流），因为在这类场景中请求处理时间差异往往非常大，轮询或随机会造成明显的不均衡。
2.5 IP Hash
def ip_hash_select(client_ip, servers):
"""
IP 哈希选择：利用 Python 内置 hash 函数。
注意：生产环境应使用更稳定的哈希函数如 xxhash 或 CRC32。
"""
return servers[hash(client_ip) % len(servers)]
def ip_hash_select_stable(client_ip, servers):
"""使用稳定哈希函数避免 Python hash 随机化影响。"""
import hashlib
digest = int(hashlib.md5(client_ip.encode()).hexdigest(), 16)
return servers[digest % len(servers)]
if __name__ == "__main__":
servers = ["server-a", "server-b", "server-c"]
ips = ["192.168.1.1", "10.0.0.2", "172.16.0.3"]
for ip in ips:
print(ip, "->", ip_hash_select_stable(ip, servers))
IP 哈希的核心价值在于会话保持。同一客户端 IP 的请求始终被路由到同一服务器，无需中心化的 Session 存储。但这一特性也导致其负载分布对客户端 IP 分布极度敏感。防火墙出口或机构网络的多个用户共享一个公网 IP，可能带来热点问题。一个常见的优化方法是将 IP 哈希与权重结合，称为加权 IP 哈希。
2.6 一致性哈希负载均衡
import bisect
import hashlib
class ConsistentHashRing:
"""
一致性哈希环实现：每台物理节点分配多个虚拟节点以改善分布均匀性。
虚拟节点数量默认设为 150，可在生产环境中根据集群规模调整。
"""
def __init__(self, replicas=150):
self.replicas = replicas
self.ring = {}
self.sorted_keys = []
def _hash(self, key):
return int(hashlib.md5(key.encode()).hexdigest(), 16)
def add_node(self, node):
for i in range(self.replicas):
key = self._hash(f"{node}#{i}")
self.ring[key] = node
bisect.insort(self.sorted_keys, key)
def remove_node(self, node):
for i in range(self.replicas):
key = self._hash(f"{node}#{i}")
idx = bisect.bisect_left(self.sorted_keys, key)
if idx < len(self.sorted_keys) and self.sorted_keys[idx] == key:
del self.sorted_keys[idx]
self.ring.pop(key, None)
def get_node(self, key):
if not self.ring:
return None
h = self._hash(key)
idx = bisect.bisect_right(self.sorted_keys, h)
if idx == len(self.sorted_keys):
idx = 0
return self.ring[self.sorted_keys[idx]]
if __name__ == "__main__":
ch = ConsistentHashRing(replicas=150)
for server in ["server-a", "server-b", "server-c"]:
ch.add_node(server)
distribution = {}
for i in range(1000):
node = ch.get_node(f"user-{i}")
distribution[node] = distribution.get(node, 0) + 1
print("Add 3 nodes:", distribution)
ch.remove_node("server-a")
distribution2 = {}
for i in range(1000):
node = ch.get_node(f"user-{i}")
distribution2[node] = distribution2.get(node, 0) + 1
print("Remove server-a:", distribution2)
一致性哈希的核心优势在于：当集群中添加或移除节点时，仅有约 1/N 的数据需要重新映射。配合虚拟节点技术，分布均匀性可接近理想随机分布。时间复杂度：查找为 O(log V)（V 为虚拟节点总数），添加/删除节点为 O(V log V)。空间复杂度为 O(N * V)。一致性哈希被广泛用于缓存系统（如 Memcached、Redis 集群）、对象存储和分布式消息队列。
3. 健康检查
import time
import requests
class HealthChecker:
"""
主动健康检查器：基于 HTTP 探测的被动与主动混合检查。
生产环境建议结合被动探测（基于请求失败率）与主动探测（心跳）。
"""
def __init__(self, servers, interval=5, timeout=2, max_fail=3):
self.servers = {s: {"healthy": True, "last_check": 0, "fail_count": 0} for s in servers}
self.interval = interval
self.timeout = timeout
self.max_fail = max_fail
def check(self, server):
try:
response = requests.get(f"http://{server}/health", timeout=self.timeout)
return response.status_code == 200
except Exception:
return False
def run_checks(self):
now = time.time()
for server, status in self.servers.items():
if now - status["last_check"] > self.interval:
ok = self.check(server)
status["last_check"] = now
if ok:
status["healthy"] = True
status["fail_count"] = 0
else:
status["fail_count"] += 1
if status["fail_count"] >= self.max_fail:
status["healthy"] = False
return [s for s, v in self.servers.items() if v["healthy"]]
if __name__ == "__main__":
hc = HealthChecker(["localhost:8080", "localhost:8081"])
healthy = hc.run_checks()
print("Healthy servers:", healthy)
健康检查有两种模式：被动检查和主动检查。被动检查由真实请求触发，当请求失败次数超过阈值时标记节点为不健康；主动检查则定期向健康探针端点发送探测请求。Nginx 的 max_fails 和 fail_timeout 就是被动检查的参数。在生产环境中推荐使用混合模式：通过主动检查快速发现节点故障，通过被动检查确认服务确实不可用（避免假阳性）。此外，健康检查端点应设计为极轻量级操作，比如仅返回 {"status": "ok"}，避免引起额外的数据库查询或远程调用开销。
4. Nginx 配置示例
upstream backend {
# 最少连接数均衡策略
least_conn;
# 备选策略（取消注释可切换）：
# ip_hash; # IP 哈希：会话保持
# hash $request_id consistent; # 一致性哈希：缓存友好
# random two least_conn; # 随机两选后取最少连接
server 10.0.0.1:8080 weight=5 max_fails=3 fail_timeout=30s;
server 10.0.0.2:8080 weight=3 backup; # 备用：仅在主节点不可用时激活
server 10.0.0.3:8080 down; # 下线：用于维护窗口
keepalive 32;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_connect_timeout 2s;
proxy_send_timeout 5s;
proxy_read_timeout 5s;
proxy_next_upstream error timeout http_502 http_503;
proxy_next_upstream_tries 2;
}
}
生产环境最佳实践：
- keepalive 连接池：
keepalive 32保持与后端服务器的空闲连接，避免每个请求都进行 TCP 三次握手，极大降低延迟。 - 超时策略分级：
proxy_connect_timeout控制建立连接超时，应设置在 2 秒以内，防止慢节点拖垮前端。 - backup 服务器：用于灾难恢复场景，_normal 服务器全部不可用时自动接管流量。
- down 标记：用于灰度发布或维护期间的流量隔离，无需修改负载均衡器代码即可快速移除节点。
- proxy_next_upstream：配置可重试的异常类型，HTTP 502 和 503 态码请求可自动重试到下一节点。
5. LVS (Linux Virtual Server)
| 模式 | 特点 | 适用 |
|---|---|---|
| NAT | 修改 IP 地址 | 小规模 |
| DR (Direct Routing) | 直接路由，性能最高 | 大规模 |
| TUN (Tunneling) | IP 隧道，跨机房 | 异地多活 |
| FULLNAT | 修改源/目的 IP | 跨网段 |
LVS 是基于 Linux 内核态实现的高性能四层负载均衡器。每个模式在数据包路径、网络拓扑和延迟特性上存在显著差异。
NAT 模式通过修改请求和回复报文的目标 IP 地址实现转发。请求到达 LVS 调度器时，源 IP 保持不变，目的 IP 被改写为后端真实服务器地址；返回时调度器再将源 IP 改回虚拟 IP。因为所有流量都经过调度器，容易成为瓶颈，但不需要修改任何后端服务器配置，部署最快。
DR (Direct Routing) 模式是性能最高的部署方式，调度器仅修改数据帧中的 MAC 地址目标为真实服务器的 MAC，后端服务器直接将响应包返还给客户端。这一路径绕过了调度器，响应带宽不受调度器限制，使得 DR 模式成为大规模场景下的首选。但后端服务器必须将虚拟 IP 绑定在 lo（loopback）接口的非 ARP 响应接口上，避免 ARP 冲突。
TUN (Tunneling) 模式利用 IP 隧道封装原始报文，将数据包发送到远程机房的后端服务器。真实服务器解封后处理请求并直接回复客户端。此模式天然支持跨机房、跨区域的异地多活部署，但每个数据包因此增加一个 IP 包头，带来微小开销。
FULLNAT 是 LVS 2.6 版本引入的增强模式，同时修改源 IP 和目的 IP。这样做使得调度器与真实服务器可以位于不同的物理网络甚至不同网段，后端服务器的回复也先返回给调度器，解决了 NAT 模式下真实服务器必须透明感知客户端 IP 的问题。
6. Power of Two Choices 算法
Power of Two Choices（两选算法）是理论计算机科学中一项经典且极具实用价值的研究成果。其核心思想是：每次选取两个随机节点，将请求发送到负载较轻者。这一简单的改进在数学上被证明能够极大地降低负载的最大值，使其接近系统中的平均负载。相比一致性哈希，两选算法无需存储哈希环，也不需要处理重哈希问题，实现极为轻量。
在均匀负载分布的证明中，设共有 n 个球（请求）和 n 个桶（服务器）。如果每个球随机选择一个桶，最大负载约为 O(log n / log log n)。但如果每个球随机选择两个桶并放入较轻者，最大负载仅为 O(log log n)。这一指数级的差距充分说明了两选算法的理论优势。
Python 实现：
import random
class PowerOfTwoChoices:
"""
Power of Two Choices 负载均衡器。
每次随机抽取两个服务器，选择当前连接数较少的那个。
如果连接数相同，则随机选择其一。
"""
def __init__(self, servers):
self.connections = {s: 0 for s in servers}
self.servers = list(servers)
def get_server(self):
a, b = random.sample(self.servers, 2)
chosen = a if self.connections[a] <= self.connections[b] else b
self.connections[chosen] += 1
return chosen
def release(self, server):
self.connections[server] = max(0, self.connections[server] - 1)
if __name__ == "__main__":
servers = ["s1", "s2", "s3", "s4", "s5"]
lb = PowerOfTwoChoices(servers)
for _ in range(20):
print(lb.get_server(), end=" ")
print()
与一致性哈希对比：一致性哈希的核心价值在于请求亲和性（affinity），即同一 key 的请求始终落点相同，这对缓存系统极为有利；而 Power of Two Choices 放弃了亲和性，换取了更优的负载均匀性。在纯状态无关、追求最大吞吐量的 API 服务中，两选算法往往是更好的选择。
7. Envoy 负载均衡策略
Envoy 是现代云原生架构中最广泛使用的数据面代理，其负载均衡模块提供了远超传统反向代理的丰富策略。
| 策略 | 说明 | 适用场景 |
|---|---|---|
| Round Robin | 轮询 | 无状态服务 |
| Least Request | 最少活跃请求 | gRPC、HTTP/2 长连接 |
| Ring Hash | 一致性哈希环 | 缓存、会话保持 |
| Maglev | 确定性哈希 | 替代 Ring Hash，快速收敛 |
| Random | 完全随机 | 均匀负载分布 |
| Original Destination | 保留原始目标 | 透明代理 |
Maglev 是 Google 提出的负载均衡算法，用于替代传统的一致性哈希。Maglev 算法会为每个后端节点预先计算一个查找表（lookup table），在节点变动时（增加或删除后端）重新生成该表。其核心优势在于：节点变动时的重新哈希旋转量极小，远小于一致性哈希的虚拟节点方案，同时最高负载差异可严格控制在约 1.05 倍均值以内。
Envoy xDS 动态配置：Envoy 通过 xDS API（Listener Discovery Service、Cluster Discovery Service、Endpoint Discovery Service、Route Discovery Service）与控制面（如 Istio）交互，实时接收负载均衡策略的变更。例如 CDS 推送 Cluster 级别的 lb_policy，EDS 推送 Endpoint 级别的权重与状态。这使得 Envoy 能够在不停机的情况下热加载负载均衡策略。
# Envoy Cluster 配置示例：使用 Ring Hash 并设置最大请求数
clusters:
- name: backend_cluster
connect_timeout: 2s
lb_policy: RING_HASH
ring_hash_lb_config:
minimum_ring_size: 1024
maximum_ring_size: 8388608
health_checks:
- timeout: 2s
interval: 5s
unhealthy_threshold: 3
healthy_threshold: 2
http_health_check:
path: /health
8. 服务发现与负载均衡集成
在微服务架构中，负载均衡无法脱离服务发现独立工作。服务发现负责动态维护可用节点列表，负载均衡器基于此列表进行流量调度。两者的集成效率直接决定了系统的可扩展性和故障恢复速度。
Consul 提供了 Catalog API 和 Health API，负载均衡器可以长轮询或基于 Blocking Queries 监听服务状态变化。当某个后端被判定为不健康时，Consul Health API 会从响应中移除该节点，负载均衡器在下一次更新时自动停止向其发流量。
客户端负载均衡（Spring Cloud LoadBalancer / Go micro / gRPC）与服务器端负载均衡的最大差异在于，Endpoint 列表存储在客户端内存中，客户端直接根据策略选择后端并建立连接。这种方式消除了反向代理的额外网络跳数，但也带来了解耦度低、客户端需要感知服务拓扑的缺点。
# 基于内存缓存的服务发现客户端负载均衡极简示例
class InMemoryDiscovery:
"""
极简服务发现：模拟从 Consul/Eureka 拉取 healthy endpoints。
客户端使用 Power of Two Choices 进行负载均衡。
"""
def __init__(self):
# 模拟从注册中心获取的端点
self.endpoints = {
"user-service": ["10.0.0.1:8080", "10.0.0.2:8080", "10.0.0.3:8080"],
}
def get_healthy(self, service_name):
return self.endpoints.get(service_name, [])
class ClientSideLB:
def __init__(self, endpoints):
self.connections = {e: 0 for e in endpoints}
self.endpoints = list(endpoints)
def call(self, service_name):
if len(self.endpoints) < 2:
chosen = self.endpoints[0] if self.endpoints else None
else:
a, b = random.sample(self.endpoints, 2)
chosen = a if self.connections[a] <= self.connections[b] else b
if chosen:
self.connections[chosen] += 1
return chosen
if __name__ == "__main__":
disc = InMemoryDiscovery()
eps = disc.get_healthy("user-service")
lb = ClientSideLB(eps)
for _ in range(10):
print("Call ->", lb.call("user-service"))
9. 子集选择与连接池
Google SRE 手册中提出了一套经典的子集算法（Subset Selection），用于解决大规模集群中每个前端节点维护全量后端连接所带来的连接数爆炸问题。假设前端有 1000 个 pod，后端有 1000 个 pod，若每个前端与所有后端都建立连接，网络中的并发连接数将达到 100 万量级。通过子集算法让每个前端仅与固定数量的后端建立连接（例如 20 个），总连接数可降低到 2 万。
import hashlib
def subset_of(key, backend_list, subset_size):
"""
Google SRE 子集选择算法：基于确定性排序选取固定大小的子集。
key 通常为前端实例标识（如 Pod IP）。
"""
def _hash(s):
return int(hashlib.md5(s.encode()).hexdigest(), 16)
# 为每个后端节点计算基于 key 的排序值
scored = [(_hash(f"{key}:{b}"), b) for b in backend_list]
scored.sort(key=lambda x: x[0])
return [b for _, b in scored[:subset_size]]
if __name__ == "__main__":
backends = [f"backend-{i}" for i in range(100)]
print("Frontend-A sub:", subset_of("frontend-A", backends, 8))
print("Frontend-B sub:", subset_of("frontend-B", backends, 8))
Thundering Herd（惊群）问题是指当大量请求同时涌入集群，所有后端节点同时被唤醒或服务突然恢复时，前端瞬间重连导致后端过载。常见的缓解措施包括：
- 抖动（Jitter）：为健康检查的重试和重连引入随机延迟，避免所有节点同步触发。
- 连接预热（Warm-up）：新节点上线后，先通过小流量逐步增加到全量，避免冷启动抖动。
- 断路器（Circuit Breaker）：请求失败率超过阈值后短时间拒绝新请求，给后端恢复缓冲区。
10. 故障转移与优雅降级
现代负载均衡策略不能仅考虑正常负载的调度，还必须深度嵌入故障恢复和降级能力。
主备切换：在多可用区部署中，当主可用区整体不可用时，流量应能在秒级甚至毫秒级切换到备用区。Nginx 的 backup 指令和 Envoy 的 locality_weight 均支持此类场景的静态配置。更高级的方案是配合全局负载均衡器（如 Google Cloud Load Balancer）基于健康检查自动跨区调度。
局部异常摘除（Outlier Detection）：Envoy 提供的异常摘除机制持续监控每个后端节点的错误率、延迟或连接失败次数，一旦超过阈值，临时将该节点从池中剔除。Nginx 的 max_fails 和 fail_timeout 是最基础的局部摘除实现。
Panic 阈值：这是 Istio/Envoy 中的核心安全机制。当健康后端的比例低于某个阈值（默认 50%）时，负载均衡器不再信任健康检查结果，暂时将所有节点都视为健康。其目的是防止因健康检查出现系统性假阴性而导致雪崩，即无节点可调度的情况。
# Envoy Outlier Detection 与 Panic 阈值配置示例
clusters:
- name: backend_cluster
outlier_detection:
consecutive_5xx: 5
interval: 10s
base_ejection_time: 30s
common_lb_config:
healthy_panic_threshold:
value: 50.0
Retry Budget（重试预算）：传统的重试策略（固定次数，如 3 次）在系统高负载时会成倍放大请求量，导致级联故障。重试预算的核心是限制重试流量占总流量的比例（例如不超过 10%），而不是固定次数。这确保即使在异常高发期，重试也不会压垮本已脆弱的后端。
11. 性能基准测试
负载均衡算法的选择不能仅凭理论推断，性能基准测试是最可靠的决策依据。下面提供基于 wrk 和 vegeta 的对比测试框架和 Python 压测数据收集脚本。
使用 wrk 测试不同算法的吞吐量：
# 启动一个基于轮询的负载均衡服务（端口 8080）
# 启动 wrk 进行压测
wrk -t12 -c400 -d30s http://localhost:8080/
使用 vegeta 压测并绘制延迟分布：
echo "GET http://localhost:8080/" | vegeta attack -rate=1000 -duration=60s | vegeta report -type=text
Python 压测数据收集与 P99 计算：
import time
import random
import statistics
import requests
from concurrent.futures import ThreadPoolExecutor, as_completed
def benchmark(lb_provider, url, concurrency=100, total_requests=10000):
"""
通用负载均衡性能基准测试框架。
lb_provider: 每次请求返回目标地址的可调用对象。
"""
latencies = []
errors = 0
def worker(_):
nonlocal errors
try:
target = lb_provider()
start = time.perf_counter()
resp = requests.get(f"http://{target}{url}", timeout=5)
latency = (time.perf_counter() - start) * 1000
if resp.status_code == 200:
latencies.append(latency)
else:
errors += 1
except Exception:
errors += 1
with ThreadPoolExecutor(max_workers=concurrency) as executor:
list(executor.map(worker, range(total_requests)))
latencies.sort()
p50 = latencies[len(latencies) // 2]
p99 = latencies[int(len(latencies) * 0.99)]
throughput = len(latencies) / sum(latencies) * 1000 * 1000
return {
"total": total_requests,
"success": len(latencies),
"errors": errors,
"p50_ms": round(p50, 2),
"p99_ms": round(p99, 2),
"throughput_rps": round(throughput, 2),
}
if __name__ == "__main__":
# 示例：模拟负载均衡选择
backends = ["127.0.0.1:8081", "127.0.0.1:8082"]
def pick():
return random.choice(backends)
# 注意：运行此脚本需要后端服务真实存在
# result = benchmark(pick, "/health", concurrency=50, total_requests=500)
# print(result)
生产环境测试建议：在对比不同算法时，应当保证后端服务完全一致，并在相同并发度（QPS）下进行测试，关注 P99 延迟的变化而非单纯平均延迟。最少连接和 Power of Two Choices 算法在处理时间差异大的负载下通常会显著优于轮询和随机算法。
总结
| 算法 | 适用场景 | 实现复杂度 |
|---|---|---|
| 轮询 | 服务器性能相同 | 低 |
| 加权轮询 | 服务器性能不同 | 低 |
| 最少连接 | 长连接、处理时间不均 | 中 |
| IP Hash | 会话保持 | 低 |
| 一致性哈希 | 缓存、有状态服务 | 中 |
| 自适应 | 动态负载变化 | 高 |
负载均衡算法的选择应当基于业务特性、网络拓扑和延迟要求综合判断。对于无状态的 API 网关 ，Power of Two Choices 结合最少连接能提供极佳的吞吐；对于缓存层，一致性哈希或 Maglev 是更优的选择；对于多活跨区域部署，则应关注 Envoy 的全局负载均衡与局部异常摘除机制的协同效果。真正的生产级负载均衡也不仅仅是请求调度，更是连接管理、健康检查、故障恢复和优雅降级等多个子系统的有机整合。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。