cfdaily
343 lines
13 KiB
Markdown
343 lines
13 KiB
Markdown
# NAS 环境 sanguo_vnpy Web Trader 架构分析
|
||
|
||
## 需求背景
|
||
|
||
- 部署目标：NAS 机器上构建一套 sanguo_vnpy 环境
|
||
- 使用方式：多位将军协同开发，可进行回测、模拟交易、实盘
|
||
- 设计原则：**基础架构保持 vnpy 官方设计不变，只做必要功能扩展**
|
||
- 基础设施：NAS 提供存储和计算，多用户通过 Web Trader 访问
|
||
|
||
---
|
||
|
||
## 基于官方双进程架构在NAS上的适配分析
|
||
|
||
### 当前官方架构图回顾
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ 浏览器 / 前端 (各将军本地或通过NAS访问) │
|
||
└─────────────┬───────────────────────────────────────────────┘
|
||
│ HTTPS / WebSocket
|
||
↓
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ NAS机器: Web服务进程 (vnpy_webtrader) │
|
||
│ - FastAPI Web服务器 │
|
||
│ - REST API / WebSocket │
|
||
│ - RPC客户端 │
|
||
└─────────────┬───────────────────────────────────────────────┘
|
||
│ RPC (本地TCP)
|
||
↓
|
||
┌─────────────────────────────────────────────────────────────┐
|
||
│ NAS机器: 单一共享交易进程 │
|
||
│ - VeighNa Trader 核心 │
|
||
│ - RPC服务端 │
|
||
│ - 所有Gateway连接 │
|
||
│ - 策略运行 │
|
||
└─────────────────────────────────────────────────────────────┘
|
||
```
|
||
|
||
---
|
||
|
||
## 潜在问题分析
|
||
|
||
### 问题1：单一共享交易进程无法支持多用户隔离
|
||
|
||
**现状**：官方默认设计是 **单用户单交易进程**
|
||
|
||
在我们NAS场景：
|
||
- 多位将军同时使用同一个交易进程
|
||
- 账户、持仓、策略都混在一起
|
||
- 无法做用户权限隔离
|
||
- 一个用户出错可能影响所有人
|
||
|
||
**风险等级**：🔴 高风险
|
||
|
||
---
|
||
|
||
### 问题2：数据存储路径问题
|
||
|
||
**现状**：vn.py默认数据存在本地路径
|
||
|
||
在我们NAS场景：
|
||
- 数据库文件需要放在NAS共享存储，方便各进程访问
|
||
- 需要规划统一数据目录结构
|
||
- 需要考虑多进程并发访问SQLite的问题（如果用SQLite）
|
||
|
||
**风险等级**：🟡 中风险
|
||
|
||
---
|
||
|
||
### 问题3：进程管理与稳定性
|
||
|
||
**现状**：默认需要手动启停进程
|
||
|
||
在我们NAS场景：
|
||
- 需要后台稳定运行，不能随会话退出而终止
|
||
- 需要崩溃自动重启
|
||
- 需要方便查看日志、排查问题
|
||
- 需要系统级别的进程监控（systemd）
|
||
|
||
**风险等级**：🟡 中风险
|
||
|
||
---
|
||
|
||
### 问题4：网络访问路径
|
||
|
||
**现状**：默认仅本地访问
|
||
|
||
在我们NAS场景：
|
||
- NAS通常在内网，需要外网访问需要做好反向代理
|
||
- WebSocket需要特殊配置支持反向代理
|
||
- 证书问题（HTTPS）
|
||
|
||
**风险等级**：🟢 低风险，配置好即可解决
|
||
|
||
---
|
||
|
||
### 问题5：保持基础架构不变的边界
|
||
|
||
你说"基础架构我不太想改"，这里需要明确：
|
||
|
||
| 范围 | 是否属于"基础架构" | 是否需要改 |
|
||
|------|-------------------|-----------|
|
||
| vnpy核心MainEngine/EventEngine/RPC设计 | 是 ✅ | ❌ 不需要改 |
|
||
| vnpy_webtrader的FastAPI+REST+WebSocket设计 | 是 ✅ | ❌ 不需要改 |
|
||
| 多用户进程模型（单进程vs多进程） | 不属于基础架构，是部署架构问题 | ✅ 需要适配 |
|
||
| 数据目录存储规划 | 不属于核心架构，是部署配置问题 | ✅ 需要适配 |
|
||
|
||
---
|
||
|
||
## 不同方案对比
|
||
|
||
### 方案A：保持官方架构，单交易进程 + 单Web进程
|
||
|
||
**架构**：
|
||
```
|
||
NAS → 1个交易进程(RPC服务端) → 1个Web进程 → 所有用户共享
|
||
```
|
||
|
||
**优点**：
|
||
- 完全保持官方基础架构，一点不改
|
||
- 资源占用最小
|
||
|
||
**缺点**：
|
||
- ❌ 无用户隔离，所有操作混在一起
|
||
- ❌ 无法支持每人独立测试策略
|
||
- ❌ 一人出错影响全局
|
||
- ❌ 权限无法控制
|
||
|
||
**适用场景**：只有你一个人用，不适合多用户团队协作
|
||
|
||
**结论**：不推荐，不符合我们多将军协作场景
|
||
|
||
---
|
||
|
||
### 方案B：每个用户独立一对进程（推荐）
|
||
|
||
**架构**：
|
||
```
|
||
┌─────────────────────────────────────────────────────────┐
|
||
│ Nginx 反向代理 │
|
||
│ - 根据路径/子域名分发到不同Web进程 │
|
||
└─────────────┬───────────────────────────────────────────┘
|
||
├───────────┬───────────┐
|
||
↓ ↓ ↓
|
||
┌─────────┐ ┌─────────┐ ┌─────────┐
|
||
│ Web-姜维 │ │ Web-张飞 │ │ Web-关羽 │ 每个用户一个Web进程
|
||
└─────┬───┘ └─────┬───┘ └─────┬───┘
|
||
│ │ │
|
||
↓ ↓ ↓
|
||
┌─────────┐ ┌─────────┐ ┌─────────┐
|
||
│交易-姜维 │ │交易-张飞 │ │交易-关羽 │ 每个用户一个交易进程
|
||
└─────────┘ └─────────┘ └─────────┘
|
||
│ │ │
|
||
└────────────┼────────────┘
|
||
↓
|
||
NAS共享存储 (各用户独立数据目录)
|
||
```
|
||
|
||
**优点**：
|
||
- ✅ 用户之间完全隔离，互不影响
|
||
- ✅ 每个人可以自由测试自己的策略，不怕弄挂别人
|
||
- ✅ 数据独立存储，权限清晰
|
||
- ✅ 依然保持官方基础架构不变（每个进程都是标准官方架构）
|
||
- ✅ 可以独立启停，不影响他人
|
||
|
||
**缺点**：
|
||
- ⚡ 资源占用比单进程多，但现在NAS性能足够支撑
|
||
- 需要做简单的进程管理和配置文件生成
|
||
|
||
**结论**：推荐！既保持了官方基础架构，又解决了多用户隔离问题，符合需求。
|
||
|
||
---
|
||
|
||
### 方案C：共享交易进程 + 多Web进程 + 用户级数据隔离
|
||
|
||
**架构**：
|
||
```
|
||
┌─────────────────────────────────────────────────────────┐
|
||
│ Nginx 反向代理 │
|
||
└─────────────┬───────────────────────────────────────────┘
|
||
┌─────────┴─────────┐
|
||
↓ ↓
|
||
┌─────────┐ ┌─────────┐
|
||
│ Web-张1 │ │ Web-张2 │ 多Web进程，共享一个交易进程
|
||
└─────┬───┘ └─────┬───┘
|
||
│ │
|
||
└──────────┼───────┘
|
||
↓
|
||
┌───────────────┐
|
||
│ 共享交易进程 │ 单一交易核心，通过用户ID隔离数据
|
||
└───────────────┘
|
||
```
|
||
|
||
**优点**：
|
||
- 比方案B省点资源
|
||
|
||
**缺点**：
|
||
- ❌ 需要修改vnpy核心代码加入用户隔离逻辑（违反"基础架构不想改"原则）
|
||
- ❌ 依然存在干扰风险（一个错误操作可能影响所有用户数据）
|
||
- ❌ 维护复杂度高，难以跟进官方更新
|
||
|
||
**结论**：不推荐，改基础架构得不偿失，省了点资源带来更多风险
|
||
|
||
---
|
||
|
||
## 推荐方案：方案B 详细设计
|
||
|
||
### 目录结构规划（在NAS上）
|
||
|
||
```
|
||
/mnt/nas-volume/sanguo_vnpy/
|
||
├── config/ # 全局配置
|
||
│ ├── nginx/ # Nginx配置（各用户站点配置）
|
||
│ └── systemd/ # systemd单元文件
|
||
├── data/ # 全局共享数据
|
||
│ ├── history/ # 历史行情数据（共享只读）
|
||
│ └── master-db/ # 主数据库（可选）
|
||
└── users/ # 用户目录（每位将军一个）
|
||
├── jiangwei/ # 姜维
|
||
│ ├── data/ # 个人数据
|
||
│ ├── logs/ # 日志
|
||
│ ├── strategies/ # 个人策略
|
||
│ ├── config.json # 进程配置（RPC端口，Web端口等）
|
||
│ ├── start_trading.py # 个人交易进程启动脚本
|
||
│ └── start_web.py # 个人Web进程启动脚本
|
||
├── zhangfei/
|
||
│ └── ...
|
||
└── guanyu/
|
||
└── ...
|
||
```
|
||
|
||
### 端口分配规划
|
||
|
||
约定端口分配规则：
|
||
- 交易RPC请求端口：`2000 + 用户编号 * 10`
|
||
- 交易RPC订阅端口：`2000 + 用户编号 * 10 + 1`
|
||
- Web服务端口：`8000 + 用户编号`
|
||
|
||
| 用户 | 编号 | RPC请求 | RPC订阅 | Web端口 |
|
||
|------|------|---------|---------|---------|
|
||
| 姜维 | 1 | 2010 | 2011 | 8001 |
|
||
| 张飞 | 2 | 2020 | 2021 | 8002 |
|
||
| 关羽 | 3 | 2030 | 2031 | 8003 |
|
||
| 赵云 | 4 | 2040 | 2041 | 8004 |
|
||
| ... | ... | ... | ... | ... |
|
||
|
||
### Nginx 配置示例（按路径分发）
|
||
|
||
```nginx
|
||
server {
|
||
listen 443 ssl;
|
||
server_name nas.yourdomain.com;
|
||
|
||
# SSL证书配置...
|
||
|
||
# 姜维
|
||
location /jiangwei/ {
|
||
proxy_pass http://127.0.0.1:8001/;
|
||
proxy_set_header Host $host;
|
||
proxy_set_header X-Real-IP $remote_addr;
|
||
|
||
# WebSocket支持
|
||
proxy_http_version 1.1;
|
||
proxy_set_header Upgrade $http_upgrade;
|
||
proxy_set_header Connection "upgrade";
|
||
}
|
||
|
||
# 张飞
|
||
location /zhangfei/ {
|
||
proxy_pass http://127.0.0.1:8002/;
|
||
proxy_set_header Host $host;
|
||
proxy_set_header X-Real-IP $remote_addr;
|
||
|
||
proxy_http_version 1.1;
|
||
proxy_set_header Upgrade $http_upgrade;
|
||
proxy_set_header Connection "upgrade";
|
||
}
|
||
|
||
# 更多用户...
|
||
}
|
||
```
|
||
|
||
### systemd 进程管理（每个用户一对服务）
|
||
|
||
```
|
||
/etc/systemd/system/
|
||
├── sanguo-trade-jiangwei.service
|
||
├── sanguo-web-jiangwei.service
|
||
├── sanguo-trade-zhangfei.service
|
||
├── sanguo-web-zhangfei.service
|
||
└── ...
|
||
```
|
||
|
||
这样：
|
||
- 开机自动启动
|
||
- 崩溃自动重启
|
||
- 可以独立启停某个用户的进程
|
||
- 日志统一通过journald管理
|
||
|
||
---
|
||
|
||
## 需要改动的地方总结（很少，不改核心架构）
|
||
|
||
| 改动项 | 是否改vnpy核心 | 说明 |
|
||
|--------|--------------|------|
|
||
| 1. 规划目录结构 | ❌ 不改动 | 只是创建目录，不碰代码 |
|
||
| 2. 为每个用户生成启动脚本 | ❌ 不改动 | 只是调用官方API，生成启动文件 |
|
||
| 3. Nginx反向代理配置 | ❌ 不改动 | 纯运维配置 |
|
||
| 4. systemd服务文件 | ❌ 不改动 | 纯运维配置 |
|
||
| 5. 端口分配规则 | ❌ 不改动 | 只是配置 |
|
||
|
||
**结论**：完全符合你的要求 "基础架构我不太想改"，我们只是做了部署层的适配，vnpy官方核心架构一点不改。
|
||
|
||
---
|
||
|
||
## 存在的其他风险和应对
|
||
|
||
| 风险 | 应对方案 |
|
||
|------|---------|
|
||
| 总资源不够（CPU/内存） | 设定用户上限，不用的进程可以停掉，使用时再开 |
|
||
| 历史行情数据重复存储 | 全局共享一份历史数据，用户数据目录只做链接 |
|
||
| SQLite并发问题 | 推荐MySQL/PostgreSQL存tick/bar数据，或者每个用户独立SQLite |
|
||
| 实盘账户安全 | 每个用户自己保管APIKey，配置文件权限设为600，只有自己能读 |
|
||
|
||
---
|
||
|
||
## 总结建议
|
||
|
||
1. **遵循官方基础架构**：保持"Web进程 + 交易进程"的双进程模型不变，不修改vnpy核心代码
|
||
2. **多用户隔离方案**：每个用户分配独立一对进程，完全隔离，互不影响
|
||
3. **目录规划**：全局共享数据放公共区，每个用户数据独立存放
|
||
4. **进程管理**：用systemd管理各进程，开机自启，崩溃自动恢复
|
||
5. **访问入口**：用Nginx反向代理，按路径分发，统一入口
|
||
|
||
这个方案完全满足：
|
||
- ✅ 基础架构不改动
|
||
- ✅ 支持多位将军同时协作
|
||
- ✅ 隔离性好，一人出问题不影响全局
|
||
- ✅ 便于运维管理
|
||
- ✅ 支持回测、模拟、实盘
|
||
|
||
你的意见如何？确认这个方向我就开始动手搭建基础目录和配置模板。
|