Java应用服务器死了(微服务)

作者:xinwang_m@163.com
发布时间: 2020-07-21 03:02:59 (3年前)
关键词: Java；服务器
摘要:

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

该文认为Node.js发起的微服务架构将彻底颠覆JavaEE传统的应用服务器概念，Java应用服务器包括Tomcat JBoss Websphere Weblogic 或Oracle的应用服务器。应用服务器是Java EE或Servlet容器。每台服务器上部署我们开发的应用程序都需要一个应用服务器，这已经是多年来养成的习惯，但是今天我们要反问一下，为什么我们要这样？为什么我们一定要为应用服务器买单？该PPT从应用服务器的四个方面进行分析：
<ol>
 <li>应用服务器是多个应用的容器？</li>
 <li>应用服务器是底层基础设施？</li>
 <li>应用服务器的部署？</li>
</ol>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替代。,该文认为Node.js发起的微服务架构将彻底颠覆JavaEE传统的应用服务器概念，Java应用服务器包括Tomcat JBoss Websphere Weblogic 或Oracle的应用服务器。应用服务器是Java EE或Servlet容器。每台服务器上部署我们开发的应用程序都需要一个应用服务器，这已经是多年来养成的习惯，但是今天我们要反问一下，为什么我们要这样？为什么我们一定要为应用服务器买单？该PPT从应用服务器的四个方面进行分析：
<ol>
 <li>应用服务器是多个应用的容器？</li>
 <li>应用服务器是底层基础设施？</li>
 <li>应用服务器的部署？</li>
</ol>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替代。

0 条回复

动动手指，沙发就是你的了！

登录后才能参与评论