Eric Brewer：容器是云计算的未来

Eric Brew是Google负责基础设施的副总裁，本文探讨了他本人对容器和Kubernetes过往的看法以及未来的展望。Brewer提到他现在主要的工 作重点之一就是Kubernetes和容器。展望未来十年，Eric Brewer认为，软件开发的方式将有很大变化。微服务和容器将会引领未来。

Eric Brewer，加州大学伯克利分校教授，曾提出CAP理论（分布式系统的重要设计理念），也是网络搜索先驱Inktomi公司的联合创始人。本次采访中， 他作为Google基础设施的副总裁，解释了为何他认为自己在容器上正进行的工作，其重要性不亚于云计算，并讨论了CAP理论自出现以来将近二十年是如何 经受住了检验。

Google目前正在推动一个叫Kubernetes的开源项目，它简化了在Docker容器集群之上构建应用的流程。

为什么是容器？为什么是现在？

编辑： 您在Google的角色是什么？一直以来有一些猜测，但没有真正公开过。

Eric Brewer：我的工作和Kubernetes、容器相关。我非常关注这个项目，并且我会推动Google朝这个方向努力。这让我感到很兴奋。

在Google之前，你和容器有什么交集吗？

早先我一直从事集群相关的工作，所以后来就有了Inktomi公司，这要早于虚拟机，至少早于虚拟机的重新回归[编者注:[1]]。Google也是类似的情况，始于1998年，几乎和现代版的虚拟机在同一个时期诞生，而那时候还没有用虚拟机构建服务的概念。

早先大家都是在硬件上直接搭建服务。Inktomi公司，也包括早期的Google，实质上使用的是Unix进程模型，用进程来完成各种任务，在 相同的硬件上跑多个进程。事实上，Google开始也并没有使用虚拟机，直到它开始做一些企业的东西，因为要跑第三方的应用。但是，对于Google所有 内部的应用，从来也没有使用过虚拟机。

坦率地说，参与提交代码和评价（Kubernetes）的人实在太多。

与此同时，整个IaaS技术革新发生了，它们都是建立在虚拟机的基础上。因此，从这个意义上来说，开源世界不得不使用虚拟机作为其技术基础来构建应用，并且很多的工具以及管理都是围绕你怎么操作和控制虚拟机。

从某种意义上来说，现在有关容器以及Kubernetes的工作，其实就是早先用进程来完成任务的一种回归，不过是在更高的层次上进行了抽象。而 且事实上，在Google内部，人们使用Linux容器，通过在同一台机器上运行不同的任务，来尝试实现性能隔离。这就是为何容器对Google的运维而 言如此重要的一个原因。

不过说真的，如果你仔细分析的话，真正的原因其实是Inktomi和Google公司的诞生早于虚拟机的广泛使用，而并不是因为容器当时已存于工具箱中。

这听起来像是重温21世纪初我们围绕“效用计算”进行的讨论，其目的是不再以服务器作为计算的度量单位。

这当然是我的想法，起于1997年。我曾谈到了一般性的话题，且我仍然坚信这一点。在某种意义上来说，我们只是刚巧出现在那里。

所以，你有没有对Kubernetes如此之受欢迎感到惊讶？

我承认我感到过惊讶。我曾想过它将会成功，我们也着手准备使之变得成功，但同时，坦率地说，参与提交代码和评论的人太多，我们忙不过来。

这也是很令人振奋的，我们不可能处理所有的pull request。我想，根据GitHub的日志，现在每天约有40个commits，需求则远远高于此。每一个都要进行校阅，质量参差不齐。有些很容易，有些则非常困难。

这是个成功带来的难题，我们是很开心的。因此增加了团队成员来尝试改善处理的速度，而且也要求提高我们自己的能力，来和开源社区希望贡献代码或者 已经贡献很多的人进行更好的沟通与合作。我非常兴奋，因为这些都已经有了，这一切太快，以至于很难能了解每天所有这些已发生的变化。

Kubernetes和Borg及Omega（Google内部的两个资源编排系统）有什么关联吗?

我要说，没有共享的代码，不过有共享的成员。

你可以看Kubernetes，特别是像pods和labels等，吸取了Borg和Omega系统的经验教训，坦率地说，这使得现在的 Kubernetes变得更好。最终Kubernetes一些方面与Borg会非常相似，比如使用IP地址的方式，但有些方面比如 labels，Kubernetes会比内部系统好得多。

我得说，那些经验教训可是来之不易的啊。

我的主要目标是......让开发者看待自己的应用像一组服务的集合，而不用直接地考虑有关资源的问题。

这是关于开发者和数据中心

从开发者的角度来看，在这些系统上部署应用的优势在哪里？

有很多的好处。Kubernetes扮演的角色就是使你对自己的应用有一个长远的视角。

容器的最初价值，真的只是你可以在笔记本上运行你的应用，然后也可以在云端部署这个应用。这是一件非常好的事，Docker干得很出色!可是之 后，你还能做什么呢? Kubernetes回答了这个问题，你可以运行一组容器，按照你想要控制的方式去升级、导入流量，你可以通过容器的数量来改变服务的规模，也就是说当你 的负载提高，你可以很容易地增加容量。

这些运维方面的方便，我觉得，才是Kubernetes带来的重要价值。

我很好奇你是如何看待过去几十年分布式系统的发展？比如非常流行的技术如Hadoop和NoSQL的出现，而且我们也开始回来思考共享资源的管理。

我认为以虚拟机作为基本资源，工作受到了某种限制。这不是一个可怕的限制，特别是对小型服务（如果它太小，这也是限制），但对于大多数服务而言，这不是一个可怕的限制。 但它确实干扰了资源利用的效率，以及在某种程度上有关容量的规划。

我认为更大的问题是，作为一个开发者，你真的不用去想这些细节：操作系统啊，安全补丁啊，服务器的数量等等。 这些东西，真的，我们能够为你处理。你只要花更多的时间专注于应用本身。

我想说，我们正在这场革新之中。

这听起来你看待这场革新是有关开发的，而不是作为基础设施的。

他们可以齐头并进，但我的主要目标，其实是，首先，让开发者看待自己的应用像一组服务的集合，而不用直接地考虑有关资源的问题。他们当然不用直接处理有关操作系统安装和升级补丁之类的问题。

我感觉它最终会成为一个巨大的变革，至少和云计算一样。

云计算使开发者期待更好的经验和工具，是因为这个时间点正好呢？还是因为以云服务为基础的小规模初创公司，像Pinterest和Airbnb，现在都碰到了多年前像Google这样的公司遇到的服务扩充问题？

我想有些事情已经发生了。就像你看待SnapChat，他们实际上是运行在Google App Engine上面，对于他们而言，这些问题已经都被解决了。在App Engine中，你不必担心有关操作系统补丁和机器的边界。而且，事实上，SnapChat说，它实际上并没有任何运维人员，都是靠Google来解决。

这就是那种我希望所有开发者可以得到的体验，只是，App Engine不够灵活做所有人想做的事情。然而，容器模型基本上是带给你和虚拟机一样的灵活性，而且多了很多类似App Engine的可用性。还有很多，我们可以用这个方法进行自动化，这些对于开发者而言，这非常重大。

是不是由于灵活性受到限制，使得App Engine以及早期的一些PaaS服务，没有像人们期望的方式获得成功？

我认为他们适合在特定的市场中成功。App Engine适合网站，Heroku适合Salesforce集成相关的业务，如果你想要使用Ruby on Rails，Engine Yard是相当不错的，但他们没有一个是通用的。

我们试图利用托管虚拟机来使App Engine变得更通用。但实际上我觉得能够给App Engine带来通用性的，其实是容器。现在，问题是，我们是否可以将App Engine的所有优点放入容器的世界。随着时间的推移，我认为我们能做到。 这不是小事，但，总的来说，还是要往那里去的。

从客户的角度，大规模采用容器，可以让更多的服务如Google和非死book，能够处理巨大的用户量而不宕机，这是不是最终的结果?

我认为最终的结果是对于行业而言意味着更高的运转速度，对于消费者意味着每天有更多的选择，更多的服务，更有趣的东西。

很多NoSQL的项目采用CAP理论来为自己所作的设计决策证言，但其中有些正确，有些并不正确。

20年后的CAP理论

除了你在Kubernetes上的工作，实际上可能，最出名的是你提出了CAP理论。能简单解释一下吗？

CAP理论描述了你想要得到三种属性，可是你只能获得其中两种，这是一个令人惊讶的和消极的结果。人们想得到的三个属性，第一个，系统一致性，意 味着系统中所有服务器能达成数据值的一致性，比如你有一个银行账户，每个服务器都应该接受银行账户的数值是多少，也就是说，银行账户的数值应该在所有服务 器上是一样的。

第二个是可用性。系统应当在线运行，并可以与用户形成交互。

第三个是为了容错而进行的数据分区，当你将数据分区到几个服务器上时，你可能觉得数据有两份或多份副本，很可靠了，但是服务器之间的网络连接会断线，那么这时你就不能既要一致性，又要可用性，只能在这两者之间选择一个。

这是我在2000年讨论的，究竟是什么意思，大概，是数据库选择一致性，因为他们看重银行帐户的约定，互联网服务则是选择可用性，包括Inktomi。所以我们做出选择，为了让系统持续运行，牺牲了一致性。

这困扰我好一段时间，直到我最终意识到，这是一个权衡，而且任何人在分布式系统中都希望获得高可用性，不得不对在一致性上进行妥协。

那是你在2000年的想法，现在有所变化吗?

现在大家都在位置之上，改变就发生了。整个NoSQL运动，从某种程度上来说，是在探索可用性。很多NoSQL的项目采用CAP理论来为自己所作的设计决策证言，但其中有些正确，有些并不正确。

但是我确实认为在过去十年，各种各样不同数据管理系统的出现，它们所进行的各种探索是非常有益的。任何这些数据管理系统 如Bigtable，Cassandra还是Dynamo等等，探索如何管理数据，这是非常好的。在这个过程中，受益匪浅。

所以目前我们都接受了这个理论，现在需要做的是进一步精细化调配属性之间的关系，来满足不同的应用场景。我认为这也是非常有帮助的。

听起来像是一个通用性的进步。举个例子，如果你足够用心调配，是不是三个属性中，我可以获得2.5个呢？

这还是三选二的权衡，只是当你对数据进行充分分区时，来做这个权衡，这也不是常见的。大多数时候，你可以拥有两个属性，你需要研判如果一个数据分 区出现问题，你要怎么办，你要怎么恢复。这并不容易，其实很复杂，但我想这恰恰就是架构师应该认真考虑的事情[编者注:[2]]。

举例，ATM机有时会和银行机房失去联络，但问题是，在这种状态下，如果有用户等待ATM取款，它到底给不给钱出来呢？如果它给钱，那它是可用 的，但是会导致数据不一致，因为ATM内账户的钱少了，但由于网络中断，银行机房数据库对应的账户钱却没有少，也就是说，实际上这个用户的银行账户中，钱 并没有因ATM给钱而削减掉这一笔钱。实际上，ATM也可以选择可用性，在网络中断的状态下，给的钱会有一个上限，比如200美金，第一次可以这样，第二 次ATM就会拒绝了。

这是靠隐瞒不一致性来进行的风险管理，但，这是一个相当不错的选择。

你允许不一致性，然后你想办法弥补，或者试图阻止。

除了某些特殊行业，如果数据并不总是一致，影响大吗？例如，消费者网站，大多数人都不会注意到。

我想大部分人的方案是，他们允许不一致的问题发生，但会确保可以在事后通过审计来检测到它们。例如，一个很常见的错误是你订购的东西，它可能会被下两次单，或者他们可能忘了你已经取消订单，最终东西意外地寄给了你。这都是很容易弥补的，他们可以把它收回来。

所以一般的答案是你允许不一致性，然后你想办法弥补，或者试图阻止。事实上，金融系统也不保证一致性，它是靠审计和赔偿来解决问题。他们不了解CAP理论，只是这个决策解决了他们的需要而已。所以我觉得，这就是一个正确的决策。

当你构建新的应用时，这会带来什么影响？如果你尝试创建下一代非死book或者推ter，由于上面讨论的问题，你将不得不失去大量的休息时间？

你无须为此牺牲休息的时间，但最好能了解当你进行数据分区时所可能带来的后果。最常见的可能就是有些消息不可用了，或者部分不可用了。偶尔你发现消息被发送两次，或者不一致的消息内容发给了不同的人。你应该知道后果是什么，尽管通常它们都是短暂的，或者无害的。

但是它们也可以是很严重的问题。很多系统因分区而丢失数据，是因为他们根本就没考虑到这些问题。

我觉得你构建应用的方式真的将发生改变。实际上，在你的应用中，很容易启用10个微服务，理论上，它们甚至可以使用10个不同的编程语言。

开发者的黄金时代

如果我是开发者，做我第一个初创公司，如果有对开发者友好的抽象和工具，我是不是能做任何东西？或者我真的需要深入了解计算机科学后才可以开发一个可行的产品？

我觉得人们应该不需要大量计算机科学的知识来开发产品的第一版。你可以选择一些简单的应用，有时候它们也会出问题，但大多数情况下是好的。

但是最终，但你二次开发时，你需要扩充服务，你不得不担心用户流量大增的情况，然后你得思考这些问题。因为它们确实会影响你系统的性能，通过影响系统的可用性，会使你的利润受到影响。

我们以Kubernetes为例。当规模成为一个问题，到底有哪些东西影响你的决策和流程？

我想说这不能解决本质的问题，但我认为你可以利用别人的优点。比如在Kubernetes，我们使用etcd来管理一定的数据，保证它们的一致 性，而且etcd已经做了一些工作。如果你想在Kubernetes里面进行分区，你可能会进入一种奇怪的状态，但问题也不是很大，因为 Kubernetes是运行在同一个数据中心所有的节点上。

麻烦的是你想把应用扩展到多个数据中心，很可能网络会中断，你不得不去进一步考虑这些问题。但是你通常可以推迟这个问题的发生，直到后来你的应用真的进化成为一个企业或者产品。

我认为最终的结果是对于行业而言意味着更高的运转速度，对于消费者意味着每天有更多的选择，更多的服务，更有趣的东西。

有没有什么更通用的东西？这些年，Google和其他公司已经构建、开源了很多技术。在某一点上看，使用这些技术，你也可以避免很多问题。

Bigtable是一个很好的例子。大约10年前，Google构建了Bigtable，是因为Google需要这样一个系统，可以管理相关的数据，同时又能做到有关一致性和可用性上的一些平衡。

但是你是对的：因为大家需要它，在Bigtable的论文发布之后，围绕它出现了很多开源版本，这确实帮助了整个社区。直到最近，你才可以直接使用Bigtable，真正的Bigtable，Google的Bigtable云服务。

如果回头看过去的十年，今天发生的事情，对应用和系统的构建发挥什么样的作用？

我想你构建应用的方法真的将会改变。原因如我所说，一旦你以微服务的方式去看待一个应用，那么软件工程师将不再构建程序库而且开始构建微服务。现在当给你使用一个开源项目，实际上，你有很多事要做，先要让它在你的系统中跑起来，然后再将它和你的其他技术集成在一起。

如果我们不考虑实际机器环境，更多地关注API和代码，一个很大的好处是，为了让API工作起来，你可以对不同的服务使用不同的编程语言。所以， 实际上这就变得很简单，只要启用10个微服务在你的应用中，理论上，它们甚至使用10种不同的编程语言。尝试将大量现存的东西粘合在一起成为一个整体，这 是一个非常大的好处。

那种系统要是变得越来越普遍，会让我们更容易地以服务为中心来开发相应的软件。

这算不算另一种从大型机，客户端-服务器到云的过渡进化，抑或是更大的或不同的东西？

很难知道，现在还非常早期。我感觉它最终会成为一个巨大的变革，至少和云计算一样。

原文链接：Google systems guru explains why containers are the future of computing（翻译：黄帅 校对：李颖杰）

===================================
译者介绍
Henry Huang，目前供职于趋势科技 Trend Micro（南京），负责集群运维的工作。