各种 Java 打包策略的优缺点答案

【问题标题】：Pros/cons to various Java packaging strategies各种 Java 打包策略的优缺点
【发布时间】：2012-02-22 12:08:44
【问题描述】：

假设我正在为一些前端 GUI (Swing) 工具编写 Java 后端。该后端将包含许多不同类型的用于中间件/业务逻辑的 EJB，以及一些过滤和转发请求到这些 EJB 的 Web 服务。

就打包和部署而言，我们有几种不同的可能策略：

1 个整体 EAR/1 个应用服务器 - 将所有 EJB 打包成 JAR，将 Web 服务打包成 WAR，并将所有这些打包在 1 个整体 EAR 中；然后将 EAR 部署到应用服务器（例如 GlassFish）
Many tiny EARs/1 appserver - 将每个组件（每个 EJB 和每个 Web 服务）打包到自己的 JAR/WAR 中，然后将每个 JAR/WAR 打包到自己的 EAR 中；因此组件和 EAR 之间存在 1:1 的比例；然后将每个 EAR 部署到同一个应用服务器
许多微型 EAR/许多应用服务器 - 与上述相同，除了每个“微型”EAR 都部署到自己的应用服务器上；因此组件和应用服务器之间存在 1:1 的相关性
无 EAR/许多应用服务器 - 除了删除“中间人”EAR 并将每个打包的 JAR/WAR 部署到其自己的应用服务器之外，与上述相同

这 4 种策略各自的优缺点是什么？有些更安全吗？表现？更有利于集群/复制？其中一些策略是不是很傻？！？

提前致谢！

【问题讨论】：

【解决方案1】：

打包应用程序对安全性没有内在影响。暴露的服务、单个服务器、请求端点等的数量，以及服务访问需要保护的资源的方式是安全所关心的，而不是如何打包。

也就是说，您在这里看到的主要问题是单体与模块化。一旦您了解那是核心问题，所有关于权衡的现有文献都是相关的。

具体来说，您将看到：

【讨论】：

感谢 cdeszaq - 所以您是说现代实践正趋向于更小、模块化、基于“组件”的开发？如果是这样，是否可以说您将成为许多 EAR/许多应用服务器的支持者？再次感谢！
基于组件的开发绝对是当前的最爱。许多 EAR 都与此同步。这些模块拆分的应用服务器数量是一个规模问题，而不是打包问题。首先将所有应用程序放在一台服务器上，然后根据负载需要将它们分开。除非需要，否则不要优化基础架构。
最后两句话对我来说将一切联系在一起。很好的答案，和很好的建议。谢谢！