2012-11-14 19 views
3

我正在研究可能使用Tomcat 7或Glassfish 3.1(可能是GlassFish,但尚未确定)的Java SE 7/Java EE 6应用程序。该应用程序将利用最近在所有主流浏览器中广泛采用的新WebSockets技术。Web套接字+ Tomcat/GlassFish +集群+负载平衡 - 有哪些选择?

通过大量的研究,阅读论坛和邮件列表监视我已确定(目前,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一起使用,没有任何兼容性问题。

回答

3

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

但是,我们负载均衡器的SSL解密硬件相当麻烦。因此,我们最终在web容器和我们的负载平衡器之间建立了web服务器(nginx),仅用于解密SSL。

这是一个适用于我们但值得记住的特例。除此之外,我没有看到在负载平衡器和Web容器之间保留Web服务器的原因。负载平衡器应该适用于web容器。旨在简化并减少设置中的不同组件。

+0

绝对有帮助,我没有考虑过的东西:SSL。我的理解是,F5和Coyote负载平衡器在TLS/SSL方面都很好,所以这不应该影响我在这里的考虑。然而,在这个过程中,我应该牢记这是一件好事,以确保覆盖基地。 (我会拭目以待,看看有没有其他人提出更具体的细节,然后我会回答这个问题。) –

+0

nginx的SSL比tomcat的SSL要快多少? – irreputable

+1

@irreputable对我们来说,这不是一个关于速度的问题。从我从操作人员了解的情况来看,这是关于管理的简易性以及将我们分散在各地的地点数量减至最少。因此我不知道速度。 –