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

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

0 概述

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

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

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

1 相關(guān)研究

1.1 負載均衡算法

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

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

1.2 Hyperledger Fabric

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

1.2.1 交易流程

Hyperledger Fabric 中的請求包括查詢請求（Query）和交易請求（Invoke）。查詢請求是讀取賬本但并不會修改賬本狀態(tài)的鏈碼調(diào)用，除了基于審計目的需要記錄訪問賬本日志之外，在通常情況下，客戶端不會提交這種只讀性事務(wù)進行排序、驗證和提交。交易請求根據(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ù)進行身份注冊，向區(qū)塊鏈網(wǎng)絡(luò)發(fā)送交易提案（proposal）至背書節(jié)點，交易提案中包括鏈碼信息、提交時間、客戶端簽名等信息。

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

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

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

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

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

1.2.2 性能分析

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

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

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

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

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

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

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

2.1 設(shè)計原理

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

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

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

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

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

2.2.1 負載指數(shù)

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

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

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

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

其中：Lai表示節(jié)點i當前的負載。

2.2.3 均衡指數(shù)

當達到理想狀態(tài)時，各節(jié)點負載需滿足：

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

2.2.4 影響權(quán)重

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

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

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

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

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

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

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

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

步驟6根據(jù)加權(quán)輪詢算法為背書節(jié)點分發(fā)交易提案，在新的反饋周期T到來時，重新采集負載信息，跳轉(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 兩個組織，每個組織包含5 個對等節(jié)點。服務(wù)器配置如表1 所示。

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

性能測試采用官方測試工具Caliper，通過編寫網(wǎng)絡(luò)配置文件、測試負載文件和測試基準配置文件等對Hyperledger Fabric 優(yōu)化前后的查詢性能和交易性能進行測試，測試指標主要包括交易吞吐量和時延兩方面，其中吞吐量是指單位時間內(nèi)能處理的交易數(shù)，時延為單個交易處理時間。測試配置文件中設(shè)置客戶端數(shù)量為5，設(shè)置每輪的測試時間為30 s，采用Fixed load 速率控制器，分別對Hyperledger Fabric 原始方案和本文優(yōu)化方案的單機網(wǎng)絡(luò)交易和查詢的吞吐量進行測試。測試結(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，平均時延為0.193 s；鏈碼查詢的平均吞吐量為205.17 transaction/s，平均時延為0.033 s。由表3 中優(yōu)化方案的測試結(jié)果可知，鏈碼交易的平均吞吐量為53.63 transaction/s，平均時延為0.18 s；鏈碼查詢的平均吞吐量為237.67 transaction/s，平均時延為0.027 s。根據(jù)計算結(jié)果：采用優(yōu)化方案后鏈碼交易吞吐量較原始方案提高了17.53%，平均處理時延降低了6.7%；鏈碼查詢吞吐量較原始方案提高了15.84%，平均處理時延降低了18.2%；請求成功數(shù)量也有所提升。

4 結(jié)束語

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