1. 课程导论：什么是可观测性、OTel 在可观测性中的角色、为什么需要 Mock 隔离接口契约
1.1 什么是可观测性
可观测性（Observability）源自控制理论，指通过系统外部输出来推断系统内部状态的能力。在软件工程领域，可观测性是指通过分析系统产生的遥测数据，理解分布式系统的行为、性能与健康状况。
现代分布式系统的复杂性使得传统监控（Monitoring）难以覆盖未知问题。可观测性强调三大支柱的协同作用：
| 支柱 | 定义 | 典型数据 | 核心价值 |
|---|---|---|---|
| 日志（Logs） | 带时间戳的离散事件记录 | 错误堆栈、访问日志、业务事件 | 事后排查、详细上下文 |
| 指标（Metrics） | 可聚合的数值时间序列 | CPU 使用率、请求延迟、错误率 | 趋势分析、告警、容量规划 |
| 链路追踪（Traces） | 请求在分布式系统中的完整路径 | Span 树、服务间调用关系、耗时分布 | 根因定位、依赖分析、性能瓶颈 |
关键认知： 可观测性不是工具的堆砌，而是通过高质量、高关联度的遥测数据，让团队能够回答“系统为什么出问题”，而不仅仅是“系统是否出问题”。
1.2 OTel 在可观测性中的角色
OpenTelemetry（OTel）是 CNCF 孵化的可观测性标准与 SDK 框架，旨在统一遥测数据的采集、生成与导出。它填补了可观测性生态中“数据标准化”与“厂商中立”的关键空白。
OTel 在可观测性体系中的核心角色可归纳为以下四点：
- 数据模型标准化： 定义 Log、Metric、Trace 的统一数据模型，消除厂商锁定。
- 采集与导出解耦： 通过 Collector 组件实现数据路由、过滤、增强，与后端（Prometheus、Jaeger、Datadog 等）解耦。
- 多语言 SDK 覆盖： 提供 Java、Go、Python、JavaScript 等主流语言的 SDK，降低接入成本。
- 上下文传播机制： 通过 W3C TraceContext 标准，实现跨服务、跨协议的链路关联。
实践要点： OTel 不提供后端存储与可视化，而是作为“数据管道”连接应用与可观测性后端。选择 OTel 意味着选择标准，而非绑定特定厂商。
1.3 为什么需要 Mock 隔离接口契约
在可观测性系统的开发与测试中，团队常面临以下痛点：
- 依赖不可控： 后端服务（如 Jaeger、Prometheus）在开发环境不稳定或未部署。
- 数据污染： 测试流量与生产流量混合，导致指标失真、告警误报。
- 成本高昂： 频繁向真实后端发送遥测数据，消耗存储与网络资源。
- 场景覆盖难： 异常链路、高延迟、错误 Span 等边界条件难以在真实环境中复现。
Mock 隔离接口契约正是为解决上述问题而生。它定义了一套标准化的接口规范，用于模拟 OTel 数据接收端的行为，使开发与测试能够在隔离环境中验证遥测数据的正确性。
1.4 Mock 隔离接口契约的核心价值
| 价值维度 | 说明 | 收益 |
|---|---|---|
| 开发效率 | 无需启动真实后端，本地即可验证数据格式与内容 | 迭代速度提升 3-5 倍 |
| 测试确定性 | Mock 返回固定响应，消除环境波动导致的误判 | 测试通过率稳定在 99%+ |
| 场景覆盖 | 可模拟超时、错误码、空数据等极端情况 | 异常场景覆盖率提升至 90% |
| 契约一致性 | 接口契约作为“唯一真相”，约束前后端交互 | 减少联调返工，接口变更可追溯 |
| 成本控制 | Mock 服务运行在本地或 CI 环境，零存储成本 | 可观测性测试成本降低 80% |
常见误区： Mock 隔离不是“伪造数据”，而是“模拟后端行为”。契约必须与真实后端的行为保持一致，否则 Mock 测试将失去意义。建议定期使用契约一致性检查工具（如 Pact、Spring Cloud Contract）对齐 Mock 与真实后端。
1.5 本课程的学习路径
本课程将围绕 OTel 可观测 Mock 隔离接口契约，从以下维度展开：
- 基础篇： OTel 协议详解（OTLP、gRPC/HTTP 传输）、Span/Metric/Log 数据模型。
- 契约设计篇： 接口契约的编写规范、版本管理、兼容性策略。
- Mock 实现篇： 基于 OTel Collector 的 Mock 接收器、自定义 Mock 服务开发。
- 测试集成篇： 在单元测试、集成测试、CI/CD 流水线中嵌入 Mock 隔离。
- 实战案例篇： 微服务架构下的全链路 Mock 隔离方案、性能压测场景。
通过本课程，你将掌握一套可落地、可复用、可自动化的可观测性 Mock 隔离方案，显著提升团队在可观测性领域的开发与测试效率。