📚 课程目录第1章租户隔离需求全景

第1章：租户隔离需求全景：多租户场景、合规要求、数据边界、性能隔离目标

构建多租户 SaaS 平台时，租户隔离是首要的架构约束。它不仅仅是把数据分开，而是在安全性、合规性、性能和成本之间寻找最优平衡点。在做任何技术选型之前，必须先看清全景：谁在使用系统、监管者要求什么、数据边界在哪里、性能目标有多高。这一章将为你绘制一幅完整的租户隔离需求全景图，作为后续 29 章所有决策的共同原点。

1. 多租户场景与隔离需求

不同租户对“隔离”的要求截然不同。我们需要根据业务场景对租户进行分类，确定隔离的基线。

B2B 企业租户：数据量大、有独立品牌需求、可能要求物理隔离以通过 SOC2 审计。通常愿意为独立资源付费。
B2C 个人租户：数据量小、用户数量大、对性价比敏感。共享基础设施带来的成本优势远大于隔离需求。
垂直场景 vs 水平场景：垂直 SaaS（如医疗行业）自带 HIPAA 合规要求；水平 SaaS（如协作工具）则更关注通用可用性。

2. 合规要求作为强制函数

合规是强制性需求，不是可选项。一旦违规，可能导致巨额罚款甚至停止运营。常见的合规驱动因素包括：

合规标准	核心要求	对隔离的影响
GDPR	数据删除权、数据可移植性、数据驻留	必须按区域隔离数据，支持一键清除某租户所有数据
SOC2	审计日志、访问控制、机密性	需要清晰的租户边界划分，确保审计日志不被跨租户污染
HIPAA	PHI（受保护健康信息）必须严格隔离	通常需要独立数据库实例，甚至独立集群
PCI DSS	持卡人数据环境必须与网络其他部分隔离	强制实施网络 + 存储层面的物理隔离

架构建议： 尽早与合规团队对齐需求。在架构初期引入合规成本远低于后期补救。许多团队在选型后才发现违反 GDPR 的数据驻留条款，导致重新设计，成本高昂。

3. 数据边界与信任边界

在多租户系统中，我们需要区分控制平面和数据平面的信任边界。

控制平面（元数据/配置）： 可以跨租户共享，但需要严格的 RBAC。例如：租户注册信息、计费配置。
数据平面（实际行记录）： 必须严格隔离。每一条 SQL 查询都需要携带租户上下文（Tenant Context），防止跨租户数据泄露。

信任链路的建立通常来自终端用户的 JWT 或 API Key，中间件会提取租户 ID 并注入到数据库驱动层。一旦中间件被绕过，数据边界立刻崩溃。

4. 性能隔离目标

性能隔离的核心是防止“吵闹邻居”效应。一个租户的突发流量（如批量做 AI 推理、大数据导入）不能影响其他租户的响应时间。

IOPS 隔离： 数据库磁盘的读写能力必须按租户分组限制。
CPU / 内存隔离： 资源池划分（cgroup / 数据库资源管理器）。
延迟 SLO： 关键租户的 P99 延迟必须在争用环境中保持稳定。

常见陷阱： 低估性能隔离的复杂性。在 PoC 阶段，共享数据库看似足够。一旦出现“吵闹邻居”租户（如大量批量导入），其他租户的延迟会瞬间飙升，导致严重 SLA 违约。

5. 需求全景图

下图总结了驱动数据库与 Schema 隔离方案选择的四个核心维度：

6. 选型权衡：隔离级别初探

基于上述需求，架构师需要在四种主流隔离级别中做出权衡。下面用一段配置清单直观展示需求如何映射到隔离决策：

# 租户隔离配置示例（tenant_config.yaml）
tenants:
  - id: acme_corp
    tier: enterprise
    compliance: gdpr, soc2
    isolation: dedicated_database   # 独立数据库实例
  - id: startup_inc
    tier: business
    compliance: none
    isolation: dedicated_schema     # 独立 Schema
  - id: free_user_001
    tier: free
    compliance: none
    isolation: shared_schema        # 共享 Schema（Tenant ID 行级隔离）

隔离级别	资源开销	安全等级	运维复杂度	适合场景
共享 Schema	极低	★☆☆☆☆	极低	免费 / 个人租户
独立 Schema	低	★★★☆☆	中	SMB / Business 租户
独立数据库	高	★★★★☆	高	企业 / 合规关键租户
独立集群	极高	★★★★★	极高	金融 / 政府 / 物理隔离需求

7. 本章落地步骤

作为课程的第 1 章，你需要完成以下动作，建立后续课程的分析基线：

审计租户目录： 列出所有现有或规划的租户，标注其属性（B2B/B2C、企业/个人、数据量级）。
映射合规要求： 为每个租户类别打上合规标签（GDPR、HIPAA、PCI、SOC2 等）。
定义数据边界： 明确数据驻留区域（如：美西、欧洲、新加坡），以及控制/数据平面的访问路径。
建立初步 SLO： 设定关键租户的性能基线（P99 延迟、吞吐量、IOPS）。
生成《租户隔离需求矩阵》： 形成正式文档，作为后续架构评审的输入。

8. 验收标准

完整性： 需求矩阵覆盖所有已知租户类别，无遗漏。
合规性： 每条合规要求都有明确的隔离对策（哪怕是“待定”状态也必须记录）。
一致性： 团队对“多租户场景”、“合规要求”、“数据边界”、“性能隔离目标”四个维度的定义达成共识。
可追溯： 每个租户的隔离等级选择都可以追溯到其需求全景图中的具体维度。