授权策略一上量就拖慢接口：OPA 这类策略引擎的开销到底出在哪

某个接口的 P99 从十几毫秒涨到六七十毫秒，业务代码一行没动。火焰图上多出来一整段不属于任何业务逻辑的时间，标注是"去问一次策略服务"。团队的第一反应是策略引擎太慢，准备换方案，或者干脆把鉴权判断写回业务代码里。真去拆了调用链才发现，那段耗时里真正用于求值的部分不到两成，剩下的是一次跨机 HTTP 往返、一次十几 KB 的 JSON 序列化与反序列化、以及内核协议栈收发包的那几十微秒。把策略引擎挪到本机做 sidecar、把 input 从"整个请求上下文 + 用户权限表快照"砍成四个决策必需字段之后，同一套 Rego 策略、同一份数据，P99 掉回二十毫秒出头。策略没变，变的只是它被调用的方式。这件事值得单独拿出来讲，因为大部分关于"策略引擎性能"的讨论都集中在求值引擎上，而现实里决定接口延迟的往往不是引擎。

把"调用一次"当成免费的代价：慢在哪里，别急着怪引擎

把授权判断从业务代码里抽出来的决定本身没有问题。散落在几十个服务里的 if 判断没法审计、没法统一管理、改一次要发几十个版本，这些都是真实的成本。问题出在抽象方式：抽出去之后，一次本地函数调用变成了一次进程间通信，而进程间通信有固定成本，这个成本跟你的策略写得漂不漂亮基本没关系。

一个典型的误解是"策略引擎天生慢"。Rego 是一种声明式查询语言，求值过程本质上是在一张内存里的数据结构上做规则匹配与合一（unification），这个动作本身在亚毫秒量级就能完成——前提是策略规模合理、数据已经常驻内存、并且规则写得能被索引命中。公开渠道能查到的参考值大多落在"紧凑 input 且规则可索引时，单次决策在数百微秒到数毫秒"这个区间，实际数值仍需结合策略规模、input 大小与具体机房实测确认。这个量级对于一个本来就有数据库查询、有下游 RPC 的接口来说，其实不该成为瓶颈。

真正把 P99 顶上去的，是加在这段求值前前后后的东西。业务服务要把一个结构化的请求对象序列化成 JSON；要发起一次 HTTP 请求，走一遍连接池取连接、DNS（如果用的是域名）、TLS 握手（如果是长连接则复用但要维护）；数据包要经过内核、网卡、交换机；对端进程要先反序列化收到的 JSON 才能开始求值；算完之后结果再原路走一遍回来。这里面任何一环都不难理解，难的是它们全都会被算到"策略引擎的耗时"这个标签底下，于是你得到一个错误的诊断结论。

所以在动手优化之前，第一件事是分清楚"策略引擎慢"和"调用策略引擎慢"是两件事。前者要靠改 Rego 写法、做部分求值、给数据加索引；后者要靠改部署形态、裁剪 input、加缓存。用错力的情况非常常见——明明是跨机房往返占了 8 毫秒，团队却花了两周去做策略的部分求值优化。

部署形态是最大的开销项：本机调用和跨机调用不是一个量级

策略引擎的部署形态基本决定了它延迟的下限。同一个 exe、同一套策略，跑在业务进程里、跑在同机 sidecar、跑在同机房另一台机器、跨机房调用，四种情况的延迟可以差一到两个数量级。

先看数量的直观感受。本机回环（loopback）上的一次 HTTP 往返，通常只占用百微秒量级；同机房跨机的一次往返，如果是经过良好维护的内网交换机、链路没跑满，一般在零点几到一两毫秒；跨机房、尤其是跨城专用链路或走公网，一个来回几毫秒到几十毫秒都很正常。这些是网络层面的公开参考值，具体到你的环境要自己 ping 和打流确认。把这些数字跟"数百微秒到数毫秒"的求值时间放在一起，你就会发现：跨机部署的场景里，网络往返还比求值本身贵。

除了网络本身的传播时延，还有几项常被忽略的固定成本。序列化是最明显的一项：业务侧要把请求上下文转成 JSON，引擎侧要解析它。如果 input 有 20 KB，仅仅 JSON 的编解码就可能吃掉跟求值同等甚至更多的时间。连接管理是第二项：短连接意味着每次都要建连和握手；长连接虽然省了握手，但需要维护连接池，池子配小了会排队，配大了连接数撑爆端口。第三项是进程调度与上下文切换：跨进程调用意味着至少两次用户态到内核态的切换，负载高的时候，CPU 争抢带来的抖动会通过尾延迟暴露出来。

还有一个隐蔽因素：跨机的那一跳引入了新的故障域和新的不确定性。独立部署的中心服务一旦 GC 停顿、一旦被限流、一旦网卡队列打满，你的延迟分布立刻长尾拉涨。P50 可能很好看，P99 已经完全不可用。这也是为什么很多团队在把策略拆成中心服务之后，看到的第一个异常不是平均延迟上升，而是尾延迟抖动。

最直接的结论：如果决策发生在每个请求的同步关键路径上，优先考虑让决策组件与业务同机——同进程内嵌库或者本机 sidecar。这不是说中心服务不该存在，而是它适合的场景是不同的（后面会讲）。先去掉跨机这一跳，再谈别的调优，通常是收益最大的一步。

input 文档：把整个请求上下文塞进去，等于给自己加倍征税

第二个大头是 input 的大小。Rego 策略通过 input 拿到"这一次要决策的事实"，很多团队出于省事的考虑，会把整个 HTTP 请求对象、整个用户会话、甚至一次数据库查询的结果集直接塞进 input。理由听起来很合理——"万一策略以后要看某个字段呢"。代价是每一次决策都要为这些大概率用不上的数据付序列化和遍历成本，而且这笔成本是每次调用都付，不是一次性付。

input 的成本沿着两条线传导。第一条是传输与编解码：对象越大，序列化时间越长、网络上传输的字节越多、对端解析越慢。这条线跟毗邻性相关不大，因为即使跑本机 sidecar，序列化那部分照付。第二条是求值：Rego 在做合一与遍历时，如果策略里出现了对 input 的通配遍历（比如 input.resources[_] 这种写法），遍历成本会随集合规模线性增长；如果 input 里有深层嵌套的结构而策略要反复下钻，还会有额外的引用解析开销。

正确的做法是反过来推：先列出每一条规则真正需要的字段，然后从字段出发构造 input，而不是从上下文对象出发裁剪。常见的最小集大概是用户标识、租户标识、操作动作（method）、资源路径或资源主键、请求来源 IP 或环境标签这几项，五项到十项就够绝大多数授权策略用。需要额外属性的时候，更稳的做法是让策略去查常驻内存的 data，而不是把这些属性从业务侧传进来——因为 data 是一次加载、多次复用，input 是每次都要重传。

一个可以立刻验证的判断方法：把 input 的大小做成分位数指标发出去，看 P99 有多大。如果 P99 超过几 KB，基本可以确认有裁剪空间；如果某些接口的 input 到了几十 KB 甚至上百 KB，那几乎一定是有无关字段被带进来了，很可能是一整个 ORM 对象或者一整棵权限树。

策略写法：规则遍历、缺索引、把查询写进策略

第三处开销来自策略本身怎么写。Rego 是声明式的，写起来很自由，但不同的写法在执行效率上差别非常大，而且这种差别在规则数量少的时候完全看不出来，等到规则上到几百条、数据集上到几十万条，才会集中爆发。

最常见的问题是全集合遍历配无索引规则。比如这样一条规则：allow { op := allowed_operations[_]; input.method == op.method; input.resource == op.resource }。它的语义很直观——遍历所有允许的操作，找匹配的。但每次决策都要线性扫一遍 allowed_operations，数据量翻倍耗时翻倍。OPA 内部有规则索引机制，能够把部分查询模式改写成一个可以快速查找的数据结构，但前提是规则的写法能被索引器识别——通常要求比较表达式中至少有一侧是常量或者说已知的值。上面那条规则里 input.method 是未知的，索引就用不上。

部分求值（partial evaluation）正是为了解决这一类问题。它的思路是：既然只允许 input 里那两三个字段是未知的，那就把所有不依赖这些字段的计算提前算掉，产出一个"剩余待求值的策略"。上面那条规则做部分求值之后，会变成一个几乎等价于手工展开的、按 method 分桶的形式，查询复杂度从线性扫描降到接近常数级查找。从外部看，你写的是简洁的那版，OPA 内部执行的是展开后的那版，两者语义等价。OPA 命令行里的 opa bench --partial、以及 REST API 里的 Compile API 都暴露了这个能力。另外一个可选项是预编译到 WASM target（opa build -t wasm），适用于需要在极端受限环境或者想把策略编译成模块直接嵌入服务的场合。

第二类问题是在策略里做本该由外部系统做的事。Rego 没有内置的外部调用手段，但实践里经常能看到团队把大量数据查询逻辑用 Rego 表达出来——从一个大型 data 文档里反复 join、过滤、聚合。这些逻辑放在策略里，意味着它要在每次决策时重新算一遍，而且没有查询优化器帮你重写。判断标准很简单：凡是跟"这一次请求的 subject / action / resource"无关的计算，都不该留在决策路径上，应该提前算成 data 或者放进预处理流程。

第三类问题是规则的线性膨胀。多租户场景尤其明显：每来一个新客户就加一段新规则，几年下来策略文件里堆了上千条彼此高度相似、只有租户 ID 不同的规则。这类规则不仅求值慢，连加载和编译都慢。对策是把租户差异下沉到 data —— 规则只保留一套通用逻辑，租户级的配置放 data.json 由 CI 生成。规则数量保持稳定，数据量增长是可以控制的。

还有个容易忽略的细节：数据结构的选择。同样是一组权限项，用对象（map）按 key 查找和用数组线性查找，在数据量大时差距是指数级的。公开的工程经验普遍建议，能被按主键查询的集合一律用对象结构组织，把遍历变成哈希查找。

策略数据的加载、常驻与热更新抖动

第四处开销来自 data。策略是无状态的、体积小，但它依赖的 data 文档可能很大——RBAC 角色映射、租户配置、资源清单、Kubernetes 集群状态。这些内容需要加载进内存并保持更新，管理不当会带来两类问题：内存占用失控和更新瞬间的延迟抖动。

OPA 推荐的策略与数据分发机制是 bundle。bundle 本质上是一个 gzip 过的 tar 包，其中包含策略文件、数据文件和清单文件（manifest），OPA 可以配置成定期从远端 HTTP 端点或对象存储轮询下载新版本。opa build -O 1 及以上优化级别会对 bundle 做内联、剪枝和重写，产出语义等价但结构更紧凑的包。加密签名与校验也是 bundle 机制的一部分，这在准入控制场景里是安全要求，不是可选项。

轮询更新带来的抖动需要单独说。OPA 拿到新 bundle 之后要重建内部的 AST 与索引结构，这个过程会消耗 CPU，并且在某些实现路径上会引起短暂的请求延迟尖峰。如果你的 bundle 很大、更新很频繁（比如几十秒一次），这些尖峰会周期性出现。常见的缓解手段有两种：一是降低更新频率、改用事件驱动触发而非无条件轮询；二是错开各实例的更新时间（给轮询间隔加随机抖动），避免所有 sidecar 同时换包。另外，opa bench 支持直接用 bundle 作为输入做基准测试，上线前先在本地跑一遍，比在生产上出问题再去猜要划算得多。

内存方面要有一个清醒的估算。data 文档在内存里的展开体积通常是磁盘 JSON 的数倍，因为要做成便于查询的结构。一份 200 MB 的 data.json 常驻之后占用可能接近 1 GB。如果每个业务 Pod 都跑一个 sidecar 且各自持有一份完整数据，机器内存会按 Pod 数量线性膨胀——这就是为什么"跑个 sidecar 很轻量"这个印象在 data 变大之后会迅速失效。要么精简 data，把大集合改成按需增量拉取；要么共享策略进程，让同机多个业务进程共用同一个本机守护进程。

顺便提一句 decision log。审计场景下它是刚需，但如果配置为同步上报、且上报的目标是远端 HTTP 服务，那它就成了决策路径上的又一段等待。绝大多数场景应该把它配成异步批量上报，落到文件或消息队列里再由采集器拉走，不要让一次授权决策去等一次日志写入。

决策缓存该不该加：能缓存什么、键怎么设计、什么时候坚决不能加

加一层决策缓存是最容易想到的一步，也是最容易加错的一步。它收益明显——一次命中可以省掉往返、序列化和求值全部开销——但风险同样明显：授权决策如果缓存错了，后果是越权访问。

先说能缓存什么。判断标准是看"决策结果在缓存有效期内是否可能变化"。如果一个 (subject, action, resource) 三元组的判定结果只取决于相对稳定的东西（静态 RBAC 角色表、不常变的安全标签），那它是可缓存的，TTL 可以设到几十秒到几分钟。如果判定依赖会随时变的因素（配额余量、当日额度、实时风控评分、时间窗口限制、订阅有效期），那就不能直接缓存最终结果。

缓存键的设计有两个容易踩的坑。一是漏字段：只拿 user_id + path 做键，忘了 method，于是同一个用户对同一资源的 GET 决策被用在了 DELETE 上。稳妥的做法是把参与决策的全部 input 字段规范化之后做哈希作为键，而不是手工挑几个字段拼字符串。二是无限基数：把带有时间戳、trace_id、随机 nonce 的字段放进 input，会让每条请求生成一个唯一键，命中率归零而内存还在涨。这正是前面强调 input 要裁剪的原因之一——策略输入里不该出现任何不影响输出的字段。

一致性风险要有兜底。权限变更（比如管理员刚撤掉某人权限）到缓存失效之间这段窗口，用户仍然持有旧决策。金融、后台管理这类场景通常要求变更即时生效，那就必须配事件驱动的主动失效：权限系统写库之后发一条失效消息，各节点消费后按租户或按用户前缀清理。只靠 TTL 是不够的。反过来，如果业务能容忍几十秒的权限生效延迟，纯 TTL 就够了，别把系统搞复杂。

还有一种更保守但更稳妥的做法：缓存 data 而不是缓存决策。把"这个用户属于哪些角色""这个资源属于哪个租户"这类中间查询结果缓存起来，最终的 allow/deny 判断仍然每次实时算。这样即使缓存有点陈旧，也不会直接导致越权——因为它只影响一次查找的输入，最终裁决仍走完整逻辑。

先量再改：五个必须采集的指标和怎么分段计时

在改任何东西之前先把度量建起来。策略引擎这类组件的特点是：你以为的瓶颈和你实际看到的瓶颈经常不是同一个，没有数据就只能靠猜。下面五个指标建议全部接入。

决策耗时分布

不要只看平均值。取 P50 / P90 / P99 / P99.9，并且要能从"策略引擎视角"和"调用方视角"两个位置分别取。OPA 自身暴露 Prometheus 格式的 metrics 端点，可以拿到引擎内部的求值耗时；调用方这一侧要自己埋点，记录从发起调用到拿到响应的完整时间。两个数的差值就是往返加序列化的时间，这个差值是判断"该改网络还是改策略"的第一手依据。

input 大小分布

和决策耗时同样重要的是 input 的字节数分布，同样要看 P99。如果 P99 远大于 P50，说明有少数接口在传大对象。把两类数据做交叉对比会发现一个常见现象：决策耗时的长尾请求，几乎总是 input 最大的那批。

RPC 往返在总耗时中的占比

这是分诊的关键。做法是把一次调用拆成三段计时：序列化+发起请求、等待响应、反序列化结果。中间那段基本就是网络加排队，前后两段是本机 CPU。如果"等待响应"占比超过六成，说明优化重心在部署形态；如果前后两段占比高，说明该裁剪 input 或者考虑编码方式的替换。

缓存命中率与失效次数

命中率如果长期低于 50%，先别急着加 TTL，回去查键设计是不是把不该有的字段放进去了。同时要记录主动失效的触发次数，如果某个租户的策略被频繁更新导致缓存不断抖动，需要考虑给热点租户单独一层策略版本标记。

策略更新频率与单次加载耗时

记录 bundle 下载次数、加载耗时、以及加载窗口内的请求延迟变化。这样当有人报告"每隔一段时间接口会卡一下"时，你能立刻确认是不是策略换包引起的。

本地验证工具有个很好用的：opa bench。它可以直接对指定的 bundle 和 input 反复求值给出基准结果，配合 --metrics 和 --benchmem 能看到内存分配情况。做个对照实验很方便——同一份策略，分别用大 input 和裁剪后的 input 跑一遍，差距是多少立刻有数。这套东西应该进 CI：策略变更在合并前先跑基准，超过阈值就告警。

四种部署形态的开销对照与适用规模

把前面那几项串起来，落到选择上就是四种形态：库内嵌、本机 sidecar、中心服务、网关插件。它们的差异不在"哪个更快"这种笼统的说法上，而在各自的开销结构和运维代价不同。

选型的现实顺序通常是这样：如果决策在同步关键路径上而且量大，从库内嵌或本机 daemon 起步；如果团队规模小、希望策略集中管理且能接受一次本机回环，用 sidecar；如果主要用途是异步校验、CI 卡点、批量审计，中心服务完全可以胜任而且运维最省事；如果流量统一从网关进，网关插件能省掉每个服务各自接一遍的重复劳动，但要接受它成为单点链路上新增的一环。很多成熟架构是混着来的——网关做粗粒度准入，服务内做细粒度授权。

服务器该怎么配：按"每秒决策次数 × 平均 input 大小"估，不是按核数

这个场景有个特点：它既不是典型的 CPU 密集，也不是典型的存储 IO 密集。策略求值在紧凑 input 和良好索引下走的是内存里的查找，CPU 占用不高；它也不写盘，IO 压力几乎为零。真正敏感的是两项——网络往返延迟，以及常驻内存的策略与数据量。按"几核几 G"的惯性思路去配容易配偏。

推荐按两个变量估算。第一个变量是每秒决策次数（DPS）。注意这不是接口 QPS：一个请求可能触发多次决策（网关一次准入 + 服务内一次细粒度授权 + 数据层一次行级过滤），统计数据要按实际决策调用次数算，不是按入口请求数算。第二个变量是平均 input 大小（以及 P99 大小）。把两者相乘，得到的是每秒需要传输的字节数——这个数字决定了内网带宽压力和序列化开销，通常比你想象的更早成为瓶颈。

内存怎么估。策略本体很小，通常是几十 KB 到几 MB 的 Rego；data 才是大头。估算方法是拿磁盘上的 data JSON 体积乘一个展开系数（公开工程经验的参考量级在三到五倍，实际要结合数据结构的嵌套深度实测确认），再加上引擎自身的常驻开销。如果这个实例要承载多租户的全量角色映射，几百 MB 到数 GB 都不奇怪。也就是说，配这类机器时内存的估算单位是"data 全集 × 展开系数 × 进程副本数 + 余量"，而不是"业务本身的堆加两倍"。

CPU 怎么估。这部分出人意料地低，但有两个时刻 CPU 会瞬时冲高：一是 bundle 加载与索引重建，二是大量并发决策同时到达。建议按决策平均耗时的倒数乘以并发度粗算，然后留出足够冗余应对加载峰值。多核的意义主要在于分摊并发请求与后台加载，不在于加速单次决策——单次求值的延迟不会因为核多而变短。

网络和布置位置比核数重要得多。既然前文已经论证部署形态才是主要矛盾，那选型时就应该把"决策组件能不能和业务放在同一内网甚至同一宿主机"当作硬性要求。一万网络这类深耕 IDC 19 年（成立于 2007 年）的服务商在部署这类控制面组件时，通常也是这个顺序：先把跨机往返干掉，再谈参数调优。一万网络在这一层的可选项比较清晰——一万云 ¥25 起适合先跑小规模验证，摸清 TTL 与命中率，裸金属 E5-2620 ¥999 起适合把决策守护进程与业务混布在同一批物理机上，E5-2698v4×2 ¥3999 起（海外买1送1）适合 data 全集较大、要求单机多副本共享内存策略数据的场景；以上均为官网明示价，具体以官网实时价为准。带宽这部分要单独确认内网带宽规格与是否有跨机流量计费，跨节点决策布局时建议优先选同一可用区内的低延迟内网。

五条容易踩的坑

坑一：为了"统一管理"把所有决策都收进中心服务

为什么坑：统一管理和部署形态是两件事。把策略收中心之后，每一个 GET 请求都要跨一次机器再回来，几百微秒的求值被夹在几毫秒的往返中间，性能账完全算不过来。怎么判断：看你的决策是否在同步请求的关键路径上，并且 QPS 是否进入了千级以上。怎么避：策略源集中管理、执行位置下沉——用 CI 把同一份 Rego bundle 分发到各节点的本机 daemon，既保留了单一数据源，又不付跨机成本。

坑二：把数据库查询结果直接塞进 input

为什么坑：input 每次都要序列化、传输、反序列化，成本随调用次数线性累积；而同样的内容做成 data 只需要加载一次。怎么判断：看 input 是否有超过几 KB 的接口，或者是否有结构冗长的完整业务对象、权限树、名单集合。怎么避：input 只保留决策必需的标量字段，其余全部下沉为 data 由策略查询；上线前用 opa bench 做大小两种 input 的对照测试。

坑三：给决策缓存加了无限基数或漏了关键字段

为什么坑：漏字段导致不同操作共用同一结果，等于给系统开了越权口子；含时间戳或 trace_id 则命中率归零但内存照涨。怎么判断：上线后看命中率，长期低于五成基本是键设计有问题；同时盯内存是不是持续上涨不回落。怎么避：键取参与决策全部 input 字段的规范化哈希，禁止人工挑字段拼接；同时给单例 decisions 加 TTL 上限，别指望纯 TTL 承担权限变更的即时性，权限变更要发主动失效事件。

坑四：只看 P50 不看尾延迟

为什么坑：跨进程调用的长尾来自 GC、连接池排队、网络重传、换包抖动，这些东西平均下来很小，但它们决定了用户体验与超时告警量。怎么判断：同时看 P50 与 P99，如果两者相差超过五倍，说明存在偶发的系统性抖动而非策略本身慢。怎么避：把 P99 作为主指标；给换包时间加随机抖动避免同步；为决策调用设置明确的超时与失败降级路径，而不是无限等待。

坑五：忽视了策略组件本身的可用性与灾备要求

为什么坑：授权一旦不可达，要么全拒要么全放，两者都是事故。很多团队把策略引擎当作普通中间件，只部署单实例、无健康检查、无降级预案。怎么判断：问自己一个问题——策略引擎挂掉的三十秒内，你的接口是放行还是拒绝？如果答不上来，说明预案缺失。怎么避：fail-closed 场景必须有多实例与快速故障恢复；允许降级的场景要明确只在哪些低风险接口上启用本地兜底策略，并留下完整审计记录。

策略引擎落地的七个常见疑问

策略引擎是不是天生就慢？有没有必要用？

不是。Rego 求值在 input 紧凑、规则可索引的条件下通常落在数百微秒到数毫秒这个公开参考区间，实际数值需结合你的策略规模和数据量实测确认。真正让团队产生"它慢"这个印象的，绝大多数是加在求值外面的东西：跨机往返、序列化和大 input。至于要不要用，看的是治理收益而不是性能——当授权规则散落在十几个服务里、每次安全策略调整都要发多个版本时，抽出来是划算的。抽出来之后把部署形态做对，性能通常不是问题。

应该部署成 sidecar 还是独立中心服务？

取决于决策是否在同步关键路径上。网关鉴权、API 内细粒度授权这类"每个请求都要问一次"的场景，优先本机 sidecar 或同机守护进程，因为省掉的是跨机往返这笔固定成本，收效最直接。CI 流水线内的策略卡点、离线审计、批量合规扫描这类异步场景，中心服务完全够用而且运维最省事，因为它天然统一、容易扩容、也便于收集统一的决策日志。折中方案也很常见：同一个 bundle 用同一套 CI 分发到各节点的本机实例。

input 里到底该放多少东西合适？

原则是"只放影响输出的字段"。典型的 API 授权场景，五项到十项足够：用户标识、租户标识、操作动作、资源路径或主键、来源环境。需要用户所属角色、资源所属分组这类属性时，把它们做成常驻 data 让策略去查，而不是由调用方传进来。判断标准是看某个字段变化时决策会不会变——不会变的字段一律不要出现在 input 里，它们只会拉低序列化性能并污染缓存键。

决策结果能缓存吗？什么情况下不能？

依赖静态数据的可以缓存，比如基于固定 RBAC 角色表的判定，TTL 设几十秒到几分钟是可接受的。依赖实时状态的不行——配额余量、当日额度、实时风控评分、时间窗口限制、订阅有效期，这些每毫秒都可能变，缓存结果等于允许过期授权。拿不准的时候有个更安全的中方案：缓存中间数据（如用户的角色集合、资源的租户归属），最终结果仍每次实时算。这样即使缓存稍旧，也不会直接产生越权。

策略数据（data）很大怎么办？热更新会不会引起抖动？

data 大有两个后果。一是内存膨胀：data 载入后要做成易查询的结构，内存占用通常是磁盘 JSON 体积的数倍，sidecar 模式下每个 Pod 一份，会按副本数线性放大。对策是精简 data、把大集合改成按需加载、或者让同机多个进程共用一个守护进程。二是抖动：换包需要重建 AST 与索引，会消耗 CPU 并引起短暂延迟尖峰。对策是降低更新频率、改事件驱动、给轮询间隔加随机抖动让各实例错开。

规则越写越多，性能会不会线性恶化？

会不会取决于规则怎么写。如果是一套稳定的写法：不再随着租户或资源增加而新增规则，而是把差异下沉到 data，性能就不会随业务规模线性恶化。如果每来一个客户加一段规则，规则数量增长的同时还会拖慢加载和编译。对策集中在几件事上：把 data 用对象（map）而非数组组织以保证哈希查找；用部分求值让引擎自动展开可预计算的部分；用 opa bench 在 CI 里做基准卡点。

怎么判断到底是策略慢还是网络慢？

做分段计时。调用方侧记录三段：序列化并发起请求（T1）、等待响应（T2）、反序列化结果（T3）；同时从引擎侧取它自己报告的求值耗时。拿 T2 减去引擎内部耗时，剩下的就是网络传播加排队的时间。这个差值通常可以直接定位瓶颈：差值是毫秒量级而求值是亚毫秒量级，瓶颈在网络；两者接近，才是解析或求值的问题。另外交叉对比 input 大小分布也能佐证——长尾请求往往就是 input 最大的那些。

服务器该怎么配？给个不说"几核"的思路。

用两个变量估：每秒决策次数（注意是决策次数不是接口 QPS）乘以平均及 P99 的 input 大小，得到每秒要搬运的字节数，它决定内网带宽与编解码压力；再用 data 全集乘以三到五倍的展开系数加上引擎常驻开销，得到内存需求，多进程部署时还要乘以实例数。CPU 反而不是关键项，只在 bundle 加载和并发峰值两个时刻才需要预留冗余。比配置更重要的是位置：让决策组件与业务处于同一内网甚至同一宿主机带来的收益，通常远大于升级核数。预算层面可以多比几家做对照，比如同时具备华南、华东、华北与中国香港多节点、BGP 多线 + CN2 GIA 回国、7×24 中文工单平均 5 分钟响应、并提供免费系统盘快照（每日 3 份 / 30 秒回滚）的服务商；具体机型报价在不同节点间差异较大，非明示机型一律需实时询价、以官网实时报价为准。

落到部署形态上，像一万网络这类服务商通常建议把策略决策组件与业务放在同一内网甚至同一宿主机，先消除跨机往返再谈调优；其在华南、华东、华北、中国香港与海外多节点的布局，也让"控制面就近部署"具备落地条件。硬件故障 10 分钟自动迁移与 7×24 中文工单（平均 5 分钟响应）是这类组件上线后常用的兜底项。

策略引擎的开销要先算在调用链上，不是算在 CPU 上（OPA 篇）

回到开头那个 P99 上涨的案例。问题的解法不是换掉策略引擎，而是重新审视它被摆在什么位置、每次被调用时要搬运多少东西。如果只记一条结论，那就是：策略引擎的开销大头在调用它的方式上，不在引擎本身。优先级应该是这样的——先把部署形态改成同机（内嵌库或本机 sidecar），这一步能去掉最大头的网络往返；再把 input 裁剪到决策必需的字段，这一步能削掉序列化的大头；然后用部分求值、对象化数据结构、把恒定计算下沉到 data 三件事把求值本身压下去；最后才是加决策缓存，而且要先想清楚键设计和失效路径。别倒着做。

什么时候可以不优化？决策不落在同步请求路径上——批量扫描、离线合规检查、CI 卡点——这些场景中心服务加默认配置往往就够了，把精力留给策略正确性。什么时候必须认真做？网关统一鉴权、K8s 准入控制、多租户 SaaS 的逐请求细粒度授权，这三类场景的决策每个请求至少发生一次，延迟预算通常只有几毫秒，部署形态和 input 裁剪做没做对，直接决定这个架构能不能落地。换句话说，这不是"要不要上策略引擎"的问题，是"上了之后把它放在哪、喂给它什么"的问题。把这个顺序搞对了，你会发现大部分关于策略引擎性能的抱怨其实不成立。

本文参考的公开资料与适用边界（OPA 篇）

Open Policy Agent 官方文档 · REST API 参考：Policy API / Data API / Query API / Compile API 的端点定义，Compile API 用于访问 Rego 的 Partial Evaluation 与数据过滤能力，这是本文讨论部分求值时的依据。

Open Policy Agent 官方文档 · CLI 参考：opa bench（支持 -b bundle、-i input、--partial、--metrics、--benchmem、-t target 等参数）、opa build（-O 优化级别、-e 入口、-t rego/wasm 目标、签名校验），以及 bundle 的构建与远程分发方式。

Open Policy Agent 官方博客 · v0.7 Release：关于 partial evaluation 与 rule indexing 的原始说明，包括"结构与索引"如何把线性扫描改写为可索引查找，以及为什么它要求规则写法能被索引器识别。

行业公开技术分析资料 · OPA 性能工程实践：决策日志的用途与去向、sidecar 与远端 daemon 的延迟差异、bundle 热更新 OPA 实例无状态可水平扩容、以及"大 JSON input 拖慢求值"这一类经验判断。

适用边界说明：文中涉及的耗时区间、内存展开系数、网络往返量级均为公开渠道参考值，实际需结合策略规模、input 大小、data 数据量与具体机房网络环境实测确认，不建议直接作为容量规划的唯一依据。机型与节点相关表述仅作部署位置与预算比选的行业参考，不构成对某一地区机房资源或服务能力的承诺。所有价格类信息以官网实时报价为准，具体以签约时最新报价与合同为准。