如何理解Java 企業(yè)級應用的可擴展性

這篇文章主要介紹“如何理解Java 企業(yè)級應用的可擴展性”，在日常操作中，相信很多人在如何理解Java 企業(yè)級應用的可擴展性問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何理解Java 企業(yè)級應用的可擴展性”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

問題

可擴展性并非 Java  企業(yè)級平臺規(guī)范內(nèi)的標準組件。相關(guān)技術(shù)通常因供應商（應用服務器）而異，并且往往需要使用不止一款產(chǎn)品（應用服務器本身除外）。正因如此，設(shè)計可擴展的  Java 企業(yè)級應用才會有些棘手，要完成任務，往往不僅沒有可以參照的實例，而且要求我們必須徹徹底底地理解應用。

擴展類型

筆者確信你們不是***次看到這些內(nèi)容。擴展一般分為兩大類：縱向擴展，和橫向擴展。

擴展的***個自然階段是縱向擴展。

• 縱向擴展：包括給服務器增加更多資源，例如內(nèi)存 (RAM)、磁盤空間、處理器等。這在某些方案中具備實用價值，但經(jīng)過特定時間點后就會發(fā)現(xiàn)，這種擴展費用高昂，不如借助橫向擴展。

• 橫向擴展：在這個過程中會增加更多機器或額外的服務器實例/節(jié)點，這也叫做集群（Clustering），因為所有服務器是作為一個集體或集群一起運行的。

高可用性不等于可擴展性

系統(tǒng)高度可用（擁有多個服務器節(jié)點以方便故障轉(zhuǎn)移），并不表示系統(tǒng)可擴展。高可用性只是意味著，如果當前處理節(jié)點崩潰，請求會傳遞或轉(zhuǎn)移到集群中的 另一個節(jié)點，以便從開始處繼續(xù)?？蓴U展性則是通過增加可用資源（內(nèi)存、處理器等）而提升系統(tǒng)特定性能（例如用戶數(shù)量、吞吐量、響應時間）的能力，即使將失 敗請求傳遞到另一個節(jié)點，也無法保證應用會在這種場景中正確運行（原因我們會在下面揭曉）。

下面我們來了解一些關(guān)于可擴展性的觀點和相關(guān)討論。

讓橫向擴展的集群達到負載均衡

假設(shè)您已經(jīng)縱向擴展至***容量，現(xiàn)在又用多個節(jié)點形成集群，將系統(tǒng)進行了橫向擴展。接下來您要做的可能是在集群基礎(chǔ)架構(gòu)前放置一臺負載均衡器，讓負載分散在集群各部分之間（如果要詳細了解負載均衡，大家可以參考其他方面的資料，在這里我們重點還是說擴展問題）。

應用有狀態(tài)還是無狀態(tài)？

現(xiàn)在你已經(jīng)橫向擴展了，這就夠了嗎？如果你的應用無狀態(tài)，即應用邏輯在處理請求時不依靠現(xiàn)有服務器狀態(tài)，則橫向擴展已經(jīng)足夠。

但如果應用具有 HTTP 會話對象、有狀態(tài) EJB、會話域 bean (CDI、JSF)  等組件時，又會怎樣？這取決于具體客戶（具體來說，即調(diào)用線程），存儲特定狀態(tài)并依靠當前顯示的狀態(tài)來執(zhí)行請求（例如，HTTP  會話對象可能會存儲用戶的身份驗證狀態(tài)、購物車信息等）。

在橫向擴展或集群式應用中，節(jié)點的任何集群都可能為后續(xù)請求提供服務。如果***請求的 JVM 實例處的狀態(tài)數(shù)據(jù)沒有被接收，其他節(jié)點會如何處理請求？

會話保持

會話保持配置可在負載均衡器層面上完成，確保來自特定客戶/終端用戶的請求始終被轉(zhuǎn)發(fā)到同一個實例/應用服務器節(jié)點，即維持服務器親和力。這樣，我 們就緩解了所需狀態(tài)無法顯示的問題。但這里有個陷阱 –  如果節(jié)點崩潰怎么辦？狀態(tài)會被破壞，用戶會被轉(zhuǎn)至服務器請求處理所依賴的、但不具備現(xiàn)有狀態(tài)的實例。

集群復制

為解決上述問題，您可對應用服務器集群機制進行配置，以支持有狀態(tài)組件的復制，借此可確保 HTTP  會話數(shù)據(jù)（和其他有狀態(tài)對象）顯示在所有服務器實例上。如此一來，終端用戶請求便可轉(zhuǎn)至任何服務器節(jié)點，即使某個服務器實例崩潰或不可用，集群中的其他任 何節(jié)點都能夠處理請求?，F(xiàn)在您的集群就不是一般集群了，而是復制集群。

集群復制特定于 Java 企業(yè)級容器/應用服務器，***查閱相關(guān)文檔，了解如何復制集群。一般而言，大多數(shù)應用服務都支持 Java 企業(yè)級組件（如有狀態(tài)和無狀態(tài)的 EJB、HTTP 會話、JMS 隊列等）集群。

然而這造成了另一個問題 – 應用服務器中的每一個節(jié)點都處理會話數(shù)據(jù)，導致 JVM 堆內(nèi)存越來越多，因此垃圾回收也越來越頻繁，另外，復制集群時還會消耗一定的處理能力。

有狀態(tài)組件的外部存儲

在另一層存儲會話數(shù)據(jù)和有狀態(tài)的對象，這可以借助 RDBMS 實現(xiàn)，大多數(shù)應用服務器本身就支持這一功能。

你可能已經(jīng)注意到了，我們已經(jīng)將存儲從內(nèi)存層轉(zhuǎn)移到持久層 –  一天工作結(jié)束時，你可能會遇到由數(shù)據(jù)庫導致的擴展問題。不是說這一定會發(fā)生，但數(shù)據(jù)庫確實可能因為應用而過載，而后逐漸延時（例如在故障轉(zhuǎn)移時）。設(shè)想一 下，從數(shù)據(jù)庫中再現(xiàn)整個用戶會話狀態(tài)以便用在另一個集群實例中，不僅耗費大量時間，還會影響峰值負載下的終端用戶體驗。

***的邊界：分布式內(nèi)存中緩存

這是***的邊界，至少在我看來如此，因為它把我們帶回了內(nèi)存方法。沒有比這更好的辦法了！Oracle Coherence、Hazelcast  這類產(chǎn)品或其他任何分布式緩存/內(nèi)存網(wǎng)格產(chǎn)品可用于清理有狀態(tài)的狀態(tài)存儲和復制/分布 – 這就是緩存層。好的一面是這些產(chǎn)品大多默認支持 HTTP  會話存儲。

這種結(jié)構(gòu)設(shè)置意味著，應用服務器的重啟不會影響現(xiàn)有用戶會話 – 給系統(tǒng)打補丁而不造成宕機和終端用戶斷電（雖然并不像聽上去那么容易，但顯然是個辦法?。?，這始終是好事?？偟膩碚f，其理念是：應用層和 web 會話緩存層可獨立運行和擴展，彼此不受干擾。

分布式不等于重復式

這兩個詞之間存在巨大差異，就緩存層而言，理解其中的差異是極為關(guān)鍵的。兩者各有長短：

• 分布式：緩存共享數(shù)據(jù)的各個部分，即數(shù)據(jù)集被分在各緩存集群節(jié)點之間（利用與產(chǎn)品特定的算法）。

• 重復式：所有緩存節(jié)點都擁有所有數(shù)據(jù)，即每個緩存服務器都包含整個數(shù)據(jù)集的一份復本。

到此，關(guān)于“如何理解Java 企業(yè)級應用的可擴展性”的學習就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>