从下一代数据中心角度，谈为何Web3终将到来？

本文试图从数据中心进化的角度，探讨数据中心从最早的机房时代逐步过渡到行业云背后市场和需求变化的原因，同时也从传统业务和 Web3 业务的角度，思考了下一代数据中心呈现的状态和进化背后的理由，除此之外，还从商业需求、社会文化、和目前看到的一些迹象来解释为什么下一代数据中心会呈现分布式，最后对未来的业务形态进行了展望。

1.什么是数据中心？

数据中心（Data Center），起源于 20 世纪 40 年代的巨型计算机房，以埃尼阿克这样的最早面世的计算机为代表，早期的计算机系统，操作和维护起来很复杂，需要一个特殊的操作环境，连接所有组件需要许多电线和电缆，数据中心就是用来容纳和组织这些组件的空间。

从下一代数据中心角度，谈为何 Web3 终将到来？ — 图：最早的计算机埃尼阿克（ENIAC）来源：维基百科

在 20 世纪 80 年代，用户可以在各个地方部署计算机，当时对操作的要求还并不复杂，但是，随着信息技术（IT）运营的复杂度增加，大家意识到需要对 IT 资源进行控制。「数据中心」，适用于专门设计的计算机房。

尽管 2000 年前后处于互联网泡沫时期，很多公司倒闭，但是这段时间也给数据中心的发展和普及创造了机会，因为很多中小互联网创业公司也需要快速的互联网连接和不间断的操作来部署系统，但是对于资源有限的小公司来说，安装大型互联网数据中心是很不实际的，因此许多公司开始建造非常大的设施，也就是 IDC（Internet Data Center，互联网数据中心）

IDC 长啥样？

IDC 的发展经历了三个不同阶段：

第一代的数据中心只提供场地、带宽等基础托管服务；
第二代的数据中心则是以增值服务和电子商务作为其服务的核心；
第三代的数据中心能够提供融合的托管服务，可以实时地将互联网信息、电话信息、传真信息等集成在一起，再以客户最容易接受的方式提供给客户，这样，第三代的数据中心其实变成了一个网络服务中心。

2.数据中心的迭代

那么，从最早的机房时代再到今天常见的行业云，数据中心都经历过哪几次迭代？

数据中心 1.0 时代，基本就是物理意义上的数据中心，也就是 1990 年代至 2006 年的机房时代，包含了大型计算机，小型计算机以及今天意义上的 x86 通用计算机，基本上就是电信企业面向大型企业提供的机房，包括场地、电源、网络、通信设备等基础电信资源和设施的托管和线路维护服务。

数据中心 2.0 时代，互联网走向民用，网站数量激增，服务器、主机、出口带宽等设备与资源集中放置与维护需求激增，主机托管、网站托管等商业模式出现，再到后来 IDC 服务商出现，他们围绕主机托管提供数据存储管理、安全管理、网络互连、出口带宽网络服务等等，这一阶段的数据中心由互联网企业自行搭建或者租赁，存在建设与维护成本高、难以随业务发展而灵活扩展诸多问题，云计算应运而生。2007 至 2013 的通用计算云时代，这一时期主要的特征是商业模式构建以租户为中心，不论是物理机的服务器托管服务还是云计算的虚拟机租用模式。

数据中心 3.0 时代，2014 至 2021 的行业云时代，云服务提供商成为主流，而其中高价值的行业云诞生，数据中心的规模空前，而这也意味着计算和数据的高度的集中化。早在 1961 年就有人预料到计算会成为公共服务，1990 年代网格计算（Grid Computing）与云计算（Cloud Computing）等概念就已先后出现，不过直到本世纪初亚马逊 AWS 才真正拉开云计算的序幕，计算真正成为所见即所得的公共服务，数据中心从分散在各地的「小电站」逐步走向集中式的「大电厂」，一般都是科技巨头搭建的大型化、虚拟化、综合化数据中心，通过对存储与计算能力虚拟化，变为一种按需使用的计算力，对于使用者来说，集中规模化降低了成本，同时具备了灵活拓展能力。

数据中心的历史，最早可以追溯到 20 世纪 40 年代中期，当时最早用于军事的计算机房容纳了大型军用机器，用来处理特定的数据任务。到了 20 世纪 60 年代，有了大型计算机的诞生，IBM 公司为大型公司和政府机构部署了专用大型机房，但是，由于使用需求的增长，需要独立的建筑承载这些大型计算机，这就是最早一批数据中心的诞生。

直到 20 世纪 80 年代，个人电脑（PC）横空出世，电脑需要与远程服务器联网，这样才可以访问大型数据文件。到 20 世纪 90 年代，也就是互联网（Web1.0）开始广泛普及时，互联网交换中心（IX）大楼已逐步在主要国际城市兴起，以满足万维网的需求。这些 IX 大楼，也是是当时最重要的数据中心，很多人提供服务，很多还在使用。

什么是互联网交换中心（Internet Exchange Point）？

主要是指是不同电信运营商之间为连通各自网络而建立的集中交换平台，互联网交换中心在国外简称 IX 或 IXP，一般由第三方中立运营，是互联网的重要基础设施。

3.为什么数据中心会迭代？

从网站托管需求开始出现的数据中心发展

随着互联网使用的增长，数据中心数量开始急剧上升，因为 2000 年前后，各种规模的公司都热衷于在互联网上建立自己的网站，这时的数据中心，可以为这些公司的网站提供托管服务，并且提供远程服务器以保持它的运行。由于这个时候的互联网数据中心有着大量的服务器和来自不同电话公司和网络运营商的电缆，一旦网站出现任何技术问题，数据中心运营商可以马上更换服务器或切换连接，以保持其正常运行。

这是互联网数据中心主要的需求所在，也是商业模式和用户选择它们的理由。

当时，很多组织或者公司会将自己的数据业务迁移到数据中心，这种方式被称为主机托管，也就是说，企业要么将自己的服务器放在供应商的数据中心，要么从供应商那里租用服务器空间，用于远程运行和访问一些应用程序，例如电子邮件、数据存储或备份。

云服务与数据中心

不过，在过去的十年左右，云服务大厂频频出现，无论是微软、谷歌、亚马逊、IBM、甲骨文、SAP、Salesforce、阿里云，还是其他许多公司，云服务的市场，最初是由亚马逊网络服务启动的，该公司围绕「基础设施即服务（IaaS）」为企业提供托管解决方案。IaaS 允许公司通过云计算灵活地访问由 AWS 等供应商拥有的远程服务器，并根据其业务数据处理和管理需要，按需使用（也就是说，企业可以随时点外卖，由专业服务商处理这些业务）。

还有一种说法是，AWS 提供 IaaS，主要是因为亚马逊有着快速增长的电子商务业务，而这些业务可以为市场其他主体提供多余的云服务器容量，而事实并不是这样，AWS 的出现，是亚马逊可以向任何有需求的人或机构提供 IaaS 而专门建立的业务，IaaS 允许初创公司和小公司与大型机构竞争，因为大型机构通常拥有更广泛的计算能力供其支配，有了云服务，小公司也可以直接采购成熟的业务，不需要自己建设团队（自己建设团队，构建计算能力的成本对于小公司是非常高的）

需求和增长是如何发生的？

当很多公司开始通过云计算远程访问部分或大部分关键的商业软件应用程序，而不是在位于自己机房的服务器上部署和管理这些应用时，云计算数据中心的增速就开始了。

为什么会有这种变化？

成本和效率，永远是商业公司需要考虑的。

有了云服务，无论是何种规模的公司，都可以根据业务需求，选择合适的使用规模，从而降低软件的成本。这比在公司内部服务器上永久安装一些功能丰富的软件的成本要低很多。

由于云服务的需求急剧增加，因此，为托管这些服务而建造的数据中心的规模和数量也会增加。这样的数据中心就是超大规模的数据中心，通常这种设施由云服务提供商和其他公司所有，建造这些设施是为了向提供这些服务的家喻户晓的公司使用空间。2020 年第二季度末，如微软、谷歌和亚马逊运营的全球大型数据中心总数已增加到 541 个，比 2015 年中期的数字增加了一倍多。

总结一下：

1980–2000 年这段区间内，互联网刚出现，大型机和小型机是主流，但其成本非常高昂，运行的 UNIX 系统也成本高昂，并且，通用计算机 x86 性能尚且无法满足很多业务需求，但是随着通用计算机真正成为下一个时代的趋势，降本增效成为了所有企业的刚性需求。

2000 年到现在，2006 年 AWS 成立是一个开始，之后行业逐步认可了公有云作为基础设施的存在，特别是在 2013/2014 年，AWS 拿很多大客户的单子，我们可以这么理解，在早年间使用公有云的确成本低廉，成本优势巨大，但在 2015 之后公有云的成本优势也在不断减少，即使按照整体成本（服务器 + 租用机柜 + 运维人员工资 + 开发团队协同等因素）目前公有云成本并不占优势，于是出现了很多大厂开始自建云的趋势。

那么，下一代数据中心长什么样？和 Web3 有什么关系？为什么会出现新的第四代数据中心？背后的原因何在？

4.Web3 与下一代（第 4 代）数据中心

首先，我们认为下一代数据中心一定会与目前的数据中心不同，这是业务进化和底层技术的迭代所造成的必然。

其次，下一代数据中心，会呈现分布式（邦联化）和去中心化的形态。

为什么这么判断？

我们先从业务角度来看，这块分为两部分：一是传统业务，二是 Web3 业务。

首先，如果从传统业务来看，Service Mesh 的发展，给很多业务带来了分布式的呈现。自从几十年前第一次引入分布式系统这个概念以来，出现了很多原来根本想象不到的分布式系统使用案例，行业的需求特推动着前进的步伐，分布式系统的组成从几个大型的中央电脑发展成为数以千计的小型服务。具体是怎么回事呢？

首先，当电脑第一次联网，由于人们首先想到的是让两台或多台电脑相互通讯，因此，大家构思出了如下图的逻辑。

互相之间可以通讯的两个服务可以满足最终用户的一些需求，让我们把这个图再详细一点，添加一些网络协议栈组件：

上述这个修改过的模型自 20 世纪 50 年代以来一直使用至今。一开始，计算机很稀少，也很昂贵，所以两个节点之间的每个环节都被精心制作和维护。随着计算机变得越来越便宜，连接的数量和数据量大幅增加。随着人们越来越依赖网络系统，工程师们需要保证他们构建的软件能够达到用户所要求的服务质量。当然，还有许多问题急需解决以达到用户要求的服务质量水平。人们需要找到解决方案让机器互相发现、通过同一条线路同时处理多个连接、允许机器在非直连的情况下互相通信、通过网络对数据包进行路由、加密流量等等。

在这其中，有一种叫做流量控制的东西，下面我们以此为例。流量控制是一种防止一台服务器发送的数据包超过下游服务器可以承受上限的机制。这是必要的，因为在一个联网的系统中，你至少有两个不同的、独立的计算机，彼此之间互不了解。计算机 A 以给定的速率向计算机 B 发送字节，但不能保证 B 可以连续地以足够快的速度来处理接收到的字节。例如，B 可能正在忙于并行运行其他任务，或者数据包可能无序到达，并且 B 可能被阻塞以等待本应该第一个到达的数据包。这意味着 A 不仅不知道 B 的预期性能，而且还可能让事情变得更糟，因为这可能会让 B 过载，B 现在必须对所有这些传入的数据包进行排队处理。

一段时间以来，大家寄希望于建立网络服务和应用程序的开发者能够通过编写代码来解决上面提出的挑战。在我们的这个流程控制示例中，应用程序本身必须包含某种逻辑来确保服务不会因为数据包而过载。在我们的抽象示意图中，它是这样的：

幸运的是，技术的发展日新月异，随着像 TCP/IP 这样的标准的横空出世，流量控制和许多其他问题的解决方案被融入进了网络协议栈本身。这意味着这些流量控制代码仍然存在，但已经从应用程序转移到了操作系统提供的底层网络层中。

这个模型相当地成功。几乎任何一个组织都能够使用商业操作系统附带的 TCP/IP 协议栈来驱动他们的业务，即使有高性能和高可靠性的要求。

当第一次使用微服务

多年以来，计算机变得越来越便宜，并且到处可见，而上面提到的网络协议栈已被证明是用于可靠连接系统的事实上的工具集。随着节点和稳定连接的数量越来越多，行业中出现了各种各样的网络系统，从细粒度的分布式代理和对象到由较大但重分布式组件组成的面向服务的架构。

不过，为了处理更复杂的问题，需要转向更加分散的系统（我们通常所说的微服务架构），这在可操作性方面提出了新的要求。下面则列出了一个必须要处理的东西：

① 计算资源的快速提供

② 基本的监控

③ 快速部署

④ 易于扩展的存储

⑤ 可轻松访问边缘

⑥ 认证与授权

⑦ 标准化的 RPC

因此，尽管数十年前开发的 TCP/IP 协议栈和通用网络模型仍然是计算机之间相互通讯的有力工具，但更复杂的架构引入了另一个层面的要求，这再次需要由在这方面工作的工程师来实现。例如，对于服务发现和断路器，这两种技术已用于解决上面列出的几个弹性和分布式问题。

历史往往会重演，第一批基于微服务构建的系统遵循了与前几代联网计算机类似的策略。这意味着落实上述需求的责任落在了编写服务的工程师身上。

服务发现是在满足给定查询条件的情况下自动查找服务实例的过程，例如，一个名叫 Teams 的服务需要找到一个名为 Players 的服务实例，其中该实例的 environment 属性设置为 production。你将调用一些服务发现进程，它们会返回一个满足条件的服务列表。对于更集中的架构而言，这是一个非常简单的任务，可以通常使用 DNS、负载均衡器和一些端口号的约定（例如，所有服务将 HTTP 服务器绑定到 8080 端口）来实现。而在更分散的环境中，任务开始变得越来越复杂，以前可以通过盲目信任 DNS 来查找依赖关系的服务现在必须要处理诸如客户端负载均衡、多种不同环境、地理位置上分散的服务器等问题。如果之前只需要一行代码来解析主机名，那么现在你的服务则需要很多行代码来处理由分布式引入的各种问题。

断路器背后的基本思路非常简单。将一个受保护的函数调用包含在用于监视故障的断路器对象中。一旦故障达到一定阈值，则断路器跳闸，并且对断路器的所有后续调用都将返回错误，并完全不接受对受保护函数的调用。通常，如果断路器发生跳闸，你还需要某种监控警报。

这些都是非常简单的设备，它们能为服务之间的交互提供更多的可靠性。然而，跟其他的东西一样，随着分布式水平的提高，它们也会变得越来越复杂。系统发生错误的概率随着分布式水平的提高呈指数级增长，因此即使简单的事情，如「如果断路器跳闸，则监控警报」，也就不那么简单了。一个组件中的一个故障可能会在许多客户端和客户端的客户端上产生连锁反应，从而触发数千个电路同时跳闸。而且，以前可能只需几行代码就能处理某个问题，而现在需要编写大量的代码才能处理这些只存在于这个新世界的问题。

事实上，上面举的两个例子可能很难正确实现，这也是大型复杂库，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，深受欢迎的原因，它们能避免在每个服务中重写相同的逻辑。

大多数采用微服务架构的组织都遵循了上面提到的那个模型，如 Netflix、Twitter 和 SoundCloud。随着系统中服务数量的增加，他们发现了这种方法存在着各种弊端。即使是使用像 Finagle 这样的库，项目团队仍然需要投入大量的时间来将这个库与系统的其他部分结合起来，这是一个代价非常高的难题。有时，代价很容易看到，因为工程师被分配到了专门构建工具的团队中，但是更多的时候，这种代价是看不见的，因为它表现为在产品研发上需要花费更多的时间。

第二个问题是，上面的设置限制了可用于微服务的工具、运行和语言。用于微服务的库通常是为特定平台编写的，无论是编程语言还是像 JVM 这样的运行时。如果开发团队使用了库不支持的平台，那么通常需要将代码移植到新的平台。这浪费了本来就很短的工程时间。工程师没办法再把重点放在核心业务和产品上，而是不得不花时间来构建工具和基础架构。那就是为什么一些像 SoundCloud 和 DigitalOcean 这样的中型企业认为其内部服务只需支持一个平台，分别是 Scala 或者 Go。

这个模型最后一个值得讨论的问题是管理方面的问题。库模型可能对解决微服务架构需求所需功能的实现进行抽象，但它本身仍然是需要维护的组件。必须要确保数千个服务实例所使用的库的版本是相同的或至少是兼容的，并且每次更新都意味着要集成、测试和重新部署所有服务，即使服务本身没有任何改变。

下一个逻辑

类似于我们在网络协议栈中看到的那样，大规模分布式服务所需的功能应该放到底层的平台中。

人们使用高级协议（如 HTTP）编写非常复杂的应用程序和服务，甚至无需考虑 TCP 是如何控制网络上的数据包的。这种情况就是微服务所需要的，那些从事服务开发工作的工程师可以专注于业务逻辑的开发，从而避免浪费时间去编写自己的服务基础设施代码或管理整个系统的库和框架。将这个想法结合到我们的图表中，我们可以得到如下所示的内容：

通过改变网络协议栈来添加这个层并不是一个可行的任务。许多人的解决方案是通过一组代理来实现。这个的想法是，服务不会直接连接到它的下游，而是让所有的流量都将通过一个小小的软件来透明地添加所需功能。

在这个领域第一个有记载的进步使用了边三轮（sidecars）这个概念。「边三轮」是一个辅助进程，它与主应用程序一起运行，并为其提供额外的功能。在 2013 年，Airbnb 写了一篇有关 Synapse 和 Nerve 的文章，这是「边三轮」的一个开源实现。一年后，Netflix 推出了 Prana，专门用于让非 JVM 应用程序从他们的 NetflixOSS 生态系统中受益。在 SoundCloud，我们构建了可以让遗留的 Ruby 程序使用我们为 JVM 微服务构建的基础设施的「边三轮」：

虽然有这么几个开源的代理实现，但它们往往被设计为需要与特定的基础架构组件配合使用。例如，在服务发现方面，Airbnb 的 Nerve 和 Synapse 假设了服务是在 Zookeeper 中注册，而对于 Prana，则应该使用 Netflix 自己的 Eureka 服务注册表。随着微服务架构的日益普及，我们最近看到了一波新的代理浪潮，它们足以灵活地适应不同的基础设施组件和偏好。这个领域中第一个广为人知的系统是 Linkerd，它由 Buoyant 创建出来，源于他们的工程师先前在 Twitter 微服务平台上的工作。很快，Lyft 的工程团队宣布了 Envoy 的发布，它遵循了类似的原则。

Service Mesh

在这种模式中，每个服务都配备了一个代理「边三轮」。由于这些服务只能通过代理「边三轮」进行通信，我们最终会得到类似于下图的部署方案：

什么是 Service Mesh？

服务网格是用于处理服务到服务通信的专用基础设施层。它负责通过复杂的服务拓扑来可靠地传递请求。实际上，服务网格通常被实现为与应用程序代码一起部署的轻量级网络代理矩阵，并且它不会被应用程序所感知。这个定义最强大的地方可能就在于它不再把代理看作是孤立的组件，并承认它们本身就是一个有价值的网络。

随着微服务部署被迁移到更为复杂的运行时中去，如 Kubernetes 和 Mesos，人们开始使用一些平台上的工具来实现网格网络这一想法。他们实现的网络正从互相之间隔离的独立代理，转移到一个合适的并且有点集中的控制面上来。

来看看这个鸟瞰图，实际的服务流量仍然直接从代理流向代理，但是控制面知道每个代理实例。控制面使得代理能够实现诸如访问控制和度量收集这样的功能，但这需要它们之间进行合作：

完全理解服务网格在更大规模系统中的影响还为时尚早，但这种架构已经凸显出两大优势。首先，不必编写针对微服务架构的定制化软件，即可让许多小公司拥有以前只有大型企业才能拥有的功能，从而创建出各种有趣的案例。第二，这种架构可以让我们最终实现使用最佳工具或语言进行工作的梦想，并且不必担心每个平台的库和模式的可用性。

总结一下：随着 Service Mesh 的发展，传统业务的一部分确实会向着分布式的趋势发展。

本段参考资料：原文：Pattern: Service Mesh，来源，腾讯开发者（作者／Phil Cal?ado，翻译／雁惊寒，责编／魏伟）

其次，如果从 Web3 的业务来看，与 Web2.0 不同，Web3 的业务和基础设施绑定的很深，Web3 也有分布式数据中心的需求。特别是在以太坊转为 PoS 之后，不需要所有的节点去达成共识，而是 PoS 中的超级节点进行投票，PoW 模式下，所有节点都可以参与验证，但 PoS 的场景则只有被选出的超级节点可以成为验证节点，这些超级节点通常是运行着 GNU/Linux。每一次验证需要超过 2/3 的机器的节点都要参与投票，才能够通过，假设某项业务全球有几十个超级节点，一个节点放到德国的 Hetzner 数据中心，一个在法国节点放到 OVH 数据中心，然后日本的节点又是一个当地机房进行托管，

如何保证这些服务器本身的运行状态是可信的，比如没有遭到机房管理人员或者其他 Evil Maid（邪恶女仆）的篡改，如果能做到这点那 web3 超级节点的物理服务器可以被扔进这个星球上任何一个数据中心并且放心大胆的运行，毕竟验证服务器是关系到钱的组件。另外一方面，不同超级节点之间可以使用邦联化协议或者跨链桥的方式进行通信。

然后，我们从商业需求、社会文化、和目前看到的一些迹象来解释为什么下一代数据中心会呈现分布式：

首先是企业降低成本的需求。很多知名企业开始尝试自建云，这种自建模式本身就算分布式的呈现。原因主要在于，目前公有云成本极其高，而自建云会显著降低成本。一个典型的案例就是 Dropbox。Dropbox 通过构建自己的技术基础设施，在两年内节省运营成本近 7500 万美元。从 2015 年开始，Dropbox 开始将其文件存储服务的用户从 AWS 的 S3 存储服务转移到自己定制设计的基础设施和软件上，从 2015 年到 2016 年，这个项目，让 Dropbox 节省了 3950 万美元，将「我们的第三方数据中心服务提供商」的支出减少了 9250 万美元，2017 年，它比 2016 年的数字额外节省了 3510 万美元的运营成本。

注意，早期的 Dropbox 由于使用了亚马逊网络服务，构建起了庞大的用户群和品牌形象。尽管许多公司仍然乐于向 AWS 支付管理其基础设施的费用，但是，这种依赖知名云厂商的情况会一直存在吗？一旦初创公司变成拥有数亿用户的大公司，并且他们已经非常了解计算需求，那么建立完全按照这些需求设计的计算基础设施可能会更有效率。经过多年的实践，Dropbox 于 2016 年第四季度完成了所谓的「基础设施优化」项目。

Dropbox 管理层是这么说的，「我们的基础设施优化降低了单位成本，并帮助限制了资本支出和相关折旧。结合我们的付费用户群的同期增长，我们经历了收入成本的降低，毛利率的增加，以及我们在所呈现期间自由现金流的改善。」

那么，如果 Dropbox 选择自建基础设施，这会不会成为行业内的一种趋势？

其次，从技术的底层来看，数据中心的进化和摩尔定律有一定关联度，也就是说，芯片性能在持续提升并且价格下降还可以不断下降。但是，我们也发现，摩尔定律过去 10 年对于性能的增速明显在下降，AMD EPYC3 造就了单节点性能的一个高峰，原因除了 AMD 的微架构优化不错外也和用了 TSMC 的 5nm 工艺有关，这会成为一个通用计算的一个岔路口。为什么这么说，首先， EPYC3 的微架构优化不错且制程也使用了较先进的 5nm 工艺，基于硅的通用计算往后性能提升会极其有限。其次，EPYC3 成本上优势巨大，不光是对比 Intel 也包括 arm64 平台。AMD EPYC3 把单计算节点（服务器）性能推上了一个高峰，之前需要 4-7 个机架才能达到的性能，0xide 的服务器一个机架就可以达成，这对于 Web3 的数据中心来说，会极大的降低运维成本。

第三，就如同 BTC 出现是为了反抗金融危机之后的传统金融系统，数据中心也是一样。人类长期经历了数据和业务集中化的年代，对业务的反垄断和去中心化有着天然的需求。正所谓天下话说天下大势，分久必合，合久必分，Web1.0 时代本来是去中心化的，但到了 2.0 的年代实际上就是少数的垄断性科技企业通过使用普通用户的数据得到了了巨额利润，Web3 想解决的也是这个方面的问题，而第四代数据中心由于单点芯片技术能达到的程度，原来需要 10 个机柜的性能，现在可能 2 个就搞定了，这样的话，从技术上去支撑联邦化数据中心的业务可以说是神助攻。

第四，目前移动数据中心逐渐发展成熟，可以成为 Web3 数据中心业务的扩充。如下图，我们发现 DC-ITRoom 机架和集装箱用量在不断增大，DC-ITRoom 机架和集装箱是啥呢？其实就算是移动化的数据中心，如果做一个大的活动，活动对数据有要求，就可以使用这种集装箱式的可移动数据中心。那它和 Web3 的关系何在？在 PoW 的时代，其实就算在证明谁的算力大，那么这种移动化的数据中心可以直接靠数量堆上去给 Web3 的节点验证提供算力。

5.Web3、区块链特性与下一代数据中心

不过，我们在理解下一代数据中心时，也要结合区块链的固有特性去考虑。

已知常识是，区块链具备不可能三角，这个不可能三角指的是，去中心化、安全、可扩展性这三者是无法同时满足的，也就是说，任何系统的设计只能满足其中两个。比如极端的去中心化方案 BTC（比特币）和 XMR（门罗）都是以牺牲可扩展性为代价的，这导致 BTC/XMR 技术架构无法提供更复杂的业务，所以对于这类似这两种方案的业务来说，Layer 2 的存在是必然的，因为需要支持更复杂的业务。

为什么说 BTC 和 XMR 的设计都是极端去中心化的？因为这两种区块链，首先它们的业务非常简单且单一，比如 XMR/BTC 都是记账和转账功能；其次，每个节点都可以成为验证方，那也就意味着全网数据都可以保存在每个节点上。

但是，Layer 2 对于安全主要有几个方面的挑战：

首先，安全和可扩展性对于去中心化系统也至关重要，超级节点的引入会增加系统安全的风险。举个例子，PoW 的模式下，以前需要搞定几万个节点才能发起攻击比如 51%。但 PoS 时代，超级节点的诞生让需要掌控节点数量大大降低，安全存在的隐患也就更大。

其次，跨链协议实现中存在缺陷。这个缺陷要怎么理解？其实就是目前例如跨链桥的实现中存在 bug，比如 A 到 B 链经过跨连桥 C，但 C 在没有完成 A 和 B 的检查就把 transaction 放行，那就可能被攻击者利用去进行无限制转账。

第三就是供应链安全。主要包括开发人员是否会植入后门以及 build 基础设施的需要安全加固等考考量因素。

不过，如果牺牲一部分去中心化的特性，采用邦联化的架构，那这个三角就可以成为可能（也就是可以满足可扩展性和安全的特性）我们认为，Scalability 和 Security 是不能牺牲的，因为一旦这么做了，复杂业务也无法开展。不过，如果用分布式\邦联化替代 100 % 的完全去中心化，就会导致技术架构转变。因为完全去中心化指的是每个节点都有验证的权利，那即使某几个节点被攻击，也只是钱包安全的问题。但如果是 PoS 选出超级节点成为 validator 的节点受了攻击问题那严重性就非常高了。

6.分布式 Web3 数据中心应用实例

那么，倘若第四代数据中心真正到来，应用场景又是怎样的呢？

这里我们举一个应用场景：