4        云端平台

图40-01：实现云端的优势

       从云计算的三层服务模型（IaaS、PaaS、SaaS）上来讲，PaaS是最难实现的。IaaS主要技术是虚拟化，目前已经相对较成熟，代表产品当属Amazon的EC2啦。SaaS主要难点在于多租户和Web呈现技术，相对来说还算简单，著名的有Salesforce.org等。而PaaS平台，涉及分布式技术、资源隔离、资源管理与调度等，是最复杂的。

4.1 背景介绍

Paas将应用运行所需的 IT 资源和基础设施以服务的方式提供给用户，包括了中间件服务，信息服务，连通性服务，整合服务和消息服务等多种服务形式。为实现平台服务，业界提出了 “平台即服务（Platform as a Services，以下简称 PaaS）”的交付模式。PaaS 模式，基于互联网提供对应用完整生命周期（包括设计、开发、测试和部署等阶段）的支持，减少了用户在购置和管理应用生命周期内所必须的软硬件以及部署应用和 IT 基础设施的成本，同时简化了以上工作的复杂度。为了确保高效地交付具备较强灵活性的平台服务，在 PaaS 模式中，平台服务通常基于自动化的技术通过虚拟化的形式交付，在运行时，自动化，自优化等技术也将被广泛应用，以确保实时动态地满足应用生命周期内的各种功能和非功能需求。

4.2 PaaS介绍

       PaaS（Platform-as-a-Service）是云服务的一种，服务提供商不仅提供按需索取的硬件和操作系统服务（iaas本质），还提供了应用程序平台和解决方案栈（paas本质）。对开发者而言，PaaS极大程度上减少了IT部署的开销和痛苦，按需为应用程序提供资源，让其更易伸缩（paas特征）。

JVM、应用服务器和部署包（WAR和EAR）为Java应用程序提供了天然的隔离，允许不同开发者在同一套基础设施中部署应用程序，因此Java平台十分适合PaaS。但过去几年里，大多数PaaS产品都围绕着Ruby和Python这样的平台（因为动态语言编程要快于java编程，而且提供的公有云环境大部分是用来支撑中小企业和新兴的互联网应用，强调开发快捷是必然的选项），当时Google App Engine是唯一为Java开发者提供PaaS服务的。从2010/2011年开始，多家商业服务商进入了Java PaaS领域。

以下的内容来自一位专业人士对各个Java PaaS的认识和比较，放在本文中，并不表示我完全同意他的看法，只是从多角度来考察PaaS的能力。这里以开发者的角度来比较这些服务提供商，具体比较以下4个方面：

• 对技术平台和技术栈的支持。

• 对开发者生产力和开发过程的支持。

• 性能和可伸缩性。

• 价格和其他商业考量。

Java Paas的产品（不全，会在后续增补）

• Amazon Elastic Beanstalk 是Amazon构建于EC2云上的Java PaaS产品。其中提供了运行于EC2上的受管Tomcat实例，带有负载均衡器，还可按需提供伸缩能力。Amazon Elastic Beanstalk集成了Amazon Web Services的其他服务，能访问受管关系型数据库(RDS)、大数据存储(SimpleDB)、消息队列、电子邮件和其他服务。

• CloudBees 是一家风投的创业公司，成员由JBoss和Sun的前雇员组成，最近在两轮融资募得1400万美元。CloudBees也许是个新名字，不过它在这个领域中的影响力正在不断扩大，为Java PaaS带来了多项独特的特性，尤其是持续集成一个完整的云端开发/部署周期管理。此外，和Heroku一样，它还包含一个第三方插件和服务的市场。

• Cloud Foundry 是VMware发起的一个开源产品。VMware软件驱动着虚拟化数据中心，这是大多数PaaS产品的基础。VMware还是Spring Framework的拥有者，它是在企业Java中非常流行的一个平台栈。Cloud Foundry的一个独一无二的特性是它根本无需成为受托管的PaaS，你可以下载其代码，自己托管PaaS!这样一来，它既是一个托管平台，也是一个受托管PaaS服务。

• Google App Engine for Java 也许是市面上问世时间最长（也是最成熟）的Java PaaS产品。它的目标是提供线性伸缩性，而且不担心对Java平台本身做出巨大变化。

• Heroku for Java 是PaaS大厂Heroku最近才推出的产品，Heroku在Ruby社区颇受欢迎。

• Red Hat OpenShift 是Red Hat试水PaaS的实验性产品。Red Hat的JBoss Application Server是最流行的Java应用服务器之一，OpenShift服务提供了全面的JBoss AS支持。

4.2.1            技术支撑

       Java PaaS提供商最重要的属性之一：就是它所支持的技术平台和技术栈。

• 这方面OpenShift和CloudBees对技术的支持面最广，从简单的Servlet容器(一般是Tomcat)到完整的Java EE 6 Web Profile（JBoss AS 7）都有支持。

• Google App Engine不支持完整的Java SE平台，因此对很多流行框架的支持都很差，它还要求用户使用自己的网络和持久化API，而不是支持公开标准，让应用程序很难迁移。

• Heroku for Java要求应用程序围绕它自己的Jetty实例做封装，打破了传统Java EE应用程序的部署模型。

• Cloud Foundry项目支持Tomcat容器，但它的应用程序开发和部署针对Spring Framework做了大量优化，创建了一个半外置的依赖。因为VMware拥有Spring Framework，所以Cloud Foundry很适合基于Spring的应用程序。此外，它还支持使用RabbitMQ 的消息队列，这是基于 AMQP 标准的。但它对其他Java框架（例如Java EE）的支持很弱。

4.2.2            开发支持

       PaaS的关键价值之一：是让应用程序开发者的生活更简单，因为它消除了应用程序和资源管理的开销。所以说，对开发者友好，有工具集成是我们的一个重要考量点。

　　在这方面CloudBees无疑是赢家。它不仅是一个PaaS运行时环境，还是一个完整的构建和测试环境。开发者可以利用Jenkins服务让CloudBees自动并持续地签出、构建、测试并报告代码库中的代码。这个持续集成过程已经被运用于多个大型团队，作为他们软件开发过程的重要环节。但是，构建服务器管理对QA团队而言是一项费时费力的工作。CloudBees替QA团队承担了这份痛苦，让这一过程对开发者更加透明。最近，Red Hat OpenShift通过支持Maven和Jekins集成，在这个领域里慢慢追上CloudBees了。

　　Amazon Beanstalk、OpenShift和Google App Engine都提供了开发工具、SDK和IDE插件，与其他市面上的基于Java的工具保持一致。（注：Cloud Foundry其实也提供了for eclipse的开发环境：SpringSource Tool Suite/STS。）

4.2.3            性能伸缩

　　PaaS最重要的特性之一：是平台自动伸缩的能力，就是基于实时流量需求增加或减少服务器容量。这要求平台提供商在众多服务器之间对请求做负载均衡，监控各台服务器的负载，适时启动新服务器。

　　所有PaaS提供商都在一定程度上支持自动伸缩。对入门用户而言，Java EE应用程序必须被配置为访问中心化外部数据库，而不是访问部署在同一台服务器上的数据库。所有PaaS提供商的编程范式和工具都要强制开发者遵循这种方式。

　　更大的问题是HTTP会话。在Java应用服务器上，HTTP会话的会话状态默认是在内存里管理的。要构建能在不同服务器之间负载均衡的应用程序，开发者必须使用以下的某个方法：

• 配置负载均衡器支持“粘性会话”(sticky session)，负载均衡器会检查所有流入请求的会话ID，总是把同一会话的请求发给相同的服务器。这是最简单的方法，不过也有自己的问题：负载均衡器需要完成更多的工作，久而久之负载分发会变得不再均衡，而且在负载下降时，很难撤下扩上去的基础设施，因为每台服务器都有自己的会话。出于这些原因，很少有PaaS提供商支持这一方法。

• 为内存中的HTTP会话配置一个共享的缓存。如此一来，每时每刻所有服务器都能在内存里拥有全部HTTP会话。但是，在集群中复制内存会话这项任务既耗费带宽，又消耗计算资源。它要求应用程序开发者配置共享缓存和复制策略。

• 还可以配置应用程序，将所有HTTP会话持久化到外部关系型数据库中。

• 把会话信息存储在客户端（cookie/页面隐含域），淘宝采取的这种策略，切实可行，但好想没有上升到Java PaaS的通用解决方案中。

       Java Paas厂家比较：

• 上述所有的PaaS平台中，Google App Engine对这一问题的处理是最好的。它在架构上就将单一服务器的概念抽象了出来，会自动在不同的服务器上创建数据存储，并默认将HTTP会话保存到数据存储中，这一过程对开发者是透明的。但是，Google App Engine的问题是原生的性能太差，一个Web请求要花1至3秒才能完成一次对数据库的访问。

• Heroku for Java的每个服务器实例都封装了一个自定义的Jetty实例，因此它也提供了跨服务器实例自动共享会话的能力。然而，Heroku并不提供透明的自动伸缩，你需要观察仪表盘，适时为应用添加资源。

• 剩余的标准Java PaaS产品都强制要求开发者在专门的数据库服务器上创建数据表，这也是部署过程的一部分。对于HTTP会话，Cloud Foundry在负载均衡器中使用了粘性会话。正如上文讨论的那样，这种做法为开发者带来了便利，也有一些严重的问题。其他PaaS产品虽然没有明说，但都把会话管理的工作留给了应用程序开发者。

4.2.4            商业考量

　　对开发者而言，PaaS产品的价格是十分重要的。大多数服务提供商都有免费服务供开发者试用，这些免费服务对较小的Java Web站点来说就是很好的选择。

　　但是，正如Google App Engine最近的涨价风波所反映的那样，大型Web应用程序使用PaaS的成本还是很高的。

　　另一个要考虑的重要因素是支持。Google App Engine和Amazon Web Services在支持方面表现糟糕。开发者只能自己在论坛上寻找答案。稍小的专注于Java的提供商提供了更好的技术支持，在公共论坛上亦是如此。在我看来CloudBees提供的支持最为出色，很好地结合了付费问题单的支持和支持人员间的Java专业技术秘诀。

　　Java PaaS在过去的12个月里经历了很多，各种产品仍在快速发展，这对那些寻找低价、可伸缩、甚至是免费托管解决方案的Java开发者来说是个天大的好消息。对Java EE开发者而言，CloudBes和OpenShift是目前市面上最好的产品。

4.2.5            能力小结

       下面用个表格，简单的描述一下3大开源（提供源代码的，非开源的就不再阐述）的paas平台技术特点。每个paas背后的推手都有个在业界名声显赫的公司：

• Cloud foundry是VMWare的手笔，本身在虚拟机方面是首屈一指，再收购spring后，由spring 3.1以上的版本对cloud foundry作了更好的支持，当然VMWare也留了一手，CF是它的开源产品，它自身还有一个VMwarevFabric Cloud Application Platfor的商业产品。

• openshift是redhat的杰作，去年6月份在美盛听过redhat的售前讲解过openshift，如今说开源就开源了，估计是感受到了来自CF的强大压力，有竞争才有动力，有了动力才会有进步，这样程序员就有更多的选择，可有了太多的选择，又有些无所适从，就像当年雨后春笋般的web框架一样，呵呵。虽然VMWare和redhat分别启动了他们的 PaaS 项目，但是 VMWare 似乎赢得了更多的支持，因为 Cloud Foundry 比 OpenShift 积累了更多的伙伴和爱好者，还是早期的鸟儿有虫吃。

• cloudify所在的公司在开源社区中名声没有前面2家公司这么大，是因为它之前从事的是商业高端的应用服务器，在cloud高歌猛进的岁月里，终究也按捺不住涉足于paas系统，自然也开源并提供源代码，当然，提供下载的是社区版本，一些高级特性是属于商业版本，并没有提供源代码下载。后续的表格对比中，说明的是包含商业版本的能力。

       下面是这3大开源paas的源代码地址，后续章节也就根据自己的认识和体会，稍微阐述一下这3大paas的特点：

语言

表 42-1： 语言差异

关系数据库

表42-2：数据库支持

NoSQL

表42-3：nosql支持

其他

表 42-4：其他

       从这几张表格的数据比较，cloudify除了语言方面支持的力度比其他2个开源的paas稍逊，但在java语言，java应用服务器，以及在数据库，nosql数据库，其他互联网应用都比其他2个paas平台支撑的好。

       对于PaaS的阐述，前面是蜻蜓点水，做个略为了解，本章节的后续篇幅，将重点分析几个开源的PaaS系统，也就是针对之前对比的cloud foundry；openshift；cloudify，同时也阐述了我们部门正在作的PaaS：Talkyun-应用引擎。

       分析这些PaaS平台的目的是为了更好的了解PaaS。之前对PaaS的认识存在误区：有的认为PaaS云平台包罗万象，能彻底解决分布式，大规模，高并发的问题，是大型网站的一揽子解决方案；也有的认为PaaS类似esb，无非又是一个噱头和包装而已。银弹乎？卵蛋乎？扯蛋乎？

       但到底是什么，PaaS能提供什么功能，在此基础上，软件如何开发，系统如何架构，模块如何部署，我尝试用一种新的方式来阐述和说明，理解和把握现有业界开源的PaaS，并搭建其环境，了解其运行机理，再尝试用DIY的方式，用头脑风暴快速模拟搭建不同能力层次的paas平台，从而深入了解PaaS平台。用一句通俗的语句说就是：先看看猪的样子；然后让猪跑跑，哼哼，更深层次的了解猪的习气；最后可以自己养猪了，养肥后就可以享用了。

来源：timeson http://timeson.iteye.com/blog