J2EE应用程序部署:每台应用程序服务器上部署一个应用程序还是多个应用程序

J2EE应用程序部署:每台应用程序服务器上部署一个应用程序还是多个应用程序2011-04-11 IBM Tom Alcott引言

J2EE 规范对将 J2EE 应用程序打包成一个文件扩展名为 EAR（Enterprise Archive（企业压缩文档））的文件进行了定义，并且规定这些应用程序彼此独立。然而，该规范对于如何最佳部署应用程序却只字未提。您是应该选择在每台应用程序服务器上只部署一个 J2EE 应用程序（EAR 文件）？还是应该在单独一台应用程序服务器上部署多个 J2EE 应用程序（EAR 文件）？

IBM® WebSphere® Application Server支持这两种选择。您应该选择哪种方式？本文探讨了针对这两种选择您需要考虑的许多问题。当您阅读本文时，请记住：一个 EAR 文件可以包括一个或多个 WAR（Web 应用程序压缩文档（Web Application Archive））文件（我们将单独讨论将若干个 WAR 文件打包成一个 EAR 文件的打包准则，本文不涵盖这方面的内容）。

性能

一般来说，一台机器上的进程（应用程序服务器、HTTP 服务器进程等）数越少，在这台机器上发生内存交换、页面调度或上下文切换的可能性就越小。我们期望的结果是操作系统将投入较少的资源用于进程管理，从而使更多的系统资源能够被用于处理应用程序工作负载。这样会改善应用程序性能。

请考虑有 20 个应用程序的情况；在这种情况下，您将创建 20 台应用程序服务器，每个应用程序一台。如果每台服务器都有一个 256 MB 的 Java 堆，那么这些应用程序服务器所要求的内存将至少为 5 GB。在极端情况下，如果大量应用程序被部署到一个节点，这些应用程序服务器将不得不被共享；否则，物理内存将被用光。对于这种情况，CPU 资源也是一个限制因素，尽管通常只有在机器满负载（被定义为 85% 的 CPU 正在使用中）时（因为进程级的内务处理（housekeeping）任务会消耗大量的 CPU 周期），人们才会关注 CPU 资源。当然，通常只有当运行接近一台给定机器的内存极限或 CPU 极限时，进程管理的开销才会成为一个问题。幸运的是，为了顾及工作负载峰值（spike）或停机（outage），大多数组织采用的标准做法是以 50% 的 CPU 利用率运行生产服务器，所以这种极端情况很少发生。

作为一个示例，请考虑一下这个简单的测试案例：两个应用程序在各种不同负载下运行，它们先是各自被部署在一台应用程序服务器上，然后被部署在单独一台应用程序服务器上。所有的测试都在具有 2 GB RAM、运行 iPlanet 6.01 和 WebSphere Application Server 4.03 高级版的 2 CPU HP-UX 服务器上运行。Oracle 8.1.7 数据库单独使用一台服务器。

应用程序	吞吐量（请求数／秒）－两台应用程序服务器	吞吐量（请求数／秒）－一台应用程序服务器
应用程序 A ？ 50% CPU	31.15	36.97
应用程序 B ？ 50% CPU	48.86	53.57
应用程序 A -> 85% CPU	38.22	45.02
应用程序 B -> 85% CPU	57.66	64.58

图 1.

从上面的测试案例中可以看到，只用一台应用程序服务器运行两个应用程序会使性能得到显著改善，改善程度从 9.6% 到 18.7% 不等。尽管每个应用程序都呈现对性能有正面影响，但因每个应用程序施加的工作负载不同，所以改善程度也有所不同。应用程序 A 针对每个请求执行几次数据库选择以及一次更新，而应用程序 B 针对每个请求则只执行一次或两次数据库选择，且每隔 8 到 10 个请求进行一次更新。在任何情况下，对于那些性能很重要并且带有大量应用程序的环境来说，减少应用程序服务器数量可以显著地改善性能。在操作系统资源相同的条件下，将应用程序结合到共享的应用程序服务器中可以得到更好的应用程序性能。不过，每次都要进行测试以确保对于您的环境而言确实能够提高性能，这是很重要的。