JWT 无状态鉴权在网关层验证，CPU 增加 15%，如何优化解析性能
解读
- 场景定位：国内互联网普遍把 JWT 校验放在统一网关（Spring Cloud Gateway、Kong、Nginx+Lua、自研 Go 网关），高并发下每次请求都要做 Base64 解码、验签、反序列化，CPU 上涨 15% 属于“可感知但非致命”区间，面试官想看候选人能否把 15% 拆成可量化、可落地的优化项。
- 关键矛盾：JWT 无状态 ≠ 零成本；网关是流量入口，1ms 延迟放大到千万级 QPS 就是核数、电费、SLA 罚款；CPU 热点通常出现在签名验证（RSA256 最耗）、JSON 解析、反射构造 Claims。
- 面试意图：
- 能否用数据说话：先压测找热点，再提优化，避免拍脑袋。
- 是否熟悉国内常用组件：Spring Cloud Gateway 的 Reactor 线程模型、Netty 零拷贝、Kong 的 go-插件、pprof 火焰图、阿里 Sentine 限流等。
- 是否兼顾安全与性能：缩短密钥长度、换算法、缓存公钥都不能牺牲合规（国密、等保、PCI-DSS）。
知识点
- JWT 三段结构：Header.Payload.Signature，验签 CPU 开销 ≈ 非对称算法次数 × 密钥长度。
- 非对称 vs 对称：RSA256 验证一次约 0.15ms/核（2k 密钥），HS256 仅 0.01ms，但 HS256 需要网关与业务共享密钥，国内金融场景需评估密钥泄露风险。
- 热点分析工具：
- Linux perf + 火焰图，快速定位是否卡在
RSA_verify、json.Unmarshal、base64_decode。 - Arthas 的
profiler命令可在生产机采样，无需重启 Java 网关。
- Linux perf + 火焰图，快速定位是否卡在
- 网关线程模型：
- Spring Cloud Gateway 默认使用 Netty 的 EventLoop，阻塞验签会把 CPU 飙高，需切换到 Reactor 的
publishOn(Schedulers.parallel())或自定义线程池。
- Spring Cloud Gateway 默认使用 Netty 的 EventLoop，阻塞验签会把 CPU 飙高，需切换到 Reactor 的
- 缓存策略：
- 公钥缓存：JWKS 接口带 Cache-Control，网关内存缓存 5min，减少重复下载。
- 解析结果缓存：JWT→Claims 的不可变成果可缓存 1~5s，Key 用 jti+exp，防止重放。
- 国密与合规：SM2 验签性能约为 RSA256 的 60%，但需硬件加速卡（鲲鹏、海光），成本核算要算进去。
- 压测基线：同一台 8C16G 容器，2000 并发，90ms 思考时间，CPU 空载 20%，引入 JWT 后 35%，目标压回 25% 以内。
答案
“我会分四步把 15% 的 CPU 吃满原因拆出来并压回去：
- 采样定位：用 perf 记录 30s，火焰图显示 62% 花在
RSA_verify，21% 在 Jackson 解析，剩下是 Base64。 - 算法降级+硬件加速：
- 把 RSA256 2048 位降级到 RSA256 1536 位，验签 CPU 降 18%，等保三级允许 1536，合规通过。
- 若预算充足，在网关层加国产密码卡做 SM2 验签，性能再提 35%，且满足信创验收。
- 缓存与异步：
- 公钥走 JWKS，本地 Caffeine 缓存 5min，命中率 98%，减少 40% 网络+解析开销。
- 对读多写少场景，把验签后的 Claims 按
jti+exp为 Key 缓存 3s，QPS 1 万时可省 30% CPU。 - 验签过程丢到 Netty 的 Worker 线程池，避免 EventLoop 阻塞；Spring Cloud Gateway 通过
spring.cloud.gateway.filter.request-rate-limiter.redis-rate-limiter.parallel=true开启并行调度。
- 代码层微优化：
- 用 Jackson Afterburner 模块，关闭
DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES，解析耗时从 0.09ms 降到 0.05ms。 - Base64 用 JDK17 的
java.util.Base64替代 Apache Commons，吞吐量提 8%。 - 关闭调试日志里的全文打印 JWT，减少 3% CPU 及 5% 网络。
做完以上，2000 并发压测 CPU 从 35% 降到 22%，符合“把 15% 涨幅压回 7%”的目标，同时保持 RSA 算法、无状态、等保合规。”
- 用 Jackson Afterburner 模块，关闭
拓展思考
- 若业务坚持 RSA256 且不能降密钥长度，可考虑“批量验签”：把 10ms 内的请求打包，用 GPU 或 FPGA 做并行验签，国内阿里云 c7g 已支持 eRDMA 直通加密卡，适合夜间对账等高吞吐场景。
- 网关多活场景下，Claims 缓存需考虑一致性与失效风暴，可引入 Redis 的
set token:jti exp NX做分布式互斥，防止瞬间穿透。 - 长期看，JWT 无状态与网关高并发本质是矛盾体，可评估“半状态”方案：首次验签后下发 8 位短令牌 + Redis 集群，网关只做哈希比对，CPU 可再降 50%，但需要运维额外维护 Redis，面试时可作为“终极方案”与面试官探讨成本边界。