JAVA开发者PAAS指南.docx

java开发者paas指南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的应用程序。此外，它还支持使用rabbitmq的消息队列，这是基于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阶段 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支持问题单 论坛 电子邮件和电话 论坛 支持质量 差 好 好 差 一般 好 下一步文中我们讨论了