使用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可以為你的應用帶來令人難以置信的性能改進，
歡迎關注我的博客，里面有很多精品合集
- 本文轉載注明出處（必須帶連接，不能只轉文字）：字母哥博客，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/12544.html
標籤：架構設計