2. 租户隔离基础概念：多租户架构模式与租户ID设计

在多租户可观测性平台中，租户隔离是保障数据安全、计费准确与性能稳定的核心能力。本章从架构模式、ID设计与传递方式三个维度，建立租户隔离的基础认知。

2.1 多租户架构模式：Silo、Pool、Bridge

业界将多租户数据隔离架构归纳为三种经典模式：Silo（独立部署）、Pool（共享池）与Bridge（桥接混合）。三种模式在隔离强度、资源效率与运维复杂度上各有取舍。

下图展示了三种模式在服务实例与数据存储层面的隔离关系：

2.2 租户ID的设计原则

租户ID（Tenant ID）是隔离策略的唯一标识符，其设计质量直接影响路由效率、可观测性链路追踪与运维排障速度。以下是经过生产验证的六条核心原则：

1. 全局唯一性：跨集群、跨地域不可重复，推荐使用 UUID v7 或 Snowflake ID。
2. 不可变性：租户ID一旦分配，禁止修改；如需变更，应创建新租户并迁移数据。
3. 可排序性：时间前缀（如 Snowflake ID 的时间戳高位）便于分库分表与时间范围扫描。
4. 无业务含义：避免嵌入地域、部门、等级等业务属性，防止重构时ID失效。
5. 长度可控：建议 16~32 字节（字符串形式），过长会降低索引性能与传输效率。
6. 可观测性友好：ID 应能直接关联到租户元数据，便于日志、指标、链路中的快速定位。

2.3 租户ID的传递方式

在多服务、多协议的可观测性系统中，租户ID必须无侵入地穿透整个请求链路。以下是三种主流传递方式及其适用场景：

下图展示了租户ID在典型微服务调用链中的传递路径：

2.4 传递方式代码示例

以下展示在 OpenTelemetry Java SDK 中通过 Baggage 传递租户ID的标准做法：

// 1. 在网关层注入租户ID到 Baggage
import io.opentelemetry.api.baggage.Baggage;
import io.opentelemetry.context.Context;

public class TenantIdFilter implements HttpFilter {
    @Override
    public void doFilter(HttpRequest request, HttpResponse response, FilterChain chain) {
        String tenantId = request.getHeader("X-Tenant-ID");
        if (tenantId != null && !tenantId.isEmpty()) {
            Baggage baggage = Baggage.current().toBuilder()
                .put("tenant.id", tenantId)
                .build();
            Context context = Context.current().with(baggage);
            chain.doFilter(request, response, context);
        } else {
            chain.doFilter(request, response);
        }
    }
}

// 2. 在数据访问层读取租户ID并注入查询
import io.opentelemetry.api.baggage.Baggage;

public class TenantAwareRepository {
    public List<Metric> queryMetrics(String metricName) {
        String tenantId = Baggage.current().getEntryValue("tenant.id");
        if (tenantId == null) {
            throw new SecurityException("Missing tenant.id in baggage");
        }
        String sql = "SELECT * FROM metrics WHERE tenant_id = ? AND name = ?";
        return jdbcTemplate.query(sql, tenantId, metricName);
    }
}

2.5 租户隔离的常见陷阱与避坑

• 陷阱一：租户ID硬编码 —— 在代码中写死租户ID，导致测试环境与生产环境隔离失效。应始终从上下文或配置中心动态获取。
• 陷阱二：忽略异步链路 —— 消息队列、定时任务、异步回调中未传递租户ID，导致数据写入默认租户或报错。需在消息体或消息Header中显式携带。
• 陷阱三：索引缺失 —— 共享存储模式下，未对 tenant_id 列建立索引，导致跨租户查询性能急剧下降。建议在 tenant_id 上建立复合索引。
• 陷阱四：Baggage 滥用 —— 在 OpenTelemetry Baggage 中放入过多键值对，导致链路数据膨胀。建议只放入租户ID、请求ID等核心字段，总大小控制在 1KB 以内。