SAP Commerce Cloud Architecture
盡管我們在“SAP Commerce Cloud 入門”一文中介紹了 SAP Commerce Cloud 的一些進階架構，但在此我們将重點介紹在您的項目期間需要做出的一些實際架構決策。 使用 SAP Commerce Cloud 時，您可能會發現存在一些在 On-Premises 項目中不存在的限制。 然而，事實并非如此。這隻是以不同方式設計您的解決方案的問題。
High-Level Software Architecture
SAP Commerce Cloud 包含可用于建立定制商務解決方案的強制性和可選軟體包的組合。 這些包括：
雲自動化
Microsoft Azure - 公共雲基礎架構提供商
SAP 業務技術平台 - 用于托管 SAP Commerce Cloud Portal、SAP ntegration Suite 和 SAP Extension Suite 等應用程式/服務的業務平台
Kubernetes - 用于編排運作商業解決方案所需的 docker 節點
可定制的軟體
SAP Commerce - 在 Cloud Portal 建構過程中與您的自定義代碼結合的核心平台
Accelerator - 基于 SAP Commerce 中提供的模闆的定制店面。
Spartacus JavaScript 店面 - 一個解耦的開源店面，它使用全方位商務連接配接 (OCC) API 與您的 SAP Commerce Cloud 環境進行通信。 有關更多詳細資訊，請參閱為您的 SAP Commerce Cloud 解決方案選擇要使用的店面。
行業加速器（文檔） - 行業特定店面模闆
資料中心（文檔）- 用于為每個 SAP Commerce Cloud 環境導入/導出主資料的選項。 有關更多詳細資訊，請參閱 SAP Commerce Cloud 的內建選項。
SAP 擴充套件 - 基于開源項目“Kyma”的微服務擴充層。 有關更多詳細資訊，請參閱 SAP Commerce Cloud 的內建選項。
Additional Server Hosting & Third-Party Software Applications
通常，您需要 SAP Commerce Cloud 解決方案與第三方應用程式進行互動。 如果您的第三方應用程式需要通路伺服器或無法通過固定的建構和部署過程實作（即需要的不僅僅是通過“ant all”目标可以完成的工作），那麼它就不能成為您的 SAP Commerce 的一部分 雲代碼，需要托管在其他地方。 本節更詳細地記錄了一些常見示例，但其他選項可能包括第三方 CMS 或為二進制包設定私有存儲庫。
在規劃您的應用程式時，請仔細考慮哪些應用程式、二進制檔案或基礎架構元件（超出 Commerce 應用程式和資料庫）構成您的目标架構的一部分。 本節中的示例不排除更多樣化的目标架構，但确實需要一種架構設計，以促進生産性 SAP Commerce Cloud 訂閱與單個項目所依賴的其他元件（不由 SAP 提供）之間的關注點分離 商務雲）。
Continuous Integration / Continuous Delivery (CI/CD)
如果您正在尋找複雜的自動化管道或每次送出建構，您将需要設定自己的 CI/CD 執行個體。 這将為您提供靈活性和控制力，以確定在建構/部署到共享 SAP Commerce Cloud 環境之一之前建構和測試您的代碼。 您可以使用 Commerce Cloud API 遠端執行建構/部署。 您的 CI/CD 執行個體應該能夠連接配接到 SAP Commerce Cloud 使用的同一個 Git 存儲庫。 CI/CD 應用程式的位置并不重要，因為它不會直接影響 SAP Commerce Cloud 解決方案的性能。 如果您發現從 Git 存儲庫中提取代碼的延遲太長，您可以考慮更換您的 CI/CD 應用程式的托管位置。 有關為 SAP Commerce Cloud 解決方案設定 CI/CD 的更多資訊，請參閱使用 SAP Commerce Cloud 實施持續傳遞。
Image Resizing
圖像大小調整通常在 Commerce 中通過擴充完成，該擴充通常依賴于安裝在 Commerce 伺服器上的第三方軟體 (ImageMagick)。 在 Cloud Automation 1912 版本中，SAP Commerce Cloud 中提供了圖像轉換服務，并且可以在清單檔案中包含 cloudmediaconversion 擴充時啟用。
Third Party Application
如果您的 SAP Commerce Cloud 解決方案需要尚未由第三方托管的應用程式，您應該考慮在何處托管它。 建議嘗試通過在與 Commerce Cloud 訂閱相同的 Azure 日期中心運作它來盡量減少延遲。 如果您不知道正在使用哪個資料中心，您可以通過雲可用性中心找到此資訊。 如果您不想使用 Azure，您可以在同一地區尋找等效的公共雲提供商，盡管當呼叫轉到外部資料中心時可能會有額外的延遲。 如果它是一個異步調用或一個不經常發生的調用，那麼這種額外的延遲可能不是您的解決方案的關鍵。
上面的示例包含一個在自托管伺服器上運作的應用程式，并公開 REST 服務，這些服務可由您的一個或多個 SAP Commerce Cloud 方面調用。
E-mail Service
SAP Commerce 使用 Web 内容管理系統 (WCMS) 子產品來定義和生成電子郵件，進而利用在電子郵件文本中呈現的 WCMS 元件。 在幕後，Apache Commons 電子郵件庫提供了所有必需的軟體基礎設施，将解決方案與簡單郵件傳輸協定 (SMTP) 聯系起來。 SAP Commerce Cloud 充當用戶端，但需要 SMTP 伺服器/服務。
SAP Commerce Cloud 不提供 SMTP 伺服器，這意味着您必須提供備用 SMTP 政策。
Cloud Hot Folders (Extended Hot Folders)
Hot Folders 已發展成為 SAP Commerce Cloud 的基于檔案的內建政策，現在稱為 Cloud Hot Folders。
下圖概括地顯示了該解決方案如何從 SAP 基礎架構上的 SAP Commerce Cloud 演變為新的 SAP Commerce Cloud。 主要更新如下：
遠端存儲支援（Azure 雲存儲）
支援 ZIP 檔案（核心資料、樣本資料和原始 ImpEx 檔案）
支援 URL 媒體檔案
檔案排序
改進的監控
Caching
Content Delivery Network
擷取要緩存的端點的 IP（例如，店面、背景）。 要在 Cloud Portal 中執行此操作，請選擇環境，然後單擊端點的端點連結。 當編輯端點螢幕打開時，找到基本配置部分中的域字段。 端點的 DNS 名稱是域位址。 您可以嘗試使用 NS 查找來擷取 IP.
在您的環境期間，您的端點的 IP 是靜态的。 如果您的環境被重新配置，IP 很可能會改變。 是以，您還需要通過 CDN 提供商進行更新。
将這些 IP 提供給您的 CDN 提供商。
如果您的端點不可公開通路，請確定您已将 CDN 添加到 IP 過濾器清單中。
Region Cache
SAP Commerce Cloud 利用 SAP Commerce 的現有區域緩存。 但是，由于 SAP Commerce Cloud 建構過程控制 Java 堆大小，這可能因環境而異，是以需要以靈活的方式配置緩存區域，而不是在内部設定固定值。
Cronjobs Execution
準備使用 SAP Commerce Cloud 時的一個關鍵考慮因素是，在處理代表生産的資料集時，確定任何批量處理作業在“backgroundProcessing”方面的固定資源占用範圍内可靠運作。 如果您從 SAP 基礎架構上的 SAP Commerce Cloud 或本地執行個體遷移，則尤其如此。 ‘backgroundProcessing’ 方面将運作任何自動觸發的 cronjob； 如果您從“背景”方面手動觸發作業，它将在觸發它的節點上運作。
例如，可以開發加載價格資訊的批量處理作業，将整個價格行檔案加載到記憶體中進行處理。 在處理檔案導入時，這通常被認為是不好的做法。 原因在于，雖然在使用小資料集進行測試時，這可能在開發環境中可靠地工作，但在生産環境中，實際價格行檔案的大小可能有數百兆位元組，并且需要顯式增加配置設定給 Java 虛拟機的資源才能将檔案可靠地加載到 記憶體中。 如果這種情況發生在 SAP Commerce Cloud 上，則無法擴充配置設定給單個“背景處理”節點的資源。
是以，所有批量處理作業都應開發為：
有效利用配置設定的資源，批量導入并主動釋放引用，以在整個導入過程中實作一緻的記憶體配置檔案。
避免不必要地将大型資料集加載到記憶體中。
在“backgroundProcessing” aspect 分發大批量處理任務。
使用現有項目遷移到 SAP Commerce Cloud 的客戶應檢查其批量處理作業，以驗證他們是否遵守了這些準則。
Conclusion
盡管 SAP Commerce Cloud 以一緻的架構提供了大部分基礎設施，但總會有外部系統需要與您的商務解決方案進行互動。 正确了解 SAP Commerce Cloud 現有架構的特性和優勢将有助于您設計新的內建。