cfdaily
13 KiB
13 KiB
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 配置示例（按路径分发）
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，只有自己能读 |
总结建议
- 遵循官方基础架构：保持"Web进程 + 交易进程"的双进程模型不变，不修改vnpy核心代码
- 多用户隔离方案：每个用户分配独立一对进程，完全隔离，互不影响
- 目录规划：全局共享数据放公共区，每个用户数据独立存放
- 进程管理：用systemd管理各进程，开机自启，崩溃自动恢复
- 访问入口：用Nginx反向代理，按路径分发，统一入口
这个方案完全满足：
- ✅ 基础架构不改动
- ✅ 支持多位将军同时协作
- ✅ 隔离性好，一人出问题不影响全局
- ✅ 便于运维管理
- ✅ 支持回测、模拟、实盘
你的意见如何？确认这个方向我就开始动手搭建基础目录和配置模板。