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

摘要

本文分析了当前以太坊基础设施所面临的问题，讨论了如何借助Kubernetes和Docker实现可靠的事件跟踪，以及容器化技术的优势。

本文最初发表于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的事件监视器。但是，我们可以很容易地在需求变化的时候添加更多的容器。

为何要使用Kubernetes？

在管理多个节点集群（以太坊客户端以及它们所连接的服务）时，很快就会变得非常复杂和混乱。这些服务不仅会互相连接和依赖，更新和管理配置、管理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和移动应用程序一样的效果。幸运的是，我们发现了一种严谨的架构设计方法使这一切能够得以实现。