3. 服务边界定义：什么是服务边界，为什么在管道中需要划分边界
在分布式系统与多租户可观测性管道中，服务边界并非物理网络分区，而是指一组具有明确职责、数据隔离域和生命周期边界的逻辑单元。它定义了“谁负责什么数据”、“数据流向何处”以及“故障如何隔离”。
3.1 服务边界的核心定义
服务边界由以下三个维度共同构成：
| 维度 | 定义 | 在多租户管道中的体现 |
|---|---|---|
| 职责边界 | 服务只处理与其功能域相关的数据转换或路由逻辑 | 租户身份注入服务只负责添加 tenant.id，不参与采样决策 |
| 数据边界 | 服务仅访问其授权范围内的数据存储与上下文 | 租户 A 的 Span 数据不能写入租户 B 的索引 |
| 故障边界 | 一个服务的崩溃、延迟或资源耗尽不影响其他服务 | 租户 C 的批量导出失败不会阻塞租户 D 的实时流 |
关键认知： 服务边界 = 职责域 ∩ 数据域 ∩ 故障域。缺少任何一个维度，边界都是脆弱的。
3.2 为什么在管道中需要划分边界
未划分边界的管道会退化为“单体数据泥潭”，导致以下典型问题：
- 数据泄露与合规风险 —— 所有租户的 Trace 数据混入同一个 Kafka Topic，无法按租户粒度执行数据保留策略或 GDPR 删除请求。
- 故障爆炸半径过大 —— 一个租户的异常数据格式（如超大 Span 属性）导致整个 Collector 实例 OOM，所有租户同时丢失数据。
- 性能干扰不可控 —— 高流量租户的批处理背压传导至低流量租户的导出管道，造成非关联性延迟抖动。
- 运维与成本归属模糊 —— 无法准确统计每个租户消耗的 CPU、内存、网络带宽，导致成本分摊失真。
反模式警示： 不要将“多租户”等同于“多命名空间”。仅仅在 Kubernetes Namespace 层面隔离 Collector 实例，而不在数据管道内部定义服务边界，仍然无法解决数据混淆和故障扩散问题。
3.3 管道中的服务边界划分模型
在 OpenTelemetry 多租户管道中，服务边界通常按以下层级划分：
3.4 边界划分的粒度决策
划分粒度需要在隔离性与资源效率之间权衡。以下表格对比了三种常见策略：
| 划分粒度 | 隔离强度 | 资源开销 | 适用场景 |
|---|---|---|---|
| 进程级（每租户独立 Collector 进程） | 最高 | 高 | 金融、医疗等强合规场景；租户数量少（< 50） |
| 管道级（共享 Collector，独立 Pipeline 定义） | 中 | 中 | 大多数企业级多租户场景；租户数量中等（50–500） |
| 处理器级（共享 Pipeline，通过属性路由隔离） | 低 | 低 | 内部开发环境、低风险租户；租户数量大（> 500） |
实践建议： 从“管道级”隔离开始。它提供了足够的故障隔离能力，同时避免了进程级隔离带来的配置管理爆炸。当出现特定租户的合规审计要求时，再将该租户升级为进程级隔离。
3.5 边界划分的代码体现
在 OpenTelemetry Collector 配置中，服务边界通过 pipelines 和 processors 的独立定义来体现：
# 租户 A 的独立管道定义
service:
pipelines:
traces/tenant-a:
receivers: [otlp/tenant-a]
processors: [memory_limiter, batch/tenant-a, attributes/tenant-a]
exporters: [otlp/backend-tenant-a]
traces/tenant-b:
receivers: [otlp/tenant-b]
processors: [memory_limiter, batch/tenant-b, attributes/tenant-b]
exporters: [otlp/backend-tenant-b]
# 每个管道拥有独立的 batch 和 attributes 处理器实例
processors:
batch/tenant-a:
timeout: 5s
send_batch_size: 1000
batch/tenant-b:
timeout: 10s
send_batch_size: 500上述配置中，traces/tenant-a 和 traces/tenant-b 是两个完全独立的处理管道，它们共享 Collector 进程但拥有独立的处理器实例和导出目标——这就是管道级服务边界的典型实现。