Java开发者PaaS指南-InfoQ

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

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 的应用程序。此外，它还支持使用 Rabbit MQ 的消息队列，这是基于 AMQP 标准的。但它对其他 Java 框架（例如 Java EE）的支持很弱。

Amazon Beanstalk

CloudBees

Cloud Foundry

Google App Engine

Heroku for Java

OpenShift

Tomcat

是

否

是

Java SE

是

否

是

Java EE

否

是

否

是

支持标准 Java 库

是

否

是

文件系统访问

是

否

是

线程访问

是

否

是

对外网络连接

是

受限

是

MySQL

RDS

是

付费方案

是

商业关系型数据库

RDS

外置

否

外置

Big Data 支持

SimpleDB

外置

BigTable

外置

部署时无需特殊框架

是

否

是

方便迁移现有应用

是

否

是

应用可移植性

高

中

低

高

可用于生产环境

是

Beta 阶段

是

Beta 阶段

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

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 望而却步。

Amazon Beanstalk

CloudBees

Cloud Foundry

Google App Engine

Heroku for Java

OpenShift

IDE 工具

是

否

是

命令行工具

是

基于 Web 的控制台

是

否

是

否

是

开发机上进行测试

简单

困难

是

简单

构件时无非标准依赖

是

否

是

源码控制集成

否

是

否

部分

集成构建

否

是

否

是

集成测试

否

是

否

通过 Web 访问日志

否

是

第三方开发者 / 测试服务

否

是

否

API 访问

是

否

是

否

文档

好

差

好

性能和可伸缩性

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 产品虽然没有明说，但都把会话管理的工作留给了应用程序开发者。

Amazon Beanstalk

CloudBees

Cloud Foundry

Google App Engine

Heroku for Java

OpenShift

内建负载均衡器

是

负载均衡器自定义域名

是

否

Google Apps

是

自动伸缩应用服务器

是

计划支持

是

否

是

自动伸缩数据库

否

是

否

用户定义性能标准

是

计划支持

否

是

基于 Web 的监控仪表盘

是

计划支持

是

集群 HTTP 会话

手工

自动

手工

价格及其他商业考量

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

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

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

Amazon Beanstalk

CloudBees

Cloud Foundry

Google App Engine

Heroku for Java

OpenShift

是否有免费服务

是

N/A

是

免费

低流量入门级 Web 应用成本

高

免费

跨云提供商

否

计划支持

否

计划支持

私有云

否

Beta 阶段（OpenStack 或 vSphere）

是

否

计划支持

支持

论坛

电子邮件和电话

论坛 / Web 支持问题单

论坛

电子邮件和电话

论坛

支持质量

差

好

差

一般

好

下一步

文中我们讨论了 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 上。