前言
gRPC 是一种高性能、开源的远程过程调用（RPC）框架，基于 HTTP/2 协议，支持双向流、头部压缩等特性。它默认使用 Protocol Buffers（Protobuf）作为接口定义语言（IDL）和数据序列化格式，适用于微服务、实时通信等场景。
我们可以结合常用的http服务来了解它。本质上讲，http服务是基于http协议，是一个应用层协议，RPC是基于TPC/IP，是一个传输层协议。应用层协议在传输层之上，所以RPC效率更高，所以RPC更适合内网调用，不必每次通信都要像http一样去3次握手什么的，减少了网络开销。
RPC架构
一个完整的RPC架构里面包含了四个核心的组件，分别是Client ,Server,Client Stub以及Server Stub，这个Stub大家可以理解为存根。分别说说这几个组件：
- 客户端（Client），服务的调用方。
- 服务端（Server），真正的服务提供者。
- 客户端存根，存放服务端的地址消息，再将客户端的请求参数打包成网络消息，然后通过网络远程发送给服务方。
- 服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法。
与http对比使用场景
1. 协议与数据格式
| 特性 | gRPC | HTTP 接口（REST） |
|---|---|---|
| 协议 | 基于 HTTP/2 | 基于 HTTP/1.1 或 HTTP/2 |
| 数据格式 | 使用 Protocol Buffers（Protobuf） | 通常使用 JSON 或 XML |
| 传输方式 | 二进制传输 | 文本传输 |
2. 性能
| 特性 | gRPC | HTTP 接口（REST） |
|---|---|---|
| 序列化效率 | Protobuf 是二进制格式，序列化效率高 | JSON/XML 是文本格式，序列化效率较低 |
| 传输效率 | 基于 HTTP/2，支持多路复用和头部压缩 | HTTP/1.1 不支持多路复用，效率较低 |
| 延迟 | 低延迟，适合实时通信 | 延迟较高，适合简单请求-响应场景 |
3. 通信模式
| 特性 | gRPC | HTTP 接口（REST） |
|---|---|---|
| 通信模式 | 支持四种模式： 1. 一元 RPC 2. 服务器流 RPC 3. 客户端流 RPC 4. 双向流 RPC |
仅支持请求-响应模式 |
| 实时通信 | 支持双向流，适合实时通信 | 不支持双向流，需通过轮询模拟 |
4. 开发与使用
| 特性 | gRPC | HTTP 接口（REST） |
|---|---|---|
| 接口定义 | 使用 Protobuf 定义服务接口，强类型 | 使用文档（如 OpenAPI）定义接口 |
| 代码生成 | 自动生成客户端和服务器代码 | 通常需要手动编写客户端代码 |
| 调试工具 | 工具较少，调试复杂 | 工具丰富（如 Postman） |
| 跨语言支持 | 支持多种语言（C++, Java, Go, C# 等） | 支持多种语言，但需要手动适配 |
5. 适用场景
| 特性 | gRPC | HTTP 接口（REST） |
|---|---|---|
| 微服务通信 | 适合高性能、低延迟的微服务通信 | 适合简单的服务间通信 |
| 实时通信 | 适合实时通信场景（如聊天、推送） | 不适合实时通信 |
| 跨语言通信 | 适合异构系统之间的通信 | 适合简单的前后端通信 |
| 浏览器支持 | 需要 gRPC-Web 适配 | 原生支持 |
