RPC 只是一種屏蔽遠程過程調用的設計，它與HTTP不是對立的，兩者不是一個層面的概念。
RPC底層通信可以使用TCP實現（如Thrift），也可以使用HTTP實現（如gRPC），其本身并無限制。
1. 概念與定位
-
RPC（Remote Procedure Call）
- 概念：一種設計模式，允許像調用本地函數一樣調用遠程服務，隱藏底層網絡細節。
- 定位：專注于跨進程的高效通信，常用于微服務內部交互。
- 代表框架：Dubbo、Thrift、gRPC。
-
HTTP
- 概念：基于請求-響應的應用層協議，用于客戶端與服務器之間的通用通信。
- 定位：面向資源操作（如RESTful API），適合開放API和跨平臺交互。
-
gRPC
- 概念：Google推出的高性能RPC框架，基于HTTP/2和Protocol Buffers。
- 定位：結合RPC的效率與HTTP/2的現代特性，適合內部服務間通信。
2. 協議與傳輸
| 特性 | RPC（傳統） | HTTP（RESTful） | gRPC |
|---|---|---|---|
| 底層協議 | 自定義協議（如TCP） | HTTP/1.1 或 HTTP/2 | HTTP/2 |
| 數據傳輸格式 | 二進制（如Thrift） | 文本（JSON/XML） | 二進制（Protobuf） |
| 連接復用 | 需要自定義 | HTTP/1.1無，HTTP/2有 | 多路復用（HTTP/2） |
| 性能 | 高（低延遲） | 較低（文本解析開銷） | 極高 |
3. 通信模式
-
RPC
通常僅支持簡單的請求-響應模式，部分框架擴展了流式能力。 -
HTTP
基于請求-響應，可通過分塊傳輸或WebSocket實現簡單流式通信，但不夠高效。 -
gRPC
原生支持四種模式（一元、服務端流、客戶端流、雙向流），得益于HTTP/2的流特性。
4. 開發體驗
-
接口定義
- RPC：依賴IDL（接口定義語言）生成代碼，強類型約束。
- HTTP：通過OpenAPI/Swagger文檔定義，靈活性高但約束弱。
- gRPC：強制使用Protobuf定義接口，生成強類型代碼，減少錯誤。
-
調試工具
- HTTP：工具豐富（如Postman、curl），易于測試。
- RPC/gRPC：需專用工具（如grpcurl、BloomRPC），調試門檻較高。
5. 適用場景
-
RPC（傳統）
- 內部服務間高性能通信（如金融交易系統）。
- 需要自定義協議優化的封閉環境。
-
HTTP（RESTful）
- 對外提供開放API（如移動端、第三方集成）。
- 需要跨語言、跨平臺兼容的場景。
-
gRPC
- 微服務架構中的內部通信（如K8s生態）。
- 需要流式傳輸或低延遲的場景（如實時監控、IoT）。
- 多語言環境下的強類型接口約束需求。
6. 關鍵對比總結
| 維度 | RPC（傳統） | HTTP | gRPC |
|---|---|---|---|
| 協議效率 | 高（二進制） | 較低（文本） | 最高（HTTP/2 + Protobuf） |
| 流式支持 | 有限 | 需擴展（如WebSocket） | 原生支持 |
| 跨平臺兼容性 | 依賴框架 | 極佳 | 需gRPC庫支持 |
| 適用場景 | 內部高性能服務 | 開放API、Web交互 | 微服務、流式通信 |
總結
- 選HTTP/REST：需要廣泛兼容性和開放性（如對外API）。
- 選傳統RPC：已有技術棧依賴或需要深度協議定制。
- 選gRPC：追求高性能、強類型接口和現代特性（如流式通信）。
