介绍

数据的一致性 是一个大词，但它所表示的意思是我们可以说诸如“如果有人报告说他们的信用卡被盗，我们将立即在全球范围内冻结这张卡”之类的话。这里的“全球范围内”是指无论近在隔壁还是远在地球另一边，几乎无延迟。

在企业环境中，像这样的情况在多个服务之间保持一致非常困难。核心问题是缺乏一个统一的信用卡记录系统。我们拥有的是一系列并行运行的服务，各自努力在自己的“孤岛”中维护业务数据，从而导致了额外的复杂性。这种复杂性表现为开发人员和运维人员需要编写额外的代码并执行额外的操作流程。每次服务间的交互都会带来更多的负担，这些工作并不能为业务创造任何价值，并且要求开发人员重复造轮子，这需要耗费大量的精力。

不幸的是，这些解决方案永远都不是完美的。协调不良的数据也使我们的系统容易受到漏洞的攻击或干扰，这些攻击或干扰无法通过这些机制恢复，因为这种行为被视为正常操作。最近，国家支持的黑客越来越多地卷入攻击关键基础设施，因此这些威胁绝非空谈。

_仅有一组正确的数据，但存在多种类型的异常（引用自：异常的性质和类型：数据偏差回顾 )

这些差异也会表现为数据错乱，但这些错乱可能需要多年才能在事件发生后被发现。对数据问题的通常响应是执行临时的手动数据对齐任务来同步数据库。这些措施充其量只能解决表面症状，更不用说通常甚至无法判断哪个版本是正确的。这些异常的财务和公关后果也成为了额外的、不必要的、不可预见的业务成本。

这也有助于导致数据蔓延。数据的额外时间维度往往决定了数据的意义。拥有许多（略有不同）同一信息的不同副本，而不了解这些数据之间的关系，不仅是一种不必要的成本，还增加了组织流程不必要的复杂性。

遵守规矩!

数据同步不当是一个合规问题。数据准确性的需求在许多不同的法规中以隐含或明确的方式提出，但在《DORA》的规定中，一致恢复数据的具体要求被特别提到，特别是在《DORA》中明确提到的这一点。

第12条第7点的欧盟DORA条例规定

在这篇文章中，我们将看看数据问题是如何产生的，它们通常看起来是怎样的，我们现在对这些问题做了些什么，以及我们如何能够把这些顾虑彻底放下。

操作就是数据，数据就是基础设施

数据驱动我们的运营这一点显而易见。这种数据源自我们持续的运营，这一点对任何人都不意外。可能新的地方在于这种自我强化的依赖循环如何扰乱我们“一如既往”的业务。机器学习和商业智能还意味着数据问题会被放大，超出其原始比例。因此，数据质量的紧迫性从未如此突出过。

造成这些问题特别痛苦的原因是，真正擅长管理数据正确性的专家短缺。有一个原因，即云服务提供商靠“scaling and consistency”数据服务的高额利润为生。他们提供的服务是为了帮你解决将系统迁移到他们平台后出现的问题，并将这些系统整合到一个大型数据库中，例如Spanner、Azure SQL或DynamoDB。这种运营模式带来了多个新的问题。首先，企业中的每个服务都需要迁移到他们的专有API，这需要大量的投资并且会导致供应商锁定。其次，我们无法决定大多数服务使用哪些数据库，也没有办法迁移供应商提供的软件。

为了应对这些问题，内部数据平台 和 数据工程师 的角色在过去的几年中随之诞生。这些专家是该领域薪酬最高的专业人才之一，但是这也让他们陷入了困境。正是这种知识使他们成为这些职位的热门人选，却也意味着他们很容易成为企业运营中不可或缺的人物。

真实例子

让我们以冻结_信用卡_为例。我们经营的是世界上最简单的银行，我们只做三件事：发行和冻结信用卡给客户以及保持余额。为实现这些功能，我们通过某个在线API与卡提供方对接（我们称其为卡SaaS），并且我们有一个购买并定制的会计系统来管理这些功能。我们无需使设置更加复杂来展示问题，但这显然只是任何真正银行所需服务中极小的一部分。

我们有几种不同的选择来实现这项服务，但它们都有一个共同点：从共享数据的角度来看，它们都不够安全。由于这个系统在两个不同的服务之间共享“卡片当前的状态”，任何数据上的分歧都会成为一个问题。

“数据共享”争议

单向通信或系统的问题之一是一方接受某些变更而另一方拒绝这些变更。这通常通过所谓的“幂等性”来解决，但在这些情况下，存在一个时间窗口，在此期间两个系统不一致（其他进程或服务可能会看到无效值），这可能导致不良后果。

在我们的设置中，我们的会计系统选择最安全的方式请求冻结一张卡片：等待卡的SaaS服务完成并作出回应。不幸的是，会计系统执行的操作可能会被最终取消（数据库中常常出现意外的“回滚”）。在这种情况下，可能有一张卡无法使用，但该卡的客户账户仍然活跃（或者相反，在解冻时也可能会出现类似的情况）。

此外，由于我们不能否决同时运行的多个操作针对同一张卡进行操作，不同的服务之间可能会显示半完成的处理状态，这可能会导致其他问题。例如，如果黑客用大量“冻结”、“解冻”和“扣费”操作轰炸系统，最终结果是无法预测的，并且可能会导致非法提现。解决这个问题需要一个单一的共享事件顺序定义，以确保这些请求按顺序处理。这就是所谓的“强一致性”，这也是通常认为在这样的系统中不切实际的。

最近的值：争议

类似的一种攻击被称为时检查与使用之间的漏洞。这是一种特殊的竞态条件漏洞，它依赖于在某个服务中已经不正确或不再存在的信息。教科书上的例子是当扣款和查询余额这两个操作是在不同的计算机上执行时，因此，同时发起大量这种类型的请求可能会导致账户透支。这就是导致Flexcoin交易所破产的方式。

金融机构通常会在转账和查询余额的操作中引入特定的安全措施，但这种复杂性会随着数据类型和操作数量的增加而呈指数增长，因此对于其他操作则不再提供类似的保证。

基于 API 的设计，允许外部客户端直接访问其内部持有的数据，从而加剧了这些担忧。

调整数据就是说保持共同的状态。

如果我们的问题来源于服务之间关于某个记录状态的不一致，解决这些问题的方案必须通过某种方式来协调这些不一致。我们只能通过一些受信任的、共享的权威来实现这一点。由于所有我们的流程都需要咨询它（每次它们修改共享信息时），这必须成为我们系统中不可或缺的核心基础设施。换句话说，它不能成为我们系统中的单点故障（单一故障点），必须具备高度的可用性。

就像我们用来传递消息的那种基础设施一样。

去中心化、 自治和准确性

我们推动服务整合的核心是我们需要去中心化。这不仅是因为治理方面的原因，也有技术方面的原因。在现代技术栈中，整合是必不可少的。企业通常不会自己构建身份和访问管理或CRM系统，这背后是有原因的。“买而不是自建”意味着我们需要让我们的独立团队和服务安全地协同工作。

不幸的是，去中心化与正确性相冲突。我们集成的服务越多，我们的某些流程出现错误信息的可能性就越大，而且大多数这些问题将完全无法被我们的监控工具检测到。即使每个服务单独看都表现正常，数据对账问题最终还是会浮现。此外，出于显而易见的原因，公司通常也不愿意公开讨论这些问题。

从传统的企业服务总线（ESB）到现代的数据平台，

文中提到的这些担忧并不新鲜。当软件集成在九十年代中期真正开始时，解决方案是企业服务总线（ESB），简称ESB。ESB结合了数据平台和基于工作流的编排工具，并试图通过名为Open XA的技术来解决数据问题。XA要求所有数据库在一项操作最终确定之前，都要确认已接收所有新的共享信息。由于网络的不稳定性以及数据库通常都很忙碌，这导致了诸多操作上的困难，最终这项技术被大多数人抛弃。

为了填补这一空白，我们需要一个新的跨服务数据一致性方法，一种不会遇到这些可靠性瓶颈的新方法。结果是一种新的现代、混合云就绪、下一代数据平台，它承诺无论系统多忙，都能提供高可用性和快速处理时间。这种方法确保不忽略这些早期缺点，而是确保我们的服务拥有正确的数据，并且如果它们修改了某些内容，确保所有其他服务都能理解这是“下一个版本”。它不会强加理念给用户，而是通过像SQL这样的已知和熟悉的接口隐藏其复杂性。它能够容忍集群中多个计算机丢失，并且对我们的提交提供非常低的开销。

好消息是我们已经建成了这项服务。它是一个即插即用的模块，可以无缝集成到您现有的应用中，需要的管理最少，并且只要您的消息系统还在运行，它就能一直工作。换句话说：我们已经自动化了数据平台的管理和平台工程师的日常工作。想了解更多详情，欢迎通过info@omniledger.io联系我们！