为什么我们在同一台服务器上使用多应用服务器实例
我想有一个很好的理由，但我不明白为什么有时我们会在相同的物理服务器上放置5个具有相同web应用程序的实例。
它与多处理器架构的优化有关吗？ JVM或其他什么允许的最大ram限制？
嗯……经过很长一段时间我再次看到这个问题:)
好吧，一台机器上的多个JVM实例解决了很多问题。 首先让我们面对这一点：尽管JDK 1.7正在出现，但许多遗留应用程序是使用JDK 1.3或1.4或1.5开发的。 而且JDK的主要部分仍然存在。
现在问你的问题：
从历史上看，系统架构师通过在一个盒子上部署多个JVM来解决三个主要问题：
-
Garbage collection inefficiencies:随着堆大小的增加，垃圾收集周期 – 特别是对于主要收集 – 由于采用单线程GC，因此往往会在处理过程中引入显着的延迟。 多个JVM通过允许一般较小的堆大小并在GC循环期间启用一些并发度来解决这个问题（例如，有四个节点，当一个进入GC时，你仍然有三个其他主动处理）。 -
Resource utilization:较旧的JVM无法有效扩展到四个CPU左右。 答案？ 为盒子中的每2个CPU运行一个单独的JVM（里程可能因应用程序而异，当然）。 -
64-bit issues:较旧的JVM无法分配超出32位最大值的堆大小。 同样，多个JVM允许您最大化资源利用率。 -
Availability:人们有时在一个盒子上运行多个JVM的最后一个原因是可用性。 虽然这种做法确实不能解决硬件故障，但它确实解决了应用服务器的单个实例中的故障。
取自（ http://www.theserverside.com/discussions/thread.tss?thread_id=20044 ）
我大多看过weblogic。 以下是进一步阅读的链接：
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/perform/WLSTuning.html#wp1104298
希望这会帮助你。
我猜你指的是应用程序集群。
AFAIK，JVM的产生了非常大的堆大小在垃圾收集方面存在问题，虽然我确信通过使用GC算法和参数可以将损坏降到最低。 此外，群集应用程序没有单点故障。 如果一个节点发生故障，其余节点可以继续为客户端提供服务。 这是“基于消息的体系结构”非常适合可伸缩性的原因之一。 每个请求都映射到一条消息，然后可以由集群中的任何节点接收。
另一点是同时为多个请求提供服务，以防您的应用程序不幸地明智地使用synchronized关键字。 我们目前有一个遗留应用程序，它有很多共享状态（不幸的是），因此并发请求处理是通过产生大约20个JVM进程和一个中央调度单元来完成的，该单元执行所有调度工作。 😉
我建议你每个NUMA区域使用最少的JVM。 如果单个JVM使用多个NUMA区域（通常是单个CPU），则由于访问另一个CPU的主存储器的成本显着增加，性能会显着降低。
此外，使用多个服务器可以允许您
- 使用不同版本的java或您的应用程序服务器。
- 隔离可能会干扰的不同应用程序（它们不应该但可能会干扰）
- 限制服务之间的GC暂停时间。
编辑：这可能是历史性的。 过去可能有多种原因需要单独的JVM，但由于您不知道它们是什么，您不知道它们是否仍然适用，并且可能更简单地保留原样。
使用mutliple实例的另一个原因是可维护性。
例如，如果多个客户有多个不同的应用程序，那么在发布期间必须重新启动appserver时，为每个应用程序创建appserver的单独实例可以使生活更轻松一些。
假设您有一个平均配置主机并安装了Web / app服务器的单个实例。 现在您的应用程序变得更受欢迎，点击次数增加了2倍。 你现在做什么？
再添加一个相同配置的物理服务器并安装应用程序并对这两个主机进行负载平衡。
这不是您的应用程序的寿命终结。 您的应用程序将继续变得越来越流行，因此需要扩展它。 你的策略是什么？
- 继续添加更多相同配置的主机
- 购买function更强大的机器，您可以在其中创建更多逻辑应用程序服
你会选择哪个选项？
您将进行成本分析，其中包括实际硬件成本，管理这些服务器的成本（电力成本，数据中心占用的空间）等因素。
显然，这个决定并不容易。 在大多数情况下，拥有更强大的机器更具成本效益。