gRPC的結構
在我們搭建gRPC通信系統之前，首先需要知道gRPC的結構組成，
首先，需要一個server（服務器），它用來接收和處理請求，然后回傳回應，
既然有server，那么肯定有client（客戶端），client的作用就是向server發送請求，具體就是生成一個請求，然后把它發送到server，然后等待server的回應，
但是它們不必是一對一的關系，在整個系統里，可以有多個server，也可以有多個client，根據實際情況，一個應用程式可能是gRPC的server，也可能是gRPC的client，也可能兩者都是，
gRPC里面server和client并不是直接通信的，gRPC可以使用protocol buffer定義的訊息來生成代碼，
當client發送請求的時候，它會和server端生成的代碼進行互動；同樣在client端也有生成的代碼，client端生成的代碼負責提供一個隧道，這個隧道被用來吧client端生成的訊息發送給server，
因為server和client兩端都有生成的代碼，所以如何序列化和反序列化，以及如何進行來回的傳輸等細節，我們都可以不了解，
但是為了讓server和client端來回傳輸通信，我們還需要一個協議，傳輸協議就負責把訊息來回的傳遞，所以它并不需要懂得這些訊息的內容，生成的代碼會負責理解這些訊息，但是傳輸協議需要負責把訊息從一端傳遞到另一端，
目前，好像gRPC只能使用Protocol Buffer這一個傳輸協議，但是gRPC在設計的時候，它的傳輸層是可插拔的，所以如果我們想把Protocol Buffer使用某種JSON或XML的協議替換掉，是可行的，如果你有特定的需求使用Protocol Buffer無法實作的話，那么你也可以創建自己的傳輸協議，
設計步驟
總共應該分三步，設計原則是從里到外（看上面結構圖），
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/65251.html
標籤：其他
上一篇：C#后臺異步訊息佇列實作
下一篇：docker 常用命令