Composable Commerce: The Future of eCommerce Architecture

Explore composable commerce and MACH architecture—how API-first, headless components are replacing monolithic platforms and enabling faster, more flexible eCommerce.

E
ECOSIRE Research and Development Team
|2026年3月19日3 分钟阅读535 字数|

可组合商务:电子商务架构的未来

在电子商务历史的大部分时间里,占主导地位的技术模型是单一平台——单一供应商提供所有功能:店面、产品目录、购物车、结账、支付、订单管理和内容管理。 Magento、Salesforce Commerce Cloud 和传统 SAP Hybris 等平台体现了这种方法。购买平台;在其限制范围内进行配置;使用批准的插件进行扩展。

整体模型一度提供了上市速度和操作简单性。但随着电子商务变得更加复杂(多渠道、国际市场、大规模个性化、快速功能迭代),单体的僵化成为一种竞争负担。以季度为单位的平台发布周期无法跟上以周为单位的竞争要求。

可组合商务——从同类最佳的、API 连接的组件而不是单一的整体平台构建电子商务功能——已成为架构响应。到 2026 年,它将成为企业和快速增长的中端市场商家选择的主导架构。

要点

  • 可组合的商务将电子商务整体分解为专门的、API 连接的服务
  • MACH 原则(微服务、API 优先、云原生、无头)定义可组合架构
  • Shopify 的店面 API 和无头商务功能使其成为许多部署的可组合基础
  • 典型的可组合堆栈:无头店面 + 商务引擎 + 搜索 + CMS + 个性化 + PIM
  • 2026 年,65% 收入超过 10 亿美元的大型零售商正在追求可组合架构
  • 从整体式迁移到可组合式的迁移最好使用“strangler Fig”模式逐步完成
  • 对于高复杂性商家来说,总体拥有成本最初较高,但长期较低
  • 开发人员经验和功能上线时间是可组合的主要竞争优势

什么是组合式商务?

可组合商务将软件工程的“关注点分离”原则应用于电子商务平台架构。不是由一个系统包揽所有事情,而是通过 API 连接,每个专业服务都能出色地完成一件事。

MACH 联盟成立于 2020 年,旨在倡导可组合架构,通过四个原则对其进行定义:

微服务:将各个业务能力打包为独立的服务。购物车管理、库存检查、促销计算和税收计算是单独的服务,而不是一个整体中的功能。每个服务都可以独立开发、部署和扩展。

API 优先:每个服务都通过记录良好的 API 专门公开其功能。没有私有接口或反向通道集成。这使得服务可以互换——如果有更好的搜索服务可用,您可以将其交换而无需接触其他组件。

云原生:服务旨在利用云基础设施——自动扩展、托管服务、无服务器执行、全球分发。与自我管理的基础设施相比,这可以以更低的运营成本提供弹性容量。

无头:表示层(店面)与商务后端完全解耦。前端通过 API 使用后端功能。这使得任何表示层(React/Next.js Web 应用程序、移动应用程序、语音界面、信息亭、数字户外显示器)都能够使用相同的商务功能。


可组合的商务堆栈

典型的可组合商务实现跨多个功能类别组装专业服务:

店面和体验层

店面是作为现代 JavaScript 应用程序构建的 - 最常见的是使用 React/Next.js,但也使用 Vue.js、Nuxt 和 Remix。这是面向客户的层:产品显示、导航、搜索界面、结账 UI 和帐户管理。

可组合店面的领先框架:

  • Next.js Commerce:Vercel 的开源 Next.js 入门工具,集成了 Shopify、BigCommerce 和 WooCommerce
  • Hydrogen:Shopify 基于 React 的店面框架,构建于 Remix 之上,专为 Shopify 店面 API 设计
  • Medusa.js:具有无头店面支持的开源商务基础设施
  • Vue Storefront (Alokai):具有预构建集成的与框架无关的可组合商务加速器

商务引擎

商务引擎处理核心业务逻辑:产品目录、定价、促销、购物车、结账和订单管理。这是商务堆栈的“后端”。

领先的可组合商务引擎:

  • Shopify Plus(无头):Shopify 的 Storefront API 支持以 Shopify 成熟的商务引擎作为后端进行无头部署。处理订单、库存、付款、履行和多地点。
  • commercetools:云原生、API 优先的商务平台。深度配置能力,强大的多币种/多语言支持。最初的可组合商业先驱。
  • BigCommerce:无头友好,具有强大的中端市场功能集,并且比商务工具更低的运营开销。
  • Elastic Path:高度灵活的 API 优先平台,具有强大的 B2B 商务功能。
  • Medusa.js:具有自托管功能的开源替代方案。

搜索和发现

产品发现——搜索、过滤、导航、推荐——极大地影响转化率。可组合架构允许最佳搜索,而不是受限于平台的内置搜索。

  • Algolia:市场领先的托管搜索,具有人工智能驱动的相关性、即时结果和销售控制
  • Elastic App Search:具有托管选项的开源基础;技术灵活性强
  • Constructor.io:专门针对电子商务的人工智能搜索和发现,具有强大的 A/B 测试
  • Searchspring:专注于中端市场,具有强大的推销和个性化功能

内容管理 (CMS)

Headless CMS 独立于商务引擎来管理编辑内容(登陆页面、博客文章、活动内容、产品故事)。这使得内容团队能够在不依赖工程的情况下工作。

  • Contentful:市场领先的无头 CMS,具有强大的 API 和内容建模灵活性
  • Sanity:开发人员友好,具有实时协作和出色的 React 集成
  • Prismic:更简单的无头 CMS,具有用于基于组件的布局的强大切片模型
  • Storyblok:可视化编辑器,提供 CMS 灵活性和可视化编辑体验

个性化和 A/B 测试

个性化服务提供个性化体验——产品推荐、动态定价、个性化内容——无需进行全栈更改。

  • 动态产量(麦当劳):实时个性化和实验平台
  • Monetate:人工智能驱动的电子商务个性化,具有强大的多变量测试
  • Nosto:电子商务特定的个性化,包括推荐、弹出窗口和动态内容

产品信息管理 (PIM)

对于拥有大型、复杂产品目录的商家(尤其是 B2B 或多属性零售行业),专用的 PIM 可以管理产品数据质量和分发。

  • Akeneo:领先的开源和云 PIM 平台
  • Contentserv:具有强大数字资产管理集成的企业 PIM
  • inRiver:具有强大的源管理功能的 SaaS PIM

订单管理系统 (OMS)

复杂的全渠道履行——从商店发货、在线购买店内提货 (BOPIS)、代发货、分批发货——需要独立于商务引擎的专用 OMS。

  • 流畅的商务:具有强大分布式订单管理功能的云原生 OMS
  • Manhattan Active Omni:适用于复杂零售运营的企业 OMS
  • Radial:面向中端市场商家的端到端履行和 OMS

为什么组合式商务会获胜

功能交付速度

单体应用的发布周期(同时在所有组件上部署完整的平台更新)意味着单个有问题的功能可能会延迟整个发布。可组合服务独立部署;新的搜索功能可以在不涉及结账服务的情况下上线。

采用可组合架构的商家报告称,对于变更的交付时间为几天到几周,而在整体平台上则需要数月时间。在快速变化的竞争市场中,这种差异很快就会加剧。

同类最佳的能力

没有一个平台在所有方面都表现出色。最好的搜索引擎不同于最好的CMS,也不同于最好的个性化引擎。可组合架构允许为每个功能选择最佳工具,而不是接受整体中最薄弱的组件。

这对于竞争激烈的垂直领域的商家来说尤其重要,因为特定的功能(搜索准确性、个性化深度、内容速度)是真正的竞争优势。

技术长寿

单一平台造成了深深的供应商依赖性——迁移的成本非常高,因为平台处理所有事情。可组合架构本质上更具可移植性。可以交换单个服务而无需更换整个堆栈。

这降低了长期平台风险并保留了与供应商的谈判筹码。

全渠道原生

无头架构本质上是全渠道的。相同的商务 API 为网络店面、移动应用程序、店内信息亭、语音商务集成以及任何未来渠道提供服务。整体平台需要为每个新渠道进行定制集成工作。


Shopify 可组合方法

Shopify 已从托管 SaaS 平台发展成为功能齐全的可组合商务引擎。 Storefront API(REST 和 GraphQL)使无头店面能够使用 Shopify 作为商务后端,同时构建完全自定义的表示层。

氢气和氧气

Shopify 的 Hydrogen 框架提供了一个针对 Shopify Storefront API 优化的基于 React 的开发环境。 Oxygen 是 Shopify 针对 Hydrogen 店面的边缘托管平台 - 在全球范围内部署,响应时间低于 100 毫秒。

Hydrogen 和 Oxygen 共同提供了一个专门构建的可组合商务堆栈:Shopify 成熟的商务功能(支付、订单、库存、履行)以及完全定制的高性能店面。对于已在 Shopify 上的商家来说,这是实现可组合商务的最快途径。

Shopify 市场和全球商务

Shopify Markets 提供多货币、多语言和特定于市场的目录和定价管理,这是国际商家的一项关键功能。与无头架构相结合,Shopify Markets 支持由单个 Shopify 后端提供支持的特定市场店面(具有独特的用户体验、语言、货币和产品选择)。

Shopify 的应用程序生态系统作为可组合层

Shopify 的应用程序生态系统(8,000 多个应用程序)本身就是一种可组合架构 - 专业服务(评论、忠诚度计划、订阅、追加销售)通过定义的 API 与 Shopify 核心集成。与平台插件的主要区别在于 API 优先的设计:明确定义的集成点而不是单一的代码包含。


迁移策略:绞杀者无花果图案

在不中断业务的情况下从单一电子商务平台迁移到可组合架构需要经过深思熟虑的迁移策略。 “绞杀无花果”模式——以逐渐取代寄主树的藤蔓命名——是行之有效的方法。

绞杀无花果的工作原理

绞杀者无花果方法不是并行构建新的可组合系统并进行大爆炸切换,而是逐渐用可组合服务替换部分单体系统:

  1. 识别接缝:找到新服务将拦截之前发送到单体应用的请求的 API 或集成点
  2. 构建新服务:将新功能实现为可组合服务
  3. 逐步路由流量:开始将一定比例的流量发送到新服务,最初用于低风险场景
  4. 验证和扩展:监控性能和正确性;逐步增加新服务的流量
  5. 退役单体组件:一旦新服务处理100%的流量,删除相应的单体能力

应用到电子商务,这可能看起来像:

  • 第 1 阶段:用 Algolia 替换单体搜索(风险最小,对转化影响较大)
  • 第 2 阶段:在 Next.js 上构建新的无头店面,路由 10% 的流量
  • 第 3 阶段:将内容管理迁移到无头 CMS
  • 第 4 阶段:将无头店面扩展至 100% 并停用旧前端
  • 第 5 阶段:评估商务引擎本身(目录、购物车、结帐)是否需要更换

总拥有成本考虑因素

可组合商务的总拥有成本 (TCO) 经常被误解。

初始成本较高

组合式部署的初始成本比单体平台更高,原因如下:

  • 集成复杂性:连接多个专业服务比配置单个平台需要更多的集成工作
  • 前端开发:构建自定义店面比配置平台模板需要更多的工程投入
  • 多个供应商关系:管理 5-10 个专业供应商比管理 1 个更复杂

对于没有复杂需求的中小型商户来说,这些成本往往大于收益。可组合商业具有天然的最小可行规模。

降低长期成本(大规模)

对于年收入超过 1000 万美元或具有高度复杂性(多品牌、国际、B2B)的商家,可组合 TCO 在 3-5 年内通常较低,因为:

  • 同类最佳服务的性能通常优于整体式服务,可提高转化率和保留率
  • 独立扩展意味着为您需要的容量付费,而不是在整个整体上付费
  • 功能交付速度意味着更快地捕捉收入机会
  • 供应商谈判杠杆随着时间的推移降低服务成本

常见问题

组合式商务的最小可行规模是多少?

当您的商务需求的复杂性超出了单体平台能够优雅处理的范围,或者当您的开发团队的速度受到单体平台的发布周期的显着限制时,组合式商务就有意义了。作为粗略指导:年收入超过 1000 万美元、具有复杂要求(多渠道、国际、复杂个性化、B2B)或高功能速度要求的商家通常是不错的选择。低于此阈值,配置良好的整体平台(Shopify Plus、BigCommerce)通常可以提供更好的价值和更低的操作复杂性。

Shopify Headless(氢)可组合商业吗?

是的,在满足 MACH 定义原则(API 优先、无头、云原生)的意义上。 Shopify Storefront API 提供商务 API; Hydrogen 提供无头店面框架; Oxygen 提供云原生边缘托管。您可以通过其他可组合服务(用于搜索的 Algolia、用于 CMS 的 Contentful、用于个性化的 Nosto)来扩展此功能。关键的限制是 Shopify 本身仍然是一项托管服务 - 您具有表示层和扩展层的可组合性,但核心商务引擎 (Shopify) 无法在不从 Shopify 迁移的情况下用不同的后端替换。

我们如何使用无头/可组合店面处理 SEO?

SEO 是无头店面的一个关键考虑因素。 JavaScript 渲染的内容需要服务器端渲染 (SSR) 或静态站点生成 (SSG) 才能被搜索引擎可靠​​地索引。 Next.js 和 Remix 都原生支持 SSR/SSG。无头的关键 SEO 要求:确保所有产品和类别页面都在服务器端呈现,在所有页面上实施适当的元标记和结构化数据 (JSON-LD),确保页面加载性能满足 Core Web Vitals 阈值(无头店面通常明显优于 CWV 上的整体模板),并为国际部署正确实施规范 URL 和 hreflang。

可组合商务项目中最大的实施风险是什么?

最大的风险是:范围低估(可组合集成花费的时间比预期更长,特别是对于复杂的商业逻辑)、优化不佳的 API 调用导致的性能回归(过多的顺序 API 调用会产生延迟 - 使用 GraphQL 或 API 聚合进行批处理)、跨服务的数据一致性挑战(确保库存、定价和产品数据在搜索、商业引擎和 PIM 中保持一致)以及“集成税”(每个服务都增加了必须维护和监控的集成)。与以前交付过可组合项目的经验丰富的系统集成商一起缓解压力,进行严格的性能测试和仔细的 API 设计,以最大程度地减少干扰。

可组合商务平台如何处理跨服务的促销和折扣?

可组合架构中的促销和折扣逻辑可以存在于商务引擎(Shopify 的折扣 API、commercetools 促销 API)、专用促销服务中,也可以进行分发。主导模式是将促销逻辑集中在商务引擎中,促销结果(折扣金额、应用代码)通过 API 显示到店面。对于具有分级定价、合同定价和批量折扣的复杂 B2B 定价场景,专用的 CPQ(配置报价)服务可能比较合适。确保在使用商务 API 的所有渠道中测试促销逻辑 - 跨渠道应用的折扣不一致是常见的可组合商务质量问题。


后续步骤

可组合商务代表了电子商务架构的未来,对于那些具有增长雄心和单一平台无法有效满足的复杂性要求的商家来说。战略问题不在于是否可组合,而在于何时以及如何。

ECOSIRE 的 Shopify 实施服务 包括无头和可组合的商业架构设计、基于 Hydrogen 的自定义店面开发以及与整个可组合堆栈中的最佳服务集成。我们的团队为多个垂直领域的零售商、D2C 品牌和 B2B 商家提供了可组合的商务项目。

与我们的 Shopify 和电子商务团队联系 讨论您的可组合商务策略和准备情况评估。

E

作者

ECOSIRE Research and Development Team

在 ECOSIRE 构建企业级数字产品。分享关于 Odoo 集成、电商自动化和 AI 驱动商业解决方案的洞见。

通过 WhatsApp 聊天