本文作者Ross Jimenez来自CenturyLink Labs，他受到了Iron.io一篇介绍容器微服务的相关文章的启发，于是介绍了自己团队在构建Panamax的时候所用到的微服务的理念，此外作者还大致介绍了微服务和容器技术相结合之后的优势，以及他们怎样通过微服务化的容器来构建工作流模型。

通过Docker容器可以构建具有特定功能的工作流，也可以让容器在后台执行一系列的异步任务，我们所开发的Panamax项目，其工作模式正是依据Docker容器的这一特性进行设计的。我偶然在Iron.io看到这篇有趣的文章，“Docker化的微服务的短暂生命周期”，尽管我已经对Iron.io所提供的服务很熟悉，但是通过这篇文章，我更深入地了解他们如何使用容器，特别是使用短生命周期的容器来完成他们的服务，这的确给了我很多启发，于是我写下了这篇博客。

我们在项目中也一直使用短生命周期的容器，并把它们作为工作流中的一系列的功能性的容器，但是具体的使用方式和Iron.io有所不同。在Iron.io中，这些具有特定功能的工作流可以被一个事件触发，或者可以被提前指定好，并且可以按照即时的需求在后台完成对应的工作。在我们的使用环境中，工作流中的最初的几步要求先被完成，整个工作流能否顺利执行要依赖与工作流开始几步所产生的输出结果。

Panamax中工作流的用例：

在Panamax项目中，我们希望其中的一个功能是帮助我们的用户在云服务平台上远程启动一个集群，这样用户就可以轻易地在上面部署Panamax模板。我们目前已经可以实现在远程基础设施上部署模板，但是这需要对基础设施进行相关的设置，并且安装远程代理/适配器，这些都是相互独立的过程。

让我们通过一个例子，来看如何进行端对端的自动化操作。这个例子可能是一个比较简化的例子，假设这里的功能需要三个基本的步骤来完成：

虚拟机创建—在提供集群服务的云服务平台上开启虚拟机对虚拟机进行管理/编排工作—（Kubernetes、 CoreOs 等等）Panamax远程客户端/适配器的安装以及代理注册服务

让我们来继续讨论，对于上面这几个步骤，由于每一步的相关执行逻辑都被封装在对应的Docker容器中，所以每一个容器仅仅负责执行一些指定的步骤。理论上我们可以通过并行的方式来同时启动这些容器，但是实际上我们会受到一定的限制，当前这一步如果想要正常运行，就必须要从前一步的运行结果中取得某些数据（举例来说，如果我们不知道在step1中所创建的服务器的地址，那么在step2中我们就无法安装对应的编排工具）

工作流的执行

在尝试处理不同例子的过程中，我们逐渐构建起了一个一般性的通用框架，我们可以用这个来进行基于容器的工作流的编排，就像我们在上面所描述的那样。此外，我们的框架还需要完成以下的工作：

接收将要被执行的工作流的描述信息（也就是一个容器的列表）按照正确的顺序启动容器并且对执行过程进行监控在工作流的不同执行阶段对数据进行打包和调度报告当前工作流的执行情况

还有一个需要解决的有趣问题是，如何在容器之间进行数据的迁移。我们通过使用Unix的管道模型（piping model），来解决这个问题。我们会attach到一个运行容器的标准输出，并将输出的内容捕获，之后再将数据写入工作流链中下一个容器的标准输入流中。随着工作流中的后续步骤被不断执行，前面几个步骤的输出结果就变成了接下来几个步骤的输入结果。

开始的时候，我们将这个框架集成到了Panamax项目中，但是我们很快就要将这个框架以单独的项目的形式发布出来，这样就可以帮助其他开发者轻松实现类似的工作模式。

用于提供微服务的短生命周期容器

下面让我们讨论一下在具有特定功能的工作流中使用容器的优点:

容器可以运行在任何支持容器工作方式的计算资源上，所以通过容器构建的整个工作流或者是工作流中的某些步骤也可以直接在这些计算资源上运行。使用容器可以很方便地对所执行的任务进行逻辑单元的划分，并且容器之间的隔离性可以使其在基于微服务的设计模式中很好地进行工作。只有在容器实际执行的时候，计算资源才会被消耗，也就是说，只有在具体执行任务的时候才需要计算资源。工作流的模块化性质可以使得工作流中的每个步骤或者每一个逻辑单元，都变得容易进行 修改/扩展/重组/架构解耦。

考虑到在采用上述策略后，我们整个过程中的每一步都是解耦的，这样的话，对某个逻辑单元进行重用，就会变得很容易。这就是微服务架构的一个令人兴奋的优点：即对于工作单元的可组合的能力。工作单元可以被重新排序，容易修改并且易于扩展。虽然，我们用于工作的容器都是用GoLang语言来构建的，但实际上，每一个容器都相当于是一个黑盒，因此，开发者可以用任何他们自己希望的方式来实现。这与Panamax的远程客户端/适配器的概念很相似，它们同样都是被封装在容器中。

特定功能的容器工作流

我希望通过上面的介绍，你已经对这个模式的具体工作方式有了一些了解。虽然我们这里讨论的是一个很具体的例子，对于这种工作模式来说，还存在着更多的可能性。这种模式里构建即时所需的传感器驱动（on-demand sensor driven）和基于事件的架构（event based architectures）的能力使我感到非常兴奋， 此外，对于如何计算资源被消耗的过程方面，也给了我很多启发。如果Docker允许你在亚秒级别启动一个容器，在许多情况下，解决方案可以被完全重新构建，目的是要使得解决方案更加能基于事件驱动（event driven）以及满足实时需求（on-demand）。这意味着资源密集型的解决方案将变得更少。因为计算资源只有在短生命周期容器存在的情况下才会被需要。

还存在一种可能的解决方案：构建基于容器的函数库，这个函数库可以帮助非技术型用户很容易地通过可视化的方式构建他们自己的工作流。比如传感器类型的容器可以查询API、 执行容器可以执行工作单元。最后再说一点，虽然我们目前只开发了最基本的顺序工作流，一旦你在实际工作中需要使用更复杂的工作流，只要遵照一些工作流模式的简单的逻辑规则， 你就完全有可能自己构建出一个独特的解决方案。将上面提到的所有的这些优势结合在一起，再加上容器的“到处运行”的特性，我想以后可能会产生出许多令人称赞产品。

原文链接：http://dockerone.com/article/195