雲端發佈微服務架構及效能分析
本文分享對於新雲端發佈微服務的架構和效能數字的深入解析。
雲端現有發佈工作流程的問題
DITA發佈是一項耗用大量資源的程式,主要取決於可用的系統記憶體和CPU。 如果發佈者發佈含有許多主題的大型地圖,或是觸發了多個平行發佈請求,則對這些資源的需求會進一步增加。
如果您未使用新服務,則所有發佈都會在同樣執行AEM雲端伺服器的相同Kubernetes(k8) Pod上進行。 典型的k8 pod會限制其可使用的記憶體和CPU數量。 如果AEM Guides使用者要發佈大型或平行的工作負載,此限制可能會很快突破。 K8會重新啟動Pod,而這些Pod嘗試使用的資源超過設定的限制,可能會對AEM雲端例項本身造成嚴重影響。
這種資源限制是提出專屬服務的主要動機,可讓我們在雲端上執行多個並行和大型發佈工作負載。
新架構簡介
此服務使用Adobe的頂尖雲端解決方案,例如App Builder、IO Eventing、IMS,建立無伺服器產品。 這些服務本身是以廣泛接受的產業標準為基礎,例如Kubernetes和docker。
對新發佈微服務的每個請求都會在隔離的Docker容器中執行,該容器一次僅執行一個發佈請求。 在收到新發佈請求時,會自動建立多個新容器。 每個要求設定的單一容器可讓微服務為客戶提供最佳效能,而不會帶來任何安全性風險。 發佈結束後就會捨棄這些容器,並釋放所有未使用的資源。
所有這些通訊都由Adobe IMS使用以JWT為基礎的驗證和授權來保護,並透過HTTPS執行。
{width="600"}
效能分析
本節將展示微服務的效能編號。 它會比較微服務與AEM Guides內部部署產品的效能,因為舊的雲端架構在同時發佈或發佈非常大的地圖時發生問題。
如果您正在內部部署發佈大型對應,則可能必須調整Java棧積引數,否則您可能會遇到記憶體不足錯誤。 在雲端上,微服務已進行效能分析,並有最佳的Java棧積和其他立即可用的設定。
在雲端與內部部署執行一項發佈
-
雲端
如果您使用新服務在雲端上執行單一發佈,則與單一內部發佈相比,發佈可能需要更多一點時間。 這個稍微增加的時間是因為新雲端架構的分散式性質。
{width="600"}
-
內部部署
單一發佈的結果在舊雲端架構或內部部署上較佳,因為完整發佈會發生在執行AEM的同一個Pod/電腦上。
{width="600"}
在雲端與內部部署執行多項發佈
-
雲端
新的發佈微服務在此情境中大放異彩。 如以下影像所示,隨著多個同時發佈工作的增加,雲端可發佈工作,而不會大幅增加發佈時間。
{width="600"}
-
內部部署
在內部部署伺服器上同時執行發佈會導致效能嚴重下降。 如果發佈者同時發佈更多地圖,此效能下降會比較嚴重。
{width="600"}
其他優點
每個發佈請求的某些部分都必須在AEM執行個體上執行,以擷取要傳送至微服務的正確發佈內容。 新雲端架構使用AEM工作,取代了舊架構中的AEM工作流程。 此變更可讓AEM Guides管理員個別設定雲端發佈佇列設定,而不會影響其他AEM工作或工作流程設定。
如需如何設定新發佈微服務的詳細資訊,請前往此處: 設定微服務