Eric Brewer：容器是计算的未来

本文是一篇对Eric Brewer的采访稿，探讨了他本人对容器和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和Facebook，能够处理巨大的用户量而不宕机，这是不是最终的结果?

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

很多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理论，只是这个决策解决了他们的需要而已。所以我觉得，这就是一个正确的决策。

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

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

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

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

开发者的黄金时代

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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