容器现状：Docker之外的选择、容器编排以及它们对微服务的影响

摘要： 容器编排是容器技术成败的关键，现今各种容器技术正激烈地争夺市场份额。本文探究了当前的各种容器工具，以及如何将它们用于微服务的部署。本文的主要观点是，开发人员在构建微服务时，应该考虑采用与产商和平台无关的解决方案。

作者：Kai Wähner

正文：

本文要点：

• 容器技术市场日益拥挤。各种技术正力图在该新兴市场中争夺一席之地。
• 容器编排是在生产环境中成功部署和操作容器的关键。
• 本文详述了多种当前可用的容器技术平台和工具。
• 一些云厂商的服务可以帮助快速部署容器，并提供灵活的伸缩性，这些服务在不同程度上存在“技术锁定”。
• 我们建议开发人员在创建微服务时，应考虑与厂商和平台的无关性，以便在未来的容器部署中具有灵活的弹性。

我参加了由柏林微服务讨论会组织的一个称为“微服务编排”的活动。活动组织者邀请了来自各大企业（Google、Microsoft、Amazon、Mesosphere、CoreOS和DigitalOcean等）的专家，分别报告了容器技术、云服务以及如何编排基于容器的微服务。本文扩充了这次活动的内容，为读者给出了多种不同容器技术的概览、差异以及未来的潜在发展。容器技术间的竞争已经开始！

定义：容器技术和编排引擎

只要你在这个星球上，就一定听说过Docker以及对它的大肆宣传。为了达成共识，我们首先对容器应用的两个关键概念做精简定义。

• 容器是一组运行在Linux操作系统上并使用命名空间进程进行分隔的进程，有了容器就无需再启动和维护虚拟机。与虚拟机技术相比，容器的最大不同之处在于打包格式和可移植性。构建容器的目的在于为现代基础设施降低占用空间和启动时间、提供重用性、更好地利用服务器资源，并更好地集成到整个开发生态系统中（例如持续集成和交付生命周期）。更多的细节可参见“微服务、容器及云原生架构”一文。

• 容器治理包含了如下一系列任务：调度（包括部署、复制、扩展、复活、重新调度、升级、降级等）、资源管理（内存、CPU、存储空间、端口、IP、镜像等）和服务管理（即使用标签、分组、命名空间、负载均衡和准备就绪检查将多个容器编排在一起）。该定义引用自Mesophere。

如果有人对容器编排依然不甚了解的话，可以观看一下这个非常好的视频：“Kubernetes启蒙指南”。该视频时长八分钟，是我见过的最好的技术视频之一，已经入门的人也值得一看。

可供选择的容器和用于编排的云服务

对于微服务的编排，在市场上存在着大量容器及相应的云服务可用。容器技术和编排引擎通常是结合在一起使用的，因而常被包含在同一工具中。云端提供的服务被称为CaaS (容器即服务)，其中“用户只为他们所使用的资源付费，例如计算实例、负载均衡和调度能力”。

在下面的列表中，我给出了多种不同容器平台的特性及各自的优缺点分析。应指出的是，该列表当然不是容器及编排产品的完全列表，但是我希望它能涵盖到它们中的大部分。

• Docker是最受大众关注的容器技术，并且现在“几乎”成为事实上的容器标准。虽然Docker公司是“官方的”Docker项目持有公司，但是Docker是开源的，并且得到很多厂商的支持。最近Docker公司在主要的容器项目中添加了编排引擎Docker Swarm。Red Hat和IBM等其它一些公司对开源代码也有贡献。多个厂商提供了针对Docker的支持、咨询和云服务（例如公开的或者私有的Docker Registry）。

• Core OS提供的rkt（发音为“rocket”）是另一种容器技术，它是随容器编排引擎Fleet一并提供的。rkt是一种底层架构，直接构建于systemd之上，常用作更高层解决方案的“基础层”。rkt侧重于安全性、可组合性（例如与原生Unix的集成）和标准化或兼容性。rkt通过使用“rktnetes”与Kubernetes集成，就可以和Docker一样原生地运行Docker镜像。由此CoreOS提供了称为Tectonic的“企业级Kubernetes解决方案”，这使得更多的项目将来可能会采用rkt解决方案。

• Cloud Foundry提供的Garden。Garden容器是开源PaaS CloudFoundry的基础。考虑到IBM、SAP和Pivotal等多个相关软件厂商的PaaS战略都是基于CloudFoundry构建的，因此可以说这些企业“在暗地里”使用。与Docker和rkt不同的是，如果离开了CoudFoundry的应用场景，Garden容器并不具有真正意义上的市场。

• Kubernetes是一款受到社区大力支持的容器编排引擎。该项目最早由Google在今年初开源发布，现在Kubernetes的贡献者还来自Red Hat、CoreOS、Mesosphere等软件厂商。这些贡献者实现了让Kubernetes运行多种不同的容器，其中包括了Docker（当前使用最为广泛的容器技术）或是CoreOS的rkt（发音为“rocket”）。Google Container Engine（公共Kubernetes服务）和Red Hat的开源PaaS产品OpenShift（基于Kubernetes，用于混合云部署）是最广为人知的两个Kubernetes产品。其中后者在Kubernetes上添加了一些有用的特性，包括改进的Web用户接口，以及“从源码到部署”自动化系统，无需要了解底层容器或Docker子系统的细节。

• Amazon AWS ECS是一个公共CaaS，用于管理Docker镜像（可存储于共生的ECS Registry中）、运行Docker容器（ECS Runtime服务），以及容器实例的调度、编排、监控（AWS CloudWatch服务）。这些服务还可以与其它的AWS服务整合，例如Elastic Load Balancer（AWS ELB）和Identity and Access Management (AWS IAM)。此外，为了实现在AWS Simplified Workflow服务中使用Docker CLI命令（例如push、pull、list、tag等），该服务也与AWS ECS紧密集成。

• 还有一些云服务提供商提供了基于Docker的CaaS云产品。Microsoft Azure容器服务（ACS）可与Docker Swarm或是基于Mesos的DC/OS一起工作，共同构成容器编排引擎。Rancher Labs提供的Rancher平台也支持Docker Swarm、Kubernetes和Apache Mesos。需要注意的是，用户仍必须首先创建服务实例（例如AWS EC2），这也是绝大多数CaaS的共同特点。用户并非为运行自己的CaaS容器实例本身付费，而是为运行容器的服务实例付费。如果想要采用以容器实例计费的方式，用户需要使用“无服务架构”（该内容稍后再做讨论）。Docker公司也提供了Docker云服务，其中包括了部署和管理Docker应用的Docker Cloud，以及在企业软件供应链中集成Docker的Docker Datacenter。

• 基于Apache Mesos的DC/OS是一种运行于私有和共有云架构上的“分布式操作系统”，它对机器集群的资源进行抽象，进而提供通用的服务，因此被用作集群资源的协调器。Mesos运行于编排层（Swarm、Kubernetes等）之下，是一种辅助性工具。Apache Mesos在设计上“仅需”实现Mesos架构的接口就可以运行多种大规模、多用途的集群。Mesos支持多种架构，例如通过Marathon支持Docker和rkt容器技术、通过Chronos支持批处理，以及Apache Hadoop、Apache Spark、Apache Kafka这类大数据解决方案。作为Apache Mesos的主要贡献者，Mesosphere公司还提供了一个称为DC/OS的开源软件产品。DC/OS基于Mesos构建，两者间的关系类似于Apache Hadoop与其发布版Cloudera或是Hortonworks间的关系。

• Flockport是一个初创企业，它的核心业务在于构建基于LXC容器的App商店，使用户可以在任何的服务器、云以及服务提供平台上以秒级速度部署容器。Flockport侧重于简单易用性，即如何使服务运行起来，目标在于为用户提供可移植的实例和工作负载，这些实例和负载将具有与云端一样的灵活性，易于在服务器间迁移。博客文章“LXC和Docker容器的主要差异”对此做出了很好的解释。

• DigitalOcean是一个云架构提供商，它让开发人员可以通过在全局云数据中心上创建所谓的Droplet（即工作单元），借助块存储和联网特性去构建并部署微服务。Droplet可以是一个操作系统镜像的实例，也可以是一个Docker容器应用。DigitalOcean还为Droplet解决资源分配、监控及其它跟平台相关的问题。Droplet可与多种编排工具集成，例如Docker Swarm、Kubernetes、Apache Mesos或Dokku（一种基于Docker的微型Heroku PaaS产品）等。因此相比于AWS EC2，DigitalOcean更像是一种IaaS，侧重于微服务集群部署和运行的易用性。

• Microsoft Azure Service Fabric是一个微服务框架和容器编排引擎。它并非完全依赖Microsoft Azure，也可以用于企业内部或云端（因此说名称中的“Azure”一词对产品有点误导）。Service Fabric借助Docker实现了Linux和Windows上的容器管理，其中可以使用多种编程语言（例如C#、Java、Powershell等）。未来该产品有望支持Docker之外的更多容器技术以及编程语言。

• 无服务器的容器架构：这是一个新近出现的概念，目的在于能够部署“真正的”函数式类型的云原生微服务。该架构的主要理念是实现对付费资源百分之百的利用率。在该架构中，用户只需为函数调用付费（可参见AWS Lambda、Google Cloud Functions、Microsoft Azure Functions等）。它与CaaS产品的不同之处在于无需用户亲自去管理底层操作系统实例（即运行、扩展、使用和付费等操作）。但是无服务器容器架构产品通常仅支持对有限的几种编程语言的函数调用，例如Java和Python。IBM OpenWhisk和funktion（分别由Red Hat和JBoss所支持）是两个无服务器架构的开源产品，它们与软件厂商无关，通过支持Dockers容器实现了无服务器的容器架构。OpenWhisk正在成为一个“真正的产品”，而funktion是一个小型框架，近期更新较少。在不久的将来，大型云服务提供商很有希望会提供Docker容器。

各种容器技术间的竞争

正如你所看到的，当前市场上已有多种容器打包与编排技术、框架及云服务可用，乃至上面的列表都未能涵盖全部。仍有新的事物在不断地涌现。

从开发人员的角度可以给出的一个重要结论是，不要聚焦于在后台为容器开发代码，而应该将注意力放到业务逻辑上，采用软件厂商无关的方式实现自己的微服务。

要避免重蹈我们曾在J2EE/Java EE上所犯的错误。彼时虽然所有的软件厂商都采用同一标准规范，但是他们仍然在所谓的“标准实现”中提供了与特定厂商相关的特性和“附加值”。这导致将应用迁移到另一个Java EE应用服务器上时，需要做大量的工作（重开发、测试，诸如此类）。很多情况下，重写代码反而比迁移更加容易和快速。

虽然当前Docker的发展势头很好，但依然存在对Docker未来发展的顾虑。一些使用了Docker的软件厂商并不乐意看到Docker公司一家独大。例如在Docker项目中集成Docker Swarm的模式会令Red Hat或Google等其它的编排服务提供商高兴不起来，因为这些厂商偏重于使用Kubernetes做容器编排工具。为了能够在不使用Docker的情况下在Kubernetes中运行容器，这些厂商又建立了一个新的开源项目，称为“CRI-O”。更多的相关信息可以参阅InfoWorld的这篇文章：“Red Hat的新项目看上去非常像是Docker的分支”，文章中给出了从Docker拉出一个分支作为一个独立开源项目的相关讨论。

整合各种容器技术及工具

应注意的是，上面所讨论的技术和工具可以被放在一起使用。各种技术和工具之间通常是互补的，并没有必要去一争高低。

例如在Kubernetes集群中，可以同时使用Docker或rkt等各种容器技术去管理pods。另一个例子，Apache Mesos可管理不同集群，其中包括基本的Docker Swarm集群、Kubernetes集群，以及使用了Apache Hadoop或Apache Spark的大数据集群。不要小觑这种特性！我举一个例子，Apache Hadoop 将提供对Docker的支持，用于实现在Hadoop容器中部署Apache Kafka或是Apache Spark等独立组件（Hortonwork在上周的路演大会上展示了它的Hadoop战略，我在其中看到了这个路线图）。

容器的未来：是否会走向标准化？

让我们来看看Docker的潜在分支及关于容器技术标准化的讨论将会为我们带来什么。明年将存在三种可能的发展：

1. Docker成为事实上的标准。
2. 不同的技术并驾齐驱，其中可能包括Docker的各个分支。
3. 容器技术标准化（至少部分标准化），各个技术厂商采用该标准。

我希望会是第三项可能性。倡议和讨论仍在继续，其中包括appc（App Container specification，App容器规范）、CNI （Container Network Interface，容器网络接口）、CNCF（Cloud Native Computing Foundation，云原生计算基础）和OCI （Open Container Initiative，开放容器倡议）等。举例来说，OCI的目的在于标准化容器镜像的定义，它得到了Docker、CoreOS、Google、Red Hat、Facebook、Amazon及其它一些企业的共同支持。

结论：开发容器无关的微服务

在本文中探讨了多种神奇的容器技术、编排平台和云服务，每种技术都有其优缺点。此外市场变化也很快。

在这里我们给出一个关键结论，就是以厂商无关的方式开发微服务，提升它们的未来适应性，并很好地利用微服务和容器的优点和特性，抛弃单体和笨重的虚拟机。在“我们能否避免被云供应商套牢?”一文中，详细论述了这个问题。

总而言之，无论你是否在具有源代码（使用Java、.Net或是Go等技术）或是可视编码（例如中间件技术）的微服务之中开发业务逻辑，你应该做到的是一次开发并可在各种容器、测试环境或者云服务提供商平台中部署，无需重新开发甚至是必须要去改变之前所选用的技术。

关于作者

Kai Wähners是TIBCO软件公司的技术布道师和社区主管。TIBCO软件公司是集成和分析中间件产品的领导提供商。Wähners主要擅长的领域是大数据、高级分析、机器学习、集成、SOA、微服务、业务流程管理（BPM）、云技术、物联网技术以及包括Java EE、Groovy和Golang在内的编程语言。他时常在个人博客上分享新技术、文章和大会报告内容。

查看英文原文：The Container Landscape: Docker Alternatives, Orchestration, and Implications for Microservices