Golang 微服務爲什麼選擇使用 gRPC 作爲通信協議？

大家好，我是 frank。
歡迎大家點擊標題下方藍色文字「Golang 語言開發棧」關注公衆號。
設爲星標，第一時間接收推送文章。
文末掃碼，加羣一起學 Golang 語言。

01 介紹

我們在之前的文章中，連續使用四篇文章的篇幅介紹過 gRPC 的相關知識，如果有讀者朋友還未閱讀，可以按需翻閱一下前面的四篇關於 gRPC 的文章。

本文我們介紹 Golang 語言微服務架構的軟件系統爲什麼選擇使用 gRPC 作爲分佈式應用之間的通信協議。

微服務架構的軟件系統由多個分佈式應用組成，進程間通信技術將分佈式應用相互連接。進程間通信一般包含兩種實現方式，其中一種是同步的請求和響應，另外一種是異步的消息傳遞。

在我們微服務項目開發中，進程間通信的傳統方式是使用 RESTful 服務的方式實現同步的請求和響應。實際上，通過 HTTP 和 JSON 將應用程序構建爲 RESTful 服務已經是構建微服務的標準方法。

但是隨着微服務數量增多，RESTful 服務的方式實現進程間通信越來越低效，因爲 RESTful 服務使用文本傳輸，微服務之間缺乏強類型接口，並且 REST 架構不能強制應用程序使用等問題，所以 RESTful 服務的方式已經不能滿足需求。

基於以上原因，gRPC 進程間通信應運而生，gRPC 擴展性強、松耦合，比 RESTful 服務更高效，所以越來越多的公司將進程間通信協議替換爲 gRPC。

優點：

gRPC 進程間通信與 RESTful 服務不同的是，它沒有使用文本傳輸，而是使用基於 protocol buffers 的二進制協議，二進制傳輸的效率遠遠高於文本傳輸的效率，並且 gRPC 是基於 HTTP/2 實現的 protocol buffers 協議，從而使進程間通信更加高效。

gRPC 與 RESTful 服務不同的是，gRPC 先要定義服務接口，然後再去實現細節。因此，gRPC 可以約束多語言開發的分佈式應用程序，使分佈式應用程序更加可靠，可擴展。

gRPC 使用 protocol buffers 定義服務接口，可以支持多種語言，並且強制約束了不同語言的分佈式應用程序之間進程間通信使用的類型，可以使分佈式應用程序更加穩定。

缺點：

gRPC 也不是十全十美，在項目開發中，有時需要給三方提供接口服務，尤其是外部公司的三方，因爲 gRPC 具有接口契約和強類型等特點，會限制面向外部服務的靈活性，所以 gRPC 可能不適合面向外部的服務。

在面向瀏覽器和 APP 應用等客戶端接口開發時，因爲它們對 gRPC 的支持還處於初級階段，大部分公司還是選擇使用 REST 接口進行通信，所以我們在選擇進程間通信協議時，還是要根據實際使用場景做出最佳選擇。

本文我們介紹目前進程間通信使用比較多的 RESTful 服務方式和 gRPC 方式，隨着微服務架構的服務中，分佈式服務數量越來越多的背景下，RESTful 服務的方式已經不能滿足需求。

我們通過簡述 RESTful 服務方式的侷限性，和 gRPC 的優勢，介紹了微服務架構選擇 gRPC 通信協議的原因。

參考資料：
https://grpc.io/docs/what-is-grpc/faq/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/KnlWJDyOmedno1XuNw0_rQ