3. 策略即代码框架：OPA、Kyverno、CUE 等策略引擎在路由决策中的应用与延迟影响

在入口路由场景中，策略即代码（Policy-as-Code）将路由决策从硬编码逻辑或人工配置中剥离，交由专门的策略引擎执行。不同的策略引擎在架构设计、评估模型、缓存机制上存在显著差异，这些差异直接影响路由决策的延迟特征。本章聚焦 OPA、Kyverno、CUE 三种主流引擎，分析其在路由决策中的应用模式与延迟影响。

3.1 策略引擎核心对比

3.2 OPA：实时路由决策与延迟特征

OPA 在入口路由中最常见的部署模式是作为 Sidecar 代理 或 外部决策服务。API 网关（如 Envoy、Kong）在每次请求到达时，向 OPA 发送查询，OPA 根据 Rego 策略返回允许/拒绝决策。

3.2.1 延迟构成分析

• 网络往返延迟： 网关与 OPA 之间的 gRPC/HTTP 调用，通常占 0.5ms – 3ms。
• 策略评估延迟： Rego 规则复杂度、数据量大小决定，典型值 0.1ms – 10ms。
• 数据加载延迟： OPA 从外部数据源（如 Bundle、API）拉取数据，可能引入 10ms – 100ms 的首次加载延迟。
• 缓存命中率： 内置缓存可减少重复评估，但缓存失效策略不当会导致延迟抖动。

3.2.2 延迟优化策略

1. 部分评估（Partial Evaluation）： 将策略拆分为静态部分和动态部分，静态部分预编译为决策树。
2. 决策缓存： 对相同输入参数的请求启用缓存，TTL 根据策略变更频率设置。
3. 连接池复用： 网关与 OPA 之间使用长连接，避免每次请求建立新连接。
4. 数据分片： 将全局数据与局部数据分离，减少每次评估的数据加载量。

3.3 Kyverno：准入控制路由与延迟特征

Kyverno 在 Kubernetes 环境中作为 准入 Webhook 运行，拦截资源变更请求（如创建 Pod、更新 Ingress），根据 YAML 规则进行校验或变更。路由决策发生在资源变更时，而非每次请求。

3.3.1 延迟构成分析

• Webhook 序列化延迟： AdmissionReview 请求的 JSON 序列化/反序列化，通常占 1ms – 5ms。
• 规则匹配延迟： 根据资源类型、标签、命名空间匹配规则，复杂度 O(n)，n 为规则数量。
• 策略执行延迟： 执行 mutate/validate/generate 操作，涉及 API Server 调用时延迟增加。
• 超时机制： Kubernetes 默认 Webhook 超时 30s，但建议设置 5s – 10s 以避免 API Server 阻塞。

3.3.2 延迟优化策略

1. 规则分组： 将高频规则与低频规则分离，使用不同的 Webhook 配置。
2. 背景扫描（Background Scan）： 将非关键策略改为后台扫描模式，避免阻塞准入请求。
3. 资源过滤： 在 Webhook 配置中通过 objectSelector 和 namespaceSelector 减少不必要的 Webhook 调用。
4. 并发控制： 调整 Kyverno 的 maxQueuedRequests 和 workerCount 参数，避免请求排队。

3.4 CUE：编译时策略与零运行时延迟

CUE 的策略评估发生在 配置生成与编译阶段，而非运行时。在入口路由场景中，CUE 用于定义路由配置的约束（如路径格式、后端服务白名单、限流阈值），在配置下发到网关之前完成校验。

3.4.1 延迟特征

• 编译时延迟： CUE 的约束求解和类型检查在配置生成时完成，延迟取决于配置规模，通常 10ms – 500ms。
• 运行时延迟： 零额外延迟。网关直接加载已校验的配置，无需调用外部策略引擎。
• 变更延迟： 配置变更时需重新编译，但编译过程可异步执行，不影响现有路由。

3.4.2 CUE 路由策略示例

// 定义路由路径约束
#Route: {
  path: string
  methods: [...string]
  backend: string
  rateLimit?: int >= 0
}

// 校验规则：路径必须以 /api/v1 开头
#Route & {
  path: =~"^/api/v1/"
}

// 校验规则：后端服务必须在白名单中
#Route & {
  backend: "service-a" | "service-b" | "service-c"
}

3.5 策略引擎路由决策流程对比

3.6 延迟影响总结与选型建议