24.01-AI SaaS系统架构

要点

• AI SaaS 是一个多租户的订阅制产品，核心是「租户隔离」和「资源计量」
• 架构分四层：接入层、业务层、AI 能力层、数据层
• 关键技术选型：Cloudflare Workers（计算）+ D1（关系数据）+ R2（对象存储）+ KV（缓存/配置）
• 从单体起步，按需拆分微服务，避免过早优化

内容

1. AI SaaS 的特殊性

AI SaaS 和传统 SaaS 相比，有几个显著的特殊性：

1. 成本结构不同：每次用户调用 AI 功能，都会产生 LLM API 成本。传统 SaaS 的边际成本趋近于零，AI SaaS 的边际成本是「token 消耗 × 模型单价」
2. 资源计量复杂：需要精确追踪每个租户的 token 消耗、请求次数、存储空间
3. 多模型路由：不同租户可能使用不同的模型（GPT-4、Claude、开源模型），需要灵活的路由策略
4. 知识库管理：RAG 场景需要管理每个租户的私有知识库
5. 配额控制：需要细粒度的配额系统（按 token、按请求、按存储）

这些特殊性决定了 AI SaaS 的架构不能简单套用传统 SaaS 的模式。

2. 四层架构设计

一个完整的 AI SaaS 系统可以分成四层：

┌─────────────────────────────────────────┐
│          接入层 (Edge Layer)             │
│  - Cloudflare Workers (API Gateway)     │
│  - 认证、限流、路由、CORS               │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│          业务层 (Business Layer)         │
│  - 租户管理、用户体系、套餐订阅         │
│  - 额度系统、计费系统、用量统计         │
│  - 团队空间、权限管理                   │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│        AI 能力层 (AI Capability Layer)   │
│  - 模型路由、Prompt 管理、RAG 引擎     │
│  - 向量数据库、知识库管理               │
│  - 模型配置中心、Prompt 模板市场        │
└─────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────┐
│          数据层 (Data Layer)             │
│  - D1 (关系数据：用户、租户、订单)      │
│  - R2 (对象存储：文件、知识库文档)      │
│  - KV (缓存：配置、会话、热点数据)      │
│  - Vector DB (向量：Embedding)          │
└─────────────────────────────────────────┘

每一层的职责：

• 接入层：处理 HTTP 请求，做认证、限流、路由。这一层跑在边缘节点，延迟最低
• 业务层：处理业务逻辑，如租户管理、订阅、计费。这一层是 SaaS 的核心
• AI 能力层：封装 AI 相关的能力，如模型调用、RAG、Prompt 管理。这一层是 AI SaaS 的差异化竞争力
• 数据层：存储所有数据。选择合适的存储引擎对性能和成本至关重要

3. 关键技术选型

3.1 计算层：Cloudflare Workers

为什么选择 Workers 而不是 Node.js/Next.js API Routes？

对于 AI SaaS，Workers 的优势：

1. 边缘部署：AI 调用本身延迟高（1-10s），API 层的延迟应该尽可能低
2. 内置存储：D1/R2/KV 直接绑定，不需要维护外部数据库
3. 成本可控：免费额度大（10 万请求/天），适合初创产品

3.2 存储层：四种存储引擎

AI SaaS 需要四种不同的存储：

选择原则：

• 结构化数据 → D1（关系查询、事务支持）
• 大文件/二进制 → R2（成本低、无大小限制）
• 频繁读写的配置 → KV（毫秒级读取）
• 向量检索 → Vector DB（Pinecone/Weaviate/Upstash）

3.3 AI 能力层：模型路由

AI SaaS 的核心是模型路由。不同租户可能使用不同的模型：

// 简化的模型路由示例
async function routeModel(tenantId: string, request: ChatRequest) {
  // 1. 获取租户配置
  const config = await getTenantConfig(tenantId)
 
  // 2. 根据配额选择模型
  if (config.plan === 'free') {
    return 'gpt-3.5-turbo'  // 免费用户只能用小模型
  }
 
  if (config.preferredModel === 'gpt-4') {
    return 'gpt-4'  // 付费用户可以选择大模型
  }
 
  // 3. 根据成本优化选择
  if (request.messages.length < 1000) {
    return 'gpt-3.5-turbo'  // 短对话用小模型
  }
 
  return 'gpt-4'  // 长对话用大模型
}

4. 单体 vs 微服务

4.1 初创阶段：单体架构

初期建议用单体架构，所有代码在一个 Workers 项目里：

apps/
  api/
    src/
      index.ts          # 入口
      routes/
        auth.ts         # 认证
        tenant.ts       # 租户管理
        subscription.ts # 订阅
        chat.ts         # AI 聊天
        rag.ts          # RAG
      lib/
        db.ts           # 数据库
        storage.ts      # 存储
        llm.ts          # LLM 调用

优点：

• 开发速度快，不需要处理服务间通信
• 部署简单，一个 wrangler deploy 搞定
• 调试方便，所有日志在一起

4.2 增长阶段：拆分微服务

当团队规模扩大、流量增长后，可以按业务域拆分：

apps/
  api-gateway/      # 接入层：认证、限流、路由
  user-service/     # 用户服务：用户、租户、权限
  billing-service/  # 计费服务：订阅、额度、账单
  ai-service/       # AI 服务：模型调用、RAG
  admin-service/    # 管理服务：后台、运营

拆分原则：

1. 按业务域：用户、计费、AI 是三个独立的业务域
2. 按团队：不同团队负责不同服务
3. 按扩展需求：AI 服务需要 GPU 加速，单独部署

但要注意：微服务会带来额外的复杂性（服务发现、分布式事务、监控），只有在真正需要时才拆分。

5. 多租户数据隔离

多租户的数据隔离有三种模式：

5.1 共享数据库，共享 Schema

所有租户的数据在同一个表里，通过 tenant_id 字段区分：

CREATE TABLE users (
  id TEXT PRIMARY KEY,
  tenant_id TEXT NOT NULL,
  email TEXT NOT NULL,
  -- ...
)
 
-- 查询时必须带上 tenant_id
SELECT * FROM users WHERE tenant_id = ? AND id = ?

优点：简单、成本低 缺点：需要确保每个查询都带上 tenant_id，否则数据泄露

5.2 共享数据库，独立 Schema

每个租户一个独立的 Schema（或表前缀）：

-- 租户 A 的用户表
CREATE TABLE tenant_a_users (...)
 
-- 租户 B 的用户表
CREATE TABLE tenant_b_users (...)

优点：隔离性更好 缺点：Schema 管理复杂，不适合大量租户

5.3 独立数据库

每个租户一个独立的数据库：

// 根据租户 ID 获取数据库连接
const db = getDatabase(tenantId)

优点：最强隔离，适合企业级客户 缺点：成本高，管理复杂

AI SaaS 推荐：

• 初创阶段：共享数据库 + tenant_id 字段（模式 1）
• 增长阶段：共享数据库 + Schema 隔离（模式 2）
• 企业客户：独立数据库（模式 3）

6. 实战：最小可行架构

一个最小可行的 AI SaaS 架构：

// apps/api/src/index.ts
import { Hono } from 'hono'
import { cors } from 'hono/cors'
import { jwt } from 'hono/jwt'
 
const app = new Hono()
 
// 全局中间件
app.use('*', cors())
app.use('/api/*', jwt({ secret: process.env.JWT_SECRET! }))
 
// 业务路由
app.route('/api/auth', authRoutes)
app.route('/api/tenant', tenantRoutes)
app.route('/api/subscription', subscriptionRoutes)
app.route('/api/chat', chatRoutes)
app.route('/api/rag', ragRoutes)
 
// 全局错误处理
app.onError((err, c) => {
  console.error(err)
  return c.json({ error: 'Internal Server Error' }, 500)
})
 
export default app

数据库 Schema：

-- 租户表
CREATE TABLE tenants (
  id TEXT PRIMARY KEY,
  name TEXT NOT NULL,
  plan TEXT NOT NULL DEFAULT 'free',
  created_at INTEGER NOT NULL
)
 
-- 用户表
CREATE TABLE users (
  id TEXT PRIMARY KEY,
  tenant_id TEXT NOT NULL,
  email TEXT NOT NULL UNIQUE,
  password_hash TEXT NOT NULL,
  role TEXT NOT NULL DEFAULT 'member',
  created_at INTEGER NOT NULL
)
 
-- 订阅表
CREATE TABLE subscriptions (
  id TEXT PRIMARY KEY,
  tenant_id TEXT NOT NULL,
  plan TEXT NOT NULL,
  status TEXT NOT NULL,
  start_date INTEGER NOT NULL,
  end_date INTEGER,
  token_quota INTEGER NOT NULL
)
 
-- 额度使用表
CREATE TABLE quota_usage (
  id TEXT PRIMARY KEY,
  tenant_id TEXT NOT NULL,
  user_id TEXT NOT NULL,
  tokens_used INTEGER NOT NULL,
  model TEXT NOT NULL,
  created_at INTEGER NOT NULL
)

这个架构可以支撑：

• 多租户隔离
• 用户认证
• 订阅管理
• 额度控制
• AI 聊天
• RAG 功能

7. 架构演进路径

AI SaaS 的架构演进通常经历三个阶段：

阶段 1：单体 MVP（0-100 用户）

• 所有代码在一个 Workers 项目
• 共享数据库 + tenant_id 字段
• 手动部署，没有 CI/CD
• 目标：验证产品市场匹配（PMF）

阶段 2：模块化（100-1000 用户）

• 按业务域拆分模块（但还在同一个 Workers 项目）
• 引入 CI/CD、自动化测试
• 开始做监控和告警
• 目标：提升开发效率和系统稳定性

阶段 3：微服务（1000+ 用户）

• 按业务域拆分成独立的 Workers 项目
• 引入服务发现和 API 网关
• 多区域部署
• 目标：支持大规模并发和团队协作

关键原则：不要过早优化。在没有验证 PMF 之前，单体架构是最优选择。

8. 小结

AI SaaS 系统架构的关键点：

1. 四层架构：接入层、业务层、AI 能力层、数据层
2. 技术选型：Workers（计算）+ D1/R2/KV（存储）+ Vector DB（向量）
3. 多租户隔离：从共享 Schema 起步，按需升级到独立数据库
4. 模型路由：根据租户配额和请求特征选择模型
5. 演进路径：单体 → 模块化 → 微服务，不要过早拆分

一句话带走：

AI SaaS 的核心挑战是「多租户隔离」和「资源计量」。从单体架构起步，用 Cloudflare Workers + D1/R2/KV 构建最小可行产品，按需演进到微服务。