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

(仅为个人观点，不代表作者所服务公司的立场)

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

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

极其轻量：只打包了必要的Bin/Lib；

秒级部署：根据镜像的不同，容器的部署大概在毫秒与秒之间；

易于移植：一次构建，随处部署，因为本身是一个自包含镜像；

弹性伸缩：Docker, Kubernetes,Mesos 这类容器管理平台有着与生俱来的弹性管理能力；

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

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

      这张图是 Adrian Cockcroft 在 2014Dockercon 上第一次提出，介绍了部署速度的演进，但其分类貌似没严格遵循统一视角，比如virtualization和containers从技术角度讲，而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所示。（具体可参考：https://aws.amazon.com/solutions/case-studies/localytics/）

图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介绍视频(https://www.youtube.com/watch?v=WwBdNXt6wO4)，其中一个非常直观的演示场景就是在几乎不影响对外服务的情况下如何迅速将container封装的应用从1.0升级到1.1。这利用到了container轻量化，快速部署的特性，使得以新替旧的成本大大低于升级维护旧container ------ 听起来是个很不错的免维护的场景。表1对immutable infrastructure和artisanal infrastructure(手工艺架构)做了比较。

表1. Immutable Infrastructure vs. Artisanal Infrastructure

Immutable Infrastructure	Artisanal Infrastructure
运维简化	运维复杂度较高
持续集成，自容错	部署更新缓慢，易出错
漏洞和受攻击危险降低	定期patching，升级维护
服务持续，自主修复	服务(中断)演练 (Fire Drill)

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

      此外，经常跟容器技术一起谈论的另一个概念是microservice架构。Martin Fowler在一篇文章(http://martinfowler.com/articles/microservices.html)用下图3 形象地做了说明，

图3. 整体封装(应用) 与 Mirco-Serivce架构

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

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

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

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

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