為什么有了HTTP，還需要gRPC？
在構建現代應用，尤其是微服務架構時，我們經常討論一個問題：已經有了無處不在的HTTP，為什么還需要gRPC？答案很簡單：HTTP在某些場景下不夠高效，而gRPC正是為了解決這些痛點而生的。
HTTP的缺點
HTTP/1.1是目前最廣泛的應用層協議，但它存在一些固有的問題，尤其是在大規模分布式系統中：
- 文本協議，效率低下： HTTP/1.1是基于文本的協議，使用JSON或XML作為數據格式。這些格式可讀性好，但體積大、解析慢，在需要高性能、低延遲的場景下成為瓶頸。
- 隊頭阻塞： 每個HTTP/1.1請求都需要建立一個新的TCP連接，或者復用有限的幾個連接。在一個連接上，請求和響應是串行的，如果前一個請求耗時很長，后面的請求就會被阻塞，這就是“隊頭阻塞”。
- 單向通信： 傳統的HTTP是客戶端-服務器模式，客戶端發起請求，服務器響應。服務器無法主動向客戶端推送消息。雖然有WebSocket、長輪詢等技術作為補充，但它們并非HTTP的核心能力。
gRPC是什么？
gRPC (Google Remote Procedure Call) 是一個由Google開發的高性能、開源的通用RPC（遠程過程調用）框架。它有幾個核心特點：
- 基于HTTP/2： gRPC直接構建在HTTP/2之上，繼承了其所有優點。
- Protobuf： 這是gRPC默認的數據序列化格式。它是一種與語言無關、與平臺無關的二進制格式，比JSON/XML更小、更快、更高效。
- 面向服務： 使用
.proto文件來定義服務、消息和方法。這個文件就像一份具有強類型約束的“契約”，服務端和客戶端的代碼都可以據此自動生成，保證了一致性。
gRPC如何解決HTTP的缺點？
gRPC的設計精準地彌補了HTTP/1.1的不足：
- 二進制協議，高性能： gRPC使用Protobuf將數據序列化為二進制格式進行傳輸。相比于JSON，二進制格式體積更小，解析速度更快，大大降低了網絡帶寬消耗和CPU使用率。
- HTTP/2的多路復用： gRPC運行在HTTP/2上，它允許在單個TCP連接上同時發送和接收多個請求和響應，徹底解決了HTTP/1.1的隊頭阻塞問題。連接的復用也減少了TCP握手帶來的開銷。
- 支持流式通信： HTTP/2的原生支持使得gRPC可以輕松實現四種通信模式：
一元RPC (Unary RPC)： 客戶端發一個請求，服務端回一個響應（類似傳統HTTP）。
服務端流式RPC (Server streaming RPC)： 客戶端發一個請求，服務端返回一個數據流。
客戶端流式RPC (Client streaming RPC)： 客戶端發送一個數據流，服務端返回一個響應。
雙向流式RPC (Bidirectional streaming RPC)： 客戶端和服務端可以同時向對方發送數據流。
- 強類型的服務契約： 通過
.proto文件定義服務接口，gRPC的工具鏈可以為多種語言（Java, C++, Python, Go, Dart等）自動生成類型安全的客戶端存根和服務端骨架代碼。這使得開發者可以專注于業務邏輯，而不用處理底層的RPC細節，同時也確保了前后端的接口定義嚴格一致。
gRPC能完全替代HTTP嗎？
不能。 gRPC和HTTP（特別是RESTful API）是解決不同問題的工具，它們是互補關系，而非替代關系。
gRPC的主要優勢在于后臺服務間的通信，但在面向外部用戶（如Web瀏覽器）時存在一些天然的障礙。瀏覽器本身不支持直接調用gRPC，需要通過代理（如gRPC-Web）進行轉換，這增加了架構的復雜性。
HTTP的應用場景
HTTP/RESTful API依然是許多場景下的最佳選擇：
- 面向公眾的API： 當你需要構建開放API供第三方開發者或Web瀏覽器直接使用時，RESTful API基于JSON和HTTP，擁有最好的兼容性和通用性。
- 簡單的請求-響應通信： 對于管理后臺、簡單的CRUD操作等不需要極致性能的場景，RESTful API開發簡單、調試方便（可以直接用curl或瀏覽器測試）。
- Web瀏覽器應用： 所有面向瀏覽器的前端應用，其后端接口幾乎都會選擇HTTP API。
gRPC的應用場景
gRPC在以下場景中表現出色：
- 內部微服務通信： 這是gRPC最經典的應用場景。在數據中心內部，服務間的通信對性能、延遲和網絡帶寬要求極高，gRPC的二進制協議和HTTP/2多路復用優勢盡顯。
- 需要流式通信的場景： 例如實時數據推送、物聯網設備數據上報、實時音視頻傳輸等，gRPC原生的流式處理能力非常適合。
- 多語言環境： 當你的系統由多種不同語言編寫的服務組成時，gRPC通過
.proto文件提供了一個統一的、與語言無關的接口定義，簡化了跨語言調用的復雜性。 - 移動端應用： 移動設備網絡環境不穩定且帶寬有限，gRPC的高效性可以節省流量和電量，并提升響應速度。
如何進行技術選型？
選擇HTTP還是gRPC，可以遵循以下原則：
場景 | 推薦技術 | 理由 |
對外開放的API，面向瀏覽器或第三方開發者 | HTTP (RESTful API) | 兼容性好，通用性強，易于理解和調試。 |
公司內部，尤其是微服務之間的通信 | gRPC | 性能極致，延遲低，節省帶寬，強類型約束保證服務間調用可靠。 |
需要雙向流或單向流的實時通信 | gRPC | 原生支持流式處理，實現簡單高效。 |
移動端(App)與后端的通信 | gRPC | 更省電、省流量，在弱網環境下表現更佳。 |
架構簡單，追求快速開發和迭代 | HTTP (RESTful API) | 工具鏈成熟，生態豐富，上手快。 |
系統由多種語言棧構成，追求統一的服務定義 | gRPC |
文件提供跨語言的強類型契約。 |
總結： 沒有銀彈。將你的系統看作一個整體，對外暴露的“北-南”流量（用戶到系統）通常更適合使用HTTP/RESTful API，而系統內部服務間的“東-西”流量則應該優先考慮gRPC，以獲得最佳性能和可靠性。
