解读

1. 场景本质：生产环境引入同态加密后，单次请求链路 RT 从毫秒级跃升至秒级甚至十秒级，需判断“变慢 1000 倍”是否仍落在业务方可接受的 SLA 区间。
2. 评估难点：
   • SLA 不是单指标，而是“多维度 + 多租户 + 多时段”的综合承诺；
   • 同态加密带来的延迟呈“右偏”分布，极端长尾可能拖垮 P99/P999；
   • 国内监管对金融、医疗、政务场景有“可用性≥99.9%”“单笔≤X 秒”硬性备案要求，必须给出量化证据。
3. 面试考点：能否把“1000 倍”翻译成可测量的性能模型，并用最小成本给出“过/不过”结论，同时保留优化空间。

知识点

1. SLA 三维量化：吞吐量 QPS、响应时间 RT（P50/P99/P999）、可用性（成功率和时长）。
2. 同态加密性能特征：
   • 计算瓶颈在密文域多项式运算，CPU 单核打满，几乎无线程伸缩；
   • 输入数据长度与密文膨胀系数线性相关，导致网络 IO 同步放大；
   • 内存占用随乘法深度指数增长，触发 GC 或 OOM 风险。
3. 国内主流评估标准：
   • 金融移动渠道：单笔≤3 s、P99≤5 s、日可用性≥99.9%；
   • 政务中台：高频接口 P95≤1 s、P999≤3 s；
   • 电商秒杀：核心下单 P99≤500 ms，可降级链路放宽至 2 s。
4. 性能测试方法：
   • 基准—负载—压力—稳定性四段模型；
   • 用“带宽模型”换算并发：QPS = 并发/RT，RT 放大 1000 倍则同等并发下 QPS 下降 1000 倍；
   • 用“排队论”估算 M/M/1 等待时间，防止 CPU 单核瓶颈导致队列爆炸。
5. 统计判定：
   • 若新 RT 分布 99% 置信区间上限 < SLA 阈值，则直接通过；
   • 若置信区间与阈值重叠，用双假设检验（H0：μ≤SLA，α=0.05）决定样本量，继续加压到 1.5 倍峰值容量仍不劣化方可验收。
6. 风险缓释：
   • 预计算/缓存密文、GPU 加速、NTRU 方案降级、分段流水；
   • 同步转异步，返回“处理中”状态码，通过轮询或回调满足“用户感知 RT”< SLA。

答案

步骤 1：明确 SLA 数值
与产品、运维、监管三方确认写入合同的阈值，例如“核心接口 P99≤5 s、成功率≥99.9%、峰值 500 QPS”。若合同未更新，需发起 SLA 变更评审，避免“技术背锅”。

步骤 2：建立“加密前后”基准模型
在同一套灰度容器（CPU 型号、JDK 版本、宿主机负载均锁死）上，先用 20 并发压测老版本，采集 P50/P99/P999、CPU、内存、GC、网卡吞吐作为基线；再部署含同态加密分支，重复实验，确保唯一变量是加密逻辑。

步骤 3：换算容量损失
假设基线 RT=50 ms，目标峰值 500 QPS，所需并发度=500×0.05=25；加密后 RT≈50 s，同等并发下 QPS=25/50=0.5，下降 1000 倍。若业务可接受最大 RT=5 s，则并发度需降到 5/50=0.1，即单线程 0.1 并发，理论峰值 QPS=0.1/50=0.002，远小于 500，结论：直接同步调用无法满足。

步骤 4：设计“ SLA 验证负载”
以“阈值上限”而非“峰值”作为目标：若合同 P99≤5 s，则用 5 s 作为期望 RT，按 Little 定律计算系统可承载最大并发 N=λ×T，其中 λ 为可接受到达率。取 λ=20 QPS，则 N=20×5=100 并发。用 JMeter/ Gatling 100 并发阶梯加压，持续 30 min，观察实际 P99 是否突破 5 s；同时监控单核 CPU 利用率，若≥95% 即认为遇到硬瓶颈。

步骤 5：统计判定
采集 ≥3000 条成功样本，计算 P99 单侧 99% 置信上限：
U = P99 + z_0.99 × σ/√n ，若 U<5 s 则通过；否则继续扩容或优化。
若样本分布极度右偏，采用 Bootstrap 百分位法重采样 10 000 次取 99% 分位上限。

步骤 6：稳定性与可用性验证
连续 8 h 注入 1.2 倍阈值并发，统计“超 SLA 时长”占比，可用性=（总时长-超 SLA 时长）/总时长，要求≥99.9%。同时观察内存泄漏、FGC 次数、密文膨胀导致的网络重传率。

步骤 7：输出结论
若以上指标全部落在合同区间，则给出“当前版本满足 SLA”报告，并注明“仅在单核 3.2 GHz、内存 32 GB、网络 10 Gbps 环境下成立”；若任一指标超标，列出瓶颈证据（CPU 单核打满、网卡 9 Gbps 打满、P99 置信区间下限已超 5 s），推动算法团队采用 GPU 批处理或异步化方案，并重新评审 SLA 是否可放宽。

拓展思考

1. 如果监管要求“单笔明文计算 RT 不得高于 500 ms”，而加密后只能到 5 s，能否用“用户感知 RT”替代“系统 RT”？
   答：在国内金融备案场景下，监管只看“请求发出到收到最终成功响应”的完整时长，异步轮询也算。因此可将同步接口拆成“提交+查询”，只要查询轮询间隔×次数≤ SLA 即可，但需在用户协议里明确提示“处理中”，否则视为体验欺诈。

2. 当 GPU 加速把 RT 从 50 s 降到 5 s，但成本增加 3 倍，如何向管理层量化 ROI？
   答：用“失败成本”模型：每超 SLA 1 次罚款 10 万元，峰值日 100 万笔，原失败率 2%，引入 GPU 后降到 0.2%，年节省罚款 0.018×100 万×10 万=1.8 亿元，远大于 GPU 年费 6000 万元，ROI=2，建议投资。

3. 若未来算法升级，RT 再降 10 倍，但引入 0.01% 的密文解密失败，该如何重新评估？
   答：把“成功率”纳入 SLA，建立错误预算：可用性=成功且及时返回/总请求，若解密失败计入“失败”，需保证可用性仍≥99.9%。通过故障注入测试验证 0.01% 失败是否会把整体可用性拉穿，若会则必须增加重试或冗余方案，否则不予上线。