C# grpc初步了解以及使用

原创已于 2025-11-12 15:59:00 修改 · 742 阅读

19 ·

CC 4.0 BY-SA版权

文章标签：

#c# #visual studio

于 2025-10-01 00:14:01 首次发布

适用场景

微服务间的通信
移动应用后端 API
需要高性能的分布式系统
多语言环境下的服务调用

HTTP (REST)：通常基于 HTTP/1.1。

明文传输：头部和载荷都是可读的文本，但体积大。
队头阻塞：一个连接只能处理一个请求，多个请求需要多个 TCP 连接，效率低。
无头部压缩：每次请求都携带大量重复的头部信息（如 Cookie、User-Agent）。

gRPC：基于 HTTP/2。

二进制传输：所有内容（头部和载荷）都是二进制的，体积小，解析快。
多路复用：一个 TCP 连接上可以同时交错多个请求和响应，彻底解决了队头阻塞。
头部压缩 (HPACK)：显著减少了头部大小。

服务器推送：服务端可以主动向客户端推送数据（虽然 gRPC 本身不常用此特性，但流式处理受益于 HTTP/2 的能力）。

数据格式：Protocol Buffers vs JSON

这直接影响了序列化/反序列化的速度和数据大小。

JSON：
- 优点：人类可读，通用性强，几乎所有编程语言都支持。
- 缺点：冗余信息多（重复的字段名），序列化/反序列化速度慢，数据体积大。
Protocol Buffers：
- 优点：
  - 体积小：使用二进制和字段编号，比 JSON 小 3 到 10 倍。
  - 速度快：编解码速度比 JSON 快 5 到 100 倍。
  - 强类型和清晰的结构：通过 .proto 文件明确定义数据结构，避免了歧义。
- 缺点：二进制格式对人类不可读，需要 .proto 文件才能正确解析。
HTTP (REST)：依赖于 REST 架构风格，使用 URL 路径和 HTTP 方法（GET, POST, PUT, DELETE）来定义 API。虽然可以用 Swagger/OpenAPI 来生成文档和代码，但这并非强制，质量和一致性依赖团队自觉。
gRPC：契约先行。你必须先在一个 .proto 文件中严格定义服务接口和消息格式。

protobuf
```
// 定义服务
service Greeter {
  // 定义一个 RPC 方法
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}
// 定义请求消息
message HelloRequest {
  string name = 1;
}
// 定义响应消息
message HelloReply {
  string message = 1;
}
```
然后，使用 gRPC 的工具可以自动生成客户端和服务端的代码骨架。这保证了跨语言、跨团队开发的一致性，极大提升了开发效率。
HTTP (REST)：一个请求对应一个响应。对于实时数据流（如股票报价、日志推送），需要借助 Server-Sent Events (SSE) 或 WebSockets 等额外技术，实现起来相对复杂。
gRPC：原生支持四种流模式：

这使得 gRPC 在处理实时通信、大文件上传/下载等场景时非常强大和自然。
- 一元 RPC：一个请求，一个响应。（像普通的 HTTP 请求）
- 服务端流式 RPC：一个请求，服务端返回一个流式的响应。
- 客户端流式 RPC：客户端发送一个流式的请求，服务端返回一个响应。
- 双向流式 RPC：客户端和服务端都可以同时发送流式数据。
微服务内部通信：需要高性能、低延迟、高吞吐量。
多语言环境：团队使用多种编程语言，需要严格的接口契约和高效的代码生成。
流式数据传输：需要处理实时数据流或大文件。
面向公众的 API：需要被浏览器、移动端或第三方开发者轻松调用。
简单性和易调试性：JSON 可读，使用 curl、Postman 等工具即可轻松测试。
无需高性能：系统交互不频繁，性能要求不高。

技术栈限制：环境无法支持 HTTP/2 或 gRPC 的库。

总结

	gRPC	HTTP (REST)
核心优势	性能、效率、流式、强契约	通用性、简单性、浏览器兼容性
哲学	为机器与机器的高效通信而设计	为系统与系统（包括人机）的通用交互而设计

在现代架构中，两者常常是共存的：使用 gRPC 作为内部微服务之间的“高速公路”，同时对外暴露一个 RESTful API 网关，以便外部客户端和浏览器访问。这样既保证了内部通信的效率，又兼顾了外部的通用性。