3

我正在开发一个 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 一起使用，而没有任何兼容性问题。

4

1 回答 1

3

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

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

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

于 2012-11-14T19:52:54.553 回答