云时代的终结

我们正面临云时代的终结，这是一个很大胆的论调，甚至有一些疯狂，但请耐心看完下面的内容。

传统的认知认为服务器应用的未来在云端。亚马逊、谷歌和微软在他们的云产品中加入越来越多的工具，让运行服务器软件变得越来越容易，以致于人们觉得将代码托管在 AWS、GCP 或 Azure 上会是最好的选择——因为这样做方便、便宜、容易进行自动化、弹性伸缩……既然如此，为什么我还会预言云时代的终结呢？

云无法满足长期的伸缩性需求。在云端构建一个可伸缩、可靠、高可用的 Web 应用程序其实是很困难的。就算你做到了，那也是以耗费大量金钱和精力为前提。如果你的业务开展得非常成功，最终还是会受到云和 Web 本身能力的限制：计算机的计算速度和存储容量比网路带宽本身增长得更快。或许这对大多数公司（Netflix 和 Amazon 除外）来说并不是个大问题，但很快就会成为问题。通过网络传输的数据在急速增长，视频的分辨率在提升，需要传输的数据量越来越大，而且很快就会有 VR 数据集在网络上传来传去。

这个问题与 Web 结构本身有直接的关系。获取内容的客户端远比提供内容的服务器多。比如，有人在 Slack 上张贴了一张有趣的小猫图片，和我坐在同一个地方的其他 20 个人都对这张图片感兴趣，所以我们每个人都从服务器上把图片下载下来，那么服务器就需要发送 20 次图片。

如果将服务器移动到云端，那么靠近用户的网络需要处理无法预测的吞吐量。除此之外，还需要海量硬盘来保存这些数据，以及使用很多的 CPU 将数据推送给每一个用户。随着流服务的增长，这种情况会更加严峻。

这些活动需要大量的能源和冷却机制，让整个系统变得低效、昂贵，甚至给自然环境带来污染。

集中式的结构让系统变得脆弱。集中式的数据存储和程序在可用性和性能方面存在不足。如果 Amazon 的数据中心发生洪灾、被小行星撞毁或遭遇龙卷风该怎么办？或者轻微一点，比如发生了短暂的电力故障？机器上保存的数据就无法被访问，甚至永久丢失。

我们一般会把数据保存在多个地方来降低这种问题发生所造成的危害，但那样就需要更多的数据中心。或许使用多个数据中心会极大降低事故风险，但那些非常重要的数据仍然可能丢失，比如婚礼视频、孩子成长的照片或者像 Wikipedia 这类非常重要的公共信息资源。这些资源全部保存在云端——Facebook、Google Drive、iCloud 或 Dropbox 等。如果这些服务哪天失去资金支持，那么这些数据该怎么办？即使这种情况不会发生，要访问这些数据仍然有诸多限制，比如你要通过他们的服务才能访问到这些数据，即使你把它们分享给你的朋友们，他们也仍然需要通过这些服务来访问这些数据。

云服务提供了信任机制，但并不保证绝对安全。你的朋友只能信任经由受信任的中间人发送给他们的数据，这在大多数情况下是没有问题的，但网站和网络是由国家注册的合法实体进行运营的，政府完全有权力迫使他们做一些出格的事情。大多数时候，这样做会是一件好事，因为可以借此帮助解决犯罪问题或者移除网络上的不合法内容，但如果这种权力被滥用了就会走向另一面。

就在几周前，西班牙政府通过手中的权力停止了加泰罗尼亚地区的一次独立公民投票活动，他们封锁了与投票相关的网站。在中国，通过封锁麻烦网站和秘密修改用户内容这种行为是很常见的。即使在自由言论不成问题的西方国家，也仍然需要努力让互联网变得更加自由和开放，保证用户看到的内容就是作者要发布的。

这让我们感到坐立不安。高度集中的互联网最可怕的地方在于私人数据的堆积。大公司为我们提供了各种服务，同时坐拥大量的用户数据，他们通过这些数据预测你将会购买什么商品、将会把手中的选票投给谁、可能什么时候会买房子，甚至预测你想要几个孩子。

或许你会觉得这没什么问题，毕竟你是相信他们才愿意把信息透露给他们，但你要担心并不是他们，而是另有其人。今年早些时候，信用报告机构 Equifax 经历了有史以来最大的一次数据外泄事故，泄露了 1 亿 4 千万客户的信息。如果我们能够再小心一些或许可以避免这类问题的发生，但很显然，数据泄露是无法完全避免的，而且一旦发生了就无比危险。唯一可以防止这类情况发生的办法就是在一开始就不要如此大规模地收集数据。

那么，什么将取代云？

基于 CS 模式（如基于 HTTP 协议的客户端与服务器端交互）的互联网和依赖集中式认证实体的安全机制（比如 TLS）很容易出现一些难以解决的问题，所以我们需要找到一种更好的模式，在这个模式里，没有人会把你的个人数据保存起来，大媒体文件通过整个网络进行传播，形成一个完全点对点和无服务器的系统（这里说的“无服务器”不是指云端的无服务器架构，而是指真的没有服务器存在）。

通过广泛了解这方面的新兴技术，我确信点对点技术就是我们的方向。点对点 Web 技术旨在通过一些协议和策略替换掉已有的 Web 构件块，解决上述的大部分问题。点对点技术的目标是形成一个完全分布式、持久、冗余的数据存储，网络中的每一个客户端都保存了数据的部分副本。

如果你之前听说过 BitTorrent 技术，那么也应该很熟悉下面的内容。网络用户通过将大文件拆分成小文件（每个小文件都有一个唯一 ID）进行分享，不需要集中式认证实体。如果要下载一个文件，只需要提供文件的散列值。BitTorrent 客户端会找到持有该文件片段的对等节点，并将文件片段下载下来，直到找到所有的文件片段。

那么我们该如何找到对等节点？BitTorrent 使用了一种叫作 Kademlia 的协议，网络里的每个节点都有一个唯一 ID，与数据块 ID 的长度一样。每个数据块被保存在一个节点上，这个节点的 ID 与数据块 ID 最为接近。数据块 ID 并不是随机生成的，而是使用了数据块内容的散列值，相当于数据块内容的指纹，所以数据块可以通过散列值进行寻址，并可以通过重新计算和比较散列值来验证数据块内容。因为数据块内容是唯一的，所以就不会下载到与原先内容不一样的数据。

更有意思的是，通过将散列值内嵌到另一个数据块里，就可以实现数据块链接。如果链接的数据块被篡改，它的 ID 也会发生变化，那么链接就会失效。而如果内嵌的链接被篡改，那么包含链接的数据块 ID 也会发生变化。

通过这种内嵌 ID 链接的机制可以生成数据块链，甚至是更复杂的结构，比如有向无环图，简称 DAG。这种链接也被称为 Merkle 链接，以发明者 Ralph Merkle 的名字命名。Git 仓库就是一个 Merkle DAG 的例子，Git 将提交历史和所有的目录及文件保存成数据块，并分布成一个很大的 Merkle DAG。

这又引出了另一个有关分布式存储可寻址内容的属性：它们是不可变的。数据块内容是不可变的，修改过的版本会单独保存，不同修订版但内容没有发生变化的数据块会被重用，因为它们拥有相同的 ID。这就意味着，在这个系统里，不会出现重复的文件。所以，在这个新的 Web 系统里，同样的小猫图片只会存在一个副本。

借助 Kademlia 协议、Merkle 数据块链和 Merkle DAG，我们可以构建出结构化的文件模型和修订时间线，并在大规模的对等网络里共享数据。现在已经有一些协议在使用这三项技术构建分布式的存储，比如 IPFS。

命名和共享方面的问题

上述的几项技术已经可以解决之前所列的问题：我们拥有了分布式、高冗余的存储，在必要的时候可以追踪到文件的历史修订版本。这几乎解决了可用性、容量、性能和内容验证方面的问题。它也解决了带宽问题——数据在对等节点之间传输，不存在瓶颈。

我们还需要一个可伸缩的计算资源，不过这实现起来不会太难：人们使用的笔记本和手机比大部分应用所需要的计算能力要强大得多，所以计算能力是完全可以水平伸缩的。只要我们能够让所有设备参与计算，就可以解决可伸缩计算资源问题。

现在，我可以直接从坐在我旁边的同事那里获取小猫图片，而不是从 Slack 服务器上下载。但如果要上传一张小猫图片，就需要更新 Slack 通道，这个看似无伤大雅的事情却是最为困难的部分。

最困难的部分：更新内容

随时间变化的实体其实是人类大脑对外在世界稳定秩序的一种反映。我们也可以把这种实体看成是一种标识，随着时间的推移，它会带上一系列不同的值（这些值是静态、不可变的）。在为计算机进行信息建模时，这是一种更为自然的方式。如果我告诉你一些事情，就像泼出去的水，无法收回。美国总统是谁这个事实是不会随时间发生改变的，它们只会被具有相同标识的另一个事实所替换。在 Git 系统里，一个 ref（branch 或 tag）可以在不同时间指向不同的提交，使用一个新的提交替换当前指向的位置。Slack 的一个通道也就是一个标识，它的值就是一个随时间增长的消息列表。

真正的麻烦在于，通道里还有其他人。他们都想往通道里发送消息，有时候还同时发送。

集中式系统里会有一个单独的中心实体来保证这些更新事件按照串行的方式进行。而在一个分布式系统里，所有参与方都是公平的，所以需要一种机制来保证可以在“历史”问题上达成某种共识。

对于分布式系统来说，达成共识是最为困难的部分。这个问题不仅仅影响到并发更新操作，也影响到那些需要在适当位置进行更新的操作，比如那些随时间发生变化的“事实来源”。这个问题不仅对于数据库来说很难实现，也会影响到其他关键服务，比如 DNS。通过非集中式的方式来注册 ID 意味着所有的参与方需要达成共识，比如一个名称代表什么意思，否则两个不同的用户可能会看到具有相同名称但内容不同的文件。基于内容的寻址方式在机器层面解决了这个问题，但对于人类来说，问题依然存在。

一些已有的策略可以用于处理分布式共识问题。比如，通过“quorum”机制选出一个“首领”，让它来做出决策（如 Paxos 和 Raft 协议），接下来所有的变更都需要通过这个首领。这实际上也是一种集中式的系统，只不过它可以容忍中心实体的崩溃或网络中断。

另一种是基于工作证明（proof-of-work）的系统，比如比特币区块链，它们通过让对等节点解决谜题来达成共识。谜题难度很高，但检验步骤非常简单，而且还提供了一些额外的规则用于解决冲突。一些分布式区块链使用基于权益证明（proof-of-stake）的共识来减少解决谜题所耗费的能源。对权益证明感兴趣的读者可以参考由 BitFury 发布的这篇论文。

还有一种方式是围绕CRDT（无冲突复制数据类型）而展开，在某些情况下完全不存在共识问题。最简单的例子就是计数器，如果所有的更新操作都是要“加一”，只要我们能够保证每个更新操作只执行一次，那么次序就不重要了，而且结果总是一样的。

对于这个问题似乎并不存在一个很清晰的答案，或许根本就不存在这样的答案，不过还是有很多聪明人在努力工作，他们提出了很多有意思的解决方案。我们只需要从中做出权衡，具体要根据规模而定，并在可用性和一致性方面做出一点妥协。大部分应用会选择可用性和最终一致性。

公共文件里的隐私

隐私问题是一个很明显需要去解决的问题。在将内容保存到分布式系统的同时又如何能够做到不让所有的东西都公开呢？如果能够做到隐藏私密内容，那么基于内容寻址将会是一个很好的解决方案。我们有三个层次的隐私：公开、隐藏和私密。对于第三个层次来说，似乎可以通过加密来实现——对保存的内容进行加密并通过“带外（out of band）”（比如NFC、扫描QR 码）进行共享。

完全依赖加密似乎存在一定的风险（骇客无时不刻在寻找漏洞），但其实也没有那么糟。事实上，在实际应用当中还是很安全的。公司和政府通常会把敏感数据保存起来，让公众无法访问到。相反，只有一些内部的人员可以访问这些数据，如果你可以访问存储数据的系统，就可以看到这些数据。

但如果我们使用一种公开的方式来保存私密数据，我们就需要强制使用高强度加密来保护数据，这对于需要访问这些数据的人来说不会是一个好消息。这有点类似开源与安全相关的软件，每个人都可以看到内部的工作原理，并找出问题所在，但了解安全机制并不会帮你更好地破解系统。

这种访问控制机制所造成的问题在于，如果你授权某些人访问某些数据，那么他们就会永久持有这些数据的当前副本。你当然可以修改加密秘钥，但问题是显而易见的：只要授权他人访问数据，他们就可以拥有这些数据的私有拷贝。

这一领域所面临的挑战在于，如何建立一个系统用于验证标识和在会随时间发生变化的一组人当中共享私有数据，比如一个私有Git 仓库的协作者们。这完全可以通过组合私钥加密和旋转秘钥来实现，但这样会给用户带来不好的体验。

从云到雾

云的终结将是一个激动人心的时刻，尽管存在巨大的挑战。首先，在技术方面，我们需要在点对点网络方面做出大量的改进。基于内容寻址的存储机制为内容本身提供了验证功能，保存的内容是永久的（只要还有人对它们感兴趣），而且在速度方面应该也会有很大改进。

在未来的某一时刻，数据中心可能会成为如烟往事。用户的设备变得越来越强大，计算和存储到处可见，因为它们就在用户的手中。

对于业务来说，这种改变将会体现在成本的缩减上，并省去了构建可靠数字产品的烦恼。业务不再专注于如何减少宕机时间，而是把精力放在如何增加客户价值上。我们仍然需要一些云端服务器，但它们已经变成了对等节点。我们仍然会看到异构应用，有一些是面向客户的对等节点，也有一些是后端对等节点，它们基于不同的加密层级实现访问控制。

对于企业和用户来说，另一个好处体现在对用户数据的处理方式上。因为不再需要集中保存大量的用户信息，就不会有大量数据泄露的风险。软件开发社区的领导者们长久以来都在争辩说，用户将数据通过互联网传送给业务方的应用程序，这种设计是有缺陷的，相反，我们应该将应用程序发送给用户，让它们运行在用户的私有数据上。这种模式看起来更为安全，因为业务方就无法收集到用户的信息。

但仍然会存在混合型的方案，一些不透明的服务掌握着私有数据。

这类架构用于进行大规模计算或提供软件服务，更接近于最初设想的以开放信息交换为准则的互联网，任何人都可以向他人发布内容，并通过网络用户达成共识来控制内容的发布和访问，而不是让拥有服务器的私有实体来控制。

查看英文原文： The end of the cloud is coming

感谢徐川对本文的审校。