第1章 — Dispatcher概念、模式與反模式

最後更新： 2025年5月5日
  • 適用對象：
  • Experience Manager 6.4
  • Experience Manager 6.5

建立對象：

  • 初學者
  • 開發人員

概觀

本章簡要介紹Dispatcher的歷史和機制，並討論這會如何影響AEM開發人員如何設計其元件。

為何開發人員應關注基礎結構

Dispatcher是大部分(如果不是所有AEM安裝的話)的必要部分。 您可以找到許多線上文章，討論如何設定Dispatcher以及秘訣和技巧。

不過，這些零星的資訊總是從非常技術性的層面開始 — 假設您已知道要做什麼，因此只提供如何達成所要目標的詳細資訊。 我們從未找到任何概念性檔案，說明使用Dispatcher可以做哪些事情以及不能做哪些事情時​ 是什麼以及為什麼是。

反圖樣：Dispatcher作為事後思考

缺乏基本資訊會導致許多反模式，我們在許多AEM專案中看到：

  1. 由於Dispatcher已安裝在Apache Web Server中，因此需由專案中的「Unix gods」負責對其進行設定。 「凡世的Java開發人員」不需要擔心這個問題。

  2. Java開發人員需要確保他的程式碼可以運作…… Dispatcher稍後會神奇地使其快速。 Dispatcher一律為事後考量。 但是，這無法運作。 開發人員在設計程式碼時必須考慮到Dispatcher。 他需要瞭解它的基本概念才能做到這一點。

「先讓它運作，再讓它快速」並非總是正確的

您可能聽說過程式設計建議​ 「請先讓它運作 — 然後讓它快速。」。這並非完全錯誤。 但是，如果沒有正確的上下文，它往往會遭到錯誤解譯且無法正確套用。

建議應避免開發人員過早最佳化程式碼，因為程式碼可能永遠不會執行，或執行非常少，以致於最佳化沒有足夠的影響，無法證明將工作投入最佳化的合理性。 此外，最佳化可能會導致程式碼變得更加複雜，從而引入錯誤。 因此，如果您是開發人員，請勿將太多時間花在微調最佳化每行程式碼上。 只要確定您選擇正確的資料結構、演演算法和程式庫，並等待效能分析工具的熱點分析，就能瞭解更徹底的最佳化在哪裡可以提升整體效能。

架構決定與成品

然而，在「架構」決策方面，「先讓它運作，然後再讓它快速」的建議是完全錯誤的。 什麼是架構決策？ 簡言之，它們是昂貴、困難和/或事後無法變更的決定。 請記住，「昂貴」有時等同於「不可能」。 例如，當您的專案已用盡預算時，就不可能進行昂貴的變更。 對的基礎架構變更，是此類別中最先出現的一種變更。 不過，還有另外一種「建築」人工因素可能會變得非常難以改變：

  1. 位於應用程式「中心」的程式碼片段，其他許多片段都需仰賴這些片段。 若要變更這些專案，需要一次變更並重新測試所有相依性。

  2. 涉及某些非同步、計時相關情況的成品，在這種情況下，輸入 — 因此系統的行為可以非常隨機地變化。 變更可能會產生無法預測的效果，而且可能難以測試。

  3. 在系統的所有部分及元件中，反複使用及重複使用的軟體模式。 如果軟體模式最後變成次最佳，則所有使用模式的成品都必須重新編碼。

還記得嗎？ 在本頁頂端，我們說過Dispatcher是AEM應用程式的重要一環。 存取網頁應用程式非常隨機 — 使用者在無法預測的時間來往往。 最後，所有內容都會（或應該）在Dispatcher中快取。 因此，如果您仔細觀察，您可能已經意識到，快取可以視為「架構」成品，因此應讓團隊的所有成員、開發人員和管理員都瞭解。

我們並不是說開發人員應該實際設定Dispatcher。 他們需要瞭解概念（尤其是界限），以確保他們的程式碼也能由Dispatcher運用。

Dispatcher不會奇蹟般地提高程式碼速度。 開發人員建立元件時，必須考慮到Dispatcher。 因此，他需要瞭解運作方式。

Dispatcher快取 — 基本原則

Dispatcher作為快取Http — 負載平衡器

什麼是Dispatcher？為何最初稱為「Dispatcher」？

Dispatcher是

  • 首先也是最重要的一個快取

  • 反向proxy

  • 適用於Apache httpd webserver的模組，將AEM相關功能新增至Apache的多功能性，並與所有其他Apache模組一起順暢運作（例如SSL或甚至SSI包含，我們稍後將看到）

在網路早期，您可能會有幾百位訪客造訪網站。 一個Dispatcher的設定，「已分派」或平衡多個AEM發佈伺服器的請求負載，通常情況下已足夠 — 因此，名稱為「Dispatcher」。 然而，現今此設定不再經常使用。

我們稍後會看到設定Dispatcher和Publish系統的不同方式。 首先，讓我們從一些http快取基本概念開始。

Dispatcher快取的基本功能

Dispatcher快取的基本功能

此處會說明Dispatcher的基本概念。 Dispatcher是簡單的快取反向Proxy，能夠接收和建立HTTP請求。 正常的要求/回應週期如下：

  1. 使用者請求頁面
  2. Dispatcher會檢查是否已擁有該頁面的轉譯版本。 假設這是此頁面的第一個請求，且Dispatcher找不到本機快取復本。
  3. Dispatcher向Publish系統請求頁面
  4. 在Publish系統上，頁面會由JSP或HTL範本轉譯
  5. 頁面會傳回Dispatcher
  6. Dispatcher快取頁面
  7. Dispatcher會將頁面傳回瀏覽器
  8. 如果第二次請求相同頁面，則可直接從Dispatcher快取中提供此頁面，而不需要在Publish執行個體上重新轉譯。 這樣可節省在Publish執行個體上等待使用者和CPU週期的時間。

我們在最後一節討論「頁面」。 但相同的配置也適用於其他資源，例如影像、CSS檔案、PDF下載等。

如何快取資料

Dispatcher模組會運用託管Apache伺服器所提供的功能。 HTML頁面、下載和圖片等資源會儲存為Apache檔案系統中的簡單檔案。 就是這麼簡單。

檔案名稱是由要求的資源URL衍生。 如果您要求檔案/foo/bar.html，則會儲存該檔案，例如在/var/cache/docroot/foo/bar.html下。

原則上，如果所有檔案都已快取，並因而靜態儲存在Dispatcher中，您可以提取Publish系統的外掛程式，而Dispatcher將充當簡單的網頁伺服器。 但這只是為了說明原則。 現實生活更複雜。 您不能快取所有內容，而且快取永遠不會完全「滿」，因為由於轉譯過程的動態性質，資源數量可能是無限的。 靜態檔案系統的模型有助於產生Dispatcher功能的粗略描述。 此外，它有助於說明Dispatcher的限制。

AEM URL結構和檔案系統對映

若要更詳細地瞭解Dispatcher，讓我們重新造訪簡單範例URL的結構。 讓我們看看以下範例，

http://domain.com/path/to/resource/pagename.selectors.html/path/suffix.ext?parameter=value&otherparameter=value#fragment

  • http代表通訊協定

  • domain.com是網域名稱

  • path/to/resource是資源儲存在CRX中以及隨後儲存在Apache伺服器的檔案系統中的路徑

從這裡，AEM檔案系統和Apache檔案系統之間有一點不同。

在AEM中

  • pagename是資源標籤

  • selectors代表Sling中使用的多個選取器，以決定如何呈現資源。 URL可以有任意數目的選取器。 它們以句點分隔。 例如，選取器區段可能類似於「french.mobile.fancy」。 選取器應僅包含字母、數字和破折號。

  • html做為最後一個「選取器」稱為延伸。 在AEM/Sling中，它也部分決定轉譯指令碼。

  • path/suffix.ext是類似路徑的運算式，可以是URL的後置字元。 它可用於AEM指令碼，以進一步控制資源的呈現方式。 我們稍後會提供此零件的完整章節。 目前應該就足夠了，知道您可以將其用作其他引數。 尾碼必須有副檔名。

  • ?parameter=value&otherparameter=value是URL的查詢區段。 它可用來將任意引數傳遞至AEM。 無法快取包含引數的URL，因此引數應限制在絕對必要的情況下。

  • #fragment，URL的片段部分沒有傳遞至AEM，它只會在瀏覽器中使用；在JavaScript架構中為「路由引數」，或跳至頁面上的特定部分。

在Apache （參考以下圖表）中，

  • pagename.selectors.html是快取檔案系統中的檔案名稱。

如果URL有尾碼path/suffix.ext，則

  • pagename.selectors.html已建立為資料夾

  • path pagename.selectors.html資料夾中的資料夾

  • suffix.ext是path資料夾中的檔案。 注意：如果尾碼沒有副檔名，則不會快取檔案。

從Dispatcher取得URL後 檔案系統配置

從Dispatcher取得URL後​ 檔案系統配置

基本限制

URL、資源和檔案名稱之間的對應相當簡單明瞭。

不過，您可能會注意到一些陷阱，

  1. URL可能會變得很長。 在本機檔案系統上新增/docroot的「路徑」部分，可能會輕易超過某些檔案系統的限制。 在Windows上的NTFS中執行Dispatcher是一項挑戰。 不過，使用Linux是安全的。

  2. URL可包含特殊字元和變音。 這通常不是Dispatcher的問題。 不過請記住，應用程式的許多位置都會解譯URL。 我們經常會看到應用程式的奇怪行為 — 只是為了找出一段很少使用的（自訂）程式碼未針對特殊字元進行徹底測試。 如果可以的話，您應該避免使用這兩項功能。 如果無法做到，請規劃全面測試。

  3. 在CRX中，資源具有子資源。 例如，一個頁面會有許多子頁面。 這在檔案系統中無法比對，因為檔案系統有檔案或資料夾。

不會快取沒有副檔名的URL

URL的副檔名一律必須為。 不過您可以在AEM中提供沒有副檔名的URL。 這些URL將不會在Dispatcher中快取。

範例

http://domain.com/home.html是​ 可快取

http://domain.com/home是​ 不可快取

當URL包含尾碼時，適用相同的規則。 尾碼必須有擴充功能才能快取。

範例

http://domain.com/home.html/path/suffix.html是​ 可快取

http://domain.com/home.html/path/suffix是​ 不可快取

您可能會想，如果資源部分沒有副檔名，但尾碼有副檔名會發生什麼事？ 嗯，在此案例中，URL完全沒有尾碼。 檢視下一個範例：

範例

http://domain.com/home/path/suffix.ext

/home/path/suffix是資源的路徑……因此URL中沒有尾碼。

結論

請一律將副檔名新增至路徑和後置字元。 SEO感知人員有時會主張，這會在搜尋結果中將您排在後面。 但是未快取的頁面速度會非常慢，而且會進一步下降。

衝突的尾碼URL

假設您有兩個有效的URL

http://domain.com/home.html

和

http://domain.com/home.html/suffix.html

在AEM中絕對有效。 若沒有Dispatcher，您不會在本機開發電腦上看到任何問題。 在UAT或負載測試中，您很可能也不會遇到任何問題。 我們面臨的問題是如此微妙，以至於在大部分測試中都未能通過。 當您處於尖峰時間，而且處理時間有限，可能沒有伺服器存取權，也沒有資源可加以修正時，就會受到嚴重影響。 我們曾經遇到過……

那麼……有什麼問題嗎？

檔案系統中的home.html可以是檔案或資料夾。 並非兩者都與AEM中的相同。

如果您先要求home.html，則會建立為檔案。

對home.html/suffix.html的後續請求會傳回有效結果，但由於檔案home.html在檔案系統中「封鎖」該位置，因此無法第二次建立home.html做為資料夾，因此不會快取home.html/suffix.html。

檔案系統中的檔案封鎖位置，無法快取子資源

檔案系統中的檔案封鎖位置，無法快取子資源

如果您反其道而行之，請先要求home.html/suffix.html，然後先將suffix.html快取在資料夾/home.html下。 不過，當您後續要求home.html做為資源時，此資料夾會被刪除並取代為檔案home.html。

當父系擷取為資源時刪除路徑結構

當父系擷取為資源時刪除路徑結構

因此，快取的結果完全是隨機的，取決於傳入請求的順序。 讓事情變得更棘手的是，您通常有多個排程程式。 而效能、快取命中率和行為可能因Dispatcher而異。 如果您想瞭解網站為什麼沒有回應，您必須確定您所檢視的Dispatcher正確順序有誤。 如果您正在檢視Dispatcher （運氣好的話）有較有利的請求模式，您在嘗試尋找問題時會迷路。