gRPC in ASP.NET Core 3.x - gRPC 简介(1)
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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: .NET Core开发实战(第7课:用A
- 下一篇: 如何学习WPF技术?