通过 Cisco 发布的 Mantl 1.0 创建微服务基础设施

在近期于德国柏林举办的 Cisco Live 2016 大会上，Cisco 发布了其开源微服务平台 Mantl 的最新版本 1.0，该版本中的新特性包括：通过类似于 Project Calico 的工具进行多数据中心的配置、开发者对于整个基础设施配置的版本控制得以简化、以及在服务升级流程中引入蓝绿测试。

InfoQ 与 Cisco Intercloud Services 的 CTO Ken Owens 进行了一次访谈，内容涉及了 Mantl 最新版本的使用场景、设计决策以及未来的发展计划。

InfoQ：你好 Ken，感谢你今天能够抽出时间与 InfoQ 进行这次访谈。你能否简要地描述一下 Mantl 这个项目的作用？

Owens：Mantl 为用户提供了部署微服务平台所需的所有基础设施组件。我们所选择的组件都是符合业界标准的，例如 Docker、 Mesos 和 Terraform ，并且让他们能够良好地配合运行，使用户免于编写用于整合这些组件的代码。

Mantl 能够自动完成各种任务，这些任务在一般情况下往往需要投入几个月的时间进行 DevOps。通过这种自动化能力，用户就能够专注于应用的开发，而无需在基础设施上投入过多精力。我们的目标是让用户专注于应用程序的代码与业务的敏捷性，而不是如何设计基础设施 API。

Mantl 框架能够搭建出基础设施即服务以及软件即服务平台，使用户能够通过一种可编程的、可重复的方式部署他们的服务与应用。Mantl 不限于所对应的云环境，它支持在多个云提供商的平台上进行部署，包括 Rackspace、AWS、DigitalOcean 和 Google Cloud Platform 等等。另外，用户也可以选择部署至私有云平台，包括 OpenStack、VMWare、裸机，或者运行 CentOS 的任何系统。

我们正计划打造一个社区，为微服务基础设施提供端到端的解决方案，而不是讨论具体某个组件。这种方案的目标是解决业务上与团队所面对的挑战。它是一个完整的平台，由整个社区负责它的改进，并且进行全面的测试。

InfoQ：你在柏林举办的 Cisco Live 2016 大会上进行了一次演讲，谈到了 Mantl 新版本的发布。自从 InfoQ 上一次披露了该项目的细节以来，Mantl 又产生了哪些变化？

Owens：我们进行了大量的变更，以下是一些需要重点强调的内容：

• 可以通过网络及类似于 Project Calico 这样的工具实现多个数据中心的配置。
• 内置多种可用的服务（并且每天都在增加新的服务）：软件定义网络、软件定义存储、DNS 的支持、数据库、监控工具、服务发现（ Consul ）、加密存储（ Vault ）、日志记录（ELK 技术）、安全性等等……
• 用户的整个项目，从基础设施到应用程序的配置，都可以由版本控制系统进行管理。
• Mantl 项目已在一系列云环境中进行了自动化测试，以确保它的质量。
• 从 Mantl 0.6 版本开始，支持在升级流程中进行蓝绿测试。

InfoQ：你是否能介绍一下 Mantl 所适用的典型用户场景，以及开发者或架构师选择这一项目作为他们的基础设施平台的理由？

Owens：典型的用户场景包括 cloud native（Gartner 定义的“模式2 ”）、数据分析以及转换。最重要的组件包括Mesos、 Marathon 、Docker 和 Consul，其中 Mesos 是 Mantl 的支柱，它为资源（CPU、内存、端口等等）提供了一个抽象层，并且能够在集群的大量主机之间进行工作的分配。Marathon 则是一个用于启动微服务的简单的编排工具。

服务定义将指定所必须的资源，这些资源随后将被提交至 Mesos 中，通过 Marathon 进行分配。Marathon 将确保服务的健康，并在服务发生故障时进行重启。Consul 是一种服务发现策略，Mesos 任务会按照他们的名称自动分配合适的 Consul 终结点以用于服务发现。因此，假设用户要连接到 zookeeper 服务，所需的一切工作只是简单地定位到 zookeeper.service.consul 即可。

Ansible playbook 是最重要的配置文件，它从高层次上定义了哪些资源会被进行安装。举例来说，软件在主机上的安排是通过其中的代码所定义的，该定义为其赋予了“control”这一角色。在所有具备 control 角色的节点上，还将同时被赋予 Vault、ZooKeeper、Mesos、Marathon、Chronos 和 mantl-ui 的角色。这些角色与需要进行安装的组件相关，而这些组件则是在项目中的其他地方进行定义的。

我们相信，Mantl 的架构足够应对应用开发自动化的下一次革新，即微服务模型。

InfoQ：众多的开发者与组织在对 Kubernetes 的使用进行评估，他们认为，如果要通过 Kubernetes 对基于 Mesos 的平台进行部署，那么只有在进行大规模的部署活动（例如 Twitter 和 Apple）时，它所需投入的运维精力才能够达到合理的 ROI（投资收益率）。

Owens：这是个很好的问题。对于任何转换型模型来说，丰富的选择与可扩展性都是关键因素所在。Mesos 选择了框架的形态，这对于某些企业客户来说非常实用。而按照我们的测试来看，Kubernetes 的优势在于出色的性能与良好的可伸缩性。

Mantl 的一大价值在于我们能够在此平台上处理所有运维方面的操作，并且支持大规模的部署。不过，如果你依然对 Kubernates 有兴趣，我们也将在 Mantl 平台中集成 Kubernates，大概在 1 个月之内会推出一个支持 Kubernates 基本功能的版本。如果想要了解这方面更多的信息，可以查阅该项目的 GitHub 库。

InfoQ：你是否计划为 Mantl 的用户提供某种形式的支持模型或 SLA 呢？

Owens：是的，我们正计划为 Mantl 推出一种支持模型，除了开源模型之外，还将提供一种企业级的模型。

InfoQ：你能否为我们讲述一下 Mantl 中的组件是如何选择的？例如 HashiCorp Terraform、Logstash 等等。这中间是否经过了某种评估流程，还是说你只是简单地选择“最佳”的技术？

Owens：我们在选择过程中遵循了一种服务设计方法学，首先要做的是理解这个技术领域中的一些较大的变化，并且为模式 1 乃至模式 2 及之后的方法学定义出一种架构。一旦设计出这种架构之后，我们就会让企业开发者以及合作伙伴为我们提供反馈。同时，我们也会对各种最流行的开源项目进行一些探索。

开源是 Cisco 文化的一个重要组成部分。当我们从用户那里收集到反馈信息，并且在脑海中形成了如何设计这一软件的概念后，我们就通过一个名为“微服务基础设施”的项目为 Mantl 创建了一个原型。我们为这个原型进行了大量的测试、优化、评估以及扩展测试。

在进入服务设计阶段之后，我们审视了目前可用的工具与实际的架构需求之间的差距，并在项目中解决了这些不足之处。这些问题包括网络（为每个容器或容器组分配 IP）、服务发现、服务可用性、安全性与应用策略。最终，我们成功地推出了 Mantl 这一工具，它满足了架构上的需求、使用了“最佳的”技术、并且回应了客户的反馈。

InfoQ：你能否为我们预测一下容器与编排技术在明年的发展状况，尤其是在企业方面的应用？Docker 会一统天下吗？有可能崛起其他可行的容器格式吗？传统的 IT 基础设施提供商如何应对不断变化的格局以及新平台（例如 Mantl 等等）的浮现吗？

Owens：整个行业正在经历一次向微服务基础设施的转型，对于它的宣传力度比我所遇到的任何一次技术转型都要更大。我并不认为在明年会出现这个领域的绝对胜利者，虽然单一的容器与生态系统的采用率应该会继续上升，但由于它的复杂性，我认为人们将以企业级为目标而探索一些整合的解决方案，例如 Mantl。

InfoQ：Ken，感谢你抽空参与这次谈话。你还有哪些东西想与读者进行分享吗？

Owen：我们认为 Mantl 的成功离不开社区的支持，因此竭诚地邀请各位读者们参与到这一项目中。请在 http://mantl.io 中获取 Mantl，并关注我们的 Twitter 帐号 @usemantl 。

在 Mantl 框架的网站上，以及对应的 GitHub 库中可以找到该项目的更多信息。

查看英文原文： Building Microservice Infrastructure with Cisco’s Mantl 1.0