定义
gRPC是一个高性能、通用的开源远程过程调用框架，由Google开发，属于云原生计算基金会(Cloud Native Computing Foundation，CNCF)生态中的项目[3][1]。它基于「定义服务」的思路工作：开发者先声明一个服务，列出可以远程调用的方法及其参数和返回类型，再由框架生成对应的客户端与服务端接口，服务端实现这些接口，客户端则通过生成的接口发起调用[1][4]。
从应用层面看，gRPC把客户端与后端服务之间的消息传递过程做了封装。调用方写的是一段普通的本地函数代码，实际执行时却变成了对远程服务的跨进程调用，网络通信、序列化和执行等细节都由RPC管道隐藏起来[3]。它主要面向微服务等需要跨语言、跨平台通信的场景[2]。
在服务定义中，gRPC默认采用协议缓冲区(Protocol Buffers)作为接口定义语言(IDL)，服务接口和消息结构都写在以.proto为扩展名的文本文件里；同一份定义文件可以用于不同开发平台构建的客户端和服务端[3]。除协议缓冲区外，理论上也可以换用其他定义方式[4]。
原理
gRPC的抽象协议规定，一次调用由客户端发起一条双向消息流。在客户端到服务端的方向上，消息流以必须的调用头开始，随后是可选的初始元数据，再往后是0个或多个载荷消息；服务端到客户端的方向则包含可选的初始元数据、若干载荷消息，并以必须的状态码和可选的状态元数据结尾[4]。
这套抽象协议具体承载在HTTP/2之上。gRPC的双向消息流被映射为HTTP/2流，调用头与初始元数据作为HTTP/2头部发送并经过HPACK压缩；载荷消息被序列化成带长度前缀的gRPC帧，再由发送方切分进HTTP/2帧、由接收方重新组装；状态码和尾部元数据则使用HTTP/2的尾部头部发送[4]。协议缓冲区把消息序列化为二进制字节，而非JSON、XML那样的文本[3]。
在通信模式上，gRPC支持一元调用、服务端流、客户端流和双向流4种形式。一元调用是单次请求对应单次响应；服务端流由客户端发一次请求、服务端返回一串响应；客户端流是客户端连续发送多条消息、服务端给出一次响应；双向流则允许双方同时收发消息流，消息按发送顺序投递[5][4]。gRPC还沿用了HTTP/2的流控机制，用于精细控制缓冲在途消息所占用的内存[4]。
调用方式上，大多数语言的gRPC编程接口同时提供同步与异步两种形式。同步调用会阻塞当前线程直至服务端返回响应，最接近RPC所追求的过程调用抽象；而网络本身是异步的，因此框架也允许在不阻塞线程的情况下发起调用[4]。
发展历程
gRPC发布于2015年2月26日，由Google以开源方式推出，采用BSD许可证，基于当时刚刚定稿的HTTP/2标准。Google表示，其内部服务每秒要处理数百亿次调用，效率和可扩展性是构建其API的核心考量，而gRPC凝结了该公司多年构建分布式系统的经验[2]。在此之前，Google内部长期使用名为Stubby的内部框架，gRPC正是由它发展而来[5]。
发布之初，gRPC项目已支持C、C++、Java、Go、Node.js、Python和Ruby，Objective-C、PHP和C#的库尚在开发中。Google当时正与Square等机构合作推进该项目，并开始把自家对外服务通过gRPC端点开放[2]。与gRPC一同发布的还有协议缓冲区的新版本Proto 3，它增加了语言支持，并提供了协议缓冲区到JSON的规范映射[2]。
此后gRPC成为云原生计算基金会生态的一部分，被该基金会视为孵化中的项目，意味着已有最终用户在生产应用中使用它，且项目拥有较多贡献者[3]。在具体平台上，gRPC被集成进.NET Core 3.0及更高版本的开发工具包[3]。
应用
gRPC常用于低延迟、高扩展性的分布式系统，与云服务器通信的移动应用客户端，以及需要设计语言独立、高效精确的新协议的场景。其分层设计也便于在认证、负载均衡、日志记录和监控等方面进行扩展[6]。在云原生应用中，开发者往往同时面对不同的编程语言、框架和技术，gRPC提供统一的水平层来抽象跨平台通信所需的管道，使开发者可以专注于业务功能[3]。
在微服务与服务间通信中，gRPC的适用条件包括调用频繁且对延迟敏感、需要控制载荷体积、强调强类型与契约优先的开发方式，以及流式传输为核心需求。交易系统、实时分析、游戏后端以及物联网遥测等场景都属于典型用法[5]。相比REST风格的接口，gRPC在服务间通信方向上通常被选用，二者可以在同一套架构中承担互补的角色[5]。
在网关层面，gRPC服务可以通过支持HTTP/2的网关直接代理，由网关施加认证、限流和日志等能力；网关也可承担协议转换，把基于HTTP的RESTful JSON请求翻译为gRPC请求，使得浏览器等客户端无须特殊的gRPC客户端库即可访问gRPC服务[1][5]。服务配置和接口定义文件还可用于生成API的参考文档[1]。
局限
gRPC的消息采用二进制编码，不像JSON那样可以直接阅读，查看和调试时需要借助专门工具。它默认也不支持HTTP缓存机制，而REST接口可以借助HTTP缓存语义[5]。
浏览器支持是另一处短板。gRPC需要客户端库的配合，浏览器无法直接使用，通常要经过代理或协议转换才能访问gRPC服务，这也是gRPC更多用于内部服务间通信、而对外公开API仍多采用REST的原因之一[5][6]。
在工具与生态方面，gRPC的支持仍在完善之中，相比REST已有的成熟工具链存在差距[5]。gRPC对HTTP/2的依赖也带来约束：当客户端与gRPC服务之间经由网关通信时，部分网关尚未支持载荷压缩和协议缓冲区以外的接口定义语言[1]。此外，gRPC默认以协议缓冲区作为接口定义语言，虽然设计上允许替换，但支持其他数据格式需要额外实现[6]。
参见
参考资料
- gRPC 概览 | API Gateway | Google Cloud Documentation [引用日期2026-10-14]
- Introducing gRPC, a new open source HTTP/2 RPC Framework [引用日期2026-10-14]
- gRPC [引用日期2026-10-14]
- gRPC Concepts Overview [引用日期2026-10-14]
- apache.org 上的网页 [引用日期2026-10-14]
- gRPC：Google开源的基于HTTP/2和ProtoBuf的通用RPC框架 [引用日期2026-10-14]