java应用服务器程序_Java应用程序服务器已死！

java应用服务器程序

多年来，Enterprise Java一直是Application Server的同义词。 这些年来，Application Server的部署和操作几乎没有变化-API已适应新的范例，并引入了竞争性编程模型。 现在也该反思一下传统企业堆栈的这一部分了。

在此处阅读有关基础结构和依赖性的第一部分 。

应用服务器支持应用程序的部署。 文件格式包括用于Web应用程序的WAR，用于具有多个不同模块的企业应用程序的EAR和用于EJB或库的JAR。 这些文件格式不支持Java世界之外的依赖关系。 例如，不可能定义Java应用程序依赖于数据库服务器还是特定版本的数据库服务器。

而且，即使应用程序通常不能跨应用程序服务器移植，也无法定义JAR，WAR或EAR取决于特定的应用程序服务器或应用程序服务器的版本。 其他部署工具（例如Linux软件包管理器）也支持此类依赖关系。

它们也更通用并且支持任何类型的应用程序-不仅是Java。 这些工具已被操作成功使用。 这些工具可以自动配置和部署服务器场和群集。 具有群集支持的Application Server不需要这样做。 相反，任何运作良好的运营部门都应该能够安装大型集群。

因此，操作系统的某些功能可能是部署应用程序的更好选择。 操作系统也可以启动应用程序，例如作为Unix服务。 这样，应用程序可以充分利用操作系统以及应用程序在这样的平台上的工作方式。

Java有一个监视标准：JMX（Java管理扩展）。 它提供了一个API，用于更改正在运行的应用程序中的属性，并在发生问题时发出事件。 JMX是一个成熟而强大的工具。 它可以集成在基于SNMP的系统中，该系统在操作中很常见。 此外，新的监控工具（如石墨）也可以与JMX集成。 JMX是JDK的一部分。 因此，可以在没有应用服务器的情况下使用它。 使用Jolokia JMX数据也可以通过REST作为JSON数据进行访问。 这样，可以轻松评估它，例如使用简单的shell脚本。

通常，操作还使用其他信息源：日志文件。 可以使用诸如Graylog2或ELK堆栈之类的工具进行评估。 ELK堆栈由用于存储日志的Elasticsearch，用于解析和解释日志数据的Logstash和用于分析存储在Elasticsearch中的数据的Kibana组成。

综上所述：操作通常具有一堆用于监视和日志分析的标准工具，应用程序应将这些工具集成到其中。 如果使用了Application Server的监视功能，它们会使工具堆栈更加复杂。 因此，使用此工具栈通常比为Java应用程序创建其他工具栈更容易。

显然，应用服务器不是监视，部署或专业运行Java应用程序的先决条件。 相反，Application Server带有自己的操作工具集-如果已经实现了功能强大的通用工具栈，那么这可能并不是真正的好处。

对于开发人员来说，Application Server在构建测试周期中意味着一个额外的步骤（请参见下面的图1）。 构建的结果被压缩到JAR或WAR文件中。 然后，应用服务器将其解压缩，开发人员可以对其进行测试。 因此，代码被压缩了–只是再次被解压缩了。 可以使用JRebel之类的工具来缩短此周期，这些工具可使Application Server快速重新加载更改的类。

对于生产系统和测试系统，Application Server还增加了相当大的负担：

• 除了应用程序之外，还必须部署Application Server。 Application Server的配置通常非常复杂-有时甚至比应用程序本身的配置还要复杂。 因此，很难编写用于Application Server的自动化脚本。 诸如Chef或Puppet之类的工具可用的脚本证明了这一点。
• Application Server的配置必须适合应用程序本身的版本和配置。 并且必须在每个开发人员的本地安装和每个测试阶段都确保这一点。 当然，旧的配置也必须可用–例如，测试生产中的错误修复。 这很难做到。
• 由于当今经常使用连续交付来开发应用程序，因此该问题变得更加严重。 下方的图2显示了持续交付管道-持续交付的核心。 它包含多个测试阶段–自动验收测试，自动容量测试和探索性测试。 在上述每个阶段中，必须将软件部署在测试系统上并进行测试-管道每天要执行几次。 部署过程中的额外复杂性具有巨大的影响，因为每天要完成许多部署。 在这样的环境中，部署必须尽可能简单。 因此，应避免使用Application Server。

因此，不仅使用Application Server的好处值得怀疑–实际上，Application Server给应用程序的部署以及操作和开发增加了相当大的负担。

图2：连续交付管道

IT领域的新趋势也并不完全适合应用服务器的概念。 DevOps宣称将开发（Dev）和运营（Ops）融合到DevOps。 这导致了不同的心态：开发人员通常使用专门针对Java的工具。 运营有一系列支持更广泛前景的工具，例如，可能基于程序包管理器的部署自动化以及用于系统和应用程序指标的监视工具。

DevOps的心态使开发人员更加了解这些工具，因此他们也将它们用于设置自己的计算机。 这使得开发人员也更容易使用Application Server工具的替代方案。

对应用服务器的另一个影响是微服务。 通过这种范例，系统由微服务而不是例如JAR组成。 服务应具有业务意义，并且可以独立部署。 因此，将系统拆分为几个可部署的组件，而不是单独的部署。 每个通信都通过诸如REST之类的协议与其他通信。 每个微服务实际上都是一个单独的Web应用程序。

为这些微服务中的每一个部署应用服务器都会给系统增加可观的开销。 比传统设置需要更多的实例。 此外，微服务还专注于专用基础架构：对于前端微服务而言，应用服务器可能非常合适。 但是对于数据分析而言，像Hadoop这样的大数据特殊基础架构可能更合适。 而且，如果应按批处理发票，则诸如Spring Batch之类的批处理基础结构可能是更好的选择。

图3：连续交付管道

总结一下（请参见上面的图3）：

• 应用服务器使基础架构更加复杂。 它不仅是另一软件，而且是必须正确安装和配置的复杂软件。 另外，配置必须适合应用程序。
• Application Server减慢了测试的周转时间。 在执行之前，必须对代码进行打包和部署（即压缩和未压缩）。
• 用于监视和部署的标准操作工具是Application Server提供的解决方案的绝佳替代方案。 由于DevOps的兴起，这些标准工具变得越来越流行。
• 最后，持续交付意味着软件部署频率更高。 因此，通常应避免使用像Application Server这样的更复杂的基础结构。
• 微服务增加了独立部署的组件的数量。 同样，这意味着应避免使用复杂的基础架构。

如果应用服务器只是造成更多的复杂性，则没有充分的理由使用它们。 另一种方法是简单的Java应用程序。 它们可以打包为包含主类的JAR文件，因此可以从命令行启动。 JAR文件包含所有必需的基础结构，即库，还包含用于Web应用程序的嵌入式HTTP服务器。 对于监视和部署，可以使用标准工具，例如Graphite或基于JMX的系统。 可以使用许多自动化工具（如Puppet ， Chef或Ansible）之一进行部署 。 请注意，自动化非常容易设置。

该应用程序需要一个已安装的Java，必须将JAR文件复制到计算机上，并且可能必须为该应用程序创建一个配置文件。 可以像其他任何应用程序一样通过命令行启动该应用程序。 这比典型的应用程序服务器的安装要简单得多。 因此，即使必须安装服务器群集，也易于设置自动安装。 此设置还使隔离应用程序变得容易：每个应用程序都是一个单独的进程，可以由操作系统进行相应的管理。

对于开发人员而言，现场工作也更加轻松：可以在IDE中调试和运行应用程序。 同样，验收测试要简单得多。 无需将应用程序部署到应用程序服务器，它可以作为简单的Java应用程序运行-甚至可以在测试本身中运行。 因此，例如，Selenium GUI测试可以在与应用程序本身相同的JVM中运行，也可以在诸如Jenkins的集成服务器上运行。

某些技术最近已经实现了将Java应用程序部署为简单的JAR文件：

• Spring Boot将无容器部署应用于整个Spring生态系统和其他几种技术。 这不仅包括Web应用程序，还包括批处理或Spring Integration应用程序。 Spring Boot应用程序也可以部署为WAR文件来支持Application Server。
• Dropwizard仅支持具有预定义技术堆栈的JSON REST Web服务。 因此，它使用简单，但也不太灵活。
• Vert.x是一个专注于异步应用程序的框架，可以在JVM上与许多不同的语言一起使用。 它提供了一个选项，可以将应用程序和环境打包在一个JAR中。
• Play是用Scala编写的，可用于编写Web应用程序。 要部署Play应用程序，可以构建一个JAR，其中包括该应用程序及其环境和库。

很难提出令人信服的技术原因，为什么仍应使用Application Server。 对部署和监视的支持也可以通过已经使用过操作的通用工具来完成。 库可以提供开发人员所需的功能。 没有Application Server，构建应用程序将变得更加容易-部署，测试和调试也变得非常简单。

但是，如果您已经安装了应用程序服务器，并且习惯于在生产环境中运行它们，则情况会有所不同。 切换到无容器部署将改变很多过程。 进行这些更改的努力必须与收益保持平衡。

翻译自: https://jaxenter.com/java-application-servers-dead-112186.html

java应用服务器程序