Pro架構
雲端基礎結構上的Adobe Commerce Pro架構支援多種環境，可用於開發、測試和啟動您的商店。
- Master — 提供部署至Platform as a Service (PaaS)容器的
master分支。 - 整合 — 提供單一
integration分支以進行開發，但您可以建立一個額外的分支。 這允許最多兩個 活動 分支部署到Platform as a Service (PaaS)容器。 - 暫存 — 提供單一
staging分支，可部署至專用基礎結構即服務(IaaS)容器。 - 生產 — 提供單一
production分支以部署至專用基礎結構即服務(IaaS)容器。
下表總結了環境之間的差異：
環境架構
您的專案是單一Git存放庫，具有三個主要環境分支： integration、staging和production。 下圖顯示Pro環境的階層式關係：
主要環境
在Pro專案上，master分支會提供使用中的PaaS環境以及您的生產環境。 請一律將生產計畫碼的副本推送到master環境，這樣您就可以在不中斷服務的情況下對生產環境進行偵錯。
警告：
-
請 不 根據
master分支建立分支。 使用整合環境建立用於開發的有效分支。 -
請勿使用
master環境進行開發、UAT或效能測試
整合環境
整合環境會在名為PaaS的伺服器網格上的Linux容器(LXC)中執行。 每個環境都包含網站伺服器和資料庫，用以測試您的網站。 如需AWS和Azure IP位址清單，請參閱地區IP位址。
建議的使用案例：
整合環境是專為有限的測試和開發而設計，以便將變更移至中繼和生產環境。 例如，您可以使用整合環境來完成下列工作：
-
確保對持續整合(CI)流程的變更與雲端相容
-
在關鍵頁面上測試關鍵工作流程，例如首頁、類別、產品詳細資料頁面(PDP)、結帳和管理員
若要在整合環境中取得最佳效能，請遵循下列最佳實務：
-
限制目錄大小 — 作為參考，範例資料包含約2,048種產品。 請嘗試將目錄大小縮減至約4,000至5,000種產品。
若要檢查目錄中的產品數目，請執行下列MySQL查詢：code language-sql select distinct count(entity_id) from catalog_product_entity; -
減少客戶群組數量 — 擁有過多客戶群組可能會影響索引效能和整體效能。
-
限制使用一或兩名同時使用者
-
停用cron工作並根據需要手動執行
警告：
-
無法在整合環境中存取Fastly CDN和New Relic服務
-
整合環境架構不符合測試和生產架構
-
請勿使用
integration環境進行開發測試、效能測試或使用者驗收測試(UAT) -
請勿使用
integration環境來測試B2B的Adobe Commerce功能 -
您無法從資料庫生產或中繼還原整合環境中的資料庫
中繼環境
中繼環境提供測試網站的近乎生產環境。 此環境由專屬的IaaS硬體託管，並包含所有服務，例如Fastly CDN、New Relic APM和搜尋。
建議的使用案例：
此環境符合生產架構，且設計用於UAT、內容測試和最終稽核，然後再將功能推送到production環境。 例如，您可以使用staging環境來完成下列工作：
-
針對生產資料進行回歸測試
-
啟用Fastly快取的效能測試
-
測試新組建，而非在生產環境中修補
-
新組建的UAT測試
-
測試Adobe Commerce的B2B
-
自訂cron設定和測試cron工作
警告：
-
啟動生產網站後，請先使用預備環境測試修補程式，以進行生產關鍵性錯誤修正。
-
您無法從
staging分支建立分支。 而是將程式碼變更從integration分支推送到staging分支。
生產環境
生產環境會執行您的公開單一和多網站店面。 此環境在專用的IaaS硬體上執行，具備備援的高可用性節點，可為您的客戶提供持續存取和容錯移轉保護。 生產環境包含中繼環境中的所有服務，以及New Relic基礎結構(NRI)服務，該服務會自動連線應用程式資料和效能分析，以提供動態伺服器監視。
警告：
您無法從production分支建立分支。 而是將程式碼變更從staging分支推送到production分支。
生產技術棧疊
生產環境有三個虛擬機器器(VM)，位於由每個VM的HAProxy管理的Elastic Load Balancer後面。 每台VM都包含下列技術：
-
Fastly CDN—HTTP快取和CDN
-
NGINX — 使用PHP-FPM的網頁伺服器，一個執行個體具有多個背景工作
-
GlusterFS — 用來管理所有靜態檔案部署及與四個目錄掛載同步化的檔案伺服器：
varpub/mediapub/staticapp/etc
-
Redis — 每個VM一台伺服器，只有一個作用中，另外兩個做為復本
-
Elasticsearch — 在雲端基礎結構2.2到2.4.3-p2上搜尋Adobe Commerce
-
OpenSearch — 在雲端基礎結構2.3.7-p3、2.4.3-p2、2.4.4和更新版本上搜尋Adobe Commerce
-
Galera — 資料庫叢集，每個節點有一個MariaDB MySQL資料庫，每個資料庫的唯一識別碼的自動增加設定為3
下圖顯示生產環境中使用的技術：
備援硬體
雲端基礎結構上的Adobe Commerce不是執行傳統的、主動 — 被動master或主要 — 次要設定，而是執行 備援架構，其中所有三個執行個體都接受讀取和寫入。 此架構在擴充時可提供零停機時間，並確保交易完整性。
由於獨特的備援硬體，Adobe可提供三部閘道伺服器。 大部分的外部服務可讓您將多個IP位址新增至允許清單，因此擁有多個固定IP位址不成問題。 三個閘道對應至生產環境叢集中的三個伺服器，並保留靜態IP位址。 它完全備援，而且每個層級都具備高可用性：
- DNS
- 內容傳遞網路(CDN)
- 彈性負載平衡器(ELB)
- 包含所有Adobe Commerce服務（包括資料庫和網頁伺服器）的三伺服器叢集
備份與災難回覆
雲端基礎結構上的Adobe Commerce使用高可用性架構，該架構會複製三個獨立AWS或Azure可用性區上的每個Pro專案，每個區有一個獨立的資料中心。 除了此備援之外，Pro中繼和生產環境還會接收定期的即時備份，這些備份是針對 災難性失敗 的情況而設計。
自動備份 包含來自所有執行中服務的永久資料，例如MySQL資料庫和儲存在掛載磁碟區上的檔案。 備份會儲存至與生產環境位於相同區域的加密彈性區塊儲存(EBS)。 無法公開存取自動備份，因為它們儲存在不同的系統中。
您可以使用CLI命令，為中繼和生產環境建立資料庫的 手動備份。 請參閱備份資料庫。 針對integration環境，Adobe建議在雲端基礎結構專案上存取Adobe Commerce後，以及套用任何重大變更之前，先建立備份，作為第一步。 請參閱備份管理。
復原點目標
RPO為上次備份的最長六小時時間（例如06:00、12:00、18:00）。 備份的頻率取決於您計畫的備份排程，以及寫入儲存服務的變更量。
保留原則
Adobe會根據下列資料保留原則保留自動備份：
此政策可能會因您的雲端基礎結構計畫而異。
復原時間目標
RTO取決於儲存的大小。 大型EBS磁碟區需要更多時間來還原。 還原時間可能會因資料庫大小而異：
- 大型資料庫(200+ GB)可能需要5個小時
- 中型資料庫(150 GB)可能需要2.5小時
- 小型資料庫(60 GB)可能需要1小時的時間
Pro叢集縮放
Pro叢集大小和 計算 設定會依所選的雲端提供者(AWS、Azure)、地區和服務相依性而有所不同。 Adobe雲端基礎結構可以擴展Pro叢集，以因應流量期望和服務需求變化。
備援架構可讓Adobe雲端基礎建設得以升級，無需停機。 升級時，這三個執行個體都會輪換以升級容量，而不會影響網站作業。 例如，如果限制在PHP層級，而不是資料庫層級，則可以將額外的Web伺服器新增到現有的叢集。 這提供 水平縮放，以補充資料庫層級上額外CPU所提供的垂直縮放。 請參閱縮放架構。
如果您預期因事件或其他原因而導致流量大幅增加，可請求暫時增加容量。 請參閱如何在 Commerce說明中心 中要求暫時性的大小調整。