共计 4693 个字符，预计需要花费 12 分钟才能阅读完成。
【摘要】Fabric 作为最受欢迎的企业级区块链解决方案，曾经在很多畛域失去胜利利用。作者发现社区原生 Fabric 有很多局限，如不易扩大，性能较差，不倡议间接用于生产环境。华为区块链的伸缩个性和疾速 PBFT 算法，可能疾速晋升 Fabric 交易性能。其中伸缩个性，能够在一直服的状况下，将查问和共识吞吐率可进步到 10000tps 以上，能够满足大部分商用场景。
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) 应用程序客户端通过 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 个过程。
(1) 校验 Proposal 签名；
(2) 查看是否满足 Channel ACL；
(3) 模仿执行交易并对后果签名；
代码能够参考社区 chaincode_example02。
能够看到，单节点（8vCPU,16G）的读性能在 2500tps 左右。察看监控指标发现，CPU 使用率在 70% 左右，靠近满载，而内存使用率只有 25% 左右 [z(3]。这个不难理解，背书过程波及大量的验证、签名工作，这些都是计算密集型操作。依据区块链合乎 CAP 定理的分区容忍性，咱们能够程度扩大组织内 Peer 来晋升性能。华为区块链曾经提供了这个伸缩个性，咱们将 peer 的个数扩容为 5 个。
再次运行测试脚本，后果如下：
能够看到，在一直服，不就义稳定性的前提下，通过将单 Peer 动静伸为 5Peer。性能能够晋升 4 倍多，整体吞吐量超过 10000tps, 均匀延时只有 0.06s。
4.2 共识性能与共识算法
共识算法是晋升共识性能的要害。社区 fabric v1.0.0-alpha2 版的提供了 PBFT 共识是一种实用拜占庭算法。实用拜占庭算法次要改良了拜占庭算法效率不高的问题，将算法复杂度由指数级升高到多项式级，使得拜占庭容错算法在理论零碎利用中变得可行。
咱们先用社区的 PBFT 共识测试下：
能够看到，社区原生的 PBFT 共识，无论是吞吐量，还是均匀延时，都比拟差。华为 PBFT 算法具备 Early-Stopping 性质，即当不存在拜占庭节点时，整个网络将很快达成共识，因此速度应该很快。咱们切换为华为疾速 PBFT 共识算法，再实测一下:
切换到华为 PBFT 算法后，共识吞吐率能够达到 10000tps，一致性吞吐量也靠近 1800tps。同时，绝对社区原生版本，均匀时延也大幅缩短。这样的写性能和传统的单节点关系数据库相当，能够满足大部分商用场景。
4.3 对于最终一致性
在共识性能的测试过程中，咱们发现当共识吞吐量超过 2000 时，Peer 在同步区块时会呈现积压，导致均匀时延增大。要具体理解起因，能够通过查阅 Fabric 的要害源代码 (gossip/state/state.go) 来理解 Peer 落块的过程：
在 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]
笔者能想到的优化计划：
(1) 应用高速读写盘（SSD），进步区块文件的读写效率；
(2)Validator 校验环节是计算密集型，是否能够借助软硬件联合的办法，大幅晋升校验效力；
(3) 目前 Gossip 拿到 Payload 数据后，只能串行逐个解决。是否能够依据区块的读写集进行分区，交给不同的线程解决，最初再归并落盘，来晋升性能（参考多通道性能是单通道的倍级）；
笔者通过媒体理解到，华为区块链等产品团队，曾经在这方面投人力进行预研，期待可商用的产品早日公布，回报社区。
5 总结
Fabric 作为最受欢迎的企业级区块链解决方案，曾经在很多畛域失去胜利利用。在本次测试调优中，发现社区原生 Fabric 有很多局限，如不易扩大，性能较差，不倡议间接用于生产环境。
华为区块链的伸缩个性和疾速 PBFT 算法，可能疾速晋升 Fabric 交易性能。其中伸缩个性，能够在一直服的状况下，将查问性能晋升到 10000tps 以上（单 peer 的 4 倍多）。而疾速 PBFT 算法，能够将共识吞吐率可进步到 10000tps 以上（社区原生的 20 倍）, 可能满足大部分商用场景。
同时发现，在高并发的状况下，最终一致性的均匀时延会呈现增长，次要起因为以后区块校验和落盘为程序串行执行，无奈充分利用多核资源。如果社区后继版本或商业公司，能通过软硬件联合，分区归并的思路，晋升一致性吞吐率，升高时延，Fabric 将会在商用畛域取得更大的胜利。
6 参考资料
https://hyperledger-fabric.re…
https://github.com/hyperledger/caliper
https://github.com/hyperledger/fabric
https://github.com/yeasy/hyperledger_code_fabric
Performance Benchmarking and Optimizing Hyperledger Fabric.pdf
点击关注，第一工夫理解华为云陈腐技术~
