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

jopen 9年前

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年。我曾谈到了一般性的话题,且我仍然坚信这一点。在某种意义上来说,我们只是刚巧出现在那里。
 Eric Brewer:容器是云计算的未来

所以,你有没有对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。所以我们做出选择,为了让系统持续运行,牺牲了一致性。

这困扰我好一段时间,直到我最终意识到,这是一个权衡,而且任何人在分布式系统中都希望获得高可用性,不得不对在一致性上进行妥协。
 Eric Brewer:容器是云计算的未来

那是你在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(南京),负责集群运维的工作。