今天我們一起來聊聊淘寶1面的一個(gè)問題：HTTP 與 RPC的區(qū)別。HTTP 與 RPC是軟件開發(fā)中常見的通信方式，那么，它們到底有什么區(qū)別？我們?cè)撊绾芜x擇？這篇文章，我們來揭曉答案。

一、HTTP

1. 定義

HTTP，全稱是 HyperText Transfer Protocol，是用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議。簡(jiǎn)單來說，HTTP 就是我們平時(shí)在瀏覽器中訪問網(wǎng)頁(yè)時(shí)用的協(xié)議。它基于請(qǐng)求-響應(yīng)模式，客戶端發(fā)送請(qǐng)求，服務(wù)器返回響應(yīng)。

2. 工作原理

HTTP 是一種無狀態(tài)的協(xié)議，每次請(qǐng)求都是獨(dú)立的。客戶端發(fā)送一個(gè) HTTP 請(qǐng)求（包括方法、URL、頭部信息和可選的主體），服務(wù)器處理后返回一個(gè) HTTP 響應(yīng)（狀態(tài)碼、頭部信息和主體）。

舉個(gè)例子，當(dāng)你在瀏覽器中輸入 https://www.yuanjava.com，瀏覽器會(huì)發(fā)送一個(gè) HTTP GET 請(qǐng)求到服務(wù)器，服務(wù)器處理后返回網(wǎng)頁(yè)內(nèi)容。

二、RPC

1. 定義

RPC，全稱是 Remote Procedure Call（遠(yuǎn)程過程調(diào)用），是一種通過網(wǎng)絡(luò)執(zhí)行遠(yuǎn)程計(jì)算機(jī)上的過程（函數(shù)）的協(xié)議。它的目標(biāo)是讓開發(fā)者感覺像是在本地調(diào)用函數(shù)一樣，無需關(guān)心底層的網(wǎng)絡(luò)通信細(xì)節(jié)。常見的 RPC 框架有 gRPC、Thrift 等。

2. 工作原理

RPC 模型則更像是函數(shù)調(diào)用。客戶端調(diào)用一個(gè)遠(yuǎn)程的函數(shù)，傳遞參數(shù)，等待結(jié)果返回。RPC 框架會(huì)負(fù)責(zé)將這個(gè)調(diào)用轉(zhuǎn)換為網(wǎng)絡(luò)請(qǐng)求，傳輸參數(shù)，接收響應(yīng)并返回結(jié)果。

例如，假設(shè)你有一個(gè)遠(yuǎn)程的 getUserInfo(userId) 函數(shù)，客戶端只需要調(diào)用這個(gè)函數(shù)，RPC 框架會(huì)處理網(wǎng)絡(luò)通信，返回用戶信息。

三、核心區(qū)別

HTTP 和 RPC 的區(qū)別在于它們的通信模型和語義。

通信模型：

• HTTP：基于請(qǐng)求-響應(yīng)，通常用于資源的獲取和操作（如 RESTful 風(fēng)格）。
• RPC：基于方法調(diào)用，更像是調(diào)用遠(yuǎn)程的函數(shù)或服務(wù)。

語義：

• HTTP：強(qiáng)調(diào)資源的表現(xiàn)形式和狀態(tài)，如 GET、POST、PUT、DELETE 等動(dòng)詞。
• RPC：強(qiáng)調(diào)功能和操作，調(diào)用的是具體的方法或服務(wù)。

四、示例解析

為了更直觀地理解，讓我們通過一個(gè)簡(jiǎn)單的例子來看看延時(shí)（Latency）如何在 HTTP 和 RPC 中表現(xiàn)。

1. 場(chǎng)景描述

假設(shè)我們有一個(gè)用戶服務(wù)，需要獲取用戶信息。我們分別通過 HTTP 和 RPC 兩種方式來實(shí)現(xiàn)。

2. HTTP 實(shí)現(xiàn)

// 使用 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 請(qǐng)求耗時(shí): " + (endTime - startTime) + " ms");

3. RPC 實(shí)現(xiàn)

// 使用 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 請(qǐng)求耗時(shí): " + (endTime - startTime) + " ms");

4. 延時(shí)比較

假設(shè)我們的網(wǎng)絡(luò)延時(shí)是固定的，比如 50ms。由于 RPC 的通信協(xié)議更輕量，而且通常使用二進(jìn)制傳輸，理論上 RPC 的延時(shí)會(huì)略低于 HTTP。然而，實(shí)際情況還取決于具體的實(shí)現(xiàn)和優(yōu)化。

互動(dòng)時(shí)間：你覺得在實(shí)際項(xiàng)目中，延時(shí)差異會(huì)顯著影響用戶體驗(yàn)嗎？歡迎在評(píng)論區(qū)分享你的看法！

五、如何選擇？

1. 適用場(chǎng)景

HTTP：

• 公開 API：如面向第三方開發(fā)者的 RESTful API。
• 瀏覽器通信：前端與后端的通信，特別是網(wǎng)頁(yè)應(yīng)用。
• 簡(jiǎn)單的 CRUD 操作。

RPC：

• 內(nèi)部服務(wù)通信：微服務(wù)架構(gòu)中，服務(wù)之間的高效通信。
• 需要高性能：對(duì)延時(shí)要求高的場(chǎng)景，如實(shí)時(shí)數(shù)據(jù)處理。
• 復(fù)雜業(yè)務(wù)邏輯：需要調(diào)用多個(gè)遠(yuǎn)程方法，RPC 更具有靈活性。

2. 互補(bǔ)使用

其實(shí)，HTTP 和 RPC 并不一定是非此即彼的選擇。很多系統(tǒng)中會(huì)同時(shí)使用兩者，針對(duì)不同的需求選擇最合適的通信方式。

互動(dòng)時(shí)間：你們?cè)陧?xiàng)目中是如何選擇使用 HTTP 還是 RPC 的呢？遇到過哪些困難或有趣的情況？歡迎分享！

六、總結(jié)

本文，我們從各個(gè)維度分析和對(duì)比了 HTTP 和 RPC，通過上面的分析，我們可以看到：

• HTTP 更適合資源導(dǎo)向的通信，具有廣泛的兼容性和易用性。
• RPC 更適合服務(wù)導(dǎo)向的通信，提供了更高的性能和更自然的調(diào)用方式。

最終選擇哪種通信方式，取決于具體的應(yīng)用場(chǎng)景和需求。希望通過這篇文章，你對(duì) HTTP 和 RPC 有了更清晰的理解。