1.1 多租户SaaS概述
1.1.1 多租户定义与核心特征
多租户（Multi-Tenancy）是SaaS架构的基石，指单一软件实例同时服务多个租户（Tenant），每个租户在逻辑上相互隔离，感知不到其他租户的存在。租户可以是企业、部门、项目组或独立用户，取决于业务模型。
| 特征 | 说明 | 与传统单租户对比 |
|---|---|---|
| 共享实例 | 所有租户共用同一套应用进程与数据库 | 单租户需为每个客户独立部署 |
| 逻辑隔离 | 通过租户ID（Tenant ID）区分数据与配置 | 单租户使用物理隔离（独立服务器） |
| 可扩展性 | 新增租户无需重新部署，仅需注册与初始化 | 单租户扩展需重复部署流程 |
| 成本分摊 | 基础设施与运维成本由所有租户共同承担 | 单租户成本由单一客户全额承担 |
关键认知：多租户不是简单的"多个用户登录"，而是租户级资源隔离与权限边界。鉴权拦截链路必须确保：一个租户的用户无法访问另一个租户的数据，即使两个租户使用相同的应用代码。
1.1.2 SaaS架构演进路线
SaaS架构从单租户到成熟多租户，通常经历四个阶段。理解演进路径有助于在鉴权设计中做出正确的架构取舍。
- 阶段一：单租户托管 — 每个客户独立部署一套应用+数据库，无共享逻辑。鉴权简单（仅用户级），但运维成本随客户数线性增长。
- 阶段二：共享应用+独立数据库 — 所有租户共用应用层，但每个租户拥有独立数据库。鉴权需在连接层区分数据源，租户隔离强但资源利用率低。
- 阶段三：共享应用+共享数据库（Schema隔离） — 同一数据库实例内，每个租户使用独立Schema。鉴权需在SQL执行前注入租户过滤条件，隔离性中等。
- 阶段四：共享应用+共享数据库（行级隔离） — 所有租户数据存储在同一表中，通过
tenant_id列区分。鉴权拦截链路必须在请求入口、服务调用、数据访问三层强制校验租户上下文。
架构演进对鉴权的影响：阶段越靠后，对租户上下文传递和数据级权限拦截的要求越高。阶段四必须依赖统一的鉴权中间件，而非分散在各业务代码中。
1.1.3 租户隔离的核心挑战
多租户隔离不是单一维度的技术问题，而是数据、性能、安全、合规四维交织的复杂挑战。以下是SaaS架构中必须解决的五大核心挑战：
| 挑战维度 | 具体问题 | 典型风险 |
|---|---|---|
| 数据隔离 | 租户A的查询结果中混入租户B的数据 | 数据泄露、违反GDPR/等保 |
| 性能隔离 | 一个租户的慢查询拖慢所有租户的响应 | 服务质量下降、SLA违约 |
| 配置隔离 | 租户A修改了全局配置，影响租户B的业务逻辑 | 业务异常、功能错乱 |
| 密钥隔离 | 租户A的API密钥被用于访问租户B的资源 | 未授权访问、数据篡改 |
| 审计隔离 | 无法区分操作日志属于哪个租户 | 合规审计失败、责任追溯困难 |
常见误区：很多团队在初期只关注"数据隔离"，忽略了密钥隔离和审计隔离。一旦SaaS产品通过API对外提供服务，密钥隔离缺失将直接导致租户越权攻击；而审计隔离缺失会在等保测评中直接判定为不合格。
1.1.4 多租户鉴权拦截链路全景
下图展示了多租户SaaS中完整的鉴权拦截链路，从请求入口到数据持久化，每一层都必须嵌入租户上下文校验：
1.1.5 租户隔离策略对比
选择隔离策略时，需在隔离强度与资源效率之间做权衡。以下是三种主流策略的对比：
| 隔离策略 | 实现方式 | 隔离强度 | 资源效率 | 适用场景 |
|---|---|---|---|---|
| 独立数据库 | 每个租户一个数据库实例 | ⭐⭐⭐⭐⭐ | ⭐⭐ | 金融、医疗等强合规行业 |
| 独立Schema | 同一数据库，每个租户一个Schema | ⭐⭐⭐⭐ | ⭐⭐⭐ | 中型企业SaaS，需一定隔离性 |
| 行级隔离 | 同一表，通过tenant_id区分 |
⭐⭐⭐ | ⭐⭐⭐⭐⭐ | 通用SaaS，成本敏感型产品 |
实战建议：对于大多数SaaS产品，推荐采用混合策略——核心敏感数据（如支付、密钥）使用独立数据库或Schema，非敏感业务数据（如日志、配置）使用行级隔离。这样既满足合规要求，又控制基础设施成本。
1.1.6 本章小结
多租户SaaS的鉴权拦截链路设计，本质上是在共享基础设施上构建逻辑隔离边界。核心要点包括：
- 租户识别必须在请求入口完成，并作为不可篡改的上下文传递到每一层。
- 数据隔离策略的选择直接影响鉴权拦截的复杂度，行级隔离对中间件要求最高。
- 密钥隔离和审计隔离是容易被忽视但必须覆盖的安全维度。
- 架构演进路径决定了鉴权系统的迭代方向，建议从阶段二或阶段三起步，逐步向阶段四演进。