【IT168 评论】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恰好写了一篇文章阐述中间件平台的未来趋势,在这篇文章中,作者认为我们需要新的框架和模型来构建应用,可适应的中间件平台应该具有的特性包括:
能适应环境的变化,自动监控和管理;
灵活的线程模型;
所有的应用和服务可以根据需要动态添加;
组件库;
跟踪对象和服务的依赖,以便于迁移时,相关的服务和对象能够保持兼容。