[关闭]
@Rays 2016-12-09T09:19:39.000000Z 字数 6341 阅读 1855

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


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

作者:Kai Wähner

正文:

本文要点:

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

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

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

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

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

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

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

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

各种容器技术间的竞争

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

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

要避免重蹈我们曾在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

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注