4. 策略节点路由基础

在风控决策流中,策略节点负责“算”,路由负责“走”。当一次请求进入决策流后,系统需要根据当前上下文、用户特征、设备信息、名单状态或上游节点输出,决定下一步进入哪个策略节点。这个“决定下一步去哪”的机制,就是策略节点路由。它决定了决策流的可扩展性、可维护性与线上稳定性。

一、核心原理:路由是决策流的调度器

路由的本质是一个映射函数:输入是当前请求上下文与节点执行结果,输出是下一个或多个待执行节点。一个完整的路由体系通常包含五个要素:

  • 路由定义:描述“从哪个节点出发、满足什么条件、去往哪个节点”。
  • 路由表:所有路由定义的集合,是运行时查询的核心数据结构。
  • 优先级:当多条路由同时命中时,决定谁先被采用。
  • 命中策略:定义条件匹配方式,如精确匹配、范围匹配、表达式匹配、集合包含等。
  • 默认路由与兜底逻辑:当没有任何显式路由命中时,保证流程仍能继续或安全终止。

如果把策略节点比作函数,那么路由就是调用链。没有路由,节点只是孤立的计算单元;有了路由,节点才形成可编排、可复用、可观测的决策网络。

二、方法流程:从定义到执行

路由的落地通常遵循“定义—注册—匹配—执行—兜底”五步流程。

  1. 定义路由:明确源节点、目标节点、条件表达式与优先级。
  2. 注册路由表:将路由加载到内存或配置中心,支持热更新与版本管理。
  3. 运行时匹配:按优先级从高到低遍历,找到第一条满足条件的路由。
  4. 执行跳转:将请求上下文传递给目标节点,继续执行。
  5. 兜底处理:若全部未命中,走默认路由或进入人工审核、拒绝、降级等安全分支。

下面是一个简化的路由表配置示例,采用 JSON 表达:

{
  "routes": [
    {
      "id": "r-high-risk-device",
      "from": "risk_score",
      "to": "device_verify",
      "priority": 100,
      "condition": "riskScore >= 80 && deviceRisk == 'high'"
    },
    {
      "id": "r-medium-risk",
      "from": "risk_score",
      "to": "sms_verify",
      "priority": 50,
      "condition": "riskScore >= 50 && riskScore < 80"
    },
    {
      "id": "r-default",
      "from": "risk_score",
      "to": "pass",
      "priority": 0,
      "condition": "true"
    }
  ]
}

执行时,引擎会先匹配优先级 100 的路由,再匹配 50,最后匹配 0。优先级数值越大越先匹配,这是常见约定,但不同引擎可能相反,必须在团队内统一并写入文档。

建议将“默认路由”的优先级设为最低,并显式配置条件为 true,避免依赖隐式兜底。显式默认路由更易审计、更易测试。

三、案例场景:一次支付风控请求的路由过程

假设一次支付请求进入决策流,先经过 risk_score 节点得到风险分 72,设备风险为中。路由表按优先级匹配:

  • 优先级 100 的“高风险设备”路由条件不满足,跳过。
  • 优先级 50 的“中风险”路由条件满足,命中,跳转至 sms_verify。
  • 后续 sms_verify 节点输出验证通过,再根据其路由表进入 pass 或 reject。

如果此时配置中心误删了所有路由,或条件表达式因字段缺失全部为 false,那么默认路由就会生效,将请求导向 pass 或 manual_review。默认路由的选择直接体现业务风险偏好:偏保守则导向人工审核,偏体验则导向通过但打标观察。

下表对比了常见命中策略的适用场景与注意事项:

命中策略 适用场景 注意事项
精确匹配 枚举值、渠道号、事件类型 新增枚举需同步更新路由表
范围匹配 风险分、金额、年龄区间 注意边界开闭与区间重叠
表达式匹配 多字段组合、复杂业务规则 需做空值保护与性能评估
集合包含 名单、标签、白名单 集合大小影响匹配耗时
默认路由 无任何显式路由命中 必须显式配置并纳入监控

四、误区与复盘:路由设计中的常见坑

误区一:优先级冲突。两条路由条件同时命中且优先级相同,不同引擎可能按注册顺序或哈希顺序选择,导致结果不稳定。应保证同一源节点下优先级唯一,或明确二级排序规则。

误区二:默认路由缺失。很多线上事故源于“没有命中任何路由,流程直接中断”。默认路由不是可选项,而是决策流的安全网。

误区三:兜底逻辑过于宽松。默认路由直接放行,可能让高风险请求绕过验证。兜底应遵循“最小风险”原则,优先人工审核或降级验证。

误区四:路由表与节点版本脱节。节点升级后输出字段变更,旧路由条件引用已废弃字段,导致条件恒为 false。应将路由表与节点 schema 一起做版本管理和回归测试。

上线前必须做“路由覆盖率测试”:构造正常、边界、异常三类输入,确认每条路由至少被命中一次,且默认路由在无匹配时确实生效。未覆盖的路由等于线上隐患。

复盘时建议记录每次路由跳转的 routeId、from、to、priority 与命中条件快照。这样当决策结果异常时,可以快速定位是“节点算错”还是“路由走错”。路由可观测性,是决策流稳定运行的基础能力。

掌握路由定义、路由表、优先级、命中策略、默认路由与兜底逻辑,就掌握了策略节点编排的调度权。后续无论增加多少策略节点,只要路由体系清晰,决策流就能保持可读、可控、可演进。