Web3 应用的后端架构与 Web2 完全不同，主要原因是 Web2 后端的部分组件被区块链网络取代。

Web2 时代

一款 Web2 应用大致可以抽象成 3 部分组成，即：

1. 前端代码：用于定义 UI （ User Interface-用户界面）逻辑；例如刷 Twitter 时向下滑动屏幕，就会触发刷新。
2. 后端代码：用于定义业务逻辑；例如转发 Twitter 时，该内容就会被同步到我们自己的主页里。
3. 数据库：用于存储数据；例如我们发布的每一条内容，收到的每一个点赞都会被存储在数据库里。

这个抽象后的架构如下图所示：

现在我们把这三层架构串起来：当你刷到一条感兴趣的 Twitter 并随手点赞时，前端收到了这个动作并告诉后端，后端根据代码规则明确了点赞后需要给该内容+1赞，并告诉数据库记录这件事。数据库完成记录后报告后端，后端再报告前端，前端页面上的小红心就被点亮了。

这就是 Web2 应用高度抽象后的运作方式。

Web3 时代

Web3 应用后端的架构发生了巨大变化，主要是因为数据库和后端代码被改变了。

1. 数据库：Web3 去中心化的区块链网络取代了 Web2 中心化的数据库，大量价值数据被存储在区块链上。这些数据任何人都有权利访问或者利用。
2. 后端代码：Web2 规定了业务逻辑的后端代码也被链上协议和智能合约代替，这些代码均被公开，并且有非常大的可互操作空间。
3. 
   

这样一来，Web3 应用的架构就变成了前端和区块链网络直接交互，其中区块链网络承担了定义业务逻辑、以及存储数据的任务。

这里可以简单展开一下智能合约（定义业务逻辑）在区块链网络的运行方式。以以太坊为例，智能合约通过以太坊虚拟机（EVM），在多种操作环境下，按照相同的共识进行数据计算和处理；然后这些数据被打包进区块永久存储在链上。这一切都是去中心化的，不受任何单一实体的左右。

现在我们已知的 Web3 应用的架构可以抽象成下图的样子。

现在我们假设 Twitter 是一款 Web3 应用，来场景化的梳理一下它的运作方式：

首先 Twitter 的后端工程师写智能合约规定了点赞相关的业务逻辑，并将该智能合约部署上链。当你为某个内容点赞时，前端直接调用 Twitter 部署在链上的智能合约，智能合约自动判定为该内容增加一个赞；然后这条数据和其它数据一起被打包进一个区块，被永久存储在区块链上。最后前端收到数据已成功上链的反馈，点赞的小红心被点亮。

这就是 Web3 应用高度抽象后的运作方式（为了便于理解，这里忽略了很多细节）。

Web3 前端如何实现与区块链网络交互？

前面聊到，Web3 应用前端可直接与区块链网络交互，以便调用链上智能合约实现业务逻辑。与链交互是一款 Web3 应用是否能够正常运行的关键点，那么该如何实现呢？

答案是通过节点实现与链交互。

区块链网络依靠众多节点来实现自由访问和去中心化。每个节点都保存着一份链上状态的副本，包括每个智能合约的代码和数据。同样每个节点都有权利发起链上交易，这些发起的交易随后将被矿工确认并同步给其它节点。与链交互可以分为发起交易（写数据）或索引数据（读数据）两个场景，无论哪个都需要通过节点来实现。

目前主流的实现方式有两种：

1. 自己建立和运行节点
2. 使用第三方提供的节点服务

这两种方式有什么差异呢？

我们可以把第三方服务类比为 Web2 的云服务，而自建节点就像是使用传统的物理服务器。选择自建节点可以确保团队对节点运行状况的完全掌控，代价就是需要投入大量的资源和时间。例如：

1. 通常需要组建一个专业团队专注于解决这个问题，至少包含后端工程师和运维工程师。
2. 自建节点依然需要购买云服务来解决存储和计算，这并不便宜。
3. 拿以太坊来说，新建一个归档节点通常需要一周以上的时间以完成历史数据的同步。
4. 单节点基本无法满足业务需求，运维一个多节点集群需要解决数据一致性等诸多问题。
5. 如果业务需要支持多链，则以上工作量会重复叠加（不同公链的技术栈也各有差异）

第三方服务商的本质是一支专业团队运营了一组非常庞大的节点集群，他们负责解决上述问题并将这些节点以 API 的形式提供给项目方使用。这类服务往往是支持多链的，并配套各种运维组件。

在云服务为主流的当下，例如银行的核心业务依然需要使用私有化的物理服务器；Web3 部分领域也需要自建节点确保业务安全。但是在绝大多数场景下，使用第三方服务是性价比最好的解决方案。

我们现在已知的 Web3 应用的运行架构如下图所示

发起交易需要签名确认

我们通常把向链上写数据这个交互动作，称之为“发起交易”。

当 Web3 应用通过节点（无论是自建或是使用第三方服务）连接到区块链网络之后，我们可以自由读取存储在链上的数据。但是如果想要写入数据，则需要在发起交易前使用“私钥”进行签名确认。

你一定经历过钱包被唤醒并让你签名的场景。

公钥和私钥涉及“非对称加密学”原理，这里不做过多解释。普通用户可以极为抽象的将“私钥”理解为个人在区块链网络的终极身份证明（这也是为什么私钥不可外泄）。而例如 MetaMask 就是一种密钥管理工具，它将私钥存储在浏览器中，所以你需要发起交易时，它会被唤醒并让你点击签名。

以 Web3 版本的 Twitter 为例，当我们为一条内容点赞时，如果点赞这个行为需要被记录在链上，那么你在前端点赞后，应用需要唤醒钱包并让你额外签名确认。只有通过钱包签名后，这次交易才会被发起。

至此，Web3 应用的运行架构成为下图的样子：

去中心化的存储解决方案

把大量数据直接存储在区块链网络上，成本非常高（Gas费）。所以通常我们不会把所有数据上链，这时就需要另外的分布式存储方案。

例如 IPFS 或者 Swarm 就是这类解决方案。

它们均是链下的存储方案，虽然没有把数据存储在链上，但是依靠对等的分布式文件系统，避免了中心化数据库的垄断性，实现了所存数据不可被中心化的篡改。特别需要说的是，有些应用甚至会把前端代码存储在 IPFS 或者 Swarm 上，以追求极致的去中心化。

所以现在我们的 Web3 应用架构变成了下图的样子：

使用区块链网络上的数据

我们刚才提到，“与链交互”可分为【写数据】和【读数据】两个场景。而从链上读数据的场景要远远大于往链上写数据。

回想我们使用 Twitter 时看内容和发布内容的比例，就可以理解这一点了。（况且写数据需要支付 Gas 费，而读数据是免费的）

但恰恰是【读数据】这个更大的场景，门槛要比【写数据】高出很多。因为区块链网络是一个分布式的账本，每个区块打包的交易都是不同的（全球用户发起的交易按固定的时间周期被记录，那么每份记录的内容肯定都不同），这种数据特性被称之为“链表式结构”。链表式的数据无法被直接使用，我们需要先对链上数据进行解码和结构化，然后再开发 API 对数据进行查询和索引。

另外不同的业务场景对于数据的需求也不同，解码出来的数据通常不是都有用的，这时还需要工程师根据自己的需求对数据进行清洗加工。

1. 对标准协议解码：如 ERC20、ERC721、ERC1155 都是常用的标准协议；
2. 对智能合约解码：因为不同的工程师和业务逻辑，智能合约往往是是非标的；
3. 对数据进行清洗加工：根据业务需求剔除冗余，筛选出有价值的数据；
4. 对数据进行结构化处理：将链表式数据库转变为结构化数据库之后才能被查询和索引。

和节点一样，【读数据】这件事也有团队提供第三方服务，通常以 API 为交付形式，这点我们最后再说。

下图是我们现在探索到的 Web3 应用架构：

有时我们依然需要服务端

Web3 应用并不是所有的数据和后端代码都会上链；因为在链上存储数据或者部署智能合约都需要成本，并且公链有很大的性能限制。

同样也不是所有的项目都需要把剩余的链下数据存储在分布式存储系统中，分布式存储远没有中心化数据库成熟，这可能会牺牲用户体验、极大提高研发和运维成本。

所以大多数应用依然保留了自己的链下数据库和后端代码，只将最核心的业务上链。例如规定项目核心业务逻辑的智能合约、用户的核心资产这些一般会上链，而 NFT 项目往往会选择把图片部分存储在分布式网络上以提高可信度。

至于不那么核心的功能逻辑和其它数据，使用 Web2 的方式构建一个服务端依然是一种普遍选择。例如 Web3 的社交类工具很少见将聊天信息存储上链的（碍于成本、体验和隐私保护），又例如 GameFi 普遍只将涉及用户资产的部分上链，而不是把整个游戏的前后端、数据库全部搬到链上。

构建一个服务端处理非核心价值的数据和业务逻辑，可以最大化的兼顾用户体验和研发运维成本。

如下图所示：

很多时候我们需要支持多链生态

Web3 目前是多链生态，且这种格局可能会长期存在。

项目方往往选择一条链作为主链，但也要兼顾支持其它链，这样才能最大化的覆盖用户群体，提高用户体量上限。偏平台类的应用更需要支持多链，否则数据不完整，可用性会大打折扣。

区块链不可能三角是一个公认的概念。即【去中心化】【可拓展性】【安全性】三点最多可以兼顾其中两点，形成了三元悖论。不同的公链其实就是围绕这三个点的侧重、取舍不同，所以各个公链的技术栈会略有差异，EVM 和 non-EVM 之间的差异更大。

当我们需要支持多链的时候，研发工作和运维成本几乎是成倍叠加的；每新支持一条链，往往需要把之前的工作流程重新做一遍。

现在我们得到的 Web3 应用架构图，已经是一个抽象但相对完整的样子了。

目前可用的第三方解决方案

将前面的内容串起来，当构建一款 Web3 应用时，我们可能需要做：

1. 写智能合约规定核心业务逻辑并部署上链
2. 根据需求使用分布式存储
3. 支持如 MetaMask 等工具方便用户确认交易
4. 搭建并运维节点集群实现与链交互
5. 根据需求解码链上数据，并进行清洗加工
6. 根据需求建立链下服务端，将数据结构化以便支持更高效的查询和索引
7. 开发 API 以支持前端调用
8. 支持多链

我们可以看到这些工作大多数指向了应用与区块链交互的环节。实际上自建解决方案相当于项目方为自己搭建基础设施，这需要耗费大量的时间和资源。用户并也不会因为基础设施搭的好而选择一款产品，他们更关注产品本身解决了什么问题。所以自建基础设施是一种高投入低回报的选择。

当然你也可以通过使用第三方服务，来解决与链交互的问题。例如 Chainbase。

Chainbase 是一个 Web3 交互层基础设施，提供多链数据和节点 API，同时支持开发者自己写 SQL 生成自定义 API。这种解决方案可以最大化的降低 Web3 应用访问和利用区块链网络的门槛，把宝贵的资源专注于产品本身的构建工作当中。

这时我们的 Web3 应用架构被极大的简化了：

结论

对于 Web3 从业者，无论是否是技术成员，都应该对 Web3 应用的后端架构有最基础的认知。除了工作上的需要，更因为这些特性恰恰是很多 Web3 思想的技术基石。

搞清楚 Web3 应用的后端技术栈，即便是成熟的工程师也往往需要数周甚至数月的时间。如果没有技术基础，这个过程甚至可以说是痛苦的。希望这篇内容能够搭建一个大概的框架，提高大家的学习效率。

如果你有任何相关疑问，或者发现任何纰漏，请随时联系我。

责任编辑：Felix