AEM as a Cloud Service 開發指南

2025年2月5日

建立對象：

  • 管理員
  • 開發人員

本檔案說明在AEM as a Cloud Service上開發的准則，以及它與AEM內部部署和AMS中的AEM不同的重要方式。

程式碼必須可感知叢集

在AEM as a Cloud Service中執行的程式碼必須瞭解，它一律在叢集中執行。 這表示執行中的例項永遠多於一個。 程式碼必須具復原性，尤其是因為例項可能隨時停止。

在AEM as a Cloud Service更新期間，有些執行個體同時執行舊程式碼和新程式碼。 因此，舊程式碼不得中斷新程式碼建立的內容，且新程式碼必須能夠處理舊內容。

如果需要識別叢集中的主要節點，可以使用Apache Sling Discovery API來偵測它。

記憶體中的狀態

狀態不得保留在記憶體中，而是要保留在存放庫中。 否則，如果執行個體停止，此狀態可能會遺失。

檔案系統上的狀態

請勿在AEM as a Cloud Service中使用執行個體的檔案系統。 磁碟是暫時性的，當執行個體回收時就會加以處置。 在處理單一請求時，可以限制使用檔案系統作為暫時性儲存空間，但不應將其濫用於大型檔案。 這是因為這可能會對資源使用配額產生負面影響，並遇到磁碟限制。

舉例來說，若不支援使用檔案系統，Publish層級應確保任何必須儲存的資料都會運送至外部服務，以供長期儲存之用。

觀察

同樣地，由於所有非同步發生的事（例如在觀察事件上動作），無法保證會在本機執行，因此必須謹慎使用。 JCR事件和Sling資源事件都是如此。 發生變更時，可能會移除執行個體，並由其他執行個體取代。 拓撲中當時處於作用中的其他執行個體能夠對該事件做出反應。 但在此情況下，這不會是本機事件，在發佈事件時進行中的領導人選舉的情況下，甚至可能沒有活動的領導人。

背景工作與長時間執行的工作

作為背景工作執行的程式碼必須假設執行所在的例項隨時都會停機。 因此，程式碼必須有韌性，而且最重要的是可恢復。 這表示如果程式碼重新執行，就不應從頭開始，而應從原本的地方開始。 雖然這並非此類程式碼的新需求，但在AEM as a Cloud Service中，執行個體很有可能停止運作。

為了將問題降至最低，應儘可能避免長時間執行工作，而且這些工作應至少可以恢復。 若要執行這類作業，請使用Sling作業，此作業有至少執行一次的保證，因此如果中斷，將會儘快重新執行。 但是他們或許不應該從頭開始。 若要排程這類工作，最好使用Sling工作排程器，因為這會再次確保至少執行一次。

請勿使用Sling Commons Scheduler進行排程，因為無法保證執行。 只是更有可能已排程。

同樣地，由於所有非同步發生的事（例如對觀察事件執行動作，包括JCR事件或Sling資源事件），無法保證執行，因此必須謹慎使用。 目前的AEM部署就是如此。

傳出HTTP連線

強烈建議任何傳出HTTP連線設定合理的連線和讀取逾時；連線逾時建議值為1秒，讀取逾時建議值為5秒。 確切的數字必須根據處理這些要求的後端系統的效能來確定。

對於未套用這些逾時的程式碼，在AEM as a Cloud Service上執行的AEM執行個體將強制執行全域逾時。 這些逾時值是連線呼叫的10秒和連線的讀取呼叫的60秒。

Adobe建議使用提供的Apache HttpComponents Client 4.x程式庫來建立HTTP連線。

已知可以運作，但可能需要自行提供相依性的替代方法是：

除了提供逾時功能外，也應對這類逾時功能進行適當處理，以及非預期的HTTP狀態代碼。

處理要求速率限制

當AEM的傳入要求速率超過正常程度時，AEM會以HTTP錯誤碼429回應新要求。 對AEM進行程式化呼叫的應用程式可以考慮防禦式編碼，在幾秒鐘後使用指數回退策略重試。 在2023年8月中旬之前，AEM以HTTP錯誤代碼503回應相同的條件。

無傳統UI自訂

AEM as a Cloud Service僅支援第三方客戶程式碼的Touch UI。 傳統UI無法供自訂。

沒有原生二進位檔或原生程式庫

原生二進位檔和程式庫不得部署或安裝在雲端環境中。

此外，程式碼在執行階段不應嘗試下載原生二進位檔或原生Java擴充功能（例如JNI）。

沒有透過AEM as a Cloud Service的串流二進位檔

應透過CDN存取二進位檔案，CDN將在核心AEM服務之外提供二進位檔案。

例如，請勿使用asset.getOriginal().getStream()，這會觸發將二進位檔案下載到AEM服務的暫存磁碟。

沒有反向復寫代理

AEM as a Cloud Service不支援從Publish反向復寫至作者。 如果需要這類策略，您可以使用在Publish執行個體的伺服器陣列之間共用的外部持續性存放區，潛在地還有作者叢集。

可能需要移轉轉轉復寫代理

透過發佈訂閱機制，將內容從Author復寫至Publish。 不支援自訂復寫代理。

沒有多載開發環境

生產環境的大小較高，可確保穩定操作，而中繼環境的大小類似生產環境，可確保生產條件下的實際測試。

開發環境和快速開發環境應僅限於開發、錯誤分析和功能測試，且不應設計為處理高工作負載或大量內容。

例如，在開發環境中變更大型內容存放庫上的索引定義可能會導致重新索引導致太多處理。 需要大量內容的測試應在中繼環境中執行。