RPC 只是一种屏蔽远程过程调用的设计，它与HTTP不是对立的，两者不是一个层面的概念。

RPC底层通信可以使用TCP实现（如Thrift），也可以使用HTTP实现（如gRPC），其本身并无限制。

---

1. 概念与定位

• RPC（Remote Procedure Call）

  • 概念：一种设计模式，允许像调用本地函数一样调用远程服务，隐藏底层网络细节。
  • 定位：专注于跨进程的高效通信，常用于微服务内部交互。
  • 代表框架：Dubbo、Thrift、gRPC。

• HTTP

  • 概念：基于请求-响应的应用层协议，用于客户端与服务器之间的通用通信。
  • 定位：面向资源操作（如RESTful API），适合开放API和跨平台交互。

• gRPC

  • 概念：Google推出的高性能RPC框架，基于HTTP/2和Protocol Buffers。
  • 定位：结合RPC的效率与HTTP/2的现代特性，适合内部服务间通信。

---

2. 协议与传输

特性	RPC（传统）	HTTP（RESTful）	gRPC
底层协议	自定义协议（如TCP）	HTTP/1.1 或 HTTP/2	HTTP/2
数据传输格式	二进制（如Thrift）	文本（JSON/XML）	二进制（Protobuf）
连接复用	需要自定义	HTTP/1.1无，HTTP/2有	多路复用（HTTP/2）
性能	高（低延迟）	较低（文本解析开销）	极高

---

3. 通信模式

• RPC
  通常仅支持简单的请求-响应模式，部分框架扩展了流式能力。

• HTTP
  基于请求-响应，可通过分块传输或WebSocket实现简单流式通信，但不够高效。

• gRPC
  原生支持四种模式（一元、服务端流、客户端流、双向流），得益于HTTP/2的流特性。

---

4. 开发体验

• 接口定义

  • RPC：依赖IDL（接口定义语言）生成代码，强类型约束。
  • HTTP：通过OpenAPI/Swagger文档定义，灵活性高但约束弱。
  • gRPC：强制使用Protobuf定义接口，生成强类型代码，减少错误。

• 调试工具

  • HTTP：工具丰富（如Postman、curl），易于测试。
  • RPC/gRPC：需专用工具（如grpcurl、BloomRPC），调试门槛较高。

---

5. 适用场景

• RPC（传统）

  • 内部服务间高性能通信（如金融交易系统）。
  • 需要自定义协议优化的封闭环境。

• HTTP（RESTful）

  • 对外提供开放API（如移动端、第三方集成）。
  • 需要跨语言、跨平台兼容的场景。

• gRPC

  • 微服务架构中的内部通信（如K8s生态）。
  • 需要流式传输或低延迟的场景（如实时监控、IoT）。
  • 多语言环境下的强类型接口约束需求。

---

6. 关键对比总结

维度	RPC（传统）	HTTP	gRPC
协议效率	高（二进制）	较低（文本）	最高（HTTP/2 + Protobuf）
流式支持	有限	需扩展（如WebSocket）	原生支持
跨平台兼容性	依赖框架	极佳	需gRPC库支持
适用场景	内部高性能服务	开放API、Web交互	微服务、流式通信

---

总结

• 选HTTP/REST：需要广泛兼容性和开放性（如对外API）。
• 选传统RPC：已有技术栈依赖或需要深度协议定制。
• 选gRPC：追求高性能、强类型接口和现代特性（如流式通信）。