1. 多租户基础概念：SaaS多租户模型、租户与用户的区别、隔离级别概述
1.1 SaaS多租户模型
多租户（Multi-Tenancy）是SaaS架构的核心设计模式，指单一软件实例同时服务多个独立组织（租户），每个租户在逻辑上完全隔离，互不可见。该模型通过资源共享大幅降低运营成本，同时通过隔离机制保障数据安全与合规。
核心定义： 多租户 = 单实例 + 多组织 + 逻辑隔离。租户共享基础设施与代码，但拥有独立的业务视图与配置能力。
根据资源隔离程度与部署方式，SaaS多租户模型通常分为以下三种主流模式：
| 模型 | 资源隔离方式 | 典型场景 | 成本 | 隔离强度 |
|---|---|---|---|---|
| 独立数据库模式 | 每个租户独占一个数据库实例 | 金融、医疗等高合规行业 | 高 | 最高 |
| 共享数据库-独立Schema | 同一数据库，每个租户拥有独立Schema | 中型企业SaaS、CRM系统 | 中 | 中 |
| 共享数据库-共享表 | 同一数据库、同一表，通过租户ID字段区分 | 低合规要求、高密度租户场景 | 低 | 低 |
架构选型建议： 平台门户通常采用混合模式——核心元数据使用独立Schema保证隔离，非敏感日志或配置数据使用共享表降低成本。故障域隔离设计需优先考虑独立数据库或独立Schema模式。
1.2 租户与用户的区别
在多租户体系中，租户（Tenant）与用户（User）是两个不同层级的概念，混淆二者会导致权限模型混乱与隔离漏洞。
- 租户： 代表一个组织、企业或业务单元。租户拥有独立的资源配额、配置策略、计费账户与数据边界。租户是隔离的基本单位。
- 用户： 代表一个自然人账户。用户必须归属于某个租户，在租户边界内操作。用户不能跨租户访问数据，除非显式授权。
常见误区： 将“租户”等同于“用户”会导致隔离失效。例如，在共享表模型中若仅用user_id过滤数据而未校验tenant_id，用户A可能通过修改请求参数访问用户B的数据。这是多租户系统中最严重的安全漏洞之一。
以下表格清晰展示二者的关键差异：
| 维度 | 租户（Tenant） | 用户（User） |
|---|---|---|
| 层级 | 组织级，顶层隔离单元 | 个人级，隶属于租户 |
| 生命周期 | 创建/冻结/销毁，影响整个组织 | 创建/禁用/删除，仅影响个人 |
| 资源配额 | 租户级别配额（如存储上限、API调用量） | 用户级别权限（如角色、功能菜单） |
| 故障域 | 租户是故障隔离的最小单元 | 用户故障通常不影响其他用户 |
| 标识 | tenant_id（全局唯一） | user_id（租户内唯一） |
1.3 隔离级别概述
多租户隔离不仅限于数据层，而是贯穿整个技术栈。平台门户需要从以下五个维度定义隔离级别，才能实现真正的故障域隔离：
- 数据隔离： 数据库、表、Schema或行的隔离。决定一个租户能否访问另一个租户的数据。
- 计算隔离： 应用实例、容器、进程或线程的隔离。决定一个租户的突发流量是否导致其他租户服务降级。
- 网络隔离： VPC、子网、安全组或网络策略的隔离。决定租户间的网络通信是否被阻断。
- 配置隔离： 功能开关、限流阈值、日志级别等运行时配置的隔离。决定租户能否自定义平台行为。
- 故障隔离： 熔断、降级、限流、重试等容错策略的隔离。决定一个租户的故障是否会扩散为全局故障。
关键原则： 故障域隔离的核心是“一个租户的崩溃不应影响其他租户的可用性”。这要求隔离级别必须覆盖数据、计算、网络与配置四个基础层，并在故障隔离层通过熔断与限流实现边界保护。
下图展示了多租户隔离的层级模型与各层之间的依赖关系：
实践要点： 在平台门户中，故障隔离层是“最后一道防线”。即使数据、计算、网络、配置四层隔离全部失效，故障隔离层仍能通过舱壁模式（Bulkhead）将故障限制在单个租户范围内。建议在架构设计初期就引入熔断与限流机制，而非事后补救。
总结而言，多租户基础概念是平台门户实现故障域隔离的基石。理解SaaS多租户模型、清晰区分租户与用户、掌握五层隔离级别，才能在后继章节中正确设计用户隔离策略与故障切换方案。