歡迎光臨
每天分享高質量文章

【.NET Core專案實戰-統一認證平臺】第十六章 網關篇-Ocelot集成RPC服務

一、什麼是RPC

RPC是“遠程呼叫(Remote Procedure Call)”的一個名稱的縮寫,並不是任何規範化的協議,也不是大眾都認知的協議標準,我們更多時候使用時都是創建的自定義化(例如Socket,Netty)的訊息方式進行呼叫,相比http協議,我們省掉了不少http中無用的訊息內容。因此很多系統內部呼叫仍然採用自定義化的RPC呼叫樣式進行通信,畢竟速度和性能是內網的關鍵指標之一,而標準化和語意無關性在外網中舉足輕重。所以,為何API網關無法工作在RPC上,因為它沒有一個像HTTP/HTTPS那樣的通用標準。

二、CzarRpc簡介

CzarRpc是作者基於Dotnetty實現的RPC通訊框架,參考了SurgingTars.Net優秀設計,目前正在內部使用中,下麵就CzarRpc呼叫方式做一個簡單介紹,測試結構如下:

1、服務接口

新建一個Czar.Rpc.Common類庫,首先需要取用Czar.RpcNuget包。

然後定義測試接口IHelloRpc.cs,也是目前支持的呼叫方式。

2.服務端

新建一個控制台程式Czar.Rpc.Server,然後實現服務接口,因為都是測試資料,所以就隨意實現了方法。

HelloRpcServer.cs

然後啟動服務端監聽。

啟用外部使用CzarConfig.json的配置檔案,註意需要設置成始終複製。

到此服務器端搭載完成。

3、客戶端

新建客戶端控制台程式Czar.Rpc.Client,然後配置Rpc呼叫信息。

現在開始啟用客戶端信息。

現在整個RPC呼叫搭建完畢,然後分別啟動服務器端和客戶端,就可以看到屏幕輸出內容如下。

客戶端輸出:

服務器端輸出:

至此整個CzarRpc的基本使用已經介紹完畢,感興趣的朋友可以自行測試。

三、Ocelot增加RPC支持

有了CzarRpc的通訊框架後,現在在Ocelot上實現Rpc功能簡直易如反掌,現在開始添加我們的Rpc中間件,也讓我們擴展的網關靈活起來。

還記得我介紹網關篇時添加中間件的步驟嗎?如果不記得的可以先回去回顧下。

首先如何讓網關知道這個後端呼叫是http還是Rpc呢?這時應該會想到Ocelot路由配置里的DownstreamScheme,可以在這裡判斷我們定義的是http還是rpc即可。同時我們希望之前定義的所有中間件都生效,最後一步請求時如果配置下端路由rpc,使用rpc呼叫,否則使用http呼叫,這樣可以重覆利用之前所有的中間件功能,減少重覆開發。

在之前的開發的自定義限流和自定義授權中間件開發中,我們知道開發完的中間件放到哪裡使用,這裡就不介紹原理了,直接添加到BuildCzarOcelotPipeline里如下代碼。

這裡是在最後請求前判斷使用的下游請求方式,如果DownstreamScheme使用的rpc,就使用rpc中間件處理。

Rpc處理的完整邏輯是,如何從http請求中獲取想要解析的引數,這裡需要設置匹配的優先級,目前設計的優先級為。

1、首先提取路由引數,如果匹配上就是用路由引數名稱為key,值為value,按順序組成第一批引數。

2、提取query引數,如有有值按順序組成第二批引數。

3、如果非Get請求,提取body內容,如果非空,組成第三批引數

4、從配置庫里提取rpc路由呼叫的服務名稱和函式名稱,以及是否單向呼叫。

5、按照獲取的資料進行rpc呼叫並等待傳回。

看了上面的設計是不是思路很清晰了呢?

1、rpc路由表設計

2、提取遠程呼叫方法

根據上游路由獲取遠程呼叫的配置專案

3、重寫傳回結果

由於rpc呼叫後是傳回的Json封裝的信息,需要解析成對應的HttpContent。

4、rpc中間件邏輯處理

有了前面的準備信息,現在基本可以完成邏輯代碼的開發了,詳細的中間件代碼如下。

5、啟動Rpc客戶端配置

目前Rpc的客戶端配置我們還沒啟動,只需要在AddCzarOcelot中添加相關註入即可。

6、配置客戶端

最後別忘了配置Rpc客戶端信息是否啟用證書信息,為了配置信息的內容。

現在讓網關集成Rpc功能全部配置完畢。

四、網關Rpc功能測試

本次測試我在原有的網關基礎上,增加不同型別的Rpc呼叫,就按照不同維度測試Rpc呼叫功能,本次測試案例是建立在Czar.Rpc 服務端基礎上,正好可以測試。

1、測試路由引數

請求路徑/hello/{no}/{name},呼叫的服務端方法Hello,傳入的兩個引數分別是no ,name

可以在服務器端添加斷點除錯,發現確實接收到請求信息,並正常傳回,下麵是PostMan測試結果。

2、使用Query方式傳遞引數

請求路徑/rpc/query,呼叫的服務端方法還是Hello,引數分別是no ,name

3、使用Post方式傳遞Json

請求路徑/rpc/body,呼叫的服務器方法是HelloSendModel

4、混合引數使用

請求的路徑/rpc/bodyparm/{name},呼叫的服務器端方法是HelloSendModelParm

所有的傳回結果可自行除錯測試,發現都能達到預期結果。

同時此網關還是支持預設的http請求的,這裡就不一一測試了。

五、總結

本篇我介紹了什麼是Rpc,以及Czar.Rpc的基本使用,然後使用Czar.Rpc框架集成到我們基於Ocelot擴展網關中,並實現了不能方式的Rpc呼叫,可以在幾乎不改變現有流程的情況下很快速的集成進去,這也是Ocelot開發框架的魅力所在。

如果在使用過程中有什麼問題或建議,可以在.NET Core專案實戰交流群(637326624)中聯繫作者。

最後本文涉及的所有的原始碼可在https://github.com/jinyancao/czar.gateway中下載預覽。

 

    赞(0)

    分享創造快樂