今天我们一起来聊聊淘宝1面的一个问题：HTTP 与 RPC的区别。HTTP 与 RPC是软件开发中常见的通信方式，那么，它们到底有什么区别？我们该如何选择？这篇文章，我们来揭晓答案。
1. HTTP
1.1 定义
HTTP，全称是 HyperText Transfer Protocol，是用于分布式、协作式和超媒体信息系统的应用层协议。简单来说，HTTP 就是我们平时在浏览器中访问网页时用的协议。它基于请求-响应模式，客户端发送请求，服务器返回响应。
1.2 工作原理
HTTP 是一种无状态的协议，每次请求都是独立的。客户端发送一个 HTTP 请求（包括方法、URL、头部信息和可选的主体），服务器处理后返回一个 HTTP 响应（状态码、头部信息和主体）。
举个例子，当你在浏览器中输入 https://www.yuanjava.com，浏览器会发送一个 HTTP GET 请求到服务器，服务器处理后返回网页内容。
2. RPC
2.1 定义
RPC，全称是 Remote Procedure Call（远程过程调用），是一种通过网络执行远程计算机上的过程（函数）的协议。它的目标是让开发者感觉像是在本地调用函数一样，无需关心底层的网络通信细节。常见的 RPC 框架有 gRPC、Thrift 等。
2.2 工作原理
RPC 模型则更像是函数调用。客户端调用一个远程的函数，传递参数，等待结果返回。RPC 框架会负责将这个调用转换为网络请求，传输参数，接收响应并返回结果。
例如，假设你有一个远程的 getUserInfo(userId) 函数，客户端只需要调用这个函数，RPC 框架会处理网络通信，返回用户信息。
3. 核心区别
HTTP 和 RPC 的区别在于它们的通信模型和语义。
1. 通信模型：
- HTTP：基于请求-响应，通常用于资源的获取和操作（如 RESTful 风格）。
- RPC：基于方法调用，更像是调用远程的函数或服务。
2. 语义：
- HTTP：强调资源的表现形式和状态，如 GET、POST、PUT、DELETE 等动词。
- RPC：强调功能和操作，调用的是具体的方法或服务。
4. 示例解析
为了更直观地理解，让我们通过一个简单的例子来看看延时（Latency）如何在 HTTP 和 RPC 中表现。
4.1 场景描述
假设我们有一个用户服务，需要获取用户信息。我们分别通过 HTTP 和 RPC 两种方式来实现。
4.2 HTTP 实现
// 使用 Spring Boot 的 HTTP 客户端
RestTemplate restTemplate = new RestTemplate();
String url = "http://localhost:8080/api/user/" + userId;
long startTime = System.currentTimeMillis();
ResponseEntity<User> response = restTemplate.getForEntity(url, User.class);
long endTime = System.currentTimeMillis();
System.out.println("HTTP 请求耗时: " + (endTime - startTime) + " ms");
4.3 RPC 实现
// 使用 gRPC 客户端
UserServiceGrpc.UserServiceBlockingStub stub = UserServiceGrpc.newBlockingStub(channel);
GetUserRequest request = GetUserRequest.newBuilder().setUserId(userId).build();
long startTime = System.currentTimeMillis();
User response = stub.getUser(request);
long endTime = System.currentTimeMillis();
System.out.println("RPC 请求耗时: " + (endTime - startTime) + " ms");
4.4 延时比较
假设我们的网络延时是固定的，比如 50ms。由于 RPC 的通信协议更轻量，而且通常使用二进制传输，理论上 RPC 的延时会略低于 HTTP。然而，实际情况还取决于具体的实现和优化。
互动时间：你觉得在实际项目中，延时差异会显著影响用户体验吗？欢迎在评论区分享你的看法！
5. 如何选择？
5.1 适用场景
1. HTTP：
- 公开 API：如面向第三方开发者的 RESTful API。
- 浏览器通信：前端与后端的通信，特别是网页应用。
- 简单的 CRUD 操作。
2. RPC：
- 内部服务通信：微服务架构中，服务之间的高效通信。
- 需要高性能：对延时要求高的场景，如实时数据处理。
- 复杂业务逻辑：需要调用多个远程方法，RPC 更具有灵活性。
5.2 互补使用
其实，HTTP 和 RPC 并不一定是非此即彼的选择。很多系统中会同时使用两者，针对不同的需求选择最合适的通信方式。
互动时间：你们在项目中是如何选择使用 HTTP 还是 RPC 的呢？遇到过哪些困难或有趣的情况？欢迎分享！
6. 总结
本文，我们从各个维度分析和对比了 HTTP 和 RPC，通过上面的分析，我们可以看到：
- HTTP 更适合资源导向的通信，具有广泛的兼容性和易用性。
- RPC 更适合服务导向的通信，提供了更高的性能和更自然的调用方式。