知識星球一、什麼是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.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中下載預覽。
