C# 的輕量級 RPC 架構

標籤：googl   簡單   瓶頸   構建   level   情況   機制   mode   csharp   

Redola.Rpc 的一個小目標Redola.Rpc 的一個小目標

Redola.Rpc 的一個小目標：20000 tps。

   Concurrency level: 8 threads   Complete requests: 20000Time taken for tests: 0.886 seconds    Time per request: 0.044 ms (avg) Requests per second: 22573 [#/sec] (avg)

   Concurrency level: 8 threads   Complete requests: 10000Time taken for tests: 0.424 seconds    Time per request: 0.042 ms (mean) Requests per second: 23584 [#/sec] (avg)

測試環境使用 AWS 虛擬機器 AWS EC2 C4 Instance Model c4.2xlarge，配置如下：

Processor: Intel(R) Xeon(R) CPU E5-2666 v3 @ 2.90GHz     vCPU: 8   Memory: 15 GiB  Storage: 30G EBS-OnlyBandwidth: 1,000 Mbps       OS: Windows Server 2012 R2

Redola.Rpc 是什嗎？

• Redola.Rpc 是一個基於 C# 的輕量級 RPC 架構；
• Redola.Rpc 是一個原始碼託管在 GitHub 上的開源項目；
• Redola.Rpc 是一個發布在 nuget.org 上的可安裝軟體包；

　　原始碼開源地址：https://github.com/gaochundong/Redola

　　範例測試代碼：https://github.com/gaochundong/Redola/tree/master/Tests

Redola.Rpc 的特點

• 簡單粗暴，一看就懂；
• 簡單的註冊中心，消除配置障礙；
• 支援 Request / Response 阻塞模型；
• 支援任意服務間的訊息推送；
• 內建 protobuf 序列化，提供可替換介面；

Redola.Rpc 內部結構

Redola.Rpc 基於 Cowboy.Sockets 進行構建，使用 TCP Socket 進行服務間通訊，預設使用 .NET APM TCP Socket 模式。通過 Actor 模型抽象封裝 Socket 串連與互動，實現 Actor 之間的 Register、Lookup、Handshake、KeepAlive 等功能；

Redola.Rpc 概念性模型

• Actor Peer：代表一個 Actor 節點，任意 Actor 之間均可通訊；
• Actor Master：作為 Actor 節點註冊中心，用於服務的註冊與發現；
• Actor Identity：一個 Actor 的身份描述，包括 Type、Name、Address、Port 等；
• RPC Service：用於實現具體的 RPC 服務，一個 Actor 可以註冊多個 RPC Service；

Redola.Rpc 通訊模型

Actor Peer 與 Actor Peer 之間通過 TCP 長串連進行通訊。Actor 封裝了 TCP 中關於 TcpClient 和 TcpServer 的抽象，對外不再暴露 Client 和 Server 的概念，僅以 Peer 呈現，Peer 與 Peer 之間是平等的。Actor Master 與其他 Peer 的區別僅是承擔了 Register 和 Lookup 的職責。

Actor Peer 間通過 Actor Master 查詢到需要通訊的對端 Actor Peer 的 Actor Identity，會首先進行 Handshake 交換 Actor Identity，用以記錄對方的身份。Handshake 之後，即可進行預定義註冊的 RPC 訊息通訊。

為掌握對端 Peer 的活躍情況，通過內建的 KeepAlive 機制進行服務間保活，每隔約定時間進行訊息互動，若逾時時間內未獲得保活回複，則自動中斷連線。KeepAlive 同時做了一定的最佳化，若服務間在保活時間內有任何 Send 或 Receive 訊息作業，則視為有服務間通訊，即對端為活躍狀態，會延遲發送保活請求。

假設 Actor 1 (Tyep:hello, Name:hello-001, Address:192.168.1.139, Port:8888) 需要與 Actor 2 (Type:world, Name:world-001, Address:192.168.1.158, Port:7777) 進行通訊，則僅需發送訊息時指定 Actor 2 的身份 (world, world-001)，其中 world 為 Actor 2 的類型，world-001 為該 world 類型下名稱為 world-001 的 Actor Peer。

Redola.Rpc 基本契約

• 任意 Actor 均需向 Actor Master 註冊，提供自身 Actor Identity 資訊；
• 僅指定 Actor Type 發送訊息，則會隨機 Lookup 一個該 Type 的 Actor 進行通訊；
• Actor 不區分 Client 和 Server 角色，角色由使用者設計；
• RPC 調用介面有同步和非同步之分，由使用者選擇；
• 支援 Request/Response 同步阻塞模式，可設定阻塞逾時時間；
• 訊息註冊後，通過反射匹配訊息處理方法，On + MessageType 契約編程；
• RPC 限流在訊息處理側實施，預設 RateLimiter 限制 CPU 相同數量線程；
• 內部 TCP 配置 Buffer Pool 連續記憶體會伴隨串連數和吞吐增加，單 Buffer 8K 大小；
• 若 RPC 傳遞訊息大於 84K，.NET 將 Buffer 分配到 LOH 上，GC 未必及時回收；

Redola.Rpc 的依賴庫

• Cowboy.Sockets 基於 C# 實現的 TCP Socket 類庫；
• protobuf-net 支援 .NET 的 Google Protocol Buffers 序列化；
• Logrila.Logging 日誌架構適配器；

有那麼多 RPC 架構，為什麼要自己寫一個？

演化出來的，那就是一個故事了。

起初，我們作為一個初創公司，還在嘗試思考清楚我們要做的東西究竟應該是什麼樣子，畢竟市場上少有同類競品，那麼首先設計一個原型是合理的。所以，我們只有一個應用程式，用於定時拉取第三方夥伴的 WebService 資料，並通過設計的演算法進行計算處理，然後寫入資料庫；

有了資料，總要找地方展現吧，於是招聘了 Unity3D 前端開始做炫酷的 App，有即時資料推送的展現要求，所以前後端通訊使用了 WebSocket 通訊協定，也就產生了 Cowboy.WebSockets；

第三方夥伴的 WebService 顯然不只一個介面，多個介面並發拉取，每 100 毫秒拉取一次，線程繁忙影響了計算處理和寫入資料庫；好，將資料拉取分離出去，並進行前期的資料清洗和過濾，然後再發給演算法計算引擎；這時，就有了 2 個服務，一個負責拉取資料 Feed，一個負責計算入庫 Engine，通過 Cowboy.Sockets 進行 TCP 訊息通訊；

終於有更多的資料可供展現了，當然 U3D App 也快開發完成了，App 不可能就裝在一個手機上吧，萬一發布到 AppStore 上火了呢？引入了接入層 Gateway 系列服務，用於保持 WebSocket 長串連和資料推送；好，現在有了 2 + n 個服務了，並且 n > 5 還做了軟負載平衡；

演算法引擎 Engine 計算完後，要將資料分發到這 n 個 Gateway 服務上，臣妾就這兩顆 CPU，著實做不到啊！分發成了瓶頸，萬一 n 成長到 50 怎麼辦？好，將資料推送委託給新服務 Bolt 服務，專門做推送給 Gateway；

引擎演算法發現需要更多輸入來源資料參與計算，好吧，引入更多第三方資料 Feed 供應商，每家一個服務做拉取；艾瑪~ 每家實際上是多個服務拉取~ 還有要求主動推送的 ~

哎呀，對於同一領域對象，每家的描述 ID 顯然不一樣，畢竟不是一個公司，手工匹配好煩，眼睛都快瞎了，做個 Mapping 自動服務根據特徵專門負責匹配 ID，匹配好了再發給引擎，媽媽再也不用擔心我的 ID；

資料簡直不要太多，計算引擎 Engine 邊計算邊入庫，常年 100% CPU 啊我的哥；拆！先將預先處理資料入庫，再將計算的結果入庫；

什嗎？資料庫寫入有延遲？線程被阻塞，又跟我的 CPU 過不去！拆，引流寫操作到 MQ 訊息佇列，加上 Durability 落地，愛阻塞誰阻塞誰，愛啥時候寫啥時候寫。

隔壁老王看了一眼我們的 U3D App，矮油不錯哦，狂拽酷霸吊炸天啊！你們這資料演算法和計算引擎有些超出我的知識範圍，我有一些新的產品想法，要麼你們幫我實現 H5，要麼你們提供 API 我們自己實現 H5，反正我的想法必須實現，你看這是 20% 預付款你們下個星期能不能上線 API 啊？王哥，有錢還能有辦不成的事兒？是吧，說，你都要啥推送介面？Socket + Protobuf 可以吧？HTTP 也行？

剛回國的尼古拉斯趙四聽聞有 API 開放能力，那必須接入啊，共用經濟實現共贏嘛，有錢大家一起賺，只是這 API 介面能不能修改成 RESTful + 反向 POST？

我相信，明天還會有新需求的！要善待今天的自己，底層封裝成 Redola.Rpc 架構！

C# 的輕量級 RPC 架構