微服务数据完整性违规的自动检测（OSDI 2026）
原题：Aletheia: Automated Detection of Data Integrity Violations in Microservices
一句话总结：微服务把原本由单库外键和事务保证的数据关系拆到异构存储中；Aletheia 用 SSA 数据流、跨服务抽象调用图和形式化操作模式检测潜在完整性违规，在 7 个开源应用中报告 50 个问题（其中 46 个此前未被报告），精度 81%、召回率 69%。
问题与动机
单体数据库可以用外键、主键和唯一性约束维护实体间关系。微服务拆分后，逻辑上仍属于同一实体的数据可能分散到不同服务和不同存储系统，数据库无法跨边界执行这些约束。开发者需要在应用代码中手动维护级联删除、跨服务写入和关联读取。
Aletheia 关注的是静态代码中“可能破坏完整性”的操作组合，而不是运行时修复。论文把问题归纳为三类约束：引用完整性、实体完整性和唯一性约束，并将它们转换为可搜索的读、写、删操作模式。
关键观察 / 隐含假设
- 观察 1：数据关系会通过跨服务的数据流隐式形成。 一个值从某个数据库读出或写入后，又被写入另一张表，通常意味着跨服务外键关系；图 1、§3.2 给出了这一建模依据。
- 依赖假设：关联值能在代码中被静态追踪，且查询字段和对象字段是可识别的。
- 可能失效场景：动态构造查询、用户输入跨越多个 RPC 请求建立的关系，会使关联不出现在同一条静态数据流中。
- 观察 2：异步复制和独立事务会暴露中间状态。 即使一次请求最终写入了所有分片，读请求也可能先看到引用、后看到被引用对象；并发删除与写入也可能产生悬空引用（图 2、§3）。
- 依赖假设：系统允许跨存储的非原子可见性或弱一致性。
- 可能失效场景：所有相关写入由强协调事务、同步事件或业务补偿严格串联时，静态告警可能只是保守提示。
- 假设 1：Blueprint 暴露了统一的服务调用和存储访问接口。 证据强度：强。实现 (§4.5) 依赖 Blueprint 定位 RPC 与数据库操作；对普通 Spring Boot 或 ASP.NET Core 代码的支持仍未实现。
核心方法
Aletheia 先以关系模型和关系代数定义五种操作模式：三种引用完整性违规（RI-1 级联删除缺失、RI-2 并发删除与写入、RI-3 非协调复制）、一种实体完整性违规（EI-1），以及一种唯一性违规（Un-1）。这一步把“可能不一致”变成可枚举的代码证据。
对每个服务，系统将 Go 代码转换为 SSA 中间表示，并对流入数据库操作、RPC 参数和返回值的变量做污染（taint）标注。随后它不跨所有服务直接拼接 SSA 图，而是构造抽象调用图：节点表示服务端点或存储，边表示调用或存储操作，抽象对象携带必要的数据流标注。这样回应了 §4.2 所说的规模问题。
系统遍历抽象调用图传播污染信息。当同一值带有来自不同存储操作的标注时，Aletheia 推断潜在外键，再依据读写顺序判断引用方向。最后，检测器在图上搜索 §3 定义的五类模式，并定位触发告警的代码位置。
设计取舍
- 取舍 1：采用保守的污染传播。 将表达式结果继承所有输入污染，能减少漏报，但会推断出不存在的外键，造成误报。
- 取舍 2：使用抽象调用图而非全局 SSA。 保留跨服务检测所需的信息，降低分析成本；代价是动态查询、复杂反射和跨请求语义无法恢复。
- 边界条件：当业务明确允许保留孤儿数据、延迟级联删除或使用补偿流程时，RI 告警不一定是缺陷。论文允许开发者抑制这类告警，但没有自动证明业务语义安全的方法。
实验与结果
- 在 7 个开源应用上，Aletheia 找到 50 个真阳性、12 个假阳性和 22 个假阴性，精度 81%、召回率 69%（表 2、§5.2）；46 个真阳性此前未被报告。
- 应用覆盖电商、社交网络、媒体和订票，规模为 3–31 个微服务、2–21 个存储和 6–170 个 RPC 调用（表 2）。TrainTicket 共发现 29 个引用完整性问题。
- 真实应用分析均在 4 秒内完成。合成应用最多包含 500 个微服务、2,887 个调用图；最大实例耗时 801–1,152 秒（图 5、表 3）。总调用次数比调用深度或扇出更能预测成本。
- 假阴性主要来自跨请求隐式关联和过滤条件查询；TrainTicket 中前者造成 12 个假阴性，动态查询目前未在评测中造成实际漏报（§5.2、§6）。
论断—证据表
| 论断 | 证据 | 评测边界 | 置信度 |
|---|---|---|---|
| 跨服务完整性问题在真实代码中普遍存在 | 50 个真阳性，46 个此前未报告（表 2、§5.2） | 7 个 Blueprint/移植应用，人工搜索近似真值 | 强 |
| 抽象调用图能扩展到较大调用图 | 500 个微服务、2,887 个调用图，最大约 1,152 秒（表 3、图 5） | 合成代码，未包含真实服务逻辑和生产负载 | 中 |
| 静态分析能有效定位违规模式 | 精度 81%、召回率 69%，开发者确认多个应用中的问题（§5.2） | 动态查询和跨请求关联仍漏报 | 中 |
批判性分析
论证链条
从“跨存储数据关系无法由数据库约束维护”到“可由值流推断外键”，再到“搜索五种危险操作模式”，论证链条在论文定义的模型内是闭合的。关键跳步是：值被多个数据库操作共享并不总意味着业务外键。论文用保守告警接受了这一不确定性，因此精度不能等同于已确认缺陷率。
假设压力测试
若服务通过事件总线、后台任务或用户输入跨请求建立关系，Aletheia 可能看不到完整数据流。若删除采用延迟清理，RI-1 告警还需要结合业务保留策略判断。方法也默认数据库操作和对象字段可静态识别；反射、动态 SQL、序列化协议变化会削弱分析结果。
实验可信度
应用覆盖多种存储后端和业务领域，且报告了假阳性、假阴性来源。人工搜索模式得到的真值只是近似，召回率因此不是严格的全量召回率。合成应用能测试规模趋势，但不能证明真实生产代码在同样调用次数下具有相同污染传播成本。
系统性缺陷
实现依赖 Blueprint 的统一抽象，迁移到常见微服务框架需要额外适配。告警只说明存在可能违规，未给出运行时可观测性、修复优先级或自动补偿方案。论文也未评估分析接入持续集成后的增量更新成本，以及服务版本演化造成的误报稳定性。
局限与后续工作
- 局限 1：动态构造查询和跨 RPC 请求建立的隐式关联无法可靠推断，已造成部分假阴性（§5.2、§6）。
- 局限 2：延迟删除若由分析范围外的后台进程完成，系统只能依靠人工忽略相应告警。
- 后续工作 1：增加显式外键注解，并在跨请求边界传播关联值；以 TrainTicket 中已知的 12 个跨请求假阴性作为回归测试。
- 后续工作 2：在 Spring Boot、ASP.NET Core 等框架上实现调用和存储适配器，并测量增量分析在 CI 中的时间与告警稳定性。