歡迎光臨
每天分享高質量文章

聊聊如何設計千萬級吞吐量的.NET Core網絡通信

來自:笑笑

鏈接:http://www.cnblogs.com/xxred/p/9859893.html

 

介紹

 

首先看下麵這張很具有代表性的圖,2018年5月份做的測試。當時單服務器得到 2256tps(Transactions Per Second,每秒事務數) 的吞吐率。

 

這次測試只是說明一個問題,.Net可以做超高吞吐率的應用。

 

 

 

當時測試相關記錄和代碼地址:

 

記錄:https://www.cnblogs.com/nnhy/p/newlife_net_benchmark.html

代碼國外地址:https://github.com/nnhy/NewLife.Net.Tests

代碼國內地址:http://git.newlifex.com/Stone/NewLife.Net.Tests

 

1.1 開始網絡編程

 

簡單的網絡程式示例

 

相關使用介紹《NewLife.Net—開始網絡編程》https://www.cnblogs.com/nnhy/p/newlife_net_echo.html

克隆上面的代碼,運行EchoTest專案,打開編譯的exe,打開兩次,一個選1作為服務器,一個選2作為客戶端

 

 

在客戶端連接服務器和給服務端發送資料的時候,分別觸發Start和OnReceive方法,連接之後服務端發送了Welcome 的訊息,客戶端發送5次“你好”。

 

服務端回傳收到的資料,打了一個日誌,把收到的信息轉成字串輸出到控制台。

 

NetServer是應用級網絡服務器,支持tcp/udp/ipv4/ipv6。上面可以看到,同時監聽了四個端口。

 

碼神工具https://github.com/NewLifeX/XCoder)也可以連接上來

 

 

解釋

 

對於網絡會話來說,最關鍵的就是客戶端連上來,以及收到資料包,這兩部分,對應上面Start和OnReceive兩個方法

 

 

服務端

 

上面是最小的網絡庫例程,簡單演示了服務端和客戶端,連接和收發信息。網絡應用分為NetServer/NetSession,服務端、會話,N個客戶端連接服務器,就會有N個會話。

 

來一個客戶端連接,服務端就new一個新的NetSession,並執行Start,收到一個資料包,就執行OnReceive,連接斷開,就執行OnDispose,這便是服務端的全部。

 

客戶端連接剛上來的時候,沒有資料包等其它信息,所以這個時候沒有引數。客戶端發資料包過來,OnReceive函式在處理。

 

服務端的創建,可以是很簡單,看以下截圖。這裡為了測試方便,開了很多Log,實際使用的時候,根據需要註釋。

 

 

長連接、心跳第二節設計理念再講。

 

客戶端

 

跟很多網絡庫不同,NewLife.Net除了服務端,還封裝了客戶端。客戶端的核心,也就是Send函式和Received事件,同步發送,異步接收。

 

 

因為是長連接,所以服務端隨時可以向客戶端發送資料包,客戶端也可以收到。tcp在不做設置的時候,預設長連接2小時。

 

NetServer預設20分鐘,在沒有心跳的時候,20分鐘沒有資料包往來,服務端會幹掉這個會話。

 

雖然上面講的NetServer和Client,都是tcp,但是換成其它協議也是可以的。這裡的NetServer和NetUri.CreateRemote,同時支持Tcp/Udp/IPv4/IPv6等,CreateRemote內部,就是根據地址的不同,去new不同的客戶端。所以我們寫的代碼,根本不在意用的是tcp還是udp,或者IPv6。

 

原始碼:https://github.com/NewLifeX/X/blob/master/NewLife.Core/Net/NetHelper.cs#L690

 

1.2 構建可靠網絡服務

 

《NewLife.Net——構建可靠的網絡服務》https://www.cnblogs.com/nnhy/p/newlife_net_agent.html

 

要真正形成一個網絡服務,那得穩定可靠。上面例程EchoTest只是簡單演示,接下來看下一個例程EchoAgent。

 

 

安裝運行

 

這是一個標準的Windows服務,有了這個東西,我們就可以妥妥的註冊到Windows裡面去。這也是目前我們大量資料分析程式的必備。

 

首先運行EchoAgent,按2,安裝註冊服務,用管理員身份運行。安裝成功然後可以在服務裡面找到剛剛安裝的服務。

 

 

安裝完成可以在服務上找到,再次按2就是卸載,這個是XAgent提供的功能

 

 

這時候按3,啟動服務

 

 

代碼解釋

 

接下來看代碼,服務啟動的時候,執行StartWork。在這個時候實體化並啟動NetServer,得到的效果就跟例程EchoTest一樣,區別是一個是控制台一個是服務。

 

停止服務時執行StopWork,我們可以在這裡關閉NetServer。

 

原始碼:http://git.newlifex.com/NewLife/NewLife.Net/Blob/master/EchoAgent/Program.cs

 

 

必須有這個東西,你的網絡服務程式,才有可能達到產品級。linux上直接控制台,上nohup,當然還有很多其它辦法。以後希望這個XAgent能夠支持linux吧,這樣就一勞永逸了

 

1.3 壓測

 

《NewLife.Net——網絡壓測單機2266萬tps》https://www.cnblogs.com/nnhy/p/newlife_net_benchmark.html

 

只需要記住一個兩個數字,.net應用打出來2266萬tps,流量峰值4.5Gbps

兩千萬吞吐量的數字,當然,只能看不能用。因為服務端只是剛纔的Echo而已,並沒有帶什麼業務。實際工作中,帶著業務和資料庫,能跑到10萬已經非常非常牛逼了。

 

我們工作中的服務可以跑到100萬,但是我不敢,怕它不小心就崩了。所以我們都是按照10萬的上限來設計,不夠就堆服務器好了,達到5萬以上後,穩定性更重要

 

網絡編程的坑

 

主要有粘包

 

程式員中會網絡編程的少,會解決粘包的更少!

 

1.4 網絡編程的坎——粘包

 

普遍情況,上萬的程式員,會寫網絡程式的不到20%,會解決粘包問題的不到1%,如果大家會寫網絡程式,並且能解決粘包,那麼至少已經達到了網絡編程的中級水平。

 

什麼是粘包

 

舉個慄子:客戶端連續發了5個包,服務端就收到了一個大包。代碼就不演示了,把第一個例程的這個睡眠去掉。

 

 

客戶端連續發了5個包,服務端就收到了一個大包。

 

原因

 

很多人可能都聽說Tcp是流式協議,但是很少人去問,什麼叫流式吧?流式,就是它把資料像管道一樣傳輸過去。

 

剛纔我們發了5個 “你好”,它負責把這10個字發到對方,至於發多少次,每次發幾個字,不用我們操心,tcp底層自己處理。tcp負責把資料一個不丟的按順序的發過去。所以,為了性能,它一般會把相近的資料包湊到一起發過去。對方收到一個大包,5個小包都粘在了一起,這就是最簡單的粘包。

 

這個特性由NoDelay設置決定。NoDelay預設是false,需要自己設置。如果設置了,就不會等待。但是不要想得那麼美好,因為對方可能合包。

 

局域網MTU(Maximum Transmission Unit,最大傳輸單元)是1500,處於ip tcp 頭部等,大概1472多點的樣子。

 

更複雜的粘包及解決方法

 

A 1000 位元組 B 也是 1000位元組,對方可能收到兩個包,1400 + 600。對方可能收到兩個包,1400 + 600。

 

凡是以特殊符號開頭或結尾來處理粘包的辦法,都會有這樣那樣的缺陷,最終是給自己挖坑。所以,tcp粘包,絕大部分解決方案,偏向於指定資料包長度。這其中大部分使用4位元組長度,長度+資料。對方收到的時候,根據長度判斷後面資料足夠了沒有。

 

這是粘包的處理代碼:http://git.newlifex.com/NewLife/X/Blob/master/NewLife.Core/Net/Handlers/MessageCodec.cs

 

 

每次判斷長度,接收一個或多個包,如果接收不完,留下,存起來。等下一個包到來的時候,拼湊完整。

 

雖然tcp確保資料不丟,但是難免我們自己失手,弄丟了一點點資料。為了避免禍害後面所有包,就需要進行特殊處理了。

 

每個資料幀,自己把頭部長度和資料體湊一起發送啊,tcp確保順序。這裡我們把超時時間設置為3~5秒,每次湊包,如果發現上次有殘留,並且超時了,那麼就扔了它,省得禍害後面。

 

 

根據以上,粘包的關鍵解決辦法,就是設定資料格式,可以看看我們的SRMP協議,1位元組標識,1位元組序號,2位元組長度

 

 

如果客戶端發送太頻繁,服務端tcp緩衝區阻塞,發送視窗會逐步縮小到0,不再接受客戶端資料。

 

1.5 .NetCore版RPC框架

 

NetCore版RPC框架NewLife.ApiServerhttps://www.cnblogs.com/nnhy/p/newlife_apiserver.html)。

 

 

先看看這個效果

 

 

代碼分析

 

我們看這部分代碼,4次呼叫遠程函式,成功獲取結果,包括二進制高速呼叫、傳回覆雜物件、捕獲遠程異常,沒錯,這就是一個RPC。

 

 

服務端

 

有沒有發現,這個ApiServer跟前面的NetServer有點像?其實ApiServer內部就有一個NetServer

 

 

這麼些行代碼,就幾個地方有價值,一個是註冊了兩個控制器。你可以直接理解為Mvc的控制器,只不過我們沒有路由管理系統,直接手工註冊。

 

第二個是指定編碼器為Json,用Json傳輸引數和傳回值。其實內部預設就是Json,可以不用指定

看看我們的控制器,特別像Mvc,只不過這裡的Controller沒有基類,各個Action傳回值不是ActionResult,是的,ApiServer就是一個按照Mvc風格設置的RPC框架

 

 

傳回覆雜物件

 

 

做請求預處理,甚至攔截異常

 

 

像下麵這樣寫RPC服務,然後把它註冊到ApiServer上,客戶端就可以在1234端口上請求這些接口服務啦

 

 

客戶端

 

客戶端是ApiClient,這裡的MyClient繼承自ApiClient

 

 

這些就是我們剛纔客戶端遠程呼叫的stub代碼啦,當然,我們沒有自動生成stub,也沒有要求客戶端跟服務端共用接口之類。

 

實際上,我們認為完全沒有必要做接口約束,大部分專案的服務接口很少,並且要求靈活多變

stub就是類似於,剛纔那個MyController實現IAbc接口,然後客戶端根據服務端元資料自動在記憶體裡面生成一個stub類並編譯,這個類實現了IAbc接口。

 

客戶端直接操作接口,還以為在呼叫服務端 的函式呢

其實stub代碼內部,就是封裝了 這裡的InvokeAsync這些代碼,等同於自動生成這些代碼,包括gRPC、Thrift等都是這麼乾的

 

框架解析

 

這個RPC框架,封包協議就是剛纔的SRMP,負載資料也就是協議是json

當需要高速傳輸的時候,引數用Byte[],它就會直接傳輸,不經json序列化,這是多年經驗得到的靈活性與性能的最佳結合點

 

2.1 人人都有一個自己的高性能網絡庫

 

網絡庫核心代碼:http://git.newlifex.com/NewLife/X/Tree/master/NewLife.Core/Net

我們一開始就是讓Tcp/Udp可以混合使用,網絡庫設計於2005年,應該要比現如今絕大部分網絡框架要老。服務端清一色採用 Server+Session 的方式。

 

網絡庫的幾個精髓檔案

 

 

其中比較重要的一個,裡面實現了 Open/Close/Send/Receive 系列封裝,Tcp/Udp略有不同,多載就好了。打開關閉比較簡單,就不講了

 

 

所有物件,不管客戶端服務端,都實現ISocket。然後客戶端Client,服務端Server+Session。tcp+udp同時支持並不難,因為它們都基於Socket。

目前無狀態無會話的通信架構,做不到高性能。我們就是依靠長連接以及合併小包,實現超高吞吐量

 

一般靈活性和高性能都是互相矛盾的

 

2.2 高性能設計要點

 

第一要點:同步發送,因為要做發送佇列、拆分、合併,等等,異步發送大大增加了複雜度。大家如果將來遇到詭異的40ms延遲,非常可能就是tcp的nodelay作怪,可以設為true解決

 

第二要點:IOCP,高吞吐率的服務端,一定是異步接收,而不是多執行緒同步。當然,可以指定若干個執行緒去select,也就是Linux裡面常見的poll,那個不在這裡討論,Windows極少人這麼乾,大量資料表明,iocp更厲害。

 

 

SAEA是.net/.netcore當下最流行的網絡架構,我們可以通俗理解為,把這個緩衝區送給操作系統內核,待會有資料到來的時候,直接放在裡面,這樣子就減少了一次內核態到用戶態的拷貝過程。

 

我們測試4.5Gbps,除以8,大概是 540M位元組,這個拷貝成本極高

 

第三要點:零拷貝ZeroCopy,這也是netty的核心優勢。iocp是為了減少內核態到用戶態的拷貝,zerocopy進一步把這個資料交給用戶層,不用拷貝了。

資料處理,我們採用了鏈式管道,

 

 

這些都是管道的編碼器

 

 

第四要點:合併小包,NoDelay=false,允許tcp合併小包,MTU=1500,除了頭部,一般是1472

 

第五要點:二進制序列化,訊息報文盡可能短小,每個包1k,對於100Mbps,也就12M,理論上最多12000包,所以大量Json協議或者字串協議,吞吐量都在1萬上下

SRMP頭部4位元組,ApiServer的訊息報文,一般二三十個位元組,甚至十幾個位元組

 

第五要點:批量操作,User FindByID(int id); User[] FindByIDs(int[] ids);

 

最後

 

整理不全,大家湊合著看。中途錄屏,語音啥的還掉了,準備得不是很好,下周再來一次吧,選Redis

 


●編號173,輸入編號直達本文

●輸入m獲取文章目錄

推薦↓↓↓

 

Web開發

更多推薦25個技術類公眾微信

涵蓋:程式人生、演算法與資料結構、黑客技術與網絡安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等

文章已於修改
    赞(0)

    分享創造快樂