Apache mod_proxy_balancer不支持实时动态权重偏移，但可通过balancer-manager手动调权、健康检查驱动衰减、配置热更新批量偏移三种方式，安全可控地模拟故障场景。
Apache 的 mod_proxy_balancer 本身不支持“实时动态权重偏移”作为故障演练原生功能，但可通过组合健康检查、运行时权重干预与人工触发机制，安全、可控地模拟权重倾斜、节点降级、流量压测等典型故障场景。关键不是让权重“自动漂移”，而是按需、可逆、可观测地人为扰动权重分布，从而验证集群容错能力。
一、用 balancer-manager 接口手动调整权重做演练
这是最轻量、最推荐的演练方式：不改配置、不重启、即时生效，且操作可记录、可回滚。
- 确保已启用并放行
/balancer-manager（需mod_status+ 访问控制） - 后端节点必须使用
route=参数（便于识别），且lbmethod已设为byrequests或bytraffic
执行示例（将 node2 权重临时调低至 1，模拟性能劣化）：
curl -X POST "http://lb.example.com/balancer-manager?b=mycluster&w=http://192.168.1.11:8080&dw=1"
恢复原权重（比如原为 5）：
curl -X POST "http://lb.example.com/balancer-manager?b=mycluster&w=http://192.168.1.11:8080&dw=5"
-
dw=表示 desired weight，直接覆盖内存中当前值 - 此操作仅影响本次运行状态，
apachectl graceful后会重置——适合短时演练 - 建议搭配监控看板（如 Prometheus + Grafana）观察请求分发比例变化
二、配合健康检查实现“阶梯式权重衰减”演练
模拟节点逐步失能过程（如 CPU 持续升高 → 响应变慢 → 错误增多），用健康检查结果驱动权重下调。
- 启用
mod_proxy_hcheck（Apache ≥2.4.33） - 配置主动探测，并关联自定义健康端点（如
/health?level=degraded）
示例配置片段：
<Proxy balancer://mycluster>
BalancerMember http://192.168.1.10:8080 route=node1 \
hcmethod=HTTP hcuri="/health?level=normal" hcinterval=5 hcfail=2 hcpass=3
BalancerMember http://192.168.1.11:8080 route=node2 \
hcmethod=HTTP hcuri="/health?level=degraded" hcinterval=5 hcfail=1 hcpass=1
</Proxy>- 当
/health?level=degraded返回 503（或超时），hcfail=1会立即标记 node2 为Down - 再配合外部脚本监听
/balancer-manager?json=1输出，检测到status=Down后，自动调用接口将其weight设为0或1，实现“权重归零式演练”
✅ 优势：贴近真实故障链路；❌ 注意：需后端服务配合提供多级健康响应
三、用配置热更新模拟“批量权重偏移”
适用于需要一次性拉偏多个节点权重、验证调度策略鲁棒性的场景（如灰度发布前压测）。
- 编写 Python/Shell 脚本，读取当前节点状态，生成新权重配置（如：所有偶数 IP 权重 ×0.3，奇数 ×1.5）
- 输出为临时 conf 片段（如
/etc/apache2/mods-enabled/balancer-weight-shift.conf） - 执行
apachectl graceful加载新权重
示例逻辑（伪代码）：
# 获取当前权重列表 → 按规则缩放 → 写入 new_weights.conf BalancerMember http://192.168.1.10:8080 loadfactor=5 # → 保持 BalancerMember http://192.168.1.11:8080 loadfactor=5 # → 改为 1 BalancerMember http://192.168.1.12:8080 loadfactor=5 # → 改为 0
-
graceful不中断连接，但要注意：频繁执行可能引发短暂请求排队 - 演练结束后，恢复原始配置并再次
graceful即可
四、验证演练效果的关键动作
权重变了，是否真生效？不能只靠猜，要实测：
- 查看
/balancer-manager页面，确认各 worker 的 “Current Requests” 和 “Load Factor” 显示值 - 在测试请求头中加
Connection: close，用curl -H "Connection: close" -sI http://lb/ | grep X-Backend观察后端标识分布 - 开启 Apache 日志
%{BALANCER_WORKER_ROUTE}e字段，统计各 route 出现频次（建议采样 1000+ 请求） - 若开启 sticky session，注意
stickysession=routeId是否仍能正确绑定，避免演练干扰会话一致性
不复杂但容易忽略。
