基于负载均衡算法的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 共识中背书节点的隐私保护问题进行研究，进一步提升优化方案的交易和查询安全性和容错性。