高效部署相同 WAR 的多个实例（不同的上下文，相同的容器）

Question

我有一个 WAR（app.war）和一个容器（Tomcat、Jetty、Glassfish 等等）。 我的目标是按需在容器上部署数百个相同 Web 应用程序的实例。

http://foo/app1 --> app.war
http://foo/app2 --> app.war
http://foo/app3 --> app.war 
...
http://foo/appN --> app.war

实现这一目标的一些明显方法：

• 在 Tomcat 中，为每个应用程序创建一个 context.xml 文件（名为 appN.xml ），所有文件都指向同一个 WAR。其他容器也有类似的方法
  • 这种方法的问题：会爆炸WAR N次，占用大量磁盘空间
• 使用符号链接创建指向 app.war 扩展版本的 webapp/{app1,app2,appN} 文件夹。这可以防止磁盘空间爆炸，但 JVM 仍在将许多重复的 JAR 加载到内存中
• 使用一些共享 lib 文件夹来包含大多数 jars（以及前两个选项的组合）。

我想知道是否有更好的方法来做到这一点。理想情况下，创建一个新实例不应该占用更多的磁盘空间（除了边缘配置文件），并且只占用与线程执行堆栈和其他运行时分配相关的内存。

有什么想法吗？

Answer 1

Jetty 通过所谓的叠加层增加了对您不久前寻找的内容的支持。

http://wiki.eclipse.org/Jetty/Tutorial/Configuring_the_Jetty_Overlay_Deployer

从维基页面复制一点：

• 您可以保持 WAR 文件不可变，甚至已签名，以便清楚您部署了哪个版本。
• 您为自定义/配置 Web 应用程序所做的所有修改都是单独的 WAR，因此很容易识别，以便查看和迁移到新版本。
• 您可以创建一个参数化模板叠加层，其中包含适用于 Web 应用程序的许多实例（例如，用于多租户部署）的常见自定义和配置。
• 由于分层部署清楚地识别了通用组件和实例特定组件，Jetty 能够为模板共享类加载器和静态资源缓存，从而大大减少多个实例的内存占用。

Answer 2

抱歉，有点跑题了，但在我看来，您的场景大喊“多租户”应用程序，因此您有一个可以为多个“租户”（客户）服务的应用程序。

关于多租户设置，必须考虑以下注意事项：

• 客户无法访问彼此的数据（如果他们的数据存储在相同的数据库、相同的架构中并使用“鉴别器”字段来分隔数据）。这可以通过使用带有Access Control Lists 的 Spring Security 来实现
• Hibernate 从 4.0 版开始内置了 support for multitenancy apps。
• 这两个 SO 问题也可能有用
  • Multiple Entity Manager issue in Spring when using more than one datasource（用于使用不同的数据源（不同的数据库或每个客户在同一数据库上的不同模式）。
  • Multi tenancy support in Java EE 6

多租户的好处：

• 共享代码意味着为一个客户修复的错误对所有人都已修复（如果不同的客户对什么构成错误和什么构成功能有不同的看法，这也可能是一个缺点）。
• 集群部署可以在客户之间分担负载（但是，需要确保所有客户都可以使用峰值容量）。

缺点：

• 代码会稍微复杂一些，因为查询需要确保客户之间的“区别”有效，而不会意外地将客户暴露给彼此的数据。

Answer 3

您可以在前端配置 Apache (mod_proxy/mod_proxy_ajp) 以将命名虚拟主机指向部署在 Tomcat 上的单个 WAR。您的应用程序应该以服务所有请求的方式设计/编写——每个网站名称的特定配置可以存储在数据库中或作为应用程序中的配置文件——您的应用程序只需要探测用户的请求域名即可确保应用正确的设置（每个会话一次）。一般来说，您应该能够通过一个应用程序解决此问题。伟大的开发者都是懒惰的。

Answer 4

如果您使用的是 Jetty，则可以通过编程方式添加上下文。

WebAppContext webapp = new WebAppContext();
webapp.setBaseResource(myBaseDirectory);
webapp.setContextPath(myContextPath);

只需为所有上下文循环执行此操作。它的磁盘空间开销应该接近于零。

在 Tomcat 中可能有类似的方法。

Answer 5

如果这是用于实验，那么您列出的任何方法都可以工作。

如果这是用于生产，那么我建议不要这样做。虽然我没有测试所有容器，但我使用过的容器让我相信，简单地为无头虚拟机提供容器会更有弹性。 Linux VM 可以非常小，使用 VM 技术，您可以根据需要添加或减少任意数量的实例。

如果您真的想要一个动态增长的解决方案，那么您应该寻求消除单点故障，而不是尝试将您的整个世界集中在一起。

如果您确实需要“高达第二”的负载扩展/收缩，那么您应该查看 AWS 或 CloundFoundry。