Eric Brewer:容器和微服务是计算的未来

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和代码,那么一个应用里的十个服务理论上可以用十种不同的语言。这种更以服务为中心的软件将越来越普遍,这一变革的意义与从大型机到客户端/服务器到云,可能是等量齐观的。

容器和微服务,能使整个企业更加敏捷,从而为其用户提供更多有意思的产品,它们是计算的未来。

时间: 2024-11-08 01:16:19

Eric Brewer:容器和微服务是计算的未来的相关文章

华为云容器和微服务是什么?

近期华为云围绕容器和微服务,号召行业分析师,应用上云实践者围绕容器和微服务进行深入讨论. 华为云全栈容器与微服务,业务创新快人一步 敏捷.高效.智能是Cloud 2.0时代企业数字化转型核心诉求,华为云全栈容器和微服务全面拥抱云原生,提供全栈云原生应用开发与管理,包括容器.微服务框架.云中间件.压测.APM等系列产品,涵盖应用开发.编译.构建.部署.测试.发布.上线.运维等应用全生命周期管理,让客户更聚焦自己的业务.到目前为止,华为云容器和微服务产品广泛引用在金蝶云.同济大学.图灵生物.华为消费

一个无聊的实验:验证网站是否通过web容器还是微服务部署

一般来说一台web服务器会部署多个实例(且共享80端口),举个栗子例如nginx通常部署多个站点,每个站点都有自己的端口 例如 8091,8092之类的. 通过nginx进行代理.(前提微服务直接使用 80端口而 没有通过nginx之类的代理) 那么web容器是如何神器的命中你想要的网站的呢. 其实这个很简单就是通过http协议请求中Host参数 那么逆向思考 是不是如果在模拟请求的不传Host参数是不是可以?如果类似 ok 咱们使用telnet 验证: telnet www.xxx.com 8

轻量级容器Docker+微服务+RESTful API

[宗师]李锟(44035001) 10:23:03感觉Docker这样的轻量级容器+微服务+RESTful API三者可以形成一个铁三角.这也代表了PaaS未来的发展方向. [宗师]李锟(44035001) 10:47:07 轻量级容器+微服务+RESTful API,这是未来的一个很明显的技术发展趋势.越早投入,就越早收获.同学们记住这些话,都做个有心人.一般人我不告诉他. [宗师]李锟(44035001) 10:47:47学习不要只考虑能不能解决明天的吃法问题,那样做是没有出息的.

容器化微服务

本文是<Java Rest Service实战>的容器化服务章节实验记录.使用的基础环境ubuntu 16.04 LTS,实验中的集群都在一个虚拟机上,其实质是伪集群,但对于了解搭建的基本方法已经满足基本要求了. 一.构建Zookeeper容器集群 1. 定义Dockerfile FROM index.tenxcloud.com/docker_library/java MAINTAINER HaHa#事先下载好zookeeper COPY zookeeper-3.4.8.tar.gz /tmp

Istio旨在成为容器化微服务的网格管道

在精彩的软件容器世界中,当新项目涌现并解决你认为早已解决的问题时,这感觉就像地面在你的脚下不断地移动.在许多情况下,这些问题很久以前被解决,但现在的云原生架构正在推动着更大规模的应用程序部署,这就需要新的工具和方法. 微服务就是一个很好地例子.在此模型下,典型的应用程序或服务将被分解成可以独立部署的功能模块,这些功能模块能彼此分开扩展和维护,并且链接在一起时可以提供应用或服务的全部功能.当使用容器来开发微服务时,后一块可能是棘手的.当它们可能散布在服务器节点集群中时,并且在它们的实例不断弹出时,

基于容器与微服务架构的Web应用实践eShopOnContainers

微软官方提供了一个基于Docker和微服务的示例应用eShopOnContainers:它使用了面向服务的架构并且从服务端到客户端都是跨平台的:该架构使用通过http作为客户端与服务端直接的通信协议.多个微服务每个都有自己的db:另外主要使用的技术Docker.事件总线.DDD/CQRS. 开源项目地址: https://github.com/dotnet-architecture/eShopOnContainers 每个微服务都提供了一种实施方案: Identity微服务:使用了Identit

容器和微服务

原文地址:https://www.cnblogs.com/w-honey/p/12651254.html

有容云:微服务容器化的挑战和解决之道

注: 本文根据6月是18日七牛云微服务课堂-微服务容器化的挑战和解决之道演讲内容整理而成,演讲者:有容云联合创始人兼首席架构师马洪喜,与大家一起探讨了如何通过容器技术将微服务和 DevOps 落地. 嘉宾介绍: 马洪喜,此前担任 Rancher Labs 中国区技术负责人.Citrix 公司资深架构师.Oracle 公司虚拟化产品开发经理等职务,在容器云.IaaS 云.桌面云建设方面拥有丰富的经验. 单体架构 VS 微服务架构 传统单体架构存在各种各样的问题,如加载编译耗时长.代码管理复杂.横向

微服务容器化的挑战和解决之道

注: 本文根据6月是18日七牛云微服务课堂-微服务容器化的挑战和解决之道演讲内容整理而成,演讲者:有容云联合创始人兼首席架构师马洪喜,与大家一起探讨了如何通过容器技术将微服务和 DevOps 落地. 嘉宾介绍: 马洪喜,此前担任 Rancher Labs 中国区技术负责人.Citrix 公司资深架构师.Oracle 公司虚拟化产品开发经理等职务,在容器云.IaaS 云.桌面云建设方面拥有丰富的经验. 单体架构 VS 微服务架构 传统单体架构存在各种各样的问题,如加载编译耗时长.代码管理复杂.横向