CN110580206B - 用于区块链***的压力测试的方法、介质和控制装置 - Google Patents

Abstract

一种用于区块链***的压力测试的方法，包括：在单个服务器上按照区块链的初始配置参数部署初始数量的记账节点模块、共识节点模块以及应用程序编程接口服务器APIServer模块；经由APIServer模块基于合约对部署在单个服务器上的区块链进行多轮测试，其中，在每轮测试中并发地对一个记账节点模块进行测试，并调整针对各轮测试的并发数直到该并发数使得记账节点模块、共识节点模块以及APIServer模块中的一个模块的***资源使用率基本饱和为止；和基于该模块的***资源使用率基本饱和时各模块的***资源使用率确定用于典型压力测试场景的记账节点模块数量与共识节点模块数量之间的比例，并基于在所述多轮测试中检测到的各模块对CPU的多核利用率确定各模块对服务器的占用关系。

Description

用于区块链***的压力测试的方法、介质和控制装置

技术领域

本公开涉及用于区块链***，特别是同盟链***的压力测试的方法、计算机可读介质以及控制装置。

背景技术

近年来，关于区块链的技术发展迅速。已经开发出了应用于各种领域的区块链***。区块链一般可以表示一种分布式、去中心化的网络数据库***，在区块链上发生的交易涉及区块链上的所有节点的参与。

为了更好地在实际实现中部署区块链，需要对区块链***进行测试，特别是进行压力测试。因此，需要一种可以快速搭建区块链***的压力测试场景，并在该场景下进行压力测试的方法。

发明内容

本公开提供了一种用于区块链***的压力测试的方法、计算机可读介质以及控制装置。

根据本公开的一个方面，提供了一种用于区块链***的压力测试的方法，包括：在单个服务器上按照区块链的初始配置参数部署初始数量的记账节点模块、共识节点模块以及应用程序编程接口服务器APIServer模块；经由APIServer模块基于合约对部署在单个服务器上的区块链进行多轮测试，其中，在每轮测试中并发地对一个记账节点模块进行测试，并且调整针对各轮测试的并发数直到该并发数使得记账节点模块、共识节点模块以及APIServer模块中的一个模块的***资源使用率基本饱和为止；和基于所述一个模块的***资源使用率基本饱和时各模块的***资源使用率确定用于典型压力测试场景的记账节点模块数量与共识节点模块数量之间的比例，并基于在所述多轮测试中检测到的各模块对CPU的多核利用率确定各模块对服务器的占用关系。

根据本公开的另一个方面，提供了一种存储有计算机可执行指令的计算机可读介质，当所述计算机可执行指令被处理器执行时，使得所述处理器执行如上所述的方法。

根据本公开的又一个方面，提供了一种用于区块链***的压力测试的控制装置，所述控制装置包括存储有计算机可执行指令的存储器和处理器，当所述计算机可执行指令被所述处理器执行时，使得所述装置执行如上所述的方法。

附图说明

并入说明书中并且构成说明书的一部分的附图示出了本公开的实施例，并且与描述一起用于说明本公开的原理。

图1是根据本公开的用于区块链***的压力测试的方法的示意性流程图；

图2是根据本公开的对部署在单个服务器上的区块链进行测试的示意图；

图3是根据本公开的用于区块链***的压力测试的方法的进一步的示意性流程图；

图4是说明根据本公开的测试示例所采用的区块链架构的示意图；

图5是说明根据本公开的测试示例所采用的典型测试***的示意图；

图6是可以实现根据本公开的实施例的计算机设备的示例性配置图。

具体实施方式

下面将参考附图来详细描述本公开的优选的实施例。不是本公开必需的细节和功能被省略，以便不会混淆本公开的理解。

请注意，类似的参考数字和字母指的是图中的类似的项目，因而一旦在一幅图中定义了一个项目，就不需要在之后的图中讨论了。

本公开中，术语“区块链”包括但不限于关于分布式存储、点对点网络、共识机制、加密算法等的技术。术语“同盟链”或“联盟链”通常是指由多个组织或机构通过联盟的形式组建的区块链，同盟参与者之间通过契约或其他形式建立了信任和共识机制，构造区块和链接功能仅限于联盟参与者，访问权限可以对外采取限制性开放。特别地，本公开的技术典型地可用于同盟链，但该技术也可用于其他类型的区块链，例如公有链和私有链。

如已经在背景技术部分介绍的，区块链具有分布式、去中心化的特点，在区块链上发生的交易涉及区块链上的所有节点的参与。区块链上的节点一般例如包括共识节点和业务节点。共识节点例如运行共识算法，使得在整个区块链对区块达成共识的情况下参与区块创建。业务节点例如可以是实际发起区块链上的交易的节点，并且在不同的区块链架构下可以具有不同的名称。在本公开中，以超级账本的区块链架构为例进行说明，在该架构下，一般将业务节点称为记账(peer)节点。在本文下面的描述中，采用术语记账节点来表示业务节点。要指出的是，本公开的技术还可以应用于其他架构的区块链，并且术语“记账节点”旨在表示区别于共识节点的在区块链上发起交易的业务节点而并非旨在限定区块链的架构。

本公开的技术的发明人特别注意到对于区块链***，可能存在影响其性能(例如每秒交易数TPS)的瓶颈模块。当瓶颈模块的处理能力饱和时，即使改变其他模块和/或节点(例如共识节点和记账节点)的数量比例，区块链***的性能可能依然处于饱和状态。因此，需要一种能够确定导致区块链***的性能瓶颈的瓶颈模块，以及在该模块饱和时其他模块和/或节点的数量比例的方法，以便为实际区块链***的部署提供参考。

压力测试一般表示在正常***资源的情况下对***中的节点发起大并发的测试，从而挖掘***的每秒交易数TPS和/或每秒查询数QPS。

传统地，对于区块链，特别是同盟链的压力测试，一般采用类似于集中式***的压力测试方式，只对区块链网络中的某个单节点发起大并发数的读写测试请求。但是，由于区块链的分布式特性，对单个节点发起的并发读写测试请求并不是由一个节点来集中处理的，相反，由测试请求带来的压力分布在整个区块链上，这使得通过只对区块链网络中的某个单节点发起大并发数的读写测试请求而得到的TPS和/或QPS是不准确的甚至是无效的。因此，需要一种能够较为准确地测量区块链***的TPS和/或QPS的方法，以便为实际应用中的限流管控提供数据支持。

此外，传统的对于区块链的压力测试一般仅仅对区块链底层直接发起测试，而不是经由应用层(例如经由应用程序编程接口服务器APIServer)对区块链进行测试。然而，在实际应用中，实际的交易都需要经由应用层来实现。鉴于此，需要一种能够对整个区块链***(包括应用层)进行压力测试的方法。

下面，将参考附图对本公开的方案进行详细描述。

首先，参考图1说明根据本公开的用于区块链***的压力测试的方法10。

如图1所示，该方法在步骤S100处开始。

在步骤S102处，在单个服务器上部署区块链。这里，在单个服务器上部署区块链表示按照区块链的初始配置参数在单个服务器上部署初始数量的记账节点模块、共识节点模块以及应用程序编程接口服务器APIServer模块，以构成测试用的单服务器上的完整区块链***。

区块链的配置参数例如可至少包括日志级别、块大小、安全传输层协议的开启状态、共识算法、P2P算法、记账算法以及加密算法中的一个或多个，不同的配置参数可能会在TPS、CPU使用率、内存使用率、I/O操作数等方面影响区块链***的性能。

具体而言，日志级别(例如，从低到高的日志级别可以包括ALL、TRACE、DEBUG、INFO、WARN、ERROR、FATAL、OFF等)可以表示以什么样的详细程度对区块链运行期间的事件进行记录，例如，高日志级别可以对应于较少事件的记录，从而对应较不频繁的输入输出(I/O)操作，低日志级别可以对应于较多事件的记录，从而对应较频繁的I/O操作。块大小例如表示一个块中包含的交易数量。TLS协议用于为通信提供诸如保密性和数据完整性之类的安全性，TLS的开启与否会影响区块链网络中消息的传输量的大小以及由加密操作所导致的CPU使用率差异等。配置参数中涉及的“算法”具备广义上的含义，可以表示借助各种算法而实现的具体技术、协议等，而不仅仅是构成该技术或协议的狭义上的算法本身，此外不同“算法”可能具有不同的复杂度，可能会不同程度地影响区块链的性能。例如，共识算法可以包括Paxos、Raft、PBFT(实用拜占庭容错)以及自定义算法等。P2P算法可以包括Kademlia网络，Gossip协议或自定义的P2P算法等。记帐算法可以包括采用levelDB,couchDB等的KV(Key-value，键-值)数据库等。加密算法可以包括哈希算法、椭圆曲线算法、零知识证明、SHA-256等。

根据本公开，区块链的初始配置参数可以是随机选择的或预先确定的。实际上，对于作为测试目标的一些真实区块链***应用场景，可能对配置参数有一定的要求。例如，当真实区块链***的应用场景对安全要求比较高时，可能要求必须开启TLS协议并采用安全度较高的加密算法。再例如，真实区块链***的应用场景可能对容错性有一定的要求，例如，可能要求能容错故障节点和作恶节点，这种情况下，只能容错故障节点的Raft算法可能并不适用。鉴于此，对于这些对配置参数有具体要求的应用场景，可以利用基于该应用场景而预先确定的配置参数来在单个服务器上部署测试用区块链***。而对于其他没有特殊要求的实际应用场景，可以随机选择所述配置参数。

根据本公开，对于记账节点模块、共识节点模块以及APIServer模块的初始数量分别为2个、1个以及1个。按照这种初始数量来部署各个模块，可以形成可运行S104处的多轮测试的最简单的区块链***。利用这种最简单配置，可以有效且快速的搭建测试***并开始测试。

进一步地，各个模块可以按照Docker容器方式部署，这使得能够降低共用资源和/或宿主机资源调度产生的影响。

要说明的是，如本领域所了解的，部署区块链***还包括在区块链上的各个节点模块上存储合约。在区块链领域中，合约一般表示区块链上的各个节点之间达成的能够自动执行的协议，并且基于特定的触发事件而自动执行。在本发明的测试用区块链中，可以采用能够对区块链上的各个节点施加压力的最简单的“合约”，例如，该“合约”可以规定基于测试期间经由APIServer对某记账节点发起的请求而按照“键-值”对的形式将数据写入区块链(即，经由共识节点进行共识并将该数据同步到区块链上的所有节点)。基于该示例合约的具体测试操作将在下文进一步说明。

继续参考图1，在S104处经由APIServer模块基于合约对部署在单个服务器上的区块链进行多轮测试，其中，在每轮测试中并发地对一个记账节点模块进行测试，并且调整针对各轮测试的并发数直到该并发数使得记账节点模块、共识节点模块以及APIServer模块中的一个模块的***资源使用率基本饱和为止。例如，***资源使用率可以包括CPU使用率或内存使用率。

下面参考图2对S104处执行的测试进行详细说明。

如图2所示，对于每次测试，可以由压力发射机经由APIServer模块对某个记账节点模块发送基于合约的测试请求。压力发射机可以是专用于为区块链***发送测试请求的独立于部署区块链的服务器的设备。例如，压力发射机可以是与部署区块链的服务器分开的另一台服务器或计算机。在采用上述示例合约的情况下，对于每次测试，可以由压力发射机经由APIServer模块对某个记账节点模块发送按照“键-值”对的形式将数据写入区块链的请求。如图2所示，该写入请求可以是HTTP POST请求。要说明的是，还可以采用基于其他协议的请求，只要能够对记账节点模块发送数据写入请求即可。由于记账节点之间是对等的关系，因此可以对随机选择的一个记账节点模块进行请求，并且在多轮测试期间，可以不更换被测记账节点。要指出的是，由于对于每轮测试以并发的形式对一个记账节点模块进行数个测试请求，因此，为了避免并发写操作锁导致的延迟影响测试的准确性，对于并发的多个“键-值”对写入请求，各个写入请求之间的键的取值不同，例如可以采用随机的键取值以防止对相同键进行过多次数的写入而触发并发写操作锁。对于“键-值”中值的取值，没有特殊的要求，例如，可以采用固定值、随机值或者按照规律或不规律的步长递增的取值。

在多轮测试期间，随着调整测试请求的并发数(下文中也称为并发请求数或并发的测试请求数)，可以检测到当并发数增长到一定程度时，记账节点模块、共识节点模块以及APIServer模块中的一个模块的***资源使用率(例如CPU使用率或内存使用率)趋于稳定(例如，大约稳定在90％处)，这时，可以认为该模块的***资源使用率基本饱和，并且该模块可以被视为区块链***的瓶颈模块。典型地，瓶颈模块可能是记账节点模块或APIServer模块。当检测到某个模块的***资源使用率基本饱和时，可以检测此时记账节点模块的***资源使用率以及共识节点模块的***资源使用率。例如，此时可以检测记账节点模块和共识节点模块的与达到饱和的***资源使用率相同类型(例如CPU使用率或内存使用率)的***资源使用率。换句话说，例如，在检测到某个模块的CPU使用率基本饱和的情况下，检测此时记账节点模块的CPU使用率和共识节点模块的CPU使用率，或者例如，在检测到某个模块的内存使用率基本饱和的情况下，检测此时记账节点模块的内存使用率和共识节点模块的内存使用率。

要指出的是，在S104的多轮测试期间获得的各模块的***资源使用率以及相应的并发数仅仅是测试环境下获得的估计值而非实际应用环境下的确切值，其作用主要在于为搭建典型测试场景(即利用多个服务器搭建的测试用区块链***)以及搭建实际应用环境给出理论指导。

根据本公开，在S104处的多轮测试期间，还可以检测各个模块对CPU的多核利用率。在本文中，模块对CPU的多核利用率可以表示该模块是否能够充分利用CPU多核的优势。例如，对于能够充分利用CPU多核优势的模块，当针对该模块的压力上升时，可以检测到该模块对CPU的各个核的使用率均有一定的增加，而对于不能充分利用CPU多核优势的模块，当针对该模块的压力上升时，仅可以检测到该模块对CPU的一个核的使用率有一定的增加而其他核的使用率并没有明显变化。

根据本公开，随着对记账节点模块的并发请求数的增加，各个模块的压力均相应地增加。可以在S104处的多轮测试期间，检测各模块对CPU各个核的使用率是否会随着并发请求数的增长而均有所增长，如果对于该模块，仅CPU的一个核的使用率会随着并发请求数的增加而增加，那么可以认为该模块的CPU多核利用率低，即该模块难以利用CPU多核优势，相对比地，如果对于该模块CPU的各个核的使用率均会随着并发请求数的增加而增加，那么可以认为该模块的CPU多核利用率较高，即该模块能够充分利用CPU多核优势。

继续参考图1，在S106处，基于瓶颈模块的***资源使用率基本饱和时各模块的***资源使用率确定用于典型压力测试场景的记账节点模块数量与共识节点模块数量之间的比例，并基于在所述多轮测试中检测到的各模块对CPU的多核利用率确定各模块对服务器的占用关系。

具体而言，用于典型压力测试场景的记账节点模块数量与共识节点模块数量之间的比例可以与瓶颈模块的***资源使用率基本饱和时记账节点模块的***资源使用率与共识节点模块的***资源使用率之间的比例相同。这里的“比例相同”可以具有较为广义的含义。例如，由于***资源使用率之间的实际比例很可能并非是整数比，因此，可以适当地对记账节点模块数量与共识节点模块数量之间的比例进行取整(利用四舍五入或者简单地上/下取整)。

确定各模块对服务器的占用关系可以包括例如基于各模块对CPU的多核利用率，将能够充分利用CPU多核优势的模块确定为适于单独部署在一个服务器上，和将难以利用CPU多核优势的两个模块确定为适于部署在同一个服务器上。

该方法10在S108处结束。

上面已经参考图1、2说明了根据本公开的用于区块链***的压力测试的方法。要指出的是，图1中的各个步骤仅仅是示例性的，该方法还可以包括除上述步骤之外的其他步骤。

例如，在基于初始配置参数进行多轮并发测试直到瓶颈模块的***资源使用率基本饱和为止并检测此时的各模块的***资源使用率后，还可以附加地进行多轮进一步的测试，在进一步的测试期间，可以对部署在单个服务器上的区块链调整其配置参数，并进行进一步的检测。

具体而言，可以检测与不同的配置参数相对应的各模块的***资源使用率和使记账节点模块、共识节点模块以及APIServer模块中的一个模块的***资源使用率基本饱和的并发数。基于所述检测，可以将与最佳并发数相对应的配置参数确定为用于典型压力测试场景的配置参数。与最佳并发数相对应的配置参数例如可以是与最大并发数相对应的配置参数。与最佳并发数相对应的配置参数还可以是在相同的最大并发数情况下与较低的***资源使用率相对应的配置参数。

此外，还可以基于上述检测将与最佳并发数相对应的配置参数下的记账节点模块、共识节点模块和APIServer模块中的一个模块的***资源使用率基本饱和时记账节点模块与共识节点模块之间的***资源使用率的比例确定为用于典型压力测试场景的记账节点模块数量与共识节点模块数量之间的比例。不同配置参数下的瓶颈模块可能是相同或不同的。因此，这里在进一步的测试期间检测到的瓶颈模块可能与对利用初始配置参数部署的区块链的测试下检测到的瓶颈模块相同或不同。要指出的是，检测瓶颈模块的目的主要在于确定***达到性能瓶颈时记账节点模块数量与共识节点模块数量之间的比例关系，因此具体哪个模块的***资源使用率达到饱和并不重要，只要检测此时记账节点模块与共识节点模块之间的***资源使用率的比例以确定其数量比例即可。

进一步而言，如果存在与最佳并发数对应的多种配置参数，则可以根据与不同配置参数对应的记账节点模块与共识节点模块之间的***资源使用率的多个比例来确定记账节点模块数量与共识节点模块数量之间的最大概率的比例。例如，存在四种与最佳并发数对应的配置参数，并且分别检测到与各种配置参数相对应的记账节点模块与共识节点模块之间的四个***资源使用率比：{8/1，8/1，9/1，7/1}，此时，可以确定用于典型压力测试场景的记账节点模块数量与共识节点模块数量之间的最大概率的比例为8/1。

再例如，在基于初始配置参数进行多轮并发测试直到瓶颈模块的***资源使用率基本饱和为止并检测此时的各模块的***资源使用率之后附加地进行的多轮进一步测试期间，还可以适当地调整记账节点模块的数量，并检测与不同记账节点模块数量对应的瓶颈模块达到饱和时记账节点模块与共识节点模块之间的***资源使用率比，并根据测得的多个***资源使用率比来确定记账节点模块数量与共识节点模块数量之间的最大概率的比例。与仅仅在一个共识节点模块以及两个记账节点模块的情况下进行测试相比，调整记账节点模块的数量可以使得最终确定的记账节点模块数量与共识节点模块数量之间的比例更准确。

进一步地，还可以在上述进一步的测试期间既调整配置参数又调整记账节点模块的数量。

上文已经描述了对部署在单个服务器上的区块链***进行测试的具体操作。如图3所示，根据本公开，对区块链***的压力测试还可以包括在对部署在单个服务器上的区块链***进行测试之后，按照单个服务器上的测试结果在多个服务器上部署区块链以构建典型压力测试场景，并对部署在多个服务器上的区块链***进行测试。

可以基于通过单个服务器上的区块链测试所确定的用于典型压力测试场景的记账节点模块数量与共识节点模块数量之间的比例以及各模块对服务器的占用关系在多个服务器上部署各个模块。如上文所解释的，可以按照与瓶颈模块的***资源使用率基本饱和时记账节点模块的***资源使用率与共识节点模块的***资源使用率之间的比例来配置记账节点模块与共识节点模块的数量，并且可以基于各模块对CPU的多核利用率，将能够充分利用CPU多核优势的模块单独部署在一个服务器上，和将难以利用CPU多核优势的两个模块部署在同一个服务器上。

特别地，为了更加符合实际应用情况，每个节点模块(例如共识节点模块和记账节点模块)可以部署在分开的服务器上，即，一般不将两个节点模块(例如两个记账节点模块或一个记账节点模块和一个共识节点模块)部署在同一服务器上，并且优选地，共识节点模块不与APIServer模块部署在同一服务器上。例如，当通过单服务器上的区块链测试确定APIServer模块和记账节点模块的CPU多核利用率均较低时，可以按照与记账节点模块相同的数量配置APIServer模块，并且在每个服务器上部署一个APIServer模块和一个记账节点模块。再例如，当通过单服务器上的区块链测试确定APIServer模块的CPU多核利用率高时，可以仅利用一个单独的服务器部署一个APIServer模块作为布置在多个服务器上的区块链的应用层接口模块，并且各个记账节点模块可以被部署在单独的服务器上，无论记账节点模块是否能够充分CPU多核优势。

在多个服务器上部署了区块链***之后，可以经由APIServer模块基于合约对部署在多个服务器上的区块链进行多轮并发测试，并检测各轮并发测试下的每秒交易数TPS和/或各个服务器的***资源使用率，其中在每轮测试中并发地对多个记账节点模块进行测试并且并发地对同一记账节点模块进行测试，并且其中对于各轮并发测试的并发数不同。对部署在多个服务器上的区块链***的测试可以利用与针对部署在单个服务器上的区块链***的测试中使用的合约相同的合约来进行。例如，类似于单服务器上的测试，对于每次测试，可以由压力发射机经由APIServer对某个记账节点模块发送按照“键-值”对的形式将数据写入区块链的请求。压力发射机可以是独立于部署区块链***的多个服务器的单独的服务器或计算机。

在多个服务器上进行的区块链***的测试的主要目的在于挖掘区块链***的最大TPS。根据本公开，通过调整并发数来测试该并发数下区块链***的TPS或某个***资源使用率下的TPS。这里，“并发数不同”具有两层含义，一方面，各轮并发测试所针对的记账节点模块的数量不同，另一方面，对于单个记账节点模块的并发的测试请求数不同。可以理解的是，对于相继的两轮测试，可以保持测试所针对的记账节点模块的数量并调整对于单个记账节点模块的并发的测试请求数，或者可以保持对于单个记账节点模块的并发的测试请求数并调整测试所针对的记账节点模块的个数，或者也可以同时改变这两方面的并发数，只要能够充分测试不同并发数下区块链***的TPS即可。

此外，在多个服务器上进行的区块链***的测试还可以针对QPS来进行，这种情况下，可以修改合约，使得基于每次测试，请求读取存储在区块链上的数据。例如，合约可以使得对于每次测试，请求读取由“键”识别的对应“值”。

上面已经参考图1-3说明了根据本公开的用于区块链***的压力测试的方法。

根据本公开，在单个服务器上部署区块链***可以使得对于各个模块的***环境(例如，CPU、内存、网络带宽等)一致，因此可以方便地分析比对各个模块对于各个***资源的消耗程度，而不存在由于硬件环境不一致而导致的资源消耗程度的差异，进而可以快速且有效的确定区块链***中的瓶颈模块，并相应地确定用于典型压力测试场景或实际应用场景的记账节点模块数量与共识节点模块数量之间的比例、各模块对服务器的占用关系以及区块链的配置参数等。

根据本公开，通过对部署在多个服务器上的区块链(即典型压力测试场景下的区块链)进行多轮并发数不同的测试，可以有效地挖掘***的最大TPS，从而为限流管控提供数据支持。例如，当经过测试发现在一定的***资源使用率下该区块链***的TPS不够大时，可以考虑在实际应用该区块链***时，不在该区块链***上配置交易写入频繁的应用，或者可以考虑对该区块链***上的交易写入进行进一步地限制。

根据本公开，不是对区块链底层架构直接进行测试，而是通过作为区块链底层与应用层之间的接口的APIServer模块进行测试，这使测试可以更接近实际应用情况以获得更准确的数据。此外，由于APIServer模块也可能成为区块链***中的瓶颈模块，在考虑APIServer模块对***资源的占用率的情况下确定区块链***的部署方式(例如各节点模块数量之间的比例关系以及各模块对服务器的占用情况)，可以获得更具实际指导意义的部署方案。

上文已经说明了本公开的一般方案及其优点。下面，将介绍利用本公开的方法进行的测试示例。

首先，参考图4简要介绍利用本公开的方法进行的测试示例中使用的区块链架构。

在该测试示例中，采用超级账本(Hyperledger)作为区块链架构。如图4所示，在超级账本的底层架构主要由成员资格服务、区块链服务以及链式代码服务这三部分构成。成员资格服务的功能是管理网络的身份、隐私权和保密性之类，该服务并不是本测试示例关注的重点，这里不再详细描述。链式代码服务的功能主要是为节点提供能够执行链式代码的环境，例如，链式代码服务可以采用Docker来运行链式代码。超级账本中采用的术语“链式代码”可以理解为一段运行于区块链的节点上的去中心化的程序，其含义可以与上文中说明的“合约”等价。区块链服务的主要功能是生成并管理区块链的分布式账本。区块链服务可以主要由共识节点模块与记账节点模块这两个节点模块来实现。共识节点模块上可以实现共识算法并且可以实现共识管理器，共识管理器可以定义共识算法与超级账本的其他组件之间的接口；记账节点模块上可以定义点对点(P2P)协议并且可以实现账本存储功能等。

如图4所示，超级账本架构还包括应用层，可以借助应用程序编程接口服务器(APIServer)来配置、调用和/或管理超级账本架构的底层服务模块，其中，APIServer可以借助软件开发包(SDK)来开发。例如，借助应用层，可以方便地访问成员资格、区块链、交易、链式代码等相关的内容。

下面，将介绍在超级账本架构下使用本公开的方法的测试示例的具体操作过程。

首先，在单个服务器上按照区块链的初始配置参数部署2个记账节点模块(peer)、1个共识节点模块(orderer)以及1个应用程序编程接口服务器模块(APIServer)。初始配置参数的设置如表1所示，其中，对于共识算法，可以采用zookeeper+kafka来实现超级账本中的共识(zookeeper是一种分布式应用程序协调服务，其可以提供一种Paxos共识算法，kafka是用于业务逻辑的一种分布式消息队列)，并且其中，除P2P算法不可配置之外，其他的配置参数在该测试示例中都可以通过配置而选取与表1中所列的参数不同的其他可用参数。

共识算法	Zookeeper+kafka
		加密算法	SHA-256,椭圆曲线数字签名
记帐算法	levelDB数据库
		P2P算法	Gossip协议和gRPC通道
APIServer实现	Nodejs
		日志级别	INFO
块大小	99M
		TLS开启状态	关闭

表1

随后，可以利用如图2所示的方法，对一个记账节点模块进行多轮并发测试，其中，在每轮测试中并发地对一个记账节点模块进行将“键-值”数据写入区块链的请求。该测试示例中使用的服务器以及压力发射机的配置如表2所示。

表2

随着并发数的增加，检测到APIServer模块的CPU使用率首先达到饱和。此时，检测到记账节点模块与共识节点模块的CPU使用率之间的比例为8:1。因此，将用于典型压力测试场景的记账节点模块数量与共识节点模块数量之间的比例确定为8:1。此外，随着并发数的增加，检测到APIServer模块以及记账节点模块均不能利用CPU多核优势，因此，确定在典型压力测试场景下，将一个APIServer模块与一个记账节点模块配置在同一台服务器上，而将共识节点模块配置在单独的服务器上。

接下来，基于在单个服务器上的测试结果，在多个服务器上部署各个模块。图5示出了该测试示例下在多个服务器上部署的典型测试***的示意图。如图5所示，分别在八个服务器上部署八对APIServer模块和记账节点模块，在单独的服务器上部署一个共识节点模块，并且压力发射机为单独的服务器。类似于单个服务器上的测试，所使用的压力发射机以及各个服务器的配置如表2所示。

在该测试示例中，在压力发射机上利用测试脚本经由APIServer模块对部署在多个服务器上的区块链进行多轮并发测试，其中在每轮测试中并发地对多个记账节点模块进行向区块链写入“键-值”数据的请求，并且并发地对同一记账节点模块进行数个写入请求，并且其中对于各轮并发测试的并发数不同。附加地，在该测试实例中，还并发地对记账节点模块进行读取请求，例如请求读取由“键”识别的对应“值”。

在该测试示例中，检测到在对每个APIServer模块起15个线程，发起300秒时长的合约调用请求时，该区块链***的TPS达到最佳值280(交易/秒)，此时每个APIServer模块的CPU使用率峰值都达到90％以上，共识节点模块的CPU使用率达到约80％，此外，还检测到此时的QPS为343(查询/秒)。

图6示出了可以实现根据本公开的实施例的计算机设备2000的示例性配置。计算机设备2000是可以应用本公开的用于区块链***的压力测试的控制装置的硬件设备的实例。计算机设备2000可以是被配置为执行处理和/或计算的任何机器。计算机设备2000可以是但不限制于工作站、服务器、台式计算机、膝上型计算机、平板计算机、个人数据助手(PDA)、智能电话、车载计算机或以上组合。

如图6所示，计算机设备2000可以包括可能经由一个或多个接口与总线2002连接或通信的一个或多个元件。例如，计算机设备2000可以包括总线2002、一个或多个处理器2004、一个或多个输入设备2006以及一个或多个输出设备2008。总线2002可以包括但不限于，工业标准架构(Industry Standard Architecture，ISA)总线、微通道架构(MicroChannel Architecture，MCA)总线、增强ISA(EISA)总线、视频电子标准协会(VESA)局部总线、以及外设组件互连(PCI)总线等。一个或多个处理设备2004可以是任何种类的处理器，并且可以包括但不限于一个或多个通用处理器或专用处理器(诸如专用处理芯片)。输入设备2006可以是能够向计算机设备输入信息的任何类型的输入设备，并且可以包括但不限于鼠标、键盘、触摸屏、麦克风和/或远程控制器。输出设备2008可以是能够呈现信息的任何类型的设备，并且可以包括但不限于显示器、扬声器、视频/音频输出终端、振动器和/或打印机。计算机设备2000还可以包括或被连接至非暂态存储设备2010，该非暂态存储设备2010可以是任何非暂态的并且可以实现数据存储的存储设备，并且可以包括但不限于盘驱动器、光存储设备、固态存储器、软盘、柔性盘、硬盘、磁带或任何其他磁性介质、压缩盘或任何其他光学介质、ROM(只读存储器)、RAM(随机存取存储器)、缓存存储器和/或任何其他存储芯片或模块、和/或计算机可以从其中读取数据、指令和/或代码的其他任何介质。非暂态存储设备2010可以与任何接口可拆卸地连接。非暂态存储设备2010可以具有存储于其上的、用于实现前述经由双层联盟链进行交易的方法和/或步骤的数据/指令/代码。计算机设备2000还可以包括通信设备2012，该通信设备2012可以是能够启用与外部装置和/或网络通信的任何种类的设备或***，并且可以包括但不限于调制解调器、网络卡、红外线通信设备、无线通信设备和/或芯片集(诸如蓝牙^TM设备、1302.11设备、WiFi设备、WiMax设备、蜂窝通信设施等)。

计算机设备2000还可以包括工作存储器2014。该工作存储器2014可以是能够存储对于处理器2004有用的指令和/或数据的任何类型的工作存储器，并且可以包括但不限于随机存取存储器(RAM)和只读存储器(ROM)。

位于上述工作存储器上的软件元件可以包括但不限于操作***2016、一个或多个应用程序2018、驱动器和/或其他数据和代码。上述一个或多个应用程序2018可以包括用于控制执行如上所述的用于区块链***的压力测试的方法的指令。可以通过读取和执行一个或多个应用程序2018的处理器来控制执行根据本公开的用于区块链***的压力测试。更具体地，可以通过应用程序2018来控制在服务器上配置各个模块，例如，这可以通过控制在相应服务器上调用相应的模块代码来实现。此外，还可以通过应用程序2018来控制测试脚本的运行，例如合约的运行。进一步地，还可以通过应用程序2018来控制检测相应服务器上的相应的***资源使用率以及CPU多核利用率等，并进行例如***资源使用率比例的计算等。软件元件的指令的可执行代码或源代码可以存储在非暂态计算机可读存储介质(诸如如上所述的存储设备2010)中，并且可以通过编译和/或安装读入工作存储器2014中。还可以从远程位置下载软件元件的指令的可执行代码或源代码。此外，工作存储器中还可以存储参数配置文件，以便指定各个操作参数和/或数据的存储位置等。

应当理解，可以根据特定要求进行变型。例如，可以使用定制的硬件和/或特定元件可以以硬件、软件、固件、中间件、微代码、硬件描述语言或其任何组合的方式实现。此外，可以采用与其他计算机设备(诸如网络输入/输出设备)的连接。例如，本公开的方法和设备中的一些或全部可以根据本公开通过使用汇编语言编程硬件(例如，包括现场可编程门阵列(FPGA)和/或可编程逻辑阵列(PLA)的可编程逻辑电路)或软件编程语言(例如Golang，C++，java等)来实现。

应当进一步理解，计算机设备2000的元件可以分布在整个网络上。例如，可以在使用一个处理器执行一些处理的同时，使用其他远程处理器执行其他处理。计算机***2000的其他元件也可以类似地分布。因此，计算机设备2000可以被理解为在多个地点执行处理的分布式计算***。

可以通过许多方式来实施本公开的方法和设备。例如，可以通过软件、硬件、固件、或其任何组合来实施本公开的方法和设备。上述的方法步骤的次序仅是说明性的，本公开的方法步骤不限于以上具体描述的次序，除非以其它方式明确说明。此外，在一些实施例中，本公开还可以被实施为记录在记录介质中的程序，其包括用于实现根据本公开的方法的机器可读指令。因而，本公开还覆盖存储用于实现根据本公开的方法的程序的记录介质。

虽然已通过示例详细展示了本公开的一些具体实施例，但是本领域技术人员应当理解，上述示例仅意图是说明性的而不限制本公开的范围。本领域技术人员应该理解，上述实施例可以在不脱离本公开的范围和实质的情况下被修改。本公开的范围是通过所附的权利要求限定的。

Claims (8)

1.一种用于区块链***的压力测试的方法，包括：

在单个服务器上按照区块链的初始配置参数部署初始数量的记账节点模块、共识节点模块以及应用程序编程接口服务器APIServer模块；

经由APIServer模块基于合约对部署在单个服务器上的区块链进行多轮测试，其中，在每轮测试中并发地对一个记账节点模块进行测试，并且调整针对各轮测试的并发数直到该并发数使得记账节点模块、共识节点模块以及APIServer模块中的一个模块的***资源使用率基本饱和为止，其中在所述多轮测试期间检测到当并发数增长到一定程度时记账节点模块、共识节点模块以及APIServer模块中的一个模块的***资源使用率趋于稳定时，认为该模块的***资源使用率基本饱和；和

基于所述一个模块的***资源使用率基本饱和时各模块的***资源使用率确定用于典型压力测试场景的记账节点模块数量与共识节点模块数量之间的比例，并基于在所述多轮测试中检测到的各模块对CPU的多核利用率确定各模块对服务器的占用关系，其中，

***资源使用率包括CPU使用率或内存使用率，并且其中

用于典型压力测试场景的记账节点模块数量与共识节点模块数量之间的比例与所述一个模块的***资源使用率基本饱和时记账节点模块的***资源使用率与共识节点模块的***资源使用率之间的比例相同；和

基于各模块对CPU的多核利用率，将能够充分利用CPU多核优势的模块确定为适于单独部署在一个服务器上，和将难以利用CPU多核优势的两个模块确定为适于部署在同一个服务器上。

2.如权利要求1所述的方法，所述方法还包括：

基于所确定的用于典型压力测试场景的记账节点模块数量与共识节点模块数量之间的比例以及各模块对服务器的占用关系在多个服务器上部署各个模块；

经由APIServer模块基于所述合约对部署在多个服务器上的区块链进行多轮并发测试，其中在每轮测试中并发地对多个记账节点模块进行测试并且并发地对同一记账节点模块进行测试，并且其中对于各轮并发测试的并发数不同；和

检测各轮并发测试下的每秒交易数TPS和/或各个服务器的***资源使用率。

3.如权利要求1或2所述的方法，其中

区块链的所述配置参数至少包括日志级别、块大小、安全传输层协议的开启状态、共识算法、P2P算法、记账算法以及加密算法中的一个或多个，和

区块链的初始配置参数是随机选择的或预先确定的。

4.如权利要求1或2所述的方法，其中

对于记账节点模块、共识节点模块以及APIServer模块的初始数量分别为2个、1个以及1个。

5.如权利要求1或2所述的方法，其中

所述方法还包括对部署在单个服务器上的区块链调整其配置参数；

检测与不同的配置参数相对应的各模块的***资源使用率和使记账节点模块、共识节点模块以及APIServer模块中的一个模块的***资源使用率基本饱和的并发数；以及

将与最佳并发数相对应的配置参数确定为用于典型压力测试场景的配置参数，并且将与最佳并发数相对应的配置参数下的记账节点模块、共识节点模块和APIServer模块中的一个模块的***资源使用率基本饱和时记账节点模块与共识节点模块之间的***资源使用率的比例确定为用于典型压力测试场景的记账节点模块数量与共识节点模块数量之间的比例。

6.如权利要求1或2所述的方法，其中

所述合约使得在区块链上写入键-值对，其中，在各轮测试中并发的多个测试之间采用不同的键。

7.一种存储有计算机可执行指令的计算机可读介质，当所述计算机可执行指令被处理器执行时，使得所述处理器执行如权利要求1-6中任一项所述的方法。

8.一种用于区块链***的压力测试的控制装置，所述控制装置包括存储有计算机可执行指令的存储器和处理器，当所述计算机可执行指令被所述处理器执行时，使得所述装置执行如权利要求1-6中任一项所述的方法。

Images