老實說，“可擴展性”是個全面且詳盡的話題，而且往往得不到充分理解。人們通常認為可擴展性等同于高可用性，筆者見過編程新手和架構(gòu)師“老手”都建 議將集群作為可擴展性和高可用性的解決方案。建議確實沒錯，但問題是，人們通常是通過互聯(lián)網(wǎng)搜索，而非實際理解應用本身的情況來實現(xiàn)集群。
筆者并未自稱“專家”，只想通過這篇文章介紹一些有關(guān) Java 企業(yè)級應用的一般擴展策略。
問題
可擴展性并非 Java 企業(yè)級平臺規(guī)范內(nèi)的標準組件。相關(guān)技術(shù)通常因供應商（應用服務(wù)器）而異，并且往往需要使用不止一款產(chǎn)品（應用服務(wù)器本身除外）。正因如此，設(shè)計可擴展的 Java 企業(yè)級應用才會有些棘手，要完成任務(wù)，往往不僅沒有可以參照的實例，而且要求我們必須徹徹底底地理解應用。
擴展類型
筆者確信你們不是第一次看到這些內(nèi)容。擴展一般分為兩大類：縱向擴展，和橫向擴展。
擴展的第一個自然階段是縱向擴展。
縱向擴展：包括給服務(wù)器增加更多資源，例如內(nèi)存 (RAM)、磁盤空間、處理器等。這在某些方案中具備實用價值，但經(jīng)過特定時間點后就會發(fā)現(xiàn)，這種擴展費用高昂，不如借助橫向擴展。
橫向擴展：在這個過程中會增加更多機器或額外的服務(wù)器實例/節(jié)點，這也叫做集群（Clustering），因為所有服務(wù)器是作為一個集體或集群一起運行的。
高可用性不等于可擴展性
系統(tǒng)高度可用（擁有多個服務(wù)器節(jié)點以方便故障轉(zhuǎn)移），并不表示系統(tǒng)可擴展。高可用性只是意味著，如果當前處理節(jié)點崩潰，請求會傳遞或轉(zhuǎn)移到集群中的 另一個節(jié)點，以便從開始處繼續(xù)。可擴展性則是通過增加可用資源（內(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)有服務(wù)器狀態(tài)，則橫向擴展已經(jīng)足夠。
但如果應用具有 HTTP 會話對象、有狀態(tài) EJB、會話域 bean (CDI、JSF) 等組件時，又會怎樣？這取決于具體客戶（具體來說，即調(diào)用線程），存儲特定狀態(tài)并依靠當前顯示的狀態(tài)來執(zhí)行請求（例如，HTTP 會話對象可能會存儲用戶的身份驗證狀態(tài)、購物車信息等）。
在橫向擴展或集群式應用中，節(jié)點的任何集群都可能為后續(xù)請求提供服務(wù)。如果首個請求的 JVM 實例處的狀態(tài)數(shù)據(jù)沒有被接收，其他節(jié)點會如何處理請求？
會話保持
會話保持配置可在負載均衡器層面上完成，確保來自特定客戶/終端用戶的請求始終被轉(zhuǎn)發(fā)到同一個實例/應用服務(wù)器節(jié)點，即維持服務(wù)器親和力。這樣，我 們就緩解了所需狀態(tài)無法顯示的問題。但這里有個陷阱 – 如果節(jié)點崩潰怎么辦？狀態(tài)會被破壞，用戶會被轉(zhuǎn)至服務(wù)器請求處理所依賴的、但不具備現(xiàn)有狀態(tài)的實例。
集群復制
為解決上述問題，您可對應用服務(wù)器集群機制進行配置，以支持有狀態(tài)組件的復制，借此可確保 HTTP 會話數(shù)據(jù)（和其他有狀態(tài)對象）顯示在所有服務(wù)器實例上。如此一來，終端用戶請求便可轉(zhuǎn)至任何服務(wù)器節(jié)點，即使某個服務(wù)器實例崩潰或不可用，集群中的其他任 何節(jié)點都能夠處理請求。現(xiàn)在您的集群就不是一般集群了，而是復制集群。
集群復制特定于 Java 企業(yè)級容器/應用服務(wù)器，最好查閱相關(guān)文檔，了解如何復制集群。一般而言，大多數(shù)應用服務(wù)都支持 Java 企業(yè)級組件（如有狀態(tài)和無狀態(tài)的 EJB、HTTP 會話、JMS 隊列等）集群。
然而這造成了另一個問題 – 應用服務(wù)器中的每一個節(jié)點都處理會話數(shù)據(jù)，導致 JVM 堆內(nèi)存越來越多，因此垃圾回收也越來越頻繁，另外，復制集群時還會消耗一定的處理能力。
有狀態(tài)組件的外部存儲
在另一層存儲會話數(shù)據(jù)和有狀態(tài)的對象，這可以借助 RDBMS 實現(xiàn)，大多數(shù)應用服務(wù)器本身就支持這一功能。
你可能已經(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è)置意味著，應用服務(wù)器的重啟不會影響現(xiàn)有用戶會話 – 給系統(tǒng)打補丁而不造成宕機和終端用戶斷電（雖然并不像聽上去那么容易，但顯然是個辦法！），這始終是好事。總的來說，其理念是：應用層和 web 會話緩存層可獨立運行和擴展，彼此不受干擾。
分布式不等于重復式
這兩個詞之間存在巨大差異，就緩存層而言，理解其中的差異是極為關(guān)鍵的。兩者各有長短：
分布式：緩存共享數(shù)據(jù)的各個部分，即數(shù)據(jù)集被分在各緩存集群節(jié)點之間（利用與產(chǎn)品特定的算法）。
重復式：所有緩存節(jié)點都擁有所有數(shù)據(jù)，即每個緩存服務(wù)器都包含整個數(shù)據(jù)集的一份復本。
京公網(wǎng)安備 11010502049343號