Excavator ACC 是本项目的客户。根据客户提供的项目背景，站点需要服务上万个 SKU。我们为它构建的是一套跨境电商站点：访客在边缘节点获得前台页面和静态资源，业务请求进入独立的电商后端，商品、订单、会话和搜索各自由适合自己的服务承载。

这篇案例只讨论公开站点和项目架构层面的工作，不披露服务器地址、账号、密钥、内部域名、订单数据、访问量或客户未公开的业务信息。文中没有把尚未完成的可用性、排名、转化或营收结果写成项目成果；这些需要在正式运行后，按约定指标和观察窗口验证。

先定义系统边界

当目录达到上万个 SKU，首页只是访客能看到的部分。工程上需要同时回答几个问题：商品数据如何读取，分类和搜索如何分页，购物车和结账如何保持动态，搜索索引如何更新，图片如何交付，以及后台任务变慢时会不会影响用户下单。

我们先确定了四条边界：前台负责交付和展示，Medusa 负责交易，数据服务留在受控网络内，索引与缓存可以重建但不能取代订单数据。后面的 Cloudflare、Next.js、R2、Medusa 和数据服务，都是围绕这四条边界落位的。

图 1：访客请求经过 Cloudflare 边缘后，前台和业务 API 进入不同的处理路径。

前台交付与缓存边界

面向全球买家的站点，首屏请求不应把所有工作都推给源站。我们把 Next.js 前台放在 Cloudflare 的边缘运行环境中，把页面渲染、静态资源和可缓存内容尽量放到离访客更近的位置；R2 用于承载 OpenNext 的增量缓存和站点媒体资产。

缓存边界随页面职责变化。产品介绍页、分类页和内容页可以使用 ISR 或边缘缓存；购物车、账户、结账和支付回调仍然需要动态请求，并明确禁止共享缓存。价格与库存的展示可以使用短缓存或独立请求，但下单时必须回到 Medusa 做服务端校验。

这也是 SEO 和隐私边界。把购物车状态、个人信息或临时价格写进共享缓存，会让不该共享的数据进入共享响应，也会让搜索引擎看到不稳定的页面内容。缓存策略要和页面职责一起设计，不能上线后再给所有响应套一个统一的 max-age。

把交易后端从前台交付中解耦

Medusa 负责商品、购物车、订单和交易流程，是站点的业务核心。Cloudflare Tunnel 为业务 API 提供受控的边缘入口，使源站不必直接暴露公网端口；源站内部再由反向代理把请求交给 Medusa。

项目中我们特别关注了职责边界：Store API 处理访客和购物流程，管理入口应与公开 Store API 分开保护，数据库、Redis 和 Meilisearch 只加入内部网络。对上万个 SKU 的目录，搜索写入和全量重建尤其不能占用前台请求的资源。支付 webhook、搜索同步和第三方系统连接也应采用验签、幂等、重试和可追踪的处理方式。

Tunnel 解决的是源站暴露面，不是可用性本身。如果多个服务共享同一个故障域，基础设施故障仍可能同时影响 API、数据库、缓存和搜索。我们把这项边界写进演进路线，没有把 Tunnel 直接等同于高可用。

让在线请求和后台任务各走各的资源

电商后端不只有浏览器请求。商品同步、库存更新、邮件、支付通知、搜索索引和定时任务都会消耗 CPU、数据库连接或 Redis 资源。如果它们和 Store API 共用一个进程，某个慢任务就可能把用户的请求一起拖慢。

架构演进把 Medusa 的 server 与 worker 分开：server 专注 Store API、Admin API 和交易请求；worker 负责订阅器、异步工作流、定时任务、webhook 后续处理和搜索同步。两者可以使用同一份应用镜像，但应拥有独立的进程、重启策略和监控指标。

服务拆分解决的是一个具体的运维问题：当后台队列积压时，团队可以单独观察、重启或扩展 worker，不必让前台交易接口跟着一起停掉。

缓存策略的核心是失效

对电商站点来说，缓存命中只是第一步。真正需要定义的是商品发生变化后，哪些页面必须失效。产品上下架、价格变化、促销调整、库存状态和分类变更，都可能影响商品页、分类页、搜索结果和首页模块。

针对 Excavator ACC，我们把数据链路拆成三个动作：Medusa 发出商品或库存事件，后台任务更新 Meilisearch，再调用受保护的前端再验证入口，按商品、分类或集合清理相关页面。内容型页面可以保持较长的 ISR 时间；价格和库存采用更短的读取策略，结账阶段始终以业务后端为准。

图 2：业务数据、搜索索引和页面缓存是三种不同的层，更新顺序也不同。

上万级 SKU 的压力模型

目录规模进入上万个 SKU 后，系统要处理的重点变成了变更传播和资源隔离。一次价格调整可能影响多个变体和多个地区；一次库存同步可能同时触发搜索更新、商品页失效和分类页重算；一次全量导入如果直接在 API 进程里执行，就可能占满数据库连接、内存和 CPU。

我们重点处理的是四类压力。

  • 读取压力：产品列表不能依赖无限制的深分页或一次性返回全部字段，需要明确分页、排序、筛选字段和响应体大小。
  • 写入压力：商品导入、价格更新和库存同步应进入可重试的后台任务，按批次处理，并避免同一个 SKU 被重复更新时产生无序结果。
  • 索引压力：Meilisearch 是搜索投影，不是业务真相。增量更新要能重试，全量重建要能观察进度，索引损坏时要能从 Medusa / PostgreSQL 重新生成。
  • 稳定性压力：缓存失效、搜索任务或第三方同步失败时，系统要允许局部降级；不能因为搜索暂时不可用，就让商品详情、购物车和结账一起失效。
图 3：批量任务与用户请求分离，搜索和缓存失败时仍保留业务数据与交易链路。

SEO 落在路由和数据边界上

技术 SEO 在这个项目里从路由、页面职责和链接关系开始，而不是在上线前补几组 meta 标签：产品页回答产品是什么，分类页组织产品集合，内容页解释使用场景或购买问题；首页和导航把这些页面连接起来，避免所有内容挤进一个菜单。

前台采用边缘渲染和增量缓存，也要求我们认真处理 canonical、hreflang、结构化数据、缓存响应头和动态页面边界。公开页面可以被发现和复用；账户、购物车、结账和 webhook 不能因为“方便缓存”而进入共享索引或共享响应。

站内链接也是产品路径的一部分：读者可以从技术 SEO 服务了解我们处理的问题，从方法论了解诊断、实施和验证，再进入相关案例或定制软件服务。每条链接都对应下一步判断，而不是为了填满页面。

交付的边界和下一阶段

图 4：先建立职责边界和恢复能力，再按订单量与运维预算增加副本和托管能力。

Excavator ACC 项目留下的是一组可继续演进的边界：前台可以独立优化，Medusa 可以拆分 server 与 worker，PostgreSQL 和 Redis 可以逐步迁移到更适合生产的托管服务，Meilisearch 可以在需要时全量重建，Cloudflare Tunnel 也可以从单 connector 演进到多 connector。

这些都是可执行的演进路径，不是已经发生的增长结果。上线后真正值得跟踪的指标包括前台缓存命中率、API P95 延迟、后台任务失败率、搜索同步延迟、订单创建成功率和支付 webhook 异常；只有这些指标拥有基线、负责人和观察窗口，案例才有资格继续写下一章。

如果你正在构建一个需要兼顾跨境访问、产品目录、交易流程和长期维护的独立站，可以先从一个关键页面类型或一条业务链路开始评估。我们的SEO 增长服务适合处理搜索结构、内容和技术实施之间的连接；如果项目还涉及前台应用、业务 API 或内部工具，也可以了解定制软件服务。