哪种应用容器更适合于Docker容器？

Question

哪种应用容器更适合于Docker容器？

4

我们未来的架构计划是向docker /微服务迁移。目前我们正在使用JBoss EAP 6.4（有升级到EAP 7的潜力）和Tomcat。

我认为JEE容器对于微服务环境来说太重了（速度慢，内存更大，维护成本更高等）。但是，有人告诉我EAP 7非常快且轻量级，可以用于开发微服务。在决定EAP 7与Tomcat 8用于docker /微服务时，您有什么建议？成本和速度将是考虑因素。

- user1664338

也许可以帮助http://wildfly-swarm.io，例如https://github.com/wildfly-swarm/wildfly-swarm-examples/tree/master/docker/docker-jaxrs - Federico Sierra

2个回答

5

除了使用传统的应用服务器，它们并不是很重，你还可以尝试一种名为微容器的Java EE不同风味。

Java EE只是一组标准。标准产生API规范，然后每个人都可以自由实现该规范。应用服务器（AS）主要是这些功能的精心调整集合。这些API不是无缘无故地被带来的。它们代表了项目中常用的功能。应用服务器可以被视为这些功能的“策展集”。这种方法有许多优点-AS拥有许多用户，因此经过长时间的测试。自己连通功能可能会导致错误。

无论如何，一个新时代已经到来，在Docker的帮助下，应用程序携带其依赖项。在许多情况下，不再需要全面的应用服务器，所有功能都准备好为应用程序服务。过去，应用服务器并不确切知道应用程序部署所需的服务。因此，一切都被捆绑在一起。像WildFly 这样更具创新性的AS仅实例化所需的服务。此外，还有Java EE配置文件可以稍微减轻单体应用服务器的负担。

目前，我们通常将应用程序及其依赖项（JDK、库、AS）一起打包到Docker中 - 或者我们正在朝这个方向发展。因此，努力捆绑恰好所需的数量是一个合乎逻辑的选择。但是，需要AS功能的需求仍然存在着。基于标准和共同努力开发通用功能仍然是一个好主意。只是不再将其作为一个大包分发，可能会使大多数API处于非活动状态。这个努力有很多名称，例如微型容器、超级jar创作者...

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

关键点是，您的Java EE应用程序应作为独立的Java EE应用程序开发。将其包装成“刚好足够”的功能委托给这些微型解决方案。这至少是我个人的看法，这是正确的方法。这样，您将保留与完整AS和微型解决方案的兼容性。超级JAR文件，包含所有依赖项，可以在构建过程期间或之后创建。

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

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

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

- user1930502

我认为，在 Docker 时代，应用服务器/微服务器/任何具有较短发布周期的东西更好。开发人员可以快速轻松地交换依赖关系。这样，更新的版本带有最新功能几乎立即进入生产环境 :) WildFly 是具有相对较短发布周期的容器之一，其他容器不确定。 - user1930502

WildFly每年发布2次，WF Swarm每年发布12次，Payara每年发布4次（支持订阅者为12次），TomEE每年发布4次。如果您想要短的发布周期，现在有很多选择。 - OndroMih

这绝对是向前迈进的一步，因为我们不再每两年发布一个主要版本。 - user1930502

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Arun Gupta · Accepted Answer

EAP7和Tomcat 8是一个古老的问题，已经在这里这里、这里以及这里被多次回答。Tomcat仅是一个Web容器，而EAP7是一个应用服务器，提供所有Java EE 7功能，如持久性、消息传递、Web服务、安全性、管理等。EAP7有两个配置文件：Web Profile和Full Profile。Web Profile是更加精简的版本，只包含通常用于构建Web应用程序的相关实现。Full Profile则包含平台的全部功能。因此，使用EAP 7 Web Profile可以帮助您大幅减少臃肿。
对于Tomcat，您将不得不使用类似Spring的东西来提供同等的功能，并将所有相关JAR文件打包到应用程序中。
当您开始一个全新项目并且既有Java EE资源又有Spring资源时，这些讨论通常是有帮助的。以下是您可能考虑使用EAP7的原因：

您已经在使用EAP 6.4。迁移到EAP 7将是无缝的。使用Docker只是一种不同的应用程序打包方式。您现有的所有监控、集群、日志记录都将继续工作。如果选择Tomcat，那么您将不得不学习Spring的做事方式。如果您有时间和资源并且愿意尝试，也可以走这条路。但请考虑您想从中获得什么？
EAP 7针对容器和云部署进行了优化。特别地，它作为OpenShift的服务可用，因此您知道它可以直接使用。

EAP 7会比EAP 6.4在延迟和吞吐量方面有相当大的性能提升。详情请参阅https://access.redhat.com/articles/2607521。

您还可以考虑使用TomEE。他们提供了与Tomcat集成的Java EE堆栈。

另一个选择，正如@Federico所推荐的那样，请考虑使用WildFly Swarm。然后，您可以真正开始自定义Java EE平台的哪些部分。并且您的部署模型正在使用JAR文件。

至于使用Docker打包，它们都提供基本镜像，您需要将应用程序捆绑在其中。以下是使用微服务Docker镜像的一些重要考虑因素：

Docker镜像的大小：容器可能会意外死亡或编排框架可能决定在不同的主机上重新安排它。更大的镜像大小将需要更长时间来下载。这意味着对于较大的镜像，您的服务的感知启动时间将更长。这也意味着应用程序的动态扩展需要更长时间才能生效。
镜像的启动时间：在下载图像后，容器可能会快速启动，但应用程序“准备就绪”需要多长时间？

作为个人说明，我比较熟悉Java EE堆栈而不是Tomcat / Spring，并且WildFly仍然是我最喜欢的应用服务器。