【面试锦囊】Swoole 在 RPC 框架中的核心考点

Swoole做RPC需闭环整合协程、协议设计、连接管理与错误传播：不能直接用SwooleClient（同步阻塞、无连接池、无请求ID绑定）；必须基于协程Socket+Channel实现长连接与请求分发；需处理TCP粘包（固定头+循环读取）；协程上下文须用Co::getContext()透传；超时需服务端主动中断；服务注册发现为必选项，至少用Redis心跳实现。

面试里聊到Swoole做RPC，千万别以为考官只是让你启动个 SwooleServer 就完事了。真正的考点是——你能不能把「协程调度、协议设计、连接管理、错误传播」这几块拼图完整地串起来，形成一个闭环落地方案。

为什么不能直接用 SwooleClient 做 RPC 客户端

不少同学一上来就写 $client->connect() + $client->send()，压测脚本里跑跑没问题，但一上生产场景立马露馅：

• SwooleClient 是同步阻塞模型，recv() 一调用就卡住当前协程，高并发下大量协程挂起，吞吐量直接掉到地板
• 没内置连接池，每次调用都得新建TCP连接，资源开销大不说，还容易把端口池搞爆，满屏 TIME_WAIT
• 自动重试？没有。超时控制只支持全局 timeout，颗粒度太粗。出错了到底是网络抖了一下还是服务真的挂了？根本分不清
• 最关键的是，它没有请求ID绑定机制——多个并发请求同时发出，返回时根本不知道哪个响应对应哪个请求，这就是“请求-响应”上下文缺失的尴尬

真正能用的客户端，得基于 SwooleCoroutineHttpClient 或者自己封装 SwooleCoroutineSocket，手动维护长连接，再用协程 Channel 做请求分发。这一步省不了。

onReceive 回调里必须处理粘包和半包

TCP 是纯流式协议，onReceive 收到的数据长度完全不可控——运气好一次来一个完整请求，运气不好两个请求挤在一起，或者一个请求被切成三截。不处理粘包，解析必然翻车。

• 必须定义固定长度的消息头，比如前4字节存 body 长度，先读够头部，再按长度读 body
• 别傻傻地用 strlen($data) 判断是否收全——要用 socket_recv 循环读取直到凑够长度
• 协程环境下推荐 SwooleCoroutineSocket::recv() 配合 unpack('N', $header) 解包，这样不会阻塞整个 worker
• 如果用 JSON 协议，千万不能直接 json_decode($data) ——数据没收完就 decode，百分百返回 null，而且没有任何错误提示，排查起来让人抓狂

协程上下文丢失是 RPC 最隐蔽的坑

RPC 调用链里经常需要透传 trace_id、用户身份、超时时间等上下文，但 PHP 协程切换时，全局变量、静态属性、$_SERVER 都不会自动继承。这个坑，不踩一次你根本意识不到。

• Co::getContext() 和 Co::setContext() 是唯一靠谱的方式——收到请求时存进去，调用业务逻辑之前取出来，一步都不能乱
• 别在服务端方法里直接读 $_SESSION 或 $_COOKIE——TCP RPC 里根本就没有 HTTP 上下文，读出来只能是空
• 超时控制不能只靠客户端 recv() 超时：服务端业务逻辑如果卡死（比如 DB 死锁），必须用 Co::sleep() + Co::cancel() 主动中断，否则那个协程就永久占着不放了
• 日志打点一定要带上协程 ID（Co::getuid()），不然所有请求日志混在一起，根本没法定位

服务注册与发现不是加分项，是必选项

面试官如果说“手写一个 RPC”，默认考的是可运行的最小闭环。没有注册中心的 RPC 就是硬编码 IP+端口，上线即失效，谁用谁头疼。

• 最低成本方案：用 Redis 的 SET key value EX 30 NX 做服务心跳注册，KEYS rpc:service:* 做临时发现（注意线上别用 KEYS，可以用 SCAN 替代）
• 客户端首次调用前必须拉取一次服务列表，后续用定时 GET 检查存活，而不是每次调用都去查 Redis——那样性能太差
• 别把服务发现逻辑写死在客户端代码里——要抽象成 RegistryInterface 接口，方便以后换成 Etcd 或 Nacos
• 负载均衡策略至少实现轮询（RoundRobin）和随机（Random），权重配置可以先不写，但接口要预留 weight 字段，方便后续扩展

真正难的不是写通一条调用链，而是让几十个服务节点在动态扩缩容、网络分区、进程重启时，依然能维持正确的服务寻址和流量分发——这个意识，比代码本身更重要。