第2章 — 基礎設施

設定快取基礎結構

本系列第1章介紹了Publish系統和Dispatcher的基本拓撲。 一組Publish和Dispatcher伺服器可以配置為多種變數,具體取決於預期負載、資料中心的拓撲和所需的故障轉移屬性。

我們將繪製最常見的拓撲圖,並描述其優勢和不足之處。 這份清單 — 當然 — 永遠不可能是全面的。 唯一的限制是你的想像力。

「舊版」設定

在早期,潛在訪客的數量很少,硬體價格昂貴,而Web伺服器不像今天那樣具有業務關鍵性。 常見的設定是在兩個或多個發佈系統之前,讓一個Dispatcher充當負載平衡器和快取。 Dispatcher核心的Apache伺服器非常穩定,而且在大部分設定中,能夠提供相當數量的要求。

「舊版」Dispatcher設定 — 根據現今的標準,並非很常見

「舊版」Dispatcher設定 — 根據現今的標準,並非很常見


 

這是Dispatcher從收到其名稱的位置:基本上是發送請求。 此設定不再常見,因為它無法滿足當前要求的更高效能和穩定性要求。

多腿設定

如今,稍有不同的拓撲更常見。 多條腿拓撲的每個Publish伺服器都有一個Dispatcher。 專用(硬體)負載平衡器位於AEM基礎架構前,將請求發送到以下兩個(或更多)支腳:

現代化的「標準」Dispatcher設定 — 易於處理和維護

現代化的「標準」Dispatcher設定 — 易於處理和維護


 

這種設定的原因如下,

  1. 平均而言,網站提供的流量比過去高得多。 因此,需要擴大「Apache基礎設施」。

  2. 「舊版」設定未在Dispatcher層級提供備援。 如果Apache伺服器關閉,則無法連線整個網站。

  3. Apache伺服器很便宜。 它們基於開放原始碼,而且,如果您有虛擬資料中心,則可以非常快地進行資源調配。

  4. 此設定可為「滾動」或「交錯」更新案例提供簡單的方式。 您只需在Publish 1上安裝新的軟體套件時關閉Dispatcher 1即可。 安裝完成,且您已從內部網路充分經過煙霧測試的Publish 1時,您會清除Dispatcher 1上的快取,並在取下Dispatcher 2以維護Publish 2時重新啟動。

  5. 在此設定中,快取失效變得非常容易且確定。 由於只有一個Publish系統連線至一個Dispatcher,因此只有一個Dispatcher可供使用。 失效的順序和時間很瑣碎。

「橫向擴展」設定

Apache伺服器便宜且易於調配,為什麼不進一步擴展該級別。 為何每個Publish伺服器前面不能有兩個或多個Dispatcher?

「橫向擴展」設定 — 有一些應用領域,但也有限制和警告

「橫向擴展」設定 — 有一些應用領域,但也有限制和警告


 

你絕對可以! 而且,該設定有許多有效的應用方案。 但您也應該考慮到一些限制和複雜性。

失效

每個發佈系統都與多個Dispatcher連線,每個Dispatcher都必須在內容變更時失效。

維護

不言而喻,Dispatcher和Publish系統的初始設定要複雜一些。 但也要記住,「滾動」版本的效果也會稍高一些。 AEM系統可以且必須在執行時更新。 但在主動處理請求時,最好不要這麼做。 通常您只想更新發佈系統的一部分,而其他系統仍會主動提供流量,然後在測試後,切換至其他部分。 如果您很幸運,並且可以在部署過程中訪問負載平衡器,則可以在此處禁用要維護的到伺服器的路由。 如果您位在無法直接存取的共用負載平衡器上,寧可關閉要更新之發佈的Dispatcher。 越多,你就越得關閉。 如果數量很多,而且您計畫頻繁更新,建議您進行一些自動化。 如果您沒有自動化工具,那麼擴展是個壞主意。

在過去的專案中,我們使用不同的秘訣,將Publish系統從負載平衡中移除,而不需要直接存取負載平衡器本身。

負載平衡器通常是「ping」,這是查看伺服器是否正在運行的特定頁。 一般來說,偵測首頁是個小選擇。 但是,如果您想使用ping來指示負載平衡器不平衡流量,則需要選擇其他方法。 您可以建立專用的範本或servlet,這些範本或servlet可設定為以"up""down"回應(在內文中或以http回應代碼的形式回應)。 當然,Dispatcher中不得快取該頁面的回應,因此一律會從Publish系統以新鮮擷取。 現在,如果配置負載平衡器以檢查此模板或servlet,則可以輕鬆讓Publish「假裝」它關閉。 它不屬於負載平衡的一部分,可以更新。

全球分銷

「全球分送」是「橫向擴充」設定,每個發佈系統前面都有多個Dispatcher,現已分送至全球各地,以更貼近客戶並提供更佳效能。 當然,在這種情況下,您沒有中央負載平衡器,而是有基於DNS和地理IP的負載平衡方案。

注意

實際上,您正使用此方法來建置內容分送網路(CDN),因此您應考慮購買現成的CDN解決方案,而非自行建置。 建立和維護自訂CDN並非易事。

水準縮放

即使在本地資料中心,每個發佈系統前面有多個Dispatcher的「向外擴展」拓撲也具有一些優勢。 如果您發現Apache伺服器上由於高流量(和良好的快取命中率)而出現效能瓶頸,並且無法再擴展硬體(通過添加CPU、RAM和更快的磁碟),則可以添加Dispatcher來提高效能。 這稱為「水準縮放」。 不過,這是有限制的,尤其是當您經常使流量失效時。 我們將在下一節中描述其效果。

擴展拓撲的限制

通常,添加代理伺服器應會提高效能。 但是,在某些情況下,添加伺服器實際上會降低效能。 怎麼? 假設您有一個新聞入口網站,每分鐘都會介紹新文章和頁面。 Dispatcher因「自動失效」而失效:每當發佈頁面時,同一網站上快取中的所有頁面都會失效。 這是一項有用的功能 — 我們在此系列的第1章中介紹了此內容 — 但也意味著,當您的網站上經常發生更改時,快取會失效。 如果您的每個Publish例項只有一個Dispatcher,則請求頁面的第一個訪客會觸發該頁面的重新快取。 第二個訪客已取得快取版本。

如果您有兩個Dispatcher,則第二個訪客有50%的機會不快取頁面,而他在再次轉譯該頁面時遇到較大的延遲。 每個Publish有更多Dispatcher會讓情況更糟。 接下來會發生的情況是,發佈伺服器會收到更多負載,因為它必須分別重新呈現每個Dispatcher的頁面。

在頻繁的快取刷新的橫向擴展情況下,效能降低。

在頻繁的快取刷新的橫向擴展情況下,效能降低。


 

緩解過度擴充的問題

您可以考慮為所有Dispatcher使用中央共用儲存,或同步Apache伺服器的檔案系統,以緩解問題。 我們只能提供有限的第一手經驗,但要準備好,這增加了系統的複雜性,並且可以引入全新的錯誤類別。

我們在NFS上進行了一些實驗,但NFS由於內容鎖定而帶來了巨大的效能問題。 這實際上降低了整體效能。

結論 — 建議不讓數個調度程式共用通用檔案系統。

如果您遇到效能問題,請平均放大Publish和Dispatcher,以避免Publisher例項的尖峰負載。 Publish / Dispatcher比率沒有黃金規則,這在很大程度上取決於請求的分發,以及發佈和快取無效判定的頻率。

如果您也擔心訪客體驗的延遲,請考慮使用內容傳送網路、快取重新擷取、搶先快取暖機,依照此系列的第1章節所述設定寬限期,或參考第3部分的進階想法。

「交叉連接」設定

我們現在都看過的另一個設定是「交叉連接」設定:發佈執行個體沒有專用的Dispatcher,但所有Dispatcher都已連線至所有發佈系統。

交叉連接的拓撲:增加冗餘性和更複雜性


 

交叉連接的拓撲:增加冗餘和更複雜。

乍一看,這為相對較小的預算提供了一些更多冗餘。 當其中一個Apache伺服器關閉時,您仍可以有兩個Publish系統執行轉譯工作。 此外,如果其中一個發佈系統當機,您仍有兩個Dispatcher負責處理快取負載。

然而,這是有代價的。

首先,取一條腿進行維修是相當麻煩的。 事實上,這就是這個計畫的目的。以便更具彈性,並盡可能保持運行。 我們已經看到了複雜的維護計畫,來處理這個問題。 先重新設定Dispatcher 2,移除交叉連線。 重新啟動Dispatcher 2。 正在關閉Dispatcher 1、更新Publish 1、…等。 如果長度超過兩條腿,請仔細考慮。 你會得出這樣的結論:它實際上增加了複雜性,增加了成本,是人類錯誤的一個可怕來源。 最好自動化。 因此,最好檢查一下,如果您確實擁有將此自動化任務納入項目計畫的人力資源。 雖然您可以通過此方式節省一些硬體成本,但您可能會在IT員工上花費兩倍。

其次,您可能會在AEM上執行需要登入的使用者應用程式。 您可使用黏著工作階段,以確保一律會從相同AEM例項提供一位使用者,以便您維持該例項的工作階段狀態。 完成此交叉連接設定後,您必須確定黏著工作階段在負載平衡器和Dispatcher上正常運作。 並非不可能 — 但您需要注意這一點,並添加一些額外的配置和測試時間,這同樣可能有助於節省您通過儲存硬體計畫的成本。

結論

我們不建議您將此交叉連接方案作為預設選項。 但是,如果您決定使用它,則需要仔細評估風險和隱藏成本,並計畫將配置自動化納入項目。

下一步

本頁內容