Java开发者PaaS指南

作者 Michael Yuan 译者 丁雪丰 发布于 2012年1月16日

领域

运维 & 基础架构,

架构 & 设计,

语言 & 开发

主题

Java EE ,

Java ,

语言 ,

PaaS ,

编程 ,

云计算

分享到

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

相关厂商内容

保持某些系统的高可用性，是一些企业的重中之重，如何设计？

海量数据处理，海量视频分发，架构热点难点，尽在架构师峰会！

相关赞助商

ArchSummit全球架构师峰会报名启动！7折优惠，5月31日截止！

JVM、应用服务器和部署包（例如，WAR和EAR）为Java应用程序提供了天然的隔离，允许不同开发者在同一套基础设施中部署应用程序，因此Java平台十分适合PaaS。但是，过去几年里，大多数PaaS产品都围绕着Ruby和Python这样的平台，当时Google App Engine是唯一为Java开发者提供PaaS服务的。幸运的是，现在的情况已经大为改善了。

差不多从去年开始，多家商业服务商进入了Java PaaS领域。这一举动很有意义，因为Java开发者差不多有1000万之多，也许是世界上最大的开发者群体之一。本文中，我们将从开发者的角度来比较这些服务提供商。特别要说明一下，具体比较以下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 （AS）是最流行的Java应用服务器之一，OpenShift服务提供了全面的JBoss AS支持。

支持的技术平台和技术栈

Java PaaS提供商最重要的属性之一就是它所支持的技术平台和技术栈。总而言之，技术平台是Java PaaS区别于其他PaaS产品的地方。在Java平台的长期进化中，涌现了很多颇有竞争力的技术栈。对于Java PaaS厂商而言，我相信尽可能多地支持不同技术栈是十分重要的。

这方面OpenShift和CloudBees对技术的支持面最广，从简单的Servlet容器（一般是Tomcat）到完整的Java EE 6 Web Profile（JBoss AS 7）都有支持。Java PaaS先驱，Google App Engine，在标准支持方面与后来者的差距最大。Google App Engine不支持完整的Java SE平台，因此对很多流行框架的支持都很差。它还要求用户使用Google App Engine自己的网络和持久化API，而不是支持公开标准，这让应用程序很难迁移。类似的，Heroku for Java要求应用程序围绕它自己的Jetty实例做封装，打破了传统Java EE应用程序的部署模型。

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

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

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

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

Amazon Beanstalk、OpenShift和Google App Engine都提供了开发工具、SDK和IDE插件，与其他市面上的基于Java的工具保持一致。

相比Java开发者，Cloud Foundry和Heroku for Java提供了更适合Ruby开发者的工具。试用了这些工具后，我怀疑很多Java开发者可能要花一些时间来适应其中的惯例和术语。另外，Cloud Foundry目前还缺乏文档，举个例子，它的很多文档还是视频教程形式的。虽然视频教程很容易让开发者上手，但在部署重要应用或希望了解视频场景之外的内容时，这些内容显然缺乏深度。尽管Cloud Foundry平台在最近几年里经历了重大变更，但官方入门指南文档的日期还停留在2007年。目前已经有了更多的文档——比如 这篇 ，但它们不该这么难找。

另一个重要的问题，Cloud Foundry允许开发者配置自己的云环境，部署Micro Cloud可比仅仅安装一套SDK麻烦多了。这也是一个障碍，让很多开发者对Cloud Foundry望而却步。

性能和可伸缩性

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

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

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

• 配置负载均衡器支持“粘性会话”（sticky session），负载均衡器会检查所有流入请求的会话ID，总是把同一会话的请求发给相同的服务器。这是最简单的方法，不过也有自己的问题：负载均衡器需要完成更多的工作，久而久之负载分发会变得不再均衡，而且在负载下降时，很难撤下扩上去的基础设施，因为每台服务器都有自己的会话。出于这些原因，很少有PaaS提供商支持这一方法。
• 为内存中的HTTP会话配置一个共享的缓存。如此一来，每时每刻所有服务器都能在内存里拥有全部HTTP会话。但是，在集群中复制内存会话这项任务既耗费带宽，又消耗计算资源。它要求应用程序开发者配置共享缓存和复制策略。
• 还可以配置应用程序，将所有HTTP会话持久化到外部关系型数据库中。

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

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

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

价格及其他商业考量

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

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

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

下一步

文中我们讨论了Java PaaS领域的6个知名厂商，当然，现在还有一些稍小的或不那么有名的提供商，比如：

• Jelastic：它支持很多应用服务器和数据库的组合，包括MySQL数据库的多个变种和NoSQL数据库。
• WSO2 StratosLive：它是构建于WSO2应用服务器上的PaaS产品，WSO2是一款符合Java EE规范的应用服务器。
• CumuLogic：它提供的Java 应用服务PaaS可以运行于很多私有云和公有云解决方案上，包含CloudStack、 OpenStack和Eucalyptus。

我们会密切注意这些小厂商，因为它们很轻松地就能成长起来挑战大厂商的市场份额和关注度。

Java PaaS在过去的12个月里经历了很多，各种产品仍在快速发展，这对那些寻找低价、可伸缩、甚至是免费托管解决方案的Java开发者来说是个天大的好消息。对Java EE开发者而言，我相信CloudBes和OpenShift是目前市面上最好的产品，考虑到OpenShift仍处在Beta阶段，所以CloudBees成为了这场比赛的赢家。如果你愿意尝试一下Java专业户以外的选择，Heroku for Java和Cloud Foundry（Beta）是老牌Google App Engine的有力竞争对手。

关于作者

Michael Yuan博士是名创业者、作家及Java狂热份子。他在软件工程方面出版了5部图书，发表了40多篇文章，还向JBoss和Mozilla这样的知名开源软件提交代码。他最近成立的创业公司是Ringful Health，致力于使用移动技术和预测分析技术让病人更好地融入医疗团队并改善医疗效果。Ringful Health的Java服务器部署在Google App Engine for Java、Amazon EC2和CloudBees上。

查看英文原文： A Java Developer’s Guide to PaaS

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。

1. 返回顶部

   在GFW下，哪个能坚持到最后？

   发表人 孙 巍

   谷歌的PAAS平台已经证明不适合在中国这个神奇的土壤了。不知道别动平台后果如何

   回复

2. 返回顶部

   Re: 在GFW下，哪个能坚持到最后？

   发表人 Gou Dingyong

   也许是 Cloud Foundry吧，自己拿过来搭建一个私有云，呵呵。

   回复