Page 104 - 《软件学报》2021年第11期

3430 Journal of Software 软件学报 Vol.32, No.11, November 2021

助工程师更快了解智能合约内部的工作原理.开发的代码仓库可以对接持续集成(continuous integration,简称
CI)工具(例如 Jenkins、TravisCI 等),做到合并代码后自动提交部署.
(3) 构建
智能合约的开发和升级过程都比较繁琐,所以智能合约的手动部署、版本更迭以及升级过程都容易出错,
这有可能会导致系统漏洞,甚至升级失败,造成数据和经济损失.利用已有 CI 工具实现基础设施自动化,利用容
器化工具(如 Docker)打包编写完成的智能合约,衔接测试和部署.同样,将合格的智能合约镜像开源,可以方便其
他开发者直接部署于自己的区块链网络.
(4) 测试
常见的智能合约漏洞包括重入攻击 [34] 、事务顺序依赖、时间戳依赖、处理异常、整型溢出等.尽管业界已
有各种理论与工具 [35,36] ,但自动化程度较低.本文利用持续集成工具提升智能合约测试的自动化水平,将“可插
拔”、“开箱即用”的测试策略配置进入持续交付流水线,以便在智能合约上链前对其进行全方位测试.
(5) 部署
本文提倡从一开始不断地集成,将拆分后的智能合约以及区块链共识节点组合起来.每个过程都由自动化
的构建(包括测试)进行验证,以尽可能快地检测集成的错误.智能合约可交付镜像可以在开发、测试、生产环境
之间无障碍流通,打破三者之间的隔阂.开发完成的镜像可以直接交给测试网络测试,测试完成的镜像可以直接
在生产环境中部署.
(6) 监控
合约指标:在智能合约微服务运行时,采用微服务监控领域相结合的手段与工具(例如 Hyperledger Caliper、
Promethus 等),全面采集智能合约容器以及下层网络节点的性能指标数据,提供一个标准和定制的性能框架.该
框架可以集成数据异常检测 [37] 、报警及时反馈和智能决策分析,提供有效的可视化.可以监控的指标有:
• 响应时间:每个事务的响应时间,包括平均响应时间、最大响应时间和最小响应时间.
• 吞吐量:每秒成功事务的数量.
• 成功率:成功交易的数量与全部交易数量的比值.
• 资源消耗:CPU、内存、磁盘和网络 I/O 等.
容器运行日志:目前,智能合约开发领域对日志采集分析几乎没有涉及,但微服务架构在大规模分布式系统
中的日志采集、收集、分析方面已经做得十分成熟,可以借鉴微服务架构中的工具(例如 EFK、ELK)进行简单
的配置,全面采集智能合约容器运行产生的日志,提高智能合约运行过程中对于日志的实时采集、分析、展示、
以及故障定位的能力.
交易日志:智能合约的运行日志外,用户的交易行为、资金和资产的流向以及流通过程,蕴藏大量有价值的
信息.可以进行交易性日志的记录与追踪.
API 管理:结合集群网关管理工具不用考虑安全控制、流量控制、审计日志等问题,网关层还可以提供 API
发布、管理、维护等主要功能,开发者只需要简单的配置操作即可把自己开发的合约发布出去,同时置于网关
的保护之下.
链路分析:智能合约微服务的全链路调用分析,借鉴 Google 的 Dapper [38] ,在软件和通信协议中注入探针,跟
踪运行时智能合约微服务的有效调用路径及响应时间.帮助理解系统行为、用于分析性能问题的工具,以便发
生故障的时候,能够快速定位和解决问题,在出现性能瓶颈的时候,精准合理地扩容.

3 智能合约微服务化开发运维原型平台的设计与实现

本节为第 2 节提出的智能合约微服务化框架与流程提供一种可行的支撑平台,使用 3 台 Centos7.x 组成的
Kubernetes 集群,1 台 Mater 节点(dop-node1),2 台 Node 节点(dop-node2、dop-node3).Master 节点作为 NFS 服务
端.公有链允许任何节点随意进出的特性无法适用于企业级区块链应用 [39] ,本文将使用 HyperledgerFabric 进行
智能合约微服务改造,这可以避免公共区块链的运营成本,并确保更好地控制隐私 [13] .