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

umodi 发布于 2019-02-11 glassfish 最后更新 2019-02-11 21:14 6 浏览

我正在研究可能使用Tomcat 7或Glassfish 3.1(可能是GlassFish,但尚未决定)的Java SE 7 / Java EE 6应用程序。该应用程序将利用最近在所有主流浏览器中广泛采用的新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一起使用?假设可以使用标准的负载平衡器,可以简单地找到一个支持WebSocket(如Coyote)并使用它的程序。
  2. 如果标准负载均衡器不能与Tomcat / GlassFish一起使用,那么还有哪些其他选项?如何使用Java EE实现高性能和可靠的WebSocket技术?
警告:我不想考虑仅限于哑循环协议(例如循环DNS)的负载平衡技术。我不认为这些选项是可靠的/冗余的,因为人们可以很容易地将它们发送到服务器已关闭或已经处理比群集中的另一台服务器更多数量的连接。很明显,我知道像循环DNS这样的东西可以很容易地与WebSockets一起使用,没有任何兼容性问题。
已邀请:

iest

赞同来自:

我们将使用一种方法,在标准负载均衡器之后直接使用我们的Tomcat实例。我们在设置中大量使用SSL。为了简化我们的负载均衡器并避免在我们的Web容器中使用SSL /无SSL的不同配置,我们希望在负载均衡器中终止SSL。 但是,我们的负载平衡器的SSL解密硬件非常错误。因此,我们最终在Web容器和负载均衡器之间使用Web服务器(nginx),其唯一目的是解密SSL。 这是一个适用于我们的特殊情况,但值得记住。除此之外,我没有理由在您的负载均衡器和Web容器之间保留Web服务器。负载平衡器应该可以正常使用Web容器。旨在简化并最小化您的设置中的不同组件。