哈Ha！
Sebastian Dashner在IBM莫斯科办公室的Java聚会上的讲话（发现了类似的性能
记录 ）促使我开始熟悉轻量级应用程序服务器，尤其是OpenLiberty。 然后我想：
- 轻量级应用服务器的好处是什么？
- 使用它们时，工作的特异性如何变化？
- 为什么将应用程序服务器打包在容器中？
在回答这些问题时，我注意到有关该主题的公共信息很少，因此我决定在此处进行收集和系统化。
我将结果发布在削减之下。
轻量级应用服务器的好处是什么？
以前，企业Java EE应用服务器（例如JBoss AS，Oracle WebLogic，IBM WebSphere AS）被认为是重量级且笨重的设计，尤其是在启动和部署时间方面。 但是，云技术正在占领越来越多的行业，并且应用服务器要求也在不断变化。
现在，代替全功能的企业应用程序服务器，而是专注于特定任务的快速，模块化，小型应用程序服务器：
Thorntail ，
Payara Micro -WildFly和Payara的弟弟；
Meecrowave是轻量级的JAX-RS + CDI + JSON服务器，
KumuluzEE是允许您使用Node.js，Go等扩展Java EE的服务器。
此列表还包括OpenLiberty-一种开源应用程序服务器（根据EPL-1.0进行分发），该服务器支持运行WebSphere Liberty的最新Java EE / Microprofile标准。
EPL-1.0功能一览（Eclipse公共许可证版本1.0）EPL 1.0基于CPL，与GPL不兼容，允许您遵守工作中使用的其他许可和专利，并提供根据任何其他许可对产品进行许可的权利，该程序的所有副本中均应包括许可副本。
主产品的附加内容可能会单独获得许可，甚至可能获得商业许可。 但是，衍生作品的更改和增补必须在相同的EPL许可下获得许可，这要求您打开源代码。
通常，将软件项目与受EPL许可证保护的代码相关联（例如，将此代码用作库）不会使该项目成为派生作品，也不会施加相应的义务。
引用本程序的会员必须这样做，以避免对其他会员承担潜在责任。 （代表所有作者明确放弃任何保证或责任）
例如：参与者可以在产品X的报价中包含程序。然后，该参与者就是商业参与者。 如果此商家随后就X提出速度索赔或提供产品保修，则这些索赔和提议是商人的个人责任。 根据本节的规定，商业成员必须保护其他成员免受与性能和担保有关的索赔，如果法院要求任何其他成员赔偿由此造成的任何损失，则商业成员必须赔偿这些损失。
让我们看看通过使用OpenLiberty将应用程序部署在容器中可以获得什么好处。 （您必须安装任何版本的java，在wlp目录中必须执行更多步骤）
速度：
速度是云应用程序最重要的指标，因为为了使云应用程序能够快速扩展，管理和应对不断增长的负载，必须在几秒钟内启动它。 轻量级的应用程序服务器可以做到这一点。 要进行检查，请
下载OpenLiberty服务器并运行bin / server run（
命令的完整列表 ）：
$ bin/server run defaultServer (Open Liberty 19.0.0.6/wlp-1.0.29.cl190620190617-1530) Java HotSpot(TM) 64-Bit Server VM 1.8.0_212-b10 (ru_US) [AUDIT ] CWWKE0001I: defaultServer . [AUDIT ] CWWKZ0058I: dropins . [AUDIT ] CWWKF0012I: : [el-3.0, jsp-2.3, servlet-3.1]. [AUDIT ] CWWKF0011I: defaultServer . defaultServer 1,709 .
模块化和灵活性
大多数应用程序不需要整体上的Java EE，而是需要专用的一组标准，这些标准最常用于企业应用程序中。 感谢OSGI，我们可以选择所需的Java EE和/或MicroProfile标准集，而忽略其他所有内容。
例如，通过在FeatureManager块usr / servers /
serverName /server.xml中添加几行来声明Java EE中的JAX-RS和Microprofile中的mpHealth。
<?xml version="1.0" encoding="UTF-8"?> <server description="new server"> <!-- Enable features --> <featureManager> <feature>jsp-2.3</feature> <feature>mpHealth-1.0</feature> <feature>jaxrs-2.1</feature> </featureManager> <!-- To access this server from a remote client add a host attribute to the following element, eg host="*" --> <httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443" /> <!-- Automatically expand WAR files and EAR files --> <applicationManager autoExpand="true"/> </server>
动态更新
在开发过程中，程序代码和配置不断变化。
将应用程序服务器配置为监视更改，并在必要时动态地重新配置和部署应用程序。 例如，对最近变化的反应：
[AUDIT ] CWWKG0016I: . [AUDIT ] CWWKG0017I: 0,475 . [AUDIT ] CWWKF0012I: : [cdi-2.0, jaxrs-2.1, jaxrsClient-2.1, jndi-1.0, json-1.0, jsonp-1.1, mpHealth-1.0, servlet-4.0]. [AUDIT ] CWWKF0013I: : [servlet-3.1]. [AUDIT ] CWWKF0008I: 0,476 .
图像大小和组合
应用程序服务器的大小已大大减少，现在可以进行部署
每个应用程序都位于单独的应用程序服务器上，用于将它们打包在容器中，从而提供最大的灵活性。 而且，由于 该映像由多个层组成，在重新组装和分发工件时，仅复制应用程序层，并缓存OS，运行时和应用程序服务器。
Dockerhub已经预构建了包含预配置的OpenLiberty服务器的映像。 我们将使用其中之一并创建一个Dockerfile：
FROM open-liberty COPY usr/servers/defaultServer /opt/ol/wlp/usr/servers/defaultServer ENTRYPOINT ["/opt/ol/wlp/bin/server", "run"] CMD ["defaultServer"]
让我们组装图像：
docker build -t app .
作为容器运行：
docker run -d --name app -p 9080:9080 app
检查结果
http：//本地主机：9080 / health /
要停止容器：
docker stop app
还有很多使用该容器的场景，通常，这是个别文章的场合，因此让我们回到问题所在。
工作的特异性如何变化？
套餐捆绑
容器映像必须仅收集一次，然后在所有环境中执行。 因此，建议将每个应用程序与应用程序服务器一起收集。 这简化了应用程序的生命周期和部署，非常适合现代容器技术。
组装方式
现在，不再需要将不同的技术模块打包到单独的档案中。 所有业务逻辑以及Web服务和端到端功能都打包到单个war文件中。 这极大地简化了项目的安装以及组装过程。 您不再需要将应用程序打包到多个层次结构级别中，然后再次将其打包到一个服务器实例中。
发射
在构建过程中，应用程序服务器和应用程序本身都会添加到映像中。 还可以在构建过程中通过添加专门的配置文件来指定数据源，驱动器或服务器模块的潜在配置。 所有配置上的差异都不应从应用程序内部进行管理，而应从外部进行管理。 因此，不应将应用程序部署在已经运行的容器中，而应在自动部署目录中的映像组装阶段将其添加到该应用程序中，以便在容器启动时启动该应用程序。
功能扩展
容器，部署和扩展系统，监视服务和服务网格使我们有机会在应用程序顶部配置检测，监视，管理，身份验证，扩展，跟踪，稳定性，将大量逻辑透明地传输到另一个级别，从而简化了应用程序并简化了其开发。
为什么将应用程序服务器打包在容器中？
首先，通过将应用程序服务器打包在容器中，您可以使每个团队都有机会独立配置他们的应用程序服务器，并专注于实现功能，从而节省了开发人员进行手动操作，中间件和各种批准的时间。
作为奖励，您有机会充分享受容器以及围绕它们构建的所有工具的好处。 该应用程序易于管理，扩展，更新和自动化工件的组装和部署，停机时间为零。