2. 多租户架构概述
2.1 多租户的定义
多租户（Multi-Tenancy）是一种软件架构模式，其中单个软件实例服务于多个租户，每个租户拥有独立的逻辑或物理边界。租户可以是组织、团队、项目或业务线，其核心诉求是：资源隔离、数据安全与性能保障。
关键特征： 多租户 ≠ 多用户。用户是租户内的个体；租户是资源分配与计费的最小单位。
2.2 隔离模型：硬隔离 vs 软隔离
隔离模型决定了租户之间的故障边界与资源竞争程度。下表对比了两种主流模型的核心差异：
| 维度 | 硬隔离（Hard Isolation） | 软隔离（Soft Isolation） |
|---|---|---|
| 资源分配 | 独占物理/虚拟资源（如整机、专用GPU） | 共享资源池，通过配额/限流控制 |
| 故障域 | 租户故障不影响其他租户 | 故障可能扩散，依赖熔断/降级保护 |
| 性能保障 | 严格保证（无邻居噪声） | 统计复用，存在突发争抢 |
| 成本效率 | 低（资源碎片多） | 高（资源池化利用率高） |
| 典型场景 | 金融核心、合规敏感系统 | SaaS应用、开发测试环境 |
容量规划启示： 硬隔离需要按峰值预留资源，容量利用率通常低于 50%；软隔离允许超配（overcommit），但必须建立精确的租户画像与争抢模型。
2.3 租户粒度与资源池化策略
租户粒度直接影响隔离成本与运维复杂度。常见的粒度层级包括：
- 实例级租户： 每个租户独占一个服务实例（如独立 Kubernetes 集群）。隔离最强，但管理开销最大。
- 命名空间级租户： 共享集群，通过命名空间（Namespace）划分。隔离中等，适合大多数微服务场景。
- 应用级租户： 同一进程内通过上下文隔离（如线程池、数据库 schema）。隔离最弱，但资源复用度最高。
资源池化策略需与租户粒度匹配：
| 策略 | 适用粒度 | 核心机制 |
|---|---|---|
| 静态分区 | 实例级 | 固定 CPU/内存/磁盘配额，不可超配 |
| 动态权重 | 命名空间级 | 基于公平调度（如 Dominant Resource Fairness） |
| 弹性共享 | 应用级 | 资源池 + 限流 + 熔断 + 降级 |
2.4 混合隔离模型
实际生产环境很少采用纯硬或纯软隔离。推荐分层混合策略：
- 控制面隔离： API Server、调度器等共享，但租户数据隔离。
- 数据面隔离： 核心租户使用硬隔离节点，普通租户使用软隔离节点池。
- 存储隔离： 通过 PV/PVC 或存储池实现租户级 IOPS 隔离。
常见陷阱： 软隔离下“吵闹邻居”问题（Noisy Neighbor）会导致容量规划偏差。必须为每个租户建立 资源画像（CPU 使用率 P99、内存抖动频率、IO 突发模式），否则超配比例失控。
2.5 容量规划视角的关键指标
在多租户架构中，以下指标直接影响资源预留与故障边界测试：
- 租户密度： 每节点/每集群承载的租户数量。密度越高，软隔离压力越大。
- 超配比（Overcommit Ratio）： 分配资源 / 物理资源。建议初始值 ≤ 3:1，根据监控逐步调整。
- 隔离失效概率： 因资源争抢导致 SLA 违约的概率。硬隔离为 0，软隔离需通过混沌工程验证。
- 故障半径： 单个租户故障影响的最大租户数。硬隔离为 1，软隔离可能扩散至整个共享池。
实践建议： 在容量规划初期，为每个租户建立 资源预留基线（Guaranteed）与 弹性上限（Limit）。硬隔离租户预留 = 峰值需求；软隔离租户预留 = 均值 + 1.5σ（标准差），剩余资源作为共享缓冲区。