DApp 基础设施设计：借助 Kubernetes、Docker 和 Parity 实现可靠的以太坊事件跟踪

本文最初发表于Hacker Noon博客，经原作者 Carlo Las Marias 授权由 InfoQ 中文站翻译分享。

学习 Solidity 并编写智能合约相对来讲是比较容易的，但是我们发现更加困难的技术挑战在于设计安全、可扩展和简洁的 DApp 后端基础设施。与传统的应用不同，DApp 依赖于区块链的状态，而该状态有内在不确定性，DApp 所使用的以太坊组件相对比较新，而且处于活跃的开发状态中。

对于在以太坊上开发 DApp 的人来说，最早得到的教训之一就是在智能合约中记录事件是报告状态变更和跟踪行为的有效方式。事件是在区块链上发布的并且可以重播，而从技术上将它们并不适合存储在昂贵的区块状态中（即内存和存储），对于区块链数据的“存储”来说，这是一种节省成本的有效方案。同时，事件是实时发布的，允许实时发现和报告所进行的操作。

不过，对于 DApp 开发者来说，早期可能发现的另外一个潜在教训就是事件监控是不可靠的：事件只有能够被 DApp 在需要的时候探测到，它才有用处。如果你需要实时数据，但是事件发现延迟了，或者完全丢掉了事件，那么这可能会造成糟糕的用户体验或 DApp 的完全失败。

我们的解决方案：DApp 开发人员如果需要可靠的事件跟踪的话，那么应该考虑将 Kubernetes/Docker 添加到他们的工具集中。尽管这些技术有一定的学习曲线，但是很好地解决了目前以太坊生态系统中的一些特定问题，这些主要是由可靠性所导致的。

当前以太坊基础设施技术的问题

在CryptoBaskets，我们在以太坊基础设施和可靠性方面开展了大量的实验和研究，以支撑我们的产品。除了运行本地节点之外，我们还使用过不同的云厂商，如 AWS、Google Cloud 和 Digital Ocean 来托管节点。我们搭建了节点监控器，它能够跟踪节点的性能和可靠性，如示例截图所示。

因为我们的项目需要尽可能接近实时的事件跟踪，所以必须形成解决当前以太坊基础设施问题的方案：

1. 以太坊节点的 peer 数量持续下降：基于各种原因，以太坊节点会阶段性出现故障，它们要么会停止同步，要么会出现延后，从而导致无法获取最新的区块链信息。导致这一点的原因在于 peer 数量的下降（drop in peer count），这是任意节点的死亡之吻。peer 数量的下降可能会在任何时间发生，这通常由于某个节点卡在一个“坏”块上了，这个块被重新组织或最终落在了一个侧链上。以太坊节点的运行方式类似于流行的儿童桌（kids’ table），如果节点最终位于一个坏块上，那么你的节点会被列入黑名单或被污染，所有的 peer 都会丢弃它并且不会进行重连。

2. Infura websocket 不稳定：Infura提供了 websocket 连接的功能，以支持事件跟踪。这为开发人员提供了跟踪事件的能力，而且不需要运行自己的节点。尽管这比根本不支持事件有了很大的改善，但是这依然不是一个完美的方案。Infura 的 websocket 无法提供持续的连接，每隔几分钟连接就会断掉。使用第一个版本的Augur桌面客户端的开发人员，会使用 Infura 来构建和维护 Augur 相关事件的数据库，他们可能已经发现了这种现象。

3. 使用watch()监视实时事件可能会丢掉事件：节点在同步的时候经常会出现延迟，会落后几个块。造成这一点的主要原因在于硬盘驱动的读取/写入速度。花费一定的成本换成高速的 SSD 驱动是一种可行的缓解方案，但是以太坊主网的数据库超过了 100GB，云托管的账单会随之暴涨。除此之外，这还没有解决 peer 节点数量下降的问题。如果你的节点出现了延迟并且在同步追赶的话，那么我们发现这样会错失实时的事件。

冗余和监控

一个能容错的以太坊事件监视方案应该能够探测到故障、进行分类，然后像什么事情都没有发生那样继续运行。如下是我们的设计：

1. 节点冗余：我们运行多个以太坊节点，每个都有附加的事件跟踪器，从而提供单节点或多节点故障/延迟时的冗余；

2. 事件重放：因为事件实时跟踪是不可靠的，所以我们循环事件监视器来进行事件重放，并且节点间的事件回放是交叉进行的。为了提升效率，我们采用菊花链（daisy-chain）的方式进行重放，我们会记住每次重放时当前块的编号，所以后续的重放会从当前的块号开始进行。

3. 事件聚合器：我们的事件监视器会将事件报告给一个中心化的事件聚合器。我们的事件聚合器会跟踪已经看到的事件，并将新发现的唯一事件转发给不同的服务，这些服务需要处理该事件。

我们最终形成的架构如下所示，在下面的内容中将会讨论各个组件：

为何要进行 Docker 化？

对我们的应用来讲，使用 docker 的收益在于能够很容易地添加需要访问区块链的额外服务，我们只需要启动新的能够连接 parity 实例即可。每个容器是独立运行的，所以变更、功能添加和升级都可以在不影响其他已有容器/服务的情况下完成。

在上面的样例中，我们只有三个连接 parity 数据的容器：1）节点监视器；2）针对 App 1 的事件监视器；3）针对 App 2 的事件监视器。但是，我们可以很容易地在需求变化的时候添加更多的容器。

为何要使用 Docker 化？

在管理多个节点集群（以太坊客户端以及它们所连接的服务）时，很快就会变得非常复杂和混乱。这些服务不仅会互相连接和依赖，更新和管理配置、管理 secret（比如 API key）都需要进行协同，并且会带来潜在的安全漏洞。除此之外，在规模不断增大的系统中，监控服务器和服务的故障并重启出现故障的容器都会变得很有挑战性。而这就是 Kubernetes 能够发挥作用的地方了，它处理了所有的这些问题。

如下是我们发现最有用的特性：

Replica/扩展：Kubernetes 对于实现冗余来说非常棒，因为它内置了可扩展性。你可以按照默认的用法自动化地生成集群节点的副本（以太坊客户端及其关联的服务），也可以通过一个简单的命令行指令来实现。这个过程中，不需要单独配置每个集群。

添加新服务：你可以很容易地添加新的服务和需要访问以太坊节点的跟踪器，只需要在 Kubernetes deployment 或 stateful set 中添加新的容器即可。

通过 Stateful Set 实现的 Persistent Volumes：docker 容器本质特点就是短暂存活的。对于以太坊节点同步功能来说，在节点出现故障并重启的时候，我们并不想要同步一个超过 100GB 的数据库。Kubernetes 能够允许我们创建 Persistent Volumes，它是一个聚合数据存储，会维护其数据和存储。如果你的以太坊节点重启的话，它会重新连接至 Persistent Volume，并从上次停止的位置开始恢复其数据。

安全性：使用 Kubernetes secret 是存储 API key 和其他敏感数据的一种很整洁的方法。敏感数据只有在 secret 创建的时候会被暴露，一旦 secret 创建完成，它就会进行加密。secret 可以作为 volume 挂载到任何需要访问它的容器上。而原始的、非加密的数据则没有必要进行共享了。

IPC 连接增加了安全性和访问控制：服务进行集群化并提供对共享 volume 的访问功能（比如 Persistent Volume）之后，需要连接 parity 的服务可以借助集群的文件系统通过 IPC（inter-process communication，进程间通信）的方式进行访问。这种方式会防止对以太坊客户端的未授权访问，从而增加安全性。默认情况下，大多数开发人员会使用 RPC（remote procedure call，远程方法调用）连接 web3 provider，这会通过互联网发起web3.httpProvider() HTTP 连接。与 IPC 连接不同，RPC 连接可能会对公众或互联网开放，这会带来未授权用户发现并连接你的 RPC web3 provider 的风险，这有可能会导致你的客户端过载。在最糟糕的情况下，有人会在互联网上通过 RPC web3 使用不经意破解的账号发送事务。

存活状态和就绪状态的探针：Kubernetes 允许我们创建监视器，这种监视器能够将出现故障或未就绪的 pod 进行重启或从服务中清理出去。例如，我们可以使用就绪状态的探针，防止以太坊客户端在完全同步之前就接受任何传入的请求。

实时、滚动式更新/无停机：在为已存活的应用部署更新时，kubernetes 会在销毁旧的已有 pod 之前创建新的 pod。在新的 pod 创建和准备好之前（等待就绪状态探针），已有的 pod 会继续提供服务。只有当更新的 pod 准备就绪并能够提供的时候，旧的 pod 才会销毁。

Nginx ingress 控制器：Kubernetes 允许我们使用 Nginx ingress 控制器将流量转发给集群中不同的服务，它会根据 URL 地址进行路由。在你的域管理器中，只需要将所有的子域转发给 ingress 地址，所以在服务的 IP 地址发生变化的时候，你无需对它们进行单独的管理。Nginx ingress 控制器还会管理 HTTPS 路由和 TLS 证书。在 DApp 生态系统中，它还可以用来为前端应用创建 web3 provider。默认情况下，以太坊客户端只提供了非安全的 http 连接。

Parity 与 Geth

尽管 Parity 之前有过失误（参见Multi-Sig漏洞和库的漏洞），但 Parity 的一项成就就是创建了一个稳定的以太坊客户端（我们暂时先忽略共识漏洞）。尽管大多数开发人员在开始会使用以太坊的 Go 实现“Geth”，但是稍微使用 Google 或 stack exchange 搜索一下就会发现很多 Geth 同步相关的令人沮丧的问题。在实践中，我们发现 Geth 节点需要耗费更多的时间来进行同步，通常要比 Parity 节点更慢（在上面的节点监控仪表盘中，你甚至可以看到这一点）。另一方面，我们发现 Parity 节点会从头开始同步并且在几个小时到一天的时间内可用。

作为相对比较新的技术，像 Parity 和 Geth 这样的以太坊客户端技术在不断更新和改善，这也是我们为何维护两种类型节点的原因。

结论

去中心化的应用的前景很光明，但是考虑到它们的技术栈的重要性，大量的后端工作是必要的，以使在响应性和可靠性方面达到像集中式 web 和移动应用程序一样的效果。幸运的是，我们发现了一种严谨的架构设计方法使这一切能够得以实现，