2. 租户隔离基础概念：多租户架构定义、隔离级别与 Tenant ID 设计原则
在可观测性系统中，租户隔离是保障数据安全、避免“噪声干扰”以及实现成本分摊的基石。本章从多租户架构的原始定义出发，逐步拆解隔离的两种核心模式——硬隔离与软隔离，并深入探讨租户标识（Tenant ID）的设计原则，为后续的通信机制与架构实践打下理论基础。
2.1 多租户架构定义
多租户（Multi-Tenancy）是指单个软件实例能够同时为多个独立的用户群体（即“租户”）提供服务，且每个租户在逻辑上或物理上感知不到其他租户的存在。在可观测性场景中，租户通常对应一个业务线、一个团队、一个项目或一个客户环境。
核心特征：
- 共享资源池：计算、存储、网络等基础设施由所有租户共用，提升资源利用率。
- 逻辑隔离：每个租户的数据、配置、权限在逻辑上严格分离，互不可见。
- 可扩展性：新增租户无需重新部署整套系统，仅需进行配置或资源分配。
可观测性平台的多租户架构通常包含以下三个层次：
| 层次 | 说明 | 典型组件 |
|---|---|---|
| 数据层 | 指标、日志、链路数据的存储与查询隔离 | 时序数据库、日志索引、链路存储 |
| 计算层 | 告警规则、聚合计算、数据处理管线的隔离 | 流处理引擎、告警管理器 |
| 展示层 | 仪表盘、用户界面、权限控制的隔离 | Grafana、Kibana、自定义UI |
2.2 隔离级别：硬隔离 vs 软隔离
隔离级别的选择直接决定了系统的安全性、性能与运维复杂度。业界通常将隔离模式分为两大类：硬隔离（Hard Isolation）与软隔离（Soft Isolation）。
2.2.1 硬隔离（物理/进程级隔离）
硬隔离为每个租户分配独立的物理资源或进程实例，租户之间不存在资源共享。在可观测性系统中，常见的实现方式包括：为每个租户部署独立的 Collector、独立的存储集群或独立的查询引擎。
- 优点：安全性最高，一个租户的故障或性能问题不会影响其他租户；数据完全物理分离，合规性强。
- 缺点：资源利用率低，运维成本高，扩展时需为每个租户重复部署全套组件。
2.2.2 软隔离（逻辑/数据级隔离）
软隔离所有租户共享同一套基础设施，通过数据标签、权限策略和查询过滤来实现逻辑上的隔离。这是当前云原生可观测性平台的主流方案。
- 优点：资源利用率高，运维简单，新增租户仅需配置 Tenant ID 和权限。
- 缺点：隔离强度依赖代码正确性，存在“吵闹邻居”问题（如某个租户的突发查询拖慢共享存储）。
实践建议：在可观测性系统中，通常采用混合隔离策略：对核心生产环境租户使用硬隔离（独立 Collector + 独立存储），对开发测试租户使用软隔离（共享存储 + Tenant ID 过滤）。这样在安全性与成本之间取得平衡。
下表从多个维度对比两种隔离模式：
| 对比维度 | 硬隔离 | 软隔离 |
|---|---|---|
| 资源分配 | 独占物理/虚拟资源 | 共享资源池 |
| 数据安全 | 极高（物理隔离） | 高（依赖权限与标签） |
| 运维复杂度 | 高（每租户独立部署） | 低（统一管理） |
| 资源利用率 | 低（存在资源碎片） | 高（弹性复用） |
| 扩展成本 | 线性增长 | 接近常数 |
| 典型场景 | 金融、医疗、合规敏感 | SaaS、内部平台、DevOps |
2.3 租户标识（Tenant ID）的设计原则
Tenant ID 是多租户隔离的核心元数据。无论是硬隔离还是软隔离，系统都需要一个全局唯一的标识来关联数据、配置与权限。设计不当的 Tenant ID 会导致数据泄露、查询性能下降或扩展困难。
2.3.1 Tenant ID 的三大设计原则
- 全局唯一性：在整个可观测性平台中，Tenant ID 必须唯一，避免跨租户数据混淆。推荐使用 UUID 或 雪花算法（Snowflake ID）生成。
- 不可变性：一旦分配，Tenant ID 不应变更。变更 Tenant ID 意味着需要重写所有历史数据中的标签，代价极高。
- 低熵性（查询友好）：Tenant ID 应尽量短小且有序，便于作为索引或分区键。过长的随机字符串会降低存储和查询效率。
常见陷阱：不要使用租户名称（如 "team-alpha"）作为 Tenant ID。名称可能变更，且长度不固定，不利于存储和索引。始终使用无业务含义的稳定标识符。
2.3.2 Tenant ID 的常见生成方案对比
| 方案 | 示例 | 长度 | 有序性 | 适用场景 |
|---|---|---|---|---|
| UUID v4 | f47ac10b-58cc-4372-a567-0e02b2c3d479 |
36 字符 | 无序 | 分布式环境，无需排序 |
| Snowflake ID | 734958273948672001 |
19 位数字 | 时间有序 | 需要按时间范围查询的场景 |
| ULID | 01ARZ3NDEKTSV4RRFFQ69G5FAV |
26 字符 | 时间有序 | 兼顾可读性与有序性 |
| 自增整数 | 1001 |
4-8 字节 | 有序 | 单机或中心化分配，不推荐分布式 |
2.3.3 Tenant ID 在数据流中的传递方式
在可观测性系统中，Tenant ID 需要贯穿数据采集、传输、存储与查询的全链路。以下是三种常见的传递方式：
- HTTP Header 传递：在 API 网关或 Collector 入口处，通过
X-Tenant-ID或X-Scope-OrgID头携带 Tenant ID。适用于请求/响应模式。 - 数据标签注入：在 Agent 端或 Collector 端，将 Tenant ID 作为标签（Label/Tag）写入指标、日志或 Span 中。适用于异步数据流。
- 上下文传播：在微服务调用链中，通过 W3C Trace Context 或 OpenTelemetry 的 Baggage 机制传递 Tenant ID，确保链路数据归属正确。