grpc php怎么用？跟着这份入门教程轻松上手！

发布日期： 2025-09-24 阅读量： 作者： admin

最近手头项目服务间通信有点多，老用 HTTP 那套，传来传去都是 JSON，感觉有点笨重，性能上也不是最优。听同事念叨了几次 gRPC，说这玩意儿效率高，基于 HTTP/2，还是二进制传输，就想着自己动手试试看在 PHP 里能不能跑起来。

准备工作

一开始嘛肯定得先把环境搭起来。我寻思着 PHP 跑 gRPC，总得有个扩展支持。上网一搜，果然，得装个 gRPC 的 PHP 扩展。还好有 PECL，直接在服务器上敲了命令：

pecl install grpc

装这个过程还算顺利，没碰到啥大坑。装完之后，记得要在 `*` 文件里把这个扩展加上，比如加一行 `extension=*`，然后重启一下 PHP-FPM 或者 Apache 之类的，让它生效。

光有扩展还不够，gRPC 这玩意儿是基于 Protobuf（Protocol Buffers）来定义服务和消息格式的。还得装个 Protobuf 的编译器，就是那个 `protoc` 工具。这个工具是用来把我们写的 `.proto` 文件编译成 PHP 代码的。我这边系统是 Linux，直接用包管理器就装上了，挺方便。

定义服务和消息

环境搞定了，接下来就得定义服务了。这就是写 `.proto` 文件。我先试着定义一个简单的服务，比如说，就叫 `Greeter`，里面有个方法叫 `SayHello`，接收一个 `HelloRequest` 消息，返回一个 `HelloReply` 消息。消息里面也就简单包含个字符串字段。

写这个 `.proto` 文件感觉还行，语法挺清晰的，照着官方文档的例子，大概就能写出来。定义好了谁能调用啥方法，传啥参数，返回啥结果。

生成 PHP 代码

写好 `.proto` 文件后，就轮到 `protoc` 工具上场了。得用它来生成 PHP 的客户端和服务端的代码骨架。命令大概是类似这样的：

protoc --php_out=. --grpc_out=. --plugin=protoc-gen-grpc=`which grpc_php_plugin` your_*

这里 `your_*` 就是我刚写的那个 `.proto` 文件名。执行完这个命令，就会在当前目录下生成一堆 PHP 文件。里面包含了定义的消息类、客户端的存根（Stub）代码，还有服务端需要实现的接口。

编写服务端

有了生成的代码，就可以开始写服务端逻辑了。我这边就简单写了个 PHP 脚本。主要是创建一个类，继承自生成的服务接口（比如 `GreeterService`），然后实现里面定义的方法（比如 `SayHello`）。

在 `SayHello` 方法里，就写真正的业务逻辑。比如从请求里拿到名字，然后拼接个 "Hello, [名字]" 字符串，放到响应消息里返回。

写完逻辑，还得启动一个 gRPC 服务器来监听请求。我用了 PHP 的 gRPC 库提供的 `Server` 类，设置好监听的地址和端口，把我写的服务实现注册进去，然后 `run()` 起来就行了。这个服务端脚本需要一直跑着。

注意： PHP 本身处理并发请求能力有限，如果是生产环境，很多人会结合 Swoole 或者 Hyperf 这样的框架来跑 gRPC 服务端，性能会好很多。我这回实践就先简单跑个脚本试试。

编写客户端

服务端跑起来了，就该写个客户端去调用它了。客户端写起来感觉更简单点。

主要是用生成的那个客户端存根类（比如 `GreeterClient`）。实例化它的时候，需要传入服务端的地址和端口，还有一些连接凭证（我本地测试就用了不安全的连接）。

然后，就可以像调用本地方法一样，直接调用 `SayHello` 方法了。创建一个 `HelloRequest` 对象，把名字填进去，传给 `SayHello`。这个方法会返回一个包含 `HelloReply` 对象的数组（通常只有一个元素）和状态信息。从 `HelloReply` 对象里就能取出服务端返回的消息了。

跑起来试试

两边代码都写好了。我先在终端里把服务端脚本跑起来，看着它监听在指定的端口。然后在另一个终端里运行客户端脚本。

第一次跑，客户端成功连接到服务端，发送了请求，也收到了服务端返回的 "Hello, World" 之类的消息。成功了！感觉挺神奇的，就像调用本地函数一样，但实际上是跨进程甚至跨机器通信了。

试着传了点不同的数据，改了改服务端的逻辑，都还挺顺利。确实感觉比搭个 HTTP 接口，然后用 cURL 或者 Guzzle 去请求要规整一些，特别是接口定义这块，有 `.proto` 文件约束着，不容易出错。

一点想法

总的体验下来，PHP 搞 gRPC 是完全没问题的。就是前期准备工作比搞个简单的 REST API 要多一些，得装扩展、装工具、写 proto 定义、生成代码。但一旦这些弄好了，后面写客户端和服务端的逻辑，感觉因为有代码生成，反而更清晰规范了。

性能方面，虽然我没做严格的基准测试，但直观感觉二进制传输和 HTTP/2 带来的效率提升应该是实打实的，特别是在内部服务间频繁调用的场景下，这点优势应该会比较明显。

如果项目对性能有要求，或者想让服务间的接口定义更严格规范，用 gRPC 是个不错的选择。也得考虑团队对这套东西的熟悉程度，以及维护成本会不会增加。对我来说，这回实践还是挺有收获的，以后项目里可以考虑用起来了。

上一篇: 免备案香港服务器租用选哪家？这几点帮你选对！

下一篇: 想知道哪里能注册org域名？对比这几个注册商不踩坑！

grpc php怎么用？跟着这份入门教程轻松上手！

随便看看