Web Sockets + Tomcat/Glassfish + Cluster + Load Balancing - 有哪些选择？

Question

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

通过大量的研究、论坛阅读和邮件列表监控，我已经确定（目前来看）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）的负载平衡技术。我认为这些选项不可靠/冗余，因为您可能会被发送到一个已关闭或已处理比集群中的另一个服务器更多连接的服务器。显然，我知道像轮询DNS这样的东西可以在没有任何兼容性问题的情况下与WebSockets一起使用。

- Nick Williams

Answer 1

我们原本打算使用在标准负载均衡器之后直接拥有Tomcat实例的方法。我们在设置中大量使用SSL。为了简化负载均衡器后面的配置，避免在Web容器中出现不同的SSL/非SSL配置，我们希望在负载均衡器中终止SSL。

然而，我们的负载均衡器的SSL解密硬件存在很多问题。因此，我们最终采用了在Web容器和负载均衡器之间加入Web服务器（nginx）的方式，唯一目的是解密SSL。

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

- K Erlandsson

---

绝对有帮助，而且是我没有考虑过的：SSL。我的理解是，F5和Coyote负载均衡器在TLS/SSL方面都非常出色，因此这不应该对我的考虑产生影响。然而，在这个过程中，这是我应该记住的好事情，以确保基础得到覆盖。（在我标记此回答之前，我会等待看是否有其他人提供更具体的细节。） - Nick Williams

Nginx的SSL比Tomcat的SSL快多少？ - irreputable

@irreputable 对我们来说，这不是一个关于速度的问题。从我们的运维人员所了解的情况来看，这是关于管理便捷性和最小化我们散布证书的位置数量的问题。因此，我不清楚速度方面的情况。 - K Erlandsson

@不可信的，Kristoffer 是对的。您部署私钥和证书的地方越少，就越好。我也听说过（虽然我没有亲身经历过），在 Tomcat 中配置 SSL 真是一件麻烦的事情。 - Nick Williams