gRPC的架构和工作原理，以及和RPC的差异

这张图其实把 “本地函数调用” 和 “远程过程调用（RPC）” 的差别，以及 gRPC 把 RPC 工程化后的完整链路 都画出来了。

1) 先读图：从“本地调用”到“远程调用”

• 本地调用：OrderManagement -> Payment 就是同一进程内的函数调用，参数按内存传递，几乎不需要“序列化/网络/协议”。

• 远程调用（RPC）：Server A(Order Service) -> Server B(Payment Service)，调用“看起来像函数”，但实际上必须解决：

  1. 怎么表达“要调用哪个方法 + 参数”？

  2. 参数/返回值怎么序列化？

  3. 怎么通过网络传输？

  4. 超时、重试、错误码、鉴权、可观测性怎么做？

gRPC 就是把这些问题用一套标准方案“打包解决”。

2) gRPC 的架构（图里的几个核心模块）

从左到右可以对应成 5 层：

1. IDL/契约层（Proto）

   用 .proto 定义 service、rpc 方法、请求/响应消息结构（强类型契约）。

2. 代码生成层（Stub）

   生成 Client Stub（客户端代理）与 Server Skeleton/Handler（服务端接口骨架）。

3. 编解码层（Encoding/Decoding）

   默认使用 Protocol Buffers（Protobuf）二进制编码（图里 JSON vs Protobuf 的对比）。

4. 运行时层（gRPC Runtime）

   管控：连接、流、多路复用、超时（deadline）、metadata、压缩、拦截器（interceptors）等。

5. 传输层（Transport）

   标准 gRPC 基本跑在 HTTP/2 之上（图中间那朵 “HTTP2” 云），通常再叠加 TLS（HTTPS）。

3) 工作原理（对应图里的 1~14 步）

按图的流程把一次调用串起来（以 Order 调 Payment 为例）：

1. 客户端发起业务请求（图里还画了“REST call”到 Order Service：这表示“网关/前端可能先用 HTTP/JSON 进来”，但服务间内部用 gRPC）

2. Order Service 内部代码调用 rpc 方法（看起来像本地函数）

3. 实际调用落到 client stub（代理对象）

4. client stub 把参数交给 gR