第2章：DLP系统架构与接口分类
做DLP接口测试，第一步得先把系统的“骨架”摸清楚。说白了，你得知道数据从哪来、经过谁、送到哪去，中间又经过哪些接口。我刚开始接触DLP时，一上来就盯着RESTful接口写用例，结果被测服务老是超时——后来才发现gRPC调用的超时策略没配置对。嗯，今天就带你把这些接口类型一个一个掰开看。
2.1 整体架构概览
DLP系统的模块不多，但链路挺长。一般分为三层：
- 接入层：接收外部流量，比如邮件、HTTP请求、文件上传。
- 策略引擎层：核心判断逻辑，做内容检测、分类、动作决策。
- 数据存储层：存策略配置、审计日志、命中记录。
模块之间通信方式不同，我按经验把它们归为四类：RESTful、gRPC、消息队列、内部RPC。下面这张图应该能帮你看清它们的关系：
关键点：测试用例设计前，一定要先确认被测接口属于哪一类。不同的接口类型，校验重点和工具链完全不同。
2.2 RESTful接口
RESTful接口是最常见的了。DLP中一般用来暴露管理功能：创建策略、查询规则、获取审计报告。我个人习惯先测HTTP状态码和响应体结构的完整性。举个例子：
# 典型RESTful接口测试思路
POST /api/v1/policy
Content-Type: application/json
{
"name": "禁发敏感文件",
"action": "block",
"priority": 1
}
预期返回：
- 201 Created
- body 包含 policyId
这里有个坑——很多同学只测200成功场景，忽略了4XX和5XX在DLP中的语义。我曾经遇到过一个案例：RESTful接口在并发创建策略时返回500，但实际数据已写入了一半。你想想，后续的gRPC策略加载就可能读到脏数据。所以RESTful测试一定要包括：幂等校验、并发冲突、超时重试边界。
注意：DLP的RESTful接口往往作为“管理入口”，不直接参与数据面流。如果你发现必须通过RESTful接口造大量策略数据来触发数据面逻辑，建议考虑用内部RPC或者直接写入数据库来加速测试。
2.3 gRPC接口
gRPC在DLP中很常见。特别是数据面检测场景，比如流式内容分析。它基于Protobuf，强类型、高性能。我记得第一次做gRPC接口测试时，还想着像REST那样手动构造JSON——结果完全行不通。你必须先定义好proto文件，然后生成客户端存根。
测试gRPC接口，我总结三个重点：
- 服务健康检查：调用一个空参数方法，验证服务是否活着。
- 正常流交互：发送合法请求，校验响应字段，尤其注意enum值范围和时间戳格式。
- 压力与边界：并发请求数、消息体大小（比如1KB和4MB）、超时触发。
说实话，gRPC接口的深坑常在“deadline propagation”上。客户端和服务端的超时配置如果不一致，就会出现上游等下游的情况。我曾见过一个线上事故：一个gRPC调用链上三层服务，最内层设置了5秒超时，外层却设了2秒，结果一直报错“context deadline exceeded”。所以测试时要刻意构造超时链路。
小技巧：使用grpcurl或ghz这类工具做gRPC的冒烟测试，比写代码快得多。但正式的参数化用例还是用代码好，我推荐python的grpcio + pytest参数化。
2.4 消息队列接口
消息队列接口在DLP中主要做异步事件投递，比如：文件扫描完成后通知审计模块、策略变更后通知各节点。我个人最喜欢这种接口，因为它天然松耦合，测试起来容易隔离。但这也让“端到端验证”变难了——你必须确保消息正确入队、出队，并且消费方能处理。
测试消息队列接口，我通常分三步：
- 生产端：发送消息，验证消息格式、路由键、是否持久化。
- 队列端：检查队列深度、死信情况、延时消息。
- 消费端：模拟消费并断言结果，比如触发策略重载或写入数据库。
还有一点要注意：消息体序列化方式。有的团队用JSON，有的用Protobuf，甚至有的用编组后的二进制。你测试时一定要确认字段映射正确。我曾经踩过一个坑：生产端用Protobuf序列化，消费端解析时用了旧版本的proto文件，导致多了一个必填字段无法解析，消息一直进入死信队列。
建议：在测试环境搭建一个“消息积压模拟”的用例，比如往队列里连续塞10000条消息，然后观察消费者处理速率和是否有最终一致性问题。这在DLP的场景里很关键——漏处理一条策略变更，可能导致整个系统误判。
2.5 内部RPC接口
内部RPC接口通常是团队自研的、或者使用Thrift、Aeron这类框架。它们不对外暴露，但模块间调用频率极高。我记得在一次大版本重构中，我们把所有内部RPC接口从Java RMI迁移到了自定义二进制协议，结果性能提升了3倍。
测试内部RPC接口，最头疼的是“没有文档”。很多团队只维护了RESTful的OpenAPI，内部RPC全靠代码注释。怎么办？我的做法是：先抓包或反射拿到接口签名，然后写一个简单的mock服务，验证参数合法性。
| 特性 | RESTful | gRPC | 消息队列 | 内部RPC |
|---|---|---|---|---|
| 通信协议 | HTTP/1.1 | HTTP/2 | TCP / AMQP | 自定义TCP |
| 序列化 | JSON / XML | Protobuf | 二进制 / JSON | 自定义 |
| 同步/异步 | 同步 | 支持双向流 | 异步 | 同步 / 单向 |
| 测试工具 | curl, Postman | grpcurl, ghz | 客户端SDK | 代码 mock |
| DLP典型场景 | 策略管理 | 实时扫描 | 事件通知 | 策略加载 |
再次提醒：内部RPC接口往往没有超时保护机制。测试时一定要验证：如果模块B挂掉，模块A的响应是否会阻塞整个线程池。这属于稳定性测试，但很多团队都忽略了。
其实这四种接口在DLP中不是孤立存在的。一条数据流可能先通过RESTful配置策略，然后以gRPC的方式下发给引擎，引擎内部又通过内部RPC调用分词模块，最终通过消息队列通知审计。你写接口测试用例时，最好把这种“跨接口场景”也纳入进来。我个人习惯是先理清一张“接口依赖图”，再逐个击破。