李 政，楊 丹，董金德，李 寧，畢靖文

(1.甘肅省交通科學(xué)研究院集團(tuán)有限公司，蘭州 730000；2.甘肅紫光智能交通與控制技術(shù)有限公司，蘭州 730000；3.甘肅省公路交通建設(shè)集團(tuán)有限公司 康略項(xiàng)目分公司，甘肅 隴南 746500)

0 引言

隨著區(qū)塊鏈技術(shù)的發(fā)展應(yīng)用，眾多行業(yè)和領(lǐng)域的使用者對(duì)區(qū)塊鏈平臺(tái)的服務(wù)質(zhì)量和性能要求也提出更高的使用要求[1-2]。然而，區(qū)塊鏈平臺(tái)應(yīng)用性能是否滿足實(shí)際應(yīng)用需求時(shí)長(zhǎng)沒(méi)有引起足夠的重視[3]。因此，研究區(qū)塊鏈應(yīng)用平臺(tái)的性能問(wèn)題具有非常重要的現(xiàn)實(shí)意義。

近幾年，國(guó)內(nèi)外學(xué)者在區(qū)塊鏈性能測(cè)試及評(píng)價(jià)方面進(jìn)行了積極的探索研究。王銳[4]設(shè)計(jì)工具對(duì)4種主流區(qū)塊鏈系統(tǒng)進(jìn)行了綜合測(cè)試分析，提出了優(yōu)化方案。王旭等[5]建立了區(qū)塊鏈性能數(shù)學(xué)模型，得到了影響區(qū)塊鏈性能的主要因素。李雪飛等[6]針對(duì)單用戶單通信道的分布式Fabric raft區(qū)塊鏈網(wǎng)絡(luò)性能提出了一個(gè)區(qū)塊生成速率的性能指標(biāo)。劉亞茹等[7]基于用戶視角提出了一種區(qū)塊鏈系統(tǒng)綜合評(píng)價(jià)方法，并將其應(yīng)用于比特幣平臺(tái)的評(píng)價(jià)。朱立等[8]針對(duì)上海證劵競(jìng)價(jià)交易的實(shí)際業(yè)務(wù)場(chǎng)景，研究分析了節(jié)點(diǎn)數(shù)、區(qū)塊大小、打包時(shí)間以及網(wǎng)絡(luò)帶寬等因素對(duì)區(qū)塊鏈性能的影響。N.Weston等[9]探索了區(qū)塊鏈技術(shù)在移動(dòng)網(wǎng)絡(luò)環(huán)境中的性能。C.X.Fan等[10]對(duì)現(xiàn)有區(qū)塊鏈性能評(píng)估方法進(jìn)行了研究分析，提出有效性和效率來(lái)優(yōu)化區(qū)塊鏈系統(tǒng)性能。P.Zheng等[11]提出了針對(duì)區(qū)塊鏈系統(tǒng)的實(shí)時(shí)性能監(jiān)控框架。M.Kuzlu等[12]從吞吐量、延遲和可擴(kuò)展性3個(gè)方面分析了區(qū)塊鏈網(wǎng)絡(luò)工作負(fù)載對(duì)Hyperledger Fabric區(qū)塊鏈性能的影響。Dinh等[13]提出了BlockBench區(qū)塊鏈測(cè)評(píng)框架，并對(duì)Ethrerum、Parity和Hyperledger Fabric區(qū)塊鏈從吞吐量、交易延遲、容錯(cuò)性等方面展開(kāi)了綜合評(píng)估，幫助開(kāi)發(fā)人員識(shí)別瓶頸并進(jìn)行改進(jìn)。

但是，無(wú)可否認(rèn)區(qū)塊鏈技術(shù)發(fā)展應(yīng)用至今，在除金融領(lǐng)域的其他行業(yè)成功案例并不多，以上參考文獻(xiàn)研究都是基于主流區(qū)塊鏈自身性能的代表，結(jié)合具體行業(yè)應(yīng)用實(shí)際需求測(cè)試分析不足、針對(duì)性不強(qiáng)、可借鑒方法體系不明確。不同應(yīng)用場(chǎng)景在節(jié)點(diǎn)數(shù)量、區(qū)塊大小、交易時(shí)間等方面的設(shè)置及要求各異，因此，本文主要研究面向公路工程領(lǐng)域交通產(chǎn)品質(zhì)量控制的區(qū)塊鏈應(yīng)用平臺(tái)的性能測(cè)試與影響量化分析，旨在建立一種在具體業(yè)務(wù)場(chǎng)景下的區(qū)塊鏈應(yīng)用平臺(tái)性能泛在、可移植借鑒的測(cè)試架構(gòu)、環(huán)境和方法體系，以實(shí)現(xiàn)對(duì)區(qū)塊鏈平臺(tái)開(kāi)發(fā)應(yīng)用性能優(yōu)化提供相關(guān)理論支撐和參考。

1 Hyperledger Fabric區(qū)塊鏈及交通產(chǎn)品質(zhì)量控制系統(tǒng)

1.1 Hyperledger Fabric區(qū)塊鏈

國(guó)家戰(zhàn)略上明確提出要把區(qū)塊鏈作為核心技術(shù)自主創(chuàng)新的重要突破口，隨著《交通強(qiáng)國(guó)建設(shè)綱要》的發(fā)布，為區(qū)塊鏈、大數(shù)據(jù)、互聯(lián)網(wǎng)、人工智能、超級(jí)計(jì)算等新技術(shù)與交通行業(yè)深度融合應(yīng)用提供了契機(jī)[14～15]。中華人民共和國(guó)國(guó)民經(jīng)濟(jì)和社會(huì)發(fā)展第十四個(gè)五年規(guī)劃和2035年遠(yuǎn)景目標(biāo)綱要中也指出，要重點(diǎn)發(fā)展聯(lián)盟鏈服務(wù)平臺(tái)、供應(yīng)鏈管理、政務(wù)服務(wù)等領(lǐng)域應(yīng)用方案[16]。

Hyperledger Fabric是開(kāi)源企業(yè)級(jí)聯(lián)盟鏈，支持靈活信任假設(shè)，可以通過(guò)多種方式配置[17]。因此適用于政府機(jī)構(gòu)、企業(yè)等組織結(jié)構(gòu)和節(jié)點(diǎn)的加入、聯(lián)盟成員之間交易需要授權(quán)才能進(jìn)行的場(chǎng)景，也能結(jié)合實(shí)際業(yè)務(wù)場(chǎng)景發(fā)揮出區(qū)塊鏈的可信安全、高可用、高性能、可編程、隱私保護(hù)上的優(yōu)勢(shì)[18]。

1.2 基于區(qū)塊鏈的交通產(chǎn)品質(zhì)量控制系統(tǒng)

1.2.1 系統(tǒng)架構(gòu)

基于Hyperledger Fabric區(qū)塊鏈的交通產(chǎn)品質(zhì)量控制應(yīng)用系統(tǒng)采用的技術(shù)架構(gòu)主要分為物理層、區(qū)塊鏈層、應(yīng)用服務(wù)層、前端以及全鏈路監(jiān)控層5個(gè)部分，各部分的詳細(xì)說(shuō)明情況描述如下。

1)物理層：主要依賴于docker swarm 容器編排集群，方便進(jìn)行高效的管理資源，無(wú)縫的進(jìn)行服務(wù)擴(kuò)展，實(shí)現(xiàn)整個(gè)架構(gòu)的高可用性。

2)區(qū)塊鏈層：基于超級(jí)賬本Hyperledger Fabric、主要orderer共識(shí)排序節(jié)點(diǎn)、peer對(duì)等節(jié)點(diǎn)、世界狀態(tài)庫(kù)couchdb、ca節(jié)點(diǎn)以及ca節(jié)點(diǎn)庫(kù)postgresql組成，是整個(gè)系統(tǒng)的核心。目前系統(tǒng)支持的orderer共識(shí)有kafka共識(shí)和raft共識(shí)，用來(lái)保證orderer排序節(jié)點(diǎn)的高可用性，防止因orderer意外宕機(jī)而造成無(wú)法排序出塊而導(dǎo)致整個(gè)區(qū)塊鏈網(wǎng)絡(luò)的癱瘓。Peer對(duì)等節(jié)點(diǎn)則是網(wǎng)絡(luò)中的平等的儲(chǔ)存賬本的數(shù)據(jù)節(jié)點(diǎn)，節(jié)點(diǎn)之間使用gossip協(xié)議進(jìn)行數(shù)據(jù)同步，所有的區(qū)塊鏈數(shù)據(jù)都存在于此節(jié)點(diǎn)。Ca節(jié)點(diǎn)則用于配置管理身份和證書以及協(xié)調(diào)組織關(guān)系。Ca節(jié)點(diǎn)產(chǎn)生的數(shù)據(jù)儲(chǔ)存于postgresql數(shù)據(jù)庫(kù)之上。

3)應(yīng)用服務(wù)層：使用單體微服務(wù)的架構(gòu)方式，系統(tǒng)數(shù)據(jù)庫(kù)層使用MySQL一主兩從的方式保證MySQL的高可用性以及postgresql數(shù)據(jù)庫(kù)儲(chǔ)存部分區(qū)塊鏈同步下來(lái)的區(qū)塊、交易、合約、通道信息等，持久化層使用mybatis、mybatis plus等，緩存使用redis哨兵模式保證緩存的高可用性，權(quán)限使用oauth2來(lái)實(shí)現(xiàn)靈活配置的效果，外部接口依賴于RestTemplate。

4)前端：主要分為web端與小程序端，web端使用基于vue的組件化的開(kāi)發(fā)方式，配合nodejs、webpack、es6、axios、echarts等其他組件實(shí)現(xiàn)高效開(kāi)發(fā)，小程序端使用基于vue組件的mp-vue的方式開(kāi)發(fā)，既可以保證性能又可減少學(xué)習(xí)維護(hù)成本。

5)全鏈路監(jiān)控層：主要是用來(lái)監(jiān)控由下至上整個(gè)系統(tǒng)生態(tài)的健康性而設(shè)立的，在異常之前做到預(yù)警，發(fā)送預(yù)警信息至維護(hù)人員釘釘達(dá)到提前解決系統(tǒng)故障的效果，即負(fù)責(zé)其他四層的后勤保障，目前主要監(jiān)控了docker swarm容器主機(jī)的CPU、內(nèi)存、磁盤大小、網(wǎng)絡(luò)信息等主機(jī)信息，區(qū)塊鏈網(wǎng)絡(luò)節(jié)點(diǎn)的各節(jié)點(diǎn)的健康信息，redis集群的健康信息，postgresql&MySQL&couchdb數(shù)據(jù)庫(kù)的健康信息以及各節(jié)點(diǎn)各服務(wù)的日志信息等，實(shí)現(xiàn)簡(jiǎn)易運(yùn)維，減少運(yùn)維人員的壓力。

基于Hyperledger Fabric區(qū)塊鏈的交通產(chǎn)品質(zhì)量控制應(yīng)用平臺(tái)是甘肅省交通強(qiáng)國(guó)建設(shè)試點(diǎn)主要技術(shù)成果之一。系統(tǒng)明確了交通產(chǎn)品質(zhì)量控制中各節(jié)點(diǎn)單位工作執(zhí)行的架構(gòu)層次及之間的相互邏輯關(guān)系，以實(shí)現(xiàn)交通產(chǎn)品質(zhì)量控制數(shù)據(jù)共享[19～20]，系統(tǒng)服務(wù)架構(gòu)設(shè)置如圖1所示。借助Fabric需要接入?yún)^(qū)塊鏈的第三方不需要自己搭建區(qū)塊鏈節(jié)點(diǎn)網(wǎng)絡(luò)來(lái)實(shí)現(xiàn)區(qū)塊鏈客戶端，便可以直接在平臺(tái)實(shí)現(xiàn)一鍵建鏈，省去建立通道，節(jié)點(diǎn)加入通道等一系列操作，提供智能合約的編寫，安裝，實(shí)例化，升級(jí)等業(yè)務(wù)的一鍵式發(fā)布，簡(jiǎn)潔運(yùn)維等。

圖1 基于區(qū)塊鏈的交通產(chǎn)品質(zhì)量控制體系架構(gòu)

1.2.2 系統(tǒng)業(yè)務(wù)邏輯

按照《公路水運(yùn)行業(yè)產(chǎn)品質(zhì)量監(jiān)督抽查管理辦法(交科技規(guī)[2020]2號(hào))》的規(guī)定，一個(gè)完整的交通產(chǎn)品質(zhì)量監(jiān)督檢測(cè)工作流程包含產(chǎn)品信息備案、抽樣單信息、樣品封樣、運(yùn)輸、樣品拆樣、試驗(yàn)結(jié)果確認(rèn)和異議處理等重要環(huán)節(jié)[21]。通過(guò)總結(jié)和分析實(shí)際工程建設(shè)項(xiàng)目在原材料產(chǎn)品質(zhì)量管控中存在的具體問(wèn)題，表明這些環(huán)節(jié)是易發(fā)質(zhì)量安全的風(fēng)險(xiǎn)點(diǎn)和各級(jí)節(jié)點(diǎn)單位責(zé)任不清、推諉扯皮等現(xiàn)象的來(lái)源處，給質(zhì)量監(jiān)督及檢驗(yàn)單位的公信力造成不良影響，這也是本論文依托基金項(xiàng)目采用區(qū)塊鏈技術(shù)去急需解決的問(wèn)題所在。

在以上重要工作環(huán)節(jié)上，都會(huì)有不同節(jié)點(diǎn)單位主導(dǎo)發(fā)起相關(guān)應(yīng)用工作流程。比如在交通產(chǎn)品質(zhì)量檢測(cè)現(xiàn)場(chǎng)抽樣、樣品封樣、樣品拆樣的環(huán)節(jié)均是由檢測(cè)單位負(fù)責(zé)發(fā)起，施工單位、監(jiān)理單位、建設(shè)單位和產(chǎn)品廠家參與相關(guān)環(huán)節(jié)的審核確認(rèn)及背書簽名，各節(jié)點(diǎn)單位之間的事務(wù)關(guān)系如圖2所示。這其中涉及到交通產(chǎn)品質(zhì)量數(shù)據(jù)的基本屬性信息、相關(guān)過(guò)程照片和視頻等體現(xiàn)各方工作職責(zé)的“證據(jù)”信息，一個(gè)工作環(huán)節(jié)結(jié)束以后的業(yè)務(wù)數(shù)據(jù)通過(guò)區(qū)塊鏈外部接口API與區(qū)塊鏈網(wǎng)絡(luò)交互，上鏈存證，即可實(shí)現(xiàn)交通產(chǎn)品質(zhì)量控制重要數(shù)據(jù)信息的不可篡改和可證可溯，基于區(qū)塊鏈的交通產(chǎn)品質(zhì)量控制檢測(cè)體系全面建立。

圖2 產(chǎn)品抽檢、封樣、拆樣環(huán)節(jié)事務(wù)關(guān)系圖

基于Hyperledger Fabric區(qū)塊鏈的交通產(chǎn)品質(zhì)量控制系統(tǒng)上鏈信息數(shù)據(jù)結(jié)構(gòu)如表1所示。

表1 上鏈信息數(shù)據(jù)結(jié)構(gòu)

2 性能測(cè)試過(guò)程模型

性能測(cè)試過(guò)程模型將整個(gè)過(guò)程分割為6個(gè)階段，如圖3所示。

圖3 性能測(cè)試過(guò)程模型

1)制定性能測(cè)試計(jì)劃。進(jìn)行性能測(cè)試之前，測(cè)試人員需要制定一個(gè)明確的性能測(cè)試計(jì)劃，詳細(xì)說(shuō)明如何進(jìn)行性能測(cè)試，為后續(xù)更好地執(zhí)行性能測(cè)試提供參考。

2)性能測(cè)試需求分析。性能需求分析階段，需要對(duì)被測(cè)系統(tǒng)進(jìn)行分析，熟悉被測(cè)系統(tǒng)資源，明確性能測(cè)試內(nèi)容，量化、細(xì)化性能需求，即確定性能測(cè)試指標(biāo)和測(cè)試場(chǎng)景。

3)性能測(cè)試設(shè)計(jì)。性能測(cè)試設(shè)計(jì)階段，需要完成測(cè)試環(huán)境設(shè)計(jì)和測(cè)試數(shù)據(jù)設(shè)計(jì)。

4)性能測(cè)試執(zhí)行。性能測(cè)試執(zhí)行階段，需要搭建測(cè)試環(huán)境，按照測(cè)試場(chǎng)景執(zhí)行性能測(cè)試和測(cè)試結(jié)果記錄，測(cè)試執(zhí)行過(guò)程中依據(jù)測(cè)試條件不斷改變參數(shù)值，得到測(cè)試結(jié)果，具體流程如圖4所示。

圖4 性能測(cè)試執(zhí)行過(guò)程

5)性能測(cè)試結(jié)果分析。性能測(cè)試結(jié)果分析階段，需要發(fā)現(xiàn)性能瓶頸并定位分析，為后續(xù)回歸測(cè)試提供參考。

6)性能調(diào)優(yōu)。第一輪性能測(cè)試結(jié)束且測(cè)試結(jié)果不理想的條件下，可根據(jù)測(cè)試結(jié)果進(jìn)行性能優(yōu)化調(diào)整，使系統(tǒng)各項(xiàng)資源使用趨向合理和平衡。

3 性能測(cè)試架構(gòu)和環(huán)境構(gòu)建

3.1 測(cè)試指標(biāo)選擇

性能指標(biāo)是評(píng)估系統(tǒng)性能的主要依據(jù)，全面性、針對(duì)性和可擴(kuò)展應(yīng)用性要強(qiáng)。結(jié)合本交通產(chǎn)品質(zhì)量控制具體場(chǎng)景和區(qū)塊鏈平臺(tái)的服務(wù)需求，確定如下性能指標(biāo)。

1)吞吐率TPS(transactions per second)，指在一定時(shí)間段內(nèi)完成有效交易的速率，用來(lái)衡量區(qū)塊鏈系統(tǒng)對(duì)交易的處理性能，TPS越高表示系統(tǒng)交易處理能力越強(qiáng)。計(jì)算公式如式(1)所示：

(1)

其中：m表示t時(shí)間段內(nèi)完成的總交易數(shù)，t表示完成交易的總耗時(shí)。

2)讀吞吐量RPS(read throughput)，指在一定時(shí)間段內(nèi)，每秒完成讀取操作的數(shù)量。計(jì)算公式如式(2)所示：

(2)

其中：n表示t時(shí)間段內(nèi)完成的總讀取操作數(shù)量，t表示完成讀取操作的總耗時(shí)。

3)寫吞吐量WPS(write throughput)，指在一定時(shí)間段內(nèi)，每秒完成上鏈操作的數(shù)量。計(jì)算公式如式(3)所示：

(3)

其中：n表示t時(shí)間段內(nèi)完成的總上鏈操作數(shù)量，t表示完成上鏈操作的總耗時(shí)。

4)響應(yīng)時(shí)間RT(response time)，指一個(gè)交易從提交請(qǐng)求開(kāi)始到接收交易完成響應(yīng)所花費(fèi)的時(shí)間。計(jì)算公式如式(4)所示：

RT=t1-t0

(4)

其中：t0表示交易開(kāi)始的時(shí)間，t1表示所有交易完成的時(shí)間。

5)區(qū)塊生成速率BPS(block per second)，指一定時(shí)間段內(nèi)，區(qū)塊鏈系統(tǒng)每秒產(chǎn)生的區(qū)塊個(gè)數(shù)。計(jì)算公式如式(5)所示：

(5)

其中：a表示t0到t1時(shí)間段內(nèi)產(chǎn)生的區(qū)塊個(gè)數(shù)，t0表示交易開(kāi)始的時(shí)間，t1表示所有交易完成時(shí)間。

6)交易延遲TL(transaction latency)，指一個(gè)交易從提交到可以在網(wǎng)絡(luò)中使用所需要的時(shí)間。計(jì)算公式如式(6)所示：

TL=t1-t0

(6)

其中：t0表示交易提交的時(shí)間，t1表示交易可以在網(wǎng)絡(luò)中使用的時(shí)間。

3.2 性能測(cè)試架構(gòu)設(shè)計(jì)

面向公路交通產(chǎn)品質(zhì)量控制這一典型場(chǎng)景應(yīng)用的Hyperledger Fabric區(qū)塊鏈平臺(tái)，論文通過(guò)在平臺(tái)所連接的區(qū)塊鏈節(jié)點(diǎn)上進(jìn)行交易來(lái)記錄交通產(chǎn)品質(zhì)量數(shù)據(jù)的請(qǐng)求、訪問(wèn)以及存儲(chǔ)等操作。同時(shí)，為了保證實(shí)際應(yīng)用場(chǎng)景業(yè)務(wù)的正常運(yùn)行，需要明確平臺(tái)每項(xiàng)交易的有效性，現(xiàn)有的性能測(cè)試方法及工具在單個(gè)交易有效性的細(xì)粒度追蹤方面具有一定的局限性，為此，本文采用了如圖5所示的測(cè)試架構(gòu)，包含客戶端、觀察端以及區(qū)塊鏈網(wǎng)絡(luò)三部分。

圖5 性能測(cè)試架構(gòu)

客戶端代表用戶向區(qū)塊鏈網(wǎng)絡(luò)提交交易的節(jié)點(diǎn)，可以將工作引入系統(tǒng)或調(diào)用系統(tǒng)行為的實(shí)體。

觀察端是從區(qū)塊鏈網(wǎng)絡(luò)接收通知或查詢區(qū)塊鏈網(wǎng)絡(luò)提交事務(wù)狀態(tài)的節(jié)點(diǎn)，但觀察端不能提交任何新事務(wù)。

區(qū)塊鏈網(wǎng)絡(luò)用于設(shè)置運(yùn)行維護(hù)區(qū)塊鏈所需的硬件、軟件以及網(wǎng)絡(luò)等配置信息。

客戶端、觀察端以及區(qū)塊鏈網(wǎng)絡(luò)的工作內(nèi)容及執(zhí)行流程如下。

Step 1：對(duì)產(chǎn)生的交易提案進(jìn)行簽名；

Step 2：通過(guò)gRPC將簽名提案發(fā)至背書節(jié)點(diǎn)；

Step 3：取出背書后的結(jié)果，并封裝成特定的Envelope數(shù)據(jù)格式；

Step 4：把封裝好的Envelope數(shù)據(jù)通過(guò)gRPC廣播到排序節(jié)點(diǎn)；

Step 5：排序節(jié)點(diǎn)生成區(qū)塊，然后將區(qū)塊廣播到 Peer節(jié)點(diǎn)，Peer節(jié)點(diǎn)接收區(qū)塊，經(jīng)過(guò)驗(yàn)證后保存到本地賬本，最后向其他節(jié)點(diǎn)廣播已提交區(qū)塊；

Step 6：接收到Peer節(jié)點(diǎn)廣播的區(qū)塊之后，計(jì)算區(qū)塊中交易數(shù)量以及總耗時(shí)，當(dāng)發(fā)送所有預(yù)設(shè)的交易數(shù)量時(shí)結(jié)束運(yùn)行，并根據(jù)總耗時(shí)計(jì)算TPS。

3.3 性能測(cè)試環(huán)境搭建

良好的測(cè)試環(huán)境既是執(zhí)行系統(tǒng)測(cè)試的前提，也是順利完成測(cè)試的保證，確保其與真實(shí)環(huán)境一致或存在可比性。本文的測(cè)試環(huán)境如表2所示。

表2 測(cè)試環(huán)境配置

4 Fabric性能測(cè)試及工程案例分析

4.1 基準(zhǔn)性能測(cè)試

根據(jù)交通產(chǎn)品質(zhì)量控制系統(tǒng)區(qū)塊鏈平臺(tái)的開(kāi)發(fā)運(yùn)行機(jī)制，論文首先進(jìn)行基準(zhǔn)性能測(cè)試，計(jì)算吞吐率(TPS)、讀吞吐量(RPS)、寫吞吐量(WPS)、響應(yīng)時(shí)間(RT)、區(qū)塊生成速率(BPS)以及交易延遲(TL)這6個(gè)指標(biāo)的值。實(shí)驗(yàn)相關(guān)參數(shù)配置如表3所示。實(shí)驗(yàn)結(jié)果統(tǒng)計(jì)如表4所示。

表3 Fabric相關(guān)配置

表4 基準(zhǔn)實(shí)驗(yàn)結(jié)果

Node：指節(jié)點(diǎn)數(shù)，它是區(qū)塊鏈網(wǎng)絡(luò)最基本的組成模塊，用于檢查一個(gè)事務(wù)是否有效。

Batch Timeout：指出塊時(shí)間，即最長(zhǎng)出塊間隔，用來(lái)定時(shí)檢測(cè)緩存中是否存在還未出塊的數(shù)據(jù)，只有緩存中存在數(shù)據(jù)才會(huì)出塊，否則無(wú)法出塊。

Max Message Count：指區(qū)塊最大交易條數(shù)，表示一個(gè)區(qū)塊中能夠包含的最大交易條數(shù)，它用于判斷新出現(xiàn)的交易以及緩存里的交易數(shù)量是否達(dá)到這個(gè)數(shù)量，如果達(dá)到了這個(gè)條件，則會(huì)立即出塊。

Absolute Max Bytes：指區(qū)塊最大字節(jié)數(shù)，所有情況下區(qū)塊的最大允許字節(jié)數(shù)，如果一個(gè)交易數(shù)據(jù)本身就超過(guò)了這個(gè)大小，則會(huì)被直接退回，沒(méi)有機(jī)會(huì)參與打包。

Preferred Max Bytes：指區(qū)塊首選字節(jié)數(shù)，正常情況下一個(gè)區(qū)塊中的交易數(shù)據(jù)大小會(huì)小于此參數(shù)。

Num_of_conn：指總連接數(shù)。

影響Fabric區(qū)塊鏈平臺(tái)交易性能的因素有許多，論文根據(jù)交通產(chǎn)品質(zhì)量控制數(shù)據(jù)交易、運(yùn)行機(jī)制以及實(shí)際應(yīng)用過(guò)程，選取了節(jié)點(diǎn)數(shù)、出塊時(shí)間、區(qū)塊最大交易條數(shù)、區(qū)塊最大字節(jié)數(shù)、區(qū)塊首選字節(jié)數(shù)以及總連接數(shù)作為區(qū)塊鏈平臺(tái)性能影響主要因素進(jìn)行實(shí)驗(yàn)評(píng)估分析。

4.2 節(jié)點(diǎn)數(shù)

與基準(zhǔn)測(cè)試相比，只改變節(jié)點(diǎn)數(shù)。分別測(cè)試節(jié)點(diǎn)數(shù)為1、2、3、4、5、6、7、8時(shí)的性能，測(cè)試結(jié)果如圖6所示。

圖6 各指標(biāo)隨著節(jié)點(diǎn)數(shù)的變化

根據(jù)圖中的曲線變化得出，隨著節(jié)點(diǎn)數(shù)的增加，吞吐率、讀吞吐量、寫吞吐量以及區(qū)塊生成速率的值隨之下降，而響應(yīng)時(shí)間和交易延遲的值隨之上升。當(dāng)節(jié)點(diǎn)數(shù)為1時(shí)，吞吐率、讀吞吐量、寫吞吐量以及區(qū)塊生成速率的值最高，響應(yīng)時(shí)間和交易延遲值最低，說(shuō)明此時(shí)平臺(tái)性能達(dá)到最優(yōu)狀態(tài)。該測(cè)試結(jié)果符合聯(lián)盟鏈節(jié)點(diǎn)數(shù)少的性能特點(diǎn)。

4.3 出塊時(shí)間

與基準(zhǔn)測(cè)試相比，只改變出塊時(shí)間。分別測(cè)試出塊時(shí)間為0.2 s、0.5 s、1 s、2 s、5 s、10 s時(shí)的性能，測(cè)試結(jié)果如圖7所示。

圖7 各指標(biāo)隨著出塊時(shí)間的變化

根據(jù)圖示曲線變化可得，當(dāng)出塊時(shí)間為1 s時(shí)，吞吐率、讀吞吐量以及寫吞吐量值最高，響應(yīng)時(shí)間和交易延遲值最低，說(shuō)明此時(shí)平臺(tái)性能達(dá)到最優(yōu)狀態(tài)。而當(dāng)出塊時(shí)間超過(guò)1 s之后，吞吐率、讀吞吐量以及寫吞吐量這3個(gè)指標(biāo)值均呈下降趨勢(shì)，響應(yīng)時(shí)間以及交易延遲曲線呈上升趨勢(shì)。說(shuō)明隨著出塊時(shí)間的增加，區(qū)塊生成速率逐漸降低，這是由于吞吐率越高，每秒交易數(shù)越多，效率越高，對(duì)應(yīng)時(shí)間內(nèi)產(chǎn)生的區(qū)塊數(shù)量越少，即區(qū)塊生成速率越低，相反，交易效率越低，就會(huì)不斷的進(jìn)行區(qū)塊打包，性能越差。

4.4 區(qū)塊最大交易條數(shù)

與基準(zhǔn)測(cè)試相比，只改變區(qū)塊最大交易條數(shù)。分別測(cè)試區(qū)塊最大交易條數(shù)為40、160、320、640、720、1 280、2 048、3 000時(shí)的性能，測(cè)試結(jié)果如圖8所示。

圖8 各指標(biāo)隨著區(qū)塊最大交易條數(shù)的變化

根據(jù)圖中的曲線變化得出，隨著區(qū)塊最大交易條數(shù)的增加，吞吐率、讀吞吐量以及寫吞吐量的值隨之急劇增加并保持相對(duì)平緩狀態(tài)，而響應(yīng)時(shí)間、交易延遲以及區(qū)塊生成速率的值隨之急劇降低并保持水平，兩組指標(biāo)變化趨勢(shì)反對(duì)稱性特征明顯。值得注意的是，當(dāng)區(qū)塊最大交易條數(shù)超過(guò)2 048之后，寫吞吐量的指標(biāo)值開(kāi)始呈現(xiàn)下降趨勢(shì)，交易延遲呈現(xiàn)上升趨勢(shì)。原因是由于隨著區(qū)塊最大交易條數(shù)的增加，區(qū)塊出現(xiàn)分叉情況，無(wú)效區(qū)塊的比重增多，造成區(qū)塊鏈性能下降。

4.5 區(qū)塊首選字節(jié)數(shù)

與基準(zhǔn)測(cè)試相比，改變區(qū)塊首選字節(jié)數(shù)大小。分別測(cè)試區(qū)塊大小為200 MB、300 MB、400 MB、500 MB、600 MB、700 MB時(shí)的性能，測(cè)試結(jié)果如圖9所示。

圖9 各指標(biāo)隨著區(qū)塊首選字節(jié)數(shù)的變化

根據(jù)圖中的曲線變化得出，當(dāng)區(qū)塊首選字節(jié)數(shù)為300 MB的時(shí)候，吞吐率、讀吞吐量以及寫吞吐量的值最高，響應(yīng)時(shí)間和交易延遲的值最低，說(shuō)明此時(shí)平臺(tái)性能達(dá)到最優(yōu)。隨著區(qū)塊首選字節(jié)數(shù)增加，寫吞吐量、交易延遲和區(qū)塊生成速率變化幅度較小，趨于平緩，說(shuō)明改變區(qū)塊首選字節(jié)數(shù)對(duì)交易延遲和區(qū)塊生成速率的影響不大，即對(duì)本區(qū)塊鏈平臺(tái)的性能影響較小。

4.6 區(qū)塊最大字節(jié)數(shù)

與基準(zhǔn)測(cè)試相比，改變區(qū)塊最大字節(jié)數(shù)的大小。分別測(cè)試區(qū)塊最大字節(jié)數(shù)為100 MB、200 MB、300 MB、400 MB、500 MB、600 MB、800 MB時(shí)的性能，測(cè)試結(jié)果如圖10所示。

圖10 各指標(biāo)隨著區(qū)塊最大字節(jié)數(shù)的變化

根據(jù)圖中的曲線變化得出，隨著區(qū)塊最大字節(jié)數(shù)的增加，各指標(biāo)變化幅度較小，趨于平緩，說(shuō)明改變區(qū)塊最大字節(jié)數(shù)的大小對(duì)吞吐率、讀吞吐量、寫吞吐量、響應(yīng)時(shí)間、交易延遲以及區(qū)塊生成速率的影響不大，即對(duì)本區(qū)塊鏈平臺(tái)的性能影響較小。

4.7 總連接數(shù)

與基準(zhǔn)測(cè)試相比，改變總連接數(shù)的大小。分別測(cè)試總連接數(shù)為10 000、14 000、16 000、18 000、22 000、24 000、26 000時(shí)的性能，測(cè)試結(jié)果如圖11所示。

圖11 各指標(biāo)隨著總連接數(shù)的變化

根據(jù)圖中的曲線變化得出，隨著總連接數(shù)的增加，吞吐率、讀吞吐量、寫吞吐量、響應(yīng)時(shí)間、交易延遲以及區(qū)塊生成速率變化幅度較小，趨于平緩，說(shuō)明改變總連接數(shù)的大小對(duì)本區(qū)塊鏈平臺(tái)的性能影響較小。值得注意的是，當(dāng)

總連接數(shù)為16 000的時(shí)候，吞吐率和讀吞吐量的值相對(duì)較低，且響應(yīng)時(shí)間的值最高，說(shuō)明此時(shí)平臺(tái)服務(wù)性能較差。

5 結(jié)束語(yǔ)

論文針對(duì)基于Hyperledger Fabric區(qū)塊鏈的公路工程交通產(chǎn)品質(zhì)量控制平臺(tái)的性能測(cè)試展開(kāi)研究及量化評(píng)估分析，建立了一個(gè)面向工程領(lǐng)域具體行業(yè)場(chǎng)景下的區(qū)塊鏈應(yīng)用平臺(tái)性能測(cè)試模型、測(cè)試架構(gòu)及測(cè)試環(huán)境和以吞吐率、讀吞吐量、寫吞吐量、響應(yīng)時(shí)間、區(qū)塊生成速率以及交易延遲作為性能測(cè)試指標(biāo)的方法體系，系統(tǒng)研究了節(jié)點(diǎn)數(shù)、出塊時(shí)間、區(qū)塊最大交易條數(shù)、區(qū)塊最大字節(jié)數(shù)、區(qū)塊首選字節(jié)數(shù)以及總連接數(shù)等不同因素對(duì)區(qū)塊鏈應(yīng)用平臺(tái)服務(wù)性能的影響，并對(duì)產(chǎn)生原因進(jìn)行了一定的分析綜述。值得說(shuō)明的是，論文選取的各影響因素最優(yōu)值在實(shí)際應(yīng)用過(guò)程中能夠支撐業(yè)務(wù)開(kāi)發(fā)及運(yùn)行取得較好性能，系統(tǒng)運(yùn)行穩(wěn)定，服務(wù)響應(yīng)及時(shí)，用戶反饋良好。最后，論文研究成果對(duì)現(xiàn)有主流區(qū)塊鏈平臺(tái)在不同行業(yè)場(chǎng)景上的開(kāi)發(fā)應(yīng)用和系統(tǒng)服務(wù)性能優(yōu)化提升等工作可提供相關(guān)理論支撐和參考。