Java应用服务器死了

该文认为Node.js发起的微服务架构将彻底颠覆JavaEE传统的应用服务器概念,Java应用服务器包括Tomcat JBoss Websphere Weblogic 或Oracle的应用服务器。应用服务器是Java EE或Servlet容器。

每台服务器上部署我们开发的应用程序都需要一个应用服务器,这已经是多年来养成的习惯,但是今天我们要反问一下,为什么我们要这样?为什么我们一定要为应用服务器买单?

该PPT从应用服务器的四个方面进行分析:
1. 应用服务器是多个应用的容器?
2. 应用服务器是底层基础设施?
3. 应用服务器的部署?
4.应用服务器的监控?

首先,应用服务器是多个应用的容器,这样做的好处是能够对应用进行通过ClassLoader隔离,相互不会影响。其实只是靠ClassLoader隔离类的加载层次是不够的,CPU 内存 应用系统是否需要隔离呢?否则,如果某个独立应用非常耗费CPU,还是会对其他应用造成影响。特别是我们将JMS和Web置于同一台服务器,JMS会消耗很多资源。

所以,隔离是不可能的,即使JVM成为一个操作系统,隔离也不会很完美。Linux等操作系统是通过进程彼此隔离,但是CPU 内存等也是共享的。

那么多个应用部署在一个应用服务器中真正是什么意思呢?JavaEE讲的多个应用的应用指的是一种组件Component概念,并不是App,如WAR EJB JAR等。不同的组件由不同Classloader加载,彼此隔离。

下图展示了JavaEE的三个概念:
应用服务器 --> App应用 ---->多个组件

也就是说,一个应用服务器对应一个App应用,不是多个App,而是多个组件,这是JavaEE应用服务器的真正含义。多个应用服务器可以组成集群。

其次,应用服务器是基础设施,提供一些基础功能,这些功能包括:两段事务提交(2PC) 网络和线程以及基础API。

2PC是一个跨数据库的事务机制,保证复杂操作过程的原子性,通过JMS可实现分布式事务。但是2PC存在下面问题:会降低处理性能,不是100%可靠,2PC也会失败,在分布式环境有限制,对于新技术无法使用,如REST + 2PC?   NoSQL + 2PC? 最大问题还是NoSQL批判的那样,没有拓展性scalability。

网络和线程设施包括数据库连接池和Http线程池等等,JavaEE的API包括EJB, CDI, JPA, JSF等,现实中问题是:版本与应用服务器版本紧耦合,由此应用App严重依赖应用服务器,直到有新的应用服务器发布,否则新的API无法使用,API版本冲突上升愈演愈烈。

这些基础设施通过并不能覆盖通常应用,还需要附加额外的库包,最后应用服务器被库包替代,应用能够携带库包移植,反而更具有移植性。所以,应用服务器和库包一样,应该是应用程序的另外一个部分而已,否则...

倡导应用服务器独立,这会导致每个应用服务器有自己的基础设施,例如数据库连接池 特别的配置方法,甚至加入了自己额外的库包到应用服务器中,最后导致依赖循环,应用app和应用服务器都依赖同一个包的不同版本,造成难以协调的恶果。

应用服务器独立还会导致服务器之间的差异,甚至不同版本服务器都存在差异,导致我们的应用并不能无缝地部署到这些不同的厂商的服务器中。

另外,应用服务器并不是通用的基础设施,批处理 MapReduce等并不提供,它只是基础设施中的一种而已。

最后,应用服务器能够提供部署应用和监控运行的功能,但是这些总是和复杂的工具相关,比如部署格式就有WAR, EAR, JAR三种,部署工具使用Maven等脚本,监控方面基于JMX 和SMNP就有很多工具系列。在今天部署日益频繁的情况下,简单部署更加重要,这时应用服务器成为令人头疼的问题。

因此,应用服务器这几个特点导致了今天的各种问题,难道我们还要继续如此纠结下去吗?

在今天对产品需要Continuous Delivery连续交付的压力下,我们需要更加简单的基础设施,更简单的部署方式。

如今微服务架构正在日益流行,有如下特点:
• 能够建立基于服务组合的软件
• 服务有业务的含义  如订单Order, Catalog目录等服务
• 服务能够独立重新部署
• 相比传统应用是整块一起部署到应用服务器,微服务能够独立部署。
• 微服务之间通过REST通讯。

那么我们的问题是:难道要为每个微服务安装一个应用服务器吗?非常笨重。

微服务的架构提出无疑颠覆了传统应用服务器概念,如今我们可以抛弃应用服务器,这么做:
创建一个JAR文件,里面包含一个main类用于直接启动,其中有优化定制的基础设施库包比如Http服务器等。

在部署方面易于部署,因为只有一个JAR包,然后是一些命令行配置,这些都是标准的部署工具,监控工具也是标准的,比如基于REST URL的监控,日志文件等。

目前技术方面已经准备好,如Java的Spring Boot或Javascript的Node.js。

banq注:应用服务器通常也是Java中间件的另外一种代称,应用服务器已死,中间件概念变得轻量,负责拓展性伸缩性Scalable的一些中间件被云计算的Paas替代。参考:云计算的Paas五层

看了对node.js的介绍及相关资料,有一种冲动