18

在微服务架构下分散数据的删除

 5 years ago
source link: http://dockone.io/article/10493
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

By Megan Kanne, 4 May 2020

微服务体系结构倾向于在整个组织中构建独立的数据责任,但却带来了彻底删除数据的挑战。一个常见的方案是为每个数据集或记录设置组织级的统一标准。然而不可避免的是,总会有跨越多个数据集和记录的数据。这些数据通常分布在整个微服务架构中,需要在多个团队之间协调才能删除。

另一种解决方案是将数据删除视为一个过程,而不是单一的事件。在Twitter平台上,我们称这个过程为“擦除”,并使用“擦除管道”来协调微服务之间的数据删除。本文将讨论如何建立一个擦除管道,包括数据可发现性、访问和处理等。并讨论一些常见问题,以及如何做好对擦除管道的持续维护等。

可发现性

首先,删除数据必须能定位到数据,与事件、用户、记录相关的数据通常都是在线或离线数据集,归属于组织内独立的团队。所以首要任务是利用组织的知识,行业知识,以及组织内的沟通渠道来汇编出数据的完整列表。

数据访问和处理方法

通常都是采用如下3种方式之一去访问可以找到的数据。(1)通过实时API或(2)同步机制去访问时刻更新的在线数据。采用如MapReduce之类的(3)并发分布式计算框架获取离线数仓中更新的数据。为了访问到每一份数据,你所构建的擦除管道需要能够支持全部的访问处理机制。

提供实时API获取更新数据的方式是最简单的,擦除管道也可以调用API来执行数据删除任务。一旦API调用成功,数据就被实时删除,擦除管道也就执行完毕。

但这一方法的缺点是:它假设每个数据擦除任务都可以在一个API调用周期的时间内完成,通常是几毫秒、几秒,或者再稍长一点的时间。但如果数据擦除不能在一个周期内完成,擦除管道将变得复杂一些。不能在一个API调用周期内完成删除的数据包括导出到离线快照的数据,或存在于多个后端和缓存中的数据等。这种非规范化的数据是微服务架构为提高性能,所固有的数据形态。这也意味着数据生命周期管理的责任被委托给了拥有数据API和业务逻辑的团队。

如果需要通知数据所有者去进行数据删除。擦除管道支持将擦除事件发布到分布式队列(如Kafka),订阅该队列主题的合作团队就可启动数据删除,执行擦除事件,并反馈数据被删除的结果确认。

最后,需要删除的可能包含目标数据的完整离线数据集,如快照或模型训练数据。在这些情况下,您可以提供一个离线目标数据集,合作团队从其自有的数据集中删除可擦除部分的目标数据。简单程度类似于擦除事件队列的持久化日志。

擦除管道

我们所描述的擦除管道需具备多项关键特征,包括:

  • 能接收推入管道的擦除请求
  • 能对删除的数据块提供追踪和存档
  • 支持调用同步API删除数据
  • 支持对异步数据擦除,提供擦除事件的发布
  • 支持为擦除事件,生成离线数据集。

一个擦除管道案例如下图所示:

vu6J3yy.png!web

浅绿色组件为用户所构建,深绿色组件为其他的开发团队构建。

设计采用这种架构是非常不错的开端,不过仍有几个问题需深入讨论一下:

常规问题

第一个问题是服务中断和网络分区。擦除管道需具备应对中断的弹性。它的目标是成功擦除,它需要能够在服务恢复后重试未完成的事件,做到这点的一个简单方法是保证所有擦除任务都是可重放的。当出现故障时,我们只需重放失败的擦除事件。其中,擦除跟踪系统可定位到尚未被完全处理的擦除任务,并重放这些事件。

有时候,不管你重复多少次擦除事件,管道都不能完成擦除任务,我们称为“broken”事件。原因可能是数据是无需擦除的,例如无效数据。当某个数据拥有团队无法完成擦除任务时,可能是擦除管道的完整性就超出执行者的可控范围。解决方式是需要把擦除任务分配给正确的团队。

维护

委派数据擦除任务可以通过让每个数据拥有团队随时执行删除任务来实现。管道的维护也类似,采用统一的SLA标准,将相互独立的任务整合成一条管道。只有每个团队都负责各自的擦除部分的基础上,管道才可能扩展。

在Twitter平台,我们希望每个拥有删除任务的团队都配置个体事件成功完成的告警。对于历时几天或几周SLA的擦除事件,我们还提供了总体成功的告警。这使我们能够及时地捕获擦除管道的问题,同时将发生的单个擦除任务的问题交给所负责的团队。

测试

测试上述的分布式管道遵循同样的原则:每个数据拥有团队负责测试自己的擦除任务。作为擦除管道的所有者,需要做的就是生成各团队可以执行的测试事件。

主要的挑战是在合作伙伴团队拥有的系统中协同创建测试数据。为了集成测试各部分的擦除任务,这些合作伙伴需要在您发起擦除事件之前准备好测试数据。对应的一种解决方案是采用测试框架,它将测试数据生成与定时作业配对,定时作业在创建测试数据之后再发起擦除事件。

未来展望

为在线微服务和离线仓库中的数据抽象出如数据访问层或数据目录之类的对象,可以显著降低擦除管道的复杂性。Twitter正朝着这个方向前进,尽可能地简化如数据删除等复杂处理任务的架构。数据访问层或数据目录为数据擦除请求和启动数据处理建立索引。这无形中统一了数据删除与数据所有权责任。

感谢阅读,希望这篇文章能让读者了解到微服务体系结构在数据遵从性方面可能带来的挑战。并帮助用户在开始自己的设计时带来新的火花。

原文链接:

https://blog.twitter.com/engin ... .html (翻译:易理林)


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK