本文說明如何透過 Adobe Developer App Builder 重新思考 Adobe Commerce 的可擴充性，並以更可擴充的架構取代大部分自訂 PHP，以提升可擴充性、穩定性及可維護性，適合實際生產環境中的長期增長。

簡介

多年來，PHP 的擴充性一直是 Adobe Commerce 自訂的支柱。但隨著雲端原生架構的成熟，也有更好的替代方案。在最近為一家領先的歐洲行動與金融服務供應商進行的實作中，我們以 App Builder (Adobe 的雲端原生擴充平台) 取代大部分傳統 Adobe Commerce 模組開發。我們透過利用執行階段動作 (無伺服器功能)、事件和 API 來達成此目標，以提供更可擴充和可維護的解決方案。本文將說明該決定背後的原因、架構結構和經驗教訓。

概觀

Adobe Commerce 的 API 優先方法可逐步採用，方法是評估哪些功能最有利於在核心 Adobe Commerce 平台之外以雲端原生應用程式的形式執行，並先移轉這些功能。

此流程會產生明確的結果：

• 約 70% 的功能是使用 App Builder 實作的

• 約 30% 仍保留為原生 Adobe Commerce PHP 自訂

此平衡可讓我們保持結帳相關的原生邏輯貼近於 Commerce，同時解除安裝 App Builder 的整合、驗證、背景處理和協調流程，以發揮擴充性、隔離和部署彈性的優勢。

產生的架構 (請參閱下圖，僅概述 App Builder 擴充功能) 反映此混合式方法：Adobe Commerce 仍然是交易核心，而 App Builder 則作為整合和自動化支柱。此策略會透過事件導向的流程和 API Mesh (Adobe 的 API 協調流程服務) 連線身分識別 (SSO)、PIM、ERP、第三方服務和自訂商業邏輯。

架構逐步說明：混合式模型的運作方式

解決方案的核心是使用 Adobe Commerce 進行其擅長的操作：目錄、定價、購物車、結帳和訂購位置。我們特意保持交易核心整潔且穩定，避免 Commerce 執行階段中不必要的自訂。

圍繞該核心的一切 (身分識別、資料驗證、可用性邏輯、背景處理和第三方整合) 都透過 App Builder 和 Adobe API Mesh 處理。

購物者體驗建立於新的 Commerce 店面 (由 Edge Delivery Services 提供支援)。

1. 進入層：CDN、Commerce 店面與身分識別

來自一般網站訪客的所有流量會先抵達 CDN + Edge Delivery Service，確保最佳績效、安全性和全域傳送，然後所有請求才能送達後端系統。

驗證會透過 Keycloak SSO 處理，透過以下方式整合：

• App Builder SSO 整合

• Marketplace 的標準 Adobe Commerce PHP 模組，用於核心 SSO 組態和設定

• 此設定可讓我們結合平台穩定性與雲端原生彈性。

此方法的主要優點

• 透過經驗證的 Marketplace 模組進行集中式身分管理

  我們仰賴得到良好支援的 Adobe Commerce 擴充功能進行 SSO 設定、使用者對應和核心驗證流程，避免在 Commerce 執行階段內維護自訂驗證邏輯。

• 最小修改，最大安全性

  我們不會重寫或分叉 SSO 模組，而是透過 App Builder 套用小型的目標擴充功能，讓原始模組完全可升級。

• API 優先整合模型

  由於所有通訊都嚴格依賴 SSO API，因此我們會與 PHP 模組的內部實作詳細資料解耦。即使模組發生內部變更，只要 API 合約有效，我們的整合就會維持穩定。

2. 協調層：Adobe API Mesh

我們整合架構的核心是 Adobe API Mesh，它是平台所涉所有業務系統之間的中心協調與通訊中樞：

• Commerce 店面 (作為前端)

• Adobe Commerce

• 績效指數方法

• ERP

• 外部驗證服務

• 和所有 App Builder 應用程式

與其使用 EDS Frontend 或 Adobe Commerce 建立與這些系統的點對點直接整合，所有通訊都會透過 API Mesh 路由。

使用 Adobe API Mesh 的主要優點

• 單一整合介面
  系統只需要「知道」一個後端整合端點：網格。每個外部相依性都會隱藏在統一 API 閘道後面。

• 一致的 API 合約
  所有系統都透過定義良好的合約和版本化合約進行通訊，消除了隱藏的耦合性，並大幅降低中斷變更的風險。

• 後端系統之前的完全解耦
  PIM、ERP、驗證服務與 App Builder 應用程式之間完全隔離。任何系統都可以獨立演化，不必強迫整個環境進行變更。

• 集中式安全性和治理
  驗證、授權和流量控制會在網格層級強制執行，而不是分散在多個自訂整合中。

• 簡化的 Commerce 程式碼庫
  Adobe Commerce 或 Frontend 不再包含複雜的整合邏輯。它們只會使用 Mesh 公開的 API，讓 PHP 層保持精簡和交易型。

3. 店面與 SSO 層使用的 App Builder 服務

這些服務由 Commerce 店面和 SSO 層直接使用，而非由 Adobe Commerce 使用，這可讓關鍵商業邏輯獨立於 Commerce 執行階段運作。

客戶資料接收器 (SSO → App Builder)

此服務會接收並同步來自 SSO 層的客戶資料，而不會影響店面或 Commerce 績效。使用 App Builder 可確保安全處理、非同步擴充性，以及 Adobe Commerce 上的零部署相依性。

每個客戶的產品可用性 (店面 → App Builder → PIM)

在請求觸達 Commerce 之前，產品可用性會根據客戶內容和 PIM 資料即時解決。App Builder 可讓此邏輯獨立擴充，並保護 Commerce 免受繁重的外部相依性負載的影響。

公司資料驗證 (Dun & Bradstreet) (店面 → App Builder → 第三方)

驗證會透過 App Builder + API Mesh 直接從店面觸發，並使用第三方服務進行驗證，這會保持外部服務延遲和失敗與 Adobe Commerce 完全隔離。

外部 ID 重新導向引擎 (店面 → App Builder)

來自外部系統的傳入流量在進入店面之前會透過 App Builder 處理和對應，如此可實現安全流量標準化、彈性重新導向規則，以及 Commerce 核心的零風險。

4. Commerce 店面預先轉譯：SEO 不會影響 UX

AEM Commerce 店面是現代化的前端驅動應用程式，重度依賴 JavaScript 在瀏覽器中載入產品資料。雖然這可提供絕佳的使用者體驗，但同時也帶來傳統 SPA 挑戰：

搜尋引擎爬蟲和無瀏覽器系統通常收到幾乎空白的 HTML，因為它們無法可靠地執行 JavaScript。

為了解決這項挑戰，我們實作了 AEM Commerce 預先轉譯，這是以 App Builder 為基礎的官方 Adobe 解決方案。

預先轉譯在我們的架構中如何運作

App Builder 預先轉譯應用程式：

• 直接從 Adobe Commerce 目錄服務讀取產品資料

• 根據預先定義的範本產生完全水合的 HTML 頁面

• 將預先轉譯的輸出儲存在自己的 Blob 儲存體中

Commerce 店面接著會設定成使用此儲存體作為覆蓋來源。當出現下列任一情況時：

• 搜尋引擎爬蟲

• 任何無瀏覽器用戶端請求產品 URL

它會立即收到包含真實產品資料的完整轉譯 HTML 回應，而不會執行任何 JavaScript。

同時：

• 一般使用者仍會獲得標準的 SPA 體驗，並在瀏覽器中即時轉譯 PDP。

為什麼 App Builder 是此處的核心促進因素

App Builder 是整個預先轉譯流程的中央控制平面。它可讓我們定義：

• 資料擷取頻率

• 包含哪些產品和地區

• HTML 和 JSON-LD 結構

• SEO 後設資料產生

所有這一切都可透過小型 App Builder 設定變更進行調整，而主店面或 Adobe Commerce 不會停機。

Adobe 也提供用於預先轉譯 App Builder 應用程式的入門套件，讓我們能夠在極短的時間內準備好生產解決方案，並立即實現 SEO 提升。

此方法的主要優點

• 大量 SEO 改善
  爬蟲會收到包含結構化資料而非空白 HTML 的完整轉譯產品頁面。

• 不影響店面績效
  一般使用者保持快速且動態的 SPA 體驗。

• 零風險的部署模型
  所有預先轉譯邏輯會在 Adobe Commerce 和店面執行階段之外執行。

• 透過 App Builder 的完整控制
  預先轉譯規則、資料模型和排程無需重新部署平台即可調整。

5. 訂單與 ERP 同步：設計上是非同步的

結帳和訂購位置在 Adobe Commerce 中仍會維持完整處理，保留資料完整性和交易一致性。建立訂單後，匯出流程會由 App Builder 上建立的專用排程訂單匯出工具接管。

此匯出工具會在店面和 Commerce 請求生命週期之外，以非同步方式將訂單同步至 ERP。

此方法的主要優點

• 店面執行時間與 ERP 可用性完全解耦
  即使 ERP 速度緩慢或暫時無法使用，客戶仍可繼續下訂單，不會造成中斷。

• 由於下游故障，無法封鎖結帳
  訂單建立不再依賴即時 ERP 回應，消除了轉換風險的主要來源。

• 安全的重試和受控制的資料流程
  App Builder 允許排程的執行、重試機制和故障處理，而不會影響 Commerce 績效。

• 獨立擴充和部署
  訂單同步可以根據磁碟區進行擴充，而不會對 Adobe Commerce 造成任何重新部署或績效的副作用。

為何不完全移至 App Builder？

最早也是最重要的架構決定之一，不是將 App Builder 視為 PHP 模組的整體替代，也不是將所有內容預設為 PHP「因為這是一直以來採取的方式」。

相反地，每個需求都經過簡單的篩選：

保留在 PHP 中的項目 (30%)

我們只將 PHP 自訂保留在它們真正所屬的位置：

• 結帳和訂購位置調整

• 定價、購物車和報價邏輯

• 深層 GraphQL 和對績效敏感的鉤點

• 延遲必須接近零且完全同步的區域

在這些地方，直接存取資料庫、與 Commerce 內部緊密耦合，以及請求生命週期控制仍然是絕對合理的。

移至 App Builder 的項目 (70%)

其他所有內容已移出：

• 身分識別和 SSO 協調

• 客戶與公司驗證

• 產品可用性解決方案

• 外部系統協調

• ERP 與第三方整合

• 重新導向引擎和自動化

• 背景工作與排程器

這些是 PHP 模組過去存在的所有問題：

• 緊密耦合

• 硬部署

• 不良故障隔離

• 以及有限的擴充能力

獲得的主要優點

透過將大約 70% 的業務和整合邏輯轉移至 App Builder，我們從根本上改變了平台的建立、部署和操作方式。不僅在架構品質方面，在傳送速度、系統穩定性及長期成本控制方面，影響都顯而易見。

獨立部署

由於 App Builder 負責處理大部分的整合與業務工作流程，因此大部分的變更不再需要完全重新部署 Adobe Commerce。整合更新、驗證和背景流程可獨立部署，進而大幅減少：

• 發行風險

• 部署時間

• 團隊之間的協調開銷

單是這一點就成為了日常營運中最大的生產力提升之一。

在最重要的地方提供更好的擴充能力

以前，流量尖峰位於：

• 可用性檢查

• 公司驗證

• 或外部 API 呼叫

會直接影響 Commerce 的績效。

現在，這些工作負載在 App Builder 中可獨立擴充。因此：

• 結帳績效保持穩定

• Commerce 資源僅保留給交易型工作負載

• 以及無法預測的第三方流量不再威脅到轉換率

真正的故障隔離

最關鍵的改善之一是故障限制。第三方系統發生延遲、降級或中斷時：

• App Builder 會吸收影響

• 在該處套用重試和遞補邏輯

• Adobe Commerce 仍可全面運作

這有效消除了先前導致部分或完整店面停機的整類事件情境。

更乾淨的程式碼擁有權和明確的責任

此平台現在具有明確的架構界限：

• Adobe Commerce → 交易型邏輯、結帳、定價、購物車

• App Builder → 整合、協調、驗證、背景工作

這種分隔會：

• 簡化新開發人員的入門流程

• 減少跨團隊的相依性

• 並防止高度整合的自訂程式碼對 Commerce 核心的逐步侵蝕。

從設計上考慮到未來的發展

此混合式架構完全符合 Adobe 長期 SaaS、API 優先且可自由搭配組合的商務策略。藉由外部化大部分的自訂邏輯：

• 平台升級變得更安全

• 降低程式碼層級的廠商限制

• 解決方案已準備好移至 Adobe Commerce as a Cloud Service

我們不僅解決了目前的需求，還建立了一個在結構上已經為 Adobe Commerce 的轉型做好準備的平台。