雲端發佈微服務架構及效能分析
本文分享對於新雲端發佈微服務的架構和效能數字的深入解析。
雲端現有發佈工作流程的問題
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執行。
效能分析
本節將展示微服務的效能編號。 它會比較微服務與AEM Guides現場服務的效能，因為舊的雲端架構在同時發佈或發佈非常大的地圖時發生問題。
如果您正在內部部署發佈大型對應，則可能必須調整Java棧積引數，否則您可能會遇到記憶體不足錯誤。 在雲端上，微服務已進行效能分析，並有最佳的Java棧積和其他立即可用的設定。
在雲端與內部部署執行一項發佈
-
雲端
如果您使用新服務在雲端上執行單一發佈，則與單一內部發佈相比，發佈可能需要更多一點時間。 這個稍微增加的時間是因為新雲端架構的分散式性質。
-
內部部署
單一發佈的結果在舊雲端架構或內部部署上較佳，因為完整發佈會發生在執行AEM的同一個Pod/電腦上。
在雲端與內部部署執行多項發佈
-
雲端
新的發佈微服務在此情境中大放異彩。 如以下影像所示，隨著多個同時發佈工作的增加，雲端可發佈工作，而不會大幅增加發佈時間。
-
內部部署
在內部部署伺服器上同時執行發佈會導致效能嚴重下降。 如果發佈者同時發佈更多地圖，此效能下降會比較嚴重。
其他優點
每個發佈請求的某些部分都必須在AEM執行個體上執行，以擷取要傳送至微服務的正確發佈內容。 新雲端架構使用AEM工作，取代了舊架構中的AEM工作流程。 此變更可讓AEM Guides管理員個別設定雲端發佈佇列設定，而不會影響其他AEM工作或工作流程設定。
如需有關如何設定新發佈微服務的詳細資訊，請參閱此處： 設定微服務