[!info] related notes

• 所属 MOC: Shopify MOC
• 前置概念: Shopify
• 核心组件: Shopify 主题, Shopify 应用
• API 层: Shopify Admin API, Shopify Storefront API

Shopify 架构

一句话定义

Shopify 采用可组合商务架构（Composable Commerce），将店铺前台、收银台、支付、物流、分析等核心基础设施集成在统一堆栈中，同时通过开放 API 支持灵活定制。

核心机制 / 工作原理

1. 统一商务堆栈（Unified Commerce Stack）

Shopify 的架构围绕单一数据源（Single Source of Truth） 设计：

┌─────────────────────────────────────────────┐
│         Shopify 统一数据层                    │
│  (产品、库存、订单、客户、支付、物流)           │
└─────────────────────────────────────────────┘
              ↓                ↓                ↓
    ┌─────────────┐  ┌─────────────┐  ┌─────────────┐
    │  在线商店    │  │  移动应用    │  │  线下 POS   │
    │ (Storefront) │  │  (Mobile)   │  │   (POS)    │
    └─────────────┘  └─────────────┘  └─────────────┘
              ↓                ↓                ↓
    ┌─────────────┐  ┌─────────────┐  ┌─────────────┐
    │ 社交媒体销售  │  │ 第三方市场   │  │  自定义渠道  │
    │ (FB/IG/TikTok)│ │ (Amazon/eBay)│ │  (API集成)  │
    └─────────────┘  └─────────────┘  └─────────────┘

为什么这样设计：

• 数据一致性：所有渠道共享同一库存、订单、客户数据，避免数据孤岛
• 实时同步：线上卖出一件商品，线下库存立即更新
• 简化管理：商家只需在一个后台管理所有渠道

2. 可组合架构的三个层级

Shopify 的架构分为三层：

层级 1：核心基础设施（Shopify 托管）

不可变更，由 Shopify 负责：

• 订单处理引擎
• 支付处理（PCI 合规）
• 数据存储和备份
• 安全和性能优化
• 全球 CDN

商家获得的价值：零运维负担，自动扩展，99.99% 正常运行时间

层级 2：可配置层（低代码/无代码）

通过 Shopify 后台配置：

• 产品和分类管理
• 定价和促销规则
• 运费和税费设置
• 支付方式选择
• 主题外观定制

商家获得的价值：快速上线，图形化操作，无需编程

层级 3：可编程层（开发者定制）

通过代码扩展：

• 主题开发：Liquid 模板定制店铺前端
• 应用开发：GraphQL/REST API 扩展功能
• 无头商务：Storefront API 构建完全自定义前端
• Webhook：订阅事件，集成外部系统

商家获得的价值：深度定制，满足独特需求，构建竞争优势

3. API 优先的设计哲学

Shopify 的每个功能都首先设计为 API：

Shopify Admin（管理后台）
        ↓
    Admin API（GraphQL/REST）
        ↓
    统一数据层
        ↓
    Storefront API（GraphQL）
        ↓
店铺前端（主题或自定义前端）

这意味着：

• 管理后台能做的，API 都能做
• 第三方应用与官方功能使用相同的 API
• 开发者可以构建任何定制功能

为什么这样设计：

• 平等的生态系统：第三方应用不受限，能提供与官方功能同等质量的体验
• 无头商务支持：完全绕过 Shopify 默认前端，使用 Storefront API 构建自定义体验
• 系统集成：轻松连接 ERP、CRM、仓储管理等企业系统

最小例子 / 最小场景

场景：用户在线购买一件 T 恤

1. 用户浏览商店
   → Storefront API 获取产品数据
   → Liquid 模板渲染页面
   
2. 用户添加到购物车
   → 浏览器发送请求到 Shopify
   → 购物车数据存储在 Shopify 服务器
   
3. 用户进入结账
   → Shopify Checkout（托管结账页面）
   → 计算运费、税费（基于商家配置）
   
4. 用户完成支付
   → Shopify Payments 处理信用卡
   → 订单状态更新为"已支付"
   → Webhook 通知商家和物流系统
   
5. 商家发货
   → 在 Shopify Admin 标记"已发货"
   → 物流追踪号同步到客户账户
   → 发送发货确认邮件
   
6. 库存自动更新
   → 该 T 恤库存 -1
   → 所有渠道（线上、线下、社交媒体）同步

整个流程中：

• 商家无需管理服务器或数据库
• 数据自动同步到所有渠道
• 支付安全由 Shopify 保证

边界与易混淆点

1. 可组合架构 ≠ 微服务架构

Shopify 的可组合架构：

• 商家视角的”可组合”：选择主题、应用、渠道等构建块
• 底层仍是 Shopify 的统一系统，商家无需管理服务间通信

微服务架构：

• 技术视角的”可组合”：将系统拆分成独立部署的服务
• 商家需要自己管理服务间的集成、数据一致性、性能

Shopify 的优势：提供微服务的灵活性，但隐藏了复杂性

2. 托管式 ≠ 功能受限

常见误解：托管平台功能一定不如自托管灵活

Shopify 的解决方案：

• 主题开发：完全控制前端代码（HTML/CSS/JS/Liquid）
• 应用开发：通过 API 扩展任何后端功能
• 无头商务：完全自定义前端，只使用 Shopify 作为后端 API

真正的限制：

• 无法修改 Shopify 的核心结账流程（安全和合规原因）
• 无法访问底层数据库（但可以通过 API 访问所有数据）
• 无法自定义支付网关的底层逻辑（但可以集成第三方网关）

3. Shopify API ≠ 单一 API

Shopify 提供多个 API，适用于不同场景：

API	用途	访问权限
Admin API（GraphQL）	管理后台数据（产品、订单、客户）	需要商家授权
Admin API（REST）	旧版 API，功能同上	需要商家授权
Storefront API	构建自定义店铺前端	公开访问（有限权限）
Payments Apps API	自定义支付方式	需要 Shopify 审核

常见错误：用 Storefront API 尝试管理订单（应该用 Admin API）

4. 主题开发 vs 应用开发

维度	主题开发	应用开发
定制内容	店铺外观和前端逻辑	后端功能和数据处理
技术栈	Liquid + HTML/CSS/JS	任意后端语言 + GraphQL
运行位置	Shopify 服务器	自己的服务器或托管平台
收益模式	主题市场销售	应用订阅收费

详见：Shopify 主题开发 vs 应用开发

架构演进

1. 早期（2006-2015）：单体应用

• Liquid 模板系统
• 简单的主题定制
• 有限的 API

2. API 时代（2015-2020）：开放生态

• 推出 GraphQL Admin API
• Storefront API 支持无头商务
• 应用生态快速增长

3. 可组合架构（2020-至今）：灵活与性能

• Shopify 2.0 主题架构（JSON 模板、Sections、Blocks）
• Hydrogen 框架（React + 边缘渲染）
• Oxygen 托管平台（专为无头商务优化）
• 更强大的 API（Metafield、Metaobject 等）

设计动机：平衡易用性（快速上线）与灵活性（深度定制）

关键设计原则

1. 默认快速，可选复杂

• 新手可以用现成主题 + 应用快速上线
• 高级用户可以深度定制每个环节

2. 安全优先

• 结账流程托管在 Shopify，确保 PCI 合规
• Liquid 模板语言设计为”安全模板”（无法执行任意代码）
• 所有 API 请求需要认证和授权

3. 性能是功能

• 全球 CDN 自动分发静态资源
• 图片自动优化和懒加载
• 边缘计算（Oxygen 平台）降低延迟

4. 向后兼容

• 旧版 REST API 继续支持
• 主题升级提供迁移工具
• Shopify CLI 支持多个版本

Related notes

• Shopify MOC
• Shopify
• Shopify 主题
• Shopify 应用
• Shopify Admin API
• Shopify Storefront API