2. 可观测性基础：三大支柱与 OpenTelemetry 项目简介
在深入 BFF 层链路优化之前，必须先建立统一的可观测性认知框架。本章从“为什么需要可观测性”出发，拆解日志、指标、链路三大支柱的核心差异与协作关系，并介绍 OpenTelemetry 作为统一标准如何解决传统埋点碎片化问题。
2.1 可观测性三大支柱
可观测性（Observability）并非简单的“监控升级”，而是通过系统外部输出来推断内部状态的能力。业界公认的三大数据支柱如下：
| 支柱 | 数据形态 | 典型用途 | 查询方式 | BFF 层关注点 |
|---|---|---|---|---|
| 日志（Logs） | 带时间戳的离散事件记录 | 错误排查、审计、详细上下文 | 全文检索、关键词过滤 | 请求/响应体快照、异常堆栈 |
| 指标（Metrics） | 聚合后的数值时间序列 | 告警、容量规划、趋势分析 | PromQL 聚合、降采样 | QPS、延迟分位数、错误率 |
| 链路（Traces） | 端到端请求的有向图 | 性能瓶颈定位、依赖分析 | TraceID 检索、Span 拓扑 | 跨服务调用链、BFF 聚合耗时 |
核心认知：三大支柱并非互斥，而是互补。日志提供“发生了什么”，指标回答“有多少”，链路解释“为什么慢”。BFF 层作为流量入口和聚合枢纽，三者缺一不可。
2.2 三大支柱在 BFF 层的协作关系
下图展示了 BFF 层在一次典型请求中，三大支柱如何协同工作：
BFF 层实践要点：在 BFF 的请求入口处生成全局 TraceID，将其注入日志上下文和指标标签。这样当某个上游接口出现高延迟时，可以快速从指标下钻到具体 Trace，再通过日志还原请求参数。
2.3 OpenTelemetry 项目简介
OpenTelemetry（简称 OTel）是 CNCF 的毕业项目，旨在提供一套厂商无关的、标准化的可观测性数据采集、处理和导出框架。它合并了 OpenTracing 和 OpenCensus 两大社区，成为事实上的行业标准。
2.3.1 核心组件
| 组件 | 职责 | BFF 层典型用法 |
|---|---|---|
| API | 定义 Tracer、Meter、Logger 接口 | 引入 SDK 包，调用 API 创建 Span |
| SDK | 提供默认实现：采样、处理、导出 | 配置 BatchSpanProcessor、资源属性 |
| Collector | 接收、处理、转发遥测数据 | 部署为 Sidecar 或独立网关，做数据过滤与聚合 |
| Exporter | 将数据发送到后端（Jaeger、Prometheus、Loki 等） | 配置 OTLP Exporter 或特定后端 Exporter |
| Instrumentation | 自动埋点库（HTTP、gRPC、DB 等） | 使用 Node.js/Java 自动 instrumentation 包 |
2.3.2 数据模型与传播协议
OTel 定义了统一的数据模型，核心概念包括：
- Span：一次操作的基本单元，包含名称、开始/结束时间、属性、事件、状态。
- Trace：由多个 Span 组成的树状结构，通过 TraceID 关联。
- Resource：描述产生数据的实体（如服务名、版本、主机）。
- InstrumentationScope：标识产生数据的库或模块。
传播协议方面，OTel 推荐使用 W3C TraceContext 标准（traceparent 和 tracestate 头），确保跨服务、跨语言时链路不中断。
常见误区：不要将 OpenTelemetry 等同于“链路追踪”。OTel 同时支持日志、指标、链路三大信号，且提供了统一的 Context 传播机制。在 BFF 层，应优先使用 OTel 的 Logs Bridge API 将结构化日志与 Trace 关联，而非单独维护一套日志框架。
2.4 BFF 层引入 OpenTelemetry 的典型架构
下图展示了 BFF 服务集成 OTel 后的数据流转路径：
2.5 本章小结
- 可观测性三大支柱（日志、指标、链路）在 BFF 层各有侧重，通过 TraceID 实现关联分析。
- OpenTelemetry 提供了统一的 API、SDK、Collector 和 Exporter 生态，是 BFF 层可观测性建设的最佳起点。
- BFF 层应优先使用 W3C TraceContext 传播协议，并利用 OTel Collector 做数据预处理，避免直接向后端发送原始数据。