RPC与HTTP API对比

一、核心流程对比

环节	RPC	HTTP API
调用方式	调用远程函数/方法（如 userService.getUser(123)）	调用远程端点（如 GET /users/123）
参数传递	通过序列化直接传递编程语言对象	通过URL参数、Header或Body传递结构化数据
网络传输	通常基于TCP/UDP + 二进制协议（如gRPC的HTTP/2）	基于HTTP/HTTPS文本协议
数据封装	由框架自动处理序列化/反序列化	需手动处理JSON/XML转换
服务发现	内置服务注册发现机制（如Nacos）	依赖外部负载均衡器或DNS

表面流程：客户端传参 → 网络传输 → 服务端执行 → 返回结果 两者一致
❗ 核心差异：抽象层级不同（RPC抽象了网络通信，API需显式处理）

---

二、本质区别详解

1. 设计哲学差异

目标

目标

RPC

让远程调用像本地调用一样透明

HTTP API

提供标准化的资源访问接口

2. 技术实现对比

特性	RPC框架（如gRPC/Dubbo）	HTTP API（如RESTful）
协议层	自定义二进制协议（高效但封闭）	HTTP协议（通用但冗余）
序列化	Protobuf/Thrift（高性能二进制）	JSON/XML（文本，可读性好）
连接管理	长连接+连接池（低延迟）	通常短连接（高并发时开销大）
服务治理	内置负载均衡、熔断、链路追踪	需依赖API网关实现
跨语言支持	需各语言实现客户端存根	天然支持（任何语言都能发HTTP请求）

3. 代码层面感受

// RPC调用示例（客户端代码）
User user = userService.getUser(123); // 像调用本地方法

// HTTP API调用示例（客户端代码）
HttpResponse response = httpClient.execute(
  new HttpGet("http://service/user/123") // 显式网络操作
);
User user = parseJson(response.getBody()); // 手动反序列化

---

三、为什么需要RPC？（当HTTP API不足时）

以下场景优先选择RPC：

1. 微服务集群内部通信

   • 需求：高频调用+低延迟（如订单服务每秒调用支付服务10,000次）
   • RPC优势：二进制协议+长连接节省90%网络开销

2. 需要精细服务治理

   1. 服务发现

   2. 负载均衡

   2. 负载均衡

   心跳检测

   心跳检测

   客户端

   注册中心

   服务节点1

   服务节点2
   • RPC框架内置：熔断（节点故障自动隔离）、限流（防止雪崩）

3. 强类型接口约束

   • Protobuf定义接口后自动生成多语言客户端，避免手动解析错误

   // user_service.proto
   service UserService {
     rpc GetUser (GetUserRequest) returns (User) {}
   }
   message GetUserRequest {
     int32 user_id = 1;
   }
   

4. 流式数据传输

   • gRPC支持四种流模式：
     • 客户端流（上传文件）
     • 服务端流（实时日志推送）
     • 双向流（在线聊天室）

---

四、如何选择？（决策树）

是

否

是

否

是

否

是

否

通信场景

服务间调用是否高频？

是否需要精细治理？

使用HTTP API

RPC

是否需跨公网？

是否需强类型约束？

项目中的典型应用：

场景	推荐方案	案例说明
前端/移动端访问后端	HTTP API	浏览器调用 RESTful API
Java微服务集群内部调用	Dubbo RPC	订单服务调用库存服务
跨语言服务集成（C++/Go）	gRPC	Go编写的算法服务供Python调用
实时数据推送	gRPC流式RPC	股票价格实时更新

---

五、本质关联

1. 底层依赖：现代RPC框架通常基于HTTP/2传输（如gRPC），因此可视为HTTP API的超集
2. 演进关系：RESTful API是RPC的一种特殊形式（资源导向的RPC）
3. 互补使用：
   HTTP API

   RPC

   RPC

   RPC

   浏览器/App

   API网关

   用户服务

   订单服务

   数据库服务
   • 对外暴露HTTP API，内部微服务用RPC通信

关键结论：
HTTP API是语言，RPC是方言—— RPC在特定场景（高性能服务间调用）通过协议优化和框架封装，解决了通用HTTP API的性能和开发效率问题。选择时需权衡开发效率、性能需求、系统复杂度。