主体通译自 the-architecture-of-a-web-3-0-application
看过前 2 篇文章，本瓜相信你对 Web3.0、DApp 已经有了一个基本的认识。
传送门：
本篇带来 DApp 设计架构浅析~
先来回顾下 Web2.0 应用程序架构，一图胜千言：
图示是对大多数 Web 2.0 应用程序如何工作的一个很好的抽象总结。以一个博客平台为例：
首先，必须有一个地方来存储基本数据，也就是数据库；
其次，要有后端代码（用 Node.js、Java 或 Python 等语言编写），用于定义业务逻辑；
第三，还要有前端代码（通常用 JavaScript、HTML 和 CSS 编写），用于实现 UI 和交互；
这些代码都托管在集中式服务器上。
视角来到 Web3.0 ，消除了中心化，没有集中式的数据库，没有存放后端代码的集中式 Web 服务器。采用了区块链技术，在互联网上的匿名节点维护的分布式 状态机 上构建应用程序。
“状态机”是指一台机器，它维护一些给定的程序状态、以及该机器上允许的未来状态，它具有非常严格的规则（即共识）来定义状态如何转换。
没有一个实体可以控制这个分布式的状态机 —— 它由网络中的每个人共同维护。
后端逻辑代码化身成状态机上的“智能合约”，这是开源的。
前端部分呢？暂按下不表，先看此时数据库、后端代码演变后的架构图：
再进一步看看这些新颖的概念：
- ethereum blockchain，以太坊区块链，被认为是“世界计算器”，一个可全局访问的状态机，对等节点网络维护，状态的更改遵循共识规则的约束；只要是写入了数据，就会被记录，数据不能再更新回去；
- 智能合约：以太坊上运行的程序，由高级编程语言编写，例如 Solidity 或 Vyper；
任何人都能检查智能合约是否合理；
- EVM 虚拟机，用于执行合约的环境，相当于执行引擎；
OK，视野来到了前端代码部分。按道理将，前端代码应该也是用智能合约的方式实现，实际上，它也确实如此，不过要更为复杂一点。
当我们想要与区块链上的数据和代码进行交互时，我们需要与这些节点中的一个进行交互。任何节点都可以广播在 EVM 上执行交易的请求，然后矿工将执行交易并将结果状态更改传播到网络的其余部分。
广播新交易有两种方式：
借助第三方节点可能会更轻松一点，它的逻辑是这样的：
每个以太坊客户端（即提供者）都实现了 JSON-RPC 规范。这确保了当前端应用程序想要与区块链交互时，有一组统一的方法。JSON-RPC 是一种无状态、轻量级的远程过程调用 (RPC) 协议，定义了多个数据结构及其处理规则。它与传输无关，可以通过多种方式传输，比如 HTTP、套接字、其它传输环境，JSON (RFC 4627) 作为一种数据格式。
还有一个很重要的东西，进行身份验证，鉴权。通常借助 Metamask 实现；
Metamask 将用户的私钥存储在浏览器中，每当前端需要用户签署交易时，它就会调用 Metamask。
将所有内容都存储在区块链上是很昂贵的，更新数据都需要收费，所以还有一个 去中心化的链下存储解决方案 —— IPFS/Swarm
架构图如下：
IPFS/Swarm 是用于存储和访问数据的分布式文件系统，你可以轻松去检验它。
到目前为止，我们已经讨论了如何写入，那如何读取数据呢？
答案是借助 The Graph，The Graph 是一种链下索引解决方案，可以更轻松地查询以太坊区块链上的数据。前端工程师可以直接调用，这比传统的 REST API 更具有吸引力。
现在，Dapp 架构如下：
截至目前，架构图已初成雏形。
引申补充，完整的实现上图这一架构，成本有点高昂。所以，有一种流行的扩展方案 —— L2 scaling 解决方案
在侧链操作，然后提交到主链。
这样既节约成本，又能达到目的，真是大聪明。
本瓜就把这个侧链执行，理解为代码的预编译吧，编译后再放到浏览器引擎上做真正的编译执行。
- 附：以上框架的开发工具是 Hardhat，有兴趣自行了解
本篇就是完整的“浅析 Web3.0 DApp（去中心化应用程序）设计架构”。
以上！作为入门级架构浅析，说的真的很通透了！三连了！👍👍👍
期待 Web 3.0 DApp 的开发~~ 欢迎留言评论。
我是掘金安东尼，输出暴露输入，技术洞见生活。
