架构指南 - OpenZeppelin 文档

架构指南

本文档描述了 OpenZeppelin Monitor 的高级架构，包括核心组件、它们的交互以及整体系统设计。它提供了关于服务如何处理区块链数据并根据可配置的条件触发通知的技术概述。

系统概述

OpenZeppelin Monitor 被组织为一个数据处理流水线，从区块链数据收集到通知传递。该系统遵循模块化架构，监控过程的每个步骤都有不同的组件，专为可伸缩性和可扩展性而设计。

高级架构

下图显示了 OpenZeppelin Monitor 的核心处理流水线，从区块链网络和配置到通知渠道：

通知渠道

核心处理流水线

配置

区块链网络

Slack

邮箱

Discord

Telegram

Webhook

自定义脚本

BlockWatcherService

FilterService

TriggerService

NotificationService

网络配置

监控配置

触发器配置

EVM 网络

Stellar 网络

组件架构

系统由多个核心服务组成，这些服务在启动时初始化并协同工作以处理区块链数据和触发通知。服务初始化和依赖关系通过引导模块进行管理。

服务初始化流程

客户端层

核心服务

区块处理

引导

入口点

ClientPool

EVMClient

StellarClient

MonitorService

NetworkService

TriggerService

FilterService

TriggerExecutionService

NotificationService

BlockTracker

BlockStorage

BlockWatcherService

create_block_handler

Bootstrap::initialize_service

main.rs

核心组件

区块处理组件

• BlockWatcherService：通过轮询区块链网络以获取新区块并协调处理流水线，来组织区块监控过程。

• BlockTracker：跟踪已处理的区块号，以防止重复处理并确保服务重启时的数据一致性。

• BlockStorage：持久化区块处理状态以进行恢复，并维护每个网络的最后处理的区块号。

客户端层组件

• ClientPool：管理区块链客户端实例，并通过连接池和故障转移功能提供网络连接。

• EVMClient：处理与以太坊虚拟机兼容网络（以太坊、Polygon、BSC 等）的通信。

• StellarClient：管理与 Stellar 区块链网络的连接，并具有特定于协议的优化。

处理流水线组件

• FilterService：将监控过滤器应用于区块链数据，评估条件和匹配表达式以识别相关的交易和事件。

• TriggerExecutionService：根据匹配的监控条件执行触发器，评估触发器逻辑并准备通知有效负载。

• NotificationService：通过配置的渠道（Slack、Email、Discord、Telegram、Webhooks、Scripts）传递通知。

配置管理组件

• MonitorService：管理监控配置，并提供对具有验证和生命周期管理的活动监控的访问。

• NetworkService：管理网络配置，并为客户端连接和监控操作提供网络详细信息。

• TriggerService：管理触发器配置，并提供用于通知执行的触发器详细信息。

服务职责

下表描述了 OpenZeppelin Monitor 架构中每个服务的关键职责：

区块处理工作流程

以下运行时流程说明了数据如何在系统中流动，从区块链网络到通知渠道。此序列表示为每个配置的网络执行的核心监控循环。

NotificationServiceTriggerExecutionServiceFilterServiceBlockchainClientBlockStorageBlockWatcherServiceNotificationServiceTriggerExecutionServiceFilterServiceBlockchainClientBlockStorageBlockWatcherServiceOrchestrates block processingBlockchain interfaceApplies monitor filtersEvaluates trigger conditionsDelivers notificationsloop[For each block]Persists processing stateGet last processed blockGet latest block numberGet blocks (last+1 to latest)filter_block(block)Apply monitor filtersMonitor matchesProcess monitor matchesRun trigger conditionsExecute notificationsStore latest processed block

数据流架构

1. 区块发现阶段

BlockWatcherService 通过以下方式启动监控周期：

• 从 BlockStorage 检索最后处理的区块号

• 查询区块链以获取最新的区块号

• 计算要处理的新区块范围

2. 数据检索阶段

BlockchainClient 获取区块数据：

• 通过 RPC 连接到适当的区块链网络

• 检索完整的区块数据，包括交易和事件

• 处理特定于网络的数据格式和协议

3. 过滤阶段

FilterService 处理每个区块：

• 将特定于监控的过滤器应用于交易和事件

• 评估匹配表达式和条件

• 识别符合监控标准的相关数据

4. 触发器评估阶段

TriggerExecutionService 处理匹配项：

• 评估匹配数据的触发器条件

• 准备包含相关上下文的通知负载

• 确定要激活的通知渠道

5. 通知传递阶段

NotificationService 传递警报：

• 为每个通知渠道格式化消息

• 处理特定于渠道的传递协议

• 管理传递重试和错误处理

6. 状态持久化阶段

BlockStorage 更新处理状态：

• 记录最后处理的区块号

• 确保恢复场景的数据一致性

• 维护处理历史以进行调试

错误处理和弹性

该架构包括多种弹性机制：

• 连接池：ClientPool 管理多个连接以防止单点故障

• 状态恢复：BlockStorage 使服务能够在重启后从上次已知的良好状态恢复

• 重试逻辑：通知传递包括针对瞬时故障的可配置重试机制

• 优雅降级：单个组件故障不会级联到整个系统

有关 RPC 逻辑和网络通信的详细信息，请参阅 RPC 部分。

配置架构

系统使用基于 JSON 的配置系统，该系统组织成不同的类别：

配置类别

• 网络配置：定义区块链网络连接、RPC 端点和网络参数

• 监控配置：指定监控规则、条件和网络/触发器引用

• 触发器配置：定义通知设置和脚本定义

• 过滤器配置：包含用于数据过滤的匹配过滤器脚本

配置验证

系统实现全面的验证：

• 监控器、网络和触发器之间的交叉引用验证

• 所有配置文件的模式验证

• 服务启动期间配置引用的运行时验证

可扩展点

该架构旨在在几个关键领域实现可扩展性：

区块链支持

• 客户端层：可以通过实现 BlockchainClient 特征来添加新的区块链协议

• 传输层：特定于协议的传输客户端处理网络通信详细信息

• 过滤器层：链特定的过滤器处理依赖于协议的数据格式

通知渠道

• 渠道插件：可以通过实现通知接口来添加新的通知渠道

• 脚本支持：可以使用 Python、JavaScript 或 Bash 脚本实现自定义通知逻辑

监控逻辑

• 表达式引擎：灵活的表达式评估，用于复杂的监控条件

• 脚本触发器：可以使用支持的脚本语言实现自定义触发器逻辑

性能考虑

该架构针对以下方面进行了优化：

• 并发处理：可以同时监控多个网络

• 高效的区块处理：批量处理区块以最大限度地减少 RPC 调用

• 内存管理：流式处理大型区块以防止内存问题

• 连接重用：客户端池减少了连接开销

安全架构

系统实现了多项安全措施：

• 安全协议：支持 HTTPS/WSS

• 密钥管理：安全处理 API 密钥和敏感配置数据

• 输入验证：全面验证所有外部输入和配置

相关文档

有关项目结构、源代码组织和开发资源的详细信息，请参阅 项目结构 指南。

有关 RPC 逻辑和网络通信的信息，请参阅 RPC 部分。

有关配置示例和最佳实践，请参阅用户文档中的 配置指南 部分。

← 快速入门

项目结构 →

• 原文链接： docs.openzeppelin.com/mo...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～