哪个应用程序容器更适合Docker容器？

Question

我们未来的架构是走向码头/微服务.目前我们正在使用JBoss EAP 6.4(有可能升级到EAP 7)和Tomcat.

据我所知,JEE容器对于微服务环境来说太重(慢,内存更多,维护更高等).然而,有人告诉我,EAP 7速度快,重量轻,可用于开发微服务.对于Docker /微服务,您在决定EAP 7与Tomcat 8时的输入是什么？成本和速度将被考虑.

Answer 1

EAP7与Tomcat 8是一个古老的问题,在这里,这里和这里多次回答.

Tomcat只是一个Web容器,其中EAP7是一个应用程序服务器,提供所有Java EE 7功能,如持久性,消息传递,Web服务,安全性,管理等.EAP7有两个配置文件 - Web Profile和Full Profile.Web Profile是一个非常简洁的版本,仅包含构建Web应用程序通常所需的相关实现.正如您所期望的那样,完整档案包含了平台的全部荣耀.因此,使用EAP 7 Web Profile可以帮助您减少膨胀.

使用Tomcat,您必须使用类似Spring的东西来提供相同的功能,并将所有相关的JAR打包到您的应用程序中.

当您启动一个全新的项目并同时拥有Java EE或Spring资源时,这些讨论通常很有用.以下是您可以考虑使用EAP7的原因:

• 您已在使用EAP 6.4.迁移到EAP 7将是无缝的.使用Docker只是一种不同的应用程序打包方式.您现有的所有监控,群集和日志记录都将继续有效.如果你要使用Tomcat,那么你将不得不学习Spring的做事方式.如果你有时间和资源并愿意尝试,你也可以走这条路.但想想你想从中获得什么？
• EAP 7针对容器和云部署进行了优化.特别是,它可以作为OpenShift服务使用,所以你知道它可以工作OOTB.
• 与EAP 6.4相比,EAP 7在延迟和吞吐量方面将提供良好的性能提升.有关更多详细信息,请阅读https://access.redhat.com/articles/2607521.

您也可以考虑TomEE.它们提供与Tomcat集成的Java EE堆栈.

另一个选项,如@Federico建议,考虑使用WildFly Swarm.然后,您可以真正开始定制您想要的Java EE平台的哪些部分.您的部署模型使用的是JAR文件.

至于使用Docker的打包,它们都提供基本映像,您需要将应用程序捆绑在其中.以下是使用Docker镜像进行微服务的几个重要注意事项:

• Docker镜像的大小:容器可能意外死亡,或者编排框架可能决定在不同的主机上重新安排它.更大的图像尺寸下载需要更长的时间.这意味着您感知的服务启动时间将更多地用于更大的图像.这也意味着动态扩展应用程序需要更长时间才能生效.
• 图像的启动时间:下载图像后,容器可能会快速启动,但应用程序"准备好"需要多长时间？

作为个人注释,我比Tomcat/Spring更熟悉Java EE堆栈,而WildFly仍然是最喜欢的应用服务器.

Answer 2

除了使用不是那么重的传统应用程序服务器之外，您还可以体验 Java EE 的不同风格，称为微容器。

Java EE 只是一组标准。标准产生 API 规范，然后每个人都可以自由地实施该规范。应用服务器（AS）主要是此功能的微调集合。这些 API 并不是无缘无故地被启用的。这些代表了项目中常用的功能。应用程序服务器可以被视为这些功能的“精选集”。这种方法有很多优点 - AS 有很多用户，因此随着时间的推移它得到了很好的测试。自行连接功能可能会导致错误。

不管怎样，新时代已经到来，有了 Docker，应用程序就带着它的依赖关系了。在许多情况下，不再需要一个成熟的应用程序服务器，该服务器具有准备好为应用程序提供服务的所有功能。在过去，应用程序服务器并不确切知道部署的应用程序将需要哪些服务。因此，一切都被捆绑在一起。一些更具创新性的 AS（例如WildFly）仅实例化所需的服务。此外，还有一些 Java EE 配置文件可以稍微简化整体应用程序服务器的工作。

现在，我们通常将应用程序及其依赖项（JDK、库、AS）一起发送到 Docker 中 - 或者我们正在前往那里。因此，努力捆绑正确数量的产品是一个合乎逻辑的选择。但是，这是一个“大但是”，对 AS 功能的需求仍然相关。基于标准和共同努力开发通用功能仍然是个好主意。只是将其作为一个大包进行分发似乎不再是一种选择，这可能会使大多数 API 处于不活动状态。这项工作有很多名字，比如微容器、uberjar 创造者……

• 野蝇群
• 帕亚拉微
• 弹簧靴*

Java EE 服务器如此之轻，以至于使用其他任何东西都是值得怀疑的。* Spring Boot 不基于 Java EE，并且在入门指南中的默认配置中，Tomcat 在内部使用。

• 自由软件
• Apache TomEE

关键点是，您的 Java EE 应用程序应该开发为独立的 Java EE 应用程序。用“刚好足够”的功能来包装它被委托给这些微解决方案。至少在我看来，这是正确的道路。这样，您将保持与成熟的 AS 和微解决方案的兼容性。包含所有依赖项的 uber-jar 可以在构建过程期间或之后创建。

WildFly Swarm 或 Payara Micro 能够“扫描”应用程序，仅运行所需的服务。对于实际应用程序，生产中的内存占用量可以低至 100 MB - 对于实际应用程序。这可能就是您想要的。如果您需要 Spring，Spring Boot 也可以做类似的事情。然而，根据我的经验，Spring Boot比现代 Java EE更重量级和更耗内存，因为它显然内部有 Spring，所以如果您在内存消耗方面寻求轻量级，请尝试 Java EE，尤其是 WildFly Swarm（或纯粹的 WildFly） ）和Payara Micro。这些是我最喜欢的 AS，它们非常非常小。我想说 WildFly Swarm 更容易上手，Payara micro 需要更多阅读，但提供了有趣的功能。两者都可以用作包装器 - 您可以在构建阶段后用它们包装当前的项目，无需更改任何内容。

Payara Micro 甚至提供了可供使用的Docker 镜像！正如您所看到的，Java EE 已经成熟并准备进入 Docker 领域:)

Adam Bien 是非常好的、可靠的资源之一，例如在他的Java EE 微/纳米服务视频中。看一看。