一种典型场景区块链平台性能测试方法及应用研究

李 政，杨 丹，董金德，李 宁，毕靖文

(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区块链的公路工程交通产品质量控制平台的性能测试展开研究及量化评估分析，建立了一个面向工程领域具体行业场景下的区块链应用平台性能测试模型、测试架构及测试环境和以吞吐率、读吞吐量、写吞吐量、响应时间、区块生成速率以及交易延迟作为性能测试指标的方法体系，系统研究了节点数、出块时间、区块最大交易条数、区块最大字节数、区块首选字节数以及总连接数等不同因素对区块链应用平台服务性能的影响，并对产生原因进行了一定的分析综述。值得说明的是，论文选取的各影响因素最优值在实际应用过程中能够支撑业务开发及运行取得较好性能，系统运行稳定，服务响应及时，用户反馈良好。最后，论文研究成果对现有主流区块链平台在不同行业场景上的开发应用和系统服务性能优化提升等工作可提供相关理论支撑和参考。