第2章 — 基礎結構
設定快取基礎結構
我們在本系列的第1章中介紹了Publish系統的基本拓撲和Dispatcher。 一組Publish和Dispatcher伺服器可設定成許多變數，視預期的負載、資料中心的拓撲以及所需的容錯移轉屬性而定。
我們將草擬最常見的拓撲，並描述優點及不足之處。 這份清單（當然）永遠不可能完整。 唯一的限制是想像力。
「舊版」設定
在早期，潛在的訪客人數不多，硬體昂貴，而且網頁伺服器並不像現在這樣被視為業務關鍵型伺服器。 常見的設定是在兩個或更多Publish系統前，將一個Dispatcher作為負載平衡器和快取。 Dispatcher核心的Apache伺服器非常穩定，在大多數設定下，都能滿足一般的需求。
「舊版」Dispatcher設定 — 以目前的標準來看，並不常見
這是Dispatcher從收到其名稱的位置：它基本上是在傳送請求。 此設定已不再很常見，因為它無法滿足現今對效能和穩定性的更高要求。
多足式設定
現今稍有不同的拓撲比較常見。 多足拓撲的每部Publish伺服器會有一個Dispatcher。 專用的（硬體）負載平衡器位於AEM基礎結構前面，將請求分派給這兩個（或多個）分支：
現代「標準」Dispatcher設定 — 易於處理和維護
以下是這類設定的原因，
-
網站平均提供的流量比過去多很多。 因此，需要擴展「Apache基礎結構」。
-
「舊版」設定未提供Dispatcher層級的備援。 如果Apache Server發生問題，便無法連線整個網站。
-
Apache伺服器價格低廉。 這些服務是以開放原始碼為基礎，而且只要您擁有虛擬資料中心，就能快速完成布建作業。
-
此設定可讓您以簡單的方式進行「滾動」或「交錯」更新案例。 只要在Dispatcher 1上安裝新的軟體套件時關閉Publish 1即可。 當安裝完成時，且您已透過內部網路進行充分煙霧測試Publish 1，您可清除Dispatcher 1上的快取，然後重新啟動，同時取下Dispatcher 2以維護Publish 2。
-
在此設定中，快取失效變得非常容易且具有確定性。 由於只有一個Publish系統連線至一個Dispatcher，因此只有一個Dispatcher要失效。 失效的順序和時機微不足道。
「向外擴展」設定
Apache Server價格低廉且易於布建，何不進一步推出該層級的擴充功能。 為何每個Publish伺服器前面沒有兩個或更多Dispatcher？
「向外擴充」設定 — 有一些應用程式區域，但也有限制和警告
您絕對可以這樣做！ 對於該設定，有許多有效的應用程式情境。 但也有一些限制和複雜性值得考慮。
失效
每個Publish系統都會連線至多個Dispatcher，每個系統都必須在內容變更時失效。
維護
不用說，Dispatcher和Publish系統的初始設定比較複雜。 但也請記住，「滾動」版本的工作量也更高。 AEM系統在執行時可以而且必須更新。 但是明智的做法是在他們主動處理請求時不要這麼做。 通常您只想更新部分Publish系統，而其他系統則仍在主動提供流量，然後在測試後切換至其他部分。 如果您很幸運，而且可以在部署過程中存取負載平衡器，您可以在此處停用進行維護的伺服器路由。 如果您位在無法直接存取的共用負載平衡器上，寧可關閉要更新的Publish的Dispatcher。 位置愈多，您必須關機的次數就愈多。 如果數量很大並且您計畫經常更新，建議使用一些自動化功能。 如果您沒有自動化工具，繼續擴充無論如何都不是個好主意。
在過去的專案中，我們使用不同的秘訣將Publish系統從負載平衡中移除，而不需要直接存取負載平衡器本身。
負載平衡器通常會「ping」，此為特定頁面，用於檢視伺服器是否正常運作及執行中。 一個簡單的選擇通常是ping首頁。 但是，如果您想要使用ping訊號讓負載平衡器不要平衡流量，您可以選擇其他專案。 您可以建立專用範本或servlet，將其設定為以"up"或"down"回應（在內文中或作為http回應代碼）。 該頁面的回應當然不得在Dispatcher中快取，因此一律會從Publish系統全新擷取。 現在，如果您設定負載平衡器以檢查此範本或servlet，您可以輕鬆讓Publish「假裝」它停止運作。 它不會是負載平衡的一部分，而且可以更新。
全球分佈
「全球發佈」是「向外擴充」設定，您在每個Publish系統前有多個Dispatcher — 現已分佈於世界各地，以更接近客戶並提供更優異的效能。 當然，在這種情況下，您沒有中央負載平衡器，而是有基於DNS和地理IP的負載平衡配置。
注意水平縮放
即使是在本機資料中心，「向外擴充」拓撲(在每個Publish系統前面有多個Dispatcher)也有一些優點。 如果您發現Apache Server因高流量（以及良好的快取命中率）而造成效能瓶頸，而且您無法再擴充硬體（藉由新增CPU、RAM和更快的磁碟），您可以藉由新增Dispatcher來提升效能。 這稱為「水平縮放」。 然而，這有限制，尤其是當您經常讓流量失效時。 我們將在下一節中說明此效果。
向外擴展拓朴的限制
新增Proxy伺服器通常應該會提高效能。 但是，在某些情況下，新增伺服器實際上可能會降低效能。 如何進行？ 假設您有一個新聞入口網站，您每分鐘都會在此介紹新文章和頁面。 Dispatcher會透過「自動失效」而失效：每當發佈頁面時，同一網站上的快取中的所有頁面都會失效。 這是一個有用的功能 — 我們在本系列的第1章中已經說明這個功能 — 但也表示當您的網站經常發生變更時，您經常會使快取失效。 如果每個Publish例項只有一個Dispatcher，則第一個請求頁面的訪客會觸發該頁面的重新快取。 第二個訪客已取得快取版本。
如果您有兩個Dispatcher，則第二個訪客有50%的機會未快取頁面，然後他會在再次轉譯該頁面時體驗到較大的延遲。 每個Publish擁有更多的Dispatcher會讓情況變得更糟。 實際上是Publish伺服器會收到更多負載，因為它必須分別重新呈現每個Dispatcher的頁面。
在經常進行快取排清的擴充案例中效能降低。
