弯道超车：容器技术究竟为云计算带来了什么？

这两年容器技术及其相关工具，平台异常火爆。在各大技术论坛或云计算峰会议题中，都会占很大比重，各主流云计算平台也无一例外地迅速提供了容器服务。从 2014 年或更早，就有专家预见到 Docker/ 容器技术会是云计算的颠覆力量（disruptive force）。坦率地讲，云计算作为一种服务和应用的业务模式，很难讲会被颠覆，但容器技术的确是云计算的 game changer，它改变了我们思考云计算的视角，是云计算的 reinventor。

目前很多容器技术分析和经验分享中，人们谈论了它带来的诸多好处：

• 极其轻量：只打包了必要的 Bin/Lib；
• 秒级部署：根据镜像的不同，容器的部署大概在毫秒与秒之间；
• 易于移植：一次构建，随处部署，因为本身是一个自包含镜像；
• 弹性伸缩：Docker、Kubernetes、Mesos 这类容器管理平台有着与生俱来的弹性管理能力；

但貌似这些特点，之前虚拟化云管理平台也或多或少都可实现。容器镜像在某种程度上也常被视作为轻量级虚机镜像，至于快速部署，弹性伸缩也可通过自动化脚本、监控、编排（比如 heat）来组合完成。那么，容器技术究竟给云计算带来什么本质的改变呢?

图 1. 部署速度的演进（引自 Adrian Cockcroft, Battery Ventures）

这张图是 Adrian Cockcroft 在 2014 DockerCon 上第一次提出，介绍了部署速度的演进，但其分类貌似没严格遵循统一视角，比如 Virtualization 和 Container 从技术角度讲，而 Serverless 更像应用实现架构的视角，不特指某种技术。假如做个粗浅的解释， Datacenters 可以理解为传统技术下的 IT 平台，Virtualization 可以理解为基于虚拟化的云计算平台，Containers 可以是 Docker、Kurbernetes、Mesos 之类的容器平台，而 Serverless 则可是 AWS Lambda 为代表的新型应用平台。这里，有了另一个问题，毫秒级的部署和秒级的生命周期对云计算又意味着什么？

先以 AWS Lambda 为例，了解一下 Serverless。 Lambda 是个事件驱动的弹性计算平台。用户可以写一段代码，AWS 为其创建一个 Lambda 资源，这样，当指定的事件来临的时候，AWS 的 runtime 会创建相应运行环境，执行代码，执行完毕（或者 timeout）后，回收相应资源。看起来很平常，但 Lambda 一推出即惊艳四溢，为什么？

AWS 网站上有个 Lambda 对流数据处理分析参考案例。Localytics 是一家网络和移动应用分析公司，他们需要对来自安装在超过 30 亿设备中 37，000 多个 App 的数据进行 App 使用情况和用户行为进行分析。工程团队需要经常对子数据集提供新的分析处理服务，通常这意味着分析平台需要考虑额外的容量规划，性能监测和基础设施管理。然而，在这样量级上，这无疑会让平台变得复杂，新服务上线变得缓慢而痛苦。Localytics 采用了 Lambda 实现了新的数据分析服务，这些服务可以并行访问来自 30 亿个设备的流数据，从而能迅速为客户提供相应的分析报告，如图 2 所示。

图 2. Lambda 对社交媒体数据流处理（来自 Amazon 网站）

在 AWS Lambda 之前，IFTTT 已经在提供类似事件驱动动作（/ 计算）的服务，但一直不温不火。为什么到 AWS Lambda 就火呢？从目前了解的有限资料来看，AWS Lambda 是基于容器技术实现的，它把核心函数和服务包装成容器，相信也同样打包了用户代码，同时高度优化了容器的管理和调度，实现快速几乎实时的大规模 scale out 和 scale down。也就是说，同样的业务场景，容器技术让 AWS Lambda 和 IFTTT 产生了完全不同效果。同样，也正是容器易于部署，编排的特性，让用户专注于应用本身而不是计算资源的管理，这就催生了 Serverless 的概念。

Lacalytics 的例子很好说明了容器技术以应用 / 服务为中心的（application centric），而传统基于虚拟化技术的云平台是以机器（虚拟或真实的物理资源）为中心，后者势必让我们去考虑很多所谓 DevOps 的工作，而显然那将是需要不断提高但却永无止境的付出。容器技术以应用 / 服务为核心，跳出了原有以资源管理维护为中心的思维模式，显然是云计算演进过程中的一个里程碑式的跨越。

除了催生 Serverless 概念，容器技术还发展出了另外一个概念：immutable infrastructure（不可变基础架构）。所谓不可变基础架构，就是说系统一旦部署，就不再更变升级。当服务 / 应用需要升级时，只要部署一个新版系统，摧毁旧版就好了。在这个过程中，系统对外服务几乎是持续的。从这个概念描述中，我们很容易想到容器及相应的编排管理框架可以自然地实现 immutable infrastructure。 Google 的 Brendan Burns 有一段对 Kurbenetes 介绍视频，其中一个非常直观的演示场景就是在几乎不影响对外服务的情况下如何迅速将 Container 封装的应用从 1.0 升级到 1.1。这利用到了 container 轻量化，快速部署的特性，使得以新替旧的成本大大低于升级维护旧 Container —— 听起来是个很不错的免维护的场景。表 1 对 immutable infrastructure 和 artisanal infrastructure（手工艺架构）做了比较：

表 1. Immutable Infrastructure vs. Artisanal Infrastructure

事实上，类似免维护的观念在硬件领域已非常普遍。比如电脑的显示屏不亮了，维修工程师要么换屏，要么换主板，没有人会再用仪器去检测显示芯片组了，因为这样的投入费时费工。这里，修（维护升级）还是换（去旧补新）基于很简单的成本逻辑，一旦换新的比升级旧的成本更低时，人们自然选择直接换新的。同样，Container 标准化封装和快捷部署和销毁，让新应用 / 服务取代旧应用 / 服务，比研究如何给应用 / 服务打 patch 升级更为简化高效。由此，容器技术让应用的 immutable infrastructure 变成现实。

此外，经常跟容器技术一起谈论的另一个概念是 Microservice 架构。Martin Fowler 在一篇文章中用下图 3 形象地做了说明：

图 3. 整体封装（应用）与 Mirco-Serivce 架构

并谈到了微服务的几个主要特征：

• 组件化的服务（封装）
• 围绕业务能力组织
• 是独立产品不是项目
• 简化的通讯与连接
• 去中心管理
• 去中心数据管理
• 基础架构自动化
• 容错设计
• 递进设计

从这些特性看，容器技术及其相关的编排管理框架是得它成为实现 Microservice 架构最自然的载体。比如，通常一个 Container 镜像是一个应用 / 服务的独立完整的封装，一般要求是 Stateless，而且从管理角度看，Container 平台都提供自动化的生命周期，scale out 和 scale down 的管理。

Serverless 架构，Immutable Infrastructure 和 Micro-service 架构，这些概念 / 方法的出现，给我们构建云计算应用 / 服务提供了全新视角，使得创建和部署新应用就像使用乐高积木一样简单，大规模的弹性伸缩就如同自动点一下复制和删除命令一样快捷。我们在创建应用 / 服务时，不用再考虑机器（资源），不用再考虑维护，而且有很多可随时拼装的组件待用，同时服务的部署也非常快捷，让失败的成本大幅降低，我们唯一所需关心的只是应用和服务本身。通过上面的讨论，我们看到这一切最重要的推动力量就是容器技术。

容器，这个十几年前的技术，结合近年发展起来编排管理框架，把 Serverless、Immutable Infrastructure 和 Micro-Service 这些美好概念变成了真正的现实，从而给云计算的发展带来了革命性的进步。正如 Docker 的创始人 Solomon Hykes 在 DockerCon 15 的主题演讲谈到的，Container 技术让互联网可编程（programmable），使得大规模创新（massive innovations）成为可能。