微服務優化之使用gRPC作微服務的內部通訊

使用gRPC作微服務的內部通訊

gRPC是一個由Google開源的遠程服務調用框架,具備多路複用和雙向流式通訊的特性。

你們好,在本文中將爲你們介紹爲何咱們應該使用gRPC代替RESTful或JSON,來開發微服務內部的通訊接口。網絡

什麼是gRPC?

gRPC是一個高性能的、開源的、廣泛通用的RPC框架。簡單地說,它可以幫助咱們創建透明的服務端和客戶端通訊系統。Google開發了GRPC而且將其開源。 經過它,一個客戶端消費者服務能夠像調用本地方法同樣,調用另外一臺主機上面的服務端方法。 gRPC本質上仍然遵循常規的Remote Procedure Call (RPC) 技術,可是在實現上使用了HTTP2.0、協議緩衝區等更現代化的技術方案,從而最大程度上確保服務端和客戶端的互操做性及性能上的提高。框架

服務之間如何使用gRPC通訊?

當客戶端向服務端發起請求的時候,客戶端gRPC類庫使用協議緩衝區而且封裝遠程過程調用(RPC),而且將其經過HTTP2發送到服務端。服務端將其拆封,而且使用協議緩衝區調用對應的程序。響應數據的過程和發送請求的過程是相似的,只不過一個是從客戶端到服務端,一個是從服務端到客戶端。
從開發的角度,在服務端和客戶端使用gRPC最大的好處在於:你的服務端的代碼和客戶端的代碼不須要擔憂它會影響你解析JSON或者其餘相似的文本格式消息。gRPC雖然接收到的是二進制格式,但會並將其反序列化爲對象。一樣的咱們能夠經過IDL來定義服務接口,IDL是很是強大的一個特性,幫助咱們處理多個微服務之間的互操做。微服務

爲何gRPC是高效的?

  • 它基於HTTP2構建,既支持傳統的請求-響應模型,也支持雙向流模型。
  • 能夠將JSON數據轉換到協議緩衝區
  • 多路複用
  • 雙向流模型
  • 網絡傳輸的是二進制數據,相對於JSON等文本數據更加輕量級。
  • 多語言支持

何時使用gRPC?

最初,幾乎全部的微服務之間都是經過JSON數據接口通訊的,一個服務可能調用空一個服務或者多個服務,被調用的服務可能還調用其餘服務。若是其中任何一個服務運行緩慢,將影響整個系統的運行速度,由於RESTful(JSON) API不支持HTTP2的多路複用和雙向流模型。傳統的RESTful接口使用JSON、XML或者其餘的一些格式做爲數據載體,使得服務運行緩慢,內存佔用較高、而且傳輸過程沒有壓縮。

gRPC解決全部的這些問題,可是它僅僅用於系統應用微服務之間的通訊的狀況,系統的對外服務接口仍然使用HTTP-JSON接口。這樣保證對外部用戶的開發技術棧沒有任何影響。性能

總結 Conclusion

與傳統REST API相比,使用gRPC建立的API能夠爲你的應用帶來使人難以置信的性能改進。spa

歡迎關注個人博客,裏面有不少精品合集

  • 本文轉載註明出處(必須帶鏈接,不能只轉文字):字母哥博客
相關文章
相關標籤/搜索