區(qū)塊鏈性能評(píng)測(cè)的方案分享

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

應(yīng)用系統(tǒng)性能提升的關(guān)鍵在于運(yùn)維端的接入管理模型（AAA，認(rèn)證Authentication、授權(quán)Authorization、計(jì)費(fèi)Accounting）及業(yè)務(wù)端的并發(fā)（Concurrency）/吞吐量（Throughput）模型。區(qū)塊鏈?zhǔn)堑湫偷摹斑\(yùn)維友好型”系統(tǒng)，天然的自我治理能力極大程度上優(yōu)化了接入管理模型，但現(xiàn)有區(qū)塊鏈系統(tǒng)的并發(fā)/吞吐量模型指標(biāo)卻飽受詬病。無論是BTC的7tps，還是ETH的40tps在傳統(tǒng)業(yè)務(wù)系統(tǒng)動(dòng)輒萬級(jí)甚至十萬級(jí)tps面前都難以抬頭。

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

·聚焦底層基礎(chǔ)設(shè)施，項(xiàng)目自身行業(yè)或領(lǐng)域特征不明顯，易引入本行業(yè)業(yè)務(wù)；

·能夠?qū)崿F(xiàn)微服務(wù)級(jí)部署，擴(kuò)容友好，易遷移部署；

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

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

測(cè)試設(shè)計(jì)

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

Transaction，傳統(tǒng)IT人習(xí)慣叫“事務(wù)”，區(qū)塊鏈圈的人通常叫“交易”，可能是BTC白皮書翻譯傳承下來的吧。軟件測(cè)評(píng)應(yīng)充分考慮軟件質(zhì)量體系的要求，同理，對(duì)于一個(gè)區(qū)塊鏈底層架構(gòu)而言，模擬價(jià)值傳輸壓力的交易激勵(lì)能夠作為區(qū)塊鏈底層基礎(chǔ)設(shè)施tps指標(biāo)的驗(yàn)證形式。

據(jù)此，先定義一個(gè)原子事務(wù)作為本次測(cè)試驗(yàn)證的基本測(cè)試用例——“合約轉(zhuǎn)賬”。1次“合約轉(zhuǎn)賬”包括2次讀2次寫操作，具體步驟如下：

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

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

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

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

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

進(jìn)而，再定義一個(gè)基本的測(cè)試流程梗概：

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

繼續(xù)定義不同的測(cè)試場(chǎng)景：

·場(chǎng)景I：?jiǎn)螜C(jī)場(chǎng)景，1業(yè)務(wù)處理節(jié)點(diǎn)+1業(yè)務(wù)數(shù)據(jù)集；

·場(chǎng)景II：集群-單機(jī)場(chǎng)景，N業(yè)務(wù)處理節(jié)點(diǎn)+1業(yè)務(wù)數(shù)據(jù)集；

·場(chǎng)景III：分布式集群場(chǎng)景，N業(yè)務(wù)處理節(jié)點(diǎn)+N業(yè)務(wù)數(shù)據(jù)集。

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

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

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

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

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

測(cè)試搭建及部署

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

8月8日補(bǔ)充：AELF官方Github已給出權(quán)威版測(cè)試搭建步驟，下文為筆者的搭建步驟。

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

克隆及編譯代碼：

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

·cd aelf

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

確認(rèn)配置文件目錄：

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

·Windows： C：\Users\xxxxx\AppData\Local\aelf\config

配置數(shù)據(jù)集信息：

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

·根據(jù)本機(jī)Redis安裝情況修改配置：

{

// 數(shù)據(jù)庫(kù)類型（內(nèi)存：inmemory，Redis：redis，SSDB：ssdb）

“Type”： “redis”，

// 數(shù)據(jù)庫(kù)地址

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

// 數(shù)據(jù)庫(kù)端口

“Port”： 6379

}

單機(jī)場(chǎng)景部署：

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

{

// 是否為集群模式

“IsCluster”： false，

“HostName”： “127.0.0.1”，

“Port”： 0，

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

“WorkerCount”： 8，

// 運(yùn)行Benchmark模式

“Benchmark”：true，

// 最大并行分組級(jí)別，大于等于WorkerCount

“ConcurrencyLevel”： 16，

“Seeds”： ［

{

“HostName”： “127.0.0.1”，

“Port”： 32551

}

］，

“SingleHoconFile”： “single.hocon”，

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

“ManagerHoconFile”： “manager.hocon”

}

運(yùn)行Benchmark：

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

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

集群場(chǎng)景部署：

運(yùn)行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拷貝至配置文件目錄，并根據(jù)本集群情況配置IsCluster、HostName、WorkerCount、Benchmark、ConcurrencyLevel、Seeds：

{

// 是否為集群模式

“IsCluster”： true，

// Worker的 ip 地址

“HostName”： “127.0.0.1”，

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

“Port”： 32551，

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

“WorkerCount”： 8，

// 運(yùn)行Benchmark模式

“Benchmark”：true，

// 最大并行分組級(jí)別，大于等于WorkerCount*Worker 的進(jìn)程數(shù)

“ConcurrencyLevel”： 16，

// Manager的 ip、端口信息

“Seeds”： ［

{

“HostName”： “192.168.100.1”，

“Port”： 4053

}

］，

“SingleHoconFile”： “single.hocon”，

“MasterHoconFile”： “master.hocon”，

“WorkerHoconFile”： “worker.hocon”，

“ManagerHoconFile”： “manager.hocon”

}

運(yùn)行ConcurrencyWorker：

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

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

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

運(yùn)行Benchmark：

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

測(cè)試執(zhí)行與數(shù)據(jù)分析

該部分不再贅述具體的執(zhí)行過程，直接針對(duì)三種場(chǎng)景給出測(cè)試驗(yàn)證的數(shù)據(jù)干貨。特別強(qiáng)調(diào)，本次測(cè)試的數(shù)據(jù)結(jié)果為筆者自行測(cè)試，環(huán)境和過程可能因人為操作誤差不是很嚴(yán)謹(jǐn)，具體性能指標(biāo)以官方發(fā)布為準(zhǔn)，好事者勿擾?。?！

場(chǎng)景I 單機(jī)場(chǎng)景測(cè)試數(shù)據(jù)

通過上圖可以看出，當(dāng)數(shù)據(jù)庫(kù)與業(yè)務(wù)單元分離部署時(shí)，網(wǎng)絡(luò)延遲會(huì)導(dǎo)致TPS指標(biāo)下降，同等網(wǎng)絡(luò)延遲下TPS指標(biāo)跟隨變化趨勢(shì)基本相同。

場(chǎng)景II 集群-單機(jī)場(chǎng)景測(cè)試數(shù)據(jù)

通過上兩圖可以看出當(dāng)數(shù)據(jù)集服務(wù)為單例部署時(shí)，2進(jìn)程16業(yè)務(wù)單元的部署模式較為理想。針對(duì)2進(jìn)程16業(yè)務(wù)單元的部署模式又做了服務(wù)器擴(kuò)容的補(bǔ)充分析，分析表明在數(shù)據(jù)集服務(wù)為單例時(shí)，服務(wù)器增長(zhǎng)到5時(shí)性能達(dá)到瓶頸，TPS指標(biāo)開始下滑。

場(chǎng)景III 分布式集群場(chǎng)景測(cè)試數(shù)據(jù)

上圖測(cè)試環(huán)境為8個(gè)Redis實(shí)例構(gòu)建的集群，5個(gè)Twemproxy，每臺(tái)服務(wù)器連接不同的Twemproxy，TPS指標(biāo)能夠隨擴(kuò)容而增長(zhǎng)至理想值附近。

其他相關(guān)測(cè)試參數(shù)：使用240000個(gè)交易，重復(fù)5次。

測(cè)試總結(jié)

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

簡(jiǎn)單的測(cè)試驗(yàn)證后，同為搬磚碼農(nóng)的筆者也有一些建議給AELF技術(shù)團(tuán)隊(duì)：

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

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

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

刨除掉上述三點(diǎn)，該測(cè)試網(wǎng)目前的表現(xiàn)可圈可點(diǎn)，后續(xù)進(jìn)展值得期待。