2. 核心概念：策略引擎、策略即代码、策略即服务、策略即测试的区别与联系
在构建 Policy as Code 流水线之前，必须厘清四个核心概念：策略引擎、策略即代码、策略即服务与策略即测试。它们分别对应策略的执行载体、表达形式、交付模式和质量保障。混淆这些概念会导致流水线设计失衡——要么引擎选型错误，要么策略无法复用，要么测试覆盖不足。
2.1 概念定义与职责边界
| 概念 | 英文 | 核心职责 | 类比（传统开发） |
|---|---|---|---|
| 策略引擎 | Policy Engine | 加载策略规则，对输入数据进行评估并返回决策结果 | 运行时 / 解释器 |
| 策略即代码 | Policy as Code | 用声明式或函数式语言将策略编写为可版本管理的代码文件 | 源代码 |
| 策略即服务 | Policy as a Service | 将策略引擎封装为网络服务，通过 API 对外提供策略评估能力 | 微服务 |
| 策略即测试 | Policy as Test | 为策略代码编写单元测试、集成测试和契约测试，纳入 CI 门禁 | 自动化测试 |
记忆锚点：策略即代码解决“怎么写”，策略引擎解决“怎么跑”，策略即服务解决“怎么给”，策略即测试解决“怎么对”。四者缺一不可。
2.2 四者关系架构图
下图展示了四个概念在流水线中的分层关系与数据流向。策略即代码作为输入源，经过策略引擎评估后，通过策略即服务暴露给外部消费者；策略即测试则贯穿整个生命周期，对代码和服务进行持续验证。
2.3 关键区别对比
以下从六个维度进一步区分四个概念，帮助你在实际选型与架构设计中做出正确判断：
| 对比维度 | 策略即代码 | 策略引擎 | 策略即服务 | 策略即测试 |
|---|---|---|---|---|
| 产出物 | .rego / .yaml / .json 文件 | 二进制 / 容器 / 库 | REST / gRPC 端点 | 测试用例 + 覆盖率报告 |
| 版本管理 | Git 仓库 | 容器镜像仓库 | API 版本号 | 与策略代码同仓库 |
| 变更频率 | 高（业务规则变化） | 低（引擎升级） | 中（接口演进） | 高（随策略同步） |
| 故障影响域 | 策略评估结果错误 | 引擎崩溃 / 性能瓶颈 | 服务不可用 / 超时 | 误报 / 漏报 |
| 典型工具 | OPA Rego, Sentinel, Cedar | OPA, Kyverno, HashiCorp Sentinel | OPA REST API, Cedar Agent | OPA Test, Conftest, Regal |
| 调试方式 | REPL / 静态分析 | 日志 / 指标 / 追踪 | curl / Postman / 客户端 SDK | 断言失败输出 / 覆盖率 |
2.4 流水线中的协作流程
在 CI/CD 流水线中，四个概念按以下顺序协作，形成完整的策略交付闭环：
- 编写（策略即代码）：开发者在 IDE 中编写 Rego 或 YAML 策略文件，提交至 Git 仓库。
- 验证（策略即测试）：CI 阶段自动执行
opa test或conftest verify，确保策略逻辑正确。 - 打包（策略即代码 + 引擎）：将策略代码与引擎二进制打包为容器镜像或可分发 Bundle。
- 部署（策略即服务）：将打包后的策略引擎以 Sidecar 或独立服务形式部署，暴露 API 端点。
- 调用（策略即服务）：微服务或 CI 工具通过 HTTP/gRPC 调用策略服务，传入上下文数据，获取决策结果。
实践要点：策略即测试不应只在策略代码变更时执行。建议在每次引擎版本升级或服务配置变更时，也触发完整的策略测试套件，防止回归。
2.5 策略即测试的独立价值
策略即测试并非策略即代码的附属品，它有独立的工程价值：
- 防止策略漂移：通过断言锁定预期行为，避免无意的规则修改导致安全漏洞。
- 加速调试：测试用例本身就是可执行的文档，新人可通过测试理解策略意图。
- 支撑重构：当策略引擎升级或语法变更时，测试套件是唯一的安。
- 度量覆盖率：策略覆盖率（Policy Coverage）应作为流水线门禁指标之一，低于阈值则阻断发布。
常见误区：不要将策略即测试等同于“手动验证”。策略即测试必须是自动化、可重复、可量化的。在流水线中，策略测试失败应直接阻断后续阶段，而非仅输出警告。
2.6 总结：四者协同模型
四个概念构成一个完整的策略生命周期模型：
- 策略即代码是输入，提供可读、可审计的策略定义。
- 策略引擎是处理器，将代码转化为可执行的决策逻辑。
- 策略即服务是接口，将引擎能力标准化、服务化。
- 策略即测试是保障，确保前三者的正确性与稳定性。