调用链路概述：请求生命周期、关键节点、监控维度
咱们做 DLP 策略嵌入，说白了就是要在数据流动的路上设卡。
那路是什么样的？卡又设在哪？这就是调用链路要回答的问题。我刚开始接触 SDK 嵌入时，总想着把策略一股脑塞进去，结果处处碰壁，后来才发现——不理解链路，策略就是瞎搞。
这一节，咱们把一条完整的请求从生到死走一遍。你想想看，一个用户发起请求，经过网关、微服务、数据库，再到响应返回，这中间 SDK 到底该在哪发力？
请求生命周期
一条请求的生命周期，我习惯分成这么几段：
- 接入：客户端发起请求，经过负载均衡、API 网关。
- 认证与鉴权：确认你是谁，你能干什么。
- 路由与分发：把请求发到对应的后端服务。
- 业务处理：服务内部逻辑，比如查询、计算、组装。
- 数据访问：读写数据库或调用外部服务。
- 响应返回：结果打包，一路送回客户端。
嗯，这里要注意——每个阶段都有可能泄露数据。比如认证阶段，日志可能打出了密码明文；业务处理阶段，返回值里可能混进了不该暴露的敏感字段。
我的核心观点：DLP 不是后知后觉的查漏，而是在每个关键节点主动“过滤”。SDK 要做的事，就是嵌入到各个阶段，在数据还没跑远之前把它拦住。
关键节点
那具体的拦截点在哪？我列几个常见的：
| 关键节点 | 所在阶段 | DLP 拦截点 |
|---|---|---|
| API 网关 | 接入 / 响应返回 | 请求参数、响应体脱敏 |
| 服务间 RPC | 路由与分发 | 序列化前后拦截数据 |
| ORM 层 | 数据访问 | 查询结果集脱敏 |
| 缓存层 | 数据访问 | 缓存写入 / 读出时扫描 |
| 消息队列 | 异步处理 | 消息体策略匹配 |
| 日志输出 | 全周期 | 日志刷盘前清洗 |
每个节点的 SDK 嵌入方式都不一样。举个例子，API 网关层适合做通用协议拦截，而 ORM 层则要深入到 SQL 执行的底层。我在某个项目中就吃过亏——只在网关做了脱敏，结果 RPC 调用里照样泄露了内部员工手机号。后来才补上微服务间的 SDK 拦截。
小建议：刚开始不用贪多。选 2-3 个最高风险节点先布防，比如 API 输入 + 数据库输出。跑稳了再铺开。
监控维度
策略都嵌进去了，怎么知道它用没用？有没有误杀？这就离不开监控。我个人习惯从三个维度来盯着：
- 性能维度：每条请求因为 DLP 检查多了多少毫秒？误报多、性能才扛得住？我见过一个团队把每字段都过正则，结果接口响应从 20ms 飙到 500ms，用户都跑了。
- 策略命中率：哪些规则频繁命中？哪些规则形同虚设？命中率突然飙升，可能是业务变了，也可能是规则写得太宽。
- 违规分布：数据泄露大多集中在哪个接口？哪个用户？哪个节点？有了这些，才能针对性优化策略。
| 监控维度 | 关键指标 | 工具推荐 |
|---|---|---|
| 性能 | P99 延时增量、吞吐下降比 | Prometheus + Grafana |
| 策略命中 | 命中次数、命中率变化曲线 | ES + Kibana 日志聚合 |
| 违规分布 | 按节点 / 用户 / 接口聚合 | 自定义告警规则 |
避坑提醒：我曾经监控维度只看了命中率，结果发现某条规则命中率很低，就把它关掉了。关了之后才发现，那条规则恰好是防止内部 API 泄露高敏感数据的最后一道防线。后来我学乖了——监控的同时一定要看未命中但本应命中的流量，做个“漏报抽样”。
上图就是我眼中的完整调用链路。你看，DLP SDK 并不是只挂在一个地方，而是以“化身”的形式出现在网关、业务服务、数据访问层，甚至在最后输出日志时也要刷一遍。
最后再说一句：理解了链路，你就能回答“策略该放哪”和“为什么有的地方放了没用”这两个核心问题。别小看这张图，后面每一章，都是围绕它展开的。