本文章同時發佈於：
文章為自己的經驗與夥伴整理的內容，設計沒有標準答案，如有可以改進的地方，請告訴我，我會盡我所能的修改，謝謝大家～
大家好，繼昨天DAY08的介紹後，Clean
Architecture
架構告一段落。現在我們來思考一下，如果後端微服務龐大起來，如下圖，可能會產生什麼問題？
微服務溝通的災難與解決
- 傳輸的速度因為 JSON文本傳輸的方式導致緩慢
- 大量的服務溝通會使得 Restful API 的 request 與 response 的欄位逐漸混亂
雖然我們已經透過了 Swagger 最大程度的控管 Restful API
的介面，但
值透過enum來實現、這個參數是require但你忘記帶程式也不會告知你，為了解決這些問題，有個很簡單粗暴的方法：讓 Service 的溝通變成 function call 吧！
而這件事可以透過RPC(Remote
Procedure
Call)達成，流程圖如下，其實他得概念並不複雜，單純就是把
call function與return result間的流程加了一道網路轉換
- Client 端呼叫一個 function
- 此 function 的參數會被編碼成特定格式的封包，供網路傳送使用
- 網路傳送封包
- Server 接收封包
- 將封包轉換成 function 的參數格式
- 執行此 function，並回傳 result
事實上 RPC 在 1976
年就誕生了，並不是什麼新技術，當時為了要處理多台電腦的通信採用此方法，後來衍伸出了XML-RPC、SOAP這樣的協定，但在定義與使用上都有些繁瑣古老，後來
Google 發展出了gRPC，為現代的微服務提供簡單高效強大的
RPC 協定。
新世代的 RPC - gRPC
- 微服務溝通介面混亂的問題: 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
別忘了 RPC 還是透過網路
微服務很大的痛就是網路，試想看看 function call
有可能會因為網路不穩而失敗，這會多難麻煩 XD。
gRPC 可用此方法處理，Deadlines/Timeouts 來設定 timeout，go-grpc-middleware來
retry。
總而言之這是個要特別注意的地方，雖然變成了 function call
但他還是
網路傳輸XD。接下來將介紹 gRPC 的傳輸方案的實際實作，謝謝你的閱讀～