聊聊 gRPC：為什麼它是微服務的高性能首選？

大家好！

今天想跟各位聊聊 gRPC。如果你最近在接觸微服務或雲原生架構，應該常聽到這個名詞。它是 Google 在 2015 年開源的 RPC（Remote Procedure Call）框架。 簡單來說，gRPC 的出現是為了解決傳統 REST API 在效能上的瓶頸。它的終極目標是：讓你呼叫遠端的服務，感覺就像在呼叫本地的函式一樣順手，而且速度更快。

為什麼它能這麼快？

gRPC 之所以效能碾壓傳統 API，主要歸功於兩個底層技術： HTTP/2：這是它的傳輸高速公路。相比 HTTP/1.1，它支援多路復用（Multiplexing），不用每次請求都重新握手，還能壓縮 Header，傳輸效率極高。

Protocol Buffers (Protobuf)：這是它的語言。它把資料序列化成二進位（Binary），體積比 JSON 小非常多，解析速度也快上好幾倍。

核心原理：一切從「合約」開始 開發 gRPC 服務時，我們不會先寫 code，而是先寫 .proto 檔案。這就是前後端的強型別合約。 舉個簡單的例子（Hello World）：

syntax = "proto3";

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

寫好這個定義檔後，我們用 protoc 編譯器幫我們自動生成各種語言（Go, Java, Python 等）的程式碼。這省去了手寫 HTTP Client/Server 的繁瑣工作，而且保證雙方傳輸的資料結構絕對一致。

踩坑小提醒：

在使用 protoc 生成代碼時，請務必注意編譯器的版本一致性。如果開發團隊成員或 CI/CD 環境的 protoc 版本差異過大，生成的程式碼可能會帶有不同的版本檢測邏輯，導致運行時報錯。 萬一真的遇到了，有時得手動去生成檔裡把那個版本檢測（version check）的區塊刪掉才能跑（雖然是旁門左道，但救急時很有用）。這部分的實作細節與避坑指南，我們會在之後的實作篇詳細解說。

通訊流程：

當你在客戶端呼叫 client.SayHello(request) 時，背後發生了什麼事？ Stub（存根）接手：客戶端的 Stub 把你的參數用 Protobuf 打包成二進位。 傳輸：透過 HTTP/2 的連線傳給伺服器。 解包與執行：伺服器收到後解包，執行你真正的業務邏輯。 回傳：結果再次打包回傳，客戶端收到後解包。 對寫程式的你來說，這些序列化、網路傳輸都是透明的，你只需要關心業務邏輯。 比 REST 更靈活的四種模式 除了傳統的一問一答（Unary），gRPC 最強大的是它原生支援串流（Streaming）： Server Streaming：你送一個請求，Server 一直推資料給你（適合股票報價、Log 推播）。 Client Streaming：你一直推資料給 Server，最後它回你一個結果（適合物聯網傳感器數據上傳）。 Bidirectional Streaming：雙向即時通訊，就像講電話一樣（適合聊天室、即時遊戲）。 這在以前用 REST 做起來很痛苦，通常還得外掛 WebSocket，但在 gRPC 裡只是定義不同而已。

總結：該選 gRPC 還是 REST？

這沒有絕對的對錯，通常我會這樣建議：

選 gRPC：如果是在內部微服務之間溝通。因為它快、省頻寬、有型別檢查，能抓出很多開發時的錯誤。

選 REST：如果是對外公開 API（給前端瀏覽器、第三方廠商）。因為 JSON 可讀性高，且 HTTP/1.1 的通用性目前還是最強的。

gRPC 確實能讓架構更嚴謹、效能更好。如果你還沒試過，強烈建議在下一個專案的內部通訊試試看。 這篇主要是原理介紹，下一篇我們會直接進入實戰環節，手把手帶大家跑一次 gRPC 的實作，也會示範剛剛提到的版本檢測問題該如何處理。敬請期待！