2. 架构设计原则：单体 vs 微服务架构下的可观测性挑战，租户隔离的架构模式

在构建可观测性体系时，架构风格直接决定了数据采集、存储、查询的复杂度与隔离能力。单体架构与微服务架构在可观测性上面临截然不同的挑战，而租户隔离的选型则需要在成本、安全与运维复杂度之间做出权衡。

2.1 单体架构下的可观测性挑战

单体应用将所有功能模块部署在同一个进程中，日志、指标、链路数据集中产生。这种集中性带来了简单的数据采集路径，但也隐藏着严重的可观测性瓶颈。

2.2 微服务架构下的可观测性挑战

微服务架构将单体拆分为数十甚至数百个独立服务，每个服务独立部署、独立扩展。这种分布式特性使得可观测性面临全新的复杂性。

• 链路追踪碎片化： 一次用户请求可能跨越 5～15 个服务，需要全局 Trace ID 串联所有 Span。
• 日志分散： 每个服务输出独立的日志流，缺乏统一采集与关联能力。
• 指标基数爆炸： 每个服务暴露多个指标，加上租户维度标签，时间序列数量呈指数级增长。
• 租户数据交叉： 多个租户共享同一服务实例，日志与指标中必须携带租户上下文，否则无法实现数据级隔离。
• 排障链路长： 从告警到根因定位，需要跨服务、跨团队协作，可观测性数据必须形成闭环。

2.3 租户隔离的三种架构模式

租户隔离的核心目标是确保一个租户的可观测性数据不会影响另一个租户的可用性、性能与安全性。根据隔离粒度与成本，业界主要采用三种模式：数据隔离、服务隔离、混合隔离。

2.3.1 数据隔离模式

数据隔离是最轻量的实现方式。所有租户的日志、指标、链路数据写入同一套存储后端，通过数据中的 tenant_id 字段进行逻辑分区。查询时由可观测性平台自动附加租户过滤条件。

# 结构化日志示例：数据隔离模式
{
  "timestamp": "2025-03-21T10:30:00.123Z",
  "level": "ERROR",
  "tenant_id": "tenant_alpha",
  "service": "order-service",
  "trace_id": "abc123def456",
  "message": "订单支付超时",
  "metadata": {
    "order_id": "ORD-20250321-001",
    "amount": 299.00
  }
}

2.3.2 服务隔离模式

服务隔离为每个租户部署独立的数据采集 Agent、消息队列、存储集群。租户之间在基础设施层面完全隔离，不存在资源争抢。

# 部署拓扑示意：服务隔离模式
租户 A → Agent A → Kafka Cluster A → Elasticsearch Cluster A
租户 B → Agent B → Kafka Cluster B → Elasticsearch Cluster B
租户 C → Agent C → Kafka Cluster C → Elasticsearch Cluster C

2.3.3 混合隔离模式

混合隔离是数据隔离与服务隔离的折中方案。核心可观测性数据（如审计日志、安全告警）采用服务隔离，确保合规与安全；非核心数据（如调试日志、性能指标）采用数据隔离，降低存储成本。

典型的混合隔离策略如下：

• 核心链路： 每个租户独立部署 Trace 采集与存储，保证链路追踪的完整性与隔离性。
• 日志分级： ERROR 及以上级别日志按租户隔离存储；INFO/DEBUG 日志共享存储，按标签过滤。
• 指标聚合： 租户级核心指标（如 P99 延迟、错误率）独立存储；细粒度调试指标共享存储。

2.4 架构选型决策矩阵

在实际项目中，选择哪种隔离模式需要综合考虑租户规模、安全等级、预算与运维能力。以下决策矩阵可作为参考：

2.5 架构设计原则总结

无论选择哪种架构风格与隔离模式，以下原则应贯穿可观测性体系的设计始终：

• 数据标准化先行： 在架构选型之前，先定义统一的日志、指标、链路数据模型，确保所有服务输出结构一致。
• 租户上下文透传： 从网关层开始，将 tenant_id 注入请求上下文，确保所有可观测性数据都能关联到租户。
• 隔离强度与成本平衡： 不要追求绝对的物理隔离，根据数据敏感度与租户规模选择混合策略。
• 可观测性即产品： 将可观测性能力作为 SaaS 产品的一部分提供给租户，而非仅作为运维工具。
• 渐进式演进： 从数据隔离起步，随着租户规模增长逐步迁移到混合隔离或服务隔离。