量化交易系统开发工具链整合方案
来源: Trilium
以下是整合并优化后的方案，融合了两个方案的优势，补充了协同逻辑和细节，形成更完善的开发工具链体系：
🛠️ 量化交易系统开发工具链整合方案#### 一、核心组件配置（整合优化版）##### 1. Tmux 开发环境布局脚本（**scripts/dev/start-dev.sh**）- 布局升级：2×2 四窗格标准化布局（兼容方案一的分区逻辑，复用方案二的组件划分）左上：后端服务（pm2 dev 模式启动，实时显示启动日志）
- 右上：数据库客户端（自动连接开发库，预设常用查询语句）
- 左下：前端服务（
npm run dev启动，监控编译日志） - 右下：lnav 日志中心（自动加载自定义格式，聚焦
logs/backend.log） - 增强特性：自动依赖检查（检测 tmux/pm2/lnav 是否安装，缺失则提示安装命令）
- 会话智能管理（存在同名会话时自动附加，无则创建；支持
--new参数强制新建） - 彩色交互界面（添加启动进度条、组件状态色标，成功 / 失败用绿 / 红标识）
- 一键进入指定窗格（支持
./start-dev.sh backend直接跳转到后端窗格）
2. PM2 进程管理配置（**ecosystem.config.js**）- 多服务统一管理（融合方案二的多服务支持，强化方案一的资源控制）核心服务：后端 API 服务（src/main.py）
- 辅助服务：数据收集器（
src/data/collector.py）、GPU 策略计算服务（src/strategy/gpu_worker.py） - 增强特性：环境隔离：
NODE_ENV=dev时启用热重载，prod时启用资源限制（内存 >1G 重启） - 智能重启策略：开发环境
watch: true（文件变更自动重启），生产环境max_restarts: 10（防无限重启） - 健康检查：对
/health接口每秒探测，3 次失败触发重启并发送告警到终端 - 日志分级：开发环境日志输出到终端 + 文件，生产环境仅输出到文件（按天轮转）
3. Lnav 日志解析配置（**config/lnav/mystocks_log.json**）- 格式统一与扩展（整合方案一的 SQL 支持和方案二的字段识别）核心字段解析：timestamp（自动转换为时间戳）、level（映射到 lnav 级别）、request_id（关联全链路）、duration（计算耗时分布）、path（接口路径）、status（HTTP 状态码）、error（异常信息）
- 增强特性：预设查询模板：一键执行常用分析（如
top 10 慢接口、500 错误统计） - 自动安装与更新：
scripts/dev/setup_lnav.sh脚本支持dev/prod环境切换，自动覆盖旧配置 - 多日志关联：同时加载
backend.log、collector.log，通过request_id或symbol跨文件关联
二、关键文件结构（标准化路径）
plaintext
/opt/claude/mystocks_spec/
├── scripts/
│ └── dev/
│ ├── start-dev.sh # tmux会话启动入口
│ └── setup_lnav.sh # lnav配置安装脚本
├── config/
│ └── lnav/
│ └── mystocks_log.json # lnav日志格式定义
├── ecosystem.config.js # PM2多服务配置
└── logs/
├── backend.log # 后端主日志
├── collector.log # 数据收集器日志
└── gpu_worker.log # GPU服务日志
三、协同工作流（工具链联动逻辑）-
开发环境一键启动执行 ./scripts/dev/start-dev.sh 后：
Tmux 自动创建会话并分窗，依次启动：后端窗格：pm2 start ecosystem.config.js --env dev（开发模式启动所有服务）
- 前端窗格：cd frontend && npm run dev
- 数据库窗格：psql -U dev_user -d quant_dev -f scripts/dev/init_queries.sql（加载预设查询）
- 日志窗格：lnav logs/*.log（自动应用 mystocks_log.json 格式）
-
问题排查闭环
前端报错时，在日志窗格用 :filter-in request_id=xxx 定位对应后端请求日志
- 服务崩溃时，PM2 自动重启并在日志中标记 [PM2] Restarted service: backend，tmux 日志窗格实时显示
- 性能问题时，用 lnav 的 :histogram -f duration path=/api/strategy 分析策略接口耗时分布
-
生产环境切换
执行 pm2 start ecosystem.config.js --env prod 启动生产模式（自动启用资源限制和日志轮转）
- 用 tmux new-session -s prod -n monitor 'pm2 monit' 单独创建生产监控会话
四、文档与快速指南-
核心文档：docs/guides/DEV_TOOLCHAIN_GUIDE.md（整合两个方案的使用说明）
包含 tmux 窗格快捷键（如 Ctrl+b + 方向键 切换窗格）
- PM2 常用命令（pm2 logs backend 查看后端日志、pm2 restart ecosystem.config.js 重启服务）
- Lnav 高级用法（如用 SQL 查询：SELECT path, COUNT(*) FROM log WHERE level='ERROR' GROUP BY path）
-
快速开始命令：
bash
# 1. 一键启动开发环境（含tmux+pm2+lnav联动）
./scripts/dev/start-dev.sh
# 2. 单独安装lnav配置（支持开发/生产环境）
./scripts/dev/setup_lnav.sh dev # 开发环境（含调试字段）
./scripts/dev/setup_lnav.sh prod # 生产环境（精简字段，聚焦性能）
# 3. 生产环境服务管理
pm2 start ecosystem.config.js --env prod # 启动生产服务
pm2 monit # 监控服务状态
优化亮点总结- 工具协同化：解决了两个方案中工具 “各自为战” 的问题，通过 start-dev.sh 实现 tmux 启动时自动联动 PM2 和 lnav，形成闭环工作流。
- 环境差异化：开发 / 生产环境配置分离（如 PM2 的热重载 vs 资源限制、lnav 的调试字段 vs 精简字段），避免配置冲突。
- 操作人性化：添加自动检查、彩色提示、快捷跳转等功能，降低新成员上手成本。
- 扩展性预留：PM2 支持多服务配置，方便后续新增模块（如回测服务）；lnav 支持多日志关联，适配系统复杂度增长。