2. OPA基础回顾：OPA架构、Rego策略语言核心概念、OPA与Envoy/Kong等网关的集成模式
2.1 OPA整体架构与核心组件
Open Policy Agent (OPA) 是一个开源的、通用策略引擎，它将策略决策从应用逻辑中解耦出来。在API网关场景下，OPA作为策略决策点（PDP），接收来自网关（作为策略执行点PEP）的查询请求，基于Rego策略和输入数据做出决策，并返回结果。
OPA的核心架构遵循“查询-决策”模型，不直接修改请求，而是提供决策结果供网关执行。
架构要点： OPA本身不存储状态，所有外部数据（如用户列表、IP黑名单、服务元数据）必须通过数据推送（Push）或Bundle拉取（Pull）方式加载到OPA的内存中，以保证决策性能。
2.2 Rego策略语言核心概念
Rego是OPA专用的声明式策略语言，灵感来源于Datalog。它专注于“策略即代码”，通过规则（Rules）和查询（Queries）来表达策略逻辑。
| 概念 | 说明 | 示例 |
|---|---|---|
| 规则（Rule） | 策略的基本单元，定义决策逻辑 | allow { input.method == "GET" } |
| 文档（Document） | 规则求值后生成的数据结构 | default allow = false |
| 输入（input） | 查询时传入的请求数据 | input.path, input.headers |
| 数据（data） | 外部加载的全局数据 | data.users, data.roles |
| 迭代（Iteration） | 隐式遍历集合，无需显式循环 | some user in data.users |
| 内置函数 | 字符串、正则、JWT、HTTP等操作 | io.jwt.decode() |
关键理解： Rego 中的规则默认是“全量求值”，即所有规则都会被计算。在性能调优时，应避免在规则中编写大量嵌套循环或复杂正则，优先使用索引（Indexing）和部分求值（Partial Evaluation）来加速决策。
2.2.1 典型Rego策略示例
package api.auth
# 默认拒绝
default allow = false
# 允许条件：用户角色为 admin 且请求路径以 /admin 开头
allow {
input.role == "admin"
startswith(input.path, "/admin")
}
# 允许条件：请求方法为 GET 且路径在白名单中
allow {
input.method == "GET"
input.path in data.whitelist_paths
}
# 拒绝条件：请求来源IP在黑名单中
deny["blocked_ip"] {
input.client_ip in data.blacklist_ips
}2.3 OPA与API网关的集成模式
OPA与API网关的集成主要分为边车模式（Sidecar）和远程模式（Remote）两种。在性能敏感的场景下，边车模式因零网络延迟而成为首选。
| 集成模式 | 部署方式 | 延迟特征 | 适用场景 |
|---|---|---|---|
| 边车模式 | OPA作为Sidecar与网关同Pod部署 | 微秒级（本地IPC） | 高吞吐、低延迟要求 |
| 远程模式 | OPA作为独立服务，网关通过HTTP/gRPC调用 | 毫秒级（网络开销） | 策略集中管理、多网关共享 |
2.3.1 OPA与Envoy集成（基于Envoy External Authorization Filter）
Envoy通过ext_authz过滤器与OPA集成。Envoy将HTTP请求的元数据（路径、方法、头部等）封装为CheckRequest发送给OPA，OPA返回CheckResponse，包含是否允许以及可选的自定义头部。
- 集成方式： Envoy配置ext_authz gRPC服务指向OPA的地址。
- 数据流： 请求到达Envoy → ext_authz过滤器 → OPA决策 → 允许则转发，拒绝则返回403。
- 性能关键点： 使用缓存（Cache）和异步流（Streaming）减少重复决策。
2.3.2 OPA与Kong集成（基于Kong Plugin）
Kong通过OPA插件实现集成。该插件在Kong的访问阶段（access phase）调用OPA的REST API，将请求上下文作为JSON发送，OPA返回决策结果。
- 集成方式： 安装并启用
opa插件，配置OPA服务端点。 - 数据流： 请求进入Kong → OPA插件 → HTTP POST到OPA → 决策返回 → 允许则继续，拒绝则中断。
- 性能关键点： 使用连接池和本地决策缓存降低OPA调用频率。
2.4 集成模式选型建议
在实际项目中，选择哪种集成模式需要综合考虑延迟要求、运维复杂度和策略一致性。
选型建议：
- 延迟敏感型（如金融交易、实时API）：优先选择 Envoy 边车模式，将 OPA 与网关部署在同一 Pod 内，避免网络跳转。
- 策略集中管理型（如多团队共享策略）：选择 Kong 远程模式或 Envoy 远程模式，OPA 作为中心化服务，便于策略更新和审计。
- 多集群架构：建议在每个集群内部署边车 OPA，并通过全局 Bundle 服务同步策略和数据，避免跨集群决策延迟。
注意： 在远程模式下，OPA 服务的可用性和延迟直接影响网关的响应时间。必须为 OPA 服务配置熔断（Circuit Breaker）、超时（Timeout）和降级（Fallback）策略，防止 OPA 故障导致网关雪崩。