賀鵬飛，范鵬飛，尹千慧，王中訓(xùn)，張桐敬，梁大偉

（1.煙臺(tái)大學(xué) 物理與電子信息學(xué)院，山東 煙臺(tái) 264005；2.華能山東煙臺(tái)發(fā)電有限公司煙臺(tái)發(fā)電廠，山東 煙臺(tái) 264002；3.煙臺(tái)市食品藥品檢驗(yàn)檢測中心，山東 煙臺(tái) 264000）

0 概述

區(qū)塊鏈?zhǔn)怯啥喙?jié)點(diǎn)參與的由區(qū)塊構(gòu)成的有序數(shù)據(jù)鏈，記錄了賬本中業(yè)務(wù)對(duì)象的所有狀態(tài)，本質(zhì)是一個(gè)具有一致性的分布式賬本［1］。區(qū)塊鏈融合了共識(shí)算法、密碼學(xué)、智能合約、對(duì)等網(wǎng)絡(luò)等技術(shù)，實(shí)現(xiàn)了交易的安全、可靠和不可篡改，是一種利用哈希指針及分布式存儲(chǔ)技術(shù)進(jìn)行數(shù)據(jù)存儲(chǔ)的系統(tǒng)［2］。目前，主流的區(qū)塊鏈開發(fā)平臺(tái)包括以太坊、Hyperledger Fabric 等，其中以太坊屬于公有鏈，由于公有鏈中全網(wǎng)節(jié)點(diǎn)共同參與，因此交易速度較慢。Hyperledger Fabric 采用成員許可制，支持自定義的共識(shí)協(xié)議及多種語言的智能合約，交易速度快，運(yùn)營成本低，是一種模塊化的許可鏈開發(fā)平臺(tái)［3］。此外，Hyperledger Fabric 為上層應(yīng)用開發(fā)者提供了多種SDK 開發(fā)包，降低了應(yīng)用開發(fā)者的學(xué)習(xí)門檻。主流的共識(shí)算法有工作量證明（Proof of Work，PoW）、權(quán)益證明（Proof of Stake，PoS）、代理權(quán)益證明（Delegated Proof of Stake，DPoS）、實(shí)用拜占庭容錯(cuò)（Practical Byzantine Fault Tolerance，PBFT）等。不同于其他共識(shí)機(jī)制，在Hyperledger Fabric 中共識(shí)被定義為對(duì)包含在區(qū)塊中的一組交易的正確性的全面驗(yàn)證［4］。簡而言之，Hyperledger Fabric 將共識(shí)過程解耦，通過背書-排序-驗(yàn)證過程達(dá)成共識(shí)。

針對(duì)Hyperledger Fabric 性能研究，周玉舒［5］基于區(qū)塊鏈設(shè)計(jì)鋼鐵供應(yīng)鏈系統(tǒng)，引入SQL 和負(fù)載均衡技術(shù)設(shè)計(jì)鏈上查詢請求分發(fā)方案，解決了鏈上查詢效率低下的問題。孟吳同［6］在Hyperledger Fabric區(qū)塊鏈開發(fā)平臺(tái)中引入基于可隨機(jī)驗(yàn)證函數(shù)（Verifiable Random Function，VRF）的抽簽算法，為交易隨機(jī)抽取背書節(jié)點(diǎn)，改進(jìn)后提高了鏈碼的吞吐量，降低了交易延遲，同時(shí)提升了共識(shí)安全性。THAKKAR 等［7］研究Hyperledger Fabric 中參數(shù)配置產(chǎn)生的性能影響，識(shí)別系統(tǒng)中存在的性能瓶頸并研究了3 種優(yōu)化方案。袁普［8］使用PNTOOL 工具箱搭建GSPN 模型對(duì)Hyperledger Fabric 性能進(jìn)行分析，并對(duì)Hyperledger Fabric 中存在的性能瓶頸提出解決方案，通過參數(shù)的最優(yōu)化配置和背書節(jié)點(diǎn)的負(fù)載均衡進(jìn)行性能優(yōu)化，提升了系統(tǒng)吞吐量。FOSCHINI等［9］對(duì)Hyperledger Fabric 進(jìn)行測試，研究了實(shí)現(xiàn)鏈碼的編程語言和背書節(jié)點(diǎn)數(shù)量對(duì)交易延遲的影響，結(jié)果表明GO 語言實(shí)現(xiàn)的鏈碼性能最優(yōu)。何英［10］在Hyperledger Fabric 中引入負(fù)載均衡的一致性哈希算法，采用二分查找的背書節(jié)點(diǎn)搜索算法，提升了鏈碼的吞吐量，解決了共識(shí)中背書提案分發(fā)導(dǎo)致的性能瓶頸問題。NARAYANAM 等［11］對(duì)Hyperledger Fabric 中的排序服務(wù)進(jìn)行優(yōu)化，通過并行交易驗(yàn)證減少了等待時(shí)間，實(shí)現(xiàn)了高交易吞吐量。王洋［12］針對(duì)檔案業(yè)務(wù)的應(yīng)用場景，基于Hyperledger Fabric 平臺(tái)對(duì)PBFT 算法、節(jié)點(diǎn)角色以及智能合約等進(jìn)行改進(jìn)，進(jìn)一步保障了數(shù)據(jù)安全，提升了系統(tǒng)性能。劉云等［13］使用最小損失算法動(dòng)態(tài)調(diào)整區(qū)塊參數(shù)以提升鏈上事務(wù)吞吐量。劉應(yīng)等［14］基于哈希取模算法和默克爾樹設(shè)計(jì)中間件優(yōu)化方法，通過實(shí)時(shí)驗(yàn)證以實(shí)現(xiàn)數(shù)據(jù)一致性，使系統(tǒng)查詢性能提升至數(shù)據(jù)庫級(jí)別。周步祥等［15］基于Stackelberg 博弈理論構(gòu)建交易模型，采用迭代算法求解交易策略，從而實(shí)現(xiàn)了交易的最優(yōu)化。陳悅妍［16］對(duì)區(qū)塊鏈系統(tǒng)進(jìn)行輕量化研究，提出基于分組-分配方式存儲(chǔ)數(shù)據(jù)的擴(kuò)容算法，并設(shè)計(jì)預(yù)付式激勵(lì)與交易機(jī)制和數(shù)據(jù)安全共享與驗(yàn)證機(jī)制。

本文針對(duì)Hyperledger Fabric 共識(shí)中背書階段存在的性能瓶頸，提出基于動(dòng)態(tài)負(fù)載反饋的提案分發(fā)優(yōu)化方案。該方案根據(jù)反饋周期T采集節(jié)點(diǎn)負(fù)載信息，利用加權(quán)輪詢算法分發(fā)交易提案至背書節(jié)點(diǎn)，以解決共識(shí)機(jī)制中背書階段提案分發(fā)方式導(dǎo)致的系統(tǒng)性能低下問題。

1 相關(guān)研究

1.1 負(fù)載均衡算法

負(fù)載均衡技術(shù)是一種為了使服務(wù)器資源得到有效利用的技術(shù)。負(fù)載均衡算法［17］根據(jù)調(diào)度策略的不同可分為靜態(tài)負(fù)載均衡算法和動(dòng)態(tài)負(fù)載均衡算法［18］。靜態(tài)負(fù)載均衡算法簡單易于實(shí)現(xiàn)，但無法根據(jù)集群實(shí)際負(fù)載調(diào)整調(diào)度策略，包括輪詢算法、加權(quán)輪詢算法、一致性哈希算法等。動(dòng)態(tài)負(fù)載均衡算法能根據(jù)服務(wù)器性能變化及時(shí)調(diào)整調(diào)度策略，因此應(yīng)用廣泛，包括最小連接數(shù)算法、加權(quán)最小連接數(shù)算法、最快響應(yīng)算法等。

近幾年，國內(nèi)外學(xué)者對(duì)動(dòng)態(tài)負(fù)載均衡算法進(jìn)行深入研究并取得了一定的成果。針對(duì)目前提出的固定權(quán)重負(fù)載均衡算法在微服務(wù)請求較多的情況下無法實(shí)現(xiàn)更好的負(fù)載均衡效果，YI 等［19］提出一種基于動(dòng)態(tài)權(quán)重的負(fù)載均衡算法。為更好地解決蜂窩車聯(lián)網(wǎng)與移動(dòng)邊緣計(jì)算融合應(yīng)用場景下邊緣服務(wù)器資源負(fù)載分配不均、資源利用率較低等問題：林峰［20］提出一種動(dòng)態(tài)負(fù)載均衡算法，該算法能夠更好地提升邊緣服務(wù)器集群的負(fù)載均衡度，縮短任務(wù)完成時(shí)間；倪雅婷等［21］提出一種由動(dòng)態(tài)配置、負(fù)載收集、算法調(diào)度組成的動(dòng)態(tài)負(fù)載均衡策略，對(duì)Nginx 中WLC 算法進(jìn)行改進(jìn)，滿足了DRC 集群的大流量訪問需求；李嵐［22］利用神經(jīng)網(wǎng)絡(luò)動(dòng)態(tài)優(yōu)化參數(shù)，提出用于移動(dòng)通信平臺(tái)的動(dòng)態(tài)負(fù)載均衡算法，降低了算法的響應(yīng)時(shí)間，提升了移動(dòng)通信平臺(tái)的運(yùn)行效率。徐愛鑫等［23］提出一種基于非合作博弈降載的主控制器重選模型，解決了軟件定義網(wǎng)絡(luò)中多控制器負(fù)載失衡問題。

1.2 Hyperledger Fabric

在Hyperledger Fabric 中節(jié)點(diǎn)按邏輯角色解耦，實(shí)現(xiàn)了排序服務(wù)、共識(shí)、身份認(rèn)證、權(quán)限管理、加解密、賬本機(jī)制的模塊化，提高了可擴(kuò)展性［24］。Hyperledger Fabric 采用成員許可制，支持多通道管理、可編程和第三方實(shí)現(xiàn)，并通過Docker 容器技術(shù)，實(shí)現(xiàn)了低資源占用前提下的節(jié)點(diǎn)快速啟動(dòng)。此外，Hyperledger Fabric 支持自定義的共識(shí)協(xié)議，實(shí)現(xiàn)了應(yīng)用平臺(tái)的定制化。在實(shí)際運(yùn)行過程中，不同節(jié)點(diǎn)擔(dān)任不同的邏輯角色。

1.2.1 交易流程

Hyperledger Fabric 中的請求包括查詢請求（Query）和交易請求（Invoke）。查詢請求是讀取賬本但并不會(huì)修改賬本狀態(tài)的鏈碼調(diào)用，除了基于審計(jì)目的需要記錄訪問賬本日志之外，在通常情況下，客戶端不會(huì)提交這種只讀性事務(wù)進(jìn)行排序、驗(yàn)證和提交。交易請求根據(jù)提案內(nèi)容調(diào)用指定鏈碼內(nèi)的函數(shù)，經(jīng)過提案、背書、排序、提交等一系列的交易過程，最終將區(qū)塊寫入相應(yīng)通道賬本中。Hyperledger Fabric 交易流程如圖1 所示。

圖1 Hyperledger Fabric 交易流程Fig.1 Process of Hyperledger Fabric transaction

Hyperledger Fabric 交易過程具體如下：

1）客戶端通過SDK 調(diào)用證書服務(wù)進(jìn)行身份注冊，向區(qū)塊鏈網(wǎng)絡(luò)發(fā)送交易提案（proposal）至背書節(jié)點(diǎn)，交易提案中包括鏈碼信息、提交時(shí)間、客戶端簽名等信息。

2）背書節(jié)點(diǎn)在收到提案后，檢查客戶端簽名并確認(rèn)提交者是否被授權(quán)執(zhí)行該操作，根據(jù)提案內(nèi)容調(diào)用并模擬執(zhí)行交易（實(shí)際并不改變當(dāng)前賬本的狀態(tài)），隨后背書節(jié)點(diǎn)調(diào)用背書系統(tǒng)鏈碼（Endorsement System Chaincode，ESCC），并根據(jù)節(jié)點(diǎn)身份對(duì)交易響應(yīng)簽名，同時(shí)將簽名和背書執(zhí)行結(jié)果發(fā)送至客戶端［25］。

3）客戶端在收到背書節(jié)點(diǎn)返回的信息后，檢查背書節(jié)點(diǎn)的簽名是否有效，若簽名無效，則交易停止。同時(shí)，客戶端根據(jù)背書策略，檢查背書數(shù)量是否與背書策略相匹配，并檢查背書結(jié)果是否一致。在檢查無誤后，根據(jù)背書生成的讀寫集打包生成交易發(fā)送給排序節(jié)點(diǎn)，否則中止交易。

4）在排序服務(wù)中，排序節(jié)點(diǎn)根據(jù)共識(shí)算法將交易按時(shí)間順序排序，基于交易順序達(dá)成共識(shí)，并按指定的切分策略，首先將交易打包為區(qū)塊，然后分發(fā)到相應(yīng)通道的所有組織的主節(jié)點(diǎn)上。

5）提交節(jié)點(diǎn)在收到區(qū)塊后，使用讀寫集中的讀集對(duì)交易進(jìn)行校驗(yàn)以檢查交易的有效性（如果讀集中鍵的版本和世界狀態(tài)中鍵的版本一致，則認(rèn)為該交易是有效的），檢查通過后將區(qū)塊提交至區(qū)塊鏈中，并修改相應(yīng)業(yè)務(wù)對(duì)象的世界狀態(tài)。

在區(qū)塊被提交至鏈上并更新世界狀態(tài)后，則認(rèn)為交易已完成。這一過程主要包括背書、排序、驗(yàn)證3 個(gè)階段，其中，背書是指接收客戶端的交易請求后模擬執(zhí)行交易，對(duì)結(jié)果簽名并返回交易響應(yīng)的過程，排序是對(duì)交易按時(shí)間順序達(dá)成一致并打包為區(qū)塊的過程，驗(yàn)證是由提交節(jié)點(diǎn)對(duì)交易完整性和賬本一致性進(jìn)行檢查。

1.2.2 性能分析

Hyperledger Fabric 將共識(shí)機(jī)制解耦，使共識(shí)過程邏輯分離。Hyperledger Fabric 通過背書-排序-驗(yàn)證過程達(dá)成共識(shí)，使得系統(tǒng)具有模塊化的特性，提高了靈活性，但是也對(duì)系統(tǒng)性能產(chǎn)生了一些影響。對(duì)Hyperledger Fabric 共識(shí)階段做進(jìn)一步分析：

1）背書階段，默認(rèn)背書策略會(huì)將提案分發(fā)給通道所有成員，通道中大部分成員達(dá)成一致即背書成功。通過背書預(yù)先執(zhí)行交易提案進(jìn)行交易有效性驗(yàn)證，避免了各節(jié)點(diǎn)都調(diào)用鏈碼執(zhí)行交易的過程，提高了系統(tǒng)的交易處理速度。但在背書過程中，背書節(jié)點(diǎn)需要校驗(yàn)提案合法性、執(zhí)行智能合約、生成讀寫集、背書簽名、背書響應(yīng)等步驟，消耗了大量時(shí)間。在默認(rèn)背書策略下，當(dāng)客戶端產(chǎn)生大量交易時(shí)，背書節(jié)點(diǎn)難以及時(shí)處理，容易形成較長的交易請求隊(duì)列，從而導(dǎo)致較長的交易時(shí)延。

2）排序階段，排序節(jié)點(diǎn)使用共識(shí)算法達(dá)成交易順序一致性共識(shí)，僅負(fù)責(zé)交易排序并根據(jù)區(qū)塊參數(shù)設(shè)置將排序后的交易打包成為區(qū)塊，在此階段中處理時(shí)長主要取決于所采用的共識(shí)算法。

3）驗(yàn)證階段，提交節(jié)點(diǎn)首先對(duì)區(qū)塊結(jié)構(gòu)和數(shù)據(jù)進(jìn)行檢查，通過驗(yàn)證系統(tǒng)鏈碼（Validation System Chain Code，VSCC）驗(yàn)證背書有效性以及交易合法性，然后執(zhí)行多版本并發(fā)控制（Multi-Version Concurrency Control，MVCC）驗(yàn)證是否存在并發(fā)操作，檢查通過后提交區(qū)塊至分類賬本并更新相應(yīng)世界狀態(tài)。當(dāng)區(qū)塊切分策略設(shè)置過小時(shí)，在交易發(fā)送速率不斷提高的過程中，多個(gè)API 的頻繁調(diào)用會(huì)使驗(yàn)證性能顯著下降，驗(yàn)證階段的隊(duì)列長度暴漲從而成為系統(tǒng)瓶頸。

綜合以上分析得出，在不改變Hyperledger Fabric 網(wǎng)絡(luò)架構(gòu)的前提下，合理選取區(qū)塊配置參數(shù)可以規(guī)避區(qū)塊大小導(dǎo)致的驗(yàn)證階段性能瓶頸問題，從而將系統(tǒng)性能瓶頸定位到背書階段，因此本文設(shè)計(jì)基于動(dòng)態(tài)負(fù)載反饋的提案分發(fā)優(yōu)化方案以均衡背書節(jié)點(diǎn)性能，提高系統(tǒng)效率。

2 基于動(dòng)態(tài)負(fù)載反饋的提案分發(fā)優(yōu)化方案

在Hyperledger Fabric 共識(shí)機(jī)制的基礎(chǔ)上，設(shè)計(jì)一種基于動(dòng)態(tài)負(fù)載反饋的提案分發(fā)優(yōu)化方案。該方案周期性計(jì)算背書節(jié)點(diǎn)負(fù)載，通過動(dòng)態(tài)反饋的負(fù)載均衡算法依據(jù)節(jié)點(diǎn)權(quán)值選取交易背書節(jié)點(diǎn)完成交易背書，實(shí)現(xiàn)了交易背書節(jié)點(diǎn)性能的均衡利用，提高了交易處理性能。

2.1 設(shè)計(jì)原理

在系統(tǒng)運(yùn)行過程中，原有共識(shí)機(jī)制忽略了背書節(jié)點(diǎn)之間背書任務(wù)量的差異，容易導(dǎo)致節(jié)點(diǎn)處理性能失衡。考慮到所有節(jié)點(diǎn)都配置在Docker 容器中，Docker 容器共享宿主機(jī)的內(nèi)核，在同一宿主機(jī)或多個(gè)宿主機(jī)配置相同的情況下，可以通過節(jié)點(diǎn)當(dāng)前負(fù)載來衡量節(jié)點(diǎn)的剩余處理能力。因此，為了增強(qiáng)Hyperledger Fabric 集群的負(fù)載自適應(yīng)能力，提出基于動(dòng)態(tài)負(fù)載反饋的提案分發(fā)優(yōu)化方案。

該方案根據(jù)反饋周期T計(jì)算節(jié)點(diǎn)負(fù)載，并根據(jù)節(jié)點(diǎn)負(fù)載計(jì)算節(jié)點(diǎn)權(quán)值，建立候選背書節(jié)點(diǎn)列表，客戶端/應(yīng)用程序提交交易請求至客戶端服務(wù)器，客戶端服務(wù)器作為負(fù)載均衡器依據(jù)當(dāng)前周期的節(jié)點(diǎn)權(quán)值，根據(jù)負(fù)載均衡算法為提案選擇背書節(jié)點(diǎn)，并最終調(diào)用SDK 將指定交易提案分發(fā)至背書節(jié)點(diǎn)為交易進(jìn)行背書。節(jié)點(diǎn)權(quán)值大小與節(jié)點(diǎn)當(dāng)前負(fù)載成反比，與節(jié)點(diǎn)的剩余處理能力成正比。

在該方案中，由于節(jié)點(diǎn)具有相同的配置，在實(shí)現(xiàn)方案效果的同時(shí)考慮算法復(fù)雜度對(duì)服務(wù)器性能的影響，因此選用加權(quán)輪詢算法實(shí)現(xiàn)對(duì)提案的分發(fā)。通過這種動(dòng)態(tài)反饋的負(fù)載均衡機(jī)制，根據(jù)節(jié)點(diǎn)負(fù)載周期性修正節(jié)點(diǎn)權(quán)值，避免了加權(quán)輪詢算法中由于特殊權(quán)值產(chǎn)生的不均勻序列，從而實(shí)現(xiàn)了交易背書分配策略的動(dòng)態(tài)調(diào)整，使背書節(jié)點(diǎn)的負(fù)載趨于均衡，并最終提升了系統(tǒng)的交易處理性能?；趧?dòng)態(tài)負(fù)載反饋的提案分發(fā)優(yōu)化方案流程如圖2 所示。

圖2 基于動(dòng)態(tài)負(fù)載反饋的提案分發(fā)優(yōu)化方案流程Fig.2 Process of optimization scheme of proposal distribution based on dynamic load feedback

2.2 參數(shù)設(shè)置

2.2.1 負(fù)載指數(shù)

選取CPU、內(nèi)存、磁盤以及帶寬使用率來綜合評(píng)價(jià)節(jié)點(diǎn)負(fù)載，其中，CPU 利用率反映了節(jié)點(diǎn)繁忙情況，磁盤使用率反映了對(duì)磁盤的使用程度，內(nèi)存利用率反映了節(jié)點(diǎn)內(nèi)存使用情況，帶寬利用率反映了網(wǎng)絡(luò)使用情況。假設(shè)集群an是由n個(gè)節(jié)點(diǎn)組成，即an={a1，a2，…，an}，Lai表示節(jié)點(diǎn)i的當(dāng)前負(fù)載，則：

其中：Cai、Mai、Dai、Nai分別為節(jié)點(diǎn)i當(dāng)前的CPU、內(nèi)存、磁盤以及帶寬使用率和NNet分別為每秒帶寬上傳速度、每秒帶寬下載速度和網(wǎng)絡(luò)帶寬，參數(shù)數(shù)值通過對(duì)Docker 進(jìn)行性能監(jiān)控獲得；αcpu、αmem、αdisk、αnet分別為節(jié)點(diǎn)i當(dāng)前的CPU 利用率、內(nèi)存利用率、磁盤使用率以及網(wǎng)絡(luò)帶寬利用率的負(fù)載影響權(quán)重，并且αcpu+αmem+αdisk+αnet=1。

2.2.2 節(jié)點(diǎn)權(quán)值

為能夠根據(jù)節(jié)點(diǎn)負(fù)載反饋動(dòng)態(tài)改變節(jié)點(diǎn)處理背書任務(wù)數(shù)量，實(shí)現(xiàn)節(jié)點(diǎn)負(fù)載自適應(yīng)，節(jié)點(diǎn)權(quán)值設(shè)定需要能夠反映節(jié)點(diǎn)當(dāng)前處理能力，即節(jié)點(diǎn)權(quán)值與節(jié)點(diǎn)當(dāng)前負(fù)載呈反比。根據(jù)以上分析，將節(jié)點(diǎn)權(quán)值設(shè)為節(jié)點(diǎn)負(fù)載倒數(shù)的占比，負(fù)載越高的節(jié)點(diǎn)權(quán)值越低，分配到的任務(wù)數(shù)量越少，負(fù)載越低的節(jié)點(diǎn)權(quán)值越高，分配到的任務(wù)數(shù)量越多。利用ωi表示節(jié)點(diǎn)權(quán)值，計(jì)算公式如下：

其中：Lai表示節(jié)點(diǎn)i當(dāng)前的負(fù)載。

2.2.3 均衡指數(shù)

當(dāng)達(dá)到理想狀態(tài)時(shí)，各節(jié)點(diǎn)負(fù)載需滿足：

此時(shí)各節(jié)點(diǎn)負(fù)載離散程度最小，集群負(fù)載的均方差為0。反之，在負(fù)載不均衡時(shí)，集群負(fù)載的均方差較大。因此采用集群an負(fù)載的標(biāo)準(zhǔn)差來表示節(jié)點(diǎn)的負(fù)載均衡情況，使用Lavg表示集群an的平均負(fù)載，Ld表示集群an的均衡指數(shù)，得到：

2.2.4 影響權(quán)重

對(duì)于各指標(biāo)的影響權(quán)重α={αcpu，αmem，αdisk，αnet}的計(jì)算，傳統(tǒng)方法是根據(jù)經(jīng)驗(yàn)取值，其結(jié)果可能會(huì)與實(shí)際偏差較大，難以精確描述各指標(biāo)對(duì)于節(jié)點(diǎn)性能的影響。本文選擇將各性能指標(biāo)與響應(yīng)時(shí)延的相關(guān)系數(shù)作為各指標(biāo)占比權(quán)值。相關(guān)系數(shù)是研究變量之間線性相關(guān)程度的量。響應(yīng)時(shí)延為背書階段的提案處理時(shí)間，即客戶端發(fā)送交易請求至背書節(jié)點(diǎn)與背書節(jié)點(diǎn)返回響應(yīng)至客戶端的時(shí)間差，可通過回調(diào)函數(shù)打印背書響應(yīng)時(shí)間戳和提案中的時(shí)間戳，將時(shí)間戳解析后對(duì)其求差值得到。當(dāng)前節(jié)點(diǎn)負(fù)載越高，節(jié)點(diǎn)剩余處理能力越弱，用戶請求處理時(shí)延越長，而響應(yīng)時(shí)延是節(jié)點(diǎn)負(fù)載情況的直接體現(xiàn)。因此，各性能指標(biāo)與響應(yīng)時(shí)延之間的相關(guān)系數(shù)能從一定程度上反映各性能指標(biāo)對(duì)節(jié)點(diǎn)負(fù)載的影響，影響權(quán)重計(jì)算如下：

通過測試并計(jì)算得出各參數(shù)對(duì)于負(fù)載的影響權(quán)重分別為0.335 1、0.340 7、0.156 1、0.168 1，依次為CPU 利用率、內(nèi)存利用率、磁盤使用率、網(wǎng)絡(luò)帶寬利用率的影響權(quán)重。

2.2.5 反饋周期

通過節(jié)點(diǎn)集群周期性反饋性能給負(fù)載均衡器實(shí)現(xiàn)性能均衡，反饋周期T會(huì)影響系統(tǒng)負(fù)載均衡的有效性。在收集負(fù)載信息并進(jìn)行計(jì)算的過程中，會(huì)消耗均衡器所在的服務(wù)器資源。當(dāng)T設(shè)置過小時(shí)，會(huì)更多地消耗服務(wù)器資源，加重服務(wù)器的性能負(fù)載。當(dāng)T設(shè)置過大時(shí)，收集到的節(jié)點(diǎn)負(fù)載信息誤差較大，實(shí)時(shí)性較差。因此，為實(shí)現(xiàn)較好的負(fù)載均衡效果，需要對(duì)T進(jìn)行合理設(shè)置。本文參考負(fù)載均衡算法的經(jīng)驗(yàn)值，選取T的范圍為2～15 s 并以間隔1 s 進(jìn)行實(shí)驗(yàn)，通過多次實(shí)驗(yàn)取平均值并計(jì)算不同T下的集群均衡指數(shù)，測試結(jié)果如圖3 和圖4 所示。從圖3 可以看出：當(dāng)反饋周期T小于6 s 時(shí)，集群吞吐量呈遞增趨勢；當(dāng)反饋周期T為6～8 s 時(shí)，集群吞吐量在53 transaction/s 左右，吞吐量達(dá)到最大值；當(dāng)反饋周期T大于8 s 時(shí)，集群吞吐量呈下降趨勢。從圖4 可以看出：當(dāng)反饋周期T小于9 s 時(shí)，集群均衡情況較穩(wěn)定；當(dāng)反饋周期T大于9 s 時(shí)，集群均衡指數(shù)呈上升趨勢。因此，經(jīng)過綜合衡量后選取反饋周期T為7 s。

圖3 不同反饋周期下的集群吞吐量Fig.3 Cluster throughput under different feedback periods

圖4 不同周期下的集群均衡指數(shù)Fig.4 Cluster equilibrium index under different periods

2.3 算法流程

基于動(dòng)態(tài)負(fù)載反饋的提案分發(fā)優(yōu)化算法具體步驟如下：

步驟1測試計(jì)算影響權(quán)重α、反饋周期T，算法初始化。

步驟2在部署Hyperledger Fabric 的服務(wù)器上采集各節(jié)點(diǎn)的負(fù)載狀況，包括CPU 利用率、內(nèi)存利用率、磁盤使用率、網(wǎng)絡(luò)帶寬上傳/下載速率。

步驟3根據(jù)負(fù)載信息，利用式（1）量化當(dāng)前周期節(jié)點(diǎn)負(fù)載。

步驟4根據(jù)節(jié)點(diǎn)負(fù)載，利用式（4）計(jì)算當(dāng)前周期節(jié)點(diǎn)權(quán)值。

步驟5初始化加權(quán)輪詢算法。將當(dāng)前周期的節(jié)點(diǎn)權(quán)值作為加權(quán)輪詢算法的權(quán)重weight，并將currentWeight 設(shè)置為0。

步驟6根據(jù)加權(quán)輪詢算法為背書節(jié)點(diǎn)分發(fā)交易提案，在新的反饋周期T到來時(shí)，重新采集負(fù)載信息，跳轉(zhuǎn)至步驟3 開始新一輪算法。

3 測試與結(jié)果分析

在雙核、2 GB 內(nèi)存和60 GB 系統(tǒng)硬盤的阿里云服務(wù)器上搭建Hyperledger Fabric 環(huán)境，F(xiàn)abric 網(wǎng)絡(luò)中包括Orgl 和Org2 兩個(gè)組織，每個(gè)組織包含5 個(gè)對(duì)等節(jié)點(diǎn)。服務(wù)器配置如表1 所示。

表1 服務(wù)器配置Table 1 Server configuration

性能測試采用官方測試工具Caliper，通過編寫網(wǎng)絡(luò)配置文件、測試負(fù)載文件和測試基準(zhǔn)配置文件等對(duì)Hyperledger Fabric 優(yōu)化前后的查詢性能和交易性能進(jìn)行測試，測試指標(biāo)主要包括交易吞吐量和時(shí)延兩方面，其中吞吐量是指單位時(shí)間內(nèi)能處理的交易數(shù)，時(shí)延為單個(gè)交易處理時(shí)間。測試配置文件中設(shè)置客戶端數(shù)量為5，設(shè)置每輪的測試時(shí)間為30 s，采用Fixed load 速率控制器，分別對(duì)Hyperledger Fabric 原始方案和本文優(yōu)化方案的單機(jī)網(wǎng)絡(luò)交易和查詢的吞吐量進(jìn)行測試。測試結(jié)果如表2、表3 所示。

表2 原始方案性能測試結(jié)果Table 2 Performance test results of the original scheme

表3 優(yōu)化方案性能測試結(jié)果Table 3 Performance test results of the optimized scheme

由表2 中原始方案的測試結(jié)果可知：鏈碼交易的平均吞吐量為45.63 transaction/s，平均時(shí)延為0.193 s；鏈碼查詢的平均吞吐量為205.17 transaction/s，平均時(shí)延為0.033 s。由表3 中優(yōu)化方案的測試結(jié)果可知，鏈碼交易的平均吞吐量為53.63 transaction/s，平均時(shí)延為0.18 s；鏈碼查詢的平均吞吐量為237.67 transaction/s，平均時(shí)延為0.027 s。根據(jù)計(jì)算結(jié)果：采用優(yōu)化方案后鏈碼交易吞吐量較原始方案提高了17.53%，平均處理時(shí)延降低了6.7%；鏈碼查詢吞吐量較原始方案提高了15.84%，平均處理時(shí)延降低了18.2%；請求成功數(shù)量也有所提升。

4 結(jié)束語

本文針對(duì)Hyperledger Fabric 背書階段存在的性能瓶頸，提出一種基于動(dòng)態(tài)負(fù)載反饋的提案分發(fā)優(yōu)化方案。該方案綜合考慮多種性能指標(biāo)量化節(jié)點(diǎn)負(fù)載和節(jié)點(diǎn)權(quán)值，根據(jù)負(fù)載數(shù)據(jù)計(jì)算影響權(quán)重與反饋周期，并通過加權(quán)輪詢算法分發(fā)交易提案，實(shí)現(xiàn)背書節(jié)點(diǎn)負(fù)載的動(dòng)態(tài)均衡。測試結(jié)果表明，優(yōu)化方案相比于原始方案鏈碼交易和查詢的吞吐量更高且處理時(shí)延更短，同時(shí)證明了負(fù)載均衡算法應(yīng)用于Hyperledger Fabric 共識(shí)性能優(yōu)化的可行性。后續(xù)將對(duì)Hyperledger Fabric 共識(shí)中背書節(jié)點(diǎn)的隱私保護(hù)問題進(jìn)行研究，進(jìn)一步提升優(yōu)化方案的交易和查詢安全性和容錯(cuò)性。