📚 课程目录第3章路由策略核心概念

路由策略核心概念：路由规则引擎、条件匹配、动作执行、路由拓扑

告警路由自动配置的核心在于一套可编程、可观测的策略体系。本章深入拆解路由策略的四个基础构件：规则引擎（决策大脑）、条件匹配（输入过滤）、动作执行（输出行为）与路由拓扑（路径结构）。理解这四个概念，是设计高可用、可变更的告警路由系统的前提。

3.1 路由规则引擎：策略的决策中枢

规则引擎是路由系统的“大脑”，负责接收告警事件、解析规则集、输出路由决策。一个生产级的规则引擎通常包含以下核心模块：

模块	职责	典型实现
事件接收器	标准化告警输入（JSON/Protobuf）	Webhook、Kafka Consumer
规则解析器	编译 DSL 规则为可执行条件树	AST 解析、表达式求值器
匹配执行器	按优先级遍历规则，执行条件匹配	短路匹配、并行匹配
动作调度器	将匹配结果映射为具体动作链	责任链模式、异步队列
缓存与状态	缓存规则元数据、告警去重状态	Redis、本地 LRU Cache

  设计要点：规则引擎必须支持热加载，避免因规则变更导致路由中断。建议将规则存储与引擎执行分离，通过配置中心（如 etcd / Consul）推送增量更新。

3.2 条件匹配：告警的精准过滤器

条件匹配决定了“哪些告警走哪条路”。匹配维度通常分为三类：

属性匹配：基于告警标签（severity、service、env）、时间戳、来源等字段做精确或模糊匹配。
上下文匹配：关联告警的依赖拓扑、历史事件、变更窗口状态（如“是否在变更窗口内”）。
复合条件：通过逻辑运算符（AND / OR / NOT）组合多个条件，支持嵌套优先级。

以下是一个典型的条件匹配 DSL 示例：

rule "critical_db_alert_to_pagerduty"
  when
    alert.severity == "critical"
    AND alert.service matches "mysql|postgresql"
    AND alert.env != "dev"
    AND window.status == "in_maintenance"  // 变更窗口上下文
  then
    route.to = "pagerduty_critical"
    route.priority = 1
end

避坑指南：避免在条件中使用“全量正则匹配”作为默认策略，会导致引擎性能急剧下降。优先使用精确匹配或前缀匹配，正则仅用于少数复杂场景。

3.3 动作执行：路由决策的输出行为

动作执行是条件匹配后的“输出端”。一个路由动作可以是一个原子操作，也可以是一组串行/并行的动作链。常见动作类型包括：

动作类型	说明	示例
转发	将告警发送到指定目标	PagerDuty、Slack、邮件
抑制	在指定时间内阻止重复告警	同服务 5 分钟内只发一次
聚合	将多条相关告警合并为一条	按主机+故障类型聚合
标签注入	为告警添加额外上下文标签	注入变更单 ID、责任人
回调	触发外部系统 API	自动创建 Jira Ticket

注意：动作执行必须设计幂等性与重试机制。例如，转发动作因网络抖动失败时，应自动重试 3 次并记录失败日志，避免告警丢失。

3.4 路由拓扑：告警的路径结构

路由拓扑定义了告警从“入口”到“出口”的完整路径结构。一个清晰的路由拓扑可以帮助团队快速理解告警流向、定位瓶颈与单点故障。拓扑通常分为两种模式：

线性拓扑：告警依次经过多个路由节点，每个节点执行一次匹配与动作。适合简单、固定的告警流。
分支拓扑：告警根据条件匹配结果，进入不同的分支路径。适合多租户、多环境、多优先级的复杂场景。

下图展示了一个典型的分支路由拓扑结构：

3.5 路由拓扑与变更窗口的集成

在变更窗口场景下，路由拓扑需要动态感知窗口状态。下图展示了变更窗口如何影响路由路径选择：

  架构建议：将变更窗口状态作为路由条件的一个一等公民字段。在规则引擎中，通过一个全局的 window.status 上下文变量，即可实现拓扑的动态切换，无需修改规则本身。

3.6 路由策略的常见反模式

反模式	问题	正确做法
单规则匹配所有告警	规则过于宽泛，无法精细控制	按服务/严重度/环境拆分为多条规则
动作执行无重试	网络抖动导致告警丢失	所有动作加入重试队列，最多 3 次
拓扑硬编码在代码中	变更需要重启服务	拓扑由配置中心动态下发
忽略变更窗口上下文	变更期间告警淹没正常通道	路由条件中注入 window.status

掌握路由策略的核心概念后，下一层我们将探讨如何将这些策略与变更窗口生命周期进行深度绑定，实现真正的“变更感知路由”。