快捷導(dǎo)航

使用gRPC微服務(wù)的內(nèi)部通信優(yōu)化

更新時(shí)間：2022年03月08日 16:20:36 作者：字母哥哥

這篇文章主要為大家介紹了微服務(wù)優(yōu)化之使用gRPC做微服務(wù)的內(nèi)部通信，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步

使用gRPC做微服務(wù)的內(nèi)部通信

gRPC是一個(gè)由Google開(kāi)源的遠(yuǎn)程服務(wù)調(diào)用框架，具有多路復(fù)用和雙向流式通信的特性。

大家好，在本文中將為大家介紹為什么我們應(yīng)該使用gRPC代替RESTful或JSON，來(lái)開(kāi)發(fā)微服務(wù)內(nèi)部的通信接口。

什么是gRPC?

gRPC是一個(gè)高性能的、開(kāi)源的、普遍通用的RPC框架。簡(jiǎn)單地說(shuō)，它能夠幫助我們建立透明的服務(wù)端和客戶(hù)端通信系統(tǒng)。Google開(kāi)發(fā)了GRPC并且將其開(kāi)源。通過(guò)它，一個(gè)客戶(hù)端消費(fèi)者服務(wù)可以像調(diào)用本地方法一樣，調(diào)用另一臺(tái)主機(jī)上面的服務(wù)端方法。

gRPC本質(zhì)上仍然遵循常規(guī)的Remote Procedure Call (RPC) 技術(shù)，但是在實(shí)現(xiàn)上使用了HTTP2.0、協(xié)議緩沖區(qū)等更現(xiàn)代化的技術(shù)方案，從而最大程度上確保服務(wù)端和客戶(hù)端的互操作性及性能上的提升。

服務(wù)之間如何使用gRPC通信？

當(dāng)客戶(hù)端向服務(wù)端發(fā)起請(qǐng)求的時(shí)候，客戶(hù)端gRPC類(lèi)庫(kù)使用協(xié)議緩沖區(qū)并且封裝遠(yuǎn)程過(guò)程調(diào)用(RPC),并且將其通過(guò)HTTP2發(fā)送到服務(wù)端。服務(wù)端將其拆封，并且使用協(xié)議緩沖區(qū)調(diào)用對(duì)應(yīng)的程序。響應(yīng)數(shù)據(jù)的過(guò)程和發(fā)送請(qǐng)求的過(guò)程是類(lèi)似的，只不過(guò)一個(gè)是從客戶(hù)端到服務(wù)端，一個(gè)是從服務(wù)端到客戶(hù)端。

從開(kāi)發(fā)的角度，在服務(wù)端和客戶(hù)端使用gRPC最大的好處在于：你的服務(wù)端的代碼和客戶(hù)端的代碼不需要擔(dān)心它會(huì)影響你解析JSON或者其他類(lèi)似的文本格式消息。gRPC雖然接收到的是二進(jìn)制格式，但會(huì)并將其反序列化為對(duì)象。同樣的我們可以通過(guò)IDL來(lái)定義服務(wù)接口，IDL是非常強(qiáng)大的一個(gè)特性，幫助我們處理多個(gè)微服務(wù)之間的互操作。

為什么gRPC是高效的？

它基于HTTP2構(gòu)建，既支持傳統(tǒng)的請(qǐng)求-響應(yīng)模型，也支持雙向流模型。
可以將JSON數(shù)據(jù)轉(zhuǎn)換到協(xié)議緩沖區(qū)
多路復(fù)用
雙向流模型
網(wǎng)絡(luò)傳輸?shù)氖嵌M(jìn)制數(shù)據(jù)，相對(duì)于JSON等文本數(shù)據(jù)更加輕量級(jí)。
多語(yǔ)言支持

什么時(shí)候使用gRPC？

最初，幾乎所有的微服務(wù)之間都是通過(guò)JSON數(shù)據(jù)接口通信的，一個(gè)服務(wù)可能調(diào)用空一個(gè)服務(wù)或者多個(gè)服務(wù)，被調(diào)用的服務(wù)可能還調(diào)用其他服務(wù)。如果其中任何一個(gè)服務(wù)運(yùn)行緩慢，將影響整個(gè)系統(tǒng)的運(yùn)行速度，因?yàn)镽ESTful(JSON) API不支持HTTP2的多路復(fù)用和雙向流模型。傳統(tǒng)的RESTful接口使用JSON、XML或者其他的一些格式作為數(shù)據(jù)載體，使得服務(wù)運(yùn)行緩慢，內(nèi)存占用較高、并且傳輸過(guò)程沒(méi)有壓縮。