Web套接字+ Tomcat / Glassfish +集群+负载平衡 - 有哪些选择？

Question

我正在开发一个可能使用Tomcat 7或Glassfish 3.1的Java SE 7 / Java EE 6应用程序（可能是GlassFish，但尚未确定）。该应用程序将利用最近在所有主流浏览器中广泛采用的新WebSockets技术。

通过大量研究，论坛阅读和邮件列表监控，我已经确定（目前，AFAICT）mod_jk / isapi_redirect和mod_proxy都不可靠（或根本不）支持WebSockets。由于这些是在Tomcat或GlassFish集群中负载平衡/引导流量的两种久经考验的方法，这显然是一个问题。

另一方面，Tomcat和GlassFish都有内置的Web服务器，这些服务器被广泛宣传为与Apache或IIS一样高效地提供静态内容，因此通常不建议放置Apache或IIS在其中一台服务器前面，除非您需要冗余/负载平衡。

所以，所有这些都让我想到了这些问题：

1. 是否需要Apache或IIS才能在Tomcat / GlassFish集群中进行负载平衡？简单地将标准负载均衡器（如您将在任何其他场景中使用的那样）放置在Tomcat或GlassFish服务器集群前面并放弃中间Web服务器，这不是那么有效（或者更重要吗？）？或者是否还有一些技术原因导致标准负载平衡器无法与TC / GF配合使用？假设可以使用标准负载均衡器，可以简单地找到一个支持WebSockets（如Coyote）并使用它。
2. 如果标准负载均衡器不能与Tomcat / GlassFish一起使用，还有哪些其他选项？如何使用Java EE实现高性能和可靠的WebSocket技术？

警告：我不想考虑仅限于哑循环协议（例如Round-Robin DNS）的负载均衡技术。我不认为这些选项是可靠的/冗余的，因为可以很容易地将这些选项发送到已关闭或已经处理比集群中的另一个服务器大得多的连接的服务器。显然，我知道像Round-Robin DNS这样的东西很容易与WebSockets一起使用而没有任何兼容性问题。

Answer 1

我们将使用一种方法，在标准负载均衡器之后直接使用我们的Tomcat实例。我们在设置中大量使用SSL。为了简化我们的负载均衡器并避免在我们的Web容器中使用SSL /无SSL的不同配置，我们希望在负载均衡器中终止SSL。

然而，我们的负载平衡器的SSL解密硬件非常错误。因此，我们最终在Web容器和负载均衡器之间使用Web服务器（nginx），其唯一目的是解密SSL。

这是一个适用于我们的特殊情况，但值得记住。除此之外，我没有理由在您的负载均衡器和Web容器之间保留Web服务器。负载平衡器应该可以正常使用Web容器。旨在简化并最小化设置中的不同组件。