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

Question

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

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

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

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

1. 在 Tomcat/GlassFish 集群中是否还需要 Apache 或 IIS 来平衡负载？ 简单地将标准负载平衡器（就像您在任何其他场景中使用的那样）放置在 Tomcat 或 GlassFish 服务器集群前面并完全放弃中间 Web 服务器，难道不是同样有效（或更多？）？ 或者标准负载平衡器不能与 TC/GF 一起工作是否还有一些技术原因？ 假设可以使用标准负载均衡器，您可以简单地找到一个支持 WebSockets 的负载均衡器（如 Coyote）并使用它。
2. 如果标准负载平衡器根本无法与 Tomcat/GlassFish 一起使用，还有哪些其他选择？ 如何使用 Java EE 实现高性能和可靠的 WebSocket 技术？

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

Answer 1

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

然而，我们的负载平衡器的 SSL 解密硬件有很多问题。 因此，我们最终在我们的 Web 容器和我们的负载平衡器之间使用了 Web 服务器（nginx），其唯一目的是解密 SSL。

这是一个适用于我们的特殊情况，但值得牢记。 除此之外，我认为没有理由在负载均衡器和 Web 容器之间保留 Web 服务器。 负载均衡器应该可以很好地与 Web 容器配合使用。 力求简单并尽量减少设置中的不同组件。