写点什么

Java 开发者 PaaS 指南

2012 年 1 月 16 日

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 阶段

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 上。

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


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

2012 年 1 月 16 日 00:009066
用户头像

发布了 135 篇内容, 共 50.7 次阅读, 收获喜欢 30 次。

关注

评论

发布
暂无评论
发现更多内容

每天都要写吗?

Nydia

聊聊「测试分工和测试时间」

清菡

测试

架构师训练营 1 期 -- 第四周总结

曾彪彪

极客大学架构师训练营

极客时间架构师培训 1 期 - 第 4 周作业

Kaven

Week 3命题作业

balsamspear

极客大学架构师训练营

一次用户故事地图之旅

Bruce Talk

敏捷开发 用户故事 Product Owner 用户故事地图

B站真题:如何判断括号是否有效?

王磊

Java 数据结构 算法

迭代开发中的微服务拆分

码猿外

架构 微服务 微服务拆分 架构演进

十六、深入Python字符串

刘润森

Python

架构师训练营第四周学习总结

听夜雨

极客大学架构师训练营

第四周总结

Geek_ac4080

给新入职工程师的10条建议

supernova

管理 职场 工作方式

自学编程,看书还是视频?

沉默王二

程序员 读书 自学编程 视频

week04总结

追风

架构师一期

第四课系统架构课后作业

Geek_michael

极客大学架构师训练营

架构师训练营第四周作业

听夜雨

极客大学架构师训练营

week04作业

追风

架构师一期

架构师训练营第 1 期 - 第四周总结

Todd-Lee

极客大学架构师训练营

WEEK4 学习总结

陈勇

极客大学架构师训练营

Week 3学习总结

balsamspear

极客大学架构师训练营

手把手教你分析Mysql死锁问题

捡田螺的小男孩

MySQL 死锁

用Python绘制地理图

计算机与AI

Python 绘图

Spring 事务,你真的用对了吗(上篇)?

双儿么么哒

Spring MVC

架构师训练营 1 期 -- 第四周作业

曾彪彪

极客大学架构师训练营

会用Docker的人都别装了,这多简单呐

MySQL从删库到跑路

MySQL Docker Linux yum redhat

典型的大型互联网应用方案

garlic

极客大学架构师训练营

十五、深入Python输入和输出

刘润森

Python

视读——沟通的艺术,看入人里,看出人外(第四章)

双儿么么哒

WEEK4 一个典型的大型互联网应用系统使用了哪些技术方案和手段,主要解决什么问题?请列举描述

陈勇

甲方日常 32

句子

随笔杂谈

LeetCode题解:22. 括号生成,递归生成同时过滤,JavaScript,详细注释

Lee Chen

LeetCode 前端进阶训练营

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

Java开发者PaaS指南-InfoQ