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