文件AEM as a Cloud Service使用手冊

如何將 Headless 應用程式上線 go-live

Last update: Mon Jul 15 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
  • 主題：

建立對象：

  • undefined
  • undefined

在 AEM Headless 開發人員歷程的這一部分中，了解如何從 Git 取出本機程式碼並移至 Cloud Manager Git 以用於 CI/CD 管道，藉此來部署 Headless 應用程式。

目前進度 story-so-far

在 AEM Headless 歷程的上一個文件「如何在 AEM Headless 中將您的應用程式和內容組合在一起」中，您已了解如何使用 AEM 開發工具將您專案的所有面向組合在一起。

本文章以這些基本知識為基礎，以便您了解如何準備您自己的 AEM Headless 專案並方案上線。

目標 objective

本文件可協助在將您的應用程式上線之前，應該注意的 AEM Headless 發佈管道和效能考量事項。

  • 在應用程式推出前加以保護和擴展
  • 監控效能和偵錯問題

若要讓 AEM Headless 應用程式準備好推出，請遵循下面概述的最佳做法。

在 Headless 應用程式推出前加以保護和擴展 secure-and-scale-before-launch

  1. 使用您的 GraphQL 要求設定權杖型驗證
  2. 設定快取。

模型結構與 GraphQL 輸出 structure-vs-output

  • 避免建立輸出超過 15kb JSON (gzip 格式壓縮) 的查詢。長 JSON 檔案是資源密集型檔案，用戶端應用程式需要解析。
  • 避免片段階層有超過五個巢狀層。增加層數會使內容作者難以考量變更帶來的影響。
  • 使用多物件查詢，而不是在模型中使用相依性階層建立查詢模型。這允許更長期的靈活性來重新建構 JSON 輸出，而無需進行許多內容變更。

最大化 CDN 快取命中比例 maximize-cdn

  • 不要使用直接 GraphQL 查詢，除非您從表面要求即時內容。

    • 盡可能使用持續性查詢。
    • 提供 600 秒以上的 CDN TTL，以便 CDN 可以快取。
    • AEM 可以計算模型變更對現有查詢的影響。

  • 在低內容更改率和高內容變更改率之間分割 JSON 檔案/GraphQL 查詢，以減少流到 CDN 的用戶端流量並指派更高的 TTL。這將 CDN 使用原始伺服器重新驗證 JSON 的需要降至最低。

  • 要主動使來自 CDN 的內容無效，請使用軟清除 (Soft Purge)。這允許 CDN 重新下載內容而不會導致快取遺漏。

縮短下載 Headless 內容的時間 improve-download-time

  • 確保 HTTP 用戶端使用 HTTP/2。
  • 確保 HTTP 用戶端接受標頭要求 gzip。
  • 盡量減少用於裝載 JSON 和參考成品的網域數量。
  • 利用 Last-modified-since 重新整理資源。
  • 使用 JSON 檔案中的 _reference 輸出開始下載資產，而無需解析完整的 JSON 檔案。

部署至生產環境 deploy-to-production

確保一切都經過測試且運作正常後，您就可以將程式碼更新推送至 Cloud Manager 中的集中式 Git 存放庫。

將更新上傳到 Cloud Manager 後，可以使用 Cloud Manager 的 CI/CD 管道部署到 AEM as a Cloud Service。

您可以利用 Cloud Manager CI/CD 管道開始部署您的程式碼，請參閱此處的詳細介紹。

效能監控 performance-monitoring

為了讓使用者有最佳的 AEM Headless 應用程式使用體驗，請務必監控關鍵效能量度，如下詳述：

  • 驗證應用程式的預覽版本和生產版本

  • 確認 AEM 狀態頁面是否有目前的服務可用性狀態

  • 存取效能報告

    • 傳遞效能

      • CDN (Fastly) 效能 - 檢查呼叫次數、快取率、錯誤率和負載流量
      • 原始伺服器 - 呼叫次數、錯誤率、CPU 負載、負載流量

    • 作者效能

      • 檢查使用者、要求和負載的數量

  • 存取應用程式和空間特定的效能報告

    • 伺服器啟動後，檢查一般量度是否為綠色/橘色/紅色，然後識別特定的應用程式問題
    • 開啟上面篩選到應用程式或空間 (例如 Photoshop 桌面、付費牆) 的相同報告
    • 使用 Splunk log API 存取服務和應用程式效能
    • 如果還有其他問題，請聯絡客戶支援。

疑難排解 troubleshooting

偵錯 debugging

遵循這些最佳做法做為一般偵錯方法：

  • 使用應用程式的預覽版本驗證功能和效能
  • 使用應用程式的生產版本驗證功能和效能
  • 使用內容片段編輯器的 JSON 預覽進行驗證
  • 檢查用戶端應用程式中的 JSON 以檢查是否存在用戶端應用程式或傳遞問題
  • 使用 GraphQL 檢查 JSON 以檢查是否存在與快取內容或 AEM 相關的問題

向支援團隊記錄錯誤 logging-a-bug-with-support

為了在需要進一步協助時，可以有效率地向支援團隊記錄錯誤，請執行以下操作：

  • 如有必要，將問題進行螢幕截圖
  • 記錄重現問題的方法
  • 記錄問題重現的內容
  • 透過 AEM 支援入口網站記錄問題並標註優先順序

歷程結束 - 還是結束了？ journey-ends

恭喜！您已經完成 AEM Headless 開發人員歷程！您現在應該已經了解：

  • Headless 和 Headful 內容傳遞之間的差異。
  • AEM 的 Headless 功能。
  • 如何組織 AEM Headless 專案。
  • 如何在 AEM 建立 Headless 內容。
  • 如何在 AEM 擷取和更新 Headless 內容。
  • 如何使 AEM Headless 專案上線。
  • 上線後要做什麼。

您已經推出您的第一個 AEM Headless 專案，或是現在已經掌握完成此作業的所有必要知識。做得好！

探索單頁應用程式 explore-spa

不過，AEM Headless 存放區不需要就此停止。您可能還記得，在歷程的快速入門部分中，我們簡短討論到 AEM 如何不僅支援 Headless 傳遞和傳統的全堆疊模型，還可以支援結合兩者優點的混合模型。

如果您的專案需要這種靈活性，請繼續學習此歷程的額外部分 (選用)：如何使用 AEM 建立單頁應用程式 (SPA)。

其他資源 additional-resources

recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab