哪个应用程序容器对Docker容器更好？
我们未来的架构是朝着docker/微服务方向发展。 目前我们正在使用JBoss EAP 6.4（有可能升级到EAP 7）和Tomcat。
据我所知，JEE容器对于微服务环境来说太重（慢，更多的内存，更高的维护等）。 不过，据我了解，EAP 7速度相当快，重量轻，可以用来开发微服务。 在决定Docker /微服务的EAP 7和Tomcat 8方面你有什么想法？ 成本和速度将是考虑因素。
除了使用传统的应用程序服务器，这些服务器并不那么重，您可以品尝到不同的Java EE的风格，称为microcontainers。
Java EE只是一套标准。 标准的结果在API规范中，然后每个人都可以自由地实现规范。 应用程序服务器（AS）主要是这个function的一个优化集合。 这些API没有被无缘无故地带回来。 这些代表了项目中常用的function。 应用程序服务器可以被看作是这些function的“策划集合”。 这种方法有很多优点 – AS有很多用户，所以它随着时间的推移被很好的testing。 自行连接function可能会导致错误。
无论如何，一个新的时代已经到来，在Docker中，应用程序依赖于它。 在许多情况下，不再需要一个全function的应用程序服务器，所有function都可以提供给应用程序。 过去，应用程序服务器并不完全知道应用程序部署需要哪些服务。 因此，所有东西都被捆绑在一起。一些像WildFly这样更具创新性的AS 只实例化了所需的服务。 此外，还有一些Java EEconfiguration文件稍微缓解了Monolith Application Server的问题。
现在，我们通常将应用程序和它的依赖项（JDK，库，AS）一起发送到Docker中 – 或者我们正在向前。 因此，精确地捆绑正确的数量是一个合理的select。 但是，这是一个“大但是”，AS的function的需求仍然是相关的。 开发基于标准和共同努力的通用function仍然是一个好主意。 它似乎不再是将其作为一个大型软件包进行分发的选项，可能会使大多数API处于非活动状态。 这个努力有很多名字，无论是微型容器，uberjar创造者…
- WildFly Swarm
- Payara Micro
- 弹簧靴 *
有一些Java EE服务器如此轻便，使用其他任何东西都值得怀疑。 * Spring Boot不是基于Java EE，并且入门指南中提供的默认configuration中，Tomcat在内部使用。
- WebSphere Liberty
- Apache TomEE
关键是，您的Java EE应用程序应该作为独立的Java EE应用程序开发。 用“足够”的function包装它，就是委托给这些微型解决scheme的。 至less在我的愚见中，这是正确的路要走。 这样，您将保持与全面的AS和微解决scheme的兼容性。 包含所有依赖关系的uber-jar可以在构build过程中或之后创build。
WildFly Swarm或Payara Micro能够“扫描”应用程序，只运行所需的服务。 对于真实世界的应用程序，生产中的内存占用空间可能低至100 MB – 适用于实际应用程序。 这可能是你想要的。 Spring Boot可以做类似的事情，如果你需要Spring的话。 然而，从我的经验来看，Spring Boot比现代Java EE 更加重量级和内存要求更高，因为它显然具有Spring内部的特性，所以如果你在内存消耗方面寻求轻量级的话，试试Java EE，特别是WildFly Swarm（或者纯粹的WildFly ）和Payara Micro。 这些是我最喜欢的AS，他们可以真的很小。 我想说的是，WildFly Swarm更容易开始，Payara微需要更多的阅读，但提供有趣的function。 两者都可以作为包装工具 – 在构build阶段之后，您可以将它们包含在当前项目中，无需更改任何内容。
Payara Micro甚至提供了可以使用的Docker镜像 ！ 正如你所看到的，Java EE已经成熟并准备好进入Docker领域:)
亚当·比恩（Adam Bien）就是其中一个非常好的和可靠的资源，例如在他的Java EE微/纳米服务video中 。 看一看。
EAP7 vs Tomcat 8是一个古老的问题， 在这里和这里回答多次。
Tomcat只是一个Web容器，EAP7是一个提供所有Java EE 7function（如持久性，消息传送，Web服务，安全性，pipe理等）的应用服务器.EAP7包含两个configuration文件 – Web Profile和Full Profile。 Webconfiguration文件是非常微调的版本，只包括通常build立一个Web应用程序所需的相关实现。 完整的个人资料，正如你所期望的，包含了平台的全部荣耀。 所以使用EAP 7 Web Profile将帮助你减less相当大的膨胀。
使用Tomcat，你将不得不使用类似Spring的东西来提供相应的function，并将所有相关的JAR与你的应用程序打包在一起。
当您启动一个全新的项目并且同时拥有Java EE或Spring资源时，这些讨论通常很有帮助。 以下是您可能考虑使用EAP7的原因：
- 您已经在使用EAP 6.4。 迁移到EAP 7将是无缝的。 使用Docker将只是打包应用程序的不同风格。 所有现有的监视，群集，日志logging都将继续工作。 如果你要和Tomcat一起去，那么你将不得不学习Spring的做事方式。 如果你有时间和资源，愿意尝试，你也可以走这条路。 但想想你想从中获得什么？
- EAP 7针对容器和云部署进行了优化。 特别是它可以作为OpenShift的一个服务使用，所以你知道它可以工作OOTB。
- 与EAP 6.4相比，EAP 7在延迟和吞吐量方面将有不错的性能提升。 阅读https://access.redhat.com/articles/2607521了解更多详情。
你也可以考虑TomEE 。 他们提供与Tomcat集成的Java EE堆栈。
另一个select，如@Federicobuild议，考虑使用WildFly Swarm 。 那么你真的可以开始自定义你想要的Java EE平台的哪些部分。 而您的部署模型正在使用JAR文件。
至于使用Docker进行打包，他们都提供了一个基本的图像，你需要捆绑你的应用程序。 以下是使用Docker镜像进行微服务的一些重要注意事项：
- Docker镜像的大小：一个容器可能意外死亡，或者编排框架可能决定在不同的主机上重新安排它。 更大的图像大小需要更长的时间才能下载。 这意味着您觉得服务的启动时间会更大一些。 这也意味着应用程序的dynamic缩放需要更长时间才能生效。
- 图像启动时间：图像下载后，容器可能会启动很快，但应用程序需要多长时间才能“准备就绪”？
作为个人logging，我比Tomcat / Spring更熟悉Java EE堆栈，并且WildFly仍然是最受欢迎的应用程序服务器。