3. 租户隔离模型：数据面隔离、控制面隔离与混合隔离策略对比

在多租户可观测性平台中，隔离模型决定了故障边界如何划定、资源如何争用、以及运维人员能否快速定位“哪个租户的哪类观测数据出了问题”。根据隔离深度与共享程度，主流模型分为三类：数据面隔离（Schema / Shard）、控制面隔离（Namespace / Cluster）以及混合隔离策略。本节从可观测性故障排查视角，对比三种模型的设计要点、隔离效果与运维代价。

3.1 数据面隔离：Schema 与 Shard

数据面隔离关注存储与查询层的租户边界。每个租户的观测数据（Trace、Metric、Log）在物理或逻辑上独立存放，但控制面组件（采集器、查询路由、告警引擎）仍可共享。

维度 Schema 隔离 Shard 隔离
隔离粒度 数据库 Schema / 表空间 分片键 + 物理分片
共享程度 共享数据库实例，Schema 独立 共享集群，分片独立
故障影响面 单个 Schema 故障不影响其他 Schema 单个 Shard 故障仅影响该分片租户
可观测性排查难点 需区分“Schema 级慢查询”与“实例级瓶颈” 需追踪分片键路由与数据倾斜
典型场景 中小规模 SaaS，每个租户独立表结构 大规模时序/日志平台，按租户 Hash 分片
故障排查要点： 数据面隔离下，若某个租户的查询延迟飙升，首先检查该租户对应 Schema 或 Shard 的存储水位、索引命中率与 IO 等待。不要直接重启共享实例——那会波及所有租户。
数据面隔离：Schema 与 Shard 对比 Schema 隔离 租户 A Schema 租户 B Schema 共享数据库实例 Shard 隔离 Shard 0 (租户 A) Shard 1 (租户 B) 分布式存储集群 故障排查关注点 Schema 隔离：检查慢查询是否集中在某个 Schema → 索引或锁问题 Shard 隔离：检查分片数据倾斜 → 热点 Shard 导致查询超时 优点：Schema 级备份恢复，租户数据物理分离 缺点：共享实例资源争用，扩展受限于单库 优点：水平扩展能力强，分片故障隔离 缺点：跨分片查询复杂，需维护路由表

3.2 控制面隔离：Namespace 与 Cluster

控制面隔离将采集、路由、告警、查询解析等控制逻辑按租户拆分。每个租户拥有独立的控制面组件或进程，数据面可以共享也可以独立。这种模型在 Kubernetes 多租户场景中尤为常见。

  • Namespace 隔离：在同一集群内，通过 Kubernetes Namespace 或逻辑分组隔离采集器、告警规则、配置映射。故障排查时需注意 Namespace 级别的资源配额（CPU/Memory）是否被某个租户的告警风暴耗尽。
  • Cluster 隔离：每个租户独占一个可观测性集群（如独立的 Prometheus / Grafana / Jaeger 实例）。隔离性最强，但运维成本线性增长。
对比项 Namespace 隔离 Cluster 隔离
资源开销 低（共享集群资源） 高（每租户独立集群）
故障爆炸半径 单个 Namespace 故障可能影响集群稳定性 故障完全隔离，不影响其他租户
可观测性排查复杂度 需区分“集群级故障”与“Namespace 级故障” 每个集群独立排查，无交叉影响
适用规模 中大规模多租户，租户数 50–500 超大规模或合规敏感场景，租户数 < 50
常见陷阱： Namespace 隔离下，如果某个租户的采集器产生大量错误日志并触发告警风暴，可能耗尽集群的日志存储 IOPS 或告警通道配额，导致其他租户的告警延迟甚至丢失。排查时必须先检查控制面组件的全局限流与队列积压。
控制面隔离：Namespace vs Cluster Namespace 隔离（共享集群） NS: 租户A NS: 租户B NS: 租户C 共享采集器 / 告警引擎 / 查询路由 Cluster 隔离（独立集群） Cluster: 租户A Cluster: 租户B 独立采集 / 告警 / 存储 / 查询 故障排查关键差异 Namespace：先检查集群全局资源（CPU/内存/网络）是否被某个 Namespace 耗尽 → 再定位具体租户 Cluster：直接检查故障集群的组件健康状态，无需考虑跨租户影响

3.3 混合隔离策略：分层组合与故障排查

生产环境中，大多数平台采用混合隔离策略：控制面按 Namespace 隔离以降低运维成本，数据面按 Shard 隔离以保障存储扩展性，同时为高等级租户提供独立 Cluster 选项。这种分层组合需要在故障排查时建立清晰的隔离边界映射。

典型混合模型

  1. 控制面 Namespace + 数据面 Shard：每个租户在共享集群中拥有独立的 Namespace（采集配置、告警规则），数据按租户 Hash 写入不同 Shard。这是性价比最高的方案。
  2. 控制面 Cluster + 数据面 Schema：为关键租户部署独立控制面集群，数据面仍共享数据库但使用独立 Schema。适合合规要求高但数据量中等的场景。
  3. 全栈混合：普通租户使用方案 1，铂金租户使用方案 2，并在路由层通过租户 ID 动态分发。
混合策略 控制面 数据面 故障排查优先级
策略 A Namespace Shard 1. Namespace 资源配额 → 2. Shard 热点 → 3. 路由一致性
策略 B Cluster Schema 1. 集群组件健康 → 2. Schema 锁/IO → 3. 跨 Schema 查询
策略 C 混合路由 混合存储 1. 路由层租户标识 → 2. 目标隔离域健康 → 3. 回退策略
SRE 最佳实践： 在混合隔离架构中，务必在可观测性平台内部维护一张“租户 → 隔离域”的实时映射表，并在告警事件中携带隔离域标签（如 tenant_id=abc, isolation_domain=namespace:prod-monitor, shard=shard-03）。这能将故障排查时间从小时级缩短到分钟级。

混合隔离下的故障排查流程

1. 收到租户 A 的查询超时告警
2. 查询租户隔离映射表 → 租户 A 使用策略 A（Namespace: ns-a, Shard: shard-05）
3. 检查控制面：
   - kubectl top pod -n ns-a → 发现采集器 CPU 限流
   - 查看 ns-a 的 ResourceQuota → CPU 配额耗尽
4. 检查数据面：
   - 查询 shard-05 的存储指标 → IOPS 达到上限
   - 检查 shard-05 的分片键分布 → 发现数据倾斜
5. 结论：控制面配额不足 + 数据面热点叠加导致超时
6. 修复：调整 ns-a 的 CPU 配额上限 + 对 shard-05 进行再平衡

3.4 三种隔离模型的综合对比

评估维度 数据面隔离 控制面隔离 混合隔离
隔离强度 中（存储层隔离，控制面共享） 中高（控制面隔离，数据面可共享） 高（分层隔离，按需组合）
运维复杂度 低 中 高
资源利用率 高 中 中高
故障排查难度 中（需区分存储层与实例层） 中（需区分集群层与 Namespace 层） 高（需跨层关联）
典型故障场景 慢查询、存储倾斜 告警风暴、配置错误 路由失效、配额叠加
← 上一章 📖 返回目录 下一章 →