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：追求高性能、强类型接口和现代特性（如流式通信）。
