Redola.Rpc 的一個小目標

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

   Concurrency level: 8 threads
   Complete requests: 20000
Time 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: 10000
Time taken for tests: 0.424 seconds
    Time per request: 0.042 ms (mean)
 Requests per second: 23584 [#/sec] (avg)

測試環(huan)境使用 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-Only
Bandwidth: 1,000 Mbps
       OS: Windows Server 2012 R2

Redola.Rpc 是什么？

• Redola.Rpc 是一個基于 C# 的輕量級 框架；
• Redola.Rpc 是一個源代碼托管在 上的開源項目；
• Redola.Rpc 是一個發布在 上的可安裝軟件包；

　　源代碼開源地址：

　　樣例測試代碼：

Redola.Rpc 的特點

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

Redola.Rpc 內部結構

Redola.Rpc 基于 進(jin)行(xing)構建，使用 TCP Socket 進(jin)行(xing)服務間(jian)通信，默(mo)認使用 .NET  TCP Socket 模(mo)式(shi)。通過 Actor 模(mo)型抽象封裝 Socket 連接與交互，實(shi)現(xian) Actor 之間(jian)的 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 長(chang)連(lian)接(jie)進行通信(xin)。Actor 封裝了(le) TCP 中關于 TcpClient 和 TcpServer 的抽象，對(dui)外不再(zai)暴露 Client 和 Server 的概(gai)念，僅以 Peer 呈現，Peer 與 Peer 之間是平等(deng)的。Actor Master 與其他 Peer 的區別僅是承(cheng)擔了(le) Register 和 Lookup 的職責。

Actor Peer 間通過 Actor Master 查(cha)詢到需要通信的(de)對端 Actor Peer 的(de) Actor Identity，會首先進(jin)(jin)行 Handshake 交換(huan) Actor Identity，用以記錄對方的(de)身份。Handshake 之后，即可進(jin)(jin)行預定義注冊的(de) RPC 消(xiao)息通信。

為(wei)掌(zhang)握(wo)對端(duan) Peer 的活(huo)躍(yue)情況，通過(guo)內置的 KeepAlive 機制進行服(fu)務間(jian)(jian)保(bao)活(huo)，每隔約定時(shi)(shi)間(jian)(jian)進行消息交互(hu)，若(ruo)超時(shi)(shi)時(shi)(shi)間(jian)(jian)內未獲得保(bao)活(huo)回(hui)復，則(ze)自(zi)動(dong)斷(duan)開(kai)連(lian)接。KeepAlive 同時(shi)(shi)做了一定的優(you)化，若(ruo)服(fu)務間(jian)(jian)在保(bao)活(huo)時(shi)(shi)間(jian)(jian)內有(you)任何 Send 或 Receive 消息操作，則(ze)視為(wei)有(you)服(fu)務間(jian)(jian)通信，即對端(duan)為(wei)活(huo)躍(yue)狀態，會延遲發(fa)送保(bao)活(huo)請求。

假設 Actor 1 (Tyep:hello, Name:hello-001, Address:192.168.1.139, Port:8888) 需(xu)要與 Actor 2 (Type:world, Name:world-001, Address:192.168.1.158, Port:7777) 進行通信，則(ze)僅需(xu)發送消息(xi)時指定 Actor 2 的身(shen)份 (world, world-001)，其中 world 為(wei)(wei) Actor 2 的類(lei)型，world-001 為(wei)(wei)該 world 類(lei)型下名稱為(wei)(wei) 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 的依賴庫

• 基于 C# 實現的 TCP Socket 類庫；
• 支持 .NET 的 Google Protocol Buffers 序列化；
• 日志框架適配器；

有那么多 RPC 框架，為什么要自己寫一個？

演進(jin)出來的，那就是(shi)一(yi)個故(gu)事(shi)了。

起(qi)初(chu)，我們作為一(yi)個初(chu)創公(gong)司，還在嘗試思(si)考清(qing)楚我們要做的(de)東西究竟應(ying)該是什么樣子，畢竟市場(chang)上少有同類(lei)競品，那么首(shou)先設(she)計(ji)一(yi)個原(yuan)型是合理的(de)。所以，我們只(zhi)有一(yi)個應(ying)用(yong)程序，用(yong)于(yu)定時拉取(qu)第三方合作伙伴的(de) WebService 數據，并通(tong)過(guo)設(she)計(ji)的(de)算法(fa)進行計(ji)算處理，然后(hou)寫入數據庫；

有了數據，總(zong)要(yao)找地方(fang)展(zhan)現吧，于是招聘了 Unity3D 前端開始做(zuo)炫酷的 App，有實時數據推送的展(zhan)現要(yao)求(qiu)，所以前后(hou)端通信使用了 WebSocket 協議(yi)，也就產生了 Cowboy.WebSockets；

第三方合作伙伴的 WebService 顯然不只(zhi)一個(ge)(ge)接口(kou)，多個(ge)(ge)接口(kou)并(bing)發(fa)拉取(qu)，每 100 毫秒拉取(qu)一次，線程繁忙(mang)影響了計算(suan)處理和(he)(he)寫(xie)入(ru)數(shu)(shu)據庫(ku)；好，將數(shu)(shu)據拉取(qu)分離出(chu)去，并(bing)進行前期的數(shu)(shu)據清洗(xi)和(he)(he)過(guo)(guo)濾，然后再發(fa)給算(suan)法(fa)計算(suan)引(yin)擎；這時，就有了 2 個(ge)(ge)服(fu)務(wu)，一個(ge)(ge)負(fu)(fu)責拉取(qu)數(shu)(shu)據 Feed，一個(ge)(ge)負(fu)(fu)責計算(suan)入(ru)庫(ku) Engine，通過(guo)(guo) Cowboy.Sockets 進行 TCP 消(xiao)息通信(xin)；

終于有更多的數據(ju)可供展現(xian)了(le)(le)，當然(ran) U3D App 也(ye)快開發完成了(le)(le)，App 不(bu)可能就裝在(zai)一個(ge)手機上(shang)吧，萬一發布(bu)到(dao) AppStore 上(shang)火了(le)(le)呢？引入(ru)了(le)(le)接(jie)入(ru)層 Gateway 系列(lie)服(fu)務(wu)，用(yong)于保(bao)持 WebSocket 長連接(jie)和數據(ju)推送；好，現(xian)在(zai)有了(le)(le) 2 + n 個(ge)服(fu)務(wu)了(le)(le)，并(bing)且(qie) n > 5 還做(zuo)了(le)(le)軟負載均衡；

算法引擎 Engine 計算完后(hou)，要將數(shu)據分發(fa)到這 n 個(ge) Gateway 服務(wu)上(shang)，臣妾就這兩顆(ke) CPU，著實(shi)做不到啊！分發(fa)成了瓶頸，萬一(yi) n 成長到 50 怎么(me)辦？好，將數(shu)據推送委托(tuo)給(gei)新(xin)服務(wu) Bolt 服務(wu)，專門做推送給(gei) Gateway；

引(yin)擎算法發現需要(yao)更(geng)多輸(shu)入(ru)源數據參與計(ji)算，好(hao)吧，引(yin)入(ru)更(geng)多第三方數據 Feed 提供商(shang)，每家一個(ge)服務做拉(la)取(qu)；艾(ai)瑪~ 每家實際上(shang)是多個(ge)服務拉(la)取(qu)~ 還有要(yao)求主動推送的(de) ~

哎呀，對于(yu)同一領域對象，每家(jia)的(de)描述 ID 顯然不(bu)(bu)一樣，畢竟不(bu)(bu)是一個(ge)公(gong)司，手工匹配(pei)好煩(fan)，眼睛都快(kuai)瞎了，做個(ge) Mapping 自動服務根(gen)據特征專門負責匹配(pei) ID，匹配(pei)好了再發給引(yin)擎，媽媽再也不(bu)(bu)用擔心(xin)我的(de) ID；

數據簡直不要(yao)太(tai)多，計(ji)算引擎(qing) Engine 邊計(ji)算邊入(ru)(ru)庫，常年 100% CPU 啊我的(de)哥；拆！先將預(yu)處理數據入(ru)(ru)庫，再將計(ji)算的(de)結果入(ru)(ru)庫；

什么(me)？數據庫寫(xie)入(ru)有延(yan)遲？線程被阻塞(sai)(sai)，又跟我的 CPU 過不去！拆，引流(liu)寫(xie)操作到 MQ 消(xiao)息隊(dui)列，加(jia)上 Durability 落(luo)地，愛阻塞(sai)(sai)誰(shui)阻塞(sai)(sai)誰(shui)，愛啥時候寫(xie)啥時候寫(xie)。

隔壁(bi)老王(wang)看了一眼我(wo)(wo)(wo)(wo)們的(de) U3D App，矮油不錯哦，狂拽酷(ku)霸吊炸天啊！你們這(zhe)數據算法(fa)和計算引擎有(you)(you)些超出我(wo)(wo)(wo)(wo)的(de)知識范圍，我(wo)(wo)(wo)(wo)有(you)(you)一些新(xin)的(de)產品想(xiang)法(fa)，要(yao)(yao)么你們幫我(wo)(wo)(wo)(wo)實(shi)現 H5，要(yao)(yao)么你們提供 API 我(wo)(wo)(wo)(wo)們自己實(shi)現 H5，反正我(wo)(wo)(wo)(wo)的(de)想(xiang)法(fa)必須實(shi)現，你看這(zhe)是 20% 預付(fu)款你們下(xia)個(ge)星期能(neng)不能(neng)上線 API 啊？王(wang)哥，有(you)(you)錢還能(neng)有(you)(you)辦(ban)不成(cheng)的(de)事兒？是吧(ba)，說，你都要(yao)(yao)啥推送接口？Socket + Protobuf 可以吧(ba)？HTTP 也行？

剛回國的尼古(gu)拉斯趙四聽聞有(you) API 開放(fang)能(neng)力，那(nei)必須接(jie)入(ru)啊，共享(xiang)經濟實現共贏嘛，有(you)錢(qian)大家一(yi)起(qi)賺，只是這 API 接(jie)口能(neng)不能(neng)修改成 RESTful + 反向 POST？

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

版權聲明：本篇文章《Redola.Rpc 的一個小目標: 20000tps》由作者 Dennis Gao 發表自博客園個人技術博客，未經作者本人同意禁止以任何的形式轉載，任何自動的或人為的爬蟲轉載行為均為耍流氓。