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)——数据未收完就解码，必然返回null且不给出任何错误提示，排查起来极为痛苦

协程上下文丢失：RPC中最隐蔽的陷阱

RPC调用链中常需要传递trace_id、用户身份、超时时间等上下文信息，但PHP协程切换时，全局变量、静态属性、$_SERVER都不会自动继承。这个坑不亲身体验很难察觉。

• Co::getContext()与Co::setContext()是唯一可靠的方式——收到请求时存入上下文，执行业务逻辑前取出，顺序不能乱
• 不要在服务端方法内直接读取$_SESSION或$_COOKIE——TCP RPC没有HTTP上下文，读取到的只能是空值
• 超时控制不能仅依赖客户端recv()超时：若服务端逻辑卡死（如数据库死锁），必须通过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字段，便于后续扩展

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