GRPC详解 - 技术栈

h5打开以查看

一、什么是 gRPC？

gRPC 是一个高性能、开源、通用的 RPC 框架，由 Google 开发并基于 HTTP/2 和 Protocol Buffers 构建。

让我们分解这个定义：

RPC： 远程过程调用。它是一种技术，允许你像调用本地函数一样调用另一台机器（远程）上的函数或方法。它抽象了底层的网络通信复杂性。
高性能： 主要得益于其使用 HTTP/2 作为传输协议和 Protocol Buffers 作为序列化/反序列化工具。
通用： 可用于连接多种语言和环境中的服务，如微服务、移动客户端与后端、浏览器与后端等。
HTTP/2： 下一代 HTTP 协议，支持多路复用、头部压缩、服务器推送等特性，极大地提高了网络效率。
Protocol Buffers： gRPC 默认的接口定义语言和数据序列化工具。它高效、跨平台且语言中立。

二、核心概念与工作原理

1. Protocol Buffers

这是 gRPC 的基石。你首先需要定义 .proto 文件。

服务定义： 指定可以被远程调用的方法，以及它们的参数和返回类型。
消息定义： 指定方法之间传递的数据结构。

示例 hello.proto：

protobuf

复制代码

// 指定 protobuf 版本
syntax = "proto3";

// 定义包名（可选，用于防止命名冲突）
package hello;

// 定义服务，包含可被远程调用的方法
service Greeter {
  // 一个简单的 RPC
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// 定义请求消息的类型
message HelloRequest {
  string name = 1; // 字段的编号，用于二进制编码中标识字段
}

// 定义响应消息的类型
message HelloReply {
  string message = 1;
}

关键点：

这个 .proto 文件是契约，与编程语言无关。
使用 protoc 编译器，可以生成各种语言（如 Go, Java, Python, C#, JavaScript 等）的代码。
生成的代码包括：用于序列化/反序列化消息的类/结构体，以及客户端和服务端的基类/接口。

2. gRPC 的四种通信模式

一元 RPC
- 最简单的模式，类似于普通的函数调用。
- 客户端 发送一个请求，服务端返回一个响应。
- rpc SayHello (HelloRequest) returns (HelloReply) {}
服务端流式 RPC
- 客户端发送一个请求，服务端返回一个消息流。
- 客户端从返回的流中读取，直到没有更多消息。
- 适用场景： 服务器向客户端传输大量数据，如日志文件、视频流、数据库查询结果集。
- rpc LotsOfReplies (HelloRequest) returns (stream HelloReply) {}
客户端流式 RPC
- 客户端发送一个消息流，服务端返回一个单一的响应。
- 客户端一边写入消息流，一边等待服务端的响应。
- 适用场景： 客户端向服务器上传大量数据，如文件上传、传感器数据上报。
- rpc LotsOfGreetings (stream HelloRequest) returns (HelloReply) {}
双向流式 RPC
- 客户端和服务端都使用一个读写流来发送一系列消息。
- 两个流是独立的，可以按任意顺序读写。
- 适用场景： 实时通信，如聊天应用、游戏、双向数据同步。
- rpc BidiHello (stream HelloRequest) returns (stream HelloReply) {}

三、架构与数据流

直观地展示了 gRPC 的核心架构与四种通信模式的数据流。

四、为什么使用 gRPC？优点与缺点

优点

高性能
- HTTP/2: 多路复用允许在单个 TCP 连接上同时处理多个请求，避免了 HTTP/1.1 的队头阻塞问题。头部压缩减少了开销。
- Protocol Buffers: 是一种二进制格式，比 JSON/XML 更小、序列化和反序列化更快。
强类型契约和代码生成
- .proto 文件是明确的、版本化的契约。
- 自动生成的客户端和服务端代码减少了样板代码，确保了类型安全，并简化了开发。
跨语言互操作性
- 只要共享同一个 .proto 文件，用不同语言编写的服务可以轻松地相互通信。
内置功能丰富
- 认证： 支持 SSL/TLS 和基于令牌的认证。
- 负载均衡： 可与外部负载均衡器集成。
- 超时和重试： 可以配置截止时间和重试策略。
- 流控制： 得益于 HTTP/2。
- 可插拔的中间件： 支持拦截器，用于日志、认证、指标收集等。
非常适合微服务架构
- 在微服务环境中，服务之间的高效、类型安全的通信至关重要，gRPC 完美地满足了这一需求。

缺点

对人类不友好
- 由于使用二进制编码，消息不能被人类直接读取和调试。不能像 JSON 那样直接用 curl 命令测试（虽然有 grpcurl 等工具可以弥补）。
浏览器支持有限
- 浏览器无法直接发起 gRPC 请求（因为无法强制使用 HTTP/2 和操纵底层帧）。通常需要 gRPC-Web 代理来将 HTTP/1.1 请求转换为 gRPC 请求。
学习曲线
- 需要学习 Protocol Buffers 语法和 gRPC 的概念，相对于简单的 REST/JSON API 门槛更高。
不是面向资源的
- gRPC 使用自定义方法，而 REST 围绕 HTTP 动词（GET, POST, PUT, DELETE）和资源设计。对于面向资源的 API，REST 可能更直观。

五、gRPC vs. REST API

特性	gRPC	REST API
协议	HTTP/2	主要是 HTTP/1.1
数据格式	Protocol Buffers（二进制）	JSON/XML（文本）
契约	强类型，强制（.proto）	弱类型，可选（如 OpenAPI/Swagger）
性能	高（二进制，多路复用）	较低（文本，队头阻塞）
流式传输	原生支持四种模式	有限支持（如 Server-Sent Events）
代码生成	一流支持，内置	第三方工具（如 Swagger Codegen）
浏览器支持	需要 gRPC-Web	原生支持

六、使用场景

微服务间通信： 这是 gRPC 最主要的应用场景，尤其是在对性能要求高的系统中。
多语言环境： 当你的技术栈包含多种编程语言时，gRPC 是理想的连接桥梁。
点对点实时通信： 需要双向流式的场景，如聊天、游戏、指令下发。
移动客户端与后端： 二进制格式有助于节省移动设备的带宽和电量。
云原生应用： Kubernetes、etcd 等云原生基础设施的核心组件都使用 gRPC 进行通信。

总结

gRPC 是一个强大的现代 RPC 框架，它通过 HTTP/2 和 Protocol Buffers 的结合，提供了卓越的性能、类型安全和开发效率。虽然它在调试和浏览器兼容性方面存在一些挑战，但其在微服务、跨语言服务和性能敏感型应用中的优势是压倒性的。如果你正在构建一个分布式系统，gRPC 绝对是一个值得深入研究和采用的技术。

h5打开以查看