安全审计要求「令牌 30s 内可吊销」：JWKS 离线验签 vs RFC 7662 在线 introspection，P99 预算 5ms 内怎么落地？

【背景】 我负责一套 12 个微服务（Go 1.21 + gRPC），跑在 3 节点自建 K8s 1.28，无云。API 网关层统一做 JWT 验签，签发端是独立 auth 服务（Spring Boot 3.2 + jjwt 0.11.5，RS256 非对称）。

当前方案：

• 网关侧拉取 JWKS（/oauth2/jwks），本地缓存公钥，TTL 1h
• 验签走本地公钥 + 签名校验，零网络调用，P99 约 1.8ms
• 客户端 token TTL 1h，refresh token 7d

安全审计新提的要求：令牌泄露后 30s 内必须可吊销（即吊销操作生效的端到端延迟 ≤ 30s），且吊销能力不能依赖"等 token 自然过期"。

【现象 / 卡点】 核心矛盾：

1. JWKS 离线验签无法吊销单个 token——公钥还在，token 签名合法，验签就通过；只能缩短 TTL（但 1h → 30s 后 refresh 风暴直接打爆 auth 服务）
2. RFC 7662 introspection 每请求一次网络调用——auth 服务 P99 约 22ms + 内网 RTT 1-2ms，网关 P99 从 1.8ms 飙到 40ms+，业务方不接受
3. 安全团队不接受 fail-open（引用 id=1437 的讨论，"auth 服务挂了不能放行"），但也不能接受 P99 翻 20 倍

【已尝试的排查与结果】

1. Token blacklist in Redis：网关验签后多一次 GET blacklist:{jti}，P99 增加约 1-2ms（本地 Redis 集群）。问题：Redis 挂了又回到 fail-open / fail-closed 的老问题，而且 blacklist 会随时间膨胀（1h TTL × 200 QPS ≈ 720k 条/h），需要额外的清理策略
2. 缩短 token TTL 到 30s + refresh：压测 200 并发下 refresh 请求 QPS 达到 600+，auth 服务 CPU 从 35% 飙到 92%，P99 从 22ms 飙到 110ms，不可接受
3. JWKS 缓存 TTL 缩到 30s：只解决密钥轮换窗口（新旧公钥并存期），不解决单 token 吊销，安全团队打回
4. 在 auth 服务侧加一个 GET /revoke/check?jti=xxx 轻量接口（只查内存 LRU，不查 DB）：比 introspection 快（P99 约 5ms），但仍然是每请求一次网络调用，且 auth 服务挂了就回到老问题

【期望得到的答案形态】

• 一个在 P99 ≤ 5ms 预算内、支持 30s 吊销的可落地方案（可以是组合方案），最好有生产验证
• 如果必须引入外部依赖（Redis / auth 服务 / 消息总线），请给出降级策略：依赖不可用时是 fail-closed 还是有限放行？放行窗口多长？怎么在故障演练中验证？
• 社区里有没有人在生产跑过「JWKS + 短 TTL blacklist」或「JWKS + 事件驱动吊销通知」的混合方案？踩过什么坑（blacklist 膨胀、缓存一致性、Redis 主从切换窗口）？
• 如果最终答案是"30s 吊销和 P99 ≤ 5ms 不可兼得"，请给出可量化的 tradeoff 数据（比如：Redis blacklist 方案在 1M token/h 规模下的 P99 实测值），让安全团队和产品能坐下来谈，而不是拍脑袋

【小结】 这道题的本质是：即时吊销（security）和零网络调用（performance）在单请求路径上天然冲突，我想知道社区里怎么在工程上把这两者的冲突"摊平"——是接受一个可控的 P99 增量，还是用异步/事件机制把吊销从请求路径上摘出去。