本文主要介紹如何理解 Java 應用的擴展方式以及不同類型的擴展技術和具體技巧，介紹一些有關 Java 企業(yè)級應用的一般擴展策略。

老實說，“可擴展性”是個全面且詳盡的話題，而且往往得不到充分理解。人們通常認為可擴展性等同于高可用性，筆者見過編程新手和架構師“老手”都建議將集群作為可擴展性和高可用性的解決方案。建議確實沒錯，但問題是，人們通常是通過互聯網搜索，而非實際理解應用本身的情況來實現集群。

筆者并未自稱“專家”，只想通過這篇文章介紹一些有關 Java 企業(yè)級應用的一般擴展策略。

問題

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

擴展類型

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

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

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

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

高可用性不等于可擴展性

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

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

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

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

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

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

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

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

會話保持

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

集群復制

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

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

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

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

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

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

最后的邊界：分布式內存中緩存

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

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

分布式不等于重復式

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

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

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