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