區(qū)塊鏈性能評測的方案分享

近期區(qū)塊鏈的技術概念在傳統(tǒng)IT圈逐漸升溫，成為許多遺產系統(tǒng)升級重構方案的備選技術路線。筆者本人多年從事應用系統(tǒng)研發(fā)，目前所維護的系統(tǒng)性能漸露瓶頸，分片擴容難度較大且面臨分布式改進的潛在需求，因而亟需區(qū)塊鏈架構技術儲備。

應用系統(tǒng)性能提升的關鍵在于運維端的接入管理模型（AAA，認證AuthenticaTIon、授權AuthorizaTIon、計費AccounTIng）及業(yè)務端的并發(fā)（Concurrency）/吞吐量（Throughput）模型。區(qū)塊鏈是典型的“運維友好型”系統(tǒng)，天然的自我治理能力極大程度上優(yōu)化了接入管理模型，但現有區(qū)塊鏈系統(tǒng)的并發(fā)/吞吐量模型指標卻飽受詬病。無論是BTC的7tps，還是ETH的40tps在傳統(tǒng)業(yè)務系統(tǒng)動輒萬級甚至十萬級tps面前都難以抬頭。

本著不重復造輪子的宗旨，首先梳理了一下對區(qū)塊鏈項目的需求：

·聚焦底層基礎設施，項目自身行業(yè)或領域特征不明顯，易引入本行業(yè)業(yè)務；

·能夠實現微服務級部署，擴容友好，易遷移部署；

·并發(fā)吞吐量5k+，穩(wěn)定支撐10w級DAU，可靠性強。

根據需求有的放矢地尋覓區(qū)塊鏈項目，尋覓的過程其實遠比想象的簡單。區(qū)塊鏈項目多如牛毛，但純做技術框架不扯業(yè)務場景或者經濟模型的項目真心不多。通過對主流交易所的項目篩選（畢竟不能找一個不穩(wěn)定的團隊做的東西），基本圈定了EOS、QTUM、AELF項目。EOS官宣吞吐量約3300~3500tps，QTUM官宣吞吐量為BTC的十倍（權且估算100tps），AELF項目7月伊始發(fā)布測試網，官方暫未發(fā)布吞吐量信息。選定AELF作為調研對象的原因一方面是開發(fā)指南新近發(fā)布，與最近代碼版本的可操作性強，且AELF采用的Akka并發(fā)框架應用范圍較廣，先前有所接觸。

測試設計

現有的區(qū)塊鏈系統(tǒng)業(yè)務處理能力普遍面向價值傳遞進行建設，因此對于區(qū)塊鏈系統(tǒng)性能的評測思路應面向交易過程展開。AELF項目在區(qū)塊鏈架構方面主打的特征是“主鏈+多級側鏈”，鏈間有專門的跨鏈算法實現相對隔離的業(yè)務單元間資源的協同，鏈內節(jié)點均運行于集群，節(jié)點內部通過并行化方案提升吞吐量指標。根據官方在社區(qū)披露的信息，測試網初期（即目前）提供主鏈并行計算模塊的測試驗證，確認主鏈性能后再灰度升級至多級側鏈版本，從軟件質量體系的角度而言是合理的。通過參與社區(qū)內的技術直播互動，也與項目技術團隊充分探討了AELF選用的幾個技術方案，尤其是Akka并行框架。積極選用已被驗證的成熟技術元素確實是做新系統(tǒng)、新基礎設施時的難能可貴的姿態(tài)，進一步提升了對AELF項目的好感度。PS：該團隊技術的人也在社區(qū)，很NICE很好溝通。

TransacTIon，傳統(tǒng)IT人習慣叫“事務”，區(qū)塊鏈圈的人通常叫“交易”，可能是BTC白皮書翻譯傳承下來的吧。軟件測評應充分考慮軟件質量體系的要求，同理，對于一個區(qū)塊鏈底層架構而言，模擬價值傳輸壓力的交易激勵能夠作為區(qū)塊鏈底層基礎設施tps指標的驗證形式。

據此，先定義一個原子事務作為本次測試驗證的基本測試用例——“合約轉賬”。1次“合約轉賬”包括2次讀2次寫操作，具體步驟如下：

·從A賬戶讀取余額（1次讀）；

·從B賬戶讀取余額（1次讀）；

·從A賬戶減去金額（1次寫）；

·從B賬戶增加金額（1次寫）。

因之前接觸過BTC，深深嘆服中本聰大神UTXO體系設置的精妙，但傳統(tǒng)應用系統(tǒng)往往還是依賴賬戶模型體系，因此選用一個經典的原子轉賬事務作為標準測試用例，并以該用例的執(zhí)行效率作為吞吐量指標的依據。AELF支持區(qū)塊鏈智能合約，上述原子事務須編寫為合約腳本部署至測試網。

進而，再定義一個基本的測試流程梗概：

該測試流程可作為一個典型的區(qū)塊鏈性能測評策略。以一次“合約轉賬”為一個基本業(yè)務執(zhí)行單元，編寫運行于區(qū)塊鏈平臺上的“合約腳本”程序，該程序能夠被區(qū)塊鏈系統(tǒng)各節(jié)點部署并執(zhí)行。實施測評前需依據特定的用例或隨機生成測試用例初始化測試數據，不同場景、不同輪次的測評實施須基于相同的測試數據以確保測試結果可信。測試數據作為交易申請相繼對主網發(fā)起激勵，對于AELF此類采用分布式并行化思想進行架構設計的項目，可采用多組數據并發(fā)激勵的形式以測試較高并發(fā)交易場景下區(qū)塊鏈系統(tǒng)的性能。測試過程中，可通過實時監(jiān)視或特定時間片監(jiān)視的方式判定測試用例的執(zhí)行情況，時間片可設置為出塊周期的N倍（N《=6，借鑒BTC主網6區(qū)塊確認的慣例）。

繼續(xù)定義不同的測試場景：

·場景I：單機場景，1業(yè)務處理節(jié)點+1業(yè)務數據集；

·場景II：集群-單機場景，N業(yè)務處理節(jié)點+1業(yè)務數據集；

·場景III：分布式集群場景，N業(yè)務處理節(jié)點+N業(yè)務數據集。

單機場景旨在驗證區(qū)塊鏈系統(tǒng)的獨立性能，因區(qū)塊鏈為分布式集群系統(tǒng)，針對單機場景測評驗證對于最終全網性能指標結論的意義不是很大，但有助于我們更好地定義集群測試的邊界。如單機測評的性能指標為P，進行集群測評時能夠以P為基礎通過節(jié)點/進程增長與性能指標增長之間的關系判定是否有必要進行更大規(guī)模的測評驗證。此外，在單機測試的過程中通過補充帶有網絡延遲的測試環(huán)境有助于對網絡環(huán)境影響因素進行基本的定量。

集群-單機場景旨在針對面向區(qū)塊鏈底層平臺所支撐的實際業(yè)務類型進行覆蓋性測試。區(qū)塊鏈技術本身是去中心化的，但區(qū)塊鏈系統(tǒng)所支撐的上層業(yè)務可能有中心化特征，因此需要進行多對一場景的模擬測評。該場景的設計針對數據I/O存在固定瓶頸的情況下對區(qū)塊鏈系統(tǒng)業(yè)務處理吞吐量進行定量測評。

分布式集群場景旨在針對處于P2P網絡拓撲中交易執(zhí)行處理與交易數據協同均需實現區(qū)塊鏈共識的業(yè)務場景進行覆蓋性測試。該場景為典型的區(qū)塊鏈系統(tǒng)場景，通過單機場景及集群-單機場景的測評，能夠輔助我們對該場景下的測試邊界及測試差異性因子進行綜合分析，確定測試實施的方式及被測部署環(huán)境的典型性，從而得到較為可靠的測評結論。

區(qū)塊鏈系統(tǒng)的運行有多個層次，區(qū)塊鏈程序可被部署至多臺服務器（Server），每臺服務器可運行多個進程級實例（Worker），對AELF而言，每個實例內可以配置多個并行化業(yè)務單元（Actor）。因此性能指標TPS受服務器、進程、業(yè)務單元的影響均需在測試中體現，最優(yōu)TPS測評結果應表現在一個適宜的服務器、進程、業(yè)務單元配置之下，在測試條件允許之內尋找這個最優(yōu)的配置也是本次測評的目的之一。

綜上，擬實現的測試驗證目的包括但不限于單服務節(jié)點運行狀態(tài)下的并發(fā)執(zhí)行能力及集群環(huán)境下的性能延展性。

測試搭建及部署

測試所選用的環(huán)境為標準云平臺虛擬機（包括AWS及阿里云），根據官方在社區(qū)內推薦的配置，采用了8vCPU+16G內存的組合，網絡帶寬10G，Redis版本4.0.10，Twemproxy版本0.4.1，基本與標準集群生產環(huán)境類似，后續(xù)隨測試網內容的增多配置可能有變化，在社區(qū)隨時可以得到項目技術團隊的解答。

8月8日補充：AELF官方Github已給出權威版測試搭建步驟，下文為筆者的搭建步驟。

對AELF測試網進行開發(fā)接入的核心是厘清Benchmark環(huán)境，通過與技術團隊的咨詢交流，下述為基本的搭建與部署執(zhí)行步驟。

克隆及編譯代碼：

·git clone https://github.com/AElfProject/AElf.git aelf

·cd aelf

·dotnet publish –configuration Release -o /temp/aelf

確認配置文件目錄：

·Mac/Linux： ~/.local/share/aelf/config

·Windows： C：UsersxxxxxAppDataLocalaelfconfig

配置數據集信息：

·將代碼中的aelf/config/database.json拷貝至配置文件目錄

·根據本機Redis安裝情況修改配置：

{

// 數據庫類型（內存：inmemory，Redis：redis，SSDB：ssdb）

“Type”： “redis”，

// 數據庫地址

“Host”： “l(fā)ocalhost”，

// 數據庫端口

“Port”： 6379

}

單機場景部署：

將代碼中的aelf/config/actor.json拷貝至配置文件目錄，并根據本機情況配置IsCluster、WorkerCount、Benchmark、ConcurrencyLevel：

{

// 是否為集群模式

“IsCluster”： false，

“HostName”： “127.0.0.1”，

“Port”： 0，

// 并行執(zhí)行 worker 的數量，建議與本機cpu 核數相同

“WorkerCount”： 8，

// 運行Benchmark模式

“Benchmark”：true，

// 最大并行分組級別，大于等于WorkerCount

“ConcurrencyLevel”： 16，

“Seeds”： ［

{

“HostName”： “127.0.0.1”，

“Port”： 32551

}

］，

“SingleHoconFile”： “single.hocon”，

“MasterHoconFile”： “master.hocon”，“WorkerHoconFile”： “worker.hocon”，

“ManagerHoconFile”： “manager.hocon”

}

運行Benchmark：

dotnet AElf.Benchmark.dll -n 8000 --grouprange 80 80 --repeattime 5

// -n 總事務數量 --grouprange 分組范圍 --repeattime 重復執(zhí)行次數

集群場景部署：

運行ConcurrencyManager：

dotnet AElf.Concurrency.Manager.dll --actor.host 192.168.100.1 --actor.port 4053

// --actor.host Manager的 IP 地址 --actor.port Manager的監(jiān)聽端口

將代碼中的aelf/config/actor.json拷貝至配置文件目錄，并根據本集群情況配置IsCluster、HostName、WorkerCount、Benchmark、ConcurrencyLevel、Seeds：

{

// 是否為集群模式

“IsCluster”： true，

// Worker的 ip 地址

“HostName”： “127.0.0.1”，

// Worker監(jiān)聽的端口

“Port”： 32551，

// 并行執(zhí)行 worker 的數量，建議與本機cpu 核數相同

“WorkerCount”： 8，

// 運行Benchmark模式

“Benchmark”：true，

// 最大并行分組級別，大于等于WorkerCount*Worker 的進程數

“ConcurrencyLevel”： 16，

// Manager的 ip、端口信息

“Seeds”： ［

{

“HostName”： “192.168.100.1”，

“Port”： 4053

}

］，

“SingleHoconFile”： “single.hocon”，

“MasterHoconFile”： “master.hocon”，

“WorkerHoconFile”： “worker.hocon”，

“ManagerHoconFile”： “manager.hocon”

}

運行ConcurrencyWorker：

dotnet AElf.Concurrency.Worker.dll --actor.port 32551

// --actor.port Worker的監(jiān)聽端口

如Worker收到Manager的歡迎信息則說明該Worker加入集群，后續(xù)節(jié)點擴容可依托此環(huán)境開展

運行Benchmark：

dotnet AElf.Benchmark.dll -n 8000 --grouprange 80 80 --repeattime 5

測試執(zhí)行與數據分析

該部分不再贅述具體的執(zhí)行過程，直接針對三種場景給出測試驗證的數據干貨。特別強調，本次測試的數據結果為筆者自行測試，環(huán)境和過程可能因人為操作誤差不是很嚴謹，具體性能指標以官方發(fā)布為準，好事者勿擾?。。?/p>

場景I 單機場景測試數據

通過上圖可以看出，當數據庫與業(yè)務單元分離部署時，網絡延遲會導致TPS指標下降，同等網絡延遲下TPS指標跟隨變化趨勢基本相同。

場景II 集群-單機場景測試數據

通過上兩圖可以看出當數據集服務為單例部署時，2進程16業(yè)務單元的部署模式較為理想。針對2進程16業(yè)務單元的部署模式又做了服務器擴容的補充分析，分析表明在數據集服務為單例時，服務器增長到5時性能達到瓶頸，TPS指標開始下滑。

場景III 分布式集群場景測試數據

上圖測試環(huán)境為8個Redis實例構建的集群，5個Twemproxy，每臺服務器連接不同的Twemproxy，TPS指標能夠隨擴容而增長至理想值附近。

其他相關測試參數：使用240000個交易，重復5次。

測試總結

通過上述測試驗證的執(zhí)行結果基本能夠看出隨著系統(tǒng)的擴容，吞吐量性能指標的增長是較為健康的，測試范圍之內預期最優(yōu)指標約為1.3w~1.5w tps。此外，在每一組特定的部署模式下，能夠通過系統(tǒng)調優(yōu)獲得平均約10%~15%的性能提升，吞吐量性能曲線的極值點符合較為合理，符合快升緩降的泊松分布。目前小拓撲集群下的環(huán)境搭建驗證基本能夠滿足中小型業(yè)務系統(tǒng)的吞吐量需求，初步可應用于傳統(tǒng)應用系統(tǒng)的優(yōu)化重構——當然，只用區(qū)塊鏈技術做分布式數據庫和通信組件難免有點大材小用，后續(xù)還需關注多級側鏈體系的測試情況，進一步融和分布式業(yè)務模型。

簡單的測試驗證后，同為搬磚碼農的筆者也有一些建議給AELF技術團隊：

當Transaction數量級較大，且后續(xù)引入側鏈的結構較復雜時，目前的分組策略耗時可能會有比較顯著的提升，如10w級事務分1k級處理單元組時，可能的分組時間會達到800ms~1000ms，分組策略在后續(xù)多級側鏈體系下有待進一步優(yōu)化；

系統(tǒng)目前配置的Round-Robin-Group路由策略在生產環(huán)境下并非最優(yōu)，路由能力可通過配置調優(yōu)的方式得到進一步提升；

并行化事務處理過程中建議增加健康狀態(tài)監(jiān)控機制，如MailBox，以方便運維、開發(fā)團隊了解執(zhí)行過程及定位問題，否則復雜關聯事務的死鎖可能會導致無法預見的系統(tǒng)失效。

刨除掉上述三點，該測試網目前的表現可圈可點，后續(xù)進展值得期待。