在1913年，英国作曲家古斯塔夫·霍尔斯特（其名字明显透露出瑞典、拉脱维亚和德国混血的痕迹），发布了一部雄心勃勃的合唱作品《The Cloud Messenger》，这部作品基于一部著名的梵语诗歌，讲述了被流放的灵魂说服一朵飘过的云传递爱的信息，回到喜马拉雅山，等待他归来的忠诚妻子那里。《The Cloud Messenger》当时得到了冷淡的评价，最终迫使霍尔斯特与克利福德·巴克斯（作曲家阿诺德·巴克斯的兄弟）一起进入了一段抑郁的退隐期。克利福德·巴克斯对占星术的痴迷促使霍尔斯特创作了他最著名且成功的作品《行星组曲》。最近这部作品重新引起了人们的兴趣，但显然不是因为云计算的兴起。

不管有没有超自然的力量，认为像云这样分散而无形的东西能够可靠地传递信息（无论是爱情还是其他信息）无疑是一个浪漫的想法，但也许并不是显而易见的，至少直到21世纪，当整整一代互联网用户可能根本不知道云除了无线路由器另一端的消息传递平台之外还有其他用途。

说笑归说笑，我们现在称为云的基础设施在规模和地位上都有了增长，一些令人头疼的问题也开始浮现，让人不禁怀疑互联网是否真的被某种超自然的力量所统治。尤其是关于每个人能否共享同一份数据视图这一点，这一点尤为明显。

每个人都在同一时间看到同样的消息吗？“同一时间”到底是什么意思？

这些都是旧的问题，属于所谓的“一致性”问题范畴——但令人惊讶的是，这些问题至今仍未得到广泛解决，或许只有在少数情况下通过一些危险的变通方法得以解决。具体的技术细节要求很高，这意味着很少有人有时间和意愿深入研究。也许大多数研究这个问题的人都是物理背景的，因为核心问题是在空间和时间的背景下已经被详细探讨过的问题。

那么这在实践中意味着什么呢？让我们从IT系统面临的最关键问题之一来看：高交易量处理（OLTP）：处理这些问题的人可能会首先遇到一些更紧迫的问题。多年来，我处理过这些问题，并指出随着虚拟计算操作规模的扩大，许多现象越来越像量子力学的现象。这个想法中并没有什么魔法：这只是规模和信息访问的问题。然而，这个问题仍然很少被承认，更少被理解。

数据交易或许不能严格意义上称为诗歌，但它们无疑是承载着众多行业生命力的小段落，包括金融和旅游等行业，更不用说那些主宰着地球很大一部分的关键安全应用了。这些交易可能包含读写操作、销售购买、流媒体内容片段等许多内容。

聚合和处理大量交易 准确地 是一个如此核心的问题，人们可能会认为这个问题早就解决了。虽然“应该”是这样，但我们知道技术更多的是文化而非理性的产物，而趋势是由大公司之间的竞争商业环境所驱动的，这些公司不太适合用创新来推翻现有的想法。因此，技术陷入了自己的窠臼，不断重复着自我实现的故事，而世界则勉强地用胶带和细绳维系着——远比任何人愿意承认的要脆弱得多。

我之前曾从承诺理论的角度讨论过数据一致性问题详情见此，甚至与 András Gerlits 一起描述了一种虚拟化广域事务处理的技术解决方案，他已将其漂亮地实现于基础设施领域。其他人也写了很多相关内容。不过，让我们来回顾一下。

我们可以从两个主要的角度来看待这个问题：技术角度或实用角度：

• 技术上，数据一致性的问题实际上是长久以来的 相对性 问题，即当不同的接收者从各自的角度看待正在发生的过程，并据此做出可能与这些过程实际发生地的视角不同的判断时会发生什么。由于我之前已经多次写过这个问题，我们可以将其归入历史堆。
• 实际操作上，这个问题似乎更有趣——因为 承诺理论中的下游原则 告诉我们，所有的行动和混乱都发生在更新流的接收端。换句话说，问题在于如何使用数据以保持一致性。即使有最好的技术，最终是否一致还是每个人的选择。

基本的难题并不难理解。如果你用不同的镜头观察你面前的场景所收集到的光线，直立的建筑可能会看起来弯曲或倾斜；人可能会看起来胖瘦不一、绿色或蓝色等。无论信号源发出什么信号，最终解释并正确理解这些信号的责任在于接收者。同样，对于从传感器和来源收集的数据也是如此。我们如何才能信任报告给我们的信息呢？

理想情况下，我们都希望知道权威来源发送的“正确”版本，但实际上，大家对所看到的内容达成一致就已经是一件好事了。

每当用户界面从多个来源聚合数据到权威流时，我们都会遇到定义和管理一致性的问题。今天，在IT行业中，有两个非常实用的突出例子：_微服务_和数字孪生。

有人的时间漩涡有时处于控制之中……好吧，至少有时候是这样的！

微服务是一种设计概念，即将一个软件系统拆分成少量的人类可管理的部分，这通常会使整个技术系统的管理处于某种程度的模糊状态。从用户的角度来看，项目中的微服务需要作为一个松散耦合的单体服务一起工作，这意味着每当重要更改发生时（例如，当协议、代码、配置和整个系统的授权被更改时），这些准独立的部分必须同步更改。这导致了分布式一致性问题。

同样，在构建“数字孪生”模型时，即通过多个摄像头和传感器在智能环境中创建某个物理现象的一致虚拟图像，我们需要知道哪些数据应该放在一起，以创建一个可以根据可能变化的上下文进行语义对齐的快照。在事后从静态来源拼接数据进行取证时，有时可以使用时钟，但时钟对于动态实时更新来说并不是一个好的指导，因为它们没有考虑到延迟和先来先服务队列处理中的竞争问题，仅举两例。

感知或推断整体中多个部分的对齐问题在高并发情况下变得更加严重。如果数据从边缘到中心完全走不同的路径，我们如何公平地比较它们呢？毕竟，接收者的视角始终是他们的真相。看待高并发事务（其中“高”始终是指相对于处理能力而言）有不同的方式。此外，任何解释都必须通过所使用的传输和存储数据的技术的视角来看待。事实上，所有这些问题都可以从 政策 和 因果关系 的角度来解决，但这还不是当前软件的工作方式。

一个务实的工程师可能会（也确实有人这么做了）将一致性视为在SQL数据库之间同步部分共享状态的简单问题。这种观点确实受到了微服务范式兴起的鼓励，这种范式倾向于使用SQL后端。我曾经将微服务称为“计算历史中的暂时异常”，因为它们实际上是人类为解决通常使用编译器在其他情况下解决的问题而采取的工作方式，例如远程过程调用（RPC）。要使分布式应用程序的编译技术完整，缺少的是一个具有标准语义的分布式-链接器总线。一个“企业总线”或_智能数据管道_将能够像构建任何大型软件项目一样，使用RPC风格的编译器构建分布式应用程序，但这种概念目前仅在基本总线之上被构想。这样的企业总线（当然）正是一个Cloud Messenger。

这种总线的需求在多年前LinkedIn构建Kafka以及一些消息队列时就已经被预见到了。结合Actor模型风格的编程方法（非常符合Promise理论），已经导致了多个用于分布式系统开发的框架的出现。令人惊讶的是，数据变更的一致性或兼容性很少被解决，或者只是通过像Raft这样的分布式共识算法笨拙地处理，而这些算法实际上解决的是一个完全不同的问题，只是在相对较长的时间尺度上近似地解决了数据一致性的问题。

但大多数人使用的是简单的数据库。我们肯定已经解决了所有这些数据库的问题，对吧？有著名人物提出的Paxos，还有来自友好开源精神的Raft，谷歌对Spanner的强力方法，等等。每个数据库都内置了一些一致性的东西，现在我们对ACID与BASE（最终一致性）的争论已经感到厌倦了，因为——说实话——所有的一致性最终都是相同的：只是时间长短的问题。而且，直到出了问题，谁真的在乎呢？好吧，事实证明，我们可以在云基础设施中解决这个问题。这只需要一些智力上的投入。

一种早期的开明的云信使一致通信的实现方式，几年前由András Gerlits为仅支持SQL的孤岛系统实现。它允许独立的数据库共享一个公共表，无论谁写入或何时写入，所有数据库都只能在同步完成后读取新数据。这可以在与CAP猜想兼容的方式下完成，以打破其一些显而易见的神话。即使这种早期的尝鲜实现已经解决了一些常见的使用场景，但它更像是一种概念验证的应用程序补丁，而不是下一代服务的可靠替代基础设施。其中一个原因是它依赖于SQL。无论SQL多么主导，它绝不是唯一的表演者。人们更希望有一种可以应用于任何类型的数据存储的解决方案。

然后我们联手定义了一个基于因果时钟概念的更根本的解决方案，参见此处。最终所有数据都必须存在于键值存储中。因此，根本问题在于创建一个安全、可扩展且一致的数据存储（或用适当的术语来说，就是创建一个分布式ACID存储）。

图：时空中的序列化的时间旋涡模型。

也许在某些情况下，拥有绝对即时一致性的重要性被夸大了。这可能是为什么许多人认为可以利用Raft协议和数据复制来保证数据安全，即使有些妥协也无妨。在独立数据库之间同步部分表对于许多应用程序来说是很有用的，但它并不能覆盖所有问题。然而，在一个特定情况下，我们需要以精确原子的方式更新全局一致性：那就是平台配置更改或行为策略更改。

修改数据库模式的定义，如果处理不当，可能会造成灾难性的后果，最多也会导致无法解决的数据冲突。想象一下，如果仅仅依靠相对性就允许无控制地引入数据语义上的偏差，这将有效地导致数据被污染。此外，如果我们更改数据的安全访问控制或共享设置，在一瞬间内不同主机上的策略有所不同，那么数据的安全边界就已经被破坏了。数据在原则上可能会被污染——尤其是在高流量的情况下，请求的密度足够高，可以探测到微小的不一致性。这听起来可能是个小问题，但如果这是防火墙漏洞，你可能会有不同的看法。

几乎所有的IT问题最终都归结为某种形式的配置管理和策略管理。当云计算开始主导21世纪的运营时，策略和配置管理从90年代精心设计的代理模型转向了更为传统的“推送式分发”模型。在这种模型中，软件被打包（现在是容器或虚拟机镜像），以现成的、不可变的配置形式提供。重新配置只能通过重新部署来完成，而任何不同的配置需求现在必须提供为不同的预打包版本。像CFEngine这样的模型，即在主机上进行事后实时定制，被云计算一代所拒绝，转而采用像Ansible和Terraform这样的软件的推送上传模型。

配置空间（所有计算机上所有可配置设置的想象空间）过去是一个纯粹抽象的概念——存在于计算机内部的某个位置。现在情况已不再如此：将配置拆分为包或封装区域、“容器”等，意味着配置空间现在基本上通过虚拟化映射到了实际的空间时间位置。

这也就是说，配置现在实际上广泛地分布在物理位置上。时空本身成为了新的计算机配置，就像在经典物理学中，相空间外部化了动力学（但量子物理学提醒我们，这种看法是幼稚的）。关键在于，这些位置现在也可以在任何时候由云管理进行重新映射。那么，在云中一个任务的位置是什么？这取决于你问的时间。

这种将 内部状态 映射到实际物理空间的方式也发生在量子力学中，它导致了诸如穿过障碍物的“幽灵”效应以及边界不确定性等问题。这听起来可能像是理论上的东西，但实际上它意味着可能对托管进程的容器安全造成潜在的破坏。

图：云代理之间的状态和过程的虚拟运动表现出精确的量子行为，如这一人工模拟的双缝排列所示。

目前，没有人特别关注这些细节。有一种普遍的看法是，只要我们加密所有内容，就能解决任何封装、一致性和主权问题。简单来说，并非在所有情况下都能解决：只有当进程之间的交互完全是基于数据时才能解决。共享资源，如CPU和内存的饥饿问题仍然可能发生，因为被包含的进程由于底层对CPU和内存的依赖而相互干扰。加密并不能防止拒绝服务攻击，例如。依赖关系并不都是基于数据的（无意双关）。平台本身是影响的根本渠道。

还有一个时空问题也引起了我们的注意，这更多是模型设计上的不足，而不是技术上的问题。我们倾向于将世界视为一系列快照，仿佛动态过程中的每一个静止时刻都是一个新的、稍纵即逝的真理，而不是它真正的样子：仅仅是系统因果演化的一步。因此，数据库几乎总是采用“最新值胜出”的写策略，仿佛每个时刻都让我们更接近最终的真理。但是，事务更新流通常是随机到达过程，尤其是在分布式系统中覆盖广泛区域时，这意味着数据库中的值基本上是随机数，这不仅使得调试潜在错误变得困难，也意味着我们在根本层面上接受了不可预测性（而没有对其进行建模）。

一致性并不能保护你免受争用：如果用户想要通过提交冲突的值来互相争斗，没有任何数据库技术能够阻止他们。

这对数据语义意味着什么？这确实使得数据的语义难以管理。带有串行和并行版本控制的版本化文件系统已经存在了十多年，而版本控制在编程流程管理中已经无处不在。为什么数据库不能拥有同样的历史完整性和安全性？这在像 Omniledger 和 XTDB 这样的项目中正在得到解决，它们提供了“不可变”的时间线存储和解释性策略语义。也许这为时已晚，但技术要普及总得先引起大众的关注。

部分数据不一致的原因正是随机并行处理中的 顺序模糊性。通常没有明确的数据语义，因为接收方没有明确的过程来整理这些数据。使用数据旋涡账本模型可以更清晰地定义这一点。事实上，人们可以想象 Omniledger 和 XTDB 合并以提供全面的语义控制：IT 世界的“时间领主”终将获胜！

仅仅通过对云中过程物理原理的一点重新思考，管理这些过程——处理流和事务——已经变得简单地像是管理时空——就像照料虚拟花园一样，而不是像通常那样处理和回收随意丢弃到未管理的垃圾场中的数据。数据管理和知识管理现在是关于以智能方式管理空间和时间。

我的关于信息系统中空间和时间的作用的书

让我们不要忘记未来。当然，没有什么是真正的新事物，但对更好的东西的渴望总是会试图穿透普遍性投下的漫长阴影而闪耀出来。一切过去都发生过，也必将再次被重新发明（除了《太空堡垒卡拉狄加》中的演员们）。毕竟，大多数事情都是偶然发生的——而那些有意为之的事情，通常会被一个输得不服气的人用尽全力去反对。

我们在网络开发中犯了一个简单的疏忽。将 数据管理 与 数据通信 分开处理其实是一个已经持续了几十年的荒谬做法。这种做法之所以长期存在，主要是因为分析师和投资者为了市场分析而随意坚持某些简单的分类——大胆地 "误解估计" 公共市场。多年来，一直有关于“下一代”互联网技术的提案。所取得的一点点进展都是通过幕后悄悄进行的。

一种解决数据管理的概念与_命名数据资源_的想法有关。资源的命名（例如使用 URI）可以封装版本控制和成员资格的概念，而不仅仅是唯一的键值。通过允许名称在空间和时间上都是唯一的，并使用健壮且可扩展的发布-订阅架构，可以构建一个尊重语义的数据通信层次结构。这样的方法可以使下一代互联网在语义层面上真正尊重数据的完整性。

试着想象一个世界，在这个世界中，所有的基本互联网技术都像智能数据管道一样，从源头到目的地传输信息。然后，将变更的入口点附加到数据时间旋涡账本上！这样，你将拥有所有工具，通过定义好的策略订阅通道_自动_透明地管理一致的数据。此时，可以简单地通过配置选项来实现承诺理论下游原则。这就是Omniledger的目标。

云服务的设计者在开发云技术时根本没有考虑到可持续扩展的问题，他们只是在推销旧的物理网络架构的 熟悉性，以及所有那些不良习惯。负载均衡器 是一种补丁，诞生于纯粹的物理网络中，当时这些网络还不成熟且 孤立。在服务前面放置一个点负载均衡器的想法，用其他任何名字来说，也只是一个 交通拥堵。没有人这样做是因为这是最好的解决方案，这只是当时的一个必要补救措施。但这种补救措施却成为了当前云服务提供中的圣物。

内容分发网络 (CDN) 则属于下一代的思想。CDN 的负载均衡工作方式比普通负载均衡更加可持续，并且还提供了从一个明显的单一服务点进行数据复制的功能。同样的理念也可以用于改进所有数据服务，通过智能数据流。合理的方法是借鉴版本控制，即调整我们使用 名称 的方式，并使用 目录服务（作为间接查找）指向用于快速访问的复制副本。我们需要从时间线上查找 上下文适当版本。

基本的CDN仍然遵循“最新版本获胜”的旧模式，但多年前曾提出过一种升级方案，即Named Data Networking或NDN，它在其中增加了版本控制的措施，使得每个版本在其所属的时期都是赢家。NDN也没有完全实现，但其中的一些想法将在我们称为创新的渐进发展中渗入未来。

在 NDN 中，数据基本上是不可变的（这带来了单独的垃圾回收问题，但这是一个干净的分离），因此可以仅通过简单的分布式哈希表来定位语义命名的对象（类似于语义网中的 URI 概念）。我们用一个命名问题来交换一致性问题——但命名是我们比时空动态更了解的问题。

技术已经取得了巨大的进步，但在某些方面，与我们对它的期望相比，它似乎仍然停留在原地。数据技术迅速渗透到社会中，以至于我们有时会期望这些问题已经得到解决，但实际上这些问题才刚刚开始显现。未来几年里，我们可能还需要用创可贴和口香糖来解决这些问题。我们知道每一代人都试图将新想法重新塑造成他们年轻时所拥有的旧想法，但真正的创新者仍然存在，并最终能够带来改变——即使需要时间才能惠及大众。一个发明可能需要被重新发明两三次，才能最终被广泛采用。早期的CFEngine可以做许多早期云系统能够做的事情，甚至成为了Kubernetes自我修复的模板，但它并不是商业化的正确工具。NDN指出了某些实际问题，但被忽略了。现在的云可能是一堆笨拙的拼凑物，但这正是人类经验的本质。高瞻远瞩的精神常常被商业世界所排斥。

“天女的发丝，空中冰激凌城堡？” 荣·米歇尔曾经这样仰望云朵，富有创意地想象着。然后她也整理了一下思绪，注意到：

“但现在它们只挡住了阳光

他们对所有人都会下雨也会下雪

我本可以做那么多的事情

但是云挡住了我的路……

我个人就像一个充满希望的流亡灵魂，祈求阳光。

作者注：为了平衡时间线并安抚伟大的云灵，本文将在光明与黑暗、善与恶、冰淇淋与热巧克力、秋分日光之间发布的时刻，即2024年9月22日下午2:43发布。 :)