一種典型場景區塊鏈平臺性能測試方法及應用研究

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

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

0 引言

隨著區塊鏈技術的發展應用，眾多行業和領域的使用者對區塊鏈平臺的服務質量和性能要求也提出更高的使用要求[1-2]。然而，區塊鏈平臺應用性能是否滿足實際應用需求時長沒有引起足夠的重視[3]。因此，研究區塊鏈應用平臺的性能問題具有非常重要的現實意義。

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

但是，無可否認區塊鏈技術發展應用至今，在除金融領域的其他行業成功案例并不多，以上參考文獻研究都是基于主流區塊鏈自身性能的代表，結合具體行業應用實際需求測試分析不足、針對性不強、可借鑒方法體系不明確。不同應用場景在節點數量、區塊大小、交易時間等方面的設置及要求各異，因此，本文主要研究面向公路工程領域交通產品質量控制的區塊鏈應用平臺的性能測試與影響量化分析，旨在建立一種在具體業務場景下的區塊鏈應用平臺性能泛在、可移植借鑒的測試架構、環境和方法體系，以實現對區塊鏈平臺開發應用性能優化提供相關理論支撐和參考。

1 Hyperledger Fabric區塊鏈及交通產品質量控制系統

1.1 Hyperledger Fabric區塊鏈

國家戰略上明確提出要把區塊鏈作為核心技術自主創新的重要突破口，隨著《交通強國建設綱要》的發布，為區塊鏈、大數據、互聯網、人工智能、超級計算等新技術與交通行業深度融合應用提供了契機[14～15]。中華人民共和國國民經濟和社會發展第十四個五年規劃和2035年遠景目標綱要中也指出，要重點發展聯盟鏈服務平臺、供應鏈管理、政務服務等領域應用方案[16]。

Hyperledger Fabric是開源企業級聯盟鏈，支持靈活信任假設，可以通過多種方式配置[17]。因此適用于政府機構、企業等組織結構和節點的加入、聯盟成員之間交易需要授權才能進行的場景，也能結合實際業務場景發揮出區塊鏈的可信安全、高可用、高性能、可編程、隱私保護上的優勢[18]。

1.2 基于區塊鏈的交通產品質量控制系統

1.2.1 系統架構

基于Hyperledger Fabric區塊鏈的交通產品質量控制應用系統采用的技術架構主要分為物理層、區塊鏈層、應用服務層、前端以及全鏈路監控層5個部分，各部分的詳細說明情況描述如下。

1)物理層：主要依賴于docker swarm 容器編排集群，方便進行高效的管理資源，無縫的進行服務擴展，實現整個架構的高可用性。

2)區塊鏈層：基于超級賬本Hyperledger Fabric、主要orderer共識排序節點、peer對等節點、世界狀態庫couchdb、ca節點以及ca節點庫postgresql組成，是整個系統的核心。目前系統支持的orderer共識有kafka共識和raft共識，用來保證orderer排序節點的高可用性，防止因orderer意外宕機而造成無法排序出塊而導致整個區塊鏈網絡的癱瘓。Peer對等節點則是網絡中的平等的儲存賬本的數據節點，節點之間使用gossip協議進行數據同步，所有的區塊鏈數據都存在于此節點。Ca節點則用于配置管理身份和證書以及協調組織關系。Ca節點產生的數據儲存于postgresql數據庫之上。

3)應用服務層：使用單體微服務的架構方式，系統數據庫層使用MySQL一主兩從的方式保證MySQL的高可用性以及postgresql數據庫儲存部分區塊鏈同步下來的區塊、交易、合約、通道信息等，持久化層使用mybatis、mybatis plus等，緩存使用redis哨兵模式保證緩存的高可用性，權限使用oauth2來實現靈活配置的效果，外部接口依賴于RestTemplate。

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

5)全鏈路監控層：主要是用來監控由下至上整個系統生態的健康性而設立的，在異常之前做到預警，發送預警信息至維護人員釘釘達到提前解決系統故障的效果，即負責其他四層的后勤保障，目前主要監控了docker swarm容器主機的CPU、內存、磁盤大小、網絡信息等主機信息，區塊鏈網絡節點的各節點的健康信息，redis集群的健康信息，postgresql&MySQL&couchdb數據庫的健康信息以及各節點各服務的日志信息等，實現簡易運維，減少運維人員的壓力。

基于Hyperledger Fabric區塊鏈的交通產品質量控制應用平臺是甘肅省交通強國建設試點主要技術成果之一。系統明確了交通產品質量控制中各節點單位工作執行的架構層次及之間的相互邏輯關系，以實現交通產品質量控制數據共享[19～20]，系統服務架構設置如圖1所示。借助Fabric需要接入區塊鏈的第三方不需要自己搭建區塊鏈節點網絡來實現區塊鏈客戶端，便可以直接在平臺實現一鍵建鏈，省去建立通道，節點加入通道等一系列操作，提供智能合約的編寫，安裝，實例化，升級等業務的一鍵式發布，簡潔運維等。

圖1 基于區塊鏈的交通產品質量控制體系架構

1.2.2 系統業務邏輯

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

在以上重要工作環節上，都會有不同節點單位主導發起相關應用工作流程。比如在交通產品質量檢測現場抽樣、樣品封樣、樣品拆樣的環節均是由檢測單位負責發起，施工單位、監理單位、建設單位和產品廠家參與相關環節的審核確認及背書簽名，各節點單位之間的事務關系如圖2所示。這其中涉及到交通產品質量數據的基本屬性信息、相關過程照片和視頻等體現各方工作職責的“證據”信息，一個工作環節結束以后的業務數據通過區塊鏈外部接口API與區塊鏈網絡交互，上鏈存證，即可實現交通產品質量控制重要數據信息的不可篡改和可證可溯，基于區塊鏈的交通產品質量控制檢測體系全面建立。

圖2 產品抽檢、封樣、拆樣環節事務關系圖

基于Hyperledger Fabric區塊鏈的交通產品質量控制系統上鏈信息數據結構如表1所示。

表1 上鏈信息數據結構

2 性能測試過程模型

性能測試過程模型將整個過程分割為6個階段，如圖3所示。

圖3 性能測試過程模型

1)制定性能測試計劃。進行性能測試之前，測試人員需要制定一個明確的性能測試計劃，詳細說明如何進行性能測試，為后續更好地執行性能測試提供參考。

2)性能測試需求分析。性能需求分析階段，需要對被測系統進行分析，熟悉被測系統資源，明確性能測試內容，量化、細化性能需求，即確定性能測試指標和測試場景。

3)性能測試設計。性能測試設計階段，需要完成測試環境設計和測試數據設計。

4)性能測試執行。性能測試執行階段，需要搭建測試環境，按照測試場景執行性能測試和測試結果記錄，測試執行過程中依據測試條件不斷改變參數值，得到測試結果，具體流程如圖4所示。

圖4 性能測試執行過程

5)性能測試結果分析。性能測試結果分析階段，需要發現性能瓶頸并定位分析，為后續回歸測試提供參考。

6)性能調優。第一輪性能測試結束且測試結果不理想的條件下，可根據測試結果進行性能優化調整，使系統各項資源使用趨向合理和平衡。

3 性能測試架構和環境構建

3.1 測試指標選擇

性能指標是評估系統性能的主要依據，全面性、針對性和可擴展應用性要強。結合本交通產品質量控制具體場景和區塊鏈平臺的服務需求，確定如下性能指標。

1)吞吐率TPS(transactions per second)，指在一定時間段內完成有效交易的速率，用來衡量區塊鏈系統對交易的處理性能，TPS越高表示系統交易處理能力越強。計算公式如式(1)所示：

(1)

其中：m表示t時間段內完成的總交易數，t表示完成交易的總耗時。

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

(2)

其中：n表示t時間段內完成的總讀取操作數量，t表示完成讀取操作的總耗時。

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

(3)

其中：n表示t時間段內完成的總上鏈操作數量，t表示完成上鏈操作的總耗時。

4)響應時間RT(response time)，指一個交易從提交請求開始到接收交易完成響應所花費的時間。計算公式如式(4)所示：

RT=t1-t0

(4)

其中：t0表示交易開始的時間，t1表示所有交易完成的時間。

5)區塊生成速率BPS(block per second)，指一定時間段內，區塊鏈系統每秒產生的區塊個數。計算公式如式(5)所示：

(5)

其中：a表示t0到t1時間段內產生的區塊個數，t0表示交易開始的時間，t1表示所有交易完成時間。

6)交易延遲TL(transaction latency)，指一個交易從提交到可以在網絡中使用所需要的時間。計算公式如式(6)所示：

TL=t1-t0

(6)

其中：t0表示交易提交的時間，t1表示交易可以在網絡中使用的時間。

3.2 性能測試架構設計

面向公路交通產品質量控制這一典型場景應用的Hyperledger Fabric區塊鏈平臺，論文通過在平臺所連接的區塊鏈節點上進行交易來記錄交通產品質量數據的請求、訪問以及存儲等操作。同時，為了保證實際應用場景業務的正常運行，需要明確平臺每項交易的有效性，現有的性能測試方法及工具在單個交易有效性的細粒度追蹤方面具有一定的局限性，為此，本文采用了如圖5所示的測試架構，包含客戶端、觀察端以及區塊鏈網絡三部分。

圖5 性能測試架構

客戶端代表用戶向區塊鏈網絡提交交易的節點，可以將工作引入系統或調用系統行為的實體。

觀察端是從區塊鏈網絡接收通知或查詢區塊鏈網絡提交事務狀態的節點，但觀察端不能提交任何新事務。

區塊鏈網絡用于設置運行維護區塊鏈所需的硬件、軟件以及網絡等配置信息。

客戶端、觀察端以及區塊鏈網絡的工作內容及執行流程如下。

Step 1：對產生的交易提案進行簽名；

Step 2：通過gRPC將簽名提案發至背書節點；

Step 3：取出背書后的結果，并封裝成特定的Envelope數據格式；

Step 4：把封裝好的Envelope數據通過gRPC廣播到排序節點；

Step 5：排序節點生成區塊，然后將區塊廣播到 Peer節點，Peer節點接收區塊，經過驗證后保存到本地賬本，最后向其他節點廣播已提交區塊；

Step 6：接收到Peer節點廣播的區塊之后，計算區塊中交易數量以及總耗時，當發送所有預設的交易數量時結束運行，并根據總耗時計算TPS。

3.3 性能測試環境搭建

良好的測試環境既是執行系統測試的前提，也是順利完成測試的保證，確保其與真實環境一致或存在可比性。本文的測試環境如表2所示。

表2 測試環境配置

4 Fabric性能測試及工程案例分析

4.1 基準性能測試

根據交通產品質量控制系統區塊鏈平臺的開發運行機制，論文首先進行基準性能測試，計算吞吐率(TPS)、讀吞吐量(RPS)、寫吞吐量(WPS)、響應時間(RT)、區塊生成速率(BPS)以及交易延遲(TL)這6個指標的值。實驗相關參數配置如表3所示。實驗結果統計如表4所示。

表3 Fabric相關配置

表4 基準實驗結果

Node：指節點數，它是區塊鏈網絡最基本的組成模塊，用于檢查一個事務是否有效。

Batch Timeout：指出塊時間，即最長出塊間隔，用來定時檢測緩存中是否存在還未出塊的數據，只有緩存中存在數據才會出塊，否則無法出塊。

Max Message Count：指區塊最大交易條數，表示一個區塊中能夠包含的最大交易條數，它用于判斷新出現的交易以及緩存里的交易數量是否達到這個數量，如果達到了這個條件，則會立即出塊。

Absolute Max Bytes：指區塊最大字節數，所有情況下區塊的最大允許字節數，如果一個交易數據本身就超過了這個大小，則會被直接退回，沒有機會參與打包。

Preferred Max Bytes：指區塊首選字節數，正常情況下一個區塊中的交易數據大小會小于此參數。

Num_of_conn：指總連接數。

影響Fabric區塊鏈平臺交易性能的因素有許多，論文根據交通產品質量控制數據交易、運行機制以及實際應用過程，選取了節點數、出塊時間、區塊最大交易條數、區塊最大字節數、區塊首選字節數以及總連接數作為區塊鏈平臺性能影響主要因素進行實驗評估分析。

4.2 節點數

與基準測試相比，只改變節點數。分別測試節點數為1、2、3、4、5、6、7、8時的性能，測試結果如圖6所示。

圖6 各指標隨著節點數的變化

根據圖中的曲線變化得出，隨著節點數的增加，吞吐率、讀吞吐量、寫吞吐量以及區塊生成速率的值隨之下降，而響應時間和交易延遲的值隨之上升。當節點數為1時，吞吐率、讀吞吐量、寫吞吐量以及區塊生成速率的值最高，響應時間和交易延遲值最低，說明此時平臺性能達到最優狀態。該測試結果符合聯盟鏈節點數少的性能特點。

4.3 出塊時間

與基準測試相比，只改變出塊時間。分別測試出塊時間為0.2 s、0.5 s、1 s、2 s、5 s、10 s時的性能，測試結果如圖7所示。

圖7 各指標隨著出塊時間的變化

根據圖示曲線變化可得，當出塊時間為1 s時，吞吐率、讀吞吐量以及寫吞吐量值最高，響應時間和交易延遲值最低，說明此時平臺性能達到最優狀態。而當出塊時間超過1 s之后，吞吐率、讀吞吐量以及寫吞吐量這3個指標值均呈下降趨勢，響應時間以及交易延遲曲線呈上升趨勢。說明隨著出塊時間的增加，區塊生成速率逐漸降低，這是由于吞吐率越高，每秒交易數越多，效率越高，對應時間內產生的區塊數量越少，即區塊生成速率越低，相反，交易效率越低，就會不斷的進行區塊打包，性能越差。

4.4 區塊最大交易條數

與基準測試相比，只改變區塊最大交易條數。分別測試區塊最大交易條數為40、160、320、640、720、1 280、2 048、3 000時的性能，測試結果如圖8所示。

圖8 各指標隨著區塊最大交易條數的變化

根據圖中的曲線變化得出，隨著區塊最大交易條數的增加，吞吐率、讀吞吐量以及寫吞吐量的值隨之急劇增加并保持相對平緩狀態，而響應時間、交易延遲以及區塊生成速率的值隨之急劇降低并保持水平，兩組指標變化趨勢反對稱性特征明顯。值得注意的是，當區塊最大交易條數超過2 048之后，寫吞吐量的指標值開始呈現下降趨勢，交易延遲呈現上升趨勢。原因是由于隨著區塊最大交易條數的增加，區塊出現分叉情況，無效區塊的比重增多，造成區塊鏈性能下降。

4.5 區塊首選字節數

與基準測試相比，改變區塊首選字節數大小。分別測試區塊大小為200 MB、300 MB、400 MB、500 MB、600 MB、700 MB時的性能，測試結果如圖9所示。

圖9 各指標隨著區塊首選字節數的變化

根據圖中的曲線變化得出，當區塊首選字節數為300 MB的時候，吞吐率、讀吞吐量以及寫吞吐量的值最高，響應時間和交易延遲的值最低，說明此時平臺性能達到最優。隨著區塊首選字節數增加，寫吞吐量、交易延遲和區塊生成速率變化幅度較小，趨于平緩，說明改變區塊首選字節數對交易延遲和區塊生成速率的影響不大，即對本區塊鏈平臺的性能影響較小。

4.6 區塊最大字節數

與基準測試相比，改變區塊最大字節數的大小。分別測試區塊最大字節數為100 MB、200 MB、300 MB、400 MB、500 MB、600 MB、800 MB時的性能，測試結果如圖10所示。

圖10 各指標隨著區塊最大字節數的變化

根據圖中的曲線變化得出，隨著區塊最大字節數的增加，各指標變化幅度較小，趨于平緩，說明改變區塊最大字節數的大小對吞吐率、讀吞吐量、寫吞吐量、響應時間、交易延遲以及區塊生成速率的影響不大，即對本區塊鏈平臺的性能影響較小。

4.7 總連接數

與基準測試相比，改變總連接數的大小。分別測試總連接數為10 000、14 000、16 000、18 000、22 000、24 000、26 000時的性能，測試結果如圖11所示。

圖11 各指標隨著總連接數的變化

根據圖中的曲線變化得出，隨著總連接數的增加，吞吐率、讀吞吐量、寫吞吐量、響應時間、交易延遲以及區塊生成速率變化幅度較小，趨于平緩，說明改變總連接數的大小對本區塊鏈平臺的性能影響較小。值得注意的是，當

總連接數為16 000的時候，吞吐率和讀吞吐量的值相對較低，且響應時間的值最高，說明此時平臺服務性能較差。

5 結束語

論文針對基于Hyperledger Fabric區塊鏈的公路工程交通產品質量控制平臺的性能測試展開研究及量化評估分析，建立了一個面向工程領域具體行業場景下的區塊鏈應用平臺性能測試模型、測試架構及測試環境和以吞吐率、讀吞吐量、寫吞吐量、響應時間、區塊生成速率以及交易延遲作為性能測試指標的方法體系，系統研究了節點數、出塊時間、區塊最大交易條數、區塊最大字節數、區塊首選字節數以及總連接數等不同因素對區塊鏈應用平臺服務性能的影響，并對產生原因進行了一定的分析綜述。值得說明的是，論文選取的各影響因素最優值在實際應用過程中能夠支撐業務開發及運行取得較好性能，系統運行穩定，服務響應及時，用戶反饋良好。最后，論文研究成果對現有主流區塊鏈平臺在不同行業場景上的開發應用和系統服務性能優化提升等工作可提供相關理論支撐和參考。