3. 平台设计原则：面向租户的多租户架构、数据隔离策略、权限模型（RBAC/ABAC）设计

在自助服务可观测性平台中，多租户架构是支撑企业级规模化运营的基石。平台需要同时服务于多个业务团队（租户），每个租户拥有独立的资源视图、数据边界和操作权限。设计核心在于平衡资源共享效率与租户隔离安全性。

3.1 多租户架构模型

多租户架构通常分为三种模式，每种模式在隔离性、成本和运维复杂度上各有取舍：

3.2 数据隔离策略

数据隔离是多租户设计的核心安全防线。根据可观测性数据类型（指标、日志、链路），隔离策略需分层实施：

• 物理隔离：租户使用独立的数据库实例或独立的索引集群。隔离性最强，但成本最高，适用于合规敏感租户。
• 逻辑隔离：共享同一存储集群，通过租户 ID（tenant_id）字段进行数据分区。成本低，但需确保查询路由层强制注入租户上下文。
• 混合隔离：热数据（近期高频查询）采用逻辑隔离以降低成本；冷数据（历史归档）采用物理隔离以满足合规要求。

3.3 权限模型设计：RBAC 与 ABAC

权限模型决定了租户内用户能看到什么和能做什么。可观测性平台通常采用 RBAC（基于角色的访问控制）作为基础，并在精细场景下引入 ABAC（基于属性的访问控制）。

3.3.1 RBAC 核心设计

RBAC 通过“用户 → 角色 → 权限”的映射关系简化授权管理。在可观测性平台中，建议预定义以下角色：

3.3.2 ABAC 扩展场景

当权限控制需要更细粒度时，ABAC 基于用户属性、资源属性和环境条件动态计算权限。典型场景包括：

• 时间窗口限制：仅允许在工作时间（09:00-18:00）执行高危操作（如删除数据源）。
• 环境属性过滤：开发工程师只能查看 environment=dev 或 environment=staging 的指标，不能访问生产环境。
• 数据标签匹配：用户只能访问带有 team=payment 标签的仪表盘和告警。

3.4 权限模型与数据隔离的协同

多租户架构、数据隔离和权限模型三者必须协同工作，形成完整的访问控制链路：

1. 认证阶段：用户登录后，平台从 中解析出 tenant_id 和 user_id。
2. 授权阶段：RBAC 引擎根据用户角色判定是否允许执行请求的操作（如查询、创建、删除）。
3. 数据过滤阶段：ABAC 引擎（如启用）根据资源标签和用户属性进一步过滤返回的数据行。
4. 存储隔离阶段：查询路由层将 tenant_id 注入到存储查询中，确保只访问该租户的数据分区。

// 伪代码：权限与隔离协同流程
function handleRequest(user, request) {
    // 1. 认证
    tenantId = extractTenantFromToken(user.);
    
    // 2. RBAC 授权
    if (!rbacEngine.authorize(user.role, request.action, request.resource)) {
        return 403 Forbidden;
    }
    
    // 3. ABAC 数据过滤（可选）
    filterExpr = abacEngine.buildFilter(user.attributes, request.resource.attributes);
    
    // 4. 注入租户隔离条件
    query = request.query + " WHERE tenant_id = " + tenantId;
    if (filterExpr) {
        query += " AND " + filterExpr;
    }
    
    // 5. 执行查询
    return storageEngine.execute(query);
}