一、什麼是RPC
RPC是“遠程呼叫(Remote Procedure Call)”的一個名稱的縮寫,並不是任何規範化的協議,也不是大眾都認知的協議標準,我們更多時候使用時都是創建的自定義化(例如Socket,Netty)的訊息方式進行呼叫,相比http協議,我們省掉了不少http中無用的訊息內容。因此很多系統內部呼叫仍然採用自定義化的RPC呼叫樣式進行通信,畢竟速度和性能是內網的關鍵指標之一,而標準化和語意無關性在外網中舉足輕重。所以,為何API網關無法工作在RPC上,因為它沒有一個像HTTP/HTTPS那樣的通用標準。
二、CzarRpc簡介
CzarRpc是作者基於Dotnetty實現的RPC通訊框架,參考了Surging
和Tars.Net
優秀設計,目前正在內部使用中,下麵就CzarRpc呼叫方式做一個簡單介紹,測試結構如下:
1、服務接口
新建一個Czar.Rpc.Common
類庫,首先需要取用Czar.Rpc
Nuget包。
然後定義測試接口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中下載預覽。