gRPC的結(jié)構(gòu)?

在我們搭建gRPC通信系統(tǒng)之前，首先需要知道gRPC的結(jié)構(gòu)組成。?

首先，需要一個(gè)server（服務(wù)器），它用來接收和處理請求，然后返回響應(yīng)。?

既然有server，那么肯定有client（客戶端），client的作用就是向server發(fā)送請求，具體就是生成一個(gè)請求，然后把它發(fā)送到server，然后等待server的響應(yīng)。?

但是它們不必是一對一的關(guān)系，在整個(gè)系統(tǒng)里，可以有多個(gè)server，也可以有多個(gè)client。根據(jù)實(shí)際情況，一個(gè)應(yīng)用程序可能是gRPC的server，也可能是gRPC的client，也可能兩者都是。?

?

gRPC里面server和client并不是直接通信的，gRPC可以使用protocol buffer定義的消息來生成代碼。?

當(dāng)client發(fā)送請求的時(shí)候，它會和server端生成的代碼進(jìn)行交互；同樣在client端也有生成的代碼，client端生成的代碼負(fù)責(zé)提供一個(gè)隧道，這個(gè)隧道被用來把client端生成的消息發(fā)送給server。?

因?yàn)閟erver和client兩端都有生成的代碼，所以如何序列化和反序列化，以及如何進(jìn)行來回的傳輸?shù)燃?xì)節(jié)，我們都可以不了解。?

?

但是為了讓server和client端來回傳輸通信，我們還需要一個(gè)協(xié)議，傳輸協(xié)議就負(fù)責(zé)把消息來回的傳遞。所以它并不需要懂得這些消息的內(nèi)容，生成的代碼會負(fù)責(zé)理解這些消息，但是傳輸協(xié)議需要負(fù)責(zé)把消息從一端傳遞到另一端。?

目前，好像gRPC只能使用Protocol Buffer這一個(gè)傳輸協(xié)議。但是gRPC在設(shè)計(jì)的時(shí)候，它的傳輸層是可插拔的，所以如果我們想把Protocol Buffer使用某種JSON或XML的協(xié)議替換掉，是可行的。如果你有特定的需求使用Protocol Buffer無法實(shí)現(xiàn)的話，那么你也可以創(chuàng)建自己的傳輸協(xié)議。?

?

設(shè)計(jì)步驟?

總共應(yīng)該分三步。設(shè)計(jì)原則是從里到外（看上面結(jié)構(gòu)圖）。?

所以：?

首先我們應(yīng)該定義消息（message）。這些消息使用Protocol?Buffer來進(jìn)行定義?

定義完消息，我們使用Proto-c編譯器來生成server和client端的代碼，它們會負(fù)責(zé)把消息在兩端之間來回傳遞?

現(xiàn)在，我們就可以寫client和server了。?

?

?

gRPC?生命周期?

?

?

gRPC或者RPC的生命周期可以參考上圖。?

首先，需要創(chuàng)建一個(gè)隧道，該隧道會包裝實(shí)際用來傳輸消息的線路協(xié)議。?

例如如果我們的server和client之間使用HTTP/2協(xié)議，那么這個(gè)隧道就會包裝一個(gè)server和client之間的TCP連接。?

這些隧道的優(yōu)點(diǎn)是，它們只需要創(chuàng)建一次。一旦隧道創(chuàng)建了，你就可以在你應(yīng)用程序的生命周期之內(nèi)持續(xù)的使該隧道來回發(fā)送消息。?

?

隧道建立好之后，就該創(chuàng)建client了。client也是可以復(fù)用的，不必每個(gè)rpc調(diào)用都重建client。但是在調(diào)用之前，我們需要把client建立好。?

現(xiàn)在client進(jìn)入隧道，這個(gè)client通常是提供給我們的，我們不需要自己實(shí)現(xiàn)任何代碼。使用Proto-c編譯消息定義生成的代碼將會給我們提供client需要的一切。我們只需要提供隧道即可。?

?

client創(chuàng)建好之后，client就準(zhǔn)備好給server發(fā)送請求了。這一步是必須的，gRPC無法讓server端初始化請求發(fā)送給client端，請求都是client端初始化的。?

但是client初始化請求之后，server端是可以發(fā)送多個(gè)響應(yīng)回來的，這個(gè)以后再說。這時(shí)，client可以隨著請求發(fā)送一些metadata（元數(shù)據(jù)），這些metadata是關(guān)于請求的，但不是請求對象本身。?

?

請求被發(fā)送以后呢，server可以（但不是必須）把metadata返回。所以，你實(shí)際上可以在client和server之間進(jìn)行這種“預(yù)約對話”。client可以發(fā)送一些metadata，然后server可以把一些metadata發(fā)送回來，這些都是發(fā)生在server開始處理請求之前。?

?

生命周期的最后一部分就是發(fā)送和接收消息。就以簡單的情況為例，現(xiàn)在server就應(yīng)該把響應(yīng)發(fā)送回去了，因?yàn)閏lient已經(jīng)發(fā)送了請求，所以響應(yīng)就是要返回。?

?

注意，關(guān)于metadata需要注意的是，gRPC內(nèi)置的身份認(rèn)證系統(tǒng)是用來做client和server的身份認(rèn)證的。?

但是這個(gè)metadata也為你提供了檢查實(shí)際用戶身份的機(jī)制。所以，如果你需要認(rèn)證或者授權(quán)實(shí)際用戶，就需要在RPC請求這個(gè)級別來實(shí)現(xiàn)。也就是在這里。?

如果是client和server的身份認(rèn)證，以后再寫。。

總結(jié)

以上是生活随笔為你收集整理的gRPC in ASP.NET Core 3.x - gRPC 简介（1）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。