最近的Facebook中断事故使许多web2用户意识到他们的核心互联网服务的基础是多么脆弱。
大多数web2服务默认是中心化的，但Facebook的运营被证明是中心化的，以至于当系统的一个部分出现故障时，工程师们被封锁了一切——甚至调试工具。
在Facebook工程团队的一名成员发布的事件报告中，有一段特别有说服力的段落写道：
…当我们的工程师努力弄清楚发生了什么以及为什么会发生时，他们面临两个巨大的障碍：首先，由于他们的网络出现故障，无法通过我们的正常方式访问我们的数据中心，其次，DNS 完全丢失让我们无法使用通常用来调查和解决此类中断的许多内部工具。
互联网并不总是这样。在早期，它更加去中心化。由于没有AWS、Azure或谷歌云平台，网站大多运行在单独的服务器上。这意味着一次中断无法一举中断数百万项服务，并且来自一个提供商的规则更改无法强制实施大规模审查。
今天，谷歌、微软和亚马逊共同托管60%的互联网，仅亚马逊就占到33%，包括了最受欢迎和最依赖的web2服务，如Netflix、Spotify、Twitch、Facebook、Slack和Reddit——更不用说互联网银行和政府门户网站等重要服务。
为什么会变成这个样子？开发人员被教导以中心化的方式做事——使用这些公司的API，部署 AWS。中心化服务是赚钱的工具，它们拥有最大的营销影响力。
开发人员可以选择是为继续垄断我们的互联网做出贡献，还是寻求新选择以防止停机、抵制审查和捕捉网络原始精神。在本文中，我们将了解一些流行的web2和web3架构，以及它们如何实现或未能实现去中心化。
一切都中心化
当应用程序的后端和前端都中心化时，它具有列表中任何架构中最多的故障点。后端和前端都使用一台服务器，即使它们保持在线状态，如果它所依赖的API出现故障，整个应用程序也可能会宕机。
一个例子：Stripe。其PHP托管在AWS上，连接到Google身份验证API进行登录。
在Arweave上存储数据的中心化服务器
Arweave可以像任何其他数据库一样运行——它甚至可以使用graphQL或ardb进行查询，这使得应用程序可以轻松地从blockweave事务的完整历史记录中快速加载他们需要的内容。如果在 Arweave上存储数据的中心化应用服务器出现故障，仍然可以从Arweave查询应用程序数据，就好像其API仍在运行一样。
一个例子：ArDrive。主要后端数据存储在Arweave上，一些服务和前端由Google Cloud和 Fastly提供。
去中心化的后端，中心化的前端
当应用程序的后端由区块链提供服务时，即使前端是一个故障点，也不会出错。无论是仅仅因为它托管在中心化服务器上而容易受到攻击，还是因为托管它的实体可以响应删除请求或以其他方式对其进行审查而容易受到攻击，仍然可以说，它仍然是“窒息的喉咙”。这种设置在 Uniswap等DeFi应用程序中很常见。
一个例子：Uniswap。今年早些时候，Uniswap Labs改变了前端以隐藏大约100个代币，成为头条新闻。在这种情况下，前端比后端更容易拯救，而且由于Uniswap和其他web3应用程序经常为此目的使用智能合约，永久网络档案管理员能够克隆Uniswap以前的用户界面并将其永久托管在Arweave上。
去中心化后端，去中心化前端
具有存储在Arweave上的智能合约后端和前端的应用程序是最强大和最抗审查的架构之一。Arweave网络由数百个激励节点组成，从未停机，并且可靠地托管了大量前端，从流行的 DeFi应用程序到我们自己的永久播客和永久博客。
ArGo在这里得到了特别的赞誉，因为它提供了一种用户友好的方式，可以从GitHub存储库中持续部署前端并附加HNS和DNS域名。
一个例子：permablog，其整个后端由SmartWeave合约运行，前端也可以通过它的 arweave.net txid和一个漂亮的DNS (permablog.net) 访问。还有一个HNS域名以提供额外的弹性。
其他激励点
Handshake域名。Handshake (HNS) 是“一种去中心化的、无需许可的域名协议，其中每个对等方都在验证并负责管理根DNS域名区域”。虽然它自我描述为一个实验，但结果已经是可见的和可验证的。
多个/专用网关。网关是关于Arweave规模问题的最后一个正在进行的项目。一个流行的项目可能会（意外地）对单个网关进行DDoS攻击——我们在这里介绍了这一点——但这可以通过使用以下任一方法来避免：
Arweave Multihost为应用程序提供一种在出现故障时切换到备份网关的方法
像Vatex这样的工具可以为你的项目启动专用网关。
Meson网络。作为Arweave支持的CDN和全局缓存层的一部分，Meson提供了超过40,000 个节点的功能。
