我正在开发一个Java SE 7/Java EE 6应用程序，该应用程序可能使用Tomcat7或Glassfish 3.1(可能是Glassfish，但尚未决定)。该应用程序将利用最近在所有主要浏览器中广泛采用的新WebSockets技术。
通过大量的研究、论坛阅读和邮件列表监控，我确定(目前，AFAICT)mod_jk/isapi_redirect和mod_proxy都不可靠(或根本不)支持WebSockets。由于这是Tomcat或GlassFish集群中负载平衡/引导流量的两种久经考验的方法，因此这显然是一个问题。
然而，另一方面，Tomcat和GlassFish都有内置的web服务器，人们普遍认为它们在提供静态内容方面与Apache或IIS一样高效，因此通常不建议将Apache或IIS放在其中一个服务器之前，除非您需要冗余/负载平衡。
所以，所有这些都让我想到了这些问题：
- 在Tomcat/GlassFish集群中是否还需要Apache或IIS来实现负载平衡？简单地在Tomcat或GlassFish服务器集群前面放置一个标准负载均衡器(就像在任何其他场景中使用的一样)，并完全放弃中间的web服务器，这不是同样有效吗？或者，标准负载平衡器不能与TC/GF一起工作还有一些技术原因吗？假设可以使用标准负载均衡器，那么只需找到一个支持WebSockets(如Coyote)的负载均衡器并使用它
- 如果标准负载均衡器根本无法与Tomcat/GlassFish配合使用，还有什么其他选项？如何使用Java EE实现高性能、可靠的WebSocket技术
注意事项：我不喜欢考虑仅限于哑循环协议的负载平衡技术(如循环DNS)。我不认为这些选项是可靠/冗余的，因为其中一个选项可以很容易地发送到一个服务器，该服务器已停机或已经处理了比群集中另一个服务器多得多的连接。很明显，我知道像Round Robin DNS这样的东西可以很容易地与WebSockets一起使用，而不会有任何兼容性问题。
我们将使用一种方法，将Tomcat实例直接放在标准负载均衡器之后。我们在设置中大量使用SSL。为了在我们的负载平衡器后面保持简单，并避免在我们的web容器中对SSL/no-SSL进行不同的配置，我们希望在负载平衡器中终止SSL。
然而，我们的负载均衡器的SSL解密硬件非常有缺陷。因此，我们最终在web容器和负载均衡器之间使用了web服务器(nginx)，其唯一目的是解密SSL。
这是一个特殊情况，适用于我们，但值得记住。除此之外，我看不出有什么理由在负载均衡器和web容器之间保留web服务器。负载平衡器应该可以与web容器一起正常工作。目标是简化并最小化设置中的不同组件。