PHP实现RPC框架_远程过程调用原理与实践【操作】-php教程-PHP中文网

PHP实现RPC框架真正难点在于协议边界处理（需长度前缀防粘包）、序列化一致性（强制数组解码、规避资源/闭包）、反射调用安全隔离（白名单校验、禁用魔术方法、参数数量验证）及Swoole协程上下文管理（避免状态共享、禁用阻塞调用）。

php实现rpc框架_远程过程调用原理与实践【操作】

PHP 实现 RPC 框架不是“写个 socket 就完事”，真正卡住人的地方是协议边界、序列化一致性、以及服务端反射调用时的上下文隔离。不处理好这三点，本地跑通了，一上生产就丢包、错参、超时或直接 segfault。

原生 stream_socket_server 和 stream_socket_client 不带帧头，socket_read 可能一次只读到半条 JSON，也可能拼上两条——这就是典型的粘包问题。

别依赖 \n 或 \0 当分隔符：客户端若传的参数含换行（比如用户昵称是 "小明\n"），服务端会提前截断
必须加长度前缀：在 JSON 前写 4 字节网络序 int 表示 body 长度，服务端先读 4 字节，再按该长度读取完整 payload
客户端发送前要 pack('N', strlen($json)) . $json，服务端用 unpack('Nlen', stream_socket_recvfrom($client, 4)) 拿长度
超时必须设：用 stream_set_timeout($client, 5)，否则一个坏连接会卡死整个服务端循环

PHP 的 json_encode 默认不处理资源、闭包、私有属性；json_decode 默认返回 stdClass，不是数组，反射调用方法时参数类型会崩。

服务端接收后必须用 json_decode($raw, true) 强制转数组，否则 call_user_func_array 传参失败
客户端发参前检查是否可 JSON：用 json_last_error() === JSON_ERROR_NONE 验证，避免空字符串或 NaN 导致静默失败
别传 DateTime 对象：它会被转成空对象 {}，应统一转为 ISO8601 字符串并约定服务端解析逻辑
敏感字段（如 token）建议在传输层加密，JSON 本身不防窥探

直接 new $serviceClass + call_user_func_array 是高危操作：攻击者可构造 {"service":"ReflectionClass","method":"__construct","params":["phpinfo"]} 触发任意类实例化。

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

所有可暴露的服务类必须继承统一基类（如 AbstractRpcService），并在服务注册时显式声明允许的方法列表
服务端路由层查表匹配：isset($this->allowedMethods[$service][$method])，不命中直接返回 403
禁止通过反射访问 private/protected 方法，只允许 public 方法，且方法名不能含双下划线（防止调用 __destruct 等魔术方法）
参数数量也要校验：count($params) !== $refMethod->getNumberOfParameters()，少传或多传都拒掉

用 Swoole\Coroutine\Server 启动时，每个请求在一个协程中运行，但如果你在服务类里存了连接池、缓存句柄等状态，不同请求会互相污染。

不要在服务类属性里存 $this->pdo 或 $this->redis：协程间共享，A 请求 close 掉连接，B 请求再用就报错
改用 go(function () { $db = new PDO(...); /* 用完即弃 */ }); 或从协程本地存储（Co::getUid() + 全局数组）拿单例
Swoole\Http\Server 和 Swoole\Coroutine\Server 的回调签名不同：前者是 function ($request, $response)，后者是 function ($server, $fd, $from_id, $data)，混用会 crash
协程内禁止阻塞调用：如 sleep(1)、file_get_contents，必须换成 co::sleep 和 Co\Http\Client