PaaS作为新一代的云计算平台，目前在业界得到了广泛的关注与讨论。诸多大公司也纷纷推出自己的PaaS平台，比如Pivotal的CloudFoundry, IBM的Bluemix和Redhat的OpenShift等。其实在此之前， PaaS已经有很长一段时间的发展历程。在2007年，Salesforce最早发布force.com，其目的是支持第三方客户在Salesforce.com上开发和部署定制软件，它基本使用的元数据驱动的方式来开发和管理应用。在2008年4月的时候，技术巨头Google发布GAE(Google AppEngine)，其目的是争夺独立开发者和创业公司的市场。GAE在发布之时就得到了业界的广泛关注，在很多方面都突破了原有的技术思路，比如使用容器来部署应用，简化的用户体验等。但是，我们也看到，GAE在业务上并没有获得巨大的成功，后面的发展也证明AWS的策略更加成功。一年之后，新浪SAE也发布，其命名、发展思路与架构模式和GAE非常类似，当然，业务上也同样不太成功。
AWS也看到了PaaS平台的潜力，与2011年发布其官方PaaS平台Beanstalk。在Beanstalk之前，几乎所有的PaaS平台都是基于Linux容器技术LXC。AWS提供了另外一种打造PaaS平台的思路，即基于虚拟机完成应用的自动部署和运维，同时Beanstalk也提供了自动弹性伸缩的功能。容器和虚拟机主要是在资源利用率、安全性和隔离性上有所差别。
CloudFoundry是另外一个里程碑式的PaaS产品，在推出之日就吸引了诸多的焦点，甚至带动了PaaS搜索关键字在Google趋势里面搜索量的飚升。CloudFoundry的成功有这样几个原因：首先它是开源的和免费的。开放源代码意味着全球所有的开发者都能非常简单的部署自己的PaaS平台，同时也意味着让所有的开发者看到打造一个PaaS平台需要哪些关键的技术；其次，CloudFoundry是开放的，它能够支持多种编程语言和开发框架，也能够提供多种服务类型，虽然CloudFoundry的架构经过了几次重构，但是开放性这个关键的特性一直都保留；第三，CloudFoundry提供了一个极简的用户体验，开发人员只需要简单的几个命令就能部署自己的应用系统，彻底颠覆了之前的用户体验。当然，这种用户体验最早是来自于Heroku。
最后值得一提的是大热的Docker。Linux容器技术已经出现了很多很多年，在各大互联网巨头公司也使用了很多很多年，但是Docker利用AUFS技术第一次将容器实例镜像化，这一突破性的创新能够让容器实例可复制、可迁移、可重用。该思路彻底打破了以前只有使用虚拟机才能迁移实例的局限，所以迅速在业界得到追捧。Docker的东家DotCloud甚至把自己的PaaS平台卖掉以专心发展该项技术。
目前来看，PaaS平台技术还处于群雄逐鹿的状态，诸多技术巨头都在不遗余力的发展自己的PaaS平台以跟上技术发展的脚步。以此同时，独立的PaaS提供商（如Heroku、AppFog）等也纷纷被技术巨头收购，这带来了一种质疑的声音是PaaS是否真的能够成为一项独立可持续发展的业务模式。下文将会对此做一些简单的探讨。
二、PaaS架构比较
大致来看，PaaS的实现分为两种：以虚拟机为基础或是以容器为基础。前者的代表是AWS，后者的代表则是GAE, CloudFoundry和Heroku。前文已经提到，AWS是基于虚拟机技术来打造自己的PaaS平台，其架构模式大致如下图所示： 
具体而言，AWS基于如下构件打造了Beanstalk：首先是负载均衡层（ELB），该层需要将用户的请求投射到对应的服务器实例，同时，负载均衡层还需要。当应用实例出现扩容时，需要动态将调整的服务器实例注册到对应的域名上，以完成分流；中间是Web服务器层，目前ElasticBean支持Java、Python和PHP等多种编程语言，尽量为编程人员提供多样性的选择，开放性基本是所有PaaS平台的标配。在服务后端，Beanstalk基本依托于AWS本身的服务生态系统为应用提供服务，比如RDS、S3、DynamoDB等。
CloudFoundry等平台则是基于容器技术打造。相比于虚拟机，容器带来的系统开销非常低，如果一台虚拟机的操作系统需要占用2G的内存，则7个虚拟机所组成的集群只是操作系统就需要14G的内存占用。基于容器的技术如果一台16G的裸机除去2G的操作系统开销，还能够部署7个容器进程。所以，从经济性来说，容器的技术远远好于虚拟机。另外一个比较的标准是性能，容器的性能相对而言更好一些，具体的比较参数可以参见IBM研究院刚刚出的报告【1】。但是，从安全性和隔离型来说，虚拟机是远远好于容器的。
CloudFoundry的架构设计如下图所示。首先，CF也提供了一个路由模块(Router)，该模块基本是基于ngnix打造，只是在ngnix技术上提供了动态注册的功能。在部署时，由于CF会同时部署非常多的应用实例，所以需要一个router集群来满足应用的需要；其次，CF的应用容器基于自己开发的warden技术，warden也是基于LXC技术，但是使用c和ruby作了一层简单的封装。Docker的大热让CloudFoundry很纠结；第三，CF使用service broker来集成各种资源服务，如mongo、mysql、rabbitmq和redis等。最后，CF使用消息总线NATS/GNATS来完成应用之间的通讯。
其他基于容器的PaaS平台（如Heroku、OpenShift、DotCloud）的平台架构和上面所描述的模式基本一致，我在附件中提供了若干链接，大家如果有兴趣可以仔细研究。
三、PaaS的参考架构模式
根据上面讨论的两种架构模式，我们可以看到PaaS平台的实现基本需要如下的构件： 
PaaS平台参考架构
路由模块：该模块的基本功能是将终端用户请求路由到对应的服务器实例，并提供应用动态注册等功能。目前绝大多数的实现是基于ngnix，同时也需要使用简单的lua脚本完成应用注册和路由查询等基本功能；
服务管理模块：该模块会为开发人员和运维人员提供管理接口，其基本功能包括创建应用实例、配置应用运行参数、启停应用、发布应用程序、扩容或缩容等。服务管理模块也需要提供相应的客户端被用户使用，如命令行或是用户界面等；
应用容器模块：应用容器是PaaS平台的核心，其主要功能是管理应用实例的生命周期，汇报应用的运行状态等。目前来看，应用容器可以基于虚拟机来实现(如AWS)，也可以使用Linux容器技术来实现，最早使用的是LXC，CloudFoundry使用的是自己的warden，同样也是基于cgroup，现在最新的是docker；
应用部署模块：应用部署模块需要将应用程序打包成为可直接部署的发布包。该模块是实现PaaS平台开发性的关键。由于现有通用的PaaS平台需要支持多种编程语言和框架，如Java, Python, Ruby和PHP等，当应用发布时，PaaS平台需要根据不同的编程语言将应用打包成为通用的发布包，然后传递给容器模块部署。应用部署模块是实现这一过程的关键，目前来看起源于Heroku的buildpack已经被大家广发接受；
块存储模块：该模块主要用于存储应用的发布包，需要保证程序包的长久存储和。目前AWS的Beanstalk直接使用S3，CF可以使用网络文件系统NFS或是其他任何分布式文件存储系统（如HBase）；
数据存储模块：该模块需要保存应用和服务的基本信息，可以基于任何现有的数据库技术实现，如MYSQL或是MONGODB等；
监控模块：该模块的作用是持续监控应用的运行状态，比如健康状态（是否存活）、资源使用率（CPU、内存、硬盘、网络等）和可用性等。这些指标会成为整个PaaS平台运维的关键，也为自动弹性伸缩奠定基础；
用户认证模块：该模块需要保证应用程序的安全性和隔离性，通常而言，公有云的提供商会使用OAuth等技术集成现有的用户认证服务；
消息总线模块：该模块也是最重要的模块，由于PaaS平台所搭建的是一个大规模分布式环境，通常而言，规模在数百台到上千台的机器数量，所有模块之间的通讯会变成一个核心的问题。所以消息总线会变成系统之间通讯的基础，通常需要支持pub/sub模式。
基于该架构，应用实例的弹性伸缩也能够非常容易的实现。首先需要监控服务来不断获取实时的应用状态，当某些指标超出预先定义的阈值时，平台会启动伸缩服务，首先从应用容器模块预留资源，然后调用应用部署模块打包应用并部署，最后将应用节点注册到路由模块完成整个伸缩的过程。
四、PaaS未来发展的趋势
PaaS通过开放性的设计，能够支持多种不同的编程语言、技术框架和服务，从而为应用开发人员提供了广泛的选择，能够大大提供开发人员的效率。同时，PaaS也从运维层面为企业提供了强大的支持，将以前很难实现的技术场景（如应用弹性伸缩等）转化为可能。最后，基于容器技术实现的PaaS平台也带来了经济性的优势。所以，相比于现有纯资源型的IaaS平台，PaaS确实将云计算平台提升到一个新的高度，距离应用开发更近了一步。