写点什么

Java 应用服务器前途堪忧?

  • 2014-05-21
  • 本文字数:2055 字

    阅读完需:约 7 分钟

Java 应用服务器曾经是企业级中间件市场中重要的组成部分,但是随着轻量级微服务理念的发展以及云计算的快速普及,Java 应用服务器正在遭遇前所未有的挑战。近日,来自 adesso AG 技术咨询委员会的 Eberhard Wolff分享了一份 slide ,提出了应用服务器已死的观点,Eberhard 此前曾经在 SpringSource 担任首席技术专家,而 RedHat 的 Mark Little 也在博客上撰文,阐述了未来中间件平台该如何发展。

在 Eberhard Wolff 的 slide 中,首先分析了传统的应用服务器所面临的问题,然后介绍了新的技术发展趋势,如持续交付和微服务,对应用服务器所带来的冲击。在 Eberhard Wolff 看来,传统应用服务器的作用主要包括以下四点:

  • 多个应用的容器;
  • 基础设施;
  • 部署;
  • 监控。

但是,在这四个方面,应用服务器在提供强大支撑功能的同时,也有许多的不足。

具体来讲,如果在服务器中部署多个应用,那么这些应用会通过 ClassLoader 机制实现隔离,但这还是不够的,而且很容易导致难以解决的问题。因为操作系统是以进程为单位进行资源分配的,所以应用服务器无法实现针对应用进行内存、CPU 以及文件系统的隔离。应用之间在运行期还是会互相影响,除非 Java 的虚拟机变成操作系统,否则难以实现完美的隔离。所以,理想的方案是使应用服务器作为单个应用的容器,而不是同时运行多个应用。

在基础设施方面,应用服务器提供了两阶段提交、网络 / 线程以及 API 等功能。不过,作者认为两阶段提交会降低应用的效率,并且不能保证一定会成功。在分布式系统中,应该限制使用,因为会影响到可扩展性。应用服务器一般还会提供网络以及线程的基础设施,支持线程池和连接池,不过这些可以在应用内部来实现。作为基础设施所提供的 API,如 EJB、CDI、JPA 以及 JSF 等,在带来便利的同时,往往会导致与应用服务器的版本关联在一起,应用会依赖于应用服务器,在新的服务器推出之前,我们无法使用新的 API,除此之外,还可能会出现版本的冲突。应用有时还会将其依赖的库置于应用服务器之中,这样的话,就形成了应用与服务器之间的循环依赖,如下图所示。可以说服务器变成了应用的一部分。

在部署方面,应用服务器支持多种部署格式,如 WAR、EAR 以及 JAR 等等,但是这些格式都无法定义应用的外部依赖,如应用服务器的版本、数据库等。通常在这个过程中,会使用到 deb 或 RPM 这样完全不同的工具。应用服务器的配置甚至比应用本身的配置还复杂,相对于使用 Puppet/Chef 编写的自动化脚本,应用服务器的配置过于繁琐。对于持续交付来讲,我们必须要有大量的部署过程,因此需要简化部署,并且要使用更为通用的工具。

应用服务器的监控功能一般是通过 JMX 提供的,可以使用 SNMP 等协议进行集成,但是问题同样在于完全不同的工具链(tool chain)。在这个方面出现了一些新的技术和趋势,如 Logs+Logstash/Kibana 或 Splunk、基于 REST 或编写脚本实现监控的功能。

作者稍后提到了微服务的理念,基于这种理念所构建的软件是由服务组成的,服务会具有一定的业务含义,服务的(重)部署可以独立进行,而不是作为一个庞大的整体来进行,服务之间可以通过像 REST 这样的方式来进行交互。服务可能会有不同的非功能性需求,所以会需要不同的基础设施,如异步、传统的 Servlet、Batches、Map/Reduce 等,而应用服务器只能提供一种基础设施。

基于这种模式,应用能够以 JAR 文件的方式进行创建,在这个 JAR 中包含一个 Main 类,我们可以自定义基础设施,如 HTTP 服务器或 Batch。在监控和部署方面,它依赖于标准的部署和监控工具,提供基于 REST 的监控 URL,并且会分析评估日志文件。这种方式能够带来一系列的好处,因为它只是一个 JAR 包,所以更易于部署,我们可以在 IDE 中调试运行,验收测试会更为容易,并且可以确保基础设施与应用是兼容的。作者最后提到了相关的技术,如 Spring Boot Dropwizard

其实,关于应用服务器已死的观点,在云理念刚刚普及的时代就曾经出现过,如来自 Forrester 的首席分析师 Mike Gualtieri 在 2011 年就曾经撰文表示应用服务器的泡沫会破灭并建议不要再将金钱花费在 WebLogic、WebSphere 以及 JBoss Application Servers 上面了。当时,RedHat 的 Mark Little 曾经专门就这种观点进行过反驳。最近,Mark Little 恰好写了一篇文章阐述中间件平台的未来趋势,在这篇文章中,作者认为我们需要新的框架和模型来构建应用,可适应的中间件平台应该具有的特性包括:

  • 能适应环境的变化,自动监控和管理;
  • 灵活的线程模型;
  • 所有的应用和服务可以根据需要动态添加;
  • 组件库;
  • 跟踪对象和服务的依赖,以便于迁移时,相关的服务和对象能够保持兼容。

Mark Little 和 Eberhard Wolff 都提到了新的编程和部署模式, Parallel Universe 公司的博客上,最近也连续发表了三篇文章介绍 Java 的发展趋势,其中有一篇专门介绍现代 Java Web 应用的开发与部署,作者也提及了这种新的部署理念。

现在就说应用服务器已死可能为时尚早,但是服务化、分布式是应用的发展方向,这会对传统应用服务器的部署、监控等功能提出挑战。关于这一问题,如果您有新的见解,欢迎与我们分享。

2014-05-21 21:1911457

评论

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

架构师训练营 - 第五周总结

一个节点

极客大学架构师训练营

第一周UML图

Geek_9527

架构师训练营 -week05- 总结

lucian

极客大学架构师训练营

架构师训练营第五周总结

睡不着摇一摇

架构师一期

技术选型一第五周作业「架构师训练营第 1 期」

天天向善

食堂就餐卡系统设计

DL

4. Validator校验器的五大核心组件,一个都不能少

YourBatman

Hibernate-Validator Bean Validation 数据校验

正式“退休”的Flash,未来我们会怀念它吗?

脑极体

第五周作业

alpha

极客大学架构师训练营

架构方法学习总结

Sandman

极客大学架构师训练营

架构师训练营 -week05- 作业1

lucian

极客大学架构师训练营

架构师训练营W01作业

Geek_f06ede

极客大学架构师训练营

微服务监控:SpringBoot-Micrometer-Influx

远鹏

监控 Influxdb springboot metrics

LeetCode题解:50. Pow(x, n),迭代分治,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

1024,属于程序员的一天

白色蜗牛

编程 程序员 Java 分布式 1024

【建议收藏】10个适合程序员逛的在线社区

田维常

第五周学习总结

alpha

极客大学架构师训练营

架构师训练营 - 第五周作业

一个节点

极客大学架构师训练营

图解 | 一图摸清Android系统服务

哈利迪

android

图解 | 一图摸清Android应用进程的启动

哈利迪

android

架构师训练营 1 期 - 第五周作业(vaik)

行之

极客大学架构师训练营

架构师训练营 W01 总结

Geek_f06ede

极客大学架构师训练营

架构师训练营第 1 期 -week5

习习

LeetCode题解:50. Pow(x, n),递归分治,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

极客大学 - 架构师训练营 第五周

9527

图解 | Android系统的启动

哈利迪

android

架构师入门感悟一

笑春风

架构师2期week1作业

M.

一个大型的互联网应用系统使用了哪些技术手段

kawayi

技术选型一第五周总结「架构师训练营第 1 期」

天天向善

架构师训练营week1学习总结

花果山

极客大学架构师训练营

Java应用服务器前途堪忧?_Java_张卫滨_InfoQ精选文章