Apache mod_proxy_balancer 不支持基于 CPU 的调度，因其仅处理 HTTP 转发，无法获取后端 JVM 或系统级 CPU 指标；内置算法（byrequests、bytraffic、bybusyness）均依赖代理层可观测数据，与 CPU 无关。

Apache mod_proxy_balancer 本身不支持基于节点 CPU 使用率的调度。

为什么不能直接按 CPU 调度

Apache 的负载均衡逻辑运行在反向代理层，它只处理 HTTP 请求的转发与响应，不具备访问后端 Java 进程或操作系统级指标（如 CPU、内存、线程数）的能力。所有内置调度算法（byrequests、bytraffic、bybusyness）都依赖 Apache 自身可观察的代理维度数据：

• byrequests：统计已分发请求数
• bytraffic：累加响应字节数
• bybusyness：跟踪当前活跃连接数（仅限当前 worker 正在处理的请求数）

这些都不是 CPU 指标，也无法实时感知后端 JVM 的 GC 压力或系统负载突增。

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

可行的替代方案

若你确实需要“CPU 感知”的流量调度，需在 Apache 外围构建一层适配逻辑：

• 用健康检查端点暴露 CPU 指标：在每个 Java 微服务中提供 /health/cpu 接口（如 Spring Boot Actuator + 自定义 HealthIndicator），返回 JSON：{"status":"UP","details":{"cpuUsage":78.2}}
• 用 ping 参数做轻量探测：Apache 2.4.33+ 支持 ping=5,GET,/health/cpu，但注意：
  — 它只判断 HTTP 状态码和超时，不解析响应体
  — 无法根据 cpuUsage > 80 动态降权，只能整体标记为失效
• 引入外部调度器：用 Prometheus + Alertmanager 监控各节点 CPU，触发脚本调用 balancer-manager API 或修改配置并重载 Apache —— 实现“CPU 高 → 临时降低 loadfactor 或设 status=+D”
• 换用更合适的网关：Nginx Plus 支持 least_conn 和自定义 upstream 模块；Envoy 可通过 Lua 或 WASM 插件读取 /metrics 并动态更新集群权重；Kubernetes Ingress Controller + Horizontal Pod Autoscaler 更适合云原生场景

不推荐的“伪实现”

有人尝试用 bybusyness 代替 CPU 调度，这是误解：

• bybusyness 只看当前正在处理的请求连接数，和 CPU 利用率无直接关系
• 一个 CPU 密集型请求可能长期占用线程但连接数不变，bybusyness 完全无法识别
• 该算法也已标记为 deprecated，官方文档明确建议避免使用

靠 Apache 单独实现 CPU 感知调度，技术上不可行，工程上也不可持续。