Skip to content
DEX 设计
本文档介绍去中心化交易所（DEX）的技术架构设计，涵盖聚合询价、拆单算法、数据同步、高可用等核心模块。
一、概述
1.1 背景
基于链上流动性，提供一套类似中心化交易所的核心交易功能。相比中心化交易所：
| 对比 | 中心化交易所（CEX） | 去中心化交易所（DEX） |
|---|---|---|
| 流程 | KYC → 转入 → 交易 → 提币 | 连接钱包 → 交易 |
| 币对数量 | 有限（需上币审核） | 更多（池子即币对） |
| 资产托管 | 平台托管 | 用户自持 |
| 跑路风险 | 存在 | 不存在 |
1.2 目标
- 整体询价超越 1inch（结果和性能两方面）
- 提供稳定的询价 API 产品
- 交易成功率达到 99% 以上
二、核心概念
2.1 AMM（自动化做市商）
AMM 是 DEX 的核心交易方式，与传统订单簿模式不同。
恒定乘积做市商（CPMM）：x * y = k
示例：池子有 3 个 A 和 9 个 B（k=27），用户用 0.5A 兑换 B：
| 步骤 | 计算 |
|---|---|
| 池中 A 变为 3.5 | B = 27 / 3.5 = 7.714 |
| 用户得到 B | 9 - 7.714 = 1.286 |
| 兑换比例 | 0.5 : 1.286 = 1 : 2.571（原价 1:3） |
| 滑点 | 约 16% |
AMM 类型：
| 类型 | 公式 | 代表 |
|---|---|---|
| 恒定乘积（CPMM） | x × y = k | Uniswap V2 |
| 恒定总和（CSMM） | x + y = k | — |
| 恒定平均值（CMMM） | (x × y × z)^(1/3) = k | Balancer |
| 混合型（CFMM） | 恒定和 + 恒定积结合 | Curve |
2.2 聚合 Swap
聚合某条链上各个 DEX，为用户找到 A→B 兑换的最优路径。
核心优势：通过拆单分散到多个 DEX 获取更优价格。
示例（卖 3 ETH 换 USDT）：
| 方式 | 结果 |
|---|---|
| 单一交易所（币安） | 1×790 + 2×780 = 2350U |
| 聚合 Swap（多所拆分） | 1×800 + 1×780 + 1×790 = 2370U |
聚合器还支持多跳路由：如 ETH→USDT→BTC 可在链上一步完成。
2.3 关键术语
| 术语 | 说明 |
|---|---|
| 颗粒度 | 拆单的最小比例单位（如 5% 颗粒度） |
| 二级拆单 | 一级 10% + 二级 5% 的粒度优化 |
| 跳转次数 | A 兑换 D 的路径步数（如 A→B→D 为 2 跳） |
| Base 币 | 深度好的主流币/稳定币，作为路由中间币 |
三、业务架构
3.1 业务数据流转
sequenceDiagram
participant C as Client
participant B as DEX-Backend
participant Ch as Chain
C->>C: 1. 连接钱包
C->>Ch: 2. 授权
C->>B: 5. 用户下单
B->>C: 6. 组装 calldata 用户签名
C->>Ch: 7. 签名上链
B->>B: 3. 封装 calldata 签名上链
Ch->>B: 4. 结果推送
B->>C: 8. 结果推送
3.2 询价数据流转
graph LR
Chain["链上数据"] -->|"池子深度监听"| DTS["DEX-DTS<br/>数据同步"]
DTS -->|"落库"| DB["数据库"]
DTS -->|"推送数据"| Cache["DEX-ForCache<br/>前置缓存"]
Cache -->|"区间池子排序"| Consult["DEX-Consult<br/>询价服务"]
Client["Client"] -->|"询价"| Rest["DEX-Rest<br/>API 服务"]
Rest -->|"GRPC"| Consult
Consult -->|"询价算法计算"| Consult
四、关键设计
4.1 设计约束
| 约束 | 配置 |
|---|---|
| Base 币数量 | 有限制（非 Base 币种支持直接兑换） |
| 跳转次数 | 线上限制 3 跳 |
| 颗粒度 | 线上限制 5% |
4.2 协议接入
| 协议类型 | 代表 |
|---|---|
| 类 Uniswap V2 | SushiSwap, PancakeSwap, Uniswap V2 |
| 异构协议 | Balancer V1/V2, Curve V1, Uniswap V3 |
需要快速支撑不同协议和不同链的接入。
4.3 性能优化
- 线程池合理配置
- 协议算法优化
- 重复运算前置
- 准确性和性能之间的均衡选择
4.4 安全性保障
| 风险点 | 应对 |
|---|---|
| calldata 篡改 | 签名验证 |
| 池子数据同步错误 | 异常数据检测 |
| 协议翻译错误 | 多重校验 |
| 数据幂等性 | 时间 + 块高度控制 |
4.5 高可用设计
| 模块 | 方案 |
|---|---|
| 任务服务 | 2 台机器高可用 |
| 数据同步 | 2 台机器，Kafka rebalance 控制 |
| 询价服务 | 2 台机器轮询 + gRPC 负载均衡 |
| 前置缓存 | 3 台机器，抢占式任务 |
| API 服务 | 2 台机器高可用 |
五、架构
5.1 技术选型
| 层级 | 技术 |
|---|---|
| 存储 | Redis, MySQL |
| 消息队列 | Kafka, Redisson 队列 |
| 配置中心 | Apollo |
| 链交互 | Web3j |
| 服务通信 | Feign, gRPC |
| 监控告警 | Lark 报警, 系统监控 |
5.2 核心模块
graph TB
subgraph "数据层"
A["数据同步模块<br/>链上深度数据入库"]
B["路径缓存模块<br/>币种间路径计算"]
C["梯度缓存模块<br/>币对深度排序"]
end
subgraph "计算层"
D["询价系统模块<br/>SOR 拆单算法"]
E["分片计算"]
F["协议解析"]
end
subgraph "服务层"
G["API 服务"]
H["PMM 做市商"]
I["Limit Order"]
J["跨链交易"]
end
A --> C --> D
B --> D
F --> D
D --> G
H --> D
I --> G
J --> G
六、详细模块设计
6.1 数据同步模块
通过 Kafka 同步链上所有 DEX 的深度数据入库：
- 数据消费需要进行幂等处理
- 通过时间和块高度控制历史脏数据入库
- 支持启动同步加载
6.2 路径缓存模块
缓存两个币种之间所有可能的路径：
- 缓存主流币、稳定币之间的兑换路径
- 通过 Base Token 和路径层级控制缓存大小
- 添加/删除币种时路径需重新计算
- Curve 多币种池子（3/4 币种）需严格缓存顺序
6.3 梯度缓存模块
缓存与币对深度相关的数据：
- 每个 Pair 缓存最优 20 个（可配置）深度池子
- 池子深度变化时及时刷新
6.4 询价系统模块（SOR 拆单算法）
根据 fromToken 和 toToken 返回最优兑换结果。
扩展功能：
- 跨链交易：跨链 Swap 整体逻辑
- PMM（Private Market Maker）：做市商主动挂单/撤单，订单内存化方案
- Limit Order：限价单功能
总结
graph LR
A["链上深度数据"] --> B["数据同步 + 缓存"]
B --> C["路径计算 + 梯度排序"]
C --> D["SOR 拆单询价"]
D --> E["最优兑换路径"]
E --> F["组装 Calldata"]
F --> G["用户签名上链"]
DEX 聚合器的核心竞争力在于询价算法的准确性和性能。通过多协议聚合、多级拆单、路径优化，为用户在链上获取最优兑换价格。架构设计上需重点关注数据同步的实时性、询价服务的高可用、以及 calldata 的安全性。