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-managerAPI 或修改配置并重载 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 感知调度，技术上不可行，工程上也不可持续。
