[[438589]]

01介紹

我們?cè)谥暗奈恼轮校B續(xù)使用四篇文章的篇幅介紹過 gRPC 的相關(guān)知識(shí)，如果有讀者朋友還未閱讀，可以按需翻閱一下前面的四篇關(guān)于 gRPC 的文章。

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

02進(jìn)程間通信

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

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

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

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

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

優(yōu)點(diǎn)：

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

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

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

缺點(diǎn)：

gRPC 也不是十全十美，在項(xiàng)目開發(fā)中，有時(shí)需要給三方提供接口服務(wù)，尤其是外部公司的三方，因?yàn)?gRPC 具有接口契約和強(qiáng)類型等特點(diǎn)，會(huì)限制面向外部服務(wù)的靈活性，所以 gRPC 可能不適合面向外部的服務(wù)。

在面向?yàn)g覽器和 APP 應(yīng)用等客戶端接口開發(fā)時(shí)，因?yàn)樗鼈儗?duì) gRPC 的支持還處于初級(jí)階段，大部分公司還是選擇使用 REST 接口進(jìn)行通信，所以我們?cè)谶x擇進(jìn)程間通信協(xié)議時(shí)，還是要根據(jù)實(shí)際使用場景做出最佳選擇。

04總結(jié)

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

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