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 {// 一个简单的 RPCrpc 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打开以查看