1.4 重新流行的PaaS

1.4.1 PaaS平台发展史

PaaS平台的诞生虽然早于容器和虚拟机技术，多年来一直处于不愠不火的状态，但PaaS平台却因Docker的兴起而再次成为大家关注的焦点，新一代的PaaS平台开始以Docker为底层核心，更加接近PaaS最初的愿景。

最初的一批PaaS平台基本上以支持某种具体的编程语言为主，特别是很多公司自己开发的内部PaaS平台，这些PaaS平台通常提供了一套框架和工具以简化上层的应用开发。但实际上大部分平台都没有实现这个目标，反而增加了很大的限制，如开发语言的限制、框架特殊的API接口的限制、支持的中间件种类的限制等。很多情况下，在PaaS平台上部署一个应用反而更加复杂，这些固有的缺陷导致PaaS平台不受欢迎，特别是不受开发人员的喜爱。

2007年以后，出现了新一代的有一些影响力的PaaS产品，典型的代表有Cloud Foundry和Heroku，它们开始基于最早的容器技术实现，采用了LXC技术，但由于彼时容器技术还没有普及，加之LXC的固有缺陷，因此这两款PaaS产品都卖得不好，最后Heroku被Salesforce并购，而Cloud Foundry则成为开源产品。前面提到，Docker公司一开始也是做PaaS平台的，但与前辈们不同，Docker公司在研发自己的PaaS平台的时候，突破性地解决了容器技术长期以来的缺陷，发明了Docker这个新一代的容器引擎并用于自家的PaaS产品，因此Docker在很多人看来实际上属于第三代PaaS技术的范畴。

自从Docker开源并流行开来以后，为PaaS平台注入了新的活力和发展方向，很多公司开始基于Docker开发自家的PaaS平台。最典型的Kubernetes也可以理解为一个思想超前的开源PaaS平台，红帽的PaaS平台——OpenShift——在3.0的时候也抛弃了原先的底层架构，而是彻底拥抱Kubernetes。此外，Mesos也在0.2版本之后加入了对Docker的支持。目前Kubernetes与Mesos这两个平台在大规模生产当中已经得到了应用和验证，这些案例分布在互联网企业、传统的金融电信行业，以及其他行业当中，这也说明这个容器技术已经非常成熟了，而且新一代的PaaS平台正在慢慢地提供商业化特点来满足不同行业的需求。

图1-9是PaaS的发展进程。

PaaS的发展阶段可以分为3个阶段。

第一阶段：PaaS的过去（2007—2012年）。

这个阶段最成功的其实是Salesforce, Salesforce.com作为最成功的SaaS公司，同时也是PaaS的鼻祖，因为SaaS应用在底层需要一个好的PaaS平台支撑，一方面他们需要PaaS平台来运行自家的SaaS软件，另一方面PaaS平台可用于支持用户的定制软件。2007年，Salesforce推出的force.com可以看作PaaS平台的“始祖”，它用来支持客户开发和部署定制软件，用户可以通过Apex（与Java类似）和Visualforce（UI）来开发运行在force.com上的应用，并与Salesforce.com应用进行集成。由于force.com平台采用了meta data驱动的架构来实现多租户机制，因此也有人把force.com称作“Metadata-PaaS”。

2008年，谷歌为了与亚马逊的AWS争夺公有云市场，推出了GAE（Google App Engine）平台，GAE其实与Salesforce的force.com平台一样，也是一个PaaS平台，只不过谷歌的GAE建立在公有云技术之上，并且更加通用。2009年11月，新浪也模仿了谷歌的GAE创建了自己的PaaS平台——SAE，一时间，国内其他互联网巨头纷纷效仿并推出自己的×AE平台，但国内这些PaaS平台因为都只是立足于自己的开放平台战略，并不是真正的中立性开放，而且实力也有限，所以都没有发展起来。与此同时，国外的Heroku也成功模仿GAE并推出了运行于亚马逊AWS之上的公有PaaS服务，虽然Heroku依托AWS不断发展，并且深受Ruby/Rails开发人员的欢迎，但是Heroku并没有达到人们的预期。虽然对于比较简单的、常用的Web应用，Heroku的确非常适合，可以让开发人员专注于业务本身的开发。但是Heroku在一定程度上限制了开发人员的选择，使开发人员失去了全栈的控制权，一旦业务系统复杂起来，将迫使用户从Heroku转向亚马逊自身提供的更底层的IaaS平台。最终Heroku在2010年被Salesforce.com收购，但Salesforce.com有force.com这个PaaS平台，为何还要收购Heroku？最合理的解释是force.com平台已经不能满足其发展需求了。

作为公有云IaaS的绝对领导厂商，亚马逊也在反击，我们可以看到AWS不断向PaaS方向延伸：一是推出各种Application Services，二是在2011年推出了PaaS范畴内的与资源管理和服务编排相关的工具——CloudFormation & Beanstalk，在技术实现上Beanstalk采用了虚拟机方式进行隔离，给予开发人员更大的自主权。

相对于互联网公司来说，传统IT企业在2007—2012年的活动应该说乏善可陈，较之IBM、惠普、Oracle来说，微软在云计算领域的动作是最早的，同谷歌的GAE一样，Windows Azure公有云也定位于PaaS平台。与谷歌和亚马逊的公有云PaaS平台不同，VMware和红帽的定位则是为私有云用户提供PaaS产品。2011年，VMware发布Cloud Foundry，红帽发布OpenShift，这两家公司首先通过开源策略吸引开发人员，而后尝试推出商业版本或者提供商业支持。这个策略很奏效，Cloud Foundry在国内某种程度上成了PaaS的代名词，而OpenShift也有不少商业客户。

第二阶段：PaaS的现在（2013—2016年）。

谷歌在发布GAE后不久，就宣布GAE支持Managed VMs功能。与Azure的VM Role一样，这个功能给予PaaS开发人员完全的控制权。所以，未来PaaS与底层的IaaS之间将不会再有明显的界限与鸿沟，PaaS可能成为IaaS的一个功能，它们会作为一个整体解决方案提供给上层的应用开发商。

作为亚马逊公有云上最成功的应用厂商，Netflix在构建Cloud-Native应用上具有丰富的经验。在Netflix看来，AWS提供的功能和它要开发的Cloud-Native应用需求之间存在一定的差距，这之间需要一个符合自己业务场景需求的PaaS平台来弥补，而最难的工作就是构建这个PaaS平台。从2012年开始，Netflix自己开发的PaaS平台的一些组件逐步开源，目前在PaaS领域也有一定的影响力。

亚马逊方面则继续沿着CloudFormation & Beanstalk的PaaS之路深入发展，于2013年推出了OpsWorks服务。OpsWorks将应用程序管理、可扩展性和性能结合在一起，并且进一步支持各种DevOps原则，如持续集成，用户不但可以控制如何部署代码，还可以使用Chef工具来实现自动化配置。OpsWorks的推出引起了RightScale等亚马逊合作伙伴的不满，随后RightScale宣布支持谷歌的GCE，不得不以支持Multi-Cloud的“新特性”来维持竞争力。

从谷歌的GCE到亚马逊的AWS，公有云上IaaS融合PaaS已成必然趋势，这也是谷歌大力开源Kubernetes背后的真正动力所在。而Docker自2013年以来就非常火热，2013年年底dotCloud公司正式改名为Docker，红帽则在RHEL 6.5中增加了Docker的支持，在其下一代操作系统Atomic里则内置了Docker与Kubernetes组件。此外，谷歌的GAE也支持Docker在其之上运行，我们看到，2015年以后，以Docker为基础的新一代PaaS平台正在兴起，Docker对PaaS的影响力正在加速。

微软将Windows Azure改名为Microsoft Azure，这标志着公有云已经成为微软的优先战略方向，目前正在加速在其公有云上引入Docker生态系统。IBM作为IT行业的巨头之一，拥有最全的软件产品线、领先的开发者生态系统，并在软件开发方法论上有巨大的影响力。在Pulse 2014会议上，IBM公司发布了BlueMix的测试版本，这是一款PaaS产品，通过开放平台技术集成自家软件和第三方产品，旨在帮助开发者快速创建基于云的企业应用，IBM花费大力气营销“PaaS+DevOps”，值得我们深思。

第三阶段：PaaS的未来。

PaaS的未来发展趋势会怎样？我们认为PaaS有3个非常核心的特性，这3个特性一直并将持续影响着PaaS的发展趋势。

第一，多样性。用户的需求是多样的，同时由于历史原因，异构环境一直都是IT行业必须面对的难题，这使得中间件领域的多样性比其他领域更为明显，所以不可能有一个PaaS服务可以满足所有人的需求，SaaS与PaaS融合、PaaS与IaaS融合是不可避免的。对于大型公有云提供商，提供一体化的基础服务是趋势，而对于创业公司，根据特定的细分市场提供差异化的PaaS & DevOps服务和工具也是机会。

第二，加速应用开发。PaaS的最终目标是为应用服务，加速应用开发是PaaS最重要的目标之一，但脱离App谈PaaS毫无意义。从App的热点方向看，未来的趋势有两个：一是遗留应用的集成和迁移；二是应用的移动化、社交化的加速发展。所以PaaS产品需要研究这些领域内的App所需要的特色服务，以便更好地切合市场。

第三，自动化。使用云服务和持续交付可以极大地加速业务创新，当PaaS提供的一切资源都以编程接口方式提供时，这意味着Full-Stack Automation成为可能。而当前兴起的DevOps理念的核心之一也是自动化，用户采纳云服务和DevOps有很强的正相关性，它们的结合是“银弹”，可以使软件开发和交付的效率得到前所未有的提高。此外，从DevOps角度看，如果说PaaS的终极目标是NoOps，那么任何有助于提高应用交付和管理效率的工具、服务都应该纳入PaaS的大范畴。

1.4.2 老牌的Cloud Foundry

Cloud Foundry是PaaS平台中最古老的产品，其特点是整个功能分层比较好，PaaS平台所应该具备的功能特点基本上Cloud Foundry都包含。自从Cloud Foundry基金会成立以后，IBM、惠普、SAP等巨头纷纷加入，有点抱团取暖的感觉，但对于IBM、惠普、SAP来说，作为后来者选择加入基金会却是一个无奈的选择，Cloud Foundry只是巨头们PaaS战略的一部分而已，所以这些巨头在Docker时代又各自有了新的方向，Cloud Foundry很可能逐渐没落。

目前不能在裸机上运行是Cloud Foundry的一个缺陷，因为当时的设计理念是遵循比较标准的IaaS、PaaS、Saas的分层构架而来的，底层必须有一个PaaS平台支撑，所以其必须基于开放的云构架才可以搭建PaaS。如图1-10所示的架构图，Cloud Foundry中位于最下面的BOSH层承担了PaaS平台和底层IaaS平台对接的功能，可以对接公有云或者私有云IaaS平台。

每个在Cloud Foundry中运行的应用都被称为Droplet，它也是容器化的。但Cloud Foundry没有使用Docker，因为Docker出来得晚，也没有用LXC，背后最主要的原因是LXC过于庞大，而Cloud Foundry只需要其中的一小部分功能，并且要求很容易对应用进行测试，所以Cloud Foundry自己开发了一套容器框架——Warden，其与Docker类似。负责Droplet管理的Droplet Execution Agent（DEA）调用Warden接口完成Droplet对应的容器的创建和管理流程。DEA部署在所有物理节点上（来自IaaS层的资源），这就形成了DEA Pool——容器运行时的可调度资源池。

Cloud Foundry也提供了类似Docker的镜像打包工具，同时提供了包含Java、PHP等常见语言所开发的应用的标准化镜像打包工具。但Cloud Foundry没有提供更多的基础中间件的镜像，也没有提供类似Docker公共镜像仓库的机制以供大家分享和下载镜像，每个用户需要自己制作打包项目中所用到的各种镜像。众所周知，打包制作镜像这种任务的工作量和技术难度都很高，因此也导致了Cloud Foundry当前的状态——问世很久却一直没有在各个行业当中得到大规模推广并赢得用户口碑。

那么运行在DEA Pool里的应用如何与外部的服务互联互通？这就需要通过Service Gateway和Service Connector提供的功能来连接对内和对外服务。例如，一个外部的Redis服务要先注册到Cloud Foundry上，才能随后被DEA Pool里的应用所访问，因此Cloud Foundry不是一个非常完整的PaaS平台，这是它最大的缺陷，但是PaaS平台必须具备的功能，如智能路由、用户认证及授权、健康检查、云控制等都相对完备地实现了。因此，Cloud Foundry作为PaaS的鼻祖产品，相对还是比较完善的。此外，目前Cloud Foundry最大的缺陷是没有用Docker，但其新的版本也开始对Docker进行支持，未来Docker也可以运行在DEA Pool里。

1.4.3 Kubernetes & Mesos新秀

首先，我们来说说微服务架构之王——Kubernetes。

Kubernetes是目前PaaS领域里影响最大、最活跃的开源项目。用过Kubernetes的人都会有一个很深的体会：我们日常应用的设计、部署、扩容等环节，在Kubernetes里都能得到很好的支持。

Kubernetes中最重要的一个概念是Service，这实际上是微服务架构理念，Service就是一个微服务，背后对应一组从容器方式运行的程序实例，具备弹性扩容和自动故障恢复的能力。在后面的章节中我们会对Kubernetes进行深入的介绍和分析，因此这里就不做过多的介绍。

图1-11体现了Kubernetes微服务架构平台的核心思想。

Kubernetes第一次将Service的高度提升到超过Machine的地位，我们不再关注应用部署的细节，只要规划好系统是由多少种不同的Service所组成的，每种Service需要部署多少个容器（Pod）实例才能满足性能要求，其他的就交给Kubernetes引擎了，它会根据当前集群资源的使用情况给出最佳的调度方案，并且自动完成容器实例的创建和部署过程，我们无须再花费脑力进行规划。

Kubernetes的另外一大核心设计思想和优势是“高度自动化”。在Kubernetes的世界里，资源调度是自动化的，程序部署是自动化的，监控是自动化的，故障恢复是自动化的，服务平滑升级只要一键，服务扩容也只要一键，当前Kubernetes 1.5甚至已经初步实现了服务扩缩容的自动化。越深入学习和了解Kubernetes，你就越发地惊叹谷歌惊为天人的巨大创造力。

其次，我们谈谈号称“数据中心操作系统”的Mesos，如图1-12所示。

从严格意义上说，Mesos其实不属于一个完整的PaaS平台，而是一个先进的资源分配和任务调度系统。但考虑到资源管理也是PaaS的基本功能之一，并且很多通用应用也都已经能够在Mesos上安装并运行，所以我们也将其归到PaaS平台进行介绍。

Mesos最初并不是针对容器来进行开发的，而是想对开源的大数据管理平台Hadoop进行资源的管控和调度，从而设计和研发的一个开源项目。最早出自加州大学伯克利分校。

Mesos的设计理念分两层：下层是物理机器，组成资源池；上层是称为Framework的应用框架，每一个应用必须针对Mesos的Framework开发框架做定制化的开发后才能在Mesos上运行。为了支持Docker容器，Mesos后来提供了Marathon这个Framework。但Marathon并不是一个完整的微服务架构平台，缺乏负载均衡器、DNS等必需的组件。

Mesos的稳定性和健壮性在业界是比较认可的。例如，Twitter、MBNB的数据中心都有由几千台机器组成的一个大的Mesos平台，现在也有很多的公司以“Mesos+Marathon”为技术平台来搭建他们的容器化运行环境。Mesos提出一个流行概念——DCOS，即把Mesos当成数据中心的一个操作系统，负责统一调度数据中心的每台物理机，其上则运行各种大数据系统，这样可以确保数据中心的物理资源得到更充分的利用。

Mesos和Kubernetes这两个平台是可以完全融合在一起的，因为Kubernetes的重点是实现容器化应用的支撑和运行，而Mesos负责底层资源的分配和管控，相较于Mesos而言，Kubernetes没有更细致的底层资源管控层，所以Kubernetes和Mesos之间的调度没有冲突，完全可以融合在一起实现整个资源调度的平台。

具体的做法是Kubernetes可以作为一个Framework运行在Mesos之上，替换原来的Marathon实现容器化应用的支撑，而底层的资源则完全交给Mesos来负责管控和统一调度。实际上，Mesos中运行Kubernetes的方案就是采用了这个思路。

那么，Kubernetes是否可以替代Mesos呢？

这个问题目前还没有清晰的答案，但我们看到，Kubernetes除了继续完善微服务架构的高级功能之外，也开始进入任务调度的新领地。从本质上来说，任务调度系统的设计和开发难度要远远小于微服务架构系统，如果Kubernetes想往这方面深入发展，凭借谷歌的领导力和实力，有朝一日超越Mesos也不是不可能的事情。

最后，我们来简单谈谈PaaS与Iaas融合的问题。

OpenStack原来是Iaas平台系统，但是随着容器技术的发展，OpenStack也开始支持Docker。最近由谷歌牵头发起的Magnum子项目的目标是在OpenStack上直接支持容器，当然其主要目的是支持自家的Kubernetes平台，这样一来，既提升了OpenStack的应用场景，又借着OpenStack这艘大船，进一步扩展了Kubernetes的地盘，是一箭双雕的好事。

未来基于开源体系搭建的私有云（行业云）的技术栈目前看来非常清晰了，底层的IaaS平台可以用OpenStack来实现主机、存储、网络的虚拟化和集中管控，上层则搭建基于容器化的新一代PaaS平台（Kubernetes、Mesos等）来支撑上层应用，再辅以一些自动化运维工具和定制开发的Web管理系统，即可形成一套低成本同时又具备技术领先性的私有云。

在后面的章节中，我们将具体聊一聊微服务架构、DevOps、Docker、Kubernetes、Mesos，以及企业级容器云在电信行业的应用实践。