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

一、HTTP

1. 定義

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

2. 工作原理

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

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

二、RPC

1. 定義

RPC，全稱是 Remote Procedure Call（遠(yuǎn)程過程調(diào)用），是一種通過網(wǎng)絡(luò)執(zhí)行遠(yuǎn)程計算機(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)用一個遠(yuǎn)程的函數(shù)，傳遞參數(shù)，等待結(jié)果返回。RPC 框架會負(fù)責(zé)將這個調(diào)用轉(zhuǎn)換為網(wǎng)絡(luò)請求，傳輸參數(shù)，接收響應(yīng)并返回結(jié)果。

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

三、核心區(qū)別

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

通信模型：

• HTTP：基于請求-響應(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 等動詞。
• RPC：強(qiáng)調(diào)功能和操作，調(diào)用的是具體的方法或服務(wù)。

四、示例解析

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

1. 場景描述

假設(shè)我們有一個用戶服務(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 請求耗時: " + (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 請求耗時: " + (endTime - startTime) + " ms");

4. 延時比較

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

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

五、如何選擇？

1. 適用場景

HTTP：

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

RPC：

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

2. 互補(bǔ)使用

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

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

六、總結(jié)

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

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

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