DAY9 — 神奇的 gRPC，讓你把 call service 當成一個 function call — 概念篇 - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天

第 12 屆 iThome 鐵人賽

DAY 9

Modern Web

DAY9 — 神奇的 gRPC，讓你把 call service 當成一個 function call — 概念篇

12th鐵人賽 backend golang grpc microservice

9327 瀏覽

本文章同時發佈於：

文章為自己的經驗與夥伴整理的內容，設計沒有標準答案，如有可以改進的地方，請告訴我，我會盡我所能的修改，謝謝大家～

大家好，繼昨天DAY08的介紹後，Clean Architecture 架構告一段落。現在我們來思考一下，如果後端微服務龐大起來，如下圖，可能會產生什麼問題？

雖然我們已經透過了 Swagger 最大程度的控管 Restful API 的介面，但值透過enum來實現、這個參數是require但你忘記帶程式也不會告知你，為了解決這些問題，有個很簡單粗暴的方法：

讓 Service 的溝通變成 function call 吧！

而這件事可以透過RPC(Remote Procedure Call)達成，流程圖如下，其實他得概念並不複雜，單純就是把call function與return result間的流程加了一道網路轉換

事實上 RPC 在 1976 年就誕生了，並不是什麼新技術，當時為了要處理多台電腦的通信採用此方法，後來衍伸出了XML-RPC、SOAP這樣的協定，但在定義與使用上都有些繁瑣古老，後來 Google 發展出了gRPC，為現代的微服務提供簡單高效強大的 RPC 協定。

傳輸緩慢的問題: gPRC 透過Protobuf轉換來解決，會將 function 的參數轉換成二進制的格式，以支援二進制溝通功能的HTTP/2來傳送，使得溝通極小極快。
微服務溝通介面混亂的問題: gRPC 透過定義 Protobuf 的 schema 解決，此 schema 不但可以定義傳輸的訊息，也可以定有哪些傳輸 function，並且這些 function 的參數是什麼。

以 Golang 來說，這些定好的 Protobuf schema 透過官方的codegen tool，直接產生實際的 function 與 struct。

而你實際使用時，只要直接 call 此 function 並且帶對參數就可以了，因為是 function call，所以要帶什麼參數更加的直觀，而編譯器會告訴你是否帶對參數也更佳安全。

gRPC 在定義 function 時，可以針對不同場景，使用多種方案:

單向傳輸(Unary): 機制上跟 Restful API 一樣，就是一個 request 一個 response，只不過是透過了 gRPC 協定。
單向串流(Streaming): 你可以想像成訂閱機制，client 透過一個 request訂閱 server 後，server 就可以發送無數次 response。
雙向串流(Bidirectional streaming): 機制就像 Websocket，但是在傳輸格式有透過 schema 定義，client 可以發送無數次 request，server 也可以發送無數次 response