2. 多租户架构概述：SaaS多租户模型与可观测性隔离挑战
在SaaS场景中，多租户（Multi-Tenancy）是指单个软件实例服务于多个独立客户（租户），每个租户的数据、配置和性能边界在逻辑上相互隔离。可观测性系统作为基础设施的一部分，必须继承这种隔离模型，否则会出现数据泄露、资源抢占、计费混乱等问题。
2.1 SaaS多租户的三种核心模型
根据资源隔离的粒度与成本，业界将多租户架构归纳为三种模型：独享、共享、混合。下表从可观测性视角对比其关键差异：
| 模型 | 资源分配方式 | 隔离强度 | 可观测性成本 | 典型场景 |
|---|---|---|---|---|
| 独享（Dedicated） | 每个租户独占一套完整的基础设施（计算、存储、网络） | 最高（物理/VM级隔离） | 高（需为每租户部署独立Agent、存储、看板） | 金融、医疗等强合规行业 |
| 共享（Shared） | 所有租户共享同一套基础设施，通过应用层逻辑区分 | 最低（仅逻辑隔离） | 低（共享采集管道与存储，按标签路由） | 中小型SaaS、内部工具 |
| 混合（Hybrid） | 核心组件共享，敏感组件独享；或按租户等级动态分配 | 中等（可配置隔离策略） | 中等（需设计隔离路由层） | 大型SaaS、分层定价产品 |
架构决策提示：选择模型时，不能只看基础设施成本。可观测性系统的数据传输带宽和存储膨胀系数往往被低估。独享模型下，100个租户可能产生100倍的Agent开销和100倍的存储冗余；共享模型则可能因“吵闹邻居”导致指标失真。
2.2 三种模型的架构对比（SVG）
下图从数据采集、传输、存储三个环节，直观展示三种模型的隔离边界差异：
2.3 租户隔离在可观测性中的核心挑战
将多租户模型映射到可观测性系统时，会面临四个维度的关键挑战：
- 数据边界模糊：共享模型下，Agent采集的CPU、内存等系统指标天然属于宿主机，难以直接归属到某个租户。若标签（tenant_id）遗漏或错误，数据会污染其他租户的视图。
- 性能干扰（吵闹邻居）：一个租户的突发流量（如大量Span上报）可能耗尽共享Agent的缓冲区或共享存储的写入IOPS，导致其他租户的指标延迟甚至丢失。
- 存储与成本膨胀：独享模型下，每个租户都需要独立的指标存储、日志索引和链路追踪后端。假设单租户日增100GB数据，100个租户就是10TB，成本线性增长。
- 查询与权限控制：可观测性看板必须确保租户A的SRE只能看到租户A的数据。这要求从数据采集、传输到存储的每一层都携带租户上下文，并在查询时强制过滤。
常见陷阱：很多团队在初期选择“共享模型+标签隔离”以降低成本，但忽略了查询性能隔离。当租户数量超过1000时，共享存储的查询过滤器（如 WHERE tenant_id='xxx'）会因数据倾斜导致慢查询，甚至拖垮整个集群。此时必须引入物理分片或租户级缓存。
2.4 可观测性隔离的目标矩阵
针对上述挑战，可观测性隔离需要达成以下五个目标。每个目标在不同模型下的实现难度不同：
| 目标 | 定义 | 独享模型 | 共享模型 | 混合模型 |
|---|---|---|---|---|
| 数据完整性 | 租户A的数据不会出现在租户B的查询结果中 | ✅ 天然满足 | ⚠️ 依赖标签准确性 | ✅ 核心层标签+敏感层物理隔离 |
| 性能公平性 | 一个租户的流量突发不影响其他租户的采集与查询延迟 | ✅ 完全隔离 | ❌ 吵闹邻居风险高 | ⚠️ 需配置限流与优先级队列 |
| 成本可预测 | 每个租户的可观测性成本可独立核算、按量计费 | ⚠️ 成本线性增长 | ✅ 共享摊薄成本 | ⚠️ 需设计分摊模型 |
| 运维复杂度 | 新增租户时无需大量人工配置 | ❌ 每租户需部署全套组件 | ✅ 仅需添加标签 | ⚠️ 需自动化编排 |
| 故障半径 | 单个租户的可观测性故障不会扩散到全局 | ✅ 故障隔离 | ❌ 共享组件单点故障影响所有租户 | ⚠️ 核心组件需高可用设计 |
2.5 隔离目标与模型选择的权衡（SVG）
下图以雷达图形式展示三种模型在五个目标上的相对得分（5分制），帮助架构师根据业务优先级做出选择：
2.6 本章小结
- 三种模型：独享（强隔离高成本）、共享（低成本弱隔离）、混合（折中方案）。
- 四大挑战：数据边界模糊、性能干扰、存储成本膨胀、查询权限控制。
- 五大目标：数据完整性、性能公平性、成本可预测、运维复杂度、故障半径。
- 核心权衡：没有银弹。架构师需要根据租户的合规等级、SLA要求、预算和运维能力，选择或组合上述模型。