GRPC

在整体架构中，组件通过内存中的方法调用进行通信，这是即时且高度可靠的。然而，当迁移到微服务架构时，这些组件被网络边界分隔开。通信变成进程外网络调用（进程间通信，或 IPC）。 多年来，通过 HTTP/1.1 和 JSON 有效负载的 REST（表述性状态传输） 一直是构建 Web API 的默认标准。虽然 REST 非常适合面向公众的 Web 服务和客户端到服务器交互，但当用于高频、低延迟、内部服务到服务通信时，它会带来严重的瓶颈。 这就是现代微服务迅速转向**gRPC（Google 远程过程调用）**的原因。在本文中，我们将分析 REST 的局限性，剖析 gRPC 的架构支柱，并逐步完成在 Java 中 gRPC 服务的完整实现。 1. 微服务中 REST 的瓶颈 REST 为网络提供了二十多年的动力。然而，其底层技术并未针对内部分布式架构进行优化： A. 纯文本 JSON 的开销 JSON 是人类可读的，这使得调试变得容易，但对于机器到机器的通信来说效率极低： 序列化/反序列化成本：解析文本字符串标记并将其转换为对象会消耗大量 CPU 周期。 大有效负载大小：JSON 键在每个请求中都会重复（例如 {"transactionId": "123", "amount": 99.99}）。对于每秒处理数百万个请求的系统来说，这种冗余元数据浪费了巨大的网络带宽。 B. HTTP/1.1 连接限制 REST 通常在 HTTP/1.1 上运行，它表现出一些结构上的低效率： 队头 (HoL) 阻塞：在单个 TCP 连接上，客户端必须等待当前请求的响应，然后才能发送下一个请求。 连接池耗尽：为了处理并发请求，客户端必须打开多个 TCP 连接。当连接不断打开和关闭时，这会导致显着的操作系统资源开销、套接字耗尽以及慢启动性能损失。 C. 弱 API 合约 REST API 缺乏内置的编译时合约。虽然 OpenAPI/Swagger 有助于记录 API，但它们与代码库是分开的。后端开发人员很容易更改 JSON 字段名称并意外破坏下游服务，而不会出现编译时警告。