本文讲的是技术讨论：微服务和容器比虚拟机快多少？【编者的话】本文是Microscaling Systems的联合创始人Anne Currie在微服务日伦敦站的演讲整理稿，通过阅读本文可以深入了解到当和虚拟机比较时，微服务和容器的速度和效率。
Anne Currie，Microscaling Systems的联合创始人，提供了一个关于为何采用容器的很好概述。请享受她最初在微服务日伦敦站的演讲，该演讲研究了什么使得微服务和容器的结合如此强大。
希望你能和我们一样享受这个演讲。
今天，你已经听了非常之多的关于容器的介绍，你可能会有点感觉脑袋已经被容器轰炸了，但是我还要继续讨论容器。我的工作背景是Microscaling Systems的CTO。我已经从事这个行业很长时间了，在不同的领域担任不同公司的CTO，在不同系统的研发工作很长时间，比如后台系统，服务器之类的。我想要跟你们讨论容器，而且我认为每个人今天都应该讨论容器，原因是跟微服务和Orchestrator搭配起来，你可获得难以置信的能力，它可以潜在的完全演化成独自运行你的数据中心，构建你的系统。通过二者配合可以获得无穷尽的能力，它非常具有前瞻性，而不是聚焦于当前的。值得记住的是，当你开始采用微服务架构的时候，这只是其中的一个好处。稍后我会讲它。
我们一直以来讨论的事情之一是谁将成为胜者，平台的未来是什么？一年之后，两年之后，五年之后谁将在数据中心的BareMetal上运行？难道仅仅只剩BareMetal了，这多少有些倒退，这个很有可能不会出现。答案是在过去近十年绝对统治世界的虚拟机，还是看起来是一种新的在生产环境运行应用方式：容器？
为了思考这个问题，我认为回忆并思考下容器的益处是非常有帮助的，对于每种特定的类型的技术你付出的和收获的都是什么？
所以，我们回顾下BareMetal。为什么我们现在不在bare metal运行？为什么bare metal比虚拟机好？答案还是在于我们所运行的环境，基于这样的环境你可以获得的就像实际直接在机器运行的惊人能力。我们停止不用虚拟机的原因是，尽管虚拟机是难以置信的好用，但是他们完全不可变。它跟随物理机扩展非常困难，你需要出去采购新机器，把他们放到数据中心。这是我们十年前就在经历的全部缺点，实际我们很有可能是在bare metal上运行我们的系统。这会导致惊人差劲的服务器利用、资源利用，因为不能只在一个机器上干一件事情，当在bare metal上运行不可能高效的共享服务器资源。所以，这是其中一点使我们远离bare metal的原因，尽管在底层我们还是在运行它。
为什么是虚拟机？
讲到虚拟机，它好像解决了所有bare metal的问题。他们非常具有可扩展性而不是一成不变的。他们完全不知道你所运行的是什么。你可以运行任何操作系统，任何应用在任何硬件的任何主机系统上。网络看起来也很好。安全看上去也很好。虚拟机隔离机器的资源，并应用于自身虚拟机器上的能力是惊人的好。
虚拟机诞生已经很长一段时间了，而且他们确实已经深入人心。我意识到虚拟机的某些特征是有优势的，当我开始发现的时候并不是立即发现的，而且随着时间的流逝而变得越来越清晰。虚拟机是否是一个对所有运营团队产生优势的技术。目前为止开发者对虚拟机的担忧是显而易见的， 它是一种关于不可见的操作技术，全部是关于如何部署，至少是如何启动的事情。所以，由此所带来的虚拟机的所有优势和痛苦都会被运营团队遇到。这过程是痛苦的，学习如何协调虚拟机是一项耗时的工作，它需要年复一年的在商业或者特殊商业领域发展这种专业技能。协调虚拟机工作随着时间的推进会变的越来越可怕。我认为这正是我们所经常忘记的。虚拟机流行起来的原因之一是因为痛苦和收益都在一个团队上，这种情况更容易管理的。那么，当痛苦产生在一个团队中，而不是另外一个不同的团队，那么虚拟机还是很有趣的……
那么，虚拟机怎么了，有什么问题呢？他们还是多少有些笨重。作为高效使用数据中心的资源的一种方式，他们并不是完美的，因为你还是在宿主机器的操作系统上运行了一个完整的客户操作系统。所以，仅仅这个就意味着你要承担多的可怕负担。当讨论物理机的时候，尽管他们比横向扩展的集群快很多，但他们并不是实时扩展的。仍然是需要几分钟来把新的虚拟机上线的，即使在没有扩展基础的物理设施上。扩展基础物理设施通常在你自己的私有云上可行，在公有云上行不通。所以，虚拟机有很大的便利性，但是他们并不能解决所有的事情，考虑到操作性他们至少还有有些不利的。
为什么要容器化？
当你接触到新的竞争者——容器后，这个竞争者用很多方式解决了之前运行应用方式中存在的缺点。他们是非常轻量级，因为本质上一个容器只是多个进程的组合。他是一个使你的操作系统能做和虚拟机所提供的一样的智能工作，从限制一个特殊进程在系统上所能获得资源的角度考虑，容器就是一个系列进程。他们能做虚拟机所能做的事情，但是以一种轻量级的完全不笨重的方式来做的。这跟我们整天一直在谈论容器的优势是完全不同的，它在部署和打包方面上也具有惊人的优势。
Docker是令人称奇的！它是一个非常有用开发生产工具，适合持续集成使用。容器所能做的前述事情是不可思议的，但是这并不是容器所惟一能做的事情，它并不是因此而被发明出来的。现在，我们思考容器，我们需要把容器想象成一个持续交付工具，一个提高开发人员生产力的工具。他们早在十年前就被Google和Sun的人员发明出来作为运营工具来帮助大幅削减他们的运营成本，无论是在资源占用还是照看系统所占用的大量运营时间的成本。今天的讨论我一直在说，但是我真正想说的是容器太棒了，Docker太棒了，但是他们并不是使用容器的惟一原因。容器被发明出来不是惟一为了持续交付，我并不认为这是容器从根本上改变世界的方式。我认为是容器的运营用途才是真正的彻底的具有开创性。
在生产环境中容器并不是完美无瑕的。尽管我们在网络传输上变得越来越好，但网络依然很差劲。在伦敦有几个公司在致力于使网络传输高性能的扩展来满足容器的潜在需求，比如Calico和Weaveworks项目，因为你可能运行成百上千万的容器，需要新的可伸缩的拓扑方式来优雅的处理这个问题。
容器的安全性
对于生产环境的容器，安全性很显然是一个值得关注方面和风险，因为虚拟机防护措施做的就很好，他们完美运行在一个日益具有侵略性的不安全的世界中。我们担心将任何一种新的运营技术放进这个环境中，它都不会像虚拟机那样在安全领域很好的防卫自己。每人都对容器具有很大的兴趣，导致每人都因为容器的安全性而发狂。我认为长期看来这并不是问题。很明显这是值得担心的，但是不至于担心到你不想在生产环境中迁移到容器化基础设施的地步。
正如我所说，Docker太棒了！打包应用的全部方式使得应用移动非常容易，持续交付绝对是令人吃惊的，我并不准备诋毁Docker，因为如果容器不受欢迎的话我们根本不会在这讨论它，它会无须经历任何痛苦或者学习新的技术，就可以立刻帮你实现价值产出。所以，Docker是令人称奇的，但是对于我它真正难以置信的有趣的事情是容器是那么轻量级，相比较类似的产品容器实例化的速度是那么的快。如果我们说虚拟机和容器类似，他们都分配一定数量的资源给特定的应用程序，那么虚拟机能够在几分钟内实现，但是容器实现这个只需要几秒。容器完全是一个游戏的改变者。
为什么是一个游戏改变者？我们首先来讨论下Google是如何使用的。他们使用容器来替代自动扩展的想法。很显然，自动扩展会给你的数据中心带来需要处理的额外资源，例如增加的需求量。想获得自动伸缩的益处是非常艰难的，如果你自己运行数据中心的话，你需要提前六个月来做计划，需要购置额外的机器及这些机器需要的电力，会遇到很多无尽的工作量以至于头疼到你绝不会正真正的想要这样做，或者你提前很长时间来计划这样的方案。云的一个巨大优势就是非常迅速的扩展能力。所以，你可以在几分钟内完成服务扩展，这意味着你可以有效但并不是实时地实现服务扩展。它可以减轻关于容器安全性的感受，因为你仍然需要提前进行计划，你不可能实时响应预想不到的峰值请求，一个不可预料的请求到你系统上的峰值需求。
实际上，有了容器就具有实时响应这些事情的能力了。它不是自动调整的，因为你仍然需要加入额外的资源，这目前并不是实时的操作。通过容器你可以尽可能的重用你已有的资源。例如，想象下你是一个视频后台服务，Kittens R' Us，你发布了相当可爱的猫的视频，你提供了两个服务给你的顾客来展示猫的视频，这是一个需求非常独立的操作。如果人们立刻来找你，他们想看猫的视频。你还提供了视频上传的服务，所以他们会上传他们自己的视频，这并不是一个昂贵费时的操作。实际上，对于你的访问者来说，时间不是敏感的。如果花一分钟来上传视频，那这非常棒，如果要花一小时，那这也不是世界末日。那么你就会有两个服务，一个是非常重要而且时间也很关键的，一个是重要的但是时间不关键的。
Google所想到的主意是为了使用全部处理能力来应对时间关键的服务，应对峰值需求，我们先暂停一分钟关闭那些时间不敏感的服务，那么我们就根本没必要自动调整系统能力了，我们也不需要提前预测请求量了。这是Google这样人的思考方式，Netflix的人们实际上已经使用容器来使他们的系统更加实时和自治了。我认为这确实是一个有趣的概念，它非常吸引人。这个概念需要微服务。我的演讲是完全来自于微服务的。你需要用微服务来实现这个主意。如果你只是有一个整个系统来完成视频服务、视频编码，那么就没有可以关闭的服务了。你至少要有两个服务，理想情况下还要多。所以如果你要重用你的现有资源来实现出来请求，微服务是至关重要的。
这个思想就是你可以很快的打开或者关闭一个服务。你不需要花费十分钟，几小时或者几周在关闭它之前仔细整理清楚。如果你的服务需要关闭来释放额外的资源空间，花十分钟关闭即可，这样就像自动调整一样的效果了，但你并不是实时的。为了利用系统的任何实时的响应特性，你得有微服务并且采用一个合适的方法。
这个效果非常好，但是它确实能实现么？这看起来像一件疯狂的事情，Google宣传他们正在这样做，Netflix宣传他们正在做，但是这个确实可行么？这依赖三件事情，首先依赖微服务，这个看起来很合理，我认为我们在座的所有都认为微服务是可能实现的。再次强调这个不是一个疯狂的讨论，这是一个向产业化管理服务演进所必须要经过的工业化步骤。在一秒内实例化容器的方式并不是必须的或者容易获得的。Google正在这样做，并不意味这所有人都能这样做，可能他们使用的是特殊的我们无法获得的调度器，或者他们运行在特殊的不可获得的硬件上。有很多理由来怀疑他们在这个领域所宣传的正在做的任何事情。有哪些事情只能是他们能做的么？我们来看看这个，因为惟一找到这些疑问答案的方式只能是亲自实验。
在你的盒子上微调整
[16:31] 我们并不相信任何人关于这些事情的言论，所有如果我们想找出在哪里容器可以在几秒内实例化出来，惟一的方式就是亲自实验找出。我们构建一个工具，它是一个非常简单的在不同架构系统上的调度器，因为我们想在各种不同架构平台上尝试。我们所做的就是我们所讲述的，“好吧，让我们采用我们在这提出的最简化的形式，这里有两个服务，一个高优先级服务，对时间非常敏感，一个低优先级服务可以是一个批量服务，我们并不关心它花多久才能执行完。”高优先级服务蓝色表示，低优先级服务以紫色显示。我们还产生随机的模拟请求，以红色线显示。我们让调度器调度来与系统平台打交道，使用你所有的剩余系统资源来尽量满足模拟的请求。这可能实现么？在标准服务器和标准架构上这甚至有一点可能性么？
我们构建了这样的系统，并与其他编排工具进行比较，如ECS（Elastic Container Service，亚马逊的容器调度编排工具）、其他流行的编排工具如Mesos Marathon、Swarm、Kubernetes，还有直接调用Docker API的方式。考虑到不同平台，我们在bare metal、EC2、Agile上运行试验。在每种情况下，它的实际表现基本上是一致的，我们在每个平台看到的性能也几乎都是相近的。是的，它可以实现一种类似实时的请求处理。在标准的编排工具、标准的物理架构上是可以在近似实时的跟随你平台上的运行容器的变化而变化的。这个是使用平台的最根本想法，它可以根据落到你系统上请求量来进行有效的自我管理，自我调节，自我修正。
[19:20]Google和Netflix正在这样做，但是他们这样做的真正目的是为了什么？他们做这事是因为我们大多数对于资源的利用方式对于他们来说是不可接受的。全世界数据中心的平均利用率大约在10-15%。这是相当可怕的，不是吗？向虚拟机迁移和向云迁移实际上使得这一现象更加严重，而不是更好。现在很容易就可以提供冗余了，我们确实不需要采用那些可怕的选择了。如果你要采用自动扩展，要么可以预测你的请求量，这是完全正确的但是据我所知几乎是不可能的，要么提供巨大的冗余容量处理能力，而这需要将该能力放大近十倍。这是相当的惊人的，不是么？
对于那些人来说这是非常昂贵的。他们完全不可能那样做，所有他们需要采用一种更加自适应的但并不经常被采用的管理方式，它很少涉及到自动扩展，而是涉及到根据你的当前探测的请求量来重用你的现有处理能力，我们称之为微扩展。通过这种方式，Google获得了大约65-70%的资源利用率。相比10-15%来说是巨大的进步。Netflix获得大约50%的利用率，因为他们使用批量进程，比Google稍微笨重一些。再次强调下，这是我们所获得的五倍之多。我认为这就是Keith之前提到的想法并不是不现实的，你可以通过向智能的编排调度模型成倍甚至三倍的提高资源利用率，还可以大幅削减你的主机成本和运营成本。想象下你系统的管理难度，我认为这是非常值得做的事情。
他是什么？为了什么？我们在这为了什么而奋斗？我认为在目前，我们是为了获得更低花费，更高服务器密度，更低维护成本，更多自治功能，更加自响应的系统，这些系统可以自己照看管理自己而不需要你一直不断的来预测不可预测的请求量。这是考虑采用容器作为运营技术手段我们所能获得的一切，相对于单纯的部署或者开发手段来说。
是我的演讲时间快到了么？好吧，此时我应该完成了大部分的阐述了。我的最后一张幻灯片是总结性的。我在开始就谈论五年内关于谁将在数据中心的bare metal上运行，谁将这场战斗的观点。这场争斗已经开始了，我也并没有意识到，但是这场争斗已经在Google和Netflix的人们之间开始了。有人支持虚拟机，有人支持容器，但正如上面所说的只有容器才能交付出我们所需要的那样性能提升、自治功能和资源利用。
尽管我们认为容器会赢得这场竞争，实际上已经在某些方面上赢了。我们也将最终赢得这场竞争。我对此毫不怀疑。容器完全能够实现低维护低成本。运营角度上，你需要什么来到达获得这些好处呢？你需要进行容器化，但是这个之前有很多关于容器化的讨论了。你还需要将编排工具采纳进来，这是非常痛苦的。你需要知道什么将要交付给的蓝图。这有一些非常优秀的调度编排工具，Mesos、Kubernetes、Swarm、ECS，他们都非常棒。对于普通用户来说，在一开始考虑他们的时候，他们都是在很稳定的状态，可以放心体验尝试。微服务容器化和编排后对于数据中心来说是一个完全不同的世界，我认为这样的迁移是值得的。是的，我们开始吧！容器即将来临！我对于你今天听到的毫不怀疑，它跟微服务配合非常完美。这就是全部内容。
原文链接：Tech Talk: Microservices and Containers. How Much Faster Than a VM?! （翻译：姜俊厚）
原文发布时间为：2016-09-03
本文作者：姜俊厚
原文标题：技术讨论：微服务和容器比虚拟机快多少？