📚 课程目录第2章多租户基础

2. 多租户基础：租户模型、隔离级别与租户生命周期管理

多租户（Multi-Tenancy）是 SaaS 化可观测性系统的核心架构模式。一个租户（Tenant）代表一个独立的逻辑或物理客户组织，拥有自己的用户、数据、配置与计费单元。本章从租户模型、隔离级别和生命周期管理三个维度，建立多租户可观测性系统的理论基础。

2.1 租户模型

租户模型定义了“谁是租户”以及“租户如何被标识和访问”。在可观测性系统中，常见的租户模型有三种：

模型类型	描述	适用场景	示例
单层扁平模型	每个租户是一个独立组织，租户 ID 直接映射到数据分区	中小型 SaaS，客户数量 < 1000	租户 A → 数据分区 A
层级树状模型	租户可包含子租户（部门/项目），形成树状结构	大型企业、集团客户	集团租户 → 子公司租户 → 项目租户
混合模型	扁平 + 层级混合，支持租户间数据共享与隔离策略	复杂多业务线、跨租户分析	租户 A 共享指标给租户 B

实践建议： 初期采用单层扁平模型，租户 ID 作为所有数据写入和查询的强制过滤条件。当出现集团客户需求时，再引入租户层级树，通过 tenant_path 字段实现递归查询。

2.2 隔离级别：数据隔离、性能隔离、安全隔离

隔离级别决定了租户之间在数据、性能和安全三个维度的“距离”。不同的隔离级别对应不同的架构成本和运维复杂度。

2.2.1 数据隔离

数据隔离确保租户 A 无法读取或写入租户 B 的数据。常见实现方式：

共享表 + 租户 ID 过滤：所有租户数据存储在相同表中，通过 tenant_id 列区分。成本最低，但查询性能受数据量影响，且存在误过滤风险。
独立 Schema：每个租户拥有独立的数据库 Schema（如 PostgreSQL Schema）。隔离性较好，但连接池管理复杂。
独立数据库实例：每个租户独占一个数据库实例。隔离性最强，但资源开销大，适合高合规要求场景。

隔离方式	存储成本	查询性能	运维复杂度	推荐场景
共享表 + tenant_id	低	中（需索引）	低	免费版、试用版
独立 Schema	中	高	中	标准版、专业版
独立数据库实例	高	最高	高	企业版、金融/医疗

2.2.2 性能隔离

性能隔离防止一个租户的突发流量或异常查询影响其他租户。核心手段包括：

资源配额（Resource Quota）：限制每个租户的 CPU、内存、磁盘 IOPS 上限。
请求速率限制（Rate Limiting）：限制每个租户每秒的 API 请求数、查询并发数。
优先级队列：为付费租户设置高优先级队列，免费租户使用低优先级队列。
独立计算节点：为高 SLA 租户分配独占的查询节点或写入节点。

常见陷阱： 仅依赖数据隔离而忽略性能隔离，会导致“吵闹邻居”问题——一个租户的慢查询可能耗尽连接池，导致其他租户超时。建议在网关层和查询引擎层同时实施速率限制和并发控制。

2.2.3 安全隔离

安全隔离确保租户间的认证、授权和审计互不干扰。关键要素：

租户上下文传递：从 API 网关到后端服务，X-Tenant-ID 头必须强制传递且不可篡改。
行级安全策略（RLS）：数据库层面自动附加 WHERE tenant_id = current_tenant_id 条件。
密钥隔离：每个租户拥有独立的 API Key、Token 签名密钥和加密密钥。
审计日志隔离：租户只能查看自己租户内的操作审计日志。

2.3 租户生命周期管理

租户生命周期管理覆盖从租户创建到最终删除的全过程，每个阶段都需要与可观测性系统的数据管道、计费系统和运维流程对接。

阶段	关键操作	可观测性系统动作	注意事项
1. 创建	注册、选择套餐、支付	分配租户 ID、创建数据分区、初始化配额	确保租户 ID 全局唯一且不可重用
2. 激活	首次登录、配置数据源	创建默认仪表盘、告警规则、接入代理	提供开箱即用的可观测性体验
3. 运行	日常使用、数据上报、查询分析	数据写入、查询服务、告警触发、用量统计	持续监控租户健康状态和资源使用率
4. 变更	升级/降级套餐、增加子租户	调整配额、迁移数据分区、更新权限	变更期间保证数据不丢失、服务不中断
5. 暂停	欠费、违规、用户主动暂停	停止数据写入、冻结查询、保留数据	保留期（如 30 天）内可恢复
6. 删除	退订、注销	清理数据、释放资源、归档审计日志	执行软删除 + 硬删除双阶段，防止误操作

  生命周期自动化： 建议使用事件驱动架构管理租户状态变更。例如，当计费系统发出“租户欠费”事件时，可观测性系统自动触发暂停流程，无需人工介入。状态机模型可有效避免租户在多个阶段间出现状态不一致。

2.4 租户状态机设计

租户状态机是生命周期管理的核心模型。每个租户在同一时刻只能处于一个状态，状态转换由系统事件或人工操作触发。

2.5 租户元数据管理

每个租户的元数据需要集中存储，供所有服务查询。推荐使用独立的元数据服务（Tenant Metadata Service），而非将元数据硬编码在配置文件中。

// 租户元数据模型示例（JSON）
{
  "tenant_id": "tnt_abc123",
  "tenant_name": "某科技有限公司",
  "tier": "enterprise",           // free | standard | enterprise
  "status": "active",             // creating | active | suspended | deleted
  "created_at": "2025-01-15T08:00:00Z",
  "quotas": {
    "max_series": 1000000,
    "max_logs_per_day": 50000000,
    "max_traces_per_min": 10000,
    "max_query_concurrency": 20
  },
  "data_isolation": "schema",     // shared | schema | instance
  "parent_tenant_id": null,       // 层级模型时使用
  "features": ["alerting", "dashboard", "slo"]
}

元数据缓存策略： 租户元数据变更频率低（通常每天几次），但查询频率极高（每次 API 请求都需要校验）。建议使用本地缓存（如 Guava Cache） + Redis 分布式缓存，TTL 设置为 60 秒，元数据服务变更时主动失效缓存。

2.6 本章小结

租户模型选择直接影响架构复杂度：初期用扁平模型，后期按需引入层级模型。
隔离级别需在数据、性能、安全三个维度平衡，不可偏废。
租户生命周期管理必须自动化，状态机是防止状态不一致的最佳实践。
租户元数据服务是多租户系统的“大脑”，需要高可用、低延迟、强一致性。