老實說，“可擴展性”是一個詳盡的主題，并且通常沒有被很好地理解。 通常，它被假定與高可用性相同。 我已經看到新手程序員和“經驗豐富”的建筑師都建議將“ 集群 ”作為可伸縮性和HA的解決方案。 它實際上沒有任何問題，但是問題在于，它通常是通過谷歌搜索來完成的，而不是實際了解應用程序本身;-)

我只是寫這篇文章并不聲稱自己是“專家” ；-)它只是簡要地提出了一些用于擴展Java EE應用程序的策略。

問題…

可伸縮性不是Java EE平臺規范中的標準化組件。 相關技術大多是特定于供應商（應用程序服務器）的，通常涉及使用多個產品（除了應用程序服務器本身）。 這就是為什么將Java EE應用程序設計為可伸縮的可能會有些棘手。 沒有“菜譜”可以幫您實現成功。 真正需要從內而外了解應用程序。

縮放類型

我相信這不是您第一次閱讀本文。 通常，擴展分為兩大類–向上擴展，向外擴展

擴大規模的第一步自然就是擴大規模

• 向上擴展 ：這涉及向服務器中添加更多資源，例如RAM，磁盤空間，處理器等。在某些情況下這很有用，但在特定時間點之后會變得昂貴，您會發現最好采用向外擴展
• 向外擴展 ：在此過程中，將添加更多計算機或其他服務器實例/節點。 這也稱為群集，因為所有服務器都應該協同工作（作為一個組或群集），并且對客戶端是透明的。

高可用性！=可擴展性

是! 僅僅因為系統具有高可用性（通過讓多個服務器節點進行故障轉移），并不意味著它也具有可伸縮性。 HA只是意味著，如果當前的處理節點崩潰，該請求將被傳遞或故障轉移到集群中的另一個節點，以便它可以從其開始的地方繼續進行–差不多！ 可伸縮性是通過增加可用資源（RAM，處理器等）來改善系統特定特性（例如，用戶數量，吞吐量，性能）的能力。即使失敗的請求被傳遞到另一個節點，您也不能保證應用程序在這種情況下將正常運行（繼續閱讀以了解原因）

讓我們看一些選項和相關討論

對擴展的集群進行

假設您已擴展到最大容量，現在通過讓多個節點組成集群來擴展系統。 現在，您要做的就是將負載均衡器放在群集基礎結構的前面，以便您可以在群集成員之間分配負載。 由于除基本知識之外我沒有太多的見識，因此未詳細介紹負載平衡 ：-)但是知道這一點對于本文足夠了

我的應用程序是

好了，現在您可以橫向擴展了–夠了嗎？ 如果您的應用程序是無狀態的，則可以進行橫向擴展，即您的應用程序邏輯不依賴于現有服務器狀態來處理請求，例如JAX-RS上的RESTful API后端，基于消息的應用程序將遠程EJB作為入口，在后面使用JMS地面等

如果您的應用程序包含HTTP會話對象，有狀態EJB，會話范圍的Bean（CDI，JSF）等組件，該怎么辦？ 這些特定于客戶端（更具體地講，是調用線程），存儲特定狀態，并依賴于該狀態存在以便能夠執行請求，例如HTTP會話對象可能存儲用戶的身份驗證狀態，購物車信息等

在橫向擴展或群集應用程序中，節點中的任何群集都可以滿足后續請求。 在沒有第一個請求傳遞到的實例的JVM中創建的狀態數據的情況下，另一個節點將如何處理請求？

您好粘性會話 ！

可以在負載均衡器級別上完成粘性會話配置，以確保始終將來自特定客戶端/最終用戶的請求轉發到同一實例/應用程序服務器節點，即保持服務器親和力 。 因此，我們緩解了所需狀態不存在的問題。 但是這里有一個陷阱- 如果該節點崩潰怎么辦？ 該狀態將被破壞，并且用戶將被轉發到服務器端請求處理所不依賴的現有狀態的實例。

輸入

為了解決上述問題，您可以配置應用程序服務器群集機制以支持有狀態組件的復制。 這樣，您可以確保所有服務器實例上都存在HTTP會話數據（和其他有狀態對象）。 因此，最終用戶請求現在可以轉發到任何服務器節點。 即使服務器實例崩潰或不可用，群集中的任何其他節點也可以處理該請求。 現在，您的群集不是普通群集，而是一個復制群集

群集復制特定于您的Java EE容器/應用服務器，最好參考其相關文檔以了解具體操作。 通常，大多數應用服務器支持Java EE組件的集群，例如有狀態和無狀態EJB，HTTP會話，JMS隊列等。

但是，這帶來了另一個問題 –現在，應用程序服務器中的每個節點都處理會話數據，從而導致更多的JVM堆存儲并因此產生了更多的垃圾回收。 而且，復制中也花費了很多處理能力

有狀態組件的

通過將會話數據和有狀態對象存儲在另一層中，可以避免這種情況。 您可以使用RDBMS進行操作。 同樣，大多數應用服務器都對此提供了內置支持。

如果您注意到了，我們已經將存儲從內存層轉移到了持久層–最終，由于數據庫的原因，您可能最終會面臨可擴展性問題。 我并不是說肯定會發生這種情況，但是在某些情況下（例如在發生故障轉移的情況下），您的數據庫可能會過載，并且延遲可能會增加，具體取決于您的應用程序，請考慮從該數據庫重新創建整個用戶會話狀態，以便在另一個數據庫中使用群集實例–這可能會花費一些時間，并在高峰負載期間影響最終用戶的體驗。

最后的領域：

這是最后的領域-至少在我看來，因為這使我們回到了內存中方法。 than，沒有比這更好的了！ 可以使用諸如Oracle Coherence，Hazelcast或任何其他分布式緩存/內存網格產品之類的產品來卸載狀態存儲和復制/分發的狀態–這不過是緩存層而已。 好消息是，其中大多數產品都將HTTP會話存儲作為默認功能支持

這種體系結構設置意味著應用程序服務器重新啟動不會影響現有的用戶會話-在不停機和最終用戶停機的情況下對系統進行修補總是很不錯的（雖然聽起來并不那么容易，但肯定是可以選擇的！）。 通常，此想法是應用程序層和Web會話緩存層可以獨立工作和擴展，并且不會相互干擾。

已分發！=已復制

這些詞之間有很大的差異，因此了解緩存層的差異至關重要。 兩者各有利弊

• 分布式 ：緩存成員共享數據，即數據集在緩存集群節點之間分區（使用特定于產品的算法）
• 復制的 ：所有緩存節點都具有所有數據，即每個緩存服務器都包含整個數據集的副本。

進一步閱讀（主要針對Weblogic）

• 集群配置
• 用于會話持久性的RDBMS配置
• 分布式Web會話復制– Oracle Coherence ， Hazelcast
• 高可擴展性 –巨大的資源！

在我退出之前...

• 并非每個Java EE應用程序都要求高/極端可伸縮性。 但是，如果您打算構建互聯網/面向公眾的應用程序，將其納入設計絕對是有用的
• 對于希望利用云平臺（主要是PaaS）（例如自動彈性（經濟可行！）和HA）的應用程序，可伸縮設計是必須的
• 不難發現有狀態應用程序在擴展方面通常更具挑戰性。 完全的“無國籍”可能是不可能的，但人們應該為此努力

隨時分享用于擴展Java EE應用程序的技巧和技術。

干杯!

翻譯自: https://www.javacodegeeks.com/2015/10/basics-of-scaling-java-ee-applications.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的扩展Java EE应用程序的基础的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。