1. SaaS多租户概述
1.1 什么是多租户
多租户（Multi-Tenancy）是一种软件架构模式，其中单个软件实例能够同时为多个租户提供服务。每个租户（Tenant）代表一个客户组织（企业、团队或个人），在逻辑上相互隔离，彼此无法感知或访问对方的数据。
核心特征： 共享实例 + 逻辑隔离 = 多租户架构。与单租户（每个客户独立部署实例）相比，多租户在资源利用率、运维成本和版本一致性上具有显著优势。
多租户并非简单的"多个用户登录系统"。用户（User）是租户下的身份实体，而租户是数据隔离与计费的边界。例如：企业A和企业B都是租户，企业A的员工张三和企业B的员工李四分别是各自租户下的用户。
1.2 租户隔离模型
根据数据隔离的粒度与共享程度，业界主流有三种隔离模型。下表从多个维度进行对比：
| 维度 | Database-per-Tenant | Schema-per-Tenant | Shared Table |
|---|---|---|---|
| 隔离粒度 | 独立数据库 | 同一数据库，独立Schema | 同一数据库，同一Schema |
| 数据安全 | 最高（物理隔离） | 高（逻辑隔离） | 中等（依赖租户ID字段） |
| 资源成本 | 最高（每租户独立DB连接） | 中等 | 最低（共享连接与存储） |
| 扩展性 | 强（可独立迁移/备份） | 中等 | 弱（单表数据量增长快） |
| 租户数量上限 | 数百~数千 | 数千~数万 | 数万~百万级 |
| 典型场景 | 金融、医疗等强合规行业 | 中型SaaS平台 | 超大规模、低客单价SaaS |
选型建议： 没有绝对最优模型。成熟SaaS平台通常采用混合策略：免费/试用租户使用Shared Table，付费高等级租户自动升级到独立Database。
三种模型的架构关系如下图所示：
1.3 SaaS架构核心挑战
多租户架构在带来资源集约优势的同时，也引入了传统单租户架构不曾面临的系统性挑战。以下是SaaS架构必须解决的五大核心问题：
- 租户身份识别与路由： 请求到达时，系统必须准确识别请求属于哪个租户，并将该请求路由到正确的数据源或Schema。常见的识别方式包括域名前缀（tenant-a.example.com）、请求头（X-Tenant-ID）或URL路径。
- 数据隔离与安全： 必须防止租户A通过SQL注入、参数篡改或缓存穿透等方式访问租户B的数据。隔离失效是SaaS平台最严重的安全事故。
- 资源配额与限流： 一个租户的突发流量（如"双11"大促）不应影响其他租户的正常使用。需要为每个租户设置独立的QPS、连接数、存储空间等配额。
- 租户级配置与定制： 不同租户可能要求不同的功能开关、UI主题、业务规则或集成配置。架构需要支持运行时动态加载租户配置。
- 运维与监控复杂度： 在共享基础设施上，需要区分"全局故障"与"单租户故障"。监控系统必须能按租户维度聚合日志、指标和告警。
常见误区： 许多团队在SaaS初期选择Shared Table模型以降低开发成本，但忽略了租户ID索引设计和数据清理策略。当租户数量超过1000、单表数据量突破1亿行时，查询性能会急剧下降，且数据迁移成本极高。建议在架构设计阶段就预留隔离升级路径。
下图展示了SaaS架构在鉴权与数据访问链路中面临的核心挑战分布：