别一上来就 K8s · Claude Code 写电商的 4 档默认架构

Thu, 14 May 2026 00:00:00 +0000

别一上来就 K8s · Claude Code 写电商的 4 档默认架构

💡 一句话立场

你让 Claude Code 写电商网站，它给的栈是对的——但你要会问。 50 个用户和 10000 个用户，差出来的不只是流量，是整个架构。

我有一个执念：架构是长出来的，不是设计出来的。

每次看到有人 demo 阶段就上 K8s + 微服务全家桶，我都想问一句：你的数据库连过 100 次都没有吧？

下面这套是 Claude Code 在 2025 年的实战默认栈，按用户量分 4 档。第一档你今晚就能跑起来，第四档烧钱烧到怀疑人生。

👤 < 50 👥 50-200 👥👥 200-1000 👥👥👥 1000+
 🌱 🌿 🌳 🌲🌲🌲
 MVP 小型上线 中型电商 大型电商
Tier 0 Tier 1 Tier 2 Tier 3

全景一图流

 ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
 │ 🌱 Tier 0│───►│ 🌿 Tier 1│───►│ 🌳 Tier 2│───►│ 🌲 Tier 3│
 │ < 50 并发│ │ 50-200 │ │ 200-1000 │ │ 1000+ │
 │ 全栈一体 │ │+异步+缓存│ │前后端分离│ │微服务+K8s│
 └──────────┘ └──────────┘ └──────────┘ └──────────┘
 MVP 小型上线 中型电商 大型电商

下面一档一档拆。

🌱 Tier 0 · MVP / Demo（并发 < 50）

📝 用在哪

个人项目 · 原型 · 客户演示 · 小程序店铺

关键词：一把梭，几乎无运维。

你能想到的所有麻烦事——服务器、数据库、CDN、邮件——这一档都不用碰。

长什么样

 ┌─────────────────────────┐
 │ 🖥️ Vercel 一键部署 │
 │ ┌───────────────────┐ │
 │ │ ⚛️ Next.js 全栈 │ │
 │ │ (前 + 后 + API) │ │
 │ └─────────┬─────────┘ │
 └────────────┼────────────┘
 │
 ┌──────▼──────┐
 │ 🐘 Supabase │
 │ Postgres │
 └─────────────┘
 💳 Stripe Checkout (托管页)

Claude Code 默认推荐栈

层	默认推荐
前端	Next.js 15（App Router）+ TS + Tailwind + shadcn/ui
状态	`useState` / `useContext`（不上 Redux）
后端	Next.js API Routes / Server Actions
ORM	Prisma
数据库	SQLite 本地 / Supabase Postgres 免费层
鉴权	Auth.js (NextAuth v5) + Email / Google OAuth
支付	Stripe Checkout（托管页最省事）
文件	Supabase Storage / Cloudinary 免费层
部署	Vercel（一键）

这一档的本质

**全栈一体，零运维。**Claude Code 默认就给你这套，别自作聪明加东西。

🌿 Tier 1 · 小型上线（并发 50-200）

📝 用在哪

正式上线的小店 · 垂直品类 · SaaS 早期

关键词：仍是单体，但开始引入「异步」和「缓存」两个观念。

长什么样

 📱 浏览器
 │
 ▼
 ┌────────────────────┐
 │ ⚛️ Next.js (BFF) │ ◄──── 📨 Resend (邮件)
 │ + TanStack Query │
 │ + Zustand │
 └─────┬──────────────┘
 │
 ┌────▼────┐ ┌──────────┐
 │ 🐘 PG │◄──►│ ⚡ Upstash│
 │ (Neon) │ │ Redis │
 └─────────┘ └──────────┘
 │
 ▼
 ┌────────────┐
 │ ⏱️ Inngest │ ──► 订单后续动作
 └────────────┘

比 Tier 0 多了什么

层	升级点
🎨 前端	加 TanStack Query（服务端状态）+ Zustand（客户端轻量状态）
📋 表单	React Hook Form + Zod（校验和类型同源，神器）
🔁 后端	抽出 service 层 / 用 tRPC 或 Server Actions
🐘 数据库	PostgreSQL 托管（Supabase / Neon / Railway）
⚡ 缓存	Upstash Redis（serverless，按请求计费，便宜）
🔍 搜索	DB 自带 `pg_trgm` / `tsvector` 全文检索（别急着上 ES）
📨 邮件	Resend（发货通知、找回密码）
👀 监控	Sentry 免费层 + Vercel Analytics
⏱️ 队列	Inngest 或 Trigger.dev
🌐 CDN	Vercel / Cloudflare 自带

心法

缓存 + 异步是两个分水岭。 你的代码开始有「立刻返回」和「稍后处理」两条路，这是离开玩具阶段的标志。

🌳 Tier 2 · 中型电商（并发 200-1000）

⚠️ 架构拐点

这一档开始拆了。 前后端分离 + BFF 出现。能不能扛住活动峰值，就看这一档的底子打得稳不稳。

长什么样

 👤 用户
 │
 ┌───────────────────▼───────────────────┐
 │ 🌐 边缘层 Cloudflare / Vercel Edge │
 │ ┌──────────┐ ┌──────────────────┐ │
 │ │ 图片 CDN │ │ Edge Runtime │ │
 │ │ CF Images│ │ 地理路由 / A/B │ │
 │ └──────────┘ └──────────────────┘ │
 └───────────────────┬───────────────────┘
 ▼
 ┌───────────────────────────────────────┐
 │ 🎨 前端 BFF │
 │ ⚛️ Next.js (SSR + ISR + RSC) │
 └───────────────────┬───────────────────┘
 ▼
 ┌───────────────────────────────────────┐
 │ 🔁 独立 API 服务 │
 │ 🦅 NestJS / FastAPI / Hono │
 └──────┬──────────────────────────┬─────┘
 │ │
 ┌───────────▼──────────┐ ┌──────────▼──────────┐
 │ 💾 数据层 │ │ ⏱️ 异步层 │
 │ 🐘 Postgres 主从 │ │ BullMQ / Celery │
 │ ⚡ Redis 会话/购物车 │ │ Inngest / │
 │ 🔍 Meilisearch │ │ Redis Streams │
 │ 📦 R2 / S3 │ │ │
 └──────────────────────┘ └─────────────────────┘

模块拆解

前端

⚛️ Next.js（SSR + ISR）+ Edge Runtime（地理路由 / A/B）
🧩 React Server Components 分担首屏
🖼️ next/image + Cloudflare Images / imgix
📑 商详 ISR 重生成；首页/列表混合 SSR + CSR

后端：独立 API 服务出场

选型	适用
🦅 NestJS	TypeScript 体系
🐍 FastAPI	有 AI / 推荐需求
⚡ Hono / Elysia	轻量 + 边缘部署

API 风格：REST + OpenAPI 或 tRPC（全 TS 时）
BFF 层：Next.js 充当前端的 BFF，聚合下游

数据

🐘 PostgreSQL 主 + 读写分离 / 主从复制
⚡ Redis（Upstash 或自建）：会话、购物车、热门商品缓存、限流
🔍 Meilisearch / Typesense（轻量、自托管友好，别急着上 Elasticsearch）
📦 Cloudflare R2 / AWS S3

异步与事件

⏱️ BullMQ（Node）/ Celery（Python）：订单状态机、库存扣减、发邮件、生成发票
📡 事件驱动：Inngest 或自建 Redis Streams

鉴权与支付

🔐 Clerk 或 Auth.js + 自管 session
💳 Stripe + Webhook + 幂等键（敲黑板）
🛡️ 风控：Stripe Radar + 自定义规则

Tier 2 的真实痛点

不是性能，是数据一致性。 订单、库存、支付三者一旦异步化，就要开始想"如果中间挂了会怎样"。这一档就是从「能跑」到「能扛」的分水岭。

可观测性

🐛 Sentry（异常）
📜 Axiom / Better Stack（日志）
📊 PostHog（产品分析 + Session Replay）
🔭 OpenTelemetry 开始接入

部署

🚀 前端：Vercel / Cloudflare Pages
🐳 后端：Railway / Fly.io / Render（容器化）
🐘 DB：Neon（分支这个 feature 救命）/ Supabase / PlanetScale

🌲 Tier 3 · 大型电商（并发 1000+）

这已经不是 vibe coding 的范畴了

这一档让 Claude Code 一把梭基本翻车。但它仍然有一套主流默认推荐——作为参考可以，作为执行不行。

关键词：微服务 + 事件驱动 + K8s 全家桶。

长什么样（电商六大域）

 👤 海量用户
 │
 ▼
 ┌───────────────────────────────┐
 │ ☁️ Cloudflare │
 │ CDN + WAF + Bot + Rate Limit │
 └───────────────┬───────────────┘
 ▼
 ┌───────────────────────────────┐
 │ 🚪 API Gateway │
 │ Kong / APISIX │
 └───────────────┬───────────────┘
 │
 ┌──────────┬──────────┬───────┴──────┬──────────┬──────────┐
 ▼ ▼ ▼ ▼ ▼ ▼
🪪 Identity 📚 Catalog 🔍 Search 🛒 Cart 📦 Order 💳 Payment
 /Reco
 │
 ┌──────────┬──────────┬──────────┐ │
 ▼ ▼ ▼ │ │
📊 Inventory 🎁 Promo 📨 Notif │ │
 │ │ │ │ │
 └──────────┴──────────┴──────────┴───────────┬────────────┘
 ▼
 ┌──────────────────────────────────┐
 │ 📡 Kafka / NATS 事件总线 │
 └─────────────────┬────────────────┘
 ▼
 ┌──────────────────────────────────┐
 │ ⏰ Temporal 订单履约工作流 │
 └──────────────────────────────────┘

 数据层（按服务路由）:
 ─────────────────────────────────────────────────────────
 🐘 Postgres 集群 + PgBouncer ◄── Order / Inventory / Cart
 🔎 Elasticsearch + pgvector ◄── Search / Reco
 ⚡ Redis Cluster ◄── Cart / Promotion
 📈 ClickHouse ◄── Notification 埋点 / 大盘

整体架构思路

🧩 微服务 或 模块化单体（Modular Monolith） 二选一（别教条）
🔌 前后端彻底分离，多端共用 API Gateway
📖 CQRS（读写分离）在订单、库存、商品三大领域常见
📡 Event-Driven：Kafka / NATS / Redpanda 做事件总线

前端

端	默认
🖥️ Web 主站	Next.js（SSR + ISR）
📱 App	React Native / Expo
🛍️ Storefront	Vercel Commerce / Medusa / Shopify Hydrogen 思路
🧱 Design System	独立仓库（Turborepo monorepo + 自建组件库）
⚡ 边缘渲染	Cloudflare Workers / Vercel Edge

后端服务拆分（典型电商域）

服务	职责	默认技术
🪪 Identity	用户、鉴权、权限	NestJS / Go
📚 Catalog	商品、SKU、类目	NestJS / Go（读多写少）
🔍 Search	搜索、推荐	Elasticsearch / OpenSearch + 向量（pgvector / Qdrant）
🛒 Cart	购物车	Redis 主存 + Node/Go
📦 Order	订单状态机	Go / Java（Saga 模式）
📊 Inventory	库存（强一致）	Go + Redis Lua 扣减
💳 Payment	支付、对账	独立服务，严格幂等
🎁 Promotion	优惠券、活动	规则引擎
📨 Notification	邮件/短信/Push	异步 worker
✨ Recommendation	个性化	Python + 向量库

数据层

 📥 写
 ↓
 ┌────────────┐
 │ 🐘 Postgres │ ─────► 各服务垂直拆分
 │ 主库 │
 └─────┬──────┘
 │ 读写分离
 ┌─────▼──────┐
 │ 🔄 PgBouncer│
 └────────────┘

 ⚡ Redis Cluster ─── 缓存 / 会话 / 限流 / 分布式锁 / 热点 key
 🔎 ES / OpenSearch ─ 商品搜索 + 日志 (ELK)
 📈 ClickHouse ────── 埋点 / 订单分析 / 实时大盘
 📦 S3 / R2 ────────── 图片、静态资源 + CDN

消息与异步

🚌 Kafka / Redpanda / NATS JetStream：领域事件
⏰ Temporal：复杂工作流（订单履约、退款流程）—— Claude Code 在 2025 年很爱推这个

流量层

☁️ Cloudflare（CDN + WAF + Bot 管理 + Rate Limit）
🚪 API Gateway：Kong / APISIX / 自建（Hono on Edge）
🔌 gRPC 内部通信，REST/GraphQL 对外

可观测性（必须三件套）

 📊 Metrics ─── Prometheus + Grafana
 📜 Logs ────── Loki / ClickHouse / ES
 🕸️ Traces ──── Tempo / Jaeger（OpenTelemetry 统一）
 🐛 Errors ──── Sentry
 📈 业务大盘 ── ClickHouse + Grafana

基础设施

🚢 Kubernetes（EKS / GKE / ACK）
🏗️ Terraform / Pulumi 管 IaC
🔄 ArgoCD / Flux 做 GitOps
🐳 Docker + 多阶段构建
⚙️ CI/CD：GitHub Actions + 自托管 runner

大促 / 高并发的关键技术

技术	用法
📦 库存预扣 + 异步落库	Redis Lua + Kafka
🚦 限流	令牌桶 / 漏桶（Redis + Lua）
🛡️ 熔断降级	商详降级到静态、推荐降级到热销
🧠 本地缓存	Caffeine（JVM）/ 进程内 LRU
⚡ CDN 边缘缓存	商品页 ISR + `stale-while-revalidate`
🆔 分布式 ID	Snowflake / ULID
🔒 幂等	订单创建、支付回调强制幂等键

一张总览表（横向对比）

维度	🌱 Tier 0 (<50)	🌿 Tier 1 (50-200)	🌳 Tier 2 (200-1000)	🌲 Tier 3 (1000+)
架构形态	全栈单体	单体 + 异步任务	前后端分离 + BFF	微服务 / 模块化单体
前端	Next.js	Next.js + RQ	Next.js + Edge	Next.js + RN + Monorepo
后端	API Routes	API Routes + Service	NestJS / FastAPI	多服务 + Gateway
数据库	SQLite / Supabase	Postgres 托管	Postgres 主从 + Redis	PG 集群 + Redis Cluster + ES + ClickHouse
搜索	LIKE / pg_trgm	Postgres FTS	Meilisearch	Elasticsearch + 向量
队列	无	Inngest	BullMQ / Celery	Kafka + Temporal
部署	Vercel	Vercel + Railway	Vercel + Fly.io	K8s + Cloudflare
监控	Sentry	Sentry + PostHog	+ Axiom + OTel	Prom + Grafana + Loki + Tempo
支付	Stripe Checkout	Stripe + Webhook	Stripe + 风控	多渠道 + 对账系统

实战心法（用 Claude Code 时记住这 3 条）

💡 心法 1 · 不要一上来就 Tier 3

Claude Code 默认会给你 Tier 0/1，这是对的。等真有流量再迁。为想象中的流量买单，是创业失败的常见死法。

💡 心法 2 · 跨档迁移优先级

数据库和搜索最容易踩坑，跨档迁移时优先重构这两块。其他模块（缓存、CDN、监控）几乎可以无痛升级。

⚠️ 心法 3 · 国内场景特别提示

Vercel / Stripe / Supabase 在国内访问有问题，可替换为：

☁️ 阿里云函数计算 / Sealos

🌐 腾讯 EdgeOne CDN

🐘 PingCAP TiDB Serverless

💴 连连 / 微信支付 / 支付宝

📌 vibe coding 隐藏陷阱

让 Claude Code 在每个 tier 之间只迁移一两个组件，不要让它一次性大重构。 它在大重构里容易引入回归——它越自信，你越要 review。

决策导图：什么时候该升级？

不是看时间，是看信号。

 📈 流量上来了
 │
 ▼
 ┌──────────────────┐ 是 ┌────────────────────┐
 │ DB CPU > 70% ? │────────►│ 升 Postgres 主从 │
 └─────────┬────────┘ │ + Redis 缓存 │
 否 └────────────────────┘
 ▼
 ┌──────────────────┐ 是 ┌────────────────────┐
 │ 首页 P95 > 2s ? │────────►│ 上 ISR / Edge │
 └─────────┬────────┘ │ + CDN 缓存 │
 否 └────────────────────┘
 ▼
 ┌──────────────────┐ 是 ┌────────────────────┐
 │ 订单峰值堆积 ? │────────►│ 拆异步队列 │
 └─────────┬────────┘ │ BullMQ / Celery │
 否 └────────────────────┘
 ▼
 ┌──────────────────┐ 是 ┌────────────────────┐
 │ 搜索慢 / 不准 ? │────────►│ 换 Meilisearch │
 └─────────┬────────┘ │ / Elasticsearch │
 否 └────────────────────┘
 ▼
 ┌──────────────────┐
 │ ✅ 保持现状 │
 │ 继续观察 │
 └──────────────────┘

这张图比任何架构师的脑补都靠谱。 让数据告诉你升不升。

核心关键词

电商架构 vibe coding Claude Code 渐进式架构 Tier 0-3 Next.js 微服务 单体 BFF PostgreSQL Redis Stripe Vercel K8s Kafka Temporal CQRS 事件驱动 可观测性 阿里云/国内替换

写在最后

架构是长出来的，不是设计出来的。

先让 Claude Code 给你 Tier 0/1，把生意跑起来。

用户说慢了再上缓存。订单堆了再拆队列。团队大了再拆服务。

别为想象中的流量买单。

这一句话，能省掉你创业前两年 80% 的架构焦虑。

Vibe-Coding on Albert Intelligence

别一上来就 K8s · Claude Code 写电商的 4 档默认架构

别一上来就 K8s · Claude Code 写电商的 4 档默认架构

全景一图流

🌱 Tier 0 · MVP / Demo（并发 < 50）

长什么样

Claude Code 默认推荐栈

🌿 Tier 1 · 小型上线（并发 50-200）

长什么样

比 Tier 0 多了什么

🌳 Tier 2 · 中型电商（并发 200-1000）

长什么样

模块拆解

🌲 Tier 3 · 大型电商（并发 1000+）

长什么样（电商六大域）

整体架构思路

前端

后端服务拆分（典型电商域）

数据层

消息与异步

流量层

可观测性（必须三件套）

基础设施

大促 / 高并发的关键技术

一张总览表（横向对比）

实战心法（用 Claude Code 时记住这 3 条）

决策导图：什么时候该升级？

核心关键词

写在最后

相关笔记

架构与部署实践

基础设施与运维

Obsidian 用法