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

WebView社区
2022年9月29日04时

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

当然，也欢迎相关领域专家一同进行探讨：）

内容大纲

*本文11500字左右

什么是数据中心

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

3.为什么数据中心会迭代从网站托管需求开始出现的数据中心发展云服务与数据中心需求和增长是如何变化的？

4.Web3与下一代数据中心（第4代）下一代数据中心为什么是业务进化和底层技术的迭代的必然传统业务和Web3业务的进化

5.Web3、区块链的特性与下一代数据中心不可能三角

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

7.关于未来趋势的判断Web3业务与邦联化基于ETH的生态会更多元化

什么是数据中心？

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

最早的计算机埃尼阿克（ENIAC）

图片来源：维基百科

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

1980年代的数据中心长这样

图片来源：https://saliaw.artstation.com/projects/nNvJo

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

IDC长啥样？

图片来源：

https://www.datacenterknowledge.com/archives/2014/11/11/idc-amount-of-worlds-data-centers-to-start-declining-in-2017

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

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

参考资料：

https://baike.baidu.com/item/%E4%BA%92%E8%81%94%E7%BD%91%E6%95%B0%E6%8D%AE%E4%B8%AD%E5%BF%83/8471124?fr=aladdin

https://en.wikipedia.org/wiki/Data_center

数据中心的迭代

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

数据中心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，一般由第三方中立运营，是互联网的重要基础设施。

参考资料：

数据中心进化史：从本地机房到IDC到云再到智算中心 -创事记-2020

为什么数据中心会迭代？

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

随着互联网使用的增长，数据中心数量开始急剧上升，因为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有什么关系？为什么会出现新的第四代数据中心？背后的原因何在？

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 Calado，翻译／雁惊寒，责编／魏伟）

其次，如果从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的节点验证提供算力。

文章转发自WebView社区微信公众号，版权归其所有。文章内容不代表本站立场和任何投资暗示。

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

WebView社区文章

WEB3.0相关文章