Web套接字+ Tomcat/GlassFish +集羣+負載平衡 - 有哪些選擇？

我正在研究可能使用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，除非您需要冗餘/負載平衡。

所以，這一切使我對這些問題：

是Apache或IIS甚至不再需要在Tomcat/GlassFish的集羣負載平衡？在Tomcat或GlassFish服務器集羣之前放置一個標準的負載均衡器（比如其他任何場景中使用的標準負載均衡器），並放棄中間Web服務器，這樣做效率會更高嗎？或者是否還有一些技術原因，標準負載平衡器不能與TC/GF一起使用？假設可以使用標準負載平衡器，可以簡單地找到一個支持WebSocket（如Coyote）並使用它的程序。
如果一個標準的負載平衡器不能與Tomcat/GlassFish一起工作，還有什麼其他的選擇？如何使用Java EE來提高性能和可靠的WebSocket技術？

買者：我不想考慮僅限於啞循環協議（如循環DNS）負載平衡技術。我不認爲這些選項是可靠的/冗餘的，因爲人們可以很容易地將它們發送到服務器已關閉或已經處理比羣集中的另一臺服務器更多數量的連接。很明顯，我知道像循環DNS這樣的東西可以很容易地與WebSockets一起使用，沒有任何兼容性問題。

來源

2012-11-14 Nick Williams

我們打算使用一種方法，將Tomcat實例直接放在標準負載均衡器之後。我們在設置中大量使用SSL。爲了讓我們的負載均衡器保持簡單並避免在我們的Web容器中使用SSL/SSL的不同配置，我們希望在我們的負載均衡器中終止SSL。

但是，我們負載均衡器的SSL解密硬件相當麻煩。因此，我們最終在web容器和我們的負載平衡器之間建立了web服務器（nginx），僅用於解密SSL。

這是一個適用於我們但值得記住的特例。除此之外，我沒有看到在負載平衡器和Web容器之間保留Web服務器的原因。負載平衡器應該適用於web容器。旨在簡化並減少設置中的不同組件。

來源

2012-11-14 19:52:54

絕對有幫助，我沒有考慮過的東西：SSL。我的理解是，F5和Coyote負載平衡器在TLS/SSL方面都很好，所以這不應該影響我在這裏的考慮。然而，在這個過程中，我應該牢記這是一件好事，以確保覆蓋基地。（我會拭目以待，看看有沒有其他人提出更具體的細節，然後我會回答這個問題。） –

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

@irreputable對我們來說，這不是一個關於速度的問題。從我從操作人員瞭解的情況來看，這是關於管理的簡易性以及將我們分散在各地的地點數量減至最少。因此我不知道速度。 –

Web套接字+ Tomcat/GlassFish +集羣+負載平衡 - 有哪些選擇？

回答

相關問題