基于負載均衡算法的Hyperledger Fabric 共識機制研究

賀鵬飛，范鵬飛，尹千慧，王中訓，張桐敬，梁大偉

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

0 概述

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

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

本文針對Hyperledger Fabric 共識中背書階段存在的性能瓶頸，提出基于動態負載反饋的提案分發優化方案。該方案根據反饋周期T采集節點負載信息，利用加權輪詢算法分發交易提案至背書節點，以解決共識機制中背書階段提案分發方式導致的系統性能低下問題。

1 相關研究

1.1 負載均衡算法

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

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

1.2 Hyperledger Fabric

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

1.2.1 交易流程

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

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

Hyperledger Fabric 交易過程具體如下：

1）客戶端通過SDK 調用證書服務進行身份注冊，向區塊鏈網絡發送交易提案（proposal）至背書節點，交易提案中包括鏈碼信息、提交時間、客戶端簽名等信息。

2）背書節點在收到提案后，檢查客戶端簽名并確認提交者是否被授權執行該操作，根據提案內容調用并模擬執行交易（實際并不改變當前賬本的狀態），隨后背書節點調用背書系統鏈碼（Endorsement System Chaincode，ESCC），并根據節點身份對交易響應簽名，同時將簽名和背書執行結果發送至客戶端［25］。

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

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

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

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

1.2.2 性能分析

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

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

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

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

綜合以上分析得出，在不改變Hyperledger Fabric 網絡架構的前提下，合理選取區塊配置參數可以規避區塊大小導致的驗證階段性能瓶頸問題，從而將系統性能瓶頸定位到背書階段，因此本文設計基于動態負載反饋的提案分發優化方案以均衡背書節點性能，提高系統效率。

2 基于動態負載反饋的提案分發優化方案

在Hyperledger Fabric 共識機制的基礎上，設計一種基于動態負載反饋的提案分發優化方案。該方案周期性計算背書節點負載，通過動態反饋的負載均衡算法依據節點權值選取交易背書節點完成交易背書，實現了交易背書節點性能的均衡利用，提高了交易處理性能。

2.1 設計原理

在系統運行過程中，原有共識機制忽略了背書節點之間背書任務量的差異，容易導致節點處理性能失衡。考慮到所有節點都配置在Docker 容器中，Docker 容器共享宿主機的內核，在同一宿主機或多個宿主機配置相同的情況下，可以通過節點當前負載來衡量節點的剩余處理能力。因此，為了增強Hyperledger Fabric 集群的負載自適應能力，提出基于動態負載反饋的提案分發優化方案。

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

在該方案中，由于節點具有相同的配置，在實現方案效果的同時考慮算法復雜度對服務器性能的影響，因此選用加權輪詢算法實現對提案的分發。通過這種動態反饋的負載均衡機制，根據節點負載周期性修正節點權值，避免了加權輪詢算法中由于特殊權值產生的不均勻序列，從而實現了交易背書分配策略的動態調整，使背書節點的負載趨于均衡，并最終提升了系統的交易處理性能。基于動態負載反饋的提案分發優化方案流程如圖2 所示。

圖2 基于動態負載反饋的提案分發優化方案流程Fig.2 Process of optimization scheme of proposal distribution based on dynamic load feedback

2.2 參數設置

2.2.1 負載指數

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

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

2.2.2 節點權值

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

其中：Lai表示節點i當前的負載。

2.2.3 均衡指數

當達到理想狀態時，各節點負載需滿足：

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

2.2.4 影響權重

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

通過測試并計算得出各參數對于負載的影響權重分別為0.335 1、0.340 7、0.156 1、0.168 1，依次為CPU 利用率、內存利用率、磁盤使用率、網絡帶寬利用率的影響權重。

2.2.5 反饋周期

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

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

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

2.3 算法流程

基于動態負載反饋的提案分發優化算法具體步驟如下：

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

步驟2在部署Hyperledger Fabric 的服務器上采集各節點的負載狀況，包括CPU 利用率、內存利用率、磁盤使用率、網絡帶寬上傳/下載速率。

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

步驟4根據節點負載，利用式（4）計算當前周期節點權值。

步驟5初始化加權輪詢算法。將當前周期的節點權值作為加權輪詢算法的權重weight，并將currentWeight 設置為0。

步驟6根據加權輪詢算法為背書節點分發交易提案，在新的反饋周期T到來時，重新采集負載信息，跳轉至步驟3 開始新一輪算法。

3 測試與結果分析

在雙核、2 GB 內存和60 GB 系統硬盤的阿里云服務器上搭建Hyperledger Fabric 環境，Fabric 網絡中包括Orgl 和Org2 兩個組織，每個組織包含5 個對等節點。服務器配置如表1 所示。

表1 服務器配置Table 1 Server configuration

性能測試采用官方測試工具Caliper，通過編寫網絡配置文件、測試負載文件和測試基準配置文件等對Hyperledger Fabric 優化前后的查詢性能和交易性能進行測試，測試指標主要包括交易吞吐量和時延兩方面，其中吞吐量是指單位時間內能處理的交易數，時延為單個交易處理時間。測試配置文件中設置客戶端數量為5，設置每輪的測試時間為30 s，采用Fixed load 速率控制器，分別對Hyperledger Fabric 原始方案和本文優化方案的單機網絡交易和查詢的吞吐量進行測試。測試結果如表2、表3 所示。

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

表3 優化方案性能測試結果Table 3 Performance test results of the optimized scheme

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

4 結束語

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