基于 Fabric 的性能测试与调优实践

关注

发布于: 2020 年 11 月 12 日

摘要：本文聚焦 Fabric 核心业务，构建一个测试模型，对社区原生的 Fabric 和华为云区块链（基于 Fabric）进行实测，识别社区原生 Fabric 的性能瓶颈，并尝试通过华为区块链提供的动态伸缩、快速 PBFT 算法进行调优，提升几个关键的评测指标。

1、Fabric 性能测试现状

通俗的来讲，区块链是一种按照时间顺序将数据区块以顺序相连的方式组合成的一种链式数据结构，并以密码学方式保证的不可篡改和不可伪造的分布式账本。比特币（Bitcoin）、以太坊（Ethereum）、超级账本（Hyperledger）都是典型的区块链系统。其中 Hyperledger Fabric 是最受欢迎的企业级区块链框架，Fabric 采用了松耦合的设计，将共识机制、身份验证等组件模块化，使之在应用过程中可以方便地根据应用场景来选择相应的模块。

Fabric 的性能是用户最为关注的问题之一，然而，目前没有一个权威中立的机构，根据公认的规则，对 Fabric 进行性能测试并给出测试报告，大概有下面几个原因：

(1)Fabric 还处在快速发展中，尚未给出详细中立并且公认的测试规则；

(2)Fabric 网络结构(网络带宽、磁盘 IO、计算资源等)，配置参数(如区块大小、背书策略、通道数量、状态数据库等)，共识算法（solo,kafka,pbft 等）都会影响评测结果，很难构建反映 fabric 全貌的测试模型；

(3)Fabric 交易过程复杂，和传统的数据库有很多区别，也不适用于传统的测试方案和工具；

本文聚焦 Fabric 核心业务，构建一个测试模型，对社区原生的 Fabric 和华为云区块链（基于 Fabric）进行实测，识别社区原生 Fabric 的性能瓶颈，并尝试通过华为区块链提供的动态伸缩、快速 PBFT 算法进行调优，提升几个关键的评测指标。

2、Fabric 交易过程分析

在 Fabric 交易过程中，涉及不同的角色，每个角色承担不同的功能，节点（Peer）可细分为背书节点（Endorser peer）和提交节点（Committer peer），共识由排序（Orderer）角色完成。交易流程如下：

图1：fabric交易流程简图

(1)：应用程序客户端通过 SDK 向区块链网络发起一个交易提案（Proposal），交易提案把带有本次交易要调用的合约标识、合约方法和参数信息以及客户端签名等信息发送给背书节点（Endorser）。

(2)：背书节点（Endorser）收到交易提案（Proposal）后，验证签名并确定提交者是否有权执行操作，验证通过后执行智能合约，并将结果进行签名后发还给应用程序客户端。

(3)：应用程序客户端收到背书节点（Endorser）返回的信息后，判断提案结果是否一致，以及是否参照指定的背书策略执行，如果没有足够的背书，则中止处理；否则，应用程序客户端把数据打包到一起组成一个交易并签名，发送给 Orderers。

(4)：Orderers 对接收到的交易进行共识排序，然后按照区块生成策略，将一批交易打包到一起，生成新的区块，发送给提交节点（Committer）。

(5)：提交节点（Committer）收到区块后，会对区块中的每笔交易进行校验，检查交易依赖的输入输出是否符合当前区块链的状态，完成后将区块追加到本地的区块链，并修改世界状态。

客户端通过 Fabric 完成交易，要感知三个步骤（收集背书，提交排序和确认结果），而传统的数据库的读写，只要发起请求，等待确认即可。如果使用经典的测试工具如 JMeter,需要将 fabric sdk 进行包装 RESTFul 接口，增加了评测的复杂度。幸运的是，2017 年 5 月超级账本社区推出 Caliper，允许用户通过一系列预置的用例来测试特定的区块链技术实现。Caliper 生成的报告将会包含一系列区块链性能指标，如 TPS（平均每秒交易数），时延，系统资源占用等。本文的评测结果均为 Caliper 工具来测试生成。

3、Fabric 测试模型构建

建立性能测试模型，主要包含两部分工作：一是根据业务特点提取评测指标；二是确立稳定可测的业务模型。

3.1 评测指标

Fabric 是一个典型的分布式系统，Fabric 网络中各个 Peer 独立部署，分别维护自己的账本（支持背书查询），内部通过 Gossip 通信完成状态的同步。Fabric 符合分区容忍性，根据分布式系统的 CAP 定理，Fabric 在保证可用性的前提下，无法确保一致性。Fabric 是通过最终一致性（弱一致性的一种）来保证所有的节点最终就世界状态达成一致，这个过程就是 Orderer 共识和 Peer 验证确认的过程。因而在我们的测试模型中，主要考察以下指标：

查询吞吐量（Query Throughput）：每秒处理的查询请求量
共识吞吐量（Consensus Throughput）：每秒处理的共识请求量
一致性吞吐率（Consistency Throughput）：每秒完成的同步业务数
平均时延（Avg Latency）：完成一次事务的平均耗时
失败率（Fail Rate）：出现业务失败（含超时）的比例

3.2 业务模型

在业务场景的选择上，我们尽可能考虑主流场景，摈弃本身就是瓶颈的选项，聚焦区块链的核心业务。

基础设施方面，Orderer 和 Peer 节点我们选择主流的 8vCPU16G 规格的虚机，Client 选择一台 32vCPU64G 的虚机。整个测试在一个稳定的子网内完成。Orderer 节点我们配置 4 个，满足 3f+1 容错的最低要求。Peer 节点我们配置 1，根据需要最多扩容到 5 个。

配置参数方面，我们使用单通道，单组织背书，状态数据库选择 goleveldb。落块策略使用默认策略（2s/4M/500T）。

共识算法方面，可选择 solo、pbft、kafka。solo 模式为测试模式，无法用于生产环节。Kafka 模式一种支持 CFT 容错的共识算法，性能主要依赖外挂的 kafka 集群性能。而 pbft 能够防范拜占庭节点，应用场景更广泛，对性能的要求也更高。因而，本次测试选择 pbft 作为共识算法。

链代码方面，我们选择社区提供的 chaincode_example02 示例，业务数据占比很低，同时能够覆盖账本读写的基本用例。

4 、实测与调优

4.1 查询性能与动态伸缩

Fabric 查询性能其实就是就是一次背书请求。Peer 端主要包含 3 个过程。

校验 Proposal 签名；
检查是否满足 Channel ACL；
模拟执行交易并对结果签名；

代码可以参考社区 chaincode_example02。

图2：单组织单Peer的查询性能

可以看到，单节点（8vCPU,16G）的读性能在 2500tps 左右。观察监控指标发现，CPU 使用率在 70%左右，接近满载，而内存使用率只有 25%左右[z(3] 。这个不难理解，背书过程涉及大量的验证、签名工作，这些都是计算密集型操作。根据区块链符合 CAP 定理的分区容忍性，我们可以水平扩展组织内 Peer 来提升性能。华为区块链已经提供了这个伸缩特性，我们将 peer 的个数扩容为 5 个。

图3：华为BCS的动态伸缩特性

再次运行测试脚本，结果如下：

图4：华为BCS单组织5Peer的查询性能

可以看到，在不断服，不牺牲稳定性的前提下，通过将单 Peer 动态伸为 5Peer。性能可以提升 4 倍多，整体吞吐量超过 10000tps,平均延时只有 0.06s。

4.2 共识性能与共识算法

共识算法是提升共识性能的关键。社区 fabric v1.0.0-alpha2 版的提供了 PBFT 共识是一种实用拜占庭算法。实用拜占庭算法主要改进了拜占庭算法效率不高的问题，将算法复杂度由指数级降低到多项式级，使得拜占庭容错算法在实际系统应用中变得可行。

我们先用社区的 PBFT 共识测试下：

图5：社区原生PBFT的共识性能

可以看到，社区原生的 PBFT 共识，无论是吞吐量，还是平均延时，都比较差。华为 PBFT 算法具备 Early-Stopping 性质，即当不存在拜占庭节点时，整个网络将很快达成共识，因而速度应该很快。我们切换为华为快速 PBFT 共识算法，再实测一下:

图6：华为BCS 快速PBFT的共识性能

切换到华为 PBFT 算法后，共识吞吐率可以达到 10000tps，一致性吞吐量也接近 1800tps。同时，相对社区原生版本，平均时延也大幅缩短。这样的写性能和传统的单节点关系数据库相当，可以满足大部分商用场景。

4.3 关于最终一致性

在共识性能的测试过程中，我们发现当共识吞吐量超过 2000 时，Peer 在同步区块时会出现积压，导致平均时延增大。要详细了解原因，可以通过查阅 Fabric 的关键源代码 (gossip/state/state.go)来了解 Peer 落块的过程：

图7：gossip 同步区块流程图

在 fabric 中，账本数据主要由 GossipStateProvider 通过 Gossip 协议来同步，这里只能给出关键的流程。

(1)启动一个协程 deliverPayloads 从 orderer 或其它 Peer 获取 “毛坯块”，调用 LegerResources.StoreBlock；

(2) LegerResources 调用 Validator 校验交易是否符合背书策略,检查读集合中版本跟账本是否一致；

(3)LedgerCommittor 执行区块中的合法交易，更新账本状态；

(4)ServiceMediator 更新通道元数据；

笔者修改了一下源代码，增加了 4 个步骤的耗时统计，结果显示 40000 交易生成 200 块的情况下，步骤 2（校验）耗时 17s，和步骤 3（写块，更新索引）耗时 40s。二者占用 deliverPayloads 80%的耗时，猜测是一致性吞吐率的瓶颈。开启 Profile 模式后，监控堆栈调用情况，也进一步验证了这个猜想。[z4]

图8：gossip 同步区块Profile火焰图

笔者能想到的优化方案：

(1)使用高速读写盘（SSD），提高区块文件的读写效率；

(2)Validator 校验环节是计算密集型，是否可以借助软硬件结合的方法，大幅提升校验效能；

(3)目前 Gossip 拿到 Payload 数据后，只能串行逐一处理。是否可以根据区块的读写集进行分区，交给不同的线程处理，最后再归并落盘，来提升性能（参考多通道性能是单通道的倍级）；

笔者通过媒体了解到，华为区块链等产品团队，已经在这方面投人力进行预研，期待可商用的产品早日发布，回报社区。

5、总结

Fabric 作为最受欢迎的企业级区块链解决方案，已经在很多领域得到成功应用。在本次测试调优中，发现社区原生 Fabric 有很多局限，如不易扩展，性能较差，不建议直接用于生产环境。

华为区块链的伸缩特性和快速 PBFT 算法，能够快速提升 Fabric 交易性能。其中伸缩特性，可以在不断服的情况下，将查询性能提升到 10000tps 以上（单 peer 的 4 倍多）。而快速 PBFT 算法，可以将共识吞吐率可提高到 10000tps 以上（社区原生的 20 倍）,能够满足大部分商用场景。

同时发现，在高并发的情况下，最终一致性的平均时延会出现增长，主要原因为当前区块校验和落盘为顺序串行执行，无法充分利用多核资源。如果社区后继版本或商业公司，能通过软硬件结合，分区归并的思路，提升一致性吞吐率，降低时延，Fabric 将会在商用领域获得更大的成功。