兄弟們，最近在技術(shù)圈里，“RPC 和 RESTful 到底誰更好” 的爭論又雙叒叕冒出來了。就像武俠小說里的華山論劍，RPC 派和 RESTful 派各執(zhí)一詞，打得不可開交。今天咱們就來好好嘮嘮這事兒，爭取讓大家看完之后能拍著大腿說：“哦～原來如此！”

一、先搞清楚這倆貨到底是干啥的

1. RPC：遠程過程調(diào)用，像打電話一樣調(diào)函數(shù)

想象一下，你在公司寫代碼，需要調(diào)用另一個服務(wù)器上的函數(shù)，就像調(diào)用本地函數(shù)一樣方便。這就是 RPC 干的事兒。比如你想查用戶余額，本地調(diào)一下函數(shù)，背后就自動通過網(wǎng)絡(luò)去另一臺服務(wù)器把數(shù)據(jù)取回來了。

RPC 就像打電話：你撥個號碼（函數(shù)名），對方接電話（執(zhí)行函數(shù)），然后給你反饋（返回結(jié)果）。它的核心就是把遠程調(diào)用偽裝成本地調(diào)用，讓程序員不用操心網(wǎng)絡(luò)細節(jié)。

常見的 RPC 框架有 Dubbo、gRPC、Thrift 等。比如阿里巴巴的 Dubbo，在電商場景里用得飛起，性能杠杠的。

2. RESTful：表現(xiàn)層狀態(tài)轉(zhuǎn)移，用 HTTP 協(xié)議玩資源

RESTful 是一種架構(gòu)風(fēng)格，基于 HTTP 協(xié)議，通過 URL 定位資源，用 GET、POST、PUT、DELETE 等方法操作資源。比如獲取用戶信息用 GET /users/1，創(chuàng)建用戶用 POST /users。

RESTful 就像發(fā)郵件：你寫好地址（URL），選好郵件類型（HTTP 方法），把內(nèi)容（數(shù)據(jù)）塞進去，對方收到后處理。它的核心是以資源為中心，強調(diào)統(tǒng)一接口。

GitHub 的 API 就是典型的 RESTful 設(shè)計，全世界的開發(fā)者都能輕松調(diào)用，因為規(guī)則簡單明了。

二、RPC 和 RESTful 的核心區(qū)別：就像包子和餃子

1. 設(shè)計理念：動詞 VS 名詞

RPC 是動詞導(dǎo)向，關(guān)注 “做什么”。比如調(diào)一個 “getUserInfo” 函數(shù)，直接告訴服務(wù)器要執(zhí)行這個動作。

RESTful 是名詞導(dǎo)向，關(guān)注 “操作什么資源”。比如用 GET 請求 /users/1，告訴服務(wù)器要獲取這個用戶資源。

舉個栗子：修改用戶密碼。

• RPC 可能是：POST /userService/changePassword，參數(shù)是用戶 ID 和新密碼。
• RESTful 可能是：PUT /users/1/password，請求體里放新密碼。

2. 協(xié)議和數(shù)據(jù)格式：二進制 VS 文本

RPC 常用二進制協(xié)議（如 Protobuf），數(shù)據(jù)傳輸效率高，但可讀性差。就像加密電報，只有專業(yè)設(shè)備能解讀。

RESTful 常用JSON 或 XML，可讀性強，但數(shù)據(jù)量大。就像普通書信，誰都能看懂，但郵費可能貴點。

比如 gRPC 用 Protobuf 序列化，數(shù)據(jù)體積小，傳輸快；而 RESTful 的 JSON 雖然方便調(diào)試，但傳輸相同數(shù)據(jù)可能比 RPC 多占 30% 帶寬。

3. 狀態(tài)管理：有狀態(tài) VS 無狀態(tài)

RPC 可以是有狀態(tài)的，服務(wù)器可以記住客戶端的狀態(tài)。比如你登錄后，服務(wù)器保存你的會話信息，后續(xù)請求不用每次都傳 token。

RESTful 是無狀態(tài)的，每次請求都要包含所有必要信息。比如你每次訪問都要帶 token，服務(wù)器不保存你的狀態(tài)，這樣更靈活，也更容易擴展。

就像住酒店：

• RPC 像常住客，前臺記住你，你一去就給你房卡。
• RESTful 像過客，每次都要重新登記，雖然麻煩，但酒店可以接待更多人。

三、性能大比拼：RPC 像跑車，RESTful 像家用車

1. 傳輸效率：RPC 快人一步

因為 RPC 用二進制協(xié)議，數(shù)據(jù)體積小，傳輸快。比如傳輸 1MB 數(shù)據(jù)，RPC 可能只需要 0.5 秒，而 RESTful 可能需要 0.8 秒。

有測試數(shù)據(jù)顯示，在處理時間較短的場景（如 0ms 業(yè)務(wù)處理），RPC 的吞吐率是 RESTful 的 1.6 倍左右。比如 Dubbo 在電商高并發(fā)場景下，每秒能處理幾十萬次請求。

2. 網(wǎng)絡(luò)開銷：RESTful 有點吃虧

RESTful 的 HTTP 協(xié)議頭比較重，每次請求都要帶一堆信息，比如 Cookie、User-Agent 等。而 RPC 的協(xié)議頭簡單，甚至可以自定義，減少不必要的開銷。

比如一個 GET 請求，RESTful 的 HTTP 頭可能有幾百字節(jié)，而 RPC 的二進制頭可能只有幾十字節(jié)。

3. 長連接和流處理：RPC 更勝一籌

RPC 支持長連接和流處理，比如 gRPC 的雙向流，可以在一個連接里持續(xù)收發(fā)數(shù)據(jù)。就像打電話時可以同時說話和聽，效率高。

RESTful 基于 HTTP/1.1，默認是短連接，每次請求都要建立連接，延遲較高。雖然 HTTP/2 支持長連接和多路復(fù)用，但在流處理上還是不如 RPC 靈活。

比如實時聊天應(yīng)用，用 gRPC 的流處理可以實現(xiàn)毫秒級消息推送，而 RESTful 可能需要輪詢，浪費資源。

四、適用場景：選對工具才能事半功倍

1. 內(nèi)部系統(tǒng)：RPC 是首選

公司內(nèi)部的微服務(wù)調(diào)用，比如訂單服務(wù)調(diào)庫存服務(wù)，需要高性能、低延遲。RPC 的二進制協(xié)議和長連接能滿足需求，而且內(nèi)部系統(tǒng)對可讀性要求不高。

比如淘寶的訂單系統(tǒng)，用 Dubbo 實現(xiàn)服務(wù)間調(diào)用，每秒處理百萬級請求不在話下。

2. 對外接口：RESTful 更合適

開放給第三方的 API，比如支付寶的支付接口，需要跨語言、跨平臺調(diào)用。RESTful 的 JSON 格式和 HTTP 協(xié)議兼容性強，文檔清晰，容易上手。

GitHub 的 API 就是典型，不管你用 Java、Python 還是 Node.js，都能輕松調(diào)用。

3. 復(fù)雜業(yè)務(wù)：看情況組合

有些場景可以兩者結(jié)合。比如核心業(yè)務(wù)用 RPC 保證性能，邊緣業(yè)務(wù)用 RESTful 提供靈活接口。

比如一個電商平臺，商品詳情頁用 RESTful 提供給前端，而庫存扣減用 RPC 在內(nèi)部系統(tǒng)快速處理。

五、開發(fā)成本和維護：RESTful 像自動擋，RPC 像手動擋

1. 開發(fā)難度：RESTful 簡單，RPC 門檻高

RESTful 基于 HTTP 協(xié)議，工具鏈成熟。用 Postman 測接口，Swagger 生成文檔，分分鐘搞定。

RPC 需要定義接口、生成代碼，還要處理序列化、反序列化。比如用 gRPC，你得先寫.proto 文件，生成客戶端和服務(wù)端代碼，對新手不太友好。

2. 維護成本：RESTful 易擴展，RPC 改起來麻煩

RESTful 的接口版本控制簡單，比如在 URL 里加 /v1、/v2，新舊版本可以共存。就像給房子加個新門，不影響舊門使用。

RPC 的接口一旦發(fā)布，修改起來可能需要全量更新客戶端和服務(wù)端。比如改一個參數(shù)類型，所有調(diào)用方都得重新生成代碼，成本較高。

3. 學(xué)習(xí)曲線：RESTful 適合新手，RPC 需要經(jīng)驗

對于剛?cè)胄械某绦騿T，RESTful 的概念更容易理解，因為 HTTP 協(xié)議大家都熟。

RPC 涉及更多底層細節(jié)，比如序列化協(xié)議、網(wǎng)絡(luò)優(yōu)化，需要一定的經(jīng)驗才能用好。

六、安全性對比：RESTful 像防盜門，RPC 像保險柜

1. 傳輸安全：RESTful 天然支持 HTTPS

RESTful 基于 HTTP 協(xié)議，開啟 HTTPS 就能加密傳輸，防止中間人攻擊。就像給快遞包裹加了層鉛封，別人打不開。

RPC 需要自己實現(xiàn)加密，比如 gRPC 支持 TLS，但配置起來比 RESTful 麻煩。

2. 認證授權(quán)：RESTful 有成熟方案

RESTful 常用 OAuth 2.0、JWT 等進行認證授權(quán)，社區(qū)資源豐富，解決方案多。

RPC 的認證授權(quán)需要自己實現(xiàn)，比如在請求頭里加 token，或者用框架提供的插件。

3. 防攻擊：RESTful 更抗揍

RESTful 的無狀態(tài)設(shè)計，服務(wù)器不保存會話，減少了會話劫持的風(fēng)險。而 RPC 的有狀態(tài)設(shè)計，如果會話管理不好，容易被攻擊。

比如 RESTful 的每次請求都帶 token，即使 token 被截獲，也只能用一次（如果設(shè)置了短有效期）。

七、總結(jié)：沒有最好，只有最合適

RPC 和 RESTful 就像菜刀和剪刀，用途不同，不能簡單說誰更好。選哪個，關(guān)鍵看你的場景：

• 追求性能和內(nèi)部調(diào)用：選 RPC，比如 Dubbo、gRPC。
• 需要跨平臺和靈活接口：選 RESTful，比如 Spring Boot + Spring MVC。
• 復(fù)雜業(yè)務(wù)：兩者結(jié)合，取長補短。