了解多租用戶和同時開發

簡介

當多個團隊將程式碼部署至相同的AEM環境時,他們應遵循一些實務,以確保團隊能盡可能獨立運作,而不需仰仗其他團隊的腳步。 雖然這些技術永遠無法完全淘汰,但這些技術可將跨團隊的相依性降至最低。 為了讓同時開發模型成功,開發團隊之間的良好溝通至關重要。

此外,當多個開發團隊在相同的AEM環境中工作時,可能會有一定程度的多租用戶。 關於嘗試在AEM環境中支援多個租戶的實際考慮,特別是管理治理、運營和開發所面臨的挑戰,已有很多文章。 本文探討在多租用戶環境中實作AEM的相關技術難題,但其中許多建議適用於具有多個開發團隊的任何組織。

請務必事先注意,雖然AEM可支援在單一環境中部署多個網站,甚至多個品牌,但並不提供真正的多租用戶。 某些環境配置和系統資源將始終在環境中部署的所有站點之間共用。 本檔案為最大限度地減少這些共用資源的影響提供了指導,並為簡化這些領域的溝通和協作提出了建議。

優勢和挑戰

實作多租用戶環境有許多挑戰。

這些包括:

  • 其他技術複雜性
  • 增加開發開銷
  • 共用資源的跨組織相依性
  • 操作複雜性增加

儘管面臨挑戰,但運行多租戶應用程式確實有好處,例如:

  • 降低硬體成本
  • 縮短未來網站的上市時間
  • 降低未來租戶的實施成本
  • 標準的體系結構和整個業務的開發實踐
  • 常見的程式碼基底

如果企業需要真正的多租戶,而對其他租戶一無所知,且沒有共用的程式碼、內容或通用作者,則只有個別的作者例項才可行。 應將發展工作的總體增加與基礎設施和許可證成本的節省進行比較,以確定這種方法是否最合適。

開發技術

管理相依性

管理Maven專案相依性時,所有團隊務必在伺服器上使用相同版本的指定OSGi套件組合。 為了說明當Maven專案管理不當時可能會發生什麼問題,我們舉了一個例子:

專案A取決於程式庫1.0版,foo;foo 1.0版已嵌入到伺服器的部署中。 專案B取決於程式庫1.1版,foo;foo 1.1版已嵌入到其部署中。

此外,假設此程式庫中的API在1.0版和1.1版之間已變更。此時,這兩個專案中的其中一個將無法正常運作。

為了解決這個問題,我們建議讓所有Maven專案變成單親反應堆專案的子項。 此反應堆項目有兩個用途:它允許根據需要一起構建和部署所有項目,並包含所有子項目的依賴聲明。 父項項目定義依賴項及其版本,而子項項目僅聲明所需的依賴項,從父項目繼承版本。

在此案例中,如果專案B的團隊需要1.1版foo中的功能,在開發環境中,這項變更會迅速顯現為中斷專案A。此時,團隊可以討論此變更,讓專案A與新版本相容,或尋找專案B的替代解決方案。

請注意,這並不會消除這些團隊共用這種依賴性的必要性,它只是快速、及早地強調問題,以便團隊可以討論任何風險並就解決方案達成一致。

防止程式碼重複

處理多個專案時,請務必確保程式碼不會重複。 代碼複製會增加缺陷發生的可能性、系統更改的成本以及代碼庫中的整體剛性。 為避免重複,請將通用邏輯重構為可重複使用的程式庫,以便用於多個專案。

為支援這項需求,我們建議開發和維護所有團隊都能依賴和貢獻的核心專案。 在執行此操作時,必須確保此核心項目不再依賴於任何個別團隊的項目;這可讓您進行獨立的部署,同時仍可提升程式碼的重複使用率。

核心模組中常見的程式碼範例包括:

  • 全系統配置,例如:
    • OSGi配置
    • Servlet篩選器
    • ResourceResolver對應
    • 吊具變壓器管道
    • 錯誤處理程式(或使用ACS AEM Commons錯誤頁處理程式1)
    • 對權限敏感的快取的授權servlet
  • 實用程式類
  • 核心業務邏輯
  • 協力廠商整合邏輯
  • 編寫UI覆蓋
  • 製作所需的其他自訂項目,例如自訂Widget
  • 工作流程啟動器
  • 跨網站使用的通用設計元素

模組化專案架構

這並不會消除多個團隊依賴和可能更新相同程式碼集的需求。 通過建立核心項目,我們減少了在團隊之間共用的代碼庫的大小,但減少了對共用資源的需求。

為確保對此核心套件所做的變更不會中斷系統的功能,我們建議由資深開發人員或開發人員團隊負責督導。 一個選擇是讓一個團隊負責管理此套件的所有變更;另一種方法是讓團隊提交由這些資源審核及合併的提取請求。 必須讓團隊設計並同意管理模式,讓開發人員遵循此模式。

管理部署範圍(&N)

當不同的團隊將程式碼部署至相同的存放庫時,請務必避免覆寫彼此的變更。 AEM有一種機制可在部署內容封裝時(即篩選器)控制此項。 xml檔案。 篩選器之間必須沒有重疊。 xml檔案,否則某個團隊的部署可能會清除另一個團隊以前的部署。 要說明這一點,請參閱以下精心編製的和有問題的篩選檔案的示例:

/apps/my-company與/apps/my-company/my-site

/etc/clientlibs/my-company與/etc/clientlibs/my-company/my-site

/etc/designs/my-company與/etc/designs/my-company/my-site

如果每個團隊明確將其篩選檔案配置到他們正在使用的站點,則每個團隊可以獨立部署其元件、客戶端庫和站點設計,而不會刪除彼此的更改。

因為它是全域系統路徑,且不是特定於一個網站,所以核心專案中應包含下列servlet,因為此處所做的變更可能會影響任何團隊:

/apps/sling/servlet/errorhandler

覆蓋

覆蓋圖常用來擴充或取代現成可用的AEM功能,但使用覆蓋圖會影響整個AEM應用程式(亦即,所有租戶都可使用任何功能變更)。 如果租戶對覆蓋層的要求不同,情況就會更加複雜。 理想情況下,業務群組應合作,就AEM管理主控台的功能與外觀達成一致。

如果各業務單位無法達成共識,可能的解決方案就是不使用覆蓋。 請改為建立功能的自訂復本,並透過不同路徑公開給每個租用戶。 這可讓每個租用戶擁有完全不同的使用者體驗,但此方法也會增加實作和後續升級工作的成本。

工作流程啟動器

AEM使用工作流程啟動器,在儲存庫中進行指定的變更時自動觸發工作流程執行。 AEM提供數個立即可用的啟動器,例如對新更新的資產執行轉譯產生和中繼資料擷取程式。 雖然可以保持原樣,但在多租用戶環境中,如果租用戶具有不同的啟動器和/或工作流模型要求,則可能需要為每個租戶建立和維護單個啟動器。 這些啟動器需要配置為在其租戶的更新上執行,同時保留其他租戶的內容。 將啟動器套用至特定租用戶的指定存放庫路徑,即可輕鬆達成此目標。

虛名 URL

AEM提供虛名URL功能,可依每頁設定。 在多租用戶案例中,此方法的關注點在於AEM無法確保以此方式設定的虛名URL之間的獨特性。 如果兩個不同的使用者針對不同的頁面設定相同的虛名路徑,可能會發生非預期的行為。 因此,我們建議在Apache Dispatcher例項中使用mod_rewrite規則,這可讓中央配置點與僅對外的資源解析器規則搭配使用。

元件組

為多個製作群組開發元件和範本時,請務必有效使用componentGroup和allowedPaths屬性。 透過有效運用這些元件與網站設計,我們可確保品牌A的作者只能查看已針對其網站建立的元件和範本,而品牌B的作者只能查看其元件和範本。

測試

雖然良好的架構和開放的通訊通道有助於防止網站意外區域引入缺陷,但這些方法並非萬無一失。 因此,在將任何項目發佈至生產環境之前,請務必先完整測試平台上部署的項目。 這需要團隊在發行週期上進行協調,並強化需要一套自動化測試,以盡可能多地涵蓋功能。 此外,由於一個系統將由多個團隊共用,因此效能、安全性和負載測試變得比以往任何時候都重要。

操作考量

共用資源

AEM會在單一JVM中執行;任何部署的AEM應用程式在正常執行AEM時已耗用的資源之上,本身就會彼此共用資源。 在JVM空間本身內,線程將不會邏輯分離,AEM可用的有限資源(如記憶體、CPU和磁碟i/o)也將共用。 任何租戶消耗資源都會不可避免地影響其他系統租戶。

效能

如果不遵循AEM最佳做法,則有可能開發超出正常範圍的資源消耗應用程式。 此舉的範例會觸發許多繁重的工作流程操作(例如DAM更新資產)、在多個節點上使用MSM推播 — on-modify操作,或使用昂貴的JCR查詢來即時轉譯內容。 這些將不可避免地對其他租戶應用程式的效能產生影響。

記錄

AEM提供立即可用的介面,以執行強大的記錄器設定,可在共用開發情境中發揮優勢。 通過為每個品牌指定單獨的日誌記錄器,通過包名,我們可以實現一定程度的日誌分離。 雖然複製和驗證等全系統操作仍將記錄到中央位置,但非共用的自訂代碼可以單獨記錄,從而簡化了每個品牌技術團隊的監控和調試工作。

備份和還原

由於JCR儲存庫的性質,傳統備份在整個儲存庫中工作,而不是在單個內容路徑上。 因此,無法根據每個租戶輕鬆分離備份。 反之,從備份還原將回滾系統上所有租戶的內容和儲存庫節點。 雖然可以使用VLT等工具執行目標內容備份,或通過在單獨的環境中構建包來選擇要恢復的內容,但這些
方法不易包含組態設定或應用程式邏輯,且管理起來很麻煩。

安全性考量事項

ACL

當然,可以使用訪問控制清單(ACL)來控制誰有權根據內容路徑查看、建立和刪除內容,這需要建立和管理用戶組。 維護ACL和組的難度取決於如何確保每個租戶對其他租戶一無所知,以及部署的應用程式是否依賴共用資源。 為確保ACL、用戶和組的高效管理,我們建議建立一個集中的組,並進行必要的監督,以確保這些訪問控制和主體重疊(或不重疊),從而提高效率和安全性。

本頁內容