# 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反向代理，按路径分发，统一入口

这个方案完全满足：
- ✅ 基础架构不改动
- ✅ 支持多位将军同时协作
- ✅ 隔离性好，一人出问题不影响全局
- ✅ 便于运维管理
- ✅ 支持回测、模拟、实盘

你的意见如何？确认这个方向我就开始动手搭建基础目录和配置模板。
