[[438589]]

01介紹

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

本文我們介紹 Golang 語言微服務架構的軟件系統(tǒng)為什么選擇使用 gRPC 作為分布式應用之間的通信協(xié)議。

02進程間通信

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

在我們微服務項目開發(fā)中，進程間通信的傳統(tǒng)方式是使用 RESTful 服務的方式實現(xiàn)同步的請求和響應。實際上，通過 HTTP 和 JSON 將應用程序構建為 RESTful 服務已經(jīng)是構建微服務的標準方法。

但是隨著微服務數(shù)量增多，RESTful 服務的方式實現(xiàn)進程間通信越來越低效，因為 RESTful 服務使用文本傳輸，微服務之間缺乏強類型接口，并且 REST 架構不能強制應用程序使用等問題，所以 RESTful 服務的方式已經(jīng)不能滿足需求。

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

03gRPC 的優(yōu)點和缺點

優(yōu)點：

gRPC 進程間通信與 RESTful 服務不同的是，它沒有使用文本傳輸，而是使用基于 protocol buffers 的二進制協(xié)議，二進制傳輸?shù)男蔬h遠高于文本傳輸?shù)男?，并?gRPC 是基于 HTTP/2 實現(xiàn)的 protocol buffers 協(xié)議，從而使進程間通信更加高效。

gRPC 與 RESTful 服務不同的是，gRPC 先要定義服務接口，然后再去實現(xiàn)細節(jié)。因此，gRPC 可以約束多語言開發(fā)的分布式應用程序，使分布式應用程序更加可靠，可擴展。

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

缺點：

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

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

04總結

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

我們通過簡述 RESTful 服務方式的局限性，和 gRPC 的優(yōu)勢，介紹了微服務架構選擇 gRPC 通信協(xié)議的原因。