2. 租户隔离基础概念：多租户架构定义、SaaS场景下的租户模型、数据隔离与资源隔离的区别
2.1 多租户架构定义
多租户（Multi-Tenancy）是一种软件架构模式，指单个软件实例能够同时为多个独立的用户群体（即“租户”）提供服务。每个租户在逻辑上彼此隔离，感知不到其他租户的存在，仿佛自己独占整个系统。
核心特征包括：
- 共享实例：所有租户共用同一套应用进程、数据库或基础设施。
- 逻辑隔离：通过元数据、命名空间或权限策略实现租户间的数据与配置隔离。
- 可扩展性：新增租户无需部署新实例，仅需分配配置和存储空间。
- 计费与配额：每个租户的资源使用量可独立计量和限制。
可观测性视角：在多租户架构中，Metric 标签必须携带
tenant_id 或 org_id 等标识，否则监控数据将无法区分不同租户的行为，导致告警风暴或指标污染。
2.2 SaaS场景下的租户模型
在 SaaS（Software as a Service）场景中，租户模型通常分为以下三种层级，决定了可观测性数据的隔离粒度：
| 模型层级 | 定义 | 典型场景 | Metric标签要求 |
|---|---|---|---|
| 单租户实例 | 每个租户拥有独立的应用实例和数据库 | 金融、医疗等高合规行业 | 标签可省略 tenant_id，但需实例标识 |
| 共享实例 + Schema隔离 | 同一数据库实例，每个租户使用独立 Schema | 中型企业级 SaaS | 必须携带 tenant_id 和 schema |
| 共享实例 + 行级隔离 | 所有租户数据存储在相同表中，通过 tenant_id 列区分 | 高密度、低成本 SaaS（如协作工具） | 必须携带 tenant_id，且标签治理最严格 |
在可观测性系统中，租户模型直接影响 Metric 标签的设计策略：
- 单租户实例：标签冲突风险低，但跨租户聚合困难。
- 共享实例 + Schema隔离：需要为每个 Schema 维护独立的 Metric 命名空间。
- 共享实例 + 行级隔离：
tenant_id成为必选标签，且必须保证标签值在全局唯一。
2.3 数据隔离与资源隔离的区别
在多租户可观测性系统中，数据隔离和资源隔离是两个容易混淆但本质不同的概念。下表从多个维度进行对比：
| 对比维度 | 数据隔离 | 资源隔离 |
|---|---|---|
| 关注对象 | Metric 数据、日志、Trace 的存储与查询 | CPU、内存、磁盘 IO、网络带宽等物理资源 |
| 隔离手段 | 标签策略、命名空间、RBAC 权限、数据分区 | 容器资源限制（cgroup）、K8s ResourceQuota、限流降级 |
| 冲突表现 | 标签名重复、指标覆盖、查询结果包含其他租户数据 | 租户 A 突发流量导致租户 B 请求超时或 OOM |
| 可观测性影响 | Metric 标签治理失效，监控面板展示错误数据 | 告警阈值被“吵闹邻居”触发，SLO 计算失真 |
| 典型解决方案 | 强制标签规范、标签白名单、查询时过滤 | 资源配额、优先级调度、熔断限流 |
关键认知：数据隔离解决的是“看得见”的问题——租户 A 是否能看到租户 B 的指标；资源隔离解决的是“用得到”的问题——租户 A 的突发流量是否会影响租户 B 的服务质量。在 Metric 标签治理中，两者缺一不可：没有数据隔离，标签冲突会导致数据污染；没有资源隔离，标签再规范也无法保证系统稳定性。
2.4 可观测性场景下的隔离实践要点
在构建多租户可观测性平台时，需要同时考虑数据隔离与资源隔离，并注意以下实践要点：
- 标签设计先行：在 Metric 采集端强制注入
tenant_id标签，避免事后清洗。 - 存储层分区：按
tenant_id对时序数据库进行物理或逻辑分区，提升查询性能。 - 查询时过滤：在 API 网关或查询代理层自动追加租户过滤条件，防止跨租户数据泄露。
- 资源配额硬限制：为每个租户设置 Metric 上报速率、存储容量和查询并发数的上限。
- 监控自身可观测性：记录每个租户的指标丢弃率、查询延迟和资源使用量，用于容量规划。
常见陷阱：不要认为“数据隔离做好了，资源隔离可以忽略”。在真实生产环境中，一个租户的异常 Metric 采集（如每秒上报百万条指标）会耗尽共享的时序数据库写入能力，导致所有租户的监控数据丢失。资源隔离是数据隔离的“地基”。