📚 课程目录第1章 SaaS多租户鉴权概述

1. SaaS多租户鉴权概述：多租户模型定义、租户隔离策略、传统鉴权链路痛点

多租户（Multi-Tenancy）是一种软件架构模式，允许单个应用实例同时服务多个租户（Tenant）。每个租户是一组用户（如企业、团队或项目组），他们共享底层基础设施与代码，但在逻辑上彼此隔离，互不可见。

在SaaS场景中，租户通常对应一个企业客户。例如，一个办公协作SaaS平台同时为“A公司”和“B公司”提供服务，A公司的员工只能访问A公司的文档与审批流，B公司的员工无法看到A公司的任何数据。

  核心特征： 共享实例 + 逻辑隔离 = 多租户。与单租户（每个客户独立部署实例）相比，多租户能显著降低运维成本与资源开销。

租户隔离是多租户架构设计的核心挑战。根据数据存储与计算资源的共享程度，主流策略分为以下三种：

隔离策略	数据存储方式	隔离强度	资源成本	典型场景
独立数据库	每个租户独占一个数据库实例	最高（物理隔离）	最高	金融、医疗等强合规行业
共享数据库、独立Schema	同一数据库实例，每个租户拥有独立Schema（表空间）	中高（逻辑隔离）	中等	中大型企业SaaS，需一定数据隔离
共享数据库、共享Schema	所有租户数据存放在同一套表中，通过`tenant_id`字段区分	最低（行级隔离）	最低	中小型SaaS，追求极致资源利用率

架构建议： 大多数SaaS产品起步阶段采用“共享Schema”策略以降低成本；当业务增长或合规要求提升时，可逐步迁移至“独立Schema”或“独立数据库”。鉴权链路的设计必须兼容这三种隔离模式。

在单租户应用中，鉴权链路通常为：用户登录 → 生成Token → 每次请求携带Token → 服务端验证Token有效性 → 返回用户身份。但在多租户SaaS中，这条链路暴露出以下核心痛点：

租户上下文缺失： Token中通常只包含用户ID（user_id），缺少tenant_id。服务端无法判断该用户属于哪个租户，导致数据跨租户泄露风险。
Token验证性能瓶颈： 每次请求都需要查询数据库或远程服务验证Token，高并发场景下数据库连接池被迅速打满，响应延迟飙升。
租户切换与权限漂移： 用户可能同时属于多个租户（如跨企业协作），传统鉴权无法优雅处理“当前操作上下文”的切换，容易产生权限漂移。
拦截链路重复计算： 每个微服务或中间件都重复解析Token、查询租户信息，缺乏统一的缓存加速层，导致CPU与IO浪费。

典型事故： 某SaaS平台因Token中未携带tenant_id，且鉴权服务未做租户隔离校验，导致A公司员工通过修改请求参数，成功读取了B公司的客户订单数据。事后复盘发现，传统鉴权链路在“租户边界校验”环节存在严重缺失。

下图展示了传统多租户SaaS鉴权链路的完整流程与痛点分布：

以下为某中型SaaS平台（1000+租户，日均API请求量5000万次）在未优化前的鉴权链路性能数据：

  核心结论： 传统鉴权链路在多租户场景下，不仅存在性能瓶颈（数据库压力大、响应延迟高），更存在安全风险（租户边界模糊、数据泄露）。引入Redis缓存加速与令牌验证优化，是解决上述问题的关键路径。