一、核心概念
RPC（Remote Procedure Call，远程过程调用）和 REST（Representational State Transfer，表述性状态转移）都是常见的服务通信方式。
核心区别：
- RPC：面向方法调用，像调用本地函数一样调用远程服务。
- REST：面向资源操作，通过 HTTP Method 和 URI 操作远程资源。
需要注意：HTTP 是通信协议，而 RPC 和 REST 是不同的设计模型。gRPC 本身也可以基于 HTTP/2 进行通信。
例如，查询 ID 为 1001 的用户：
RPC：
User user = userService.getUser(1001);REST：
GET /users/1001二、RPC 与 REST 对比
| 对比维度 | RPC 框架 | HTTP REST |
|---|---|---|
| 核心思想 | 面向方法调用 | 面向资源操作 |
| 调用方式 | getUser(id) |
GET /users/DIL1 |
| 通信协议 | TCP、HTTP/2、HTTP/3 等 | HTTP |
| 数据格式 | Protobuf、JSON 等 | 通常 JSON，也支持 XML 等 |
| 性能 | 二进制编码实现通常更高效 | JSON REST 通常开销稍高 |
| 接口定义 | 常用 IDL，支持代码生成 | 常用 OpenAPI，也支持代码生成 |
| 类型约束 | 通常较强 | 取决于 API 规范和实现 |
| 服务治理 | 框架通常提供或集成相关能力 | 常依赖网关及服务基础设施 |
| 调试方式 | 可能需要专用工具 | curl、Postman 等 |
| 适用场景 | 微服务内部、高频调用 | 开放 API、前后端通信 |
注意：性能优势不是 RPC 天然具有的，而是由具体协议、编码方式、连接管理和实现决定。
三、代码实现对比
3.1 REST 示例（Spring Boot）
服务端：
@RestController
@RequestMapping("/users")
public class UserController {
@GetMapping("/{id}")
public User getUser(@PathVariable Long id) {
return userService.getUser(id);
}
}客户端请求：
GET /users/1001 HTTP/1.1
Host: user-service响应：
{
"id": 1001,
"name": "张三",
"age": 25
}3.2 RPC 示例（gRPC）
使用 Protobuf 定义接口：
syntax = "proto3";
service UserService {
rpc GetUser(GetUserRequest)
returns (UserResponse);
}
message GetUserRequest {
int64 id = 1;
}
message UserResponse {
int64 id = 1;
string name = 2;
int32 age = 3;
}Java 客户端调用：
UserResponse user = stub.getUser(
GetUserRequest.newBuilder()
.setId(1001)
.build()
);RPC 通过生成的 Stub 代理进行调用，隐藏部分网络通信细节，但底层依然存在序列化、网络传输及反序列化开销。
四、底层通信流程
4.1 RPC 调用流程（以 gRPC 为例）
4.2 REST 调用流程（典型 JSON API）
两者都涉及网络传输和序列化，区别主要在于接口抽象、编码方式、客户端调用模型和相关基础设施。
五、RPC 为什么适合微服务内部通信？
RPC 框架通常具有以下优势：
- 调用方便：通过 Stub 或代理对象调用远程方法。
- 序列化高效：如 gRPC 使用 Protobuf，通常比 JSON 更紧凑。
- 接口契约清晰：通过 IDL 定义接口，自动生成跨语言代码。
- 支持流式通信：gRPC 支持客户端流、服务端流和双向流。
- 服务治理能力：部分框架提供服务发现、负载均衡、超时和重试等能力。
但 RPC 不一定在所有场景都比 REST 快。如果服务主要耗时在数据库或外部 I/O，通信协议带来的优化可能相对有限。
六、如何选择 RPC 和 REST？
| 业务场景 | 推荐方案 | 原因 |
|---|---|---|
| 浏览器调用后端 | REST | 兼容性好，调试方便 |
| 第三方开放 API | REST | 通用、易集成 |
| Java 微服务内部调用 | Dubbo / gRPC / REST | 根据技术栈选择 |
| 多语言微服务 | gRPC | 跨语言代码生成 |
| 高频、低延迟调用 | gRPC 等高效 RPC 框架 | 编码紧凑、支持连接复用 |
| 流式数据传输 | gRPC Streaming | 原生支持流式通信 |
| 简单 CRUD 系统 | REST | 开发和维护成本较低 |
典型微服务架构
这种架构采用：
- 外部使用 HTTP REST，方便前端和第三方调用。
- 内部使用 RPC，实现服务之间的高效通信。
七、面试回答参考
问题：RPC 框架与 HTTP REST 有什么区别？
RPC 是面向动作或方法调用的通信模型，而 REST 是面向资源的架构风格。
RPC 框架通常提供接口代理、代码生成、序列化以及服务治理能力，例如 Dubbo 和 gRPC。REST 通常使用 HTTP Method 和 URI 表达资源操作。
在性能方面，采用 Protobuf 和 HTTP/2 的 gRPC 通常比传统 JSON REST 更适合高频、低延迟的内部通信，但具体性能还取决于实现方式和业务负载。
实际项目中经常结合使用两者，对外通过 REST 提供开放 API，对内通过 RPC 实现有高性能或强接口契约需求的服务调用。
八、总结
一句话总结：RPC 更像调用远程函数，REST 更像操作远程资源。
| 关键问题 | 结论 |
|---|---|
| RPC 一定比 REST 快吗？ | 不一定，取决于具体实现 |
| RPC 可以使用 HTTP 吗？ | 可以，例如 gRPC 基于 HTTP/2 |
| REST 只能使用 JSON 吗？ | 不是，也支持 XML 等数据格式 |
| RPC 和 REST 能共存吗？ | 可以，微服务架构中很常见 |
| 怎么选择？ | 外部开放接口通常选择 REST，内部高频通信可以考虑 RPC |