Eric Brewer：容器和微服务是计算的未来
程序员文章站
2022-03-12 18:35:47
...
Mesosphere的高级研究分析师Derrik Harris（原是GigaOM编辑，到访过CSDN）最近采访了Google负责基础设施的副总裁Eric Brew，谈到了容器技术、Kubernetes、云计算当然还有CAP。
Eric Brew，美国工程院院士和ACM Fellow，是著名的分布式系统专家，32岁就拿到加州大学伯克利分校教授（个人网页），提出了分布系统中非常重要的CAP定理。他也是搜索技术先驱Inktomi（李彦宏曾经在这里任职）的联合创始人和首席科学家。他在伯克利培养了David Wagner（伯克利教授）、Armando Fox（伯克利教授，Intel ）、Matt Welsh（曾在哈佛大学后来转到Google）和周枫（网易高级副总裁、有道的负责人）等人才。
下面是采访的要点：
在采访中，Brewer提到他现在主要的工作重点之一就是Kubernetes和容器，会推动Google往这个方向做更多事情。Google以及Inktomi历史上之所以都没有采用虚拟机管理集群，原因是那时候还没有或者不知道现代虚拟机技术，只能在裸硬件上用Unix的进程模型，用进程来做所有事情，在一个硬件上运行多个进程。Google主要系统自始至终都没用虚拟机，只有后来为了运行第三方的一些企业应用，才有一点。
此后，基于虚拟机的IaaS革命来了，各种开源工具和管理环境都是围绕虚拟机的管理和运行开发的。
容器和Kubernetes有一点返璞归真的意思，但抽象层次更高。Google开发Linux容器就是为了使运行在同一机器上的不同作业能够实现性能隔离，容器是Google内部非常基础的技术。
Kubernetes的架构图
Brewer承认，Kubernetes开源后的火爆超出预期，GitHub上每天多达40个提交和评论让他们忙不过来。
Kubernetes并没有使用Google内部系统Borg和Omega的代码，但开发者是同一拨人。Kubernetes尤其是pod和标签相关的一些元素，都是吸取了Borg和Omega系统的经验教训，因此要好很多。最终Kubernetes一些方面与Borg会非常相似，比如使用IP地址的方式，但有些方面比如标签，Kubernetes会比内部系统好得多。要知道，那些经验教训可是来之不易的啊。
Brewer强调，对于开发者而言，将系统部署在Kubernetes这样的容器化系统上，有很多好处。Kubernetes的作用其实是提供应用的长期视角。
容器最初的价值是开发环境（包括程序员的笔记本）与云端部署环境一致。Docker这方面非常出色，但之后呢？Kubernetes回答了这个问题：你可以运行一组容器，以可控的方式升级、导入流量，可以按容器数量扩展服务，因此负载增加时就能方便地增加容量。这些运维方面的方便是Kubernetes的重要价值。
过去几十年分布式系统的发展，Brewer认为核心是云计算兴起使开发者能够把精力花在应用本身上，不用再操心操作系统啊、安全补丁啊、服务器用多大啊、容量规划啊之类的资源运维问题，应用就是一组服务而已。比如SnapChat完全基于GAE，他们一个运维人员都没有。
当然，GAE和其他PaaS平台也有局限，就是不够通用，只能适合某些场景。比如GAE适合网站，Heroku适合与Salesforce集成相关的事情，Engine Yard适合RoR技术栈。
GAE正在试图通过托管虚拟机来逐渐变得更加通用，但是Brewer自己认为很可能能使GAE真正能通用化的是容器。“问题在于，我们是否能将GAE的优点带到容器世界。……这并非易事，但方向是这样的。”
对于自己的学术代表作CAP，Brewer说，很多NoSQL项目都用CAP定理来为自己所作的设计决策证言，但其中有些并不正确。但他认为过去十年广泛地探索不同数据管理系统，是非常有益的，从中获得了许多宝贵经验。架构师工作就是在不同场景下对互相矛盾的考虑因素进行细致而困难的微调。（另外可以参考他在IEEE Software的CAP十二年回顾文章。）
他还提到，事实上金融系统也不是基于一致性的，他们依赖的是审计和赔偿。他们甚至不知道什么CAP定理，只是按照需求做出设计决策而已。当然，他们所作的是正确的决策。比如ATM机在断网的情况下，用户还能取一次小额的现金，从而保证可用性，但不允许再次取款。
展望未来十年，Eric Brewer认为，软件开发的方式将有很大变化。应用将由许多微服务组成的，开发软件就是开发微服务而不再是库。今天，拿到一个开源项目，需要做很多事情，才能与已有系统和其他系统集成。如果能够抽象出机器细节，更关注API和代码，那么一个应用里的十个服务理论上可以用十种不同的语言。这种更以服务为中心的软件将越来越普遍，这一变革的意义与从大型机到客户端/服务器到云，可能是等量齐观的。
容器和微服务，能使整个企业更加敏捷，从而为其用户提供更多有意思的产品，它们是计算的未来。
Eric Brew，美国工程院院士和ACM Fellow，是著名的分布式系统专家，32岁就拿到加州大学伯克利分校教授（个人网页），提出了分布系统中非常重要的CAP定理。他也是搜索技术先驱Inktomi（李彦宏曾经在这里任职）的联合创始人和首席科学家。他在伯克利培养了David Wagner（伯克利教授）、Armando Fox（伯克利教授，Intel ）、Matt Welsh（曾在哈佛大学后来转到Google）和周枫（网易高级副总裁、有道的负责人）等人才。
下面是采访的要点：
在采访中，Brewer提到他现在主要的工作重点之一就是Kubernetes和容器，会推动Google往这个方向做更多事情。Google以及Inktomi历史上之所以都没有采用虚拟机管理集群，原因是那时候还没有或者不知道现代虚拟机技术，只能在裸硬件上用Unix的进程模型，用进程来做所有事情，在一个硬件上运行多个进程。Google主要系统自始至终都没用虚拟机，只有后来为了运行第三方的一些企业应用，才有一点。
此后，基于虚拟机的IaaS革命来了，各种开源工具和管理环境都是围绕虚拟机的管理和运行开发的。
容器和Kubernetes有一点返璞归真的意思，但抽象层次更高。Google开发Linux容器就是为了使运行在同一机器上的不同作业能够实现性能隔离，容器是Google内部非常基础的技术。
Kubernetes的架构图
Brewer承认，Kubernetes开源后的火爆超出预期，GitHub上每天多达40个提交和评论让他们忙不过来。
Kubernetes并没有使用Google内部系统Borg和Omega的代码，但开发者是同一拨人。Kubernetes尤其是pod和标签相关的一些元素，都是吸取了Borg和Omega系统的经验教训，因此要好很多。最终Kubernetes一些方面与Borg会非常相似，比如使用IP地址的方式，但有些方面比如标签，Kubernetes会比内部系统好得多。要知道，那些经验教训可是来之不易的啊。
Brewer强调，对于开发者而言，将系统部署在Kubernetes这样的容器化系统上，有很多好处。Kubernetes的作用其实是提供应用的长期视角。
容器最初的价值是开发环境（包括程序员的笔记本）与云端部署环境一致。Docker这方面非常出色，但之后呢？Kubernetes回答了这个问题：你可以运行一组容器，以可控的方式升级、导入流量，可以按容器数量扩展服务，因此负载增加时就能方便地增加容量。这些运维方面的方便是Kubernetes的重要价值。
过去几十年分布式系统的发展，Brewer认为核心是云计算兴起使开发者能够把精力花在应用本身上，不用再操心操作系统啊、安全补丁啊、服务器用多大啊、容量规划啊之类的资源运维问题，应用就是一组服务而已。比如SnapChat完全基于GAE，他们一个运维人员都没有。
当然，GAE和其他PaaS平台也有局限，就是不够通用，只能适合某些场景。比如GAE适合网站，Heroku适合与Salesforce集成相关的事情，Engine Yard适合RoR技术栈。
GAE正在试图通过托管虚拟机来逐渐变得更加通用，但是Brewer自己认为很可能能使GAE真正能通用化的是容器。“问题在于，我们是否能将GAE的优点带到容器世界。……这并非易事，但方向是这样的。”
对于自己的学术代表作CAP，Brewer说，很多NoSQL项目都用CAP定理来为自己所作的设计决策证言，但其中有些并不正确。但他认为过去十年广泛地探索不同数据管理系统，是非常有益的，从中获得了许多宝贵经验。架构师工作就是在不同场景下对互相矛盾的考虑因素进行细致而困难的微调。（另外可以参考他在IEEE Software的CAP十二年回顾文章。）
他还提到，事实上金融系统也不是基于一致性的，他们依赖的是审计和赔偿。他们甚至不知道什么CAP定理，只是按照需求做出设计决策而已。当然，他们所作的是正确的决策。比如ATM机在断网的情况下，用户还能取一次小额的现金，从而保证可用性，但不允许再次取款。
展望未来十年，Eric Brewer认为，软件开发的方式将有很大变化。应用将由许多微服务组成的，开发软件就是开发微服务而不再是库。今天，拿到一个开源项目，需要做很多事情，才能与已有系统和其他系统集成。如果能够抽象出机器细节，更关注API和代码，那么一个应用里的十个服务理论上可以用十种不同的语言。这种更以服务为中心的软件将越来越普遍，这一变革的意义与从大型机到客户端/服务器到云，可能是等量齐观的。
容器和微服务，能使整个企业更加敏捷，从而为其用户提供更多有意思的产品，它们是计算的未来。