删除分布在整个微服务体系结构中的数据

微服务架构倾向于在整个组织内分配数据责任。这给确保删除数据带来了挑战。常见的解决方案是设置组织范围内的按数据集或按记录保留的标准。但是，总会有跨越多个数据集和记录的数据。这些数据通常分布在您的微服务体系结构中，需要系统和团队之间进行协调才能将其删除。

一种解决方案是，不要将数据删除视为一个事件，而应将其视为一个过程。在Twitter，我们将此过程称为“擦除”，并使用擦除管道协调系统之间的数据删除。在这篇文章中，我们将讨论如何设置擦除管道，包括数据可发现性、访问和处理。我们还将讨论常见问题以及如何确保擦除管道的持续维护。

首先，您需要找到需要删除的数据。有关给定事件、用户或记录的数据可以在联机或脱机数据集中，并且可能归组织的不同部分所有。因此，您的第一项工作将是利用您对组织的知识、同事的专业知识以及组织范围内的沟通渠道来编制所有相关数据的列表。

您通常可以通过以下三种方式之一访问找到的数据。在线数据将通过(1)实时API或(2)异步变异器改变。离线仓库中的数据将通过(3)像MapReduce这样的并行分布式处理框架实现可变。为了访问每一条数据，您的管道需要支持这三种处理方法中的每一种。

通过实时API可变的数据是最简单的。您的擦除管道可以调用该API来执行数据删除任务。一旦每段数据的API调用成功，数据就被删除，擦除管道就完成了。

这种方法的缺点是，它假设每个数据删除任务都可以在API调用的范围内完成，通常是几秒或几毫秒，而这可能需要更长的时间。在这种情况下，擦除管道必须变得更复杂一些。例如，在API调用期间不能删除的数据包括导出到脱机快照的数据，或者存在于多个后端系统和缓存中的数据。这种数据反规格化是微服务体系结构固有的，可以提高性能。它还意味着将数据生命周期的责任委托给拥有数据的API和业务逻辑的团队。

您需要通知数据所有者需要进行数据删除。您的擦除流水线可以将擦除事件发布到分布式队列(如Kafka)，合作伙伴团队订阅该队列以启动数据删除。他们处理擦除事件，并回电给您的团队以确认数据已删除。

最后，可能存在完全脱机的数据集，其中包含需要删除的数据，例如快照或模型训练数据。在这些情况下，您可以提供一个脱机数据集，合作团队可以使用该数据集从其数据集中删除可擦除的数据。此离线数据集可以像擦除事件发布者的持久化日志一样简单。

到目前为止，我们描述的擦除管道有几个关键要求。它必须：

像这样的架构是一个很好的开始，但是有几个我们还没有讨论的问题。

第一个问题是服务中断和网络分区。擦除管道需要对停机具有恢复能力。它的目标是成功擦除，这样当服务恢复时，它就可以重试它的任务。实现这一点的一种简单方法是确保所有擦除任务都是可重放的。当出现中断时，我们只需重放任何丢弃的擦除事件。擦除跟踪系统知道哪些擦除事件尚未完全处理，并且可以重新发布这些事件。

有时，无论您重放擦除事件多少次，管道都不会完成。对于那些活动来说，它是“坏的”。数据可能是不可擦除的，例如，因为它最初是无效的。当您拥有数据的团队之一无法完成擦除任务时，擦除管道的完整性已超出您的控制范围。需要将解决问题的责任委派给正确的团队。

这种授权可以通过让每个拥有数据的团队随时待命执行擦除任务来实现。像这样将不同的任务组合到一个具有一个SLA的管道中的管道的维护，只有在每个团队都对自己的擦除部分负责的情况下才能进行扩展。

在Twitter，我们希望拥有擦除任务的每个团队都会在任务成功时发出警报。作为补充，我们使用数天或数周的SLA来提醒擦除事件处理的总体成功。这使我们可以及时捕获擦除管道问题，同时将单个擦除任务的问题引导给负责的团队。

测试这样的分布式管道遵循我们已经讨论过的相同原则：每个拥有数据的团队负责测试他们的擦除任务。作为擦除管道所有者，您需要做的就是生成他们可以响应的测试事件。

挑战在于协调合作伙伴团队拥有的系统中的测试数据创建。为了集成测试他们自己的擦除任务，这些合作伙伴需要在您触发擦除事件之前存在测试数据。一种解决方案是测试框架，它将测试数据生成与cron作业配对，该作业在测试数据创建后一段时间发布擦除事件。

通过为在线微服务和离线仓库中的数据实现数据访问层或数据目录等抽象，可以大大降低擦除管道的复杂性。Twitter正朝着这个方向前进，以简化数据删除等复杂处理任务所需的架构。数据访问层或数据目录索引满足擦除请求并允许处理该数据所需的数据。这将数据删除结果与数据所有权责任统一起来。

谢谢你的阅读。我们希望这篇文章能让您了解微服务架构可能为数据遵从性带来的挑战。理想情况下，它还与您分享了一些解决方案，这些解决方案将在您开始自己的设计时激发新的想法。

这一内容是由汤姆·布里利、埃里克·弗罗泽、戈兰·佩雷廷和费利克斯·杨等人的工作使之成为可能的。感谢那些审阅这篇文章的人，包括玛西娅·霍夫曼和雷恩·胡佛。