面向私募股权的区块链服务系统设计

赵晓峰 张绍华 卢 暾 戴炳荣 李 超

1(复旦大学协同信息与系统实验室 上海201210) 2(上海计算机软件技术开发中心 上海 201112)

0 引 言

区块链技术是一种近年来迅速发展起来的分布式数据库技术，其起源于数字加密货币领域。区块链技术的去中心化、数据加密和智能合约等核心技术使得其在积分交易、数字版权保护等领域有着广泛的应用[1]。区块链系统中没有中心化的控制机构，参与区块链网络中的节点的地位功能均相同。区块链应用通过客户端接入应用层，参与区块链网络中的活动，如挖矿、投票和发送交易等。当前，区块链应用往往通过单客户端参与区块链网络中的活动，因此导致区块链系统无法承受较大的并发且没有足够的冗余机制以保证安全性和稳定性。

现如今区块链技术在虚拟货币、版权交易等诸多领域有着充分的应用[2]。区块链技术在虚拟货币领域的影响非常大，如比特币、以太币等，是近年来增长最快的金融投资产品。区块链技术的去中心化特征使得在区块链网络中没有中心化的管理机构，这改变了传统的第三方信任的架构，将信任转移到网络中所有的节点共同承担[3]。区块链在版权保护等相关领域的落地，利用了其存证不可更改的特点。其数据分布式存储，没有中心化的架构对数据拥有唯一的所有权。同时利用区块链技术中核心的智能合约技术实现业务自动化结算的功能，智能合约是将业务场景中核心的业务逻辑封装成代码的形式运行在区块链网络中。区块链技术的蓬勃发展体现在区块链应用如雨后春笋般涌现出来。但是目前区块链技术本身还存在一些问题，导致没有一个杀手级的应用出现在市场。广大的高校科研人员和业内开发人员均在积极探索和改进区块链技术在应用中的不足。本文在实践中发现区块链技术通过客户端接入应用层的架构导致其无法面对高并发高可用的业务场景，因此在现在市场流量较大的情况下，区块链技术无法支持。

微服务(Micro-Service，MS)是近年来工业界提出的概念，其意义是参考服务化的理念，将后台系统按照功能拆分成多个子功能模块，并将单个服务使用容器封装操作管理的一栈式解决方案[4]。随着区块链面向的应用场景实用性增强，用户量也随之增大，单体应用架构在提供足够的并发处理方面能力不足。针对区块链应用场景，性能瓶颈仅是区块链应用模块及区块链客户端的服务能力，因此扩展整个单体应用会导致成本(CPU、内存等)的不必要增加。本文结合微服务思想，提出了一种单节点多客户端的应用架构。在系统的区块链交互模块和区块链客户端服务能力不足的情况下，可以针对能力不足的模块在最小资源消耗的情况下进行扩展，达到高并发的效果。对于模块有可能出现的故障，也有足够的备用节点保证任务正常执行。在扩展服务节点的同时，本文针对区块链应用业务场景设计了负载均衡模型以提高并发量和任务执行效率。

1 相关工作

1.1 私募股权平台

私募股权项目平台通过募集私募股权项目信息，提供私募股权相信信息的隐私保护及信息自动化交易等功能[5]。客户在平台发布项目信息招募合伙人，合伙人通过平台提供的信息筛选寻找合适的投资项目。基于区块链技术的私募股权平台构建在近年来受到了互联网金融领域的广泛关注，构建高性能高并发高可用的区块链服务平台是研究的重点[6]。区块链技术的去中心化、隐私保护、自动化结算[7]等特点刚好可以满足私募股权业务场景下的需求。

1.2 高并发架构

近年来行业内对高可用高并发架构的研究也如火如荼地进行，目前业内非常流行的高并发应用架构有微服务、SOA等[8]。微服务是将应用系统根据业务的分类拆分成独立的集成度够高的小系统，在生产环境下，根据业务的实际情况对微服务系统的小系统进行扩展迭代等操作[9]。微服务技术近年来在行业内取得了非常大的进展，在高并发场景中有非常重要的应用，阿里巴巴、京东等大型企业化应用均采用此架构。

1.3 负载均衡

仅使用微服务技术是远远不够的，因为现成的微服务解决方案并未考虑区块链相关业务的特殊性。微服务技术往往结合容器化技术进行相应的部署和构建。基于容器构建的区块链服务平台在HyperLedger的应用中非常广泛。Ethereum在市场上的占有的分额比较高，但是缺少高效的BaaS平台方案。实践中发现，Ethereum客户端在容器中运行会导致容器状态受到影响，而容器的状态又会影响到其提供服务的能力，因此需要一定的负载均衡与回收策略。

云计算领域有多种负载均衡策略如轮询、加权、最少连接等[10]。但此类方法并未考虑服务节点的状态。文献[11]将任务分组，且使用组内任务优先级相等，组内截至时间短的任务优先得到调度，实现了较高的任务调度效率。优秀的负载均衡策略应该有效地减少总任务完成的时间，同时保证较好的系统的负载均衡，提高服务资源的利用率[12]。文献[13]提出了相空分析方法，将集群中每个服务器的资源占用参数投影到以这些参数为坐标轴的相空间中，将服务器参数变化看作相空间中点的运动。文献[14]在计算空间分析方法的基础上，提出了负载均衡度概念，设计了最小负载均衡优先算法并对该算法的基本理论进行了研究和分析。

本文在文献[13]、文献[14]所提出的云计算空间分析方法基础上，经过分析论证，充分考虑区块链相关业务的特殊性和Ethereum客户端在容器中的运行情况，建立面向区块链应用场景下的负载均衡模型，提升区块链服务模块的并发能力。

2 架构设计

2.1 应用架构

区块链技术的应用架构种类庞多，大多数中小型企业往往采用单体应用的架构模式。单体应用架构有不便扩展、安全性低、并发低等特性。本文结合微服务思想设计了区块链的微服务应用框架，在单体应用的基础上首先对业务进行了横向的读写拆分，从安全限流的角度对业务进行了纵向拆分并加入了熔断和消息缓存等中间件机制。

从业务层面看，区块链应用的相关业务可大致分为读业务与写业务。读业务如获取账户信息、获取区块信息等操作耗费资源小、速度快，不存在并发瓶颈的问题；写业务如发布合约、调用合约交易等业务需要消耗占用客户端资源，存在性能瓶颈。同时，区块链写业务涉及的数据安全性要求较高，因此对写业务需要足够的安全保障。

从安全和系统响应速度角度出发，本文需要使用消息中间件对消息进行缓存并且需要一定的熔断机制保证分布式系统的容错机制。因此，本文在业务层面将系统纵向拆分成服务提供者和服务消费者，并且在消费者和服务者之间使用消息中间件和熔断机制保证响应速度和可靠性。

本文基于区块链的私募股权平台总架构如图1所示。

在本文架构中，由于网络故障等原因，服务可能出现故障，而调用出现故障的服务会导致线程阻塞和服务瘫痪。服务之间的依赖性会导致故障在整个系统中传播，使得整个微服务系统雪崩式崩溃。为防止上述服务雪崩，本文基于熔断器设计模式，当对特定服务的调用不可用达到一个阈值，熔断器将会被打开，故障服务断开，其注册在服务注册中心的API状态变为不可用。区块链后台服务模块架构如图2所示。

本文采用以太坊作为区块链底层服务平台，结合微服务思想，使用容器化技术部署以太坊客户端，并通过调用接口实时检测底层区块链环境，搭建了一个简化的BaaS(BlockChain As A Service)实验平台。本实验平台中，多个客户端共用一份数据，因此在参与区块链网路中时，即使拥有多个节点，但依然只有一个节点提供服务。区块链底层服务系统架构如图3所示，其中：Geth Client是以太坊提供的官方客户端，Status Monitor是区块链系统状态监控中心，它们均运行在容器内部。整个系统共享同一份数据，因此在区块链网络中仅看作一个节点。

2.2 问题分析

在2.1节所描述的架构中，底层的多个客户端向应用层提供区块链服务，客户端运行在容器中。通过实验监控发现，容器的状态受到执行业务影响较大，且容器的状态对容器的执行业务能力影响较大。因此，设计合理的调度机制，将应用层的任务分配给合适的区块链客户端进行处理。

在区块链服务节点提供服务的过程中，服务容器的状态变化较大的有内存和磁盘读取量两个参数，监控参数如图4所示。随着任务的执行，CPU使用率没有明显变化，内存变化率变化较大。对于磁盘读取量，分别求取最大值磁盘读取量的百分比的平均值，这个值并不能精确衡量容器磁盘读取量的大小，但能从一定程度上反映在执行过程中磁盘读取量的变化。根据节点提供的服务类型上的分析，节点进行挖矿等操作导致内存占用升高，节点进行HTTP通信以及区块数据打包导致磁盘IO数据量增大，因此本文考虑设计合理的调度模型来解决该问题，对服务能力较差、即将发生阻塞的节点进行资源回收和重新分配，使之恢复处理能力。

3 调度模型设计

3.1 负载均衡依据

对于区块链运行在容器中产生的资源消耗使得客户端无法正常运行的问题，本文将采用负载均衡调度算法来解决，将运行中的容器的工作状态表示为一个参数向量。通过实验发现，节点在处理写任务后，内存和磁盘读取的占用会急剧增加。因此选取容器的这两个参数建立容器状态空间，将节点容器的状态向量投影到该二维平面。对于本调度系统而言，在运行状态下，计算节点将大致分为两类，一类资源消耗度较小，其投影点聚集在原点附近，另一类处于资源占用状态，其投影点远离原点。

假设容器的个数为m，任务调度时根据容器状态将任务在m个容器上合理分配。将m个容器在空间的投影做两种极端化处理，假设其在空间投影的点集为U={(x1,x2)|0≤x1≤1,0≤x2≤1}，其中x1是容器内存占用率，x2是磁盘IO量与容器在阻塞时IO量的比值。

读取m个容器在不处理写任务时刻和均处理完写任务后的状态信息并求取到原点的距离：

U1={(x1,x2)|0≤x1≤1,0≤x2≤1}

(1)

U2={(x1,x2)|0≤x1≤1,0≤x2≤1}

(2)

在状态空间中的投影点分布如图5所示。

计算平均值并以之做状态分界圆：

(3)

为了评估本系统的健康状况，可以用一个健康参数进行衡量，定义其为负载均衡健康度。假设负载均衡系统中有m1个容器处于分界圆以内，m2个容器处于分界圆以外(m=m1+m2)。则定义健康参数：

(4)

由于m1+m2=m，式(4)可化简为：

(5)

由健康参数的定义可知，当LBH≥0时，此时系统有大多数的容器处于闲置状态，此时健康状态良好，且LBH越大健康状态越好；当LBH<0时，健康状态情况较差。

3.2 任务调度模型

本文将n个独立的任务分配到m台容器节点上，m

ti=tmemory+tio_memory

(6)

式中：tmemory是任务所需的内存大小；tio_memory是任务处理时需要的IO内存大小。

m个容器资源可以表示成CON(i)=(con1,con2,…,conm)，coni表示第i个容器，其属性为：

coni=(conmemory,conio_memory)

(7)

式中：conmemory是容器剩余可用内存；conio_memory是容器现有可用IO内存。

本调度模型的目标是让系统承受尽量大的并发，其目标函数与约束条件如下：

max n

s.t.ti_memory≤conj_memoryi=1,2,…,n

ti_iomemory≤conj_iomemoryj=1,2,…,m

(8)

即仅在约束条件满足的时候才能将任务分配给相应的节点。

3.3 构建优先级模型

在区块链环境下，任务可以分为读任务和写任务，读任务不消耗容器资源因此优先使用第二区域的容器，在第二区域容器均无空闲时选择第三区域的容器。对于写任务，可以分为发布合约任务、操作账户任务、调用合约任务，发布合约任务较少，操作账户任务次之，调用合约任务较多。本文根据任务出现的频率对其先后执行顺序，优先执行处理出现次数较少的任务。

任务优先级模型具体描述如下：读任务与写任务分开执行；读写任务可能在第二区域冲突，此时因为读任务耗时短且不消耗系统资源，优先执行；读任务按时间先后顺序执行；写任务分为发布合约任务、操作账户任务和调用合约任务，其在实际业务场景中出现频次依次增加，同时重要性会减小，因此优先级为降序排列。

具体任务优先级如图6所示。

图6 任务流优先级

3.4 任务分配模型

任务的优先级决定了任务的调度顺序，本文根据容器的健康参数将容器分为三个区域。将读任务交给第二区域的容器处理，写任务交给第一区域的容器处理。第三区域的容器进行定时回收重启处理。在各个区域内部，本文结合区块链场景下的任务的性质及资源的使用和分配情况，构建动态优先级。

因为容器的状态影响其执行写操作，因此本文将容器按状态分为两类，具体映射到状态平面空间为Ⅰ区、Ⅱ区，Ⅰ区代表安全区，Ⅱ区代表非安全读区。以式(3)得到的数值Disave为分界线。图7为容器状态平面分区示意图。

任务分配模型描述如下：对于写任务，优先分配到Ⅰ区，当Ⅰ区没有节点时分配到Ⅱ区；对于读任务，优先分配到Ⅱ区，当Ⅱ区没有节点时分配到Ⅰ区。

3.5 算法描述

本文设计的面向区块链微服务化场景下的任务调度算法描述如下：将任务根据其读写性质进行分类并按时间排序；将任务依次动态地分配到适合的区域中的容器；更新容器的状态信息，动态将任务分配到其中；将第三分区中的容器依次进行重启操作，回收资源；检查健康状态参数，若健康状态参数为负数，则暂停如任务分配，等待知道健康状态为正数则继续分配任务；返回流程开始下一个任务的调度。

4 实验测试

目前面向私募股权平台的版权交易平台运行良好，本部分测验分为功能测试与性能测试两个方面。功能测试即是否可以完成创建账户、转账、发布智能合约和挖矿等功能。性能测试通过与单客户端与单体区块链服务后台系统构成的区块链服务平台做并发性能对比。

本文测试环境为基于VMware station pro构建的虚拟机。VMware station pro搭建于单机电脑，其配置为：系统Windows 10专业版64位；处理器Intel(R) Core(TM) i7- 5600U @2.6 GHz；内存12 GB。VMware station pro相关配置为：版本12.5.7 build-5813279；系统Ubuntu 16.04；内存2 GB；CPU 2核；硬盘20 GB；容器Docker CE。

本文系统提供的区块链系统操作主要分为四类，分别是连接管理、账户管理、交易管理与合约发布，具体功能与测试情况如表1所示。

表1 本文系统的四类功能

以上功能均完成测试，可以成功运行。

因区块链底层服务平台是多客户端架构，为了测试多客户端在提供服务方面的能力，分别采用3客户端、5客户端和8客户端三种形式进行测试。对于并发性方面，本文分别在200、600、1 000和1 200并发量的情况下测试响应时间，测试结果如图8所示。

可以看出，在200并发量的时候，单客户端的完成速度高于多客户端，这是因为在多客户端之间的切换需要消耗时间。因此在低并发情况下，单客户端架构性能优于多客户端架构。在并发量到600及以上的时候，多客户端架构的优越性逐渐体现出来，多客户端的任务完成时间小于单客户端的任务完成时间，而且随着客户端的数量的增加，任务完成的时间变得更短。在并发量达到1 200的时候，单客户端因为阻塞问题导致无法正常完成功能，但是多客户端架构依然在没有影响的情况下完成任务。

从上述实验结果可见，本文针对区块链应用场景所设计的高并发架构可以实现相应的读写功能，并且在大并发量情况下的性能优于单客户端架构。

5 结 语

本文设计和实现的区块链服务平台有效地提高了区块链技术在应用中并发性能低和安全性低等问题。对区块链相关业务的拆分使得服务的扩展更加灵活，能够在消耗资源最小的情况下按需提升平台服务能力。基于容器化技术构建的底层区块链服务平台服务性能良好，克服了以太坊客户端提供服务能力不足的问题。基于此构建的简单BaaS实验平台，在其他区块链应用中同样适用。面向区块链业务场景设计的负载均衡模型，充分考虑了区块链业务的特性，能够在此业务场景下发挥最大的效果。