Hummingbot Gateway 架构 - 第二部分¶

作者：Martin Kou

更新（2023 年 2 月）： Hummingbot Gateway v2 现已作为独立的 Github 仓库发布：https://github.com/hummingbot/gateway。本文中列出的大部分功能现已实现，我们欢迎社区贡献。

引言¶

在本系列的第一部分中，我们讨论了为提升 Hummingbot Gateway v2 的稳健性和可靠性而进行的架构调整，旨在使其达到生产级交易系统所期望的服务质量水平。

在本系列的第二部分中，我们将探讨与 Gateway v2 如何与您交互相关的架构变更。具体而言，我们将讨论将在首次用户体验以及社区开发者体验方面所做的改进。

用户体验¶

Hummingbot Gateway 是一个后端系统，理想的用户体验是易于设置，并能在后台稳定运行，让用户专注于交易。当用户需要重新配置或升级 Gateway 时，相关文档和说明应清晰明了，配置步骤也应简单易行。

Gateway v2 将带来一系列改进，使其用户体验更接近 Apache 或 MySQL 等主流生产服务器软件的标准。我们的改进将集中在以下几个主要方面：

• 使用 Hummingbot 设置 Gateway
• 独立设置 Gateway
• 配置 Gateway
• 用户文档

使用 Hummingbot 设置 Gateway¶

当前 Hummingbot / Gateway 的设置流程存在一些可用性问题：

1. 文档不足：目前没有连贯的指引说明用户如何开始在 Uniswap 上交易。
2. 流程复杂：用户必须先在 Hummingbot 中设置 SSL 证书，然后还需运行另一个脚本（Docker 部署方式）或手动填写 Gateway 配置（源码部署方式）才能使 Gateway 正常工作。
3. 几乎没有用户体验反馈：当 Gateway 启动后，Hummingbot 没有任何界面提示表明已连接到 Gateway。
4. 所有 gateway 命令均无 -h 帮助信息。

以下是我们在 Gateway v2 中计划增加的改进，以简化 Hummingbot 的设置流程并提升用户的可维护性：

1. 通过 Docker Compose 和其他设置脚本自动化 Gateway v2 的 Docker 部署流程。
2. 在 Hummingbot 官方文档网站上提供详细的、分步的操作指南，涵盖使用 Hummingbot 设置 Gateway 所需的准备步骤、安装步骤及相关配置说明。
3. 在 Hummingbot 客户端 UI 的顶部状态栏中添加 Gateway 状态显示，以指示 Hummingbot 是否已连接到 Gateway v2 实例。
4. 为 Hummingbot 中所有 gateway 命令提供帮助信息。

设置网关（独立模式）¶

目前尚无文档说明如何以独立方式设置网关，并将非 Hummingbot 客户端连接到该网关。由于独立网关需要非 Hummingbot 客户端，因此我们可以预期大多数需要此功能的用户为交易系统开发人员和系统管理员。

以下是我们在 Gateway v2 中计划新增的功能，旨在优化独立网关的设置流程。

1. 开发者阅读关于网关整体架构、如何设置以及如何连接非 Hummingbot 客户端的概览文档。
2. 开发者通过运行 gateway-create.sh 脚本设置网关，脚本将自动生成 SSL 证书（包括 CA 证书和密钥）。
3. 开发者使用 gateway-copy-certs.sh 脚本生成客户端证书。
4. 开发者使用客户端证书将自定义客户端连接至网关，并从客户端运行“Hello World”示例脚本（例如获取以太坊 Goerli 网络上 Uniswap 中的 WETH-DAI 价格）。
5. 开发者根据我们的网关 API 文档继续开发交易客户端。

配置网关¶

原始 Hummingbot 网关的配置系统存在几个主要的可用性问题：

1. 它向首次使用的用户暴露了过多可配置变量，增加了初始设置过程中的不必要障碍。
2. 首次使用的用户需要至少在两个地方进行配置（例如，在 Docker 设置中，首先需要在 Hummingbot 中创建证书，然后运行 create-gateway.sh）。
3. 它将所有连接器模块的默认配置都暴露在同一个全局配置文件中，导致配置不具备模块化特性。

维护 Hummingbot 网关用户友好配置集的需求，实际上与 Apache 或 NGINX 等 Web 服务器，或 NodeJS Web 应用程序的需求并无太大区别。我们应参考这些服务器如何管理配置集，而不是重新造轮子。

以下是几种重要场景下的理想用户操作流程：

1. Hummingbot / 网关设置：用户可以从 Hummingbot 中直接设置钱包，输入 Infura 密钥，并启动网关。
2. 独立网关设置：用户运行一个脚本来创建 SSL 证书，并自动将其集成到网关配置中，输入 Infura 密钥后启动网关。
3. 从 UNIX 命令行检查配置：用户可以编辑少数几个定义清晰、易于阅读的配置文件（例如，local.yml 用于本地设置如 Infura 密钥或节点 URL，ssl.yml 用于 SSL 证书和密钥短语文件路径等）。
4. 从 Hummingbot 中检查配置：用户可以使用 gateway list-configs 和 gateway update 命令。
5. 添加或开发新的连接器模块：开发者应能够在自己的模块文件中添加特定于该模块的配置，而无需修改全局配置。然而，模块特定的配置仍应在本地设置文件中可被覆盖，并可通过 Hummingbot 网关命令发现和写入。

我们将重构 Gateway v2 的配置系统，将配置文件拆分为多个文件，并使其更贴近 Apache 和 NGINX 等常见服务器软件的配置方式。

1. 保留不同连接器的默认设置，但不将其放在各自的模块目录之外，以实现模块化。
2. 移除全局配置文件，改用按用途划分的专用配置文件。
3. ssl.yml - SSL 证书相关配置。
4. ethereum.yml - 以太坊链级配置，例如使用哪个网络？Infura 节点 ID？
5. local.yml - 用户覆盖配置。
6. 提供一个包含示例配置文件的目录（例如 ./config/samples/），并在文件中以内联注释的方式说明每个配置项的含义。

用户文档¶

原始的 Hummingbot Gateway 提供了 Docker 和源码安装的安装说明，并讨论了一些 Hummingbot 中的 gateway 命令，但未明确说明。然而，文档并未清晰解释用户应在何时执行哪些步骤，以及为何需要某些步骤（例如生成 SSL 证书）。

文档也没有描述用户要使 Gateway 正常运行所需的最少配置项（例如以太坊节点 URL、网络类型等）。这意味着首次从源码编译的用户只能通过试错来使 Gateway 正常工作。总体而言，当前面向新用户的文档状态并不令人满意。

Gateway v2 的安装文档将大幅扩展，我们将确保文档内容顺序合理，并以连贯的方式为首次使用者提供引导。特别是，新的安装文档将明确说明准备工作（例如带有 Docker 的操作系统环境、以太坊节点 URL / Infura 账户等）以及使 Gateway v2 正常运行所需的最少配置集合。

开发者体验¶

Hummingbot 是一个开源项目。我们预计从长远来看，社区成员将主导大部分 DEX 连接器开发、功能请求和缺陷修复工作。

这意味着我们也必须考虑社区开发者角度的用户体验。例如，设想有人希望为 Hummingbot Gateway 开发一个新的 DEX 连接器——我们需要为此规划相关事项，如文档支持、社区协助、提出和添加新连接器的流程、我们的接受标准等。

开发者文档¶

文档通常是开发者在为项目添加新功能时首先查阅的内容。我们预计大多数开发者会对为项目新增 DEX 连接器感兴趣，因此我们将特别关注编写和测试新连接器的相关指引。以下是 Gateway v2 将包含的开发者文档类型概览：

快速入门：这部分内容应类似于上述“用户体验”流程中的初始设置文档，但重点是从源码而非 Docker 部署 Gateway。应包括以下内容：

设置与配置：

• 操作系统和工具链要求，例如 Linux / macOS、git、nvm、yarn 等。
• 从 Hummingbot 仓库克隆代码、yarn 安装步骤等。
• 为测试生成客户端 SSL 证书。
• 编辑配置文件（例如 Infura API 密钥）。
• 验证设置是否正常工作。
• Uniswap 和以太坊的最小化配置。
• 提供几个使用 curl 向网关发送 Uniswap API 请求（例如获取资产价格）的命令示例，以及预期输出结果。

添加网关连接器： 这将是专为希望开发新网关连接器的开发者准备的独立章节。代码讲解应涵盖在 Hummingbot 上运行 Uniswap AMM 策略时网关使用的主要逻辑路径。

需要注意和测试的事项： 编写一个“基本可用”、“偶尔可用”或仅在测试网中工作的 DEX 和区块链连接器相对容易。但新连接器的要求是必须具备高可靠性，并能有效应对各种故障情况。

• 列出 DEX 连接器常见的故障模式，例如网络中断、交易卡住、nonce 管理不当等。
• 列出连接器为获得我们认证所需通过的单元测试用例和测试环境，针对常见错误模式进行覆盖。

API 文档¶

包含 Gateway v2 中所有可用 API 端点的文档，包括参数输入、预期输出格式以及可能发生的错误。

反馈循环¶

社区开发者在成功运行第一个“Hello World”风格的 API 后，直到新连接器被 Hummingbot 团队批准并接受为止，都需要持续的指导。

除了社区反馈和讨论外，测试用例、文档和认证标准也能为开发者提供有效反馈，帮助其自我评估进度，确保开发方向正确。

Gateway v2 将提供以下文档和支持基础设施，作为社区开发者创建新连接器和新功能时的指导框架。

运行单元测试用例及与网关交互的操作指南

开发者最早获得代码反馈的方式之一通常来自测试用例，形式可以是单元测试或手动测试（例如使用 curl 并附带特定指令）。因此，关于如何使用和编写测试用例的文档将非常有用。

具体而言，Gateway v2 将提供以下与测试相关的文档：

• 如何运行 Gateway v2 代码中包含的单元测试用例；
• 如何编写新的单元测试用例，并将其加入测试套件；
• 如何使用 curl 进行手动测试，以及生成客户端证书的方法。

用于模拟常见边缘情况（如交易中断、交易失败等）的测试环境（test fixtures）

我们预计大多数新 DEX 连接器都将对接基于 EVM 的区块链——这意味着许多相同的故障模式会重复出现。因此，我们为测试 Uniswap 等以太坊 DEX 所构建的测试环境很可能可被社区开发者复用。

同样，关于如何复用和修改这些测试环境的文档对社区开发者也十分有价值：

• 列出 DEX 连接器常见的故障模式，例如网络中断、交易卡住、nonce 管理不当等；
• 介绍用于测试 EVM 故障模式的内置测试环境，及其在新 EVM DEX 连接器测试中的复用方法。

提交和认证新连接器的流程

Hummingbot 团队将建立并公布一套认证新 DEX 连接器的流程与标准。任何新 DEX 连接器都必须包含一组必需的测试用例，以确保其在面对常见错误场景时具备可靠性和容错能力。此外，还需通过我们的代码审查和质量保证流程，确保测试用例确实有效，且连接器能在我们的测试环境中正常运行。

社区交流渠道

Hummingbot 团队已设立 Discord 频道 *#dev-gateway-v2*，专供 Hummingbot 网关社区开发者使用。根据我们在 Hummingbot 项目中的经验，初期该社区频道需要 Gateway v2 开发团队的支持。随着越来越多社区开发者完成整个开发流程，他们将逐渐能够实现自助互助。

在 Gateway v2 首次公开发布后，我们将设立轮值“办公时间”安排，由 Gateway v2 开发团队成员定期在社区频道中回答社区提出的问题。

可用性与时间规划¶

更新（2023 年 2 月）：Hummingbot Gateway v2 现已作为独立的 Github 仓库发布：https://github.com/hummingbot/gateway。本文提到的大部分功能现已实现，我们欢迎社区贡献代码。

撰写本篇博客时，Gateway v2 仍处于原型阶段和预 Alpha 版本，因此我们的首要任务是构建一个可用于生产的架构，以扩展支持 EVM 兼容链上的 Uniswap 风格 AMM。

我们正在尽可能快地将本系列博客中详述的架构方案转化为实际代码。预计 Gateway v2 的首次公开版本将于 2022 年第一季度准备就绪，届时我们将开始接受社区的 Pull Request。

在此期间，我们欢迎开发者社区提供反馈。如果您对 Hummingbot Gateway v2 有任何建议，请随时在我们的 Discord 服务器中的 #developer-chat 频道给我们留言。

对于希望与 Gateway 集成的项目或交易所，请联系我们，以获取专属的 #gateway 频道访问权限，从而获得我们开发团队的技术支持。