解读

1. 蜜罐接口本质：在灰度或压测环境里，开发/安全团队为诱捕爬虫或横向攻击，会把部分流量引到“假接口”，这些接口永远返回 200 且 body 极小，不连库、不走缓存，RT 极低。
2. 失真表现：同一链路的压测样本里突然出现“异常快”的请求，拉低 99 线、抬高 TPS，掩盖真实容量，导致 SLA 误判。
3. 面试考点：能否用“测试数据可观测性”思路，把“假流量”从“真实流量”中剥离，并给出工程化、可落地的治理方案，而不是仅喊“加断言”。

知识点

A. 数据可观测三板斧：日志埋点、链路染色、指标比对。
B. 黄金指标四维：RT、TPS、错误率、带宽；蜜罐只影响 RT 与 TPS，错误率与带宽几乎不变。
C. 统计拆分：同一线程组内按“响应体特征”二次聚合，可快速发现 body 长度、字段缺失、固定码值三类异常。
D. 国内主流工具实现：

• JMeter：Beanshell/JSR223 PostProcessor 把“响应体长度+关键字段”写入 sampleVariables，再用 AggregateReport 二次过滤。
• Locust：在 on_request_success 钩子内判断 response.content == b'{"code":0,"data":{}}'，若命中则标记 fake=1，最后通过 Grafana 的 locust_exporter 标签剔除。
• 阿里云 PTS／腾讯云压测：利用“响应断言采样日志”下载到 S3，再写 PyODPS 脚本做离线清洗。
  E. 持续治理：把“蜜罐识别规则”固化到 CICD，压测脚本拉取 nacos 配置的“黑名单 URI 正则”，每次发版前自动更新，防止开发新增蜜罐接口导致再次失真。

答案

识别阶段

1. 预跑小并发“基线采样”：线程 10、持续 3 分钟，把响应体落本地 CSV。用 pandas 做聚类，body 长度出现双峰分布且短峰 RT 远低于长峰，即可初步判定短峰为蜜罐。
2. 正式压测时，在脚本里加“轻量级断言”：
   • 判断响应体是否包含业务唯一字段（如 userId、orderSn），缺失即打 tag=honey。
   • 判断 RT 是否小于 5 ms 且 body 长度小于 50 B，同时满足即标记。
3. 实时看板：把 tag=honey 的样本单独输出到 InfluxDB，Grafana 双曲线展示“总 TPS vs 真实 TPS”，差距超过 8 % 立即告警。

剔除阶段

1. 压测报告生成前，用 JMeter 的 FilterResultsTool 执行：
   java -jar CMDRunner.jar --tool FilterResults --inputFile result.jtl --outputFile real.jtl --exclude-label-regex "(?i).*honey.*"
   把标记样本物理删除，再重新计算 99 RT 与 TPS。
2. 若使用云压测，离线拉取原始日志，跑 SparkSQL：
   SELECT * FROM log WHERE tag != 'honey' CLUSTER BY traceId;
   把结果写回新的 OSS 目录，重新导入 PTS 报告中心，系统会自动刷新 SLA。
3. 把剔除规则固化：在性能门禁的 GitLab CI job 里加一步“honey-detection”，若蜜罐流量占比 >5 %，直接打回版本，倒逼开发关闭蜜罐或提供白名单。

拓展思考

1. 蜜罐与缓存命中“极速响应”如何区分？——可引入“逻辑一致性校验”：缓存命中的数据仍包含业务主键，可验签；蜜罐数据为静态伪造，验签必失败。
2. 全链路压测里，网关层做“流量打标”(X-PerfTest:1)，蜜罐系统若未配置放行，会直接返回 403，反而把真实错误率抬高，此时需让安全团队给压测流量加白，避免“反向失真”。
3. 未来走向：把识别逻辑下沉到 sidecar（Istio Envoy），用 WASM 插件实时判断 response body schema，一旦命中蜜罐特征，自动把 sample 标记为“shadow”，既不落盘也不参与聚合，实现“零人工”治理。