12 · 系统架构设计：把全部模块组装成一套套利平台（★★★★★）

结合你的优势收官。这不再是脚本，是一套真正的套利平台。与 11-量化套利系统.md 强绑定： 那篇讲"每个环节做什么"，本篇讲"这些环节怎么落地成具体的服务、怎么互相通信、 怎么组织成一套能长期维护迭代的系统"——这正是"系统架构师"这个身份区别于"脚本作者"的地方。

0. 一句话本质

系统架构的价值不在"能不能跑一次套利"，而在"这套系统能不能被安全地扩展、 被独立地维护、在某个模块出故障时不至于全盘瘫痪"。把 12 个知识模块组装成下面这张架构图， 你得到的不是一个脚本，而是一个可以持续迭代、可以复用给下一个策略的基础设施。

1. 整体架构图 

                                Dashboard
                                    │
                    ┌───────────────────────────────┐
                    │                                │
             Strategy Center                  Wallet Center
                    │                                │
              Price Engine                Cross-chain Manager
                    │                                │
              Risk Engine                  Position Manager
                    │                                │
               Executor                  LayerZero Module（等跨链模块）
                    │                                │
             Event Listener                Mempool Listener
                    │                                │
              RPC Cluster                  Database Cluster

这已经不是脚本，而是一套真正的套利平台——每一层职责单一、可独立扩展、可独立故障隔离。

2. 各模块职责与对应知识模块

架构组件 职责 对应知识模块
Dashboard 人机交互层：策略盈亏可视化、手动干预开关、日志查询、告警展示 11-量化套利系统.md §1.11 监控
Strategy Center 策略注册、参数配置、启停控制、多策略并行调度 07/08/10（策略逻辑本身建立在这些知识上）
Wallet Center 密钥管理、多账户/多链地址管理、nonce 协调、签名服务 05-钱包与账户.md
Price Engine 价格聚合、路径搜索、利润计算 11-量化套利系统.md §1.2-1.4
Cross-chain Manager 桥路由选择、跨链消息状态跟踪、库存再平衡 09-跨链生态.md
Risk Engine 仓位限额、滑点保护、熔断机制 11-量化套利系统.md §1.7
Position Manager 跨链/跨协议头寸统一记账、盈亏归因 06（ERC4626 等资产记账标准）、08（DeFi 头寸类型）
Executor 交易/Bundle 构造与提交、gas 定价、提交渠道选择 10-MEV.md、03-EVM原理.md（ABI 编码）
LayerZero Module（跨链执行模块） 具体跨链协议的适配层（消息发送、状态查询、失败重试） 09-跨链生态.md §1 生命周期
Event Listener 订阅链上事件（Swap/Sync/Transfer等），转化为结构化市场数据 04-Solidity进阶.md §8、01-计算机基础.md（WebSocket）
Mempool Listener 监听待处理交易，发现抢跑/backrun/清算机会 10-MEV.md、01-计算机基础.md
RPC Cluster 多节点/多链 RPC 接入层，负载均衡与故障切换 01-计算机基础.md §1
Database Cluster 持久化行情历史、交易记录、策略参数、告警日志 11-量化套利系统.md §1.10 日志

2.1 为什么要这样分层：三条架构原则

  1. 单一职责：Price Engine 只管算价格和路径，不管执行；Executor 只管把决策变成交易，不管判断 要不要做这笔交易——这样任何一层出问题（比如 Price Engine 算法要迭代），不需要动 Executor 的代码。
  2. 故障隔离：RPC Cluster 某个节点挂了，不应该让 Strategy Center 崩溃，只应该触发"切换到备用节点"； Cross-chain Manager 某条桥出问题，不应该影响单链套利策略继续运行。
  3. 可观测性贯穿全层：Dashboard 不是"最后加上去的功能"，而应该从设计第一天就规划—— 每一层都要暴露健康状态、关键指标，供 Dashboard 统一展示（呼应 evidence-first 精神）。

3. 数据流走一遍：一次完整的套利决策

  1. Event Listener 订阅到某个 DEX 池子的 Sync 事件，价格发生变化。
  2. Price Engine 更新内部价格图，触发路径搜索，发现一条正利润路径。
  3. Risk Engine 检查该路径是否超过单笔仓位限额、当前是否处于熔断状态。
  4. 若通过风控，Strategy Center 确认该策略处于启用状态，触发执行请求。
  5. Wallet Center 提供签名服务，Executor 构造交易/Bundle。
  6. 若涉及跨链，Cross-chain Manager 决定走哪条桥，LayerZero Module（或其他跨链模块） 负责实际的消息发送与状态跟踪。
  7. 交易提交后，Executor 监听执行结果；成功则更新 Position Manager 头寸记录； 失败则触发失败回滚逻辑，写入 Database Cluster。
  8. 全程关键事件推送到 Dashboard，异常触发告警。

4. 前置名词小词典

  • 故障隔离（Fault Isolation）：架构设计上让某个组件的故障不会级联影响其他组件。
  • 单一职责原则（Single Responsibility Principle）：每个模块只负责一类明确的功能。
  • 可观测性（Observability）：系统对外暴露足够信息，使得外部能推断内部状态（日志/指标/追踪三支柱）。
  • 头寸归因（Position Attribution）：把盈亏拆解到具体策略/具体交易，供复盘分析。

5. 常见误区

  • ❌ "先写脚本能跑就行，架构以后再说" → 早期技术债会在系统规模变大后成倍偿还， 尤其密钥管理和风控这两块，从一开始就该独立设计而非事后补丁。
  • ❌ "所有逻辑写在一个大脚本里更简单" → 短期简单，但任何一个环节的 bug 都可能拖垮整个进程， 且无法针对单一模块做灰度发布/独立回滚。
  • ❌ "Dashboard 只是给老板看的" → Dashboard 首先是给你自己在深夜排障时用的， 设计时应以"故障时能不能 5 分钟内定位问题"为核心目标。
  • ❌ "多链就是把单链代码复制 N 份" → 多链场景下 RPC Cluster、Cross-chain Manager、 Position Manager 都需要"原生多链感知"的设计，简单复制会导致每条链的状态互相不可见、无法联动决策。

6. 与终极目标的对应 / 自检问题

对应：本架构正是 00-总览与成长路线.md §4 "终极目标"中五大组件 （数据采集中心/行为分析引擎/策略实验室/自动执行机器人/AI 辅助分析模块）的工程落地骨架。

自检（回答完这四题，说明你已经具备"系统架构师"而不只是"脚本作者"的视角）：

  1. 如果 Price Engine 判断错了一次机会导致小额亏损，架构上应该怎么设计使得这不会传导成"执行层大额亏损"？
  2. 为什么 Wallet Center 要作为独立模块，而不是让每个策略自己管理私钥？
  3. 一条链的 RPC 集群整体宕机 10 分钟，你的架构应该表现出什么行为（而不是整个系统一起挂掉）？
  4. 如果未来要接入"AI 辅助分析模块"，它应该消费架构图里哪些组件产生的数据？

── Q&A / 更正记录区（按日期追加）──

原始讨论记录见 Q&A/（按日期归档，保留完整来回过程）；本节是同步后的结论摘要， 只增不删——若后续发现本篇正文表述不准确，按更正记录追加在此，不删改正文， 保留"原来写的是什么 → 后来发现哪里不准 → 更正为什么"的轨迹。规范见 Q&A/README.md。

  • (2026-07-26 建立。暂无 Q&A——后续围绕本篇的提问/质疑/更正在此累积。)