微服务与容器

微服务与容器

【编者的话】本文对比了裸机、虚机和容器所适用的不同场景；介绍在微服务场景中使用容器的优势；阐述了谷歌和Netflix如何使用容器做到数据中心的超高利用率和对业务的弹性伸缩；解释了为什么容器化和编排框架是微服务做到弹性伸缩的关键技术，并提出了“微伸缩”的概念。

原文链接：Microservices and Containers. How much faster than a VM?!

译者介绍

李光成，IBM中国研究院资深研究员，研究方向是云计算基础设施及技术。目前在做的是Docker资源隔离方面的研究项目。

正文

目录

• 视频

• 幻灯片

• 演讲稿

• 关于演讲者

作为 Microservices Day London 的最后一篇精选演讲, 我们分享Anne Currie的关于微服务和容器的话题, Anne Currie是Microscaling Systems的合伙人, 这篇演讲提供了关于“为什么”接纳容器的很好的视角

我们希望你和我们一样喜欢这个演讲！

微服务和容器. 比虚机快多少？！

在 Microservices Day London 上的演讲

Slides

Containers Vs VMs? - It’s All About Microservices

演讲稿

简介

今天你已经听到了很多关于容器的演讲, 你或许感觉有点被容器的话题围绕，但是我将再次讨论容器。我的背景是Microscaling Systems 的CTO. 我已经在IT界工作了很多年，从事过很多不同领域的工作，做过几个公司的CTO，也接触过很多的系统。做过后台系统和服务器的事情很长时间。我将讨论容器的原因我认为跟所有人都在讨论容器的原因一样，就是通过微服务和容器以及编排的匹配，可以得到巨大的能量去改变甚至是彻底颠覆运行数据中心的方式以及系统的架构，虽然有点非现实主义而不可能立刻实现，但是还是值得听一下并且记在心里，这是在迁移到微服务架构时可以得到的好处.我将讨论这个问题。

今天要讲的一点是谁将要和什么平台将是未来的趋势。谁将在未来1年、2年和5点内在数据中心中使用裸机？会只有裸机吗，这看上去有点像是倒退，但实际上不是。在过去很长一段时间差不多是10年间虚机主导了整个世界。会是容器吗？ 这显然是一个在生产环境中运行应用的新的方式。

为了思考这个问题，我觉得思考一下这些技术选项各自的优缺点会是很有帮组的。

为什么使用裸机?

让我们退一步来思考裸机. 为什么我们现在不使用裸机？为什么裸机被虚机所代替？ 直接在一个机器上运行应用程序最大的好处是能够获得强大的性能。 我们不在这么做而是转到使用虚机的原因是，虽然使用裸机能够提供很好的性能但是这非常不灵活. 向上扩展一个物理的机器是非常困难的，你不得不购买新的机器并把它们放到数据中心。在过去10年间当我们在数据中心的裸机上运行我们的系统时经历了所有的这些问题。使用裸机同时也造成了很低的服务器利用率，你不能在一台机器上只运行一个程序，使用裸机并没有有效的在不同的应用之间共享资源。这就是为什么我们不再使用裸机，虽然底层还是在裸机上运行。

为什么使用虚机?

虚机的出现看上去解决了使用裸机的所有问题。使用虚机非常灵活而不是像裸机那样不灵活。虚机完全不关心运行什么应用程序，你可以运行任何的操作系统，任何的应用,在任何的硬件和Host操作系统上。网络和安全都是有保证的，资源的分配和管理也是非常有效的。

虚机已经存在了一段时间了，已经磨合的很好了。关于虚机我意识到的一个好处，虽然一开始的不是很明显但是越来越明晰，就是虚机技术对于运营团队来讲带来了很多好处，而对开发者来说是透明的，虚机是一种无形的技术，仅针对运营团队，只关心被部署的东西，至少是作为开始。因此，使用虚机带来的好处和使用需要学习的东西都由运营团队负责。学习如何有效的编排虚机是非常痛苦的，可能需要几年来积累这种跨业务的技能。随着时间的推移，虚机的编排已经变得容易很多。虚机变得流行的一个很重要的原因是付出和收益都落在同一个部门，这使得管理变得更容易。

虚机有什么错呢？虚机有做错任何事情吗？嗯，虚机还是有一点重。虚机还不是一种完美的方法来提高你的数据中心机器的利用率，因为你是在一个完整的Host操作系统上运行另外一个完整的操作系统。这带来了大量的额外开销。另外对于横向和纵向扩展来讲，虚机已经比裸机好很多，但是还不是实时的扩展，仍然需要几分钟来上线一台新的虚机，即使你不需要横向扩展你的基础设施。如果你在运行自己的云环境，你就需要横向扩展你的基础设施，而如果你是在使用公有云，则不需要横向扩展基础设施。因此，虚机有很大的优势，但是不能解决所有问题，在运营团队看来虚机还是存在一些不足。

为什么使用容器?

现在轮到容器，一个新的竞争者，在很多方面解决了上述两种应用运行方式的弱点。容器非常轻量级，因为在本质上容器只是一些进程的组合。它仅仅是一种使你的操作系统做一些虚机也能做的聪明事，例如对某个特定的进程或者一组进程限制系统资源。它可以以一种更轻量级的几乎没有任何额外开销的方式完成虚机的任务。这跟我们今天一整天都在讲的优势完全不同，是关于部署和打包的巨大优势。

Docker非常棒！它是一个非常有用的开发效率工具和持续集成工具。这只是容器可以做的一件了不起的事，但这不是容器能做的所有事情，也不是发明容器的原因。现在每当想起容器，我们倾向于认为容器是一个持续交付和开发效率工具。容器其实是在10年前由谷歌和Sun的工程师们发明作为一种运营工具来大幅降低他们的运营成本的，不管是从资源角度还是从管理机器的精力来讲。我会在今天的整个演讲中说明这一点，但是我非常想说的是，容器非常好，docker非常好，但是这不是我们使用容器的唯一原因，也不是发明容器的原因，我不认为这是我们彻底改变时间的方式。我认为有效的利用容器才是真正的完全的开创性。

然而容器在生产环境中并不是完美的，网络部分还是非常薄弱的，但是正在改善，有几个在伦敦的公司例如Project Calico和Weaveworks正致力改善容器网络使得可以在大规模环境中应用，因为你可能运行上百万的容器，你需要一个工具来有效的管理这些容器的网络配置。

容器安全

安全显然是在生产环境中使用容器的一个永远的关切、风险和担心，因为虚机是一个经过证明的如此安全的技术，我们正处在一个越来越不安全的世界中，在运营中引入任何不如虚机安全的技术都会使得大家担心。安全成了每个使用容器的人的兴趣点，所有人都因为容器安全而变得疯狂，我认为从长期来看这不会是一个问题。这确实真的担心，但是不至于担心到如此程度认为从长期来看也不应该将生产环境的基础设施迁移到容器环境。

就像我说的，Docker非常棒！它的整个应用打包过程使得应用从一个地方迁移到另外一个地方变得非常容易，持续交付绝对非常棒，这里边有Docker的功劳。如果不是容器变得很流行并且给了我们很多好处的话，我们也不会在这里讨论容器了，容器的使用不会带来任何学习新技术的痛苦。因此，Docker是极好的，但是最我来说，容器真正有趣的是它们如此轻量级，可以比其它任何类似技术更快的部署。如果我们说虚机可以分配一定的资源给应用程序，但是虚机需要使用几分钟，而容器则只需要几秒钟。这将带来真正的变革。

为什么会带来真正的变革呢？让我们先讨论一下谷歌是如何利用容器的。他们用容器来抛弃弹性伸缩的想法。弹性伸缩是指当业务需要时自动增加新的资源到数据中心。弹性伸缩在过去是非常困难的，尤其是你需要运行自己的数据中心时，你不得不提前6个月做好计划，你不得不提前购买新的机器，为这些新的机器加电，这非常令人头疼。你永远不想这么做，或者不得不提前很长时间计划。

云计算带来一个巨大的好处是非常快的弹性伸缩。你可以在几分钟内完成弹性伸缩，意味着你可以高效的弹性伸缩，但是还不是实时的。这给了一种错误的关于安全的意味，因为你还是需要提前计划，你不能实时响应一个意外的峰值，和一个落到你的系统上的意外的需求。

使用容器是可能做到实时响应的。这不是弹性伸缩，因为弹性伸缩你需要增加额外的资源而这绝不可能是实时的。你可能可以通过容器实时的重用已经存在的资源。例如，假设你提供一种视频服务Kittens R’Us，你提供给两个客户非常可爱的喵星人视频服务，你给他们播放喵星人视频，这是一种非常需求依赖的操作。如果有人需要现在就看一段喵星人的视频，你同时也提供视频上传服务，因此他们可以上传自己的视频，这不是一个昂贵的操作。事实上，这对你的访客来说是时间上不敏感的。如果他需要一分钟上传一个视频，这很好，但是如果他需要一个小时才能上传一个视频，这不会是世界末日。你提供了两种服务，一种是非常重要和时间敏感的，另外一个是重要的，但是时间上不敏感。

谷歌解决这个问题的办法是：“好吧，等一下，如果我们在发生峰值时把这些时间不敏感的任务所使用的资源分给时间敏感的服务使用，或许我们就不需要弹性伸缩，也不需要提前预测需求”。这其实差不多就是谷歌和Netflix如何利用容器使得他们的系统能实时和自管理。我觉得这是一个非常有趣的概念，我认为这是非常使人着迷的。这确实需要微服务，我的演讲也是从微服务派生出来的。你不得不使用一个微服务方法来实现此功能。如果你在使用整体软件架构，你使用一个整体软件来做视频播放和视频编码服务，那么你就没有什么东西能改变了。你将需要两个服务，理想情况下有更多的服务。如果你想实时地重用现有资源去处理需求，微服务是至关重要的。

一个“家畜不是宠物”（译者注：指服务分类）的方法,我不知道大家是否熟悉家畜或者宠物。基本的想法是，你可以非常快速的打开或者关闭一个服务。你不需要在关闭一个服务之前花十分钟或者几个小时甚至几周来仔细的考虑和整理。如果你的服务需要花十分钟来关闭和释放资源，你或许还可以被称作弹性伸缩，但已经不是实时的了。为了利用系统的实时反应性，你需要同时使用微服务和“家畜或者宠物”方法。

这些都非常好，但是它真的是这样吗？这看上去很疯狂，谷歌说它在做，Netflix说它也在做，但这是真的吗？这依赖于三件事情：这依赖于微服务，这应该是真的，我相信微服务是可能的。家畜不是宠物，这也不是一个疯狂的话题，这是业界非常常见的管理服务的新的方式。在一秒钟内实例化一个容器，这不一定是真的或者可以实现的。不是因为在做就意味着所有人都可以做，也许是因为他们在使用一个我们无法使用的编排系统，或者他们在特殊的硬件上运行。有很多理由使我们怀疑他们说的他们正在做的所有事情。这些事情只有他们才可以做吗？我们不得不自己去调查，因为发现问题真相的唯一方法就是实验。

微伸缩

在这件事情上我们不相信大家说的，因此为了发现如何在一秒内实例化这些应用容器，唯一的方法就是自己去做实验。我们构建了一个工具，是一个非常简单的调度器运行在不同的编排框架之上，因为我们想用不同的编排框架进行实验，我们所说的就是我们所做的“让我们用最简化的方式进行，只有两种类型的服务，一种是对时间非常敏感的高优先级服务，另外一种是低优先级服务，可能是批处理任务，不太在意用多长时间运行”。高优先级的服务是蓝色的而低优先级的服务是淡紫色的。我们随机产生模拟的任务需求，用红线标识。我们的调度器会与编排系统协同去尽量满足业务的要求，而同时使用所有的其它资源运行批处理业务。这可能吗？在标准的服务器和标准的基础设施上真的可能吗？

我们构建了这个工具并且在Amazon ECS（Amazon容器调度器）上运行。我们使用了Mesosphere另外一套非常流行的调度器Mesos和Marathon。我们也使用了Docker Swarm, Kubernetes和直接调用Docker API。关于基础设施，我们使用了裸机，也尝试了Amazon EC2和Agile。在每一种场景中，或多或少都表现出了相同的行为和类似的性能。是的，它可以做到近似的实时。使用这些标准的基础设施和标准的编排框架可以做到以近似实时的方式调整集群中哪些容器运行哪些业务。这就是让基础设施根据业务的需求进行有效的自我管理，自我调整和自我修复的想法的基础。

谷歌和Netflix在这么做但是他们这么做的真中目的是什么呢？好吧，他们这么做的目的是因为我们大多数人可以达到的资源利用率对他们来讲是不可接受的。从全世界范围来讲，数据中心的平均利用率是10-15%。这非常糟糕，不是吗？而使用虚机和云环境并没有是情形得到好转而是变得更糟糕。现在非常容易过度部署资源而我们并没有更多的选择，如果你要使用弹性伸缩，你不得不做绝对正确的提前规划，或者不得不过度部署资源，我们的过度部署的资源大略是超过10倍，这非常令人惊讶不是吗？

针对于谷歌或者Netflix的各位来讲这太昂贵了。他们不可能为了很少发生或者几乎不发生的弹性伸缩需求来过度部署，他们需要一个更高效的方法来管理这些资源，这个高效的方法就是根据目前需求的情况重用系统中已有的资源，我们把这个叫做微伸缩。使用这种方法，谷歌达到了65-70%的资源利用率，这跟我们的10-15%形成了鲜明的对比。Netflix也达到了大约50%因为他们比谷歌使用的批处理服务更少，但这也是我们的利用率的大约5倍。我认为是Keith先前讲过的，通过使用更聪明的和被编排的容器模型达到两倍甚至三倍的资源利用率并不是不切实际的，这可以极大的降低你的设备成本和运营成本，并简化系统管理。我认为这是值得去努力的。

这是什么？我们在追求什么？我认为从运营团队来讲，我们追求的是通过提高服务器的密度来降低成本，减少维护成本，系统可以自愈，系统响应更迅速，系统会管理和照顾好自己而不需要你经常去预期业务负载，有些时候业务负载是不可预期的。这是将容器技术作为一种运营技术而不是一种部署和开发技术所能获得的全部好处。

我是不是讲太多了？太好了！好吧，我基本上已经结束了。我的最后一页幻灯片是一个总结。我在开头的时候讲的关于在5年内谁会在赢得在数据中心的裸机上运行程序的战争的话题，战争已经开始了，我也没有意识到这一点，但是战争已经由谷歌和Netflix发起了。他们审视了虚机和容器，认为只有容器才能提供我们需要的高性能、自愈和资源利用率。

虽然我们认为有一场战争可以去赢，但是容易已经算是赢了，我们最终会到达，我对这一点深信不疑。它确实提供了更低的维护需求和成本。从操作层面上，我们如何才能做到呢？好吧，你需要容器化，早些时候已经讲了很多。你还需要一个编排框架，这是有点痛苦的过程。你需要理解这将会为你带来什么。已经有很多非常优秀的编排框架如Mesos, Kubernetes, Swarm, ECS；它们都非常好。它们至少是一种得体的选择，让你去开始思考这个问题。使用容器话和编排的微服务对数据中心来说是一个巨大的变化，值得我们去推动。是的，我们来了！容器来了！我深信在你听了我今天的演讲之后你会觉得容器太适合微服务了。好了，我的演讲结束了。

关于演讲者

Anne Currie已经在技术领域工作超过20年, 工作范围包括从核心服务器技术到e-commerce平台的所有领域. 她目前是Microscaling Systems的CTO, 专注在微服务和容器的融合。

关于Flocker

Flocker是一个开源的为容器化的应用设计的容器数据卷管理软件。它是一个运营团队可以用来在生产环境中运行有状态服务例如数据库的得力工具。

• Try Flocker using the Volume Hub today

• 微服务与容器.docx