1. 课程导论：事件驱动架构与值班机器人概述，为什么需要链路诊断

1.1 事件驱动架构的核心概念

事件驱动架构（Event-Driven Architecture, EDA）是一种基于事件产生、检测、消费和响应的软件架构范式。在EDA中，组件之间不直接调用，而是通过事件总线或消息队列进行异步通信。这种架构天然适合高并发、低耦合、可扩展的分布式系统。

1.2 值班机器人：事件驱动的典型场景

值班机器人（On-Call Bot）是事件驱动架构在运维领域的典型应用。当监控系统检测到异常（如CPU飙升、错误率突增、P1告警），会生成一个事件，经过路由、去重、升级、通知等环节，最终触达值班工程师。

一个完整的事件触发值班机器人流程通常包含以下阶段：

1. 事件产生：Prometheus Alertmanager、Grafana、自定义监控脚本等触发告警事件。
2. 事件路由：消息队列（Kafka/RabbitMQ）或事件总线分发事件。
3. 事件处理：去重、抑制、聚合、优先级判定。
4. 值班匹配：根据排班表、技能组、轮转规则确定目标工程师。
5. 通知触达：通过钉钉/飞书/企业微信/Slack/PagerDuty等渠道发送通知。
6. 事件闭环：确认、升级、自动恢复、事后复盘。

1.3 为什么需要链路诊断

在事件驱动架构中，一个事件的生命周期跨越多个服务、多个队列、多个异步边界。传统的日志+指标+告警三板斧在以下场景中力不从心：

• 跨服务追踪：事件从A服务发出，经过B、C、D服务，中间经过消息队列，如何串联完整路径？
• 延迟归因：事件总耗时5秒，是队列积压3秒，还是处理服务慢2秒？
• 失败定位：事件在哪个环节丢失？是消费失败、超时丢弃，还是路由错误？
• 上下文传递：告警事件的原始信息（如主机名、错误堆栈）如何在多个异步处理阶段中保持传递？

链路诊断（Distributed Tracing）正是解决上述问题的关键技术。通过为每个事件注入唯一的Trace ID，并在每个处理节点记录Span，我们可以重建事件的完整执行路径，精确测量每个阶段的耗时，快速定位故障点。

1.4 本课程的核心目标

本课程将带领你从零构建一个事件触发值班机器人，并为其接入OpenTelemetry链路诊断能力。你将学到：

• 如何用Python/Go实现事件驱动架构的核心组件（事件生产者、消息队列消费者、事件处理器）。
• 如何在异步边界（消息队列、回调、定时任务）中正确传递和恢复Trace上下文。
• 如何通过OpenTelemetry SDK自动/手动埋点，生成符合W3C Trace Context标准的Span。
• 如何将链路数据导出到Jaeger、Zipkin或自建后端，进行可视化诊断。
• 如何基于链路数据快速定位“告警丢失”、“通知延迟”、“事件重复处理”等典型故障。

1.5 课程知识图谱

1.6 本章小结