1. 多租户SaaS架构概述
1.1 什么是多租户
多租户（Multi-Tenancy）是一种软件架构模式，允许单个应用实例同时服务多个租户，同时确保每个租户的数据与配置相互隔离。租户可以是企业、组织或用户组，每个租户拥有独立的业务视图与权限边界。
核心特征：共享资源 + 逻辑隔离 + 按需定制。多租户不是简单的“多用户”，而是面向多组织、多客户、多业务线的隔离与共享平衡。
1.2 租户隔离模型
租户隔离是多租户架构的基石。根据数据隔离的粒度与共享程度，主流有三种隔离模型：
| 隔离模型 | 数据隔离级别 | 共享资源 | 典型场景 | 安全强度 |
|---|---|---|---|---|
| 数据库隔离 | 最高 | 仅应用实例 | 金融、医疗、高合规行业 | ★★★★★ |
| Schema隔离 | 中高 | 数据库实例 | 中型企业、SaaS平台 | ★★★★☆ |
| 共享表隔离 | 最低 | 数据库 + 表结构 | 低成本SaaS、个人用户 | ★★★☆☆ |
1.2.1 数据库隔离（Database per Tenant）
每个租户拥有独立的数据库实例。应用层通过数据源路由，将请求分发到对应租户的数据库。
- 优点：数据隔离最彻底，备份恢复独立，故障域最小。
- 缺点：资源开销大，连接数多，运维复杂。
- 适用：对数据安全要求极高的场景，如银行、保险、政务。
1.2.2 Schema隔离（Schema per Tenant）
所有租户共享同一个数据库实例，但每个租户拥有独立的Schema（命名空间）。表结构相同，数据物理隔离。
- 优点：资源利用率高于数据库隔离，隔离性较好。
- 缺点：数据库实例故障影响所有租户；跨租户查询困难。
- 适用：中型SaaS平台，租户数量可控。
1.2.3 共享表隔离（Shared Table）
所有租户共用同一套表结构，通过租户ID字段（tenant_id）区分数据行。这是成本最低的隔离方式。
- 优点：资源利用率最高，扩展简单，维护成本低。
- 缺点：隔离性最弱，需在应用层严格过滤 tenant_id，否则易发生数据泄露。
- 适用：低成本SaaS、个人/小团队场景。
⚠️ 安全警示：共享表隔离模式下，任何一次SQL查询遗漏 tenant_id 过滤，都可能导致跨租户数据泄露。这是多租户鉴权拦截链路必须重点防护的环节。
1.3 SaaS成熟度模型
SaaS成熟度模型由Microsoft提出，用于衡量SaaS应用在多租户、可配置性、可扩展性方面的能力。共分为4个级别：
| 级别 | 名称 | 隔离模型 | 可配置性 | 可扩展性 | 典型特征 |
|---|---|---|---|---|---|
| Level 1 | 定制化实例 | 数据库隔离 | 低（代码级定制） | 低 | 每个租户独立部署，本质是“托管软件” |
| Level 2 | 可配置实例 | 数据库/Schema隔离 | 中（配置文件/开关） | 中 | 同一代码库，通过配置满足不同租户 |
| Level 3 | 可扩展多租户 | Schema/共享表隔离 | 高（元数据驱动） | 高 | 租户可自定义字段、流程、UI |
| Level 4 | 可扩展多租户 + 弹性 | 混合隔离 | 极高 | 极高（自动扩缩容） | 水平扩展、按需分配资源、零停机 |
💡 架构建议：大多数SaaS产品从 Level 2 起步，逐步演进到 Level 3。Level 4 需要强大的基础设施支撑（如Kubernetes、分布式数据库），适合超大规模SaaS平台。本课程后续的鉴权拦截链路设计，主要面向 Level 2 ~ Level 3 的典型架构。
成熟度演进路径
- Level 1 → Level 2：将定制代码抽象为配置项，实现“一份代码，多租户运行”。
- Level 2 → Level 3：引入元数据框架，支持租户级自定义扩展，同时强化鉴权与隔离。
- Level 3 → Level 4：实现无状态化、弹性伸缩、多区域部署，鉴权链路需支持分布式会话与全局租户上下文。