3. 值班台架构概览：微服务拓扑、核心链路识别、数据流与依赖关系
值班台作为平台工程的核心可观测性入口，其自身架构必须满足高可用、低延迟与可扩展的要求。本章从微服务拓扑、核心链路、数据流与依赖关系四个维度，拆解值班台的整体架构设计。
3.1 微服务拓扑总览
值班台采用微服务架构，按职责划分为四层：接入层、聚合层、存储层与通知层。各层通过 gRPC 或异步消息队列通信，避免单点瓶颈。
架构原则：每一层均部署至少 2 个副本，跨可用区分布；关键服务（如告警引擎、Trace 聚合器）采用 Leader/Follower 选举机制。
3.2 核心链路识别
在值班台的数十个微服务中，以下三条链路对高可用性影响最大，必须优先保障：
| 链路名称 | 涉及服务 | SLO 目标 | 故障影响 |
|---|---|---|---|
| Trace 采集与存储链路 | Agent → Trace 聚合器 → Kafka → ES | P99 延迟 < 2s | Trace 数据丢失，无法排查故障 |
| 告警触发与通知链路 | 告警引擎 → 事件关联器 → 通知层 | P99 延迟 < 10s | 告警延迟或漏报，值班响应失效 |
| 实时看板数据链路 | WebSocket Hub → 指标计算器 → Redis → 前端 | P99 延迟 < 1s | 看板卡顿，值班员无法实时感知 |
设计要点：核心链路中的每个中间件（Kafka、Redis、ES）均采用集群模式，并配置熔断与降级策略。例如，当 ES 写入积压时，Trace 聚合器自动降级为本地文件缓存，待恢复后回放。
3.3 数据流与依赖关系
值班台的数据流分为上行数据流（从被监控系统到值班台）与下行数据流（值班台内部处理与通知）。依赖关系则体现为服务间的同步/异步调用与数据一致性要求。
3.3.1 上行数据流
- Agent 采集：部署在各业务节点的 Agent 通过 OTLP 协议上报 Trace、Metrics、Logs。
- 接入层路由：API Gateway 根据请求类型分发至对应的聚合服务。
- 聚合与缓冲：Trace 聚合器对 Span 进行采样与合并，写入 Kafka 缓冲；指标计算器实时聚合 Metrics 并写入 Redis。
- 持久化：Kafka Consumer 将 Trace 数据批量写入 Elasticsearch；Prometheus 从指标计算器拉取数据。
3.3.2 下行数据流
- 告警检测：告警引擎定期查询 ES 与 Prometheus，匹配告警规则。
- 事件关联：事件关联器合并重复告警，生成故障事件。
- 通知分发：通知层根据事件级别与值班排班表，通过多渠道推送。
- 前端渲染：WebSocket Hub 将实时数据推送至值班看板。
3.4 依赖关系矩阵
下表列出值班台核心服务间的依赖关系与故障传播影响：
| 上游服务 | 下游服务 | 调用方式 | 故障影响范围 | 降级策略 |
|---|---|---|---|---|
| Agent | Trace 聚合器 | gRPC 同步 | Trace 采集中断 | Agent 本地缓存，重试回放 |
| Trace 聚合器 | Kafka | 异步生产 | Trace 数据堆积 | 限流降级，丢弃低优先级 Span |
| 告警引擎 | Elasticsearch | 同步查询 | 告警检测延迟 | 切换至 Prometheus 查询 |
| 事件关联器 | 通知层 | 异步消息 | 通知延迟 | 消息队列持久化，消费端幂等 |
| WebSocket Hub | Redis | 同步订阅 | 看板数据中断 | 前端轮询降级至 REST API |
关键依赖风险：Elasticsearch 与 Kafka 是值班台的两大状态依赖。ES 故障会导致 Trace 查询与告警规则匹配不可用；Kafka 故障则阻塞所有异步数据流。生产环境必须为这两个组件部署跨可用区集群，并配置自动故障转移。
3.5 架构设计要点总结
- 无状态优先：接入层与聚合层服务均设计为无状态，通过 K8s HPA 自动扩缩。
- 异步解耦：核心链路使用 Kafka 或 Redis Stream 做异步缓冲，避免级联故障。
- 熔断与降级：每个服务依赖外部组件时均配置熔断器（如 Hystrix 或 Sentinel），并定义明确的降级返回值。
- 可观测性自监控：值班台自身 Trace 与 Metrics 通过独立 Agent 上报至另一套存储集群，避免与业务数据互相影响。