PaaS是一种云服务类型，其中供应商不但提供按需硬件和操作系统服务，而且还提供应用程序平台和解决方案堆栈。PaaS服务可将与应用程序部署关联的大多数IT管理方面自动化，包括资源配置、分段和测试、负载平衡、数据库访问以及访问平台库。PaaS的关键功能是多组织体系结构：即多个不相关的应用程序可运行在相同的硬件和软件基础设施上，从而节约成本以及更有效地利用计算资源。开发人员只需关注应用程序本身，而不需要关注部署和IT问题。

　　Java开发人员能够很好地了解并利用PaaS的开发模型。毕竟，在早期服务器端Java中，PaaS的概念就已经深深地植入了。当时，IT 组织出售使用应用程序服务器作为 “容器” 的远景，然后再将其放入应用程序存档文件中以便在共享资源环境中运行。这一远景与我们今天所看到的PaaS服务非常相似。

　　但是Java企业应用程序的早期PaaS远景没有成功。Java应用程序服务器从来没有稳定到可以随意地部署和取消部署多个不相关的应用程序。存档结构最后将开销添加到 Java应用程序开发周期中：鉴于Rails上的PHP和Ruby，开发人员可以更改某行代码并重新加载浏览器以便查看不同，然而Java开发人员必须重新编译，重新包装并重新部署其应用程序，并经常重新启动应用程序服务器。

　　事实证明，PaaS远景仅随着远比JVM先进的新一代虚拟化技术而实现。随着Google App Engine的开创，新一代Java PaaS服务履行了Java EE的旧承诺。同时它们提供随您需求成长的按需支付的IT基础设施而无需您在昂贵的硬件和系统管理功能上投入太多。

　　在本文中，我将会研究三个主要的Java公开PaaS产品以便比较它们的方法、优点和缺点。这三种都提供同一套功能，包括：

• 上传并部署应用程序WAR
• 版本控制已部署的应用程序
• 测试并分段环境
• 在线访问日志文件
• 自动监控和使用报告

　　然而除了那些共同的功能以外就是一些重要的区别。鉴于我自己使用这些新兴技术的经验，我将为比较它们提供框架并讨论潜在的解决方法以便在您使用它们时帮助您避免问题。

　　Google App Engine

　　Google App Engine (GAE) 是第一个被广泛采用Java PaaS平台。（Java版本有时被称为GAE/J，以便将其与基于GAE Python的PaaS产品中区分开来。）它也可能是市场上“最纯净”的PaaS产品—在这个意义上它几乎完全为开发人员抽象化了底层基础架构。

　　Java，但并不完全是Java

　　从2009年开始，GAE就已经支持Java平台作为开发和部署环境。然而，GAE的Java支持是有限的且不符合标准。由于它在其应用程序上强加诸多限制—它们中的许多都有充分的理由来维持可伸缩性—GAE不支持某些Java平台API：最明显的是，文件写入I/O（因为GAE不对应用程序提供文件系统访问）和许多网络I/O API（因为GAE在源于应用程序的网络操作上施加了严格的限制）。

　　通过支持其自己的有限网络I/O API，GAE限制了应用程序连接到其他服务的能力。GAE名义上允许应用程序出站连接其他服务器。但为了在可控的系统中保持线程数，GAE会强迫任何应用程序发起的连接在5到10秒后关闭。这使GAE成为不可靠混合类型应用程序平台。对于越来越多的使用第三方web服务API的应用程序来说，这就是GAE的主要限制。

　　此外，在您需要使用现有应用程序框架或将现有应用程序移动到GAE时，这些API限制构成了挑战。经过多年的演化，企业Java开发在很大程度上依赖于框架。虽然在GAE上一些流行的框架（如Spring和Struts）都是开箱即用的，但是其他一些要么不工作要么需要对其源代码打补丁。因为您基本上是正在创建一个打破上游兼容性的分支，所以手动获取框架源代码以便使其在GAE上运行永远都不是一个好主意，且其可能将难于调试的错误引入框架。一个好的示例是JavaServer Faces (JSF) web框架：其需要源代码级获取以便在GAE环境中运行，即使如此在JSF顶端的许多UI库都兼容GAE。

　　同样地，已经开发的大型企业应用程序可能使用GAE禁止的API。将这些应用程序迁移到GAE可能是昂贵的，因为您不仅需要识别问题并创建解决方法，而且还要从头再为整个应用程序做质量保证。

　　如果不支持Java平台API的一部分，那么GAE将不能履行Java关于“编写一次，随处可用”的承诺。虽然这对于许多人来说并不是致命的弱点，但这是潜在用户需要意识到的。

　　可伸缩性和性能

　　GAE承诺并传递可伸缩性，但不一定是原始性能。Web应用程序的原始性能是通过对web请求的响应时间来衡量的。可伸缩性是指无论多少用户正在访问系统，平台都能保持一致响应时间的能力。例如，3秒钟对100个并发用户作出响应的可伸缩的系统应该也可以3秒钟对100万并发用户作出响应。

　　GAE提供出色的可伸缩性就像通过一致响应时间所衡量的那样。但是其原始性能通常是缓慢的。以我的经验，GAE常常用1到3秒对数据库相关请求作出响应。

　　该特点对应用程序开发人员有明显影响。对于在大部分时间里空闲的web应用程序来说（即大多数小型web应用程序），在GAE基础设施上进行部署不会产生性能优势，即使是在低端虚拟专用服务器上。在您需要扩展应用程序远远超越低端服务器硬件容量时，真正的性能优势才会到来。

　　低流量网站的另一个问题是GAE将无效（inactive）JVM换出（swap）内存，以便在系统中优化高流量web应用程序。如果您的JVM被换出内存，那么在下一次请求到来时，GAE必须花费更多的时间来启动整个应用程序。对于低流量web应用程序来说，这可能导致缓慢的性能（第一次请求的等待时间超过5秒钟）。为了获得更一致的性能，GAE 为开发人员提供付费的选择让无效的JVM保存在内存中。一个建议：在GAE内建立 cron 作业以便每2到3分钟加载一次您自己的网站，从而保持JVM活跃。

　　BigTable的优点和限制

　　GAE的关键创新就是使用了真正可伸缩的数据存储：即Google BigTable。大多数web应用程序都使用关系数据库作为后端数据。但是关系数据库难于扩展是出了名的。要解决此问题，Google的研究人员开发了一个名为BigTable的替代数据存储解决方案，它是NoSQL数据库世界中的数据存储解决方案之一。

　　正如在关系数据库中那样，BigTable中的数据可以组成具有行和列的表，且每一行都有一个惟一的索引ID。不像关系数据库那样，BigTable表没有固定的模式且通常是非规范化（denormalized）的。表中的每一行可能都有不同的列。相对于通过键列跨不同的表链接不同行，最佳实践将是在一行中有许多列。对于数模型的设计来说这已经产生了重大的影响。为了便于检索应用程序，开发人员被鼓励将冗余信息放入每一行，而不是设计规范化的关系模型。想一想web服务器的访问日志，其中每一行都重复了 IP 地址和浏览器代理，这虽然占用了空间但却简化了批量处理。

　　BigTable的优点是可伸缩性。Google工程师宣称BigTable中数据查询的响应时间只根据结果数据集的大小确定。无论查询是针对1000行的表或者1亿行的表，您都可以获得同样的性能，只要结果被限制为1000行。就其本身而言，GAE将每次查询的返回数据集限定为1000行。

　　调整到NoSQL范例，虽然它可能对来自SQL背景的开发人员来说具有挑战性，但是对于正在面临 “大数据” 挑战的越来越多的IT组织来说，这是一个重要的技能。我发现GAE是Java开发人员开始了解NoSQL的最佳和最容易的地方之一。

　　然而，虽然BigTable对于GAE的强大可伸缩性来说是关键，但是其目前的执行留下了很多有待Java开发人员改进的地方。BigTable的具体缺陷（以及一些潜在的解决方法）包括：

　　微弱的数据查询支持：以Google查询语言（Google Query Language，GQL）编写的查询用于从BigTable检索数据。GAE需要将查询中涉及到的所有数据列编入索引，且该索引不包含BLOB或文本列。这很好，除了GAE只允许每个表100个索引以外。虽然这对于标准 SQL数据库来说可能足够了，但是像 BigTable 那样的非规范化 NoSQL 数据库可能潜在具有数以千计的列，因此 100 个索引可能会限制很多应用程序。更糟的是，GAE 没有提供简单的方式来删除不再使用的索引。

　　决定要创建哪个索引对于GAE开发人员来说是一个很大的负担。如果查询使用没有进行索引的列的组合，那么当执行查询时，GAE将只在运行时出现一个异常。虽然由于您在本地计算机上测试应用程序而导致SDK可为自动生成索引配置文件提供工具，但是如果您没有手动地详尽测试所有执行路径，那么您可能会一直错过索引。将自动生成的索引合并到已经部署的应用程序中也是一个潜在的容易出错的过程，该过程直到web应用程序用户点击错误配置的索引前都没有错误提示。

　　最后，这有点让人震惊 — 考虑到BigTable是Google产品—在数据库中不支持免费的文本搜索。您可以将搜索引擎实现（如Apache Lucene）嵌入您的应用程序，以便索引并搜索文本列。但是对于那些标准SQL LIKE语句就足以进行简单文本搜索的小型网站来说，这就是一个大麻烦。

　　导入和导出数据的难题：BigTable的另一个主要问题是无法导入和导出数据。因为没有直接访问BigTable的标准API，所以在您自己的应用程序内，您必须将数据导入和数据导出逻辑写入servlet，并使用您自己的web界面来导入或导出数据。

　　因为GAE会在30秒以后终止任何web请求线程，所以不可能通过持久连接将大量数据上传到BigTable。常用的解决方法就是将数据导入分成许多块，且每一块都要求上传并处理的时间少于30秒。然后，您可以使用自动HTTP设备，如JMeter或Grinder，以便一个接一个地运行这些任务直到所有数据都被导入。不用说，这将是一个繁琐的过程。

　　从BigTable导出数据更成问题。因为API将每个数据查询限制为1000条结果，所以导出数据必须在比30秒处理超时限制所允许的还要小的块中进行管理。

　　认识到BigTable对于大多数开发人员的局限性，GAE就可以通过其付费业务产品对已托管的MySQL服务提供访问。

　　与其他服务集成

　　GAE提供与其他Google服务的出色集成。值得注意的是，应用程序可与Google Accounts集成在一起，以便用户使用 Google 用户名和密码登录应用程序。鉴于构建用户管理系统是每个网站都必须做的重复工作，所以这可能潜在地为您节约时间。然而，缺点是并非所有的用户都有 Google帐户，且将您的网站与Google帐户捆绑使得更难于移动到另一个PaaS供应商。

　　GAE应用程序也可使用简单API以便通过GMail服务器发送电子邮件。相对于不安全的SMTP服务器，不太可能通过收件人ISP阻塞GMail服务器。

　　如果您在Google Apps上托管您的域，那么通过将Google Apps帐户与GAE帐户链接，您还可以配置通过任何在您控制下的子域访问的应用程序。例如，如果通过Google Apps托管mydomain.com，那么您就可以从www.mydomain.com而不是mydomain.appspot.com访问应用程序。

　　总体评价

　　总体而言，GAE提供了精心设计并可伸缩的PaaS。对于小型网站来说，其慷慨的免费配额也是很吸引人的。然而，缺乏对完整Java平台的支持是一个潜在的致命伤，且 GAE 中的一些组件尚处于试验阶段而不是已经生产就绪。

　　Amazon Elastic Beanstalk

　　Amazon Elastic Beanstalk（来自Amazon Web Services的相对新的产品）提供了基于Amazon Elastic Computing Cloud (EC2)基础设施的受管理的Apache Tomcat运行时环境。EC2是Infrastructure-as-a-Service (IaaS)产品，因此它可以提供比 GAE 更多的灵活性。但是作为权衡，它也需要更多的开发人员努力对应用程序进行管理和扩展。

　　纯Java Tomcat

　　Beanstalk环境支持运行在EC2虚拟服务器上的完全Tomcat服务器。它是一个可访问基础文件系统的纯Java环境。因为Tomcat的声望，所以几乎所有企业Java框架都支持Tomcat部署。这些框架可从Tomcat WAR文件启动或引导，并为您提供广泛的框架和库选择。

　　普通Tomcat运行时对线程以及文件或网络I/O没有限制。只要需要网络I/O线程就可以一直保持打开。您只受限于基础虚拟机的容量。

　　伸缩，价格

　　通过自动启动新的EC2实例并将您的WAR文件部署到新的实例，Beanstalk可以扩展您的应用程序。所有Beanstalk EC2实例都正运行在负载平衡器后面。您可以使用基于web的管理控制台来监控可用于每一个EC2实例上的资源，并设置规则，从而在现有服务器负载超过预设限制时自动启动负载平衡器后面的新服务器实例。

　　负载平衡web集群中常见的问题是如何处理HTTP会话。每一个Tomcat服务器节点都可以为其客户端创建并管理会话对象。如果跨多个服务器节点负载平衡web请求，那么您需要确保服务于请求的服务器节点都有正确的会话对象。实现其的简单办法是在负载平衡器中启用 “粘性会话（sticky session）”，这需要负载平衡器记住通过其后面的每一个服务器保持的会话cookies，并将请求转发到基于传入cookies的正确服务器。可在Beanstalk负载平衡器管理控制台中打开 “粘性会话”。更有效的和防止故障的解决方案包括跨服务器节点建立共享的内存或将会话对象简单保存到中央数据库。因为每一个服务器节点都有相同的对话状态信息，所以这些选项允许负载平衡器将请求转发到随机或最繁忙的服务器节点。但是所有这些选项都需要来自应用程序开发人员的努力。不同于GAE，其自动将会话数据保存到BigTable，Beanstalk需要您做所有的工作。

　　也许Beanstalk最大的缺陷之一就是其价格，尤其是对于可以在其他地方获得免费托管的小型网络。虽然Amazon EC2有一个 “一年免费” 计划提供给新注册的用户，但是Beanstalk的标准价格即使对于单节点安装来说也要接近每个月40美元。这对于需要时在短短几分钟内就可以自动向外扩展的集群就绪的基础设施来说是便宜的价格，但是如果您的应用程序除了偶然的流量激增以外大都处于闲置，那么相对于GAE来说就比较贵了。

　　灵活的数据库选择

　　Elastic Beanstalk平台的优点之一就是在选择数据库技术上的灵活性。其提供以下几个选项：

　　关系数据库：通过Amazon自己的关系数据库服务（Relational Database Service，RDS），您可以部署各种关系数据库。这些数据库服务器都通过Amazon管理并监控，这很容易将数据导入并从中将其导出。在您的应用程序内，所有您需要做的就是将数据源指向RDS服务器。但是请注意每一个RDS实例都是另一个运行数据库的专用服务器实例 — 数据库实例比具有可比性的EC2实例贵30%。成本可以积累，且许多应用程序不需要专用数据库服务器。

　　NoSQL：与 RDS 服务器同样的问题就是它是一个难于扩展的关系数据库。如果您喜欢类似于Google BigTable的NoSQL方法,那么它也可与Amazon SimpleDB一起使用。SimpleDB的Java API可让您的应用程序轻松访问数据。

　　您自己的数据库服务器：因为EC2提供对原始虚拟服务器的访问，所以您可以在独立的EC2实例上建立自己的数据库或NoSQL数据源（如Apache Cassandra）并只将Beanstalk应用程序指向您自己的数据库服务器。

　　数据库选择中的灵活性（尤其是使用Amazon托管关系数据库的能力）很可能吸引企业开发人员。

　　与其他服务集成

　　除了Amazon RDS和SimpleDB，Beanstalk服务器可访问其他Amazon服务，如Simple Queue Service、S3 Storage、Simple Email Service (SES)以及付费API。SES特别有趣并提供了与GAE中的GMail API的很好比较点。

　　SES有一个简单的API，其允许您使用Amazon的SMTP服务器发送电子邮件。相对于在您自己的EC2实例上建立不安全的SMTP服务器来说，使用 Amazon SMTP服务器的优点就是，Amazon服务器不太可能被主要ISP的垃圾邮件过滤器封锁。为此，SES提供了一系列丰富的工具以便控制高速增长的电子邮件数量并接收来自ISP垃圾邮件过滤器的反馈。所有这些功能都被提供给您的Beanstalk应用程序，以便您可以监控您的活动，并为了更有效的交付而优化您的电子邮件内容。

　　总体评价

　　总体而言，Amazon Elastic Beanstalk大大简化了Tomcat应用程序的部署和扩展。然而，它一直提供基本EC2基础设施的灵活性，这使其非常适合企业应用程序。然而，对于低流量网站或业余开发人员来说其成本是很高的。

　　CloudBees RUN@Cloud

　　CloudBees是Java PaaS场景的新参与者。虽然它可能只是一个开始，但是其后面的开发人员都是企业Java的老手。（它由JBoss前CTO Sacha Labourey启动，并聘用了开源Java重量级人物以JBoss闻名的Adrian Brock和以Hudson闻名的Kohsuke Kawaguchi。）其PaaS技术是从Stax Networks收购的，该公司已经对企业客户提供托管Java应用程序服务超过10年。CloudBees RUN@Cloud服务基于健全的Stax平台，并通过自服务web门户提供给单个开发人员。

　　与大公司相比，RUN@Cloud 旨在受管理的可伸缩性（如在GAE中）和灵活性（如在Amazon的PaaS服务中）之间发现正确的平衡，同时通过该平台添加自己的端对端开发生命周期支持。

　　健全的Java运行时

　　RUN@Cloud服务目前基于EC2基础设施，可以将其看做自动化程度更高的Beanstalk + RDS版本。与Beanstalk一样，RUN@Cloud也为每一个web应用程序提供在 EC2 虚拟服务器上运行的专用Tomcat实例。其提供纯Java环境，没有对文件系统访问、网络I/O以及线程的人为限制。

　　作为小型独立公司，RUN@Cloud的优点之一就是无需与Amazon捆绑在一起。在不久的将来，其计划提供其他基础设施供应商以便补充EC2。

　　免费可扩展的基础设施

　　也类似于Beanstalk，RUN@Cloud提供了可扩展的基础设施，将按需启动负载平衡器和服务器实例以满足流量激增。但是RUN@Cloud比Beanstalk提供了更多的自动化。例如，RUN@Cloud已经配置了其Tomcat服务器，以便将会话保存到其管理下的数据库中，而不是使用 “粘性会话”。此托管会话对象数据库对开发人员透明—这很像GAE。

　　因为RUN@Cloud可以使用共享的负载平衡器来管理在单个EC2实例上运行的多个Tomcat服务器，所以其无需每个Tomcat实例都有一个EC2实例。因此它可以用比Beanstalk低的多的成本运行低流量网站。实际上，RUN@Cloud有一个对于低流量应用程序或业余开发人员以及学生来说非常好的免费使用层。

　　然而，也像GAE那样，如果应用程序长时间处于不活动状态，那么RUN@Cloud可以将您的JVM交换出内存。这可能会导致对第一个请求的缓慢响应，就像应用程序在 “预热”。

　　托管的MySQL关系数据库

　　RUN@Cloud服务本身支持与Tomcat服务并列的托管MySQL服务。您可以通过基于web的管理控制台创建并管理数据库。您可以通过MySQL客户端直接连接到数据库服务器以便管理您的数据。

　　不同于Amazon RDS，RUN@Cloud服务跨多个应用程序部署共享数据库服务器。每一个应用程序都有自己的数据库但不一定是专用的服务器。PaaS 平台自动部署数据库以便最大化利用数据库服务器。与RDS相比，共享数据库服务器可能更有效地利用虚拟服务器，从而降低成本。

　　与其他服务集成

　　RUN@Cloud对通过基本基础设施供应商支持的平台API和服务提供访问。特别是对于在Amazon EC2上部署的RUN@Cloud应用程序来说，这些应用程序可以从您的应用程序内完全享有所有的Amazon web服务API — 如S3、SQS以及SES。

　　但是 RUN@Cloud 真正的亮点是其紧密地与 DEV@Cloud（基于云的 Continuous Integration 平台）集成在一起。DEV@Cloud 提供源代码、版本控制系统（Subversion 和 GIT）；一个生成库 (Apache Maven)；以及生成服务器（jenkins，以前称为 Hudson）。其允许您在云中而不是在您自己的计算机上运行应用程序的自动化生成和测试。这种类型的集中生成系统被灵敏软件团队广泛采用，以便确保总是测试库中的源代码且该代码处于可释放状态。

　　通过将RUN@Cloud与DEV@Cloud集成在一起，CloudBees提供了一系列引人注目的PaaS服务，这些服务可以管理企业Java web应用程序的整个开发、测试以及部署周期。您只需在您自己的计算机上编辑源代码，所有一切在云中都可以用最小的IT开销委派给自动化系统。

　　总体评价

　　CloudBees RUN@Cloud是Amazon Elastic Beanstalk和RDS的低成本（甚至免费的）替代品。它集成了连续构建系统，使其可以引起那些希望在开发过程中自动化所有IT功能的敏捷软件开发团队的注意。

　　结束语

　　在经过了多年的失望之后，Java PaaS服务最终达到了黄金时代。在本文中回顾并比较的三种服务中的每一种都有其独特的方法，因此具有独特的优点和缺点。

　　如果您正在开发新的应用程序并可以忍受GAE的限制，那么GAE就是出色且免费的选择。RUN@Cloud和Elastic Beanstalk都是应用程序级的可内部交换的运行时。标准的Java EE应用程序可以在任何平台上运行而不需要进行修改。RUN@Cloud起步更便宜且更易于配置，其为连续集成的开发过程提供出色的支持。我建议用免费的RUN@Cloud起步，因为如果您不愿意使用CloudBees的服务，您可以轻松地转换到Elastic Beanstalk。