hyperf 的协程 rpc 通过协程驱动、协程化客户端、多协议优化及服务治理四层设计实现高性能通信：协程轻量无切换开销，全链路协程 io，支持 json-rpc/http、json-rpc/tcp、grpc 多协议及连接池复用，并内置服务发现、负载均衡、熔断降级等治理能力。
Hyperf 的协程 RPC 实现高性能通信，核心在于把“协程 + 非阻塞 IO + 协议优化 + 资源复用”四者深度耦合，不是简单替换通信方式，而是重构整个调用生命周期。
协程驱动，避免进程/线程切换开销
传统 PHP-FPM 每次请求启动新进程，加载代码、初始化环境、释放内存，开销大且无法复用状态。Hyperf 启动后常驻 Worker 进程，每个 RPC 请求由 go() 启动独立协程处理：
- 协程轻量（KB 级内存），单进程可并发数万，无上下文切换成本
- IO 操作（如调用下游服务、查 Redis）自动让出控制权，不阻塞整个 Worker
- 同一进程内多个协程共享已加载的类、配置、连接池实例，省去重复初始化
原生协程客户端，杜绝阻塞式调用
RPC 性能瓶颈常不在协议本身，而在客户端是否协程安全。Hyperf 强制使用协程化底层组件：
- HTTP 调用走
Hyperf\HttpClient\Client（基于 Swoole Coroutine HTTP Client） - MySQL 查询用
Hyperf\DbConnection\Db（协程 MySQL 驱动） - Redis 操作用
Hyperf\Redis\Redis（协程 Redis 客户端） - 所有网络 IO 统一被 Swoole Runtime Hook，
file_get_contents、curl_exec等也能自动协程化
多协议分层与序列化优化
Hyperf 不绑定单一协议，按场景选型并做极致压缩：
- JSON-RPC over HTTP：调试友好，Postman 直连；适合内部管理后台、低频服务
- JSON-RPC over TCP：去掉 HTTP 头开销，连接更轻量，适合高频内网调用
- gRPC：默认使用 Protobuf 二进制序列化，体积比 JSON 小 60%–80%，解析更快；支持流式传输和双向通信
- 所有协议层均支持连接池复用，避免频繁建连断连
服务治理能力直接嵌入通信链路
高性能不只是快，更是稳定可持续的快。Hyperf 把治理能力作为 RPC 的“基础设施”：
- 服务发现（Nacos/Consul）自动刷新节点列表，调用前实时获取健康地址
- 内置负载均衡策略（轮询、随机、一致性哈希），请求均匀打到各实例
- 熔断器在失败率超阈值时自动切断请求，防止雪崩；降级逻辑可快速返回兜底数据
- 中间件流水线统一注入监控（TraceID）、日志、限流，不影响业务代码
