GRPC 和 传统的RPC区别

区别:

1、底层通信协议（最大的不同）

　　传统 RPC：通常基于 TCP 长连接，通过自定义的协议头来传输数据。这是为了极致性能，但开发复杂，且对防火墙或代理不友好。

　　gRPC：强制使用 HTTP/2.0 作为底层传输协议。HTTP/2 具备多路复用（在一个连接上并发处理多个请求，解决了 HTTP/1.1 的队头阻塞）、头部压缩 等特性。这使得 gRPC 在微服务间通信时网络效率极高，且天然支持代理和负载均衡。

 

2、数据序列化方式（传输的“语言”）

　　传统 RPC：支持多种序列化方式，比较灵活。例如 Java 自带的序列化、Hessian（二进制）、甚至 JSON/XML（文本）。灵活性高，但性能参差不齐。

　　gRPC：强制使用 Protobuf（Protocol Buffers，协议缓冲区）。这是谷歌开发的一种二进制序列化协议。相比 JSON，Protobuf 序列化后的体积更小（节省带宽），解析速度更快（CPU 占用低），且数据模型是强类型的（.proto 文件定义）。

 

3、流式传输（Streaming）能力

　　传统 RPC：绝大多数是 “请求-响应” 模式（Unary）。客户端发一个请求，服务端回一个响应，像打电话一样一问一答。

　　gRPC：基于 HTTP/2，原生支持 4 种通信模式：

1. 一元（请求-响应）
2. 服务端流（客户端发一次，服务端持续返回多条数据，如股票行情推送）
3. 客户端流（客户端持续发多条，服务端最后返回一次）
4. 双向流（双方像建立了一条数据管道，可以同时互相发送数据，非常适合理性实时交互）。

 

4、跨语言支持（多语言兼容性）

　　传统 RPC：像 Dubbo 早期对 Java 依赖极重，跨语言支持较弱（虽然现在有 Polyglot，但配置复杂）。

　　gRPC：官方提供了 C++、Java、Go、Python、Ruby、Node.js 等十几种语言的生成工具。只要定义了同一个 .proto 文件，不同语言的服务就能无缝通信，非常适合异构的微服务环境。

 

5、服务定义与代码生成

　　传统 RPC：定义方式各异，有些依赖接口注解，有些依赖注册中心的元数据，契约比较松散。

　　gRPC：必须使用 .proto 文件严格定义服务的接口（方法名、参数、返回类型）。通过 protoc 编译器，可以直接生成客户端和服务端的 SDK 代码，确保了强契约（Contract-First），减少了协作中的接口不匹配问题。