架构

云计算的演进变革

Posted Cola🌀

转载：https://www.thebyte.com.cn/architecture/history.html

想了解一个新鲜事物为什么会出现，最好的方法是先去了解它出现的背景、发展的历史。

回顾历史，重点不在于考古，而是借历史之名，理解每种技术出现的原因和淘汰的原因，更好地解决今天的现实问题，寻找出未来的技术演进之路。那么介绍云原生之前，让我们回顾一下过去几十年间云计算领域的演进历程。

　

物理机时代

云计算的起源最早可追溯到 60 多年前的“远古时期”。

1959 年，计算机专家 Christopher Strachey 发表《Time Sharing in Large Fast Computer》论文[1]，首次提出了“虚拟化”的概念。虚拟化正是云计算架构的核心，是云计算发展的基础。

虚拟化技术

虚拟化技术是一种资源管理技术，在各种实体资源（CPU、内存、网络、存储等）之上构建一个逻辑层，从而摆脱物理限制的约束，提高物理资源的利用率。

不过受限于当时技术，虚拟化只是一个概念和对未来的畅想！虚拟化技术成熟之前，市场一直处于物理机时代，当时启用一个新的应用，需要购买一台物理服务器、安装操作系统、配置软件运行环境，最后托管至机房，中间过程复杂且漫长。

在物理机时代，我们看到业务的工作负载是整台物理机，操作麻烦、资源没有隔离、也完全没有服务/资源供应商一说！

　

虚拟化技术成熟

Intel 创始人之一 Gordon Earle Moore，曾提出著名的摩尔定律，简而言之“每隔18个月，芯片的性能会增加一倍”，也就是说计算成本会持续呈指数式下降。随着虚拟化技术的出现，我们能够更高效地利用硬件性能提升带来计算资源。这不仅优化了资源分配，还显著降低了企业的 IT 基础设施成本。

如图 1-1 所示，2000 年前后，虚拟化技术逐渐发展成熟。

这一时期，云计算的重要里程碑之一是，2001 年 VMware 发布了第一个针对 x86 服务器的虚拟化产品 —— VMware ESX。使用 VMware ESX 可以在一台物理机器上运行多个虚拟机，如果业务需要扩容，那就再开通一个虚拟机，操作过程只要几分钟。

从虚拟化技术的发展中，我们看到业务的工作负载由物理机转向虚拟机，资源有了初级的隔离、分配/利用更加合理，而且服务部署的速度和弹性也远超物理机。

　

云计算技术成熟

2006 年 8 月 9 日，Google 首席执行官 Eric Schmidt 在搜索引擎大会（SES San Jose 2006）首次提出“云计算”（Cloud Computing）的概念[2]，而 Amazon 正是那年推出了 IaaS 服务模型的平台 AWS。

事实上，尽管“云计算”概念早在 2006 年被提出，但直到 2008 年整个行业才迎来爆发式增长，国内云计算的标杆阿里云也在这一年开始筹备。从那以后，云计算正式成为计算机领域最受关注的话题之一，同时也成为互联网公司研究及发展的重要方向。

虚拟化技术的成熟，使得云计算市场开始真正形成，基于虚拟化技术诞生了众多的云计算产品，陆续出现了 IaaS、PaaS、SaaS 以及公有云、私有云、混合云等多种云服务模型。

如图 1-2 所示，在这期间出现了云计算领域多个重要里程碑。

  • IaaS（Infrastructure as a Service，基础设施即服务）的出现：通过按时计费的方式租借服务器（卖资源），将资本支出转变为运营支出，这使得云计算得以大规模兴起和普及。
  • PaaS（Platform as a Service，平台即服务）的出现：使开发者不必费心考虑操作系统和开发工具更新或者硬件维护，云服务供应商由 IaaS 阶段的卖资源进阶为卖服务。
  • 开源 IaaS 的出现：开源云计算平台 OpenStack 简化了云的部署过程并为其带来良好的可扩展性，这使普通的企业也具备了自建私有云的能力，云也发展出了 自建私有云、公共云、租赁私有云及混合云等多种服务模型。
  • 开源 PaaS 的出现：开源应用平台 Cloud Foundry、OpenShift 能在混合云、多云乃至边缘的跨平台环境中一致地加快开发和交付应用。利用这些开源软件，企业内部参差不齐的云架构系统，被“推着”成为行业“先进”水准。
  • FaaS（Function as a Service，功能即服务）的出现：通过 FaaS，物理硬件、虚拟机操作系统和 Web 服务器软件管理等等全部由云服务供应商自动处理。无服务器（Serverless）的概念初现，开发者将无需再关注任何服务、资源等基础设施。

　

容器技术兴起

容器技术无疑是过去十年间对软件开发行业影响最深远的技术之一。

虽然容器技术早已出现，但 Docker 创新性地提出了“镜像”（image）的概念，实现了一种新型的应用打包、分发和运行机制，开发人员能够在几秒钟内完成应用程序的部署、运行，无需再担心环境不一致的问题。

Docker 的特点

Docker 的宣传口号是“Build,Ship and Run Any App,Anywhere”。

“Run Any App”一举打破了 PaaS 行业面临应用分发和交付的困境，创造出了无限的可能性，大力推动了云原生的发展。

从此，云计算从仅提供计算、存储、网络资源的初级阶段，发展成为具备强大软件交付和维护能力的综合性服务平台。

从虚拟机到容器，云计算市场经历了一次重大变革，甚至可以说是一次洗牌。在基于容器技术的容器编排市场中，Mesos、Swarm 和 Kubernetes 上演了一场史诗级“大战”。凭借先进的设计理念和高度开放的架构，Kubernetes 最终脱颖而出，成为容器编排领域的事实标准。

如图 1-3 所示，这期间有 2 个重要的里程碑：

  • 2013 年，Docker 发布，容器逐步替代虚拟机（Virtual Machine，VM），云计算进入容器时代。Docker 最大的创新在于容器镜像，它包含了一个应用运行所需的完整环境（整个操作系统的文件系统），具有一致性、轻量级、可移植、编程语言无关等特性，实现 “一次构建，随处运行”。
  • 2017 年底，Kubernetes 赢得“容器编排之战”（Container Orchestration Wars）的胜利，云计算进入 Kubernetes 时代。Kubernetes 是 Google 基于内部容器管理系统 Borg 开源的容器编排调度系统，让容器的应用从“小打小闹”进入大规模工业生产阶段。Kubernetes 将底层的计算、存储和网络资源抽象为标准化的 API 对象，应用不再依赖特定的基础设施，能够轻松在不同环境（如本地、云端、混合云）间迁移。

　

云计算形态演进总结

对以上云计算演进总结分析，可以发现以下规律：

  • 工作负载的变化：从早期的物理服务器，通过虚拟化技术演进为虚拟机，再通过容器化技术演进为目前的容器。
  • 隔离单元：无论是启动时间还是单元大小，物理机、虚拟机、容器一路走来，实现了从重量级到轻量级的转变。
  • 供应商：从闭源到开源，从 VMware 到 KVM，到 OpenStack，再到 Kubernetes。从单一供应商到跨越多个供应商，从公有云到自建云，再到混合云。

图 1-5 形象地概述了二十年间云计算的演进历程，从物理机到虚拟机再到容器，应用的构建和部署变得越来越轻、越来越快。从 IaaS 诞生到 PaaS、FaaS 一路演进，底层基础设施和平台越来越强大，以不同形态对上层应用提供强力支撑。

对于 XaaS 的一路演进，可以简单归纳为：

  • 有了 IaaS，客户不用关注物理机器，只需关注基础架构及应用程序。
  • 有了 PaaS，客户不用关注基础架构，只需关注应用程序。
  • 有了 FaaS，客户只需关注功能和数据。

过去的二十年间，云计算几乎重塑了整个行业格局。越来越多的企业开始降低对 IT 基础设施的直接资本投入，不再倾向于维护自建的数据中心，而是通过上云的方式获取更强大的计算、存储、网络资源，并实现按时、按需付费。这不仅降低了 IT 支出，还显著降低了行业技术壁垒，使更多公司，尤其是初创企业，能够更快速地落地业务想法并将其迅速推向市场。

　

容器技术

Google Cloud 对容器的定义

容器是轻量级应用软件包，它还包含依赖项，例如编程语言运行时的特定版本和运行软件服务所需的库。

Google 对容器的解释看起来也云里雾里！那么，我们延续本章 1解释云计算的方式，从容器技术出现开始，了解它发展的历史，讨论容器技术各个阶段试图解决的问题，从而深入理解容器技术。

　

chroot 阶段：隔离文件系统

容器技术并非凭空出现，它有非常久远的历史！

早在 1979 年，贝尔实验室的工程师在开发 Unix V7 期间，发现当系统软件编译和安装完成后，整个测试环境的变量就会发生改变，如果要进行下一次构建、安装和测试，就必须重新搭建和配置测试环境。工程师们思考：“能否在现有的操作系统环境下，隔离出一个用来重构和测试软件的独立环境？”。于是，一个叫做 chroot（Change Root）的系统调用功能诞生。

chroot 被认为是最早的容器技术之一，它能将进程的根目录重定向到某个新目录，复现某些特定环境，同时也将进程的文件读写权限限制在该目录内。通过 chroot 隔离出来的新环境有一个形象的命名“监狱”（Jail），这便是容器最重要的特性 —— 隔离的体现。

　

LXC 阶段：封装系统

2006 年，Google 推出 Process Container（进程容器），希望能够像虚拟机那样，给进程提供操作系统级别的资源限制、优先级控制、资源审计和进程控制能力。带着这样的设计理念，Process Container 推出不久后便被引入 Linux 内核。不过，由于 “container” 一词在内核中包含多种含义，为避免命名混淆，Process Container 随后被重命名为 Control Groups，简称 cgroups。

2008 年，Linux 内核版本 2.6.24 刚开始提供 cgroups，社区开发者就将 cgroups 资源管理能力和 Linux namespace 资源隔离能力组合在一起，形成了完整的容器技术 LXC（Linux Container，Linux 容器）。

LXC 是如今被广泛应用的容器技术的实现基础，通过 LXC 可以在同一主机上运行多个相互隔离的 Linux 容器，每个容器都有自己的完整的文件系统、网络、进程和资源隔离环境，容器内的进程如同拥有一个完整、独享的操作系统。

至 2013 年，Linux 虚拟化技术已基本成型，通过 cgroups、namespace 以及安全防护机制，大体上解决了容器核心技术“运行环境隔离”，但此时仍需等待另一项关键技术的出现，才能迎来容器技术的全面繁荣。

　

Docker 阶段：封装应用

2013 年之前，云计算行业一直在为云原生发展方向而探索。

从 2008 年 Google 推出的基于 LXC 技术的 GAE，到 2011 年开源的 Cloud Foundry，这些早期的 PaaS 平台一直在思考如何改善软件的交付方式。

就如 Cloud Foundry，它为了解决软件交付的问题，为每一种主流的编程语言都定义了一套打包的方式，开发者不得不为每一种语言、每一种框架、甚至是每个版本应用维护一个打好的包。除此，这种方式还有可能出现本机运行成功，打了个包上传之后就无法运行的情况。所以，早期的 PaaS 平台探索的技术并没有形成大的行业趋势，只局限在一些的特定的领域。

直到 Docker 的出现，大家才如梦方醒，原来不是方向不对，而是应用分发和交付的手段不行。

再来看 Docker 的核心创新“容器镜像（container image）”：

  • 容器镜像打包了整个容器运行依赖的环境，以避免依赖运行容器的服务器的操作系统，从而实现“build once，run anywhere”。
  • 容器镜像一但构建完成，就变成只读状态，成为不可变基础设施的一份子。
  • 与操作系统发行版无关，核心解决的是容器进程对操作系统包含的库、工具、配置的依赖（注意，容器镜像无法解决容器进程对内核特性的特殊依赖）。

开发者基于镜像打包应用所依赖的环境，而不是改造应用来适配 PaaS 定义的运行环境。如图所示，Docker 的宣传口号“Run Any App”一举打破了 PaaS 行业面临的困境，创造出了无限的可能性。

至此，现阶段容器技术体系解决了最核心的两个问题“如何运行软件和如何发布软件”，云计算进入容器阶段！

　

OCI 阶段：容器标准化

当容器技术的前景显现后，众多公司纷纷投入该领域进行探索。

先是 CoreOS 推出了自己的容器引擎 rkt（Rocket 的缩写），Google 也推出了自己的容器引擎 lmctfy（Let Me Contain That For You 的缩写）试图与 Docker 分庭抗礼，相互竞争的结果容器技术开始出现“碎片化”，镜像格式的标准不一、容器引擎的接口各异。

2015 年 6 月，Linux 基金会联合 Docker 带头成立 OCI（Open Container Initiative，开放容器标准）项目，OCI 的目标是解决容器构建、分发和运行标准问题，制定并维护容器镜像格式、容器运行时的标准规范（OCI Specifications）。

OCI 的成立结束了容器技术标准之争，Docker 公司被迫放弃容器规范独家控制权。作为回报，Docker 的容器格式被 OCI 采纳为新标准的基础，并且由 Docker 起草 OCI 草案规范的初稿。

当然这个“标准起草者”也不是那么好当的，Docker 需要提交自己的容器引擎源码作为启动资源。首先是 Docker 最初使用的容器引擎 libcontainer，这是 Docker 在容器运行时方面的核心组件之一 ，用于实现容器的创建、管理和运行。Docker 将 libcontainer 捐赠给了 OCI，作为 OCI 容器运行时标准的参考实现。

经过一系列的演进发展之后，OCI 有了三个主要的标准：

  • OCI Runtime Spec（容器运行时标准）：定义了运行一个容器，如何管理容器的状态和生命周期，如何使用操作系统的底层特性（namespace、cgroups、pivot_root 等）。
  • OCI Image Spec（容器镜像标准）：定义了镜像的格式，配置（包括应用程序的参数、依赖的元数据格式、环境信息等），简单来说就是对镜像文件格式的描述。
  • OCI Distribution Spec（镜像分发标准）：定义了镜像上传和下载的网络交互过程的规范。

而前面的 libcontainer，经过改造、标准化之后，成为 OCI 规范标准的第一个轻量运行时实现“runc”。

什么是 runc

runc 是非常小的运行核，其目的在于提供一个干净简单的运行环境，他就是负责隔离 CPU、内存、网络等形成一个运行环境，可以看作一个小的操作系统。runc 的使用者都是一些 CaaS（Container as a Service，容器即服务）服务商，所以个人开发者知晓的并不是太多。

OCI 项目启动后，为了符合 OCI 标准，Docker 开始推动自身的架构向前演进。

Docker 把内部管理容器执行、分发、监控、网络、构建、日志等功能的模块重构为 containerd 项目 。如图 7-13 所示，containerd 的架构分为三个部分：生态系统（Ecosystem）、平台（Platform）和客户端（Client）。它们各司其职、协同工作，提供了全面的容器管理能力。

2016 年，Docker 将 containerd 捐献给了 CNCF 管理。现在，containerd 已经成为最流行的容器运行时！

再来看 Docker 的架构。经过 runc、containerd 组件的拆分改造之后，Docker 就不再是一个简单的守护进程那么简单了，而是通过集成 containerd、containerd-shim、runc 等多个组件共同完成。

从拆分后的 Docker 架构图看 ，容器运行时被分成两类：

  • 只关注如 namespace、cgroups、镜像拆包等基础的容器运行时实现被称为“低层运行时”（low-level container runtime）。目前，应用最广泛的低层运行时是 runc；
  • 支持更多高级功能，如镜像管理、容器应用的管理等，被称为“高层运行时”（high-level container runtime）。目前，应用最广泛高层运行时是 containerd。

在 OCI 标准规范下，两类运行时履行各自的职责，协作完成整个容器生命周期的管理工作。

　

容器编排阶段：封装集群

如果说以 Docker 为代表的容器引擎，是把软件的发布流程从分发二进制安装包，转变为了直接分发虚拟化后的整个运行环境，让应用得以实现跨机器的绿色部署。

那以 Kubernetes 为代表的容器编排框架，就是把大型软件系统运行所依赖的集群环境也进行了虚拟化，让集群得以实现跨数据中心的绿色部署，并能够根据实际情况自动扩缩。

尽管早在 2013 年，Pivotal 就提出了“云原生”的概念，但是要实现服务具备韧性（Resilience）、弹性（Elasticity）、可观测性（Observability）的软件系统依旧十分困难，在当时基本只能依靠架构师和程序员高超的个人能力，云计算本身还帮不上什么忙。直到 Kubernetes 横空出世，大家才终于等到了破局的希望，认准了这就是云原生时代的操作系统，是让复杂软件在云计算下获得韧性、弹性、可观测性的最佳路径，也是为厂商们推动云计算时代加速到来的关键引擎之一。

Kubernetes 围绕容器抽象了一系列的“资源”概念能描述整个分布式集群的运行，还有可扩展的 API 接口、服务发现、容器网络及容器资源调度等关键特性，非常符合理想的分布式调度系统。

随着 Kubernetes 资源模型越来越广泛的传播，现在已经能够用一组 Kubernetes 资源来描述一整个软件定义计算环境。就像用 docker run 可以启动单个程序一样，现在用 kubectl apply -f 就能部署和运行一个分布式集群应用，而无需关心是在私有云还是公有云或者具体哪家云厂商上。

　

CNCF 阶段：百花齐放

2015 年 7 月 21 日，Google 带头成立了 CNCF（Cloud Native Computing Foundation，云原生基金会）。

OCI 和 CNCF 这两个围绕容器的基金会对云原生生态的发展发挥了非常重要的作用，二者相辅相成，共同制定了一系列行业事实标准规范。其中与容器相关规范有：CRI（Container Runtime Interface，容器运行时接口）、CNI（Container Network Interface，容器网络接口）、CSI（Container Storage Interface，容器存储接口）、OCI Distribution Spec、OCI Image Spec、OCI Runtime Spec。它们之间的关系如图 1-16 所示。

这些行业事实标准的确立，为软件相关的各行业注入了无限活力，基于标准接口的具体实现不断涌现，呈现出一片百花齐放的景象。

如图 1-17 所示，迄今为止在其 CNCF 公布的云原生全景图中，显示了近 30 个领域、数百个项目的繁荣发展，从数据存储、消息传递，到持续集成、服务编排乃至网络管理无所不包、无所不含！