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

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

到的脚本文件.表 8 展示了 5 名志愿者搭建网络及其用时的情况.由于 peer 节点的数量、组织的数量以及通信
效率的影响,同一规格的网络使用 Mictract 部署网络的时间可能会略有差别.在环境完备且中间不出现 Bug 的
前提下,采用脚本方式比 Mictract 方式平均多使用 225.6s.对于刚接触 Hyperledger Fabric 的工程师而言,理解修
改 HyperledgerFabric 网络配置文件启动网络往往需要一周左右的时间.从结果得知:与官方的部署方式相比,
Mictract 具有对于入门区块链的工程师而言具有极强的易用性,对于经验丰富的工程师而言部署效率也能得到
提升.
Table 8 Results of experiments
表 8 实验结果
志愿者 总 Peer 数量 Order 数量 组织数量 脚本方式 Mictract
A 2 2 2 5 分 42 秒 2 分 16 秒
B 4 3 2 7 分 20 秒 3 分 05 秒
C 2 3 2 5 分 58 秒 2 分 26 秒
D 3 4 3 8 分 03 秒 3 分 22 秒
E 1 2 1 5 分 06 秒 2 分 12 秒
4 局 限

本文在 3 台 centos7.x 组成的 Kubernetes 集群上搭建了 Mictract 平台,并对智能合约微服务化框架进行了
初步的验证.虽然 Mictract 可以在智能合约正确运行的前提下提升智能合约的部署效率,但是 Mictract 尚有诸多
的不足之处:(1) 缺乏系统化的研究方法支持智能合约微服务化框架的评估;(2) 受到 HyperledgerFabric 外部链
码安装部署所限,对部署相同链码的每个 peer 都要启动一个链码容器;(3) 共识算法支持有限;(4) 本文虽然搭
建了智能合约开发运维工具链,但集成工具有限;(5) 对于监控方面,未对容器性日志进行有效收集,且未深入挖
掘性能指标与交易日志的数据价值;(6) 本文选取官方示例链码进行案例研究,虽然该案例表示 Mictract 可以帮
助工程师快速理解落地智能合约原型应用,但是当前阶段的案例并非企业中完整实际案例.
5 总结与展望

针对智能合约在开发运维过程中遇到的部署效率差、监控工具不完善等问题,本文对比分析了微服务与智
能合约在设计原则上的相似性.由于微服务与智能合约在设计原则上有很大的相似性,这为本文智能合约微服
务化改造奠定了良好基础.随后,本文提出了一种智能合约微服务化框架.该框架将传统的智能合约运行方式在
保证运行无误的前提下将智能合约进行改造,改造后可以利用支持 DevOps 的自动化工具对智能合约进行进行
持续集成、持续部署与持续监控.具体来讲,通过将智能合约与共识节点进行解耦,解耦后的智能合约以容器化
的方式的插拔于下层网络节点.在此基础之上,利用 DevOps 支持微服务持续集成、持续监控的实践与工具,在
流水线中将智能合约进行容器化编排以“定制化”“插拔化”的方式进行智能合约的持续部署,利用 DevOps 监控
工具对运行中的智能合约进行持续监控.本文还介绍了原型平台 Mictract 的架构与实现原理.Mictract 的核心优
势是具备 BaaS 平台基本功能的前提下,屏蔽了底层方法原理与工具,形成了支撑智能合约开发运维的工具链.
为验证智能合约微服务化框架及其原型平台的可行性及部署效率,本文选取了 Hyperledger Fabric 官方链码
Marbles 进行案例研究.结果表明,Mictract 能够保证智能合约改造后功能运行无误,且在智能合约部署、升级效
率以及智能合约的操作监控方面取得了较为满意的效果.
此外,本文提倡在智能合约微服务化的基础上,以代码库或镜像库的形式发布分享有用且经过市场检验的
智能合约.开源共享 [40] 可以促进业界的交流合作,减少重复开发智能合约浪费的精力,为希望参与到开源智能合
约的编写工作的开发者提供良好的平台与交流机会;激励开发者用类似的方式解决相似的问题,扩宽开发者的
思维,为相同业务采用不同方法敞开了大门,同时可以减少因智能合约漏洞所产生的严重的经济财产损失.
未来,本文的后续工作将从以下几个方面展开深入研究.如图 4 所示.
(1) 在需求分析阶段,本文将基于 DDD 方法对区块链领域进行建模分析,构造针对区块链领域的 DDD 特