单纯部署Hyperf集群无法缓解FPM负载，因未切断旧流量链路、存在反向依赖及gRPC连接池未配置，必须通过切流、解耦和显式配置连接池（如min_connections=2、max_connections=8）三步协同优化。
直接换 Hyperf 不能自动解决 FPM 负载过高问题——协程集群本身不“分摊”旧流量，必须配合服务拆分、流量迁移和连接复用策略，否则可能把压力从 FPM 进程转移到 Swoole 主进程或 gRPC Channel 上。
为什么单纯部署 Hyperf 集群反而更卡
很多团队在 FPM CPU 持续 90%+ 时紧急上线 Hyperf，结果发现 QPS 没涨、延迟更高。根本原因不是协程不行，而是没切断旧链路：
- FPM 流量仍全打到旧入口（如 Nginx 的
fastcgi_pass未切流），Hyperf 实例空跑 - Hyperf 新服务调用老 FPM 接口（比如通过
HttpClient请求http://old-api/），形成反向依赖和单点瓶颈 - gRPC 客户端复用
GrpcChannel，但没配'pool' => ['max_connections' => 8]，导致所有请求挤在 1–2 个 TCP 连接上，后端实例负载倾斜
必须做的三件事：切流、解耦、控连接
不是“部署完就生效”，而是每一步都影响最终水位：
- 用 Nginx 的
split_clients或map+upstream按请求路径/Header 分流，例如把/api/v2/.*全切到 Hyperf，/api/v1/.*留给 FPM，避免灰度期互相拖垮 - 把原 FPM 项目里的数据库、Redis、HTTP 调用全部抽成独立 service，Hyperf 通过
ServiceInterface注入调用，禁止直接file_get_contents或curl_exec访问本机 FPM - 在
config/autoload/services.php中为每个消费者显式配置连接池：'pool' => ['min_connections' => 2, 'max_connections' => 8, 'connect_timeout' => 5.0, 'wait_timeout' => 3.0]，否则默认max_connections = 1，协程再多也串行
gRPC 客户端负载不均的典型误判
监控看到某台后端 CPU 100%，其他几台 10%，第一反应是 “RoundRobin 失效”，大概率错在连接复用机制：
-
BaseClient实例被长生命周期持有（比如定义为singleton），导致所有协程共用同一个GrpcChannel，轮询逻辑只在首次连接时生效 - 注册中心里实例状态不一致：某台节点在 Nacos 显示
UP，但实际健康检查接口返回 503，Hyperf 不主动剔除，仍计入负载列表 - 没开
enable.discovery => true，却写了'load_balancer' => 'roundrobin'，此时框架直接忽略配置，固定打第一个servers数组元素
真正要盯住的不是算法名字，而是 GrpcChannel 的复用边界和注册中心的实时状态——这两处不动，换 least_conn 或 consistent_hash 都只是障眼法。
