云环境下支持弹性伸缩的容器化工作流框架

•云计算与大数据专题•

计算机工程

Computer Engineering

文章编号\"1000#428(2019)0$-0007-07

文献标志码：A

2019年3月

March 2019

中图分类号：TP391

云环境下支持弹性伸缩的容器化工作流框架

刘彪，王宝生，邓文平

(国防科技大学计算机学院，长沙410073)

摘要：云计算和容器技术为工作流的运行带来便利，但其存在管理困难、资源利用率不足以及智能和自动化程度

较低等问题。为此，提出一种支持弹性伸缩的容器化工作流框架，在此基础上给出基于CPU使用率的工作流自动

伸缩模型，在流程过载时自动扩充流程的容器数目，减少任务等待时间，当任务负载减小时，能够在确保任务不丢 失的情况下完成流程的缩容，以节约资源和成本。实验结果表明，流程的扩容数量与其处理时间成正相关，较好地 消除工作流中的瓶颈，在工作流过载时，能够以较短的时间完成相同的任务量。关键词：云计算；容器；工作流框架；弹性伸缩；调度策略；负载均衡

中文引用格式：刘彪，王宝生，邓文平.云环境下支持弹性伸缩的容器化工作流框架[;]

scaling in clouD environment* J]. Computer Engineering，2019，45 ( 3) ：7-13.

.计算机工程，2019，45 (3 )

:7-13 $

英文引用格式：LBJ Biao，VAN? Baosheng，DEN? Venping• ContainerizeD 界\"!*:#% frameFor:呂以卩卩。!**./ elasti。

Containerized Workflow Framework Supporting

Elastic Scaling in Cloud Environment

LIU Biao，VANG Baosheng，DENG Venping

(School of Computer，National Universit;^ of Defense Technology，Changsha 410073，China)

[Abstract] Cloud computing and container technology bring the convenience of the workGows operation，but there are

problems such as management Difficulties，insufficient resource utilization, and low intelligence and automation.Therefore,a containerized workflow framework supporting elastic scaling is proposed. On the basis of this, a workflowautomatic scaling model based on CPU usage is presented, which can automatically expand the number of containers when the workflow process is overloaded，and reduce the task waiting time. When the task load is reduced，the process can be reduced while ensuring that the task is not lost to save resources and costs. Experimental results show that the number of expansions of the process is positively related to the processing time，which can better eliminate thebottleneck of the workflow. When the workflow is overloaded，the same amount of taslcs can be completed in [Keywords] cloud computing; Docker container; workflow framework; elastic scaling; scheduling strategy; load

balancing

DOI:10. 19678/j. issn. 1000-3428.0049811

a s

0概述

了新的机遇，也带来新的挑战。云计算通过虚拟化 将计算、存储、应用和服务变成可动态配置的资源

池，其资源的规模性、可扩展性和灵活性为科学工作 流的执行提供了强有力的支持。容器作为一种虚拟 化技术，因其轻量级、易部署、启动快等优点正逐步 取代传统的虚拟机成为新一代云化信息基础设施的 宏重构的基础单元。使用容器充当工作流的运行载 体，能够提升工作流的隔离性、可移植性、可扩展性、 可靠性和灵活性等。

云计算和容器技术给工作流的运行带来很多好

随着信息时代和大数据时代的到来，数据呈爆 发式增长，灵活高效的数据处理方法变得越来越重 要。数据处理由多个步骤组成，如数据采集、重新格 式化数据、运行分析等，这些步骤形成一条工作流。 工作流通常需要对海量数据进行查找、移动、处理、 分析及可视化等操作，但其部署和执行对计算资源 和存储空间的要求较高[16]。

云计算和容器的出现为科学工作流的执行带来

基金项目：国家自然科学基金（61472438，61602503)。作者简介：刘彪（1993—），男，硕士研究生，主研方向为云计算、大数据、并行计算；王宝生，研究员、博士生导师；邓文平，助理研究员、博士。

收稿日期：20176262

修回日期：20186364

E-mail：liubiao6891@ 163. com

8计算机工程2019年3月15日

处，但也面临一些问题和挑战，主要体现在，云数据 中心一直存在管理困难、资源利用率不足、高能耗等 问题，加上容器本身管理的复杂性，使得在云平台中 基于容器执行工作流需要一种高效的工作流编排调 度系统来有效地协调和管理数据、任务及资源；工作 流在实际运行中往往会面临突发负载，需要动态调 整资源，云计算结合容器技术虽然让资源扩缩变得 更加方便，可以按需使用与扩缩，但依然需要人工手 动操作，智能和自动化程度较低。

针对上述问题，本文提出一个基于容器的支 持自动伸缩的工作流框架，并基于此框架构建数 据传输和基于文件共享传输的可弹性伸缩工作流 模型，根据用户指定的伸缩策略和伸缩条件动态 调整工作流中每个流程的实例数目，从而应对负 载变化。

1相关工作

目前，国外已有很多比较成熟的工作流管理系

统（Workflow Managem+*Systems，WfMS )，如文 献[3-5]介绍一种在云中执行科学工作流程的解决 方案Pegasus。Pegasus采用集中式调度架构，中央调 度器负责生成所有任务的调度计划，并为其分配资 源，可帮助工作流应用在不同的环境中执行。 Pegasus基于XML格式描述抽象工作流程，而不用 考虑底层执行环境或中间件所要求的低级规范细 节，通过自动将高级工作描述映射到分布式资源上， 从而桥接科学领域和执行环境，同时提供完善的错 误自动处理和恢复机制以提升系统的可靠性。类似 于Pegasus流程管理系统的还有Triana[)] (GridFlow [7]、 JavaCog Kit [8]等，然而，这些系统都是针对各自研 究领域而开发的流程管理系统，系统的实现技术、使 用场景各不相同，缺乏统一的标准和操作模式[1]，同 时，对于一些突发负载无法处理。文献[9]提出组件 并行耦合的方案，有效地整合了现有的编程和性能 工具，有利于并行应用的开发。文献[10]为减少工 作流流程间的数据交换时间，提出一个面向大数据 处理的通用I/O中间件，为工作流系统中组件间的 数据交换提供了 一个通用框架。文献[11]分析了 KVM、Xen和Docker 3种虚拟化技术的性能，指出

Docker的性能开销可以忽略不计，并且更易使用和

部署。文献[12]进一步表示Docker可以提供更低 的延迟，并可用于硬件虚拟化的高性能网络技术。

文献[13 ]为解决将工作流应用程序部署到云环境中 的问题，引人一种新的调度算法，该算法能够检测可 并发运行的任务集合并将其分配到不同的子工作流 程中，然后将每个子工作流程分配在资源集群中，以

此减少任务间通信成本。文献[14]基于Docker容 器构建一个高性能网络功能服务链平台

OpenNetVM，使用DPDK实现高性能I/O。上述研 究对任务调度和通信成本进行了优化，但没考虑负 载变化和工作流的弹性伸缩问题。

关于工作流负载的研究，文献[15]指出在电子 商务、在线视频、气象等应用中的突发负载是平均负 载的5倍~10倍，甚至更高。文献[16]研究分布式 系统中工作流的协作方式和负载平衡技术，提出负 载均衡调度方法，采用负载因子描述单个系统的工 作流负载，当负载超过安全负载时根据负载平衡策 略进行实例迁移，实现多个工作流引擎之间的负载 均衡，但该方案不能根据任务负载进行弹性伸缩。 文献[17 ]提出一个支持资源自适应的云工作流框架

CWFlow，通过监控服务性能来动态添加或减少虚拟

机节点的数目，从而达到节省资源使用费的目的。

但在CWFlow模型中，工作流被作为一个整体来进 行扩充或缩减，对于不同流程之间执行时间差异较 大的工作流并不能获得很好表现，而且以虚拟机为 资源调节单位，资源伸缩的响应时间很大，不适应负 载变化频繁的工作流。

基于已有研究，本文提出基于容器的可弹性伸 缩工作流框架，每个流程以微服务的形式运行于容 器中，在实现工作流便捷部署、运行隔离和集中管理 的基础上，可利用微服务的松耦合性自由编排组合 工作流，并基于C P U使用率进行工作流的快速自动 弹性伸缩。本文旨在为工作流的动态弹性伸缩提供 一个通用框架，流程间耦合与通信问题在文 献[9-10，13]中已有研究。

本文主要贡献如下：

1)

提出并实现一个基于容器的工作流系(Container-based Workflow System，CBWS)，该系统 与Docker Swarm相结合，并可通过Docker原生命令使用。

2)

针对直接数据传输和基于文件数据传输2工作流进行可伸缩改进，引人停止信号、发送确认和 重传机制，实现对有状态容器的扩容和缩容，且只需 对现有工作流程序的源代码进行微小修改。

3) 提出工作流的横向和纵向2种不同伸缩策 略，并基于CPU使用率实现工作流的横向和纵向 伸缩。

2容器化工作流系统总体架构

容器化工作流系统采用集中式控制，总体架构

如图1所示。

统 类

第45卷第3期

刘彪，王宝生，邓文平：云环境下支持弹性伸缩的容器化工作流框架

9

图1

容器化工作流系统总体架构

该框架分为客户端、服务端、工作节点和持久 存储层。客户端作为用户和系统的交互工具，提供 数据可视化、工作流建模和系统管理功能。用户可 以通过客户端的图形界面自由编排组合工作流，系 统将自动把用户输入转变为指定格式的工作流描 述文件，从而对用户隐藏工作流模板语法的复杂 性。服务端由监控器和集中式工作流引擎组成，监 控器收集并汇聚主机资源、容器资源和任务状态信 息，为工作流调度与伸缩提供依据。集中式工作流 引擎负责工作流解析、调度和弹性伸缩，并自动对 工作流进行动态调整。工作节点层是由多个主机 构成的集群，为进行集中式管控，在每个主机上部 署一个节点代理，用于执行任务和监控采集。持久

存储层提供镜像仓库和网络文件系统（Network

File Sy@em，NFS)服务，用于数据存储与共享。

容器化工作流系统的工作过程描述如下：1)用户通过图形界面定义工作流，系统根据用 户输入自动生成工作流描述文件并提交给流程解 析器。

%)流程解析器对工作流描述进行解析，生成相 应的容器启动命令交给容器调度器。

3) 容器调度器根据主机资源使用情况选取合适

的主机运行容器。

4) 弹性伸缩决策器定时计算每个服务的资源使

用率，并与规定的指标比较。

5)

如果符合伸缩条件，则弹性伸缩决策模块根 据服务的伸缩策略执行服务伸缩操作。

3可弹性伸缩工作流模型

3.1直接数据传输

直接进行数据传输的工作流模型如图％所示，

各流程间存在单向的数据依赖关系，没有反馈和迭

代处理，可用有向无环图（DAG)表示。每个流程以 容器服务的形式部署和运行，利用服务发现功能使 得流程间可直接通过服务名通信，而不用考虑容器

IP的变化。当一个流程有多个容器实例时，采用负

载均衡机制将请求均衡分配到每个容器。每个流程 通过TCP协议将处理结果直接发送到下一个流程， 图3为TCP套接室的I/O缓冲区示意图，每个

socket被创建后都会分配输入缓冲区和输出缓冲

区，TCP通信通过ACK信号可确保对方收到了数 据，但仅保证对方的输入缓冲区收到数据，不能保证 对方应用程序取到数据。在工作流运行过程中，如

果直接停止一个容器，则可能导致正在处理的、缓冲 区的和正在传输的数据丢失。

图2直接数据传输的工作流模型

图3 TCP套接字的I/O缓冲区示意图

本文通过引入停止信号、发送确认和重传机制

确保任务在工作流伸缩过程中不会丢失。直接传输

数据任务处理程序的工作流程如图4所示。任务处 理程序在接收数据前先判断是否需停止，这样可确 保程序通过停止信号退出时没有任务处于执行状

态。接收数据后发送确认信号使发送方确认数据被

10

计算机工程

2019年3月15日

接收，同样发送数据后等待确认的信号，确保数据已 发送给下一个流程。由于容器的停止可能导致数据 发送失败，因此需捕获发送异常，当捕获到异常时重 新发送数据。

图4

直接传输数据的任务处理流程

3.2基于文件的数据传输

基于文件的数据传输工作流模型如图5所示， 通过NFS实现跨主机容器之间的数据交互，基于

redis构建任务队列实现多容器并发执行。具体而

言，为每个流程创建一个任务队列，任务队列中存放 待处理数据的地址，每个处理程序从任务队列中取 出数据，然后判断是否为停止信号，若是则退出程 序，否则根据地址从NFS中读取并处理数据，处理结 果存入NFS，同时将处理结果的地址添加到下一个 流程的任务队列，使任务可以继续被下一个流程处 理。基于文件数据传输工作流的每个处理程序工作 流程如图）所示。

图5

基于文件的数据传输工作流模型

(开始)

监听任务队列

取出数据

处理数据

(结束)<■

图）基于文件传输数据的任务处理流程

4

工作流的动态伸缩

传统工作流无法根据任务量或任务到达速率进

行动态伸缩，导致请求量大时服务质量下降，请求量

小时空闲资源浪费严重。CBWS支持横向和纵向 2种伸缩策略来满足不同需求的工作流动态伸缩，并 实现基于CPU使用率对工作流进行横向与纵向 伸缩。

4.1横向伸缩

横向伸缩也叫水平扩展，即用更多的节点来支 撑更大量的请求。CBWS通过调整流程服务的容器 数目实现横向伸缩。在横向扩容过程中，弹性伸缩 决策器首先获取待扩容服务的资源配额，然后查找 是否存在空闲资源大于该配额的主机，若存在则通 过docker service scale将服务的实例数目增加1个。 在缩容过程中，需考虑容器内可能有未完成的任务， 不能采用无状态服务的缩容方式来直接停止容器， 而是由伸缩决策器向一个流程容器发送停止信号使 容器自行停止。

4.2纵向伸缩

纵向伸缩也叫垂直扩展，即扩展一个点的能力 来支撑更大量的请求。CBWS通过增加容器的资源 配额来实现流程的纵向扩容，通过减少资源配额实 现纵向缩容。纵向伸缩需更新容器的资源配额，直 接使用docker service update命令更新容器时会启动 一个新容器代替当前容器，存在任务丢失可能，为避 免这种情况，先通过发送停止信号停止待更新容器，

待容器自动停止后再更新容器的资源配额，每次更

第45卷第3期

刘彪，王宝生，邓文平：云环境下支持弹性伸缩的容器化工作流框架

11

新时增加或缩减的资源数目可由用户设定。和横向 扩容一样，纵向扩容前也需检查是否有足够空闲资

源的主机来运行扩容后的容器。

4.3基于CPU使用率的自动伸缩实现

定义1(流程过载）工作流中某个流程的数 据到达速度若高于其最大数据处理速度，则称此流 程过载。

在CPU密集型工作流的处理过程中，当流程过 载时，该流程会处于满负荷工作状态，出现CPU不 够用的情况。这时要提高流程的吞吐率，就需要对 流程进行扩容。流程扩容策略由用户创建工作流时 指定，分为横向扩容和纵向扩容。CBWS以流程一 段时间内CPU的平均使用率作为该流程扩缩依据。

CBWS使用Docker SDK来操作和管理容器，系

统在创建服务时将用户输人的伸缩策略和伸缩条件 等参数作为服务的标签，伸缩决策器通过服务的标 签获取服务的相关参数，并根据这些参数进行服务

的伸缩，这也使得用户可以直接使用Docker原生命 令为服务添加标签来实现服务的自动伸缩功能，增 强了系统的易用性。

基于CPU使用率进行自动伸缩的原理步骤 如下：

步骤1

监控器采集主机和容器的资源信息并

存人数据库，为缩短采集时间，采集时使用多线程， 每个线程向一个主机发起请求，节点代理收到请求 后，将本主机及本机上容器的资源使用状态返回给 监控器。

步骤2

伸缩决策器使用Docker SDK查找出

带伸缩标签的服务。

步骤3计算每个服务的CPU平均使用率，计 算方法是通过服务名从数据库中查出属于该服务的 所有活跃的容器，然后取这些容器CPU使用率的平 均值作为该服务的CPU平均使用率。

步骤4

对所有CPU平均使用率低于预设缩容

阈值的服务根据其伸缩策略进行缩容。

步骤5对CPU平均使用率最大的且超过预设 扩容阈值的服务根据其伸缩策略进行扩容，即每轮 检测最多扩容一个服务，这样可以把资源分配给最 需要扩充的服务，这个服务往往是工作流中的瓶颈 流程。

步骤）上述步骤完成后转步骤1。

5实验结果与分析

5.1 实验环境

为验证本文提出的可弹性伸缩工作流框架的有

效性，使用python语言开发出原型系统CBWS，同时 设计一套图片处理工作流，该工作流包含3个流程， 分别为图片格式转换、轮廓滤波处理和添加水印，用

p y*o n实现了该工作流直接数据传输和基于文件传 输的2个版本。实验使用在1台笔记本电脑上用

VMware启动3台虚拟机，3台虚拟机使用主机模式

连接到一个虚拟网桥上，并组建成Swarm容器集群， 其中，1台作为管理节点，另外2台作为工作节点。 管理节点安装NFS服务端及数据库服务，并运行

CBWS服务端和客户端，工作节点运行CBWS代

理，容器都运行在工作节点。主机及虚拟机的主要 参数如表1所示。

表1

主机及虚拟机的主要参数

配置项

笔记本主机虚拟机管理节点虚

拟机工作节点CPU

!核4线程酷睿i7- 1处理器 1 处理器 ‘

7500U处理器 2核心1 核心

内存/GB

16

21操作系统

Windows 10Ubuntu16. 04Ubuntu16. 04Docker版本家庭中文版无

17. 12.0-ce

17. 12. 0-ce

5.2自动伸缩验证

本文实验以图片处理工作流为例，验证工作流 在不同负载下的自动伸缩效果。工作流流程之间 通过NFS进行数据交互，分别测试采用横向伸缩 和采用纵向伸缩时容器数目或容器资源的变化情 况。在测试时，初始化每个流程的容器数目为1， 容器CPU限制为0. 1(即限制该容器最多可使用 10%的CPU资源），每个容器分配64 MB内存，基 于CPU的扩容阈值设为90%，缩容阈值设为 40%。横向伸缩每次调整的容器数目为1，纵向伸 缩每次调整的CPU数为0. 1。测试图片为一张 624 KB的png格式图像，当无扩容时，每个流程单 容器处理一张图片所需的时间如表2所示。通过 控制图片发送速度对工作流进行压力测试，对于采 用横向伸缩策略的工作流记录不同负载下每个流 程的容器数量的变化情况，以及采用纵向伸缩策略 的工作流记录不同负载下容器CPU资源的变化情 况，实验结果如图*、图8所示。

表2

处理一张图片的平均时间

s

流程

时间

10. 557 420. 510 53

2. 452 6

12

计算机工程

2019年3月15日

蠢坳

图7

横向伸缩时不同负载下每个流程的容器数

0.8

0.7

□流程1

□流程2 0.6

■流程3

m0-5

u£ 0.30.4

0.20.1

0.0

ml ml J J J 01

0.5

1.0

1.5 2.0

2.5

3.0

请求速率/(个彳1)

图'纵向伸缩时不同负载下每个流程的容器CPU数

从图7、图+可以看出，流程容器的扩容数目或 资源的扩充数目与每个流程的处理时间成正相关，

在本次测试中，流程3最为耗时，扩容数目最多，流 程1和流程2耗时相差不多，因此，扩展数目也基本 一致。实验结果证明，CBWS可实现差异性扩容，将 更多资源用于瓶颈流程以提升其处理能力，从而能 够在提升工作流整体吞吐率的情况下降低流程间吞 吐率的差异性，有利于用更少的资源满足用户的服 务需求。

5.3处理性能

本文实验首先固定流程的最大扩容数量，横向 扩容时最大的流程容器扩充个数为5，纵向扩容时容 器CPU最大扩充数为0. 5，然后测试2种工作流模 型在使用横向和纵向伸缩策略时以最快速度处理不 同数量图片的时间。初始化的容器设置和5. 2节的 实验相同，在测试时，客户端以远大于工作流吞吐率 的速度发送图片，记录无扩容、横向扩容和纵向扩容 工作流处理不同数目图片的时间，实验结果如图9、 图10所示。

50 100

150 200

图片数

图（直接传输数据的工作流处理效率

f无扩容 i横向扩容 540I

纵向扩容

0(1

00〇T-----------------X-----------------1------------------1

50

100

150

200

图片数

图10基于NFS数据传输的工作流处理效率

图9、图10显示了基于CPU使用率的伸缩策略 对于CPU密集型工作流的有效性，相对于无扩容工 作流，无论是横向还是纵向扩容都能很大程度上提 升数据处理速度。横向扩容通过扩充容器数目分担 负载，实现并行处理，提高了工作流吞吐率，纵向扩 容通过增加容器的CPU使用时间，加快了处理速 度，从而提高吞吐率。值得注意的是，横向扩容不能 缩短单个任务的完成时间，因为每个容器的CPU数 目并没有扩充。纵向扩容增加了容器的CPU配额， 提升了处理能力，因而可以缩短单个任务的完成时 间。当纵向扩容时，一个流程只有一个容器，因此最 多只能占用一个主机的所有资源，而无法使用多个 主机资源，而横向扩容每个流程可有多个容器，容器 可被调度到不同主机，从而可以使用多个主机的资 源。另外，横向与纵向策略可以进行结合，当纵向扩 容遇到主机资源不足时转而进行横向扩容。

通过固定图片数为100张，用客户端以不同的 速度将图片传给工作流进行处理，模拟不同的任务 产生速度来测试工作流在不同负载下的处理能力。 本文以基于NFS进行数据传输的工作流为例，采用 横向伸缩策略，记录工作流在无扩容和流程容器最 大扩容数为分别为2、4、6时处理完客户端上传图片 的时间，以此测试可弹性工作流处理能力随负载的 变化情况，实验结果如图11所示。

400 r

30 o +发送时间

2 5o 20 +

无扩容

I

最大扩容数=2 1 5o 10

+最大扩容数=4 o

-0-最大扩容数=6

o

50 - ----------f Y

;00.5

-------1.0

1-------1.5

1-------2.0

1-------2.5

1-------3.0

1

发送速度/(个f1)

图11工作流处理速度随负载的变化情况

从图11可以看出，无弹性伸缩的工作流处理 100张图片的时间趋于稳定状态，原因在于其处理能 力不能随负载变化，由于其吞吐率小于任务到达速 度，上传的图片会在任务队列中排队，产生了较长的

第45卷第3期

刘彪，王宝生，邓文平：云环境下支持弹性伸缩的容器化工作流框架

13

任务等待时间。相反，可弹性伸缩工作流的吞吐率可

随任务负载发送变化，变化的范围与设置的最大流程 容器扩容数目有关。对于最大扩容数为％的工作流， 由于扩容数较少，在任务产生较慢时能及时处理完任 务，在负载大于1时，处理能力扩到最大，发生任务等 待。最大扩容数为4的工作流在负载大于2时，发生 任务等待。最大扩容数为6的工作流，在本次负载压 力测试下其吞吐率基本能与任务产生速度一致，没有 产生过多的任务等待时间，只有在负载为3时其完成 时间略高于客户端发送完成的时间，而且还大于负载 为2. 5时的完成时间。其原因在于基于容器的流程扩 容虽然很快，但仍需要一定的反应时间，在任务产生 速度太快而任务量又较小的情况下，会出现工作流尚 未扩充完成客户端即发送结束，导致新扩充的容器分 担不到足够负载，影响了完成时间，这种情况在使用 纵向伸缩策略的工作流中则不会发生。

本文对多个实验处理结果进行了检查，通过对 比最终处理完成的图片和发送的图片，确认任务没 有在工作流伸缩过程中丢失，证明了 CBWS的可靠 性和正确性。

)结束语

本文讨论了云环境下容器和工作流的结合问 题，提出一个支持自动弹性伸缩的容器化工作流框 架。该框架采用集中式控制原则，以容器微服务形 式部署和运行工作流，可对工作流进行自由编排和 组合，提高工作流的可扩展性和流程的复用性。在 该工作流框架的基础上，给出可弹性伸缩工作流模 型，实现基于CPU使用率的横向和纵向伸缩策略， 能够在确保任务不丢失的情况下，根据CPU使用率 自动伸缩服务。扩容过程基于贪心策略每次只扩充 CPU使用率最高的服务，有利于资源的合理分配。 利用此工作流框架，用户可以指定工作流的某些流 程或所有流程自动根据任务负载进行容器资源的动 态调整，从而在确保性能的前提下，以更少的资源运 行任务节省系统资源和使用费用。在目前的工作流 框架中，每条工作流中的流程平均分布到各个工作 主机中，因此流程之间存在跨主机通信，而跨主机通 信会带来额外的数据传输延迟，对于单个任务的完 成时间产生一定影响，下一步将对此进行改进。

参考文献

[1 ]张卫民，刘灿灿，骆志刚.科学工作流技术研究综

述[J].国防科技大学学报，2011，33(3):56-65.[2]

班爱琴，于炯，鲁亮，等.云环境基于多工作流的任务 调度节能算法的研究[J].电子技术与软件工程， 2015，14 (1) ：178-182.[3 ]

DEELMAN E，VAHI K，RYNGE M，et al. Pegasus in the cloud： science automation through workflow technologies [J]. IEEE Internet Computing， 2016, 20(1) ：70-76.[4]

DEELMAN E，VAHI K，JUVE G，et al. Pegasus： a

workflow management system for science automation[ J].

Future Generation Computer Systems，2015，46 ( 1 )： 17-35.

[5 ] DEELMAN E，SINGH G，SU M H，et al. Pegasus： a

framework for mapping complex scientific workflows onto distributed systems [ J ]. Scientific Programming， 2005，13 (3) ：219-237.

[6 ] MAJIT'HIA S，SHIELDS M，TAYLOR I，et al. Triana ： a

graphical Web service composition and execution toolkit[ C] //Proceedings of IEEE InternationalConference on Web Services. Washington D. C.，USA： IEEE Press，2004 ：514-521.

[7 ] GUAN Z J，HERNANDEZ F，BANGALORE P，et al.

Grid 2 flow ： a grid 2 enabled scientific workflow system with a Petri net 2 based interface [ J ]. Concurrency and Computation： Practice and Experience，2005，18 ( 10 )： 1115-1140.

[8 ] LASZEWSKI G V，GAWOR J，LANE P，et al. Features

of the Java commodity grid kit [ J ]. Concurrency and Computation Practice and Experience，2010，14(13/14/15)： 1045-1055.

[ 9 ] WATSON G， FRINGS W， KNOBLOCH C， +t al.

Scalabl+ control and monitoring of sup+rcomput+r applications using an integrated tool framework [ C] // Proceedings of IEEE ICPPW 2 11. Washington D. C.， USA：IEEE Press，2011 ：457-466.

[10] LIAO J，GEROFI B，LIEN G，et al. A flexible I/O

arbitration framework for net CDF-based big data processing workflows on high-end supercomputers [J]. Concurrency and Computation Practice and Experience， 2017，29 (15).

[11] RAHO M，SPYRIDAKIS A，PAOLINO M，et al. KVM，

Xen and Docker： a performance analysis for ARM based NFV and cloud computing [ C ] //Proceedings of IEEE International Conference on Information，Electronic and Electrical Engineering. Washington D. C.，USA ： IEEE Press，2016 ： 1-8.

[12] ANDERSON J， HU H，AGARWAL U，et al.

Performance considerations of network functions virtualization using containers [ C ] //Proceedings of

IEEE International Conference on Computing，

networking and Communications$Washington D$C$， USA：IEEEPress，2016：1-7.

[13] BAGHERI R，JAHANSHAHI M. Scheduling workflow

applications on the heterogeneous cloud resources [ J ]. Indian Journal of Science and Technology，2015,8( 12).

[14 ] ZHANG W，LIU G，ZHANG W，et al. OpenNetVM ： a

platform for high performance network service chains [ C] //Proceedings of Workshop on Hot Topics in Middle Boxes and Network Function Virtualization. New York，USA：ACM Press，2016 ：26 -31.

[15] YUCEMR，KEONG H C，CHAE M S. Wideband

communication for implantable and wearable systems[ J]. IEEE Transactions on Microwave Theory and Techniques，2009，57(10) ：2597-2604.

[16] 黄秀国，王戟.分布式协作工作流负载平衡调度[C]//

2005年全国软件与应用学术会议论文集.南京： [出版者不详]，2005：516-519.

[17] 尚世锋，姜进磊，郑纬民.CWFlow：支持资源自适应使用的云工作流框架[J].清华大学学报（自然科学版）， 2013，53 (1) ：415-420.

编辑索书志