本文介绍如何通过 Adobe Developer App Builder 重新思考 Adobe Commerce 的可扩展性，并用更具可扩展性的架构替换大部分自定义 PHP，从而改进可扩展性、稳定性和可维护性，这些改进专为实际生产环境中的长期增长而设计。

简介

多年来，PHP 的可扩展性一直是 Adobe Commerce 自定义的支柱。 但随着云原生架构的成熟，更好的替代方案也应运而生。在为欧洲一家领先的出行与金融服务提供商实施的最新项目中，我们用 Adobe 的云原生扩展平台 App Builder 取代了很大一部分传统的 Adobe Commerce 模块开发。我们通过利用运行时操作（无服务器功能）、事件和 API 来实现这一点，从而提供更具可扩展性和可维护性的解决方案。本文详细分析了这一决策背后的原因、架构结构以及经验教训。

概述

采用 Adobe Commerce 的 API 优先方法可以逐步进行，通过评估哪些功能作为云原生应用程序在核心 Adobe Commerce 平台之外运行最有益，并优先迁移这些功能。

这个过程带来了一个清晰的结果：

• 约 70% 的功能通过使用 App Builder 实现

• 约 30% 的功能仍作为原生 Adobe Commerce PHP 自定义项保留

这种平衡使我们能够将与原生逻辑和结帐相关的逻辑保留在 Commerce 中，同时将集成、验证、后台处理以及编排卸载到 App Builder，因为在这些方面，App Builder 的扩展性、隔离性和部署灵活性优势得以充分发挥。

最终的架构（参见下图，仅概述了 App Builder 扩展）体现了这种混合方法：Adobe Commerce 仍然是交易型核心，而 App Builder 则充当了集成和自动化的骨干。该策略通过事件驱动的流程和 API 网格（Adobe 的 API 编排服务）连接了身份标识 (SSO)、PIM、ERP、第三方服务以及自定义商业逻辑。

架构演练：混合模型的工作方式

该解决方案的核心是 Adobe Commerce，它将完成最擅长的工作：目录、定价、购物车、结账和订单下达。我们特意保持交易型核心的干净和稳定，避免在 Commerce 运行时中进行不必要的自定义。

该核心的一切（身份标识、数据验证、可用性逻辑、后台处理和第三方集成）均通过 App Builder 和 Adobe API Mesh 进行处理。

购物者体验基于新的 Commerce 店面（由 Edge Delivery Services 提供支持）构建。

1.进入层：CDN、Commerce Storefront 和身份标识

来自常规网站访客的所有流量首先会着陆 CDN + Edge Delivery Service，该服务可确保在任何请求到达后端系统之前实现最佳性能、安全性和全局交付。

身份验证通过 Keycloak SSO 进行处理，集成方式为：

• App Builder SSO 集成

• Marketplace 提供的用于核心 SSO 配置和设置的标准 Adobe Commerce PHP 模块

• 这种设置使我们能够将平台稳定性与云原生灵活性相结合。

此方法的主要优势

• 通过经验证的 Marketplace 模块进行集中身份管理

  我们依赖得到良好支持的 Adobe Commerce 扩展来进行 SSO 配置、用户映射和核心身份验证流程，从而避免在 Commerce 运行时内维护自定义身份验证逻辑。

• 最小修改，最大安全性

  我们没有重写或复刻 SSO 模块，而是通过 App Builder 仅应用了少量、有针对性的扩展，从而使原始模块保持完全可升级的状态。

• API 优先集成模型

  由于所有通信都严格依赖 SSO API，我们得以与 PHP 模块的内部实现详细信息解耦。即使模块在内部更改，但只要 API 合同有效，我们的集成就会保持稳定。

2.编排层：Adobe API Mesh

我们的集成架构的核心是 Adobe API Mesh，它充当该平台涉及的所有业务系统之间的中心编排和通信中心：

• Commerce Storefront（作为前端）

• Adobe Commerce

• PIM

• ERP

• 外部验证服务

• 以及所有 App Builder 应用程序

EDS 前端或 Adobe Commerce 并未与这些系统建立直接的点对点集成，而是将所有通信都通过 API Mesh 进行路由。

使用 Adobe API Mesh 的主要好处

• 单个集成表面
  系统只需要“知道”一个后端集成端点：即网格 (Mesh)。每个外部依赖项都隐藏在统一的 API 网关中。

• 一致的 API 合同
  所有系统都通过定义良好且版本化的合同进行通信，这消除了隐藏的耦合性，并显着降低了破坏性变更的风险。

• 后端系统之间完全解耦
  PIM、ERP、验证服务和 App Builder 应用程序之间完全分离。任何系统都可以独立演进，而不会在整个环境中强制进行更改。

• 集中式安全和治理
  身份验证、授权和流量控制在 Mesh 级别强制执行，而不是分散在多个自定义集成中。

• 简化的 Commerce 代码库
  Adobe Commerce 或 Frontend 不再包含复杂的集成逻辑。它们只使用 Mesh 暴露出的 API，从而使 PHP 层保持精简和专注于事务处理。

3.Storefront 和 SSO 层使用的 App Builder 服务

这些服务直接由 Commerce Storefront 和 SSO 层使用，而不是由 Adobe Commerce 使用，这使得关键商业逻辑独立于 Commerce 运行时运行。

客户数据接收器 (SSO → App Builder)

此服务接收并同步来自 SSO 层的客户数据，而不影响店面或 Commerce 的性能。使用 App Builder 可以确保安全处理、异步可扩展性，并且对 Adobe Commerce 零部署依赖。

每个客户的产品可用性 (Storefront → App Builder → PIM)

在请求到达 Commerce 之前，产品可用性会根据客户上下文和 PIM 数据实时得到解决。App Builder 允许此逻辑独立扩展，并保护 Commerce 免受繁重的外部依赖负载的影响。

公司数据验证 (Dun & Bradstreet)（Storefront → App Builder → 第三方）

验证直接从店面通过 App Builder + API Mesh 触发，并使用第三方服务进行核实，这使得外部服务的延迟和故障与 Adobe Commerce 完全隔离。

外部 ID 重定向引擎 (Storefront → App Builder)

来自外部系统的入站流量在进入店面之前会通过 App Builder 进行处理和映射，这样可以实现安全流量标准化、灵活重定向规则，并且不会给 Commerce 核心带来任何风险。

4.Commerce Storefront 预渲染：不影响 UX 前提下的 SEO

AEM Commerce 店面是一个现代化的前端驱动应用程序，它严重依赖于 JavaScript 在浏览器中加载产品数据。虽然这提供了卓越的用户体验，但它带来了经典的 SPA 挑战：

搜索引擎爬虫和无浏览器系统通常收到几乎空的 HTML，因为它们无法可靠地执行 JavaScript。

为了解决此挑战，我们实施了 AEM Commerce 预渲染，这是一项基于 App Builder 构建的官方 Adobe 解决方案。

预渲染在我们的架构中如何工作

App Builder 预渲染应用程序：

• 直接从 Adobe Commerce 目录服务中读取产品数据

• 根据预定义的模板生成完全水合的 HTML 页面

• 将预渲染的输出存储在其自己的 blob 存储中

然后，将 Commerce Storefront 配置为将此存储用作叠加源。出现以下任一情况时：

• 搜索引擎爬虫

• 任何无浏览器客户端请求产品 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 和 Storefront 运行时之外运行。

• 通过 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 的转型做好准备的平台。