Java开发者PaaS指南.docx
- 文档编号:15128285
- 上传时间:2023-07-01
- 格式:DOCX
- 页数:11
- 大小:22.39KB
Java开发者PaaS指南.docx
《Java开发者PaaS指南.docx》由会员分享,可在线阅读,更多相关《Java开发者PaaS指南.docx(11页珍藏版)》请在冰点文库上搜索。
Java开发者PaaS指南
Java开发者PaaS指南
您的评价:
收藏该经验
PaaS(Platform-as-a-Service)是云服务的一种,服务提供商不仅提供按需索取的硬件和操作系统服务,还提供了应用程序平台和解决方案栈。
对开发者而言,PaaS极大程度上减少了IT部署的开销和痛苦,按需为应用程序提供资源,让其更易伸缩。
JVM、应用服务器和部署包(例如,WAR和EAR)为Java应用程序提供了天然的隔离,允许不同开发者在同一套基础设施中部署应用程序,因此Java平台十分适合PaaS。
但是,过去几年里,大多数PaaS产品都围绕着Ruby和Python这样的平台,当时GoogleAppEngine是唯一为Java开发者提供PaaS服务的。
幸运的是,现在的情况已经大为改善了。
差不多从去年开始,多家商业服务商进入了JavaPaaS领域。
这一举动很有意义,因为Java开发者差不多有1000万之多,也许是世界上最大的开发者群体之一。
本文中,我们将从开发者的角度来比较这些服务提供商。
特别要说明一下,具体比较以下4个方面:
∙对技术平台和技术栈的支持。
∙对开发者生产力和开发过程的支持。
∙性能和可伸缩性。
∙价格和其他商业考量。
文中我们会比较以下JavaPaaS产品(按字母排序)。
∙AmazonElasticBeanstalk是Amazon构建于EC2云上的JavaPaaS产品。
其中提供了运行于EC2上的受管Tomcat实例,带有负载均衡器,还可按需提供伸缩能力。
AmazonElasticBeanstalk集成了AmazonWebServices的其他服务,能访问受管关系型数据库(RDS)、大数据存储(SimpleDB)、消息队列、电子邮件和其他服务。
∙CloudBees 是一家风投的创业公司,成员由JBoss和Sun的前雇员组成,最近在两轮融资中共募得1400万美元。
CloudBees也许是个新名字,不过它在这个领域中的影响力正在不断扩大,为JavaPaaS带来了多项独特的特性,尤其是持续集成——一个完整的云端开发/部署周期管理。
此外,和Heroku一样,它还包含一个第三方插件和服务的市场。
∙CloudFoundry 是VMware发起的一个开源产品。
VMware软件驱动着虚拟化数据中心,这是大多数PaaS产品的基础。
VMware还是SpringFramework的拥有者,它是在企业Java中非常流行的一个平台栈。
CloudFoundry的一个独一无二的特性是它根本无需成为受托管的PaaS,你可以下载其代码,自己托管PaaS!
这样一来,它既是一个托管平台,也是一个受托管PaaS服务。
∙GoogleAppEngineforJava 也许是市面上问世时间最长(也是最成熟)的JavaPaaS产品。
它的目标是提供线性伸缩性,而且不担心对Java平台本身做出巨大变化。
∙HerokuforJava 是PaaS大厂Heroku最近才推出的产品,Heroku在Ruby社区颇受欢迎。
∙RedHatOpenShift 是RedHat试水PaaS的实验性产品。
RedHat的JBossApplicationServer(AS)是最流行的Java应用服务器之一,OpenShift服务提供了全面的JBossAS支持。
支持的技术平台和技术栈JavaPaaS提供商最重要的属性之一就是它所支持的技术平台和技术栈。
总而言之,技术平台是JavaPaaS区别于其他PaaS产品的地方。
在Java平台的长期进化中,涌现了很多颇有竞争力的技术栈。
对于JavaPaaS厂商而言,我相信尽可能多地支持不同技术栈是十分重要的。
这方面OpenShift和CloudBees对技术的支持面最广,从简单的Servlet容器(一般是Tomcat)到完整的JavaEE6WebProfile(JBossAS7)都有支持。
JavaPaaS先驱,GoogleAppEngine,在标准支持方面与后来者的差距最大。
GoogleAppEngine不支持完整的JavaSE平台,因此对很多流行框架的支持都很差。
它还要求用户使用GoogleAppEngine自己的网络和持久化API,而不是支持公开标准,这让应用程序很难迁移。
类似的,HerokuforJava要求应用程序围绕它自己的Jetty实例做封装,打破了传统JavaEE应用程序的部署模型。
CloudFoundry项目支持Tomcat容器,但它的应用程序开发和部署针对SpringFramework做了大量优化,创建了一个半外置的依赖。
因为VMware拥有SpringFramework,所以CloudFoundry很适合基于Spring的应用程序。
此外,它还支持使用RabbitMQ 的消息队列,这是基于 AMQP 标准的。
但它对其他Java框架(例如JavaEE)的支持很弱。
AmazonBeanstalk
CloudBees
CloudFoundry
GoogleAppEngine
HerokuforJava
OpenShift
Tomcat
是
是
是
否
否
是
JavaSE
是
是
是
否
是
是
JavaEE
否
是
否
否
否
是
支持标准Java库
是
是
是
否
是
是
文件系统访问
是
是
是
否
是
是
线程访问
是
是
是
否
是
是
对外网络连接
是
是
是
受限
是
是
MySQL
RDS
是
是
付费方案
是
是
商业关系型数据库
RDS
外置
外置
否
外置
外置
BigData支持
SimpleDB
外置
外置
BigTable
外置
外置
部署时无需特殊框架
是
是
否
否
是
是
方便迁移现有应用
是
是
否
否
否
是
应用可移植性
高
高
中
低
低
高
可用于生产环境
是
是
Beta阶段
是
Beta阶段
Beta阶段
对开发者生产力和开发过程的支持PaaS的关键价值之一,是让应用程序开发者的生活更简单,因为它消除了应用程序和资源管理的开销。
所以说,对开发者友好,有工具集成是我们的一个重要考量点。
在这方面CloudBees无疑是赢家。
它不仅是一个PaaS运行时环境,还是一个完整的构建和测试环境。
开发者可以利用Jenkins服务让CloudBees自动并持续地签出、构建、测试并报告代码库中的代码。
这个持续集成过程已经被运用于多个大型团队,作为他们软件开发过程的重要环节。
但是,构建服务器管理对QA团队而言是一项费时费力的工作。
CloudBees替QA团队承担了这份痛苦,让这一过程对开发者更加透明。
最近,RedHatOpenShift通过支持Maven和Jekins集成,在这个领域里慢慢追上CloudBees了。
AmazonBeanstalk、OpenShift和GoogleAppEngine都提供了开发工具、SDK和IDE插件,与其他市面上的基于Java的工具保持一致。
相比Java开发者,CloudFoundry和HerokuforJava提供了更适合Ruby开发者的工具。
试用了这些工具后,我怀疑很多Java开发者可能要花一些时间来适应其中的惯例和术语。
另外,CloudFoundry目前还缺乏文档,举个例子,它的很多文档还是视频教程形式的。
虽然视频教程很容易让开发者上手,但在部署重要应用或希望了解视频场景之外的内容时,这些内容显然缺乏深度。
尽管CloudFoundry平台在最近几年里经历了重大变更,但官方入门指南文档的日期还停留在2007年。
目前已经有了更多的文档——比如 这篇 ,但它们不该这么难找。
另一个重要的问题,CloudFoundry允许开发者配置自己的云环境,部署MicroCloud可比仅仅安装一套SDK麻烦多了。
这也是一个障碍,让很多开发者对CloudFoundry望而却步。
AmazonBeanstalk
CloudBees
CloudFoundry
GoogleAppEngine
HerokuforJava
OpenShift
IDE工具
是
是
是
是
否
是
命令行工具
是
是
是
是
是
是
基于Web的控制台
是
是
否
是
否
是
开发机上进行测试
简单
简单
困难
困难
是
简单
构件时无非标准依赖
是
是
否
否
否
是
源码控制集成
否
是
是
否
否
部分
集成构建
否
是
否
否
否
是
集成测试
否
是
否
否
否
否
通过Web访问日志
否
是
是
是
是
是
第三方开发者/测试服务
否
是
否
否
否
否
API访问
是
是
否
否
是
否
文档
好
好
差
好
好
好
性能和可伸缩性PaaS最重要的特性之一是平台自动伸缩的能力,就是基于实时流量需求增加或减少服务器容量。
这要求平台提供商在众多服务器之间对请求做负载均衡,监控各台服务器的负载,适时启动新服务器。
所有PaaS提供商都在一定程度上支持自动伸缩。
但自动扩展远比看上去困难。
对入门用户而言,JavaEE应用程序必须被配置为访问中心化外部数据库,而不是访问部署在同一台服务器上的数据库。
所有PaaS提供商的编程范式和工具都要强制开发者遵循这种方式。
更大的问题是HTTP会话。
在Java应用服务器上,HTTP会话的会话状态默认是在内存里管理的。
要构建能在不同服务器之间负载均衡的应用程序,开发者必须使用以下的某个方法:
∙配置负载均衡器支持“粘性会话”(stickysession),负载均衡器会检查所有流入请求的会话ID,总是把同一会话的请求发给相同的服务器。
这是最简单的方法,不过也有自己的问题:
负载均衡器需要完成更多的工作,久而久之负载分发会变得不再均衡,而且在负载下降时,很难撤下扩上去的基础设施,因为每台服务器都有自己的会话。
出于这些原因,很少有PaaS提供商支持这一方法。
∙为内存中的HTTP会话配置一个共享的缓存。
如此一来,每时每刻所有服务器都能在内存里拥有全部HTTP会话。
但是,在集群中复制内存会话这项任务既耗费带宽,又消耗计算资源。
它要求应用程序开发者配置共享缓存和复制策略。
∙还可以配置应用程序,将所有HTTP会话持久化到外部关系型数据库中。
上述所有的PaaS平台中,GoogleAppEngine对这一问题的处理是最好的。
它在架构上就将单一服务器的概念抽象了出来,会自动在不同的服务器上创建数据存储,并默认将HTTP会话保存到数据存储中,这一过程对开发者是透明的。
但是,GoogleAppEngine的问题是原生的性能太差,一个Web请求要花1至3秒才能完成一次对数据库的访问。
HerokuforJava的每个服务器实例都封装了一个自定义的Jetty实例,因此它也提供了跨服务器实例自动共享会话的能力。
然而,Heroku并不提供透明的自动伸缩,你需要观察仪表盘,适时为应用添加资源。
剩余的标准JavaPaaS产品都强制要求开发者在专门的数据库服务器上创建数据表,这也是部署过程的一部分。
对于HTTP会话,CloudFoundry在负载均衡器中使用了粘性会话。
正如上文讨论的那样,这种做法为开发者带来了便利,也有
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Java 开发者 PaaS 指南