sanguo/sanguo_quant_live
8
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

按照工作流规则进行目录整理

Browse Source 
**主要调整：**
1. 重命名将军工作区目录：
   - data-engineering → zhaoyun-data (赵云数据工程）
   - risk-management → guanyu-risk (关羽风控管理)
   - platform → jiangwei-platform (姜维平台)
   - technical-strategy → zhangfei-technical (张飞技术策略)

2. 创建新目录：
   - archive/ (归档目录）
   - simayi-quality/ (司马懿质量保证)
   - pangtong-value/ (庞统价值投资)

3. 移动内容：
   - value-investing → pangtong-value/research (庞统价值投资)
   - running_data → zhaoyun-data/data (运行数据)
   - 文件任务管理系统文档 → archive/file-task-system

4. 清理文件：
   - 删除所有日志文件
   - 删除agent脚本
   - 删除knowledge-base (使用统一知识库)

5. 创建标准结构：
   - 各将军目录下创建research/, scripts/, reports/, references/子目录

6. 更新.gitignore：
   - 排除日志文件和临时文件

**依据：** management/workflow-rules.md
**制定：** 庞统（凤雏）
**审核：** 诸葛亮
This commit is contained in:
cfdaily
2026-03-25 17:27:35 +08:00
parent 5c9cdc7223
commit affcfa0c72
136 changed files with 56 additions and 45884 deletions
Download Patch File Download Diff File Expand all files Collapse all files
jiangwei-platform/research/03-部署方案/automation/deploy_pipeline.sh
Executable
+157
View File
@@ -0,0 +1,157 @@
#!/usr/bin/env bash
# =============================================================================
# sanguo_vnpy 自动化部署流水线脚本
# 版本: v1.0
# 作者: 姜维（后勤总督）
# =============================================================================
set -e
echo "========================================================================"
echo "🚀 sanguo_vnpy 自动化部署流水线"
echo "========================================================================"
# 颜色定义
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m'
print_info() {
echo -e "${BLUE}[INFO]${NC} $1"
}
print_success() {
echo -e "${GREEN}[SUCCESS]${NC} $1"
}
print_warning() {
echo -e "${YELLOW}[WARNING]${NC} $1"
}
print_error() {
echo -e "${RED}[ERROR]${NC} $1"
}
# 获取当前时间
get_timestamp() {
date +"%Y%m%d_%H%M%S"
}
# 配置变量
PROJECT_DIR="/Users/chufeng/.openclaw/agents/main/workspace/projects/sanguo_vnpy"
DEPLOY_ENV="${1:-production}"
TIMESTAMP=$(get_timestamp)
echo ""
print_info "部署环境: $DEPLOY_ENV"
print_info "时间戳: $TIMESTAMP"
echo ""
# 步骤 1: 代码构建
print_info "步骤 1: 代码构建..."
cd "$PROJECT_DIR"
# 检查虚拟环境
if [ ! -d "venv" ]; then
print_warning "虚拟环境不存在，正在创建..."
python3 -m venv venv
fi
# 激活虚拟环境
print_info "激活虚拟环境..."
source venv/bin/activate
# 升级依赖
print_info "升级项目依赖..."
pip install --upgrade pip wheel
pip install -e ".[alpha,dev]"
print_success "代码构建完成"
# 步骤 2: 代码检查
print_info "步骤 2: 代码质量检查..."
# 运行代码检查
if command -v ruff &> /dev/null; then
print_info "运行 Ruff 代码检查..."
ruff check sanguo/
print_success "代码检查通过"
else
print_warning "Ruff 未安装，跳过代码检查"
fi
# 步骤 3: 运行测试
print_info "步骤 3: 运行测试..."
if [ -d "tests" ]; then
if command -v pytest &> /dev/null; then
print_info "运行测试..."
pytest tests/ -v
print_success "测试通过"
else
print_warning "pytest 未安装，跳过测试"
fi
else
print_warning "测试目录不存在，跳过测试"
fi
# 步骤 4: 构建部署包
print_info "步骤 4: 构建部署包..."
# 创建部署目录
DEPLOY_DIR="/tmp/sanguo_vnpy_deploy_$TIMESTAMP"
mkdir -p "$DEPLOY_DIR"
# 复制代码
print_info "复制项目文件..."
cp -r sanguo/ "$DEPLOY_DIR/"
cp -r vnpy/ "$DEPLOY_DIR/" 2>/dev/null || true
cp pyproject.toml "$DEPLOY_DIR/"
cp README.md "$DEPLOY_DIR/"
# 构建 wheel 包
print_info "构建 wheel 包..."
pip install build
python -m build --wheel --outdir "$DEPLOY_DIR/"
print_success "部署包构建完成: $DEPLOY_DIR"
# 步骤 5: 部署到目标环境
print_info "步骤 5: 部署到目标环境..."
if [ "$DEPLOY_ENV" = "production" ]; then
print_info "生产环境部署..."
# 这里可以添加生产环境部署逻辑
# 例如: 上传到阿里云 OSS, SSH 到服务器部署等
print_warning "生产环境部署需要配置阿里云凭证"
elif [ "$DEPLOY_ENV" = "testing" ]; then
print_info "测试环境部署..."
print_success "测试环境部署完成"
else
print_info "本地开发环境部署..."
print_success "本地部署完成"
fi
# 步骤 6: 验证部署
print_info "步骤 6: 验证部署..."
# 验证模块导入
print_info "验证模块导入..."
python -c "import sanguo; import vnpy; print('✅ 模块导入成功')"
print_success "部署验证通过"
echo ""
echo "========================================================================"
echo "🎉 部署完成！"
echo "========================================================================"
echo "部署时间: $(date)"
echo "部署环境: $DEPLOY_ENV"
echo "部署包: $DEPLOY_DIR"
echo "========================================================================"
echo ""
jiangwei-platform/research/03-部署方案/terraform/main.tf
+219
View File
@@ -0,0 +1,219 @@
# =============================================================================
# sanguo_vnpy 阿里云生产环境 Terraform 配置
# 版本: v1.0
# 作者: 姜维（后勤总督）
# =============================================================================
terraform {
required_providers {
alicloud = {
source = "aliyun/alicloud"
version = ">= 1.212.0"
}
}
}
provider "alicloud" {
access_key = var.alicloud_access_key
secret_key = var.alicloud_secret_key
region = var.alicloud_region
}
# =============================================================================
# 变量定义
# =============================================================================
variable "alicloud_access_key" {
description = "阿里云 Access Key"
type = string
sensitive = true
}
variable "alicloud_secret_key" {
description = "阿里云 Secret Key"
type = string
sensitive = true
}
variable "alicloud_region" {
description = "阿里云区域"
type = string
default = "cn-hangzhou"
}
variable "environment" {
description = "环境类型: production/testing/development"
type = string
default = "production"
}
variable "instance_type" {
description = "ECS 实例规格"
type = string
default = "ecs.c6.large"
}
variable "vpc_cidr" {
description = "VPC CIDR 块"
type = string
default = "10.0.0.0/16"
}
variable "vswitch_cidr" {
description = "虚拟交换机 CIDR 块"
type = string
default = "10.0.0.0/24"
}
# =============================================================================
# VPC 网络
# =============================================================================
resource "alicloud_vpc" "sanguo_vpc" {
vpc_name = "sanguo-vnpy-${var.environment}-vpc"
cidr_block = var.vpc_cidr
}
resource "alicloud_vswitch" "sanguo_vswitch" {
vswitch_name = "sanguo-vnpy-${var.environment}-vswitch"
vpc_id = alicloud_vpc.sanguo_vpc.id
cidr_block = var.vswitch_cidr
zone_id = "${var.alicloud_region}-a"
}
# =============================================================================
# 安全组
# =============================================================================
resource "alicloud_security_group" "sanguo_sg" {
name = "sanguo-vnpy-${var.environment}-sg"
description = "sanguo_vnpy ${var.environment} 安全组"
vpc_id = alicloud_vpc.sanguo_vpc.id
}
resource "alicloud_security_group_rule" "allow_ssh" {
type = "ingress"
ip_protocol = "tcp"
nic_type = "intranet"
policy = "accept"
port_range = "22/22"
priority = 1
security_group_id = alicloud_security_group.sanguo_sg.id
cidr_ip = "0.0.0.0/0"
}
resource "alicloud_security_group_rule" "allow_http" {
type = "ingress"
ip_protocol = "tcp"
nic_type = "intranet"
policy = "accept"
port_range = "80/80"
priority = 2
security_group_id = alicloud_security_group.sanguo_sg.id
cidr_ip = "0.0.0.0/0"
}
resource "alicloud_security_group_rule" "allow_vnpy" {
type = "ingress"
ip_protocol = "tcp"
nic_type = "intranet"
policy = "accept"
port_range = "8080/8080"
priority = 3
security_group_id = alicloud_security_group.sanguo_sg.id
cidr_ip = "0.0.0.0/0"
}
# =============================================================================
# ECS 实例
# =============================================================================
resource "alicloud_instance" "sanguo_ecs" {
instance_name = "sanguo-vnpy-${var.environment}-ecs"
availability_zone = "${var.alicloud_region}-a"
instance_type = var.instance_type
security_groups = [alicloud_security_group.sanguo_sg.id]
vswitch_id = alicloud_vswitch.sanguo_vswitch.id
internet_charge_type = "PayByTraffic"
internet_max_bandwidth_out = 100
system_disk_size = 40
system_disk_category = "cloud_efficiency"
image_id = "ubuntu_22_04_x64_20G_alibase_20240228.vhd"
password = var.ecs_password
instance_charge_type = "PostPaid"
}
variable "ecs_password" {
description = "ECS 实例密码"
type = string
sensitive = true
default = "Sanguo@2024!"
}
# =============================================================================
# OSS 对象存储
# =============================================================================
resource "alicloud_oss_bucket" "sanguo_oss" {
bucket = "sanguo-vnpy-${var.environment}-data"
acl = "private"
}
# =============================================================================
# RDS 数据库（可选）
# =============================================================================
resource "alicloud_db_instance" "sanguo_rds" {
count = var.enable_rds ? 1 : 0
engine = "MySQL"
engine_version = "8.0"
instance_type = "rds.mysql.s2.large"
instance_storage = 20
vswitch_id = alicloud_vswitch.sanguo_vswitch.id
security_ips = ["0.0.0.0/0"]
db_instance_name = "sanguo-vnpy-${var.environment}-rds"
}
variable "enable_rds" {
description = "是否启用 RDS 数据库"
type = bool
default = false
}
# =============================================================================
# 输出
# =============================================================================
output "vpc_id" {
description = "VPC ID"
value = alicloud_vpc.sanguo_vpc.id
}
output "ecs_public_ip" {
description = "ECS 公网 IP"
value = alicloud_instance.sanguo_ecs.public_ip
}
output "ecs_private_ip" {
description = "ECS 私网 IP"
value = alicloud_instance.sanguo_ecs.private_ip
}
output "oss_bucket_name" {
description = "OSS 存储桶名称"
value = alicloud_oss_bucket.sanguo_oss.bucket
}
output "ecs_ssh_command" {
description = "SSH 连接命令"
value = "ssh root@${alicloud_instance.sanguo_ecs.public_ip}"
}
output "vnpy_web_url" {
description = "vn.py Web 界面地址"
value = "http://${alicloud_instance.sanguo_ecs.public_ip}:8080"
}
jiangwei-platform/research/04-运维方案/disaster-recovery/emergency_response.md
+335
View File
@@ -0,0 +1,335 @@
# sanguo_vnpy 阿里云生产环境应急响应方案
**版本**: v1.0
**作者**: 姜维（后勤总督）
**日期**: 2026-03-21
---
## 🚨 应急响应原则
### 1. 快速响应原则
- **5分钟内**：发现问题并启动响应流程
- **15分钟内**：完成初步诊断和影响评估
- **30分钟内**：确定并执行恢复方案
### 2. 优先级原则
- **P0（严重）**：系统完全不可用，数据丢失风险
- **P1（高）**：核心功能异常，影响主要交易
- **P2（中）**：次要功能异常，不影响核心交易
- **P3（低）**：轻微问题，用户体验影响
### 3. 数据安全原则
- **先备份，后操作**：任何修复操作前先备份数据
- **日志优先**：优先保存和分析日志，避免二次故障
- **最小化变更**：使用最小必要的操作修复问题
---
## 🔍 问题诊断流程
### 1. 监控告警触发
#### 告警来源
1. **系统监控**：Prometheus + Grafana
2. **应用监控**：sanguo_vnpy 内部健康检查
3. **业务监控**：策略执行异常告警
4. **用户反馈**：用户上报的问题
#### 告警级别对应
| 告警类型 | 影响 | 响应级别 |
|---------|------|---------|
| 实例宕机 | 系统不可用 | P0 |
| CPU > 90% 5分钟 | 性能下降 | P1 |
| 内存 > 90% 5分钟 | 可能OOM | P1 |
| 磁盘 > 95% | 数据写入失败 | P0 |
| vn.py 进程消失 | 应用不可用 | P0 |
| 策略执行失败 | 业务影响 | P1 |
### 2. 快速诊断步骤
#### 步骤 1: 检查系统状态
```bash
# 1. 检查服务器是否在线
ping <server-ip>
# 2. SSH 登录（如果可能）
ssh root@<server-ip>
# 3. 检查系统资源
top
htop
df -h
free -m
# 4. 检查网络
ping 8.8.8.8
curl -I https://www.aliyun.com
```
#### 步骤 2: 检查服务状态
```bash
# 1. 检查 vn.py 进程
ps aux | grep -i vnpy
ps aux | grep -i python
# 2. 检查端口监听
netstat -tlnp | grep 8080
ss -tlnp | grep 8080
# 3. 检查监控服务
systemctl status prometheus
systemctl status node_exporter
systemctl status grafana-server
```
#### 步骤 3: 检查日志
```bash
# 1. 系统日志
tail -100 /var/log/syslog
tail -100 /var/log/messages
# 2. 应用日志
tail -100 /path/to/sanguo_vnpy/logs/app.log
tail -100 /path/to/sanguo_vnpy/logs/error.log
# 3. 云服务商日志
# 阿里云控制台查看云服务器监控和事件
```
---
## 🔧 常见问题应急处理
### 场景 1: 实例完全宕机（P0）
#### 现象
- Ping 无响应
- SSH 无法连接
- 监控显示实例离线
#### 应急处理
1. **立即备份**（如果还能访问）
```bash
# 尝试通过阿里云控制台创建快照
# 快照命名: sanguo-vnpy-$(date +%Y%m%d-%H%M)-emergency
```
2. **重启实例**
- 阿里云控制台 → 实例 → 重启
- 等待 2-5 分钟
3. **如果重启失败**
- 使用可用快照回滚
- 或从备份数据重建实例
4. **验证恢复**
```bash
# 检查服务是否恢复
ssh root@<server-ip>
ps aux | grep vnpy
curl http://localhost:8080/health
```
---
### 场景 2: vn.py 进程崩溃（P0）
#### 现象
- 实例在线，但 vn.py 进程消失
- 端口 8080 无响应
- 应用监控告警
#### 应急处理
1. **保存崩溃现场**
```bash
# 保存系统状态
dmesg > /tmp/dmesg-$(date +%Y%m%d-%H%M).log
vmstat 1 5 > /tmp/vmstat-$(date +%Y%m%d-%H%M).log
# 保存应用日志
cp -r /path/to/sanguo_vnpy/logs /tmp/logs-backup-$(date +%Y%m%d-%H%M)
```
2. **检查崩溃原因**
```bash
# 检查系统日志中的 OOM
grep -i "out of memory" /var/log/syslog
grep -i "killed process" /var/log/syslog
# 检查应用错误日志
tail -200 /path/to/sanguo_vnpy/logs/error.log
```
3. **快速重启服务**
```bash
# 进入项目目录
cd /path/to/sanguo_vnpy
# 激活虚拟环境
source venv/bin/activate
# 启动 vn.py
python -m vnpy &
# 或者使用服务管理
systemctl start sanguo-vnpy
```
4. **验证恢复**
```bash
# 检查进程
ps aux | grep vnpy
# 检查端口
curl http://localhost:8080/health
# 检查监控
# 确认 Prometheus 数据恢复
```
---
### 场景 3: 磁盘空间满（P0）
#### 现象
- 磁盘使用率 > 95%
- 数据写入失败
- 应用无法保存数据
#### 应急处理
1. **立即清理临时文件**
```bash
# 清理系统临时文件
rm -rf /tmp/*
# 清理应用缓存
rm -rf /path/to/sanguo_vnpy/cache/*
# 清理旧日志（保留最近7天）
find /path/to/sanguo_vnpy/logs -name "*.log" -mtime +7 -delete
```
2. **检查大文件**
```bash
# 查找大于 100MB 的文件
find / -type f -size +100M -exec ls -lh {} \;
# 检查数据目录
du -sh /path/to/sanguo_vnpy/data
du -sh /path/to/sanguo_vnpy/results
```
3. **扩容磁盘（如果需要）**
- 阿里云控制台 → 云盘 → 扩容
- 或挂载新的数据盘
4. **验证恢复**
```bash
df -h
# 确认使用率下降到安全范围（< 80%）
```
---
### 场景 4: 数据库连接失败（P1）
#### 现象
- 应用报错无法连接数据库
- 策略无法获取数据
- 回测无法执行
#### 应急处理
1. **检查数据库状态**
```bash
# 如果使用 RDS
# 阿里云控制台检查 RDS 状态
# 如果使用本地 SQLite
ls -lh /path/to/sanguo_vnpy/data/*.db
# 检查文件权限和完整性
```
2. **网络连接测试**
```bash
# 测试数据库连接
telnet <db-host> <db-port>
nc -zv <db-host> <db-port>
# 检查安全组
# 确认应用服务器 IP 在数据库白名单中
```
3. **快速恢复方案**
```bash
# 方案 A: 切换到本地缓存数据
# 修改配置使用 akshare 直接获取
# 方案 B: 从备份恢复数据库
# 恢复最近的数据库备份
# 方案 C: 重启数据库服务
# 如果是自建数据库，重启服务
```
---
## 📋 应急响应检查清单
### 响应前检查
- [ ] 确认告警级别和影响范围
- [ ] 通知相关人员（诸葛亮/主公）
- [ ] 保存当前系统状态和日志
- [ ] 准备回滚方案
### 响应中检查
- [ ] 执行诊断步骤，确定根因
- [ ] 执行最小必要的修复操作
- [ ] 持续监控系统状态
- [ ] 记录所有操作和时间点
### 响应后检查
- [ ] 验证核心功能恢复正常
- [ ] 验证监控数据正常
- [ ] 验证业务数据完整性
- [ ] 总结故障原因和改进措施
---
## 📞 联络清单
### 紧急联络
- **总军师（诸葛亮）**：负责决策和协调
- **主公**：最终决策和资源协调
- **赵云**：数据库和数据相关问题
- **关羽**：回测引擎和风控问题
- **张飞**：API 兼容层问题
- **司马懿**：安全和合规问题
### 阿里云支持
- **阿里云控制台**：https://home.console.aliyun.com
- **阿里云工单**：紧急问题提交工单
- **阿里云电话**：400-910-0100
---
## 🔄 事后复盘
### 复盘会议
- **时间**：故障恢复后 24 小时内
- **参与人**：所有相关人员
- **内容**：
1. 故障回顾和时间线
2. 根因分析
3. 响应流程评估
4. 改进措施讨论
### 改进措施
- 技术改进：防止同类故障再次发生
- 流程改进：优化响应流程
- 监控改进：完善告警和监控
- 文档改进：更新应急方案
---
**本应急方案会持续更新，确保生产环境安全稳定运行！** 🚛
jiangwei-platform/research/04-运维方案/monitoring/deploy_monitoring.sh
Executable
+211
View File
@@ -0,0 +1,211 @@
#!/usr/bin/env bash
# =============================================================================
# sanguo_vnpy 阿里云生产环境监控系统部署脚本
# 版本: v1.0
# 作者: 姜维（后勤总督）
# =============================================================================
set -e
echo "========================================================================"
echo "🚀 sanguo_vnpy 监控系统部署"
echo "========================================================================"
# 颜色定义
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m'
print_info() {
echo -e "${BLUE}[INFO]${NC} $1"
}
print_success() {
echo -e "${GREEN}[SUCCESS]${NC} $1"
}
print_warning() {
echo -e "${YELLOW}[WARNING]${NC} $1"
}
print_error() {
echo -e "${RED}[ERROR]${NC} $1"
}
# 步骤 1: 安装系统依赖
print_info "步骤 1: 安装系统依赖..."
if command -v apt-get &> /dev/null; then
sudo apt-get update
sudo apt-get install -y prometheus node_exporter grafana nginx
elif command -v yum &> /dev/null; then
sudo yum install -y epel-release
sudo yum install -y prometheus node_exporter grafana nginx
else
print_error "不支持的操作系统"
exit 1
fi
print_success "系统依赖安装完成"
# 步骤 2: 配置 Prometheus
print_info "步骤 2: 配置 Prometheus..."
sudo mkdir -p /etc/prometheus
sudo cat > /etc/prometheus/prometheus.yml << 'EOF'
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'node_exporter'
static_configs:
- targets: ['localhost:9100']
- job_name: 'sanguo_vnpy'
static_configs:
- targets: ['localhost:8080']
metrics_path: '/metrics'
alerting:
alertmanagers:
- static_configs:
- targets: ['localhost:9093']
rule_files:
- "/etc/prometheus/alerts.yml"
EOF
# 步骤 3: 配置告警规则
print_info "步骤 3: 配置告警规则..."
sudo cat > /etc/prometheus/alerts.yml << 'EOF'
groups:
- name: sanguo_vnpy_alerts
rules:
- alert: InstanceDown
expr: up == 0
for: 5m
labels:
severity: critical
annotations:
summary: "实例 {{ $labels.instance }} 已宕机"
description: "{{ $labels.job }} 实例 {{ $labels.instance }} 已宕机超过 5 分钟"
- alert: HighCPUUsage
expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
annotations:
summary: "实例 {{ $labels.instance }} CPU 使用率过高"
description: "{{ $labels.instance }} CPU 使用率超过 80%"
- alert: HighMemoryUsage
expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 > 80
for: 5m
labels:
severity: warning
annotations:
summary: "实例 {{ $labels.instance }} 内存使用率过高"
description: "{{ $labels.instance }} 内存使用率超过 80%"
- alert: DiskSpaceLow
expr: (1 - (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"})) * 100 > 90
for: 5m
labels:
severity: critical
annotations:
summary: "实例 {{ $labels.instance }} 磁盘空间不足"
description: "{{ $labels.instance }} 磁盘使用率超过 90%"
- alert: VnpyDown
expr: up{job="sanguo_vnpy"} == 0
for: 2m
labels:
severity: critical
annotations:
summary: "sanguo_vnpy 服务已宕机"
description: "sanguo_vnpy 服务已宕机超过 2 分钟，请立即检查！"
EOF
# 步骤 4: 配置 Grafana
print_info "步骤 4: 配置 Grafana..."
sudo mkdir -p /etc/grafana/provisioning/datasources
sudo cat > /etc/grafana/provisioning/datasources/prometheus.yml << 'EOF'
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
access: proxy
url: http://localhost:9090
isDefault: true
editable: true
EOF
# 步骤 5: 启动服务
print_info "步骤 5: 启动监控服务..."
sudo systemctl enable prometheus
sudo systemctl enable node_exporter
sudo systemctl enable grafana-server
sudo systemctl start prometheus
sudo systemctl start node_exporter
sudo systemctl start grafana-server
# 步骤 6: 配置 Nginx 反向代理
print_info "步骤 6: 配置 Nginx 反向代理..."
sudo cat > /etc/nginx/sites-available/sanguo-monitoring << 'EOF'
server {
listen 80;
server_name _;
location /grafana/ {
proxy_pass http://localhost:3000/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /prometheus/ {
proxy_pass http://localhost:9090/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
location /node-exporter/ {
proxy_pass http://localhost:9100/;
proxy_set_header Host $host;
}
}
EOF
sudo ln -sf /etc/nginx/sites-available/sanguo-monitoring /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
# 步骤 7: 显示访问信息
print_success "监控系统部署完成！"
echo ""
echo "========================================================================"
echo "📊 监控系统访问信息"
echo "========================================================================"
echo "Grafana: http://$(hostname -I | awk '{print $1}'):3000"
echo "Prometheus: http://$(hostname -I | awk '{print $1}'):9090"
echo "Node Exporter: http://$(hostname -I | awk '{print $1}'):9100"
echo ""
echo "默认 Grafana 账号: admin / admin"
echo "========================================================================"
echo ""
jiangwei-platform/research/ALIBABA_CLOUD_DEPLOYMENT_RESEARCH.md
+326
View File
@@ -0,0 +1,326 @@
# sanguo_vnpy 阿里云部署调研总结
**调研人**: 姜维（后勤总督）
**调研时间**: 2026-03-21
**版本**: v1.0
---
## 🎯 调研目标
主公指令：调研生产环境部署到阿里云的方案，未来本地是开发和测试环境，生产环境放到阿里云上。
---
## 📦 已完成的成果
### 1. 基础设施即代码（Terraform）
**文件**: `platform/research/03-部署方案/terraform/main.tf`
**内容**:
- VPC 网络和虚拟交换机配置
- 安全组配置（SSH/HTTP/vn.py 端口）
- ECS 实例配置（Ubuntu 22.04）
- OSS 对象存储配置
- RDS 数据库配置（可选）
- 完整输出信息（公网IP/私网IP/SSH命令等）
---
### 2. 实时监控系统部署
**文件**: `platform/research/04-运维方案/monitoring/deploy_monitoring.sh`
**内容**:
- Prometheus 部署和配置
- Node Exporter 部署
- Grafana 部署和数据源配置
- 告警规则配置（P0/P1 级别告警）
- Nginx 反向代理配置
- 完整监控访问信息
**告警规则**:
- 实例宕机告警（P0）
- CPU 使用率过高告警（P1）
- 内存使用率过高告警（P1）
- 磁盘空间不足告警（P0）
- vn.py 服务宕机告警（P0）
---
### 3. 自动化部署流水线
**文件**: `platform/research/03-部署方案/automation/deploy_pipeline.sh`
**内容**:
- 代码构建流程
- 代码质量检查（Ruff）
- 自动化测试（pytest）
- 部署包构建（wheel 包）
- 多环境部署支持（生产/测试/开发）
- 部署验证流程
---
### 4. 应急响应方案
**文件**: `platform/research/04-运维方案/disaster-recovery/emergency_response.md`
**内容**:
- 应急响应原则（5分钟响应/15分钟诊断/30分钟恢复）
- 问题诊断流程
- 4个典型场景应急处理：
1. 实例完全宕机（P0）
2. vn.py 进程崩溃（P0）
3. 磁盘空间满（P0）
4. 数据库连接失败（P1）
- 应急响应检查清单
- 联络清单
- 事后复盘流程
---
## 📊 阿里云服务选型建议
### 计算服务
| 服务 | 推荐配置 | 用途 |
|------|---------|------|
| ECS | ecs.c6.large (2核4GB) | 生产环境主服务器 |
| 轻量应用服务器 | 2核4GB | 测试环境 |
| 容器服务 ACK | 标准版 | 未来容器化部署 |
### 存储服务
| 服务 | 用途 |
|------|------|
| OSS | 对象存储（策略/数据/日志备份） |
| NAS | 文件存储（共享数据） |
| 云盘 | 系统盘和数据盘 |
### 数据库服务
| 服务 | 用途 |
|------|------|
| 云数据库 MySQL | 生产环境数据库 |
| SQLite | 本地开发/测试数据库 |
### 网络服务
| 服务 | 用途 |
|------|------|
| VPC | 专有网络隔离 |
| 弹性公网 IP | 公网访问 |
| SLB | 负载均衡（未来扩展） |
| 安全组 | 访问控制 |
---
## 🏗️ 架构设计
### 开发-测试-生产环境架构
```
┌─────────────────────────────────────────────────────────────────┐
│ 本地环境 │
│ ┌──────────────────────┐ ┌──────────────────────┐ │
│ │ 开发环境 (venv) │ │ 测试环境 (venv_testing)│ │
│ │ - 快速迭代 │ │ - 集成测试 │ │
│ │ - 本地调试 │ │ - 自动化测试 │ │
│ └──────────────────────┘ └──────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 阿里云生产环境 │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ ECS 实例 (Ubuntu 22.04) │ │
│ │ - vn.py 应用服务 │ │
│ │ - Prometheus + Grafana 监控 │ │
│ │ - Nginx 反向代理 │ │
│ └───────────────────────────────────────────────────────┘ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ OSS 对象存储 │ │ RDS MySQL 数据库 │ │
│ │ - 策略文件 │ │ - 业务数据 │ │
│ │ - 数据备份 │ │ - 用户数据 │ │
│ │ - 日志归档 │ │ │ │
│ └──────────────────┘ └──────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
```
---
## 💰 成本估算
### 生产环境月度成本估算（推荐配置）
| 资源 | 配置 | 月度费用（估算） |
|------|------|----------------|
| ECS | ecs.c6.large (2核4GB) | ¥ 200-300 |
| 云盘 | 40GB 高效云盘 | ¥ 20-30 |
| 公网带宽 | 10Mbps | ¥ 80-100 |
| OSS | 100GB 标准存储 | ¥ 10-20 |
| **合计** | - | **¥ 310-450/月** |
---
## 💸 最小费用方案
### 方案目标
在保证基本可用性的前提下，将月度成本控制在 **¥ 100-150/月** 以内。
---
### 最小费用配置方案
| 资源 | 配置 | 月度费用（估算） | 说明 |
|------|------|----------------|------|
| **ECS 实例** | ecs.t6-c1m1.small (1核1GB) | ¥ 50-60 | 突发性能实例，性价比高 |
| **系统盘** | 20GB 高效云盘 | ¥ 10-15 | 最小系统盘 |
| **公网带宽** | 1Mbps 按流量计费 | ¥ 20-30 | 低带宽 + 流量计费 |
| **OSS 存储** | 50GB 标准存储 | ¥ 5-10 | 减少存储容量 |
| **数据库** | SQLite（本地文件） | ¥ 0 | 不使用 RDS，用 SQLite |
| **合计** | - | **¥ 85-115/月** | 💰 推荐配置的 1/3 |
---
### 最小费用架构设计
```
┌─────────────────────────────────────────────────────────────────┐
│ 最小费用阿里云生产环境 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ ECS 突发性能实例 (ecs.t6-c1m1.small) │ │
│ │ - 1核1GB，突发性能模式 │ │
│ │ - Ubuntu 22.04 │ │
│ │ - vn.py 应用 + Prometheus + Grafana │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌──────────────────┐ ┌──────────────────────┐ │
│ │ OSS 对象存储 │ │ SQLite 本地数据库 │ │
│ │ - 50GB 标准 │ │ - 数据文件存储 │ │
│ │ - 策略/日志/备份 │ │ - 无需 RDS │ │
│ └──────────────────┘ └──────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
```
---
### 最小费用方案优化策略
#### 1. 计算资源优化
- **使用突发性能实例**：ecs.t6-c1m1.small（1核1GB）
- 基础性能：1核1GB
- 突发性能：CPU积分积累，应对峰值
- 成本比标准实例低 60-70%
#### 2. 存储资源优化
- **系统盘最小化**：20GB 高效云盘
- **OSS 容量减半**：50GB 标准存储（100GB → 50GB）
- **用 SQLite 替代 RDS**：
- 本地文件数据库，无需 RDS 费用
- 定期备份到 OSS，保证数据安全
- 适合中小规模量化交易
#### 3. 网络资源优化
- **降低带宽**：10Mbps → 1Mbps
- **按流量计费**：而非固定带宽
- **利用 CDN 加速**：静态资源用 CDN
---
### 最小费用 vs 推荐配置对比
| 指标 | 推荐配置 | 最小费用 | 节省 |
|------|---------|---------|------|
| **月度费用** | ¥ 310-450 | ¥ 85-115 | **70-75%** |
| **ECS 配置** | 2核4GB | 1核1GB（突发） | 降低配置 |
| **数据库** | RDS MySQL | SQLite 本地 | 费用为0 |
| **OSS 存储** | 100GB | 50GB | 节省 50% |
| **公网带宽** | 10Mbps 固定 | 1Mbps 流量计费 | 节省 70%+ |
---
### 最小费用方案适用场景
#### ✅ 适用场景
- 个人量化交易
- 策略验证和回测
- 小规模实盘模拟
- 学习和研究用途
#### ❌ 不适用场景
- 大规模实盘交易
- 多策略并发运行
- 高频交易场景
- 需要高可用性的场景
---
### 最小费用方案扩容路径
当业务增长时，可以按以下路径逐步扩容：
1. **第1步**：ECS 升级到 2核2GB（¥ 100-120/月）
2. **第2步**：增加 OSS 到 100GB（¥ 10-20/月）
3. **第3步**：升级带宽到 5Mbps（¥ 50-60/月）
4. **第4步**：引入 RDS MySQL（¥ 150-200/月）
5. **第5步**：最终切换到推荐配置
---
## 🚀 部署流程
---
## 🚀 部署流程
### CI/CD 流水线
1. **代码提交** → Git 仓库
2. **自动构建** → 依赖检查 + 代码质量检查
3. **自动测试** → 单元测试 + 集成测试
4. **构建部署包** → Wheel 包 + 配置文件
5. **部署到测试环境** → 自动化验证
6. **部署到生产环境** → 人工确认后部署
---
## 🔒 安全保障
### 网络安全
- VPC 专有网络隔离
- 安全组白名单控制
- SSL/TLS 加密传输
### 访问控制
- RAM 访问控制
- SSH 密钥认证
- 操作审计日志
### 数据安全
- 数据加密存储
- 定期自动备份
- 跨地域容灾（可选）
---
## 📋 下一步计划
### 第1周（3月24日-27日）
- [ ] 阿里云产品深入调研
- [ ] 性能基准测试
- [ ] 成本优化方案
### 第2周（3月28日-4月1日）
- [ ] 架构设计详细方案
- [ ] 网络设计方案
- [ ] 安全设计方案
### 第3周（4月2日-9日）
- [ ] 部署流程详细设计
- [ ] Terraform 配置完善
- [ ] 部署脚本完善
### 第4周（4月10日-17日）
- [ ] 测试验证
- [ ] 运维方案完善
- [ ] 完整调研报告撰写
---
**调研正在进行中，4月17日前将提交完整调研报告！** 🚛
jiangwei-platform/research/MEMORY_ORGANIZATION.md
+299
View File
@@ -0,0 +1,299 @@
# sanguo_quant_live 记忆整理文档
**整理人**: 姜维（后勤总督）
**整理时间**: 2026-03-22
**版本**: v1.0
---
## 🎯 记忆整理目标
1. 搜索过去的记忆，对于经常性的工作，形成脚本，以后通过脚本的方式直接执行
2. 整理上下文，只保留和这个项目 sanguo_quant_live 相关的上下文，其余的进行上下文压缩，确保上下文精简
---
## 📋 经常性工作自动化脚本
### 1. Git 提交和推送自动化脚本
**文件**: `platform/research/scripts/git_push.sh`
**功能**:
- 自动添加变更
- 自动生成 commit message
- 自动推送到 Gitee
**使用方式**:
```bash
chmod +x platform/research/scripts/git_push.sh
./platform/research/scripts/git_push.sh "提交信息"
```
---
### 2. 调研文档更新自动化脚本
**文件**: `platform/research/scripts/update_research.sh`
**功能**:
- 自动读取最新调研内容
- 自动更新 ALIBABA_CLOUD_DEPLOYMENT_RESEARCH.md
- 自动生成 commit 和推送
**使用方式**:
```bash
chmod +x platform/research/scripts/update_research.sh
./platform/research/scripts/update_research.sh
```
---
## 🔧 自动化脚本实现
### git_push.sh 脚本
```bash
#!/usr/bin/env bash
# sanguo_quant_live Git 提交和推送自动化脚本
# 作者: 姜维（后勤总督）
# 版本: v1.0
set -e
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
PROJECT_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
# 颜色定义
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m'
print_info() {
echo -e "${BLUE}[INFO]${NC} $1"
}
print_success() {
echo -e "${GREEN}[SUCCESS]${NC} $1"
}
print_warning() {
echo -e "${YELLOW}[WARNING]${NC} $1"
}
print_error() {
echo -e "${RED}[ERROR]${NC} $1"
}
cd "$PROJECT_ROOT"
# 检查是否有变更
if git diff --quiet && git diff --cached --quiet; then
print_warning "没有变更需要提交"
exit 0
fi
# 获取 commit message
COMMIT_MSG="${1:-更新调研内容}"
print_info "添加变更..."
git add -A
print_info "提交变更..."
git commit -m "$COMMIT_MSG"
print_info "推送到 Gitee..."
git push origin main
print_success "Git 提交和推送完成！"
```
---
### update_research.sh 脚本
```bash
#!/usr/bin/env bash
# sanguo_quant_live 调研文档更新自动化脚本
# 作者: 姜维（后勤总督）
# 版本: v1.0
set -e
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
PROJECT_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
# 颜色定义
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m'
print_info() {
echo -e "${BLUE}[INFO]${NC} $1"
}
print_success() {
echo -e "${GREEN}[SUCCESS]${NC} $1"
}
print_warning() {
echo -e "${YELLOW}[WARNING]${NC} $1"
}
print_error() {
echo -e "${RED}[ERROR]${NC} $1"
}
cd "$PROJECT_ROOT"
print_info "检查调研文档..."
RESEARCH_DOC="platform/research/ALIBABA_CLOUD_DEPLOYMENT_RESEARCH.md"
if [ ! -f "$RESEARCH_DOC" ]; then
print_error "调研文档不存在: $RESEARCH_DOC"
exit 1
fi
print_info "检查变更..."
if git diff --quiet "$RESEARCH_DOC" && git diff --cached --quiet "$RESEARCH_DOC"; then
print_warning "调研文档没有变更"
exit 0
fi
print_info "提交调研文档更新..."
git add "$RESEARCH_DOC"
# 生成 commit message
TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")
git commit -m "docs(platform): 姜维更新阿里云部署调研 - $TIMESTAMP
调研内容更新:
- 最小费用方案已完善
- 成本优化策略已更新
- 架构设计已优化"
print_info "推送到 Gitee..."
git push origin main
print_success "调研文档更新和推送完成！"
```
---
## 📚 sanguo_quant_live 项目上下文整理
### 项目核心信息
| 项目信息 | 内容 |
|---------|------|
| **项目名称** | sanguo_quant_live |
| **调研目标** | 生产环境部署到阿里云的方案 |
| **环境规划** | 本地是开发和测试环境，生产环境放到阿里云上 |
| **调研负责人** | 姜维（后勤总督） |
| **Gitee 仓库** | git@gitee.com:cfdaily/sanguo_quant_live.git |
| **分支** | main |
---
### 已完成的调研成果
| 成果 | 文件位置 | 状态 |
|-------|---------|------|
| 1. 基础设施即代码（Terraform） | `platform/research/03-部署方案/terraform/main.tf` | ✅ 已完成 |
| 2. 实时监控系统部署 | `platform/research/04-运维方案/monitoring/deploy_monitoring.sh` | ✅ 已完成 |
| 3. 自动化部署流水线 | `platform/research/03-部署方案/automation/deploy_pipeline.sh` | ✅ 已完成 |
| 4. 应急响应方案 | `platform/research/04-运维方案/disaster-recovery/emergency_response.md` | ✅ 已完成 |
| 5. 阿里云部署调研总结 | `platform/research/ALIBABA_CLOUD_DEPLOYMENT_RESEARCH.md` | ✅ 已完成 |
| 6. 最小费用方案 | `platform/research/ALIBABA_CLOUD_DEPLOYMENT_RESEARCH.md` | ✅ 已完成 |
| 7. Git 提交自动化脚本 | `platform/research/scripts/git_push.sh` | ✅ 已完成 |
| 8. 调研文档更新自动化脚本 | `platform/research/scripts/update_research.sh` | ✅ 已完成 |
---
### 阿里云服务选型（精简）
#### 计算服务
| 服务 | 配置 | 月度费用 | 用途 |
|------|------|---------|------|
| ECS（推荐） | ecs.c6.large (2核4GB) | ¥ 200-300 | 生产环境主服务器 |
| ECS（最小费用） | ecs.t6-c1m1.small (1核1GB) | ¥ 50-60 | 最小费用方案 |
| 轻量应用服务器 | 2核4GB | ¥ 100-150 | 测试环境 |
#### 存储服务
| 服务 | 配置 | 月度费用 | 用途 |
|------|------|---------|------|
| OSS（推荐） | 100GB 标准存储 | ¥ 10-20 | 对象存储（策略/数据/日志备份） |
| OSS（最小费用） | 50GB 标准存储 | ¥ 5-10 | 对象存储（最小费用方案） |
| 云盘（推荐） | 40GB 高效云盘 | ¥ 20-30 | 系统盘和数据盘 |
| 云盘（最小费用） | 20GB 高效云盘 | ¥ 10-15 | 系统盘（最小费用方案） |
#### 数据库服务
| 服务 | 配置 | 月度费用 | 用途 |
|------|------|---------|------|
| RDS MySQL（推荐） | 2核4GB | ¥ 150-200 | 生产环境数据库 |
| SQLite（最小费用） | 本地文件 | ¥ 0 | 本地数据库（最小费用方案） |
#### 网络服务
| 服务 | 配置 | 月度费用 | 用途 |
|------|------|---------|------|
| 公网带宽（推荐） | 10Mbps 固定 | ¥ 80-100 | 公网访问 |
| 公网带宽（最小费用） | 1Mbps 流量计费 | ¥ 20-30 | 公网访问（最小费用方案） |
| VPC | 专有网络 | ¥ 0 | 专有网络隔离 |
| 安全组 | 访问控制 | ¥ 0 | 访问控制 |
#### 成本估算
| 方案 | 月度费用 | 说明 |
|------|---------|------|
| **推荐配置** | ¥ 310-450/月 | 完整功能，高可用性 |
| **最小费用** | ¥ 85-115/月 | 推荐配置的 1/3，性价比高 |
---
## 🚀 使用自动化脚本
### 设置脚本执行权限
```bash
cd /path/to/sanguo_quant_live
chmod +x platform/research/scripts/git_push.sh
chmod +x platform/research/scripts/update_research.sh
```
### 使用 Git 提交脚本
```bash
# 方式 1: 使用默认 commit message
./platform/research/scripts/git_push.sh
# 方式 2: 自定义 commit message
./platform/research/scripts/git_push.sh "自定义提交信息"
```
### 使用调研文档更新脚本
```bash
./platform/research/scripts/update_research.sh
```
---
## 📋 记忆整理完成
### ✅ 已完成的整理
1. **经常性工作自动化脚本**：
- Git 提交和推送自动化脚本
- 调研文档更新自动化脚本
2. **上下文整理**：
- 只保留和 sanguo_quant_live 相关的上下文
- 其他上下文已压缩
- 确保上下文精简高效
---
**记忆整理完成！请查阅！** 🚛
jiangwei-platform/research/aliyun-us-proxy-cost.md
+55
View File
@@ -0,0 +1,55 @@
# 阿里云美国节点代理方案分析
## 一、阿里云美国节点可用性
**可用区域**：
- 美国东部（弗吉尼亚）：`us-east-1`
- 美国西部（硅谷）：`us-west-1`
**结论**：✅ 阿里云美国节点可以作为国内主机代理！
---
## 二、费用估算（以 1核2G 配置为例）
### 2.1 云服务器（ECS）费用
| 配置 | 地域 | 计费方式 | 月费用（估算） |
|------|------|----------|---------------|
| 1核2G，40G SSD | 美国东部/西部 | 按量付费 | ~¥120-150 |
| 1核2G，40G SSD | 美国东部/西部 | 包年包月 | ~¥80-100 |
### 2.2 网络费用
- **入流量**：免费
- **出流量**：约 ¥0.8-1.2/GB
- **固定带宽**：1Mbps 约 ¥100/月，5Mbps 约 ¥400/月
### 2.3 总费用估算
| 场景 | 月费用（估算） |
|------|---------------|
| 低流量（<10GB/月） | ~¥100-150 |
| 中流量（10-50GB/月） | ~¥150-250 |
| 高流量（>50GB/月） | ~¥250+ |
---
## 三、与全球厂商对比
| 云厂商 | 美国节点月费用 | 优势 |
|--------|---------------|------|
| **阿里云** | ~¥80-150 | 国内支付方式便利，中文支持好 |
| **Linode** | ~¥36-50 | 性价比更高，网络更稳定 |
| **DigitalOcean** | ~¥40-55 | 性价比高，管理界面简洁 |
---
## 四、注意事项
1. **网络延迟**：阿里云美国节点到国内的延迟通常在 150-200ms 左右
2. **合规性**：确保使用符合中美两国相关法律法规
3. **流量监控**：注意监控出流量费用，避免超支
4. **备选方案**：若对延迟和成本敏感，优先考虑 Linode/DigitalOcean 等全球厂商
---
**分析时间**：2026年3月24日
**分析人**：姜维（伯约）
jiangwei-platform/research/canada-proxy-research/README.md
+64
View File
@@ -0,0 +1,64 @@
# 加拿大云主机中转方案调研
📚 **完整的加拿大云主机中转方案调研文档**
---
## 📋 文档目录
| 文档 | 说明 | 推荐阅读顺序 |
|------|------|-------------|
| 🚀 [快速入门指南.md](快速入门指南.md) | 10分钟快速上手指南 | ⭐⭐⭐⭐⭐ 首先阅读 |
| 📖 [加拿大云主机中转方案调研报告.md](加拿大云主机中转方案调研报告.md) | 完整的调研报告 | ⭐⭐⭐⭐⭐ 核心文档 |
| 💰 [云服务商详细对比表.md](云服务商详细对比表.md) | 6大云服务商详细对比 | ⭐⭐⭐⭐ 选择服务商参考 |
| 🔧 [WireGuard详细操作手册.md](WireGuard详细操作手册.md) | WireGuard 完整配置教程 | ⭐⭐⭐⭐ 部署指南 |
| ⚠️ [风险提示与注意事项.md](风险提示与注意事项.md) | 安全和法律风险提示 | ⭐⭐⭐⭐⭐ 必读！ |
---
## 🎯 方案要点
### 推荐方案
- **云服务商**：Linode Toronto ($5/月) 或 DigitalOcean Toronto ($6/月)
- **技术方案**：WireGuard VPN（现代、轻量、高性能）
- **实例配置**：1GB 内存，1 vCPU（足够中转使用）
### 预计成本
- **基础方案**：$5-$6/月
- **标准方案**：$10-$12/月
- **包含流量**：通常 1-2TB/月
---
## 🚀 快速开始
1. 阅读 [快速入门指南.md](快速入门指南.md)
2. 参考 [云服务商详细对比表.md](云服务商详细对比表.md) 选择服务商
3. 按照 [WireGuard详细操作手册.md](WireGuard详细操作手册.md) 部署
4. 务必阅读 [风险提示与注意事项.md](风险提示与注意事项.md)
---
## ⚠️ 重要提示
本报告仅供技术研究和学习交流使用。使用任何中转服务时，请严格遵守当地法律法规，不得用于任何非法用途。
请务必阅读 [风险提示与注意事项.md](风险提示与注意事项.md)。
---
## 📝 版本信息
- **文档版本**：1.0
- **更新时间**：2026年3月
- **调研区域**：加拿大
---
## 📄 许可证
本调研文档仅供学习和研究使用。
---
*祝您使用顺利！* 🎉
jiangwei-platform/research/canada-proxy-research/WireGuard详细操作手册.md
+289
View File
@@ -0,0 +1,289 @@
# WireGuard VPN 详细操作手册
## 目录
1. [服务器端部署](#服务器端部署)
2. [客户端配置](#客户端配置)
3. [多客户端配置](#多客户端配置)
4. [性能优化](#性能优化)
5. [故障排查](#故障排查)
---
## 服务器端部署
### 1. 选择云服务商并创建实例
推荐选择：
- **Linode Toronto** ($5/月，1GB 内存)
- **DigitalOcean Toronto** ($6/月，1GB 内存)
- **Vultr Toronto** ($6/月，1GB 内存)
操作系统选择：**Ubuntu 22.04 LTS** 或 **Debian 12**
### 2. 初始服务器配置
#### 2.1 登录服务器
```bash
ssh root@your-server-ip
```
#### 2.2 更新系统
```bash
apt update && apt upgrade -y
```
#### 2.3 启用 BBR 拥塞控制（推荐）
```bash
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p
```
#### 2.4 配置防火墙（UFW）
```bash
apt install ufw -y
ufw allow 22/tcp
ufw allow 51820/udp
ufw enable
```
### 3. 安装 WireGuard
#### 3.1 安装 WireGuard 软件包
```bash
apt install wireguard -y
```
#### 3.2 启用 IP 转发
```bash
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p
```
### 4. 生成密钥
#### 4.1 创建密钥存储目录
```bash
mkdir -p /etc/wireguard/keys
cd /etc/wireguard/keys
```
#### 4.2 生成服务器密钥对
```bash
wg genkey | tee server_privatekey | wg pubkey > server_publickey
```
#### 4.3 生成客户端密钥对
```bash
wg genkey | tee client1_privatekey | wg pubkey > client1_publickey
```
#### 4.4 查看生成的密钥
```bash
echo "服务器私钥: $(cat server_privatekey)"
echo "服务器公钥: $(cat server_publickey)"
echo "客户端私钥: $(cat client1_privatekey)"
echo "客户端公钥: $(cat client1_publickey)"
```
**重要：请妥善保存这些密钥！**
### 5. 创建 WireGuard 配置文件
#### 5.1 创建服务器配置
```bash
nano /etc/wireguard/wg0.conf
```
配置内容（请替换为实际的密钥）：
```
[Interface]
PrivateKey = <这里填入服务器私钥>
Address = 10.0.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
SaveConfig = true
[Peer]
PublicKey = <这里填入客户端公钥>
AllowedIPs = 10.0.0.2/32
```
**注意：** 如果您的网络接口不是 `eth0`，请替换为实际接口名（可以用 `ip a` 查看）。
#### 5.2 设置配置文件权限
```bash
chmod 600 /etc/wireguard/wg0.conf
```
### 6. 启动 WireGuard 服务
#### 6.1 启动服务
```bash
systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0
```
#### 6.2 检查服务状态
```bash
systemctl status wg-quick@wg0
wg show
```
---
## 客户端配置
### Windows 客户端
1. 下载 WireGuard 客户端：https://www.wireguard.com/download/
2. 安装并打开 WireGuard
3. 点击 "Add Tunnel" -> "Add empty tunnel..."
4. 输入以下配置（替换为实际值）：
```
[Interface]
PrivateKey = <客户端私钥>
Address = 10.0.0.2/24
DNS = 8.8.8.8, 1.1.1.1
[Peer]
PublicKey = <服务器公钥>
Endpoint = <服务器IP>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
```
5. 保存并点击 "Activate"
### macOS 客户端
1. 从 Mac App Store 下载 WireGuard
2. 打开应用，点击 "+" 创建新隧道
3. 导入或粘贴配置文件（同 Windows 配置）
4. 点击 "Activate"
### Linux 客户端
```bash
# 安装 WireGuard
sudo apt install wireguard -y
# 创建配置文件
sudo nano /etc/wireguard/wg0.conf
# 粘贴配置（同 Windows）
# 启动
sudo wg-quick up wg0
# 设置开机自启
sudo systemctl enable wg-quick@wg0
```
### iOS 客户端
1. 从 App Store 下载 WireGuard
2. 可以通过扫描二维码或导入配置文件
3. 激活隧道
### Android 客户端
1. 从 Google Play 下载 WireGuard
2. 导入配置文件或扫描二维码
3. 激活隧道
---
## 多客户端配置
### 添加第二个客户端
1. 在服务器上生成第二组客户端密钥：
```bash
cd /etc/wireguard/keys
wg genkey | tee client2_privatekey | wg pubkey > client2_publickey
```
2. 添加到服务器配置：
```bash
wg set wg0 peer $(cat client2_publickey) allowed-ips 10.0.0.3/32
wg-quick save wg0
```
3. 创建第二个客户端配置（使用 10.0.0.3 作为地址）
---
## 性能优化
### 1. MTU 优化
在客户端配置中添加：
```
[Interface]
MTU = 1420
```
### 2. 使用更快的加密算法
WireGuard 默认使用的加密算法已经很快，通常不需要调整。
### 3. 服务器性能调优
创建 `/etc/sysctl.d/wireguard.conf`：
```
net.core.rmem_max = 2500000
net.core.wmem_max = 2500000
net.ipv4.tcp_rmem = 4096 87380 2500000
net.ipv4.tcp_wmem = 4096 65536 2500000
```
应用：
```bash
sysctl -p /etc/sysctl.d/wireguard.conf
```
---
## 故障排查
### 问题1：无法连接
- 检查服务器防火墙：`ufw status`
- 检查 WireGuard 是否运行：`systemctl status wg-quick@wg0`
- 查看 WireGuard 状态：`wg show`
- 验证密钥是否正确
### 问题2：连接成功但无法上网
- 检查 IP 转发是否启用：`sysctl net.ipv4.ip_forward`
- 检查 iptables 规则
- 验证 DNS 设置
### 问题3：速度慢
- 尝试优化 MTU 设置
- 启用 BBR（已在前面配置）
- 检查服务器资源使用：`top`
- 考虑更换更近的区域
### 查看日志
```bash
journalctl -u wg-quick@wg0 -f
```
---
## 安全加固建议
1. **禁用 SSH 密码登录，只使用密钥**
2. **更改 SSH 端口**
3. **安装 Fail2Ban**：`apt install fail2ban -y`
4. **定期更新系统**：`apt update && apt upgrade -y`
5. **使用非默认 WireGuard 端口**（修改 ListenPort）
---
*操作手册版本：1.0*
jiangwei-platform/research/canada-proxy-research/云服务商详细对比表.md
+254
View File
@@ -0,0 +1,254 @@
# 加拿大区域云服务商详细对比表
## 综合对比总览
| 服务商 | 价格优势 | 网络质量 | 易用性 | 备案要求 | 支付方式 | 推荐指数 |
|--------|---------|---------|--------|---------|---------|---------|
| Linode | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | 不需要 | 信用卡/PayPal | ⭐⭐⭐⭐⭐ |
| DigitalOcean | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | 不需要 | 信用卡/PayPal | ⭐⭐⭐⭐ |
| Vultr | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | 不需要 | 信用卡/PayPal/支付宝 | ⭐⭐⭐⭐ |
| AWS | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | 不需要 | 信用卡 | ⭐⭐⭐⭐ |
| Azure | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | 不需要 | 信用卡 | ⭐⭐⭐⭐ |
| GCP | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | 不需要 | 信用卡 | ⭐⭐⭐⭐ |
---
## Linode (Toronto)
### 基本信息
- **成立时间**：2003年
- **公司总部**：美国
- **加拿大区域**：Toronto, ON
- **数据中心数量**：1个
### 价格详情
| 配置 | vCPU | 内存 | 存储 | 月价格 | 流量 |
|------|------|------|------|--------|------|
| Nanode | 1 | 1GB | 25GB | $5 | 1TB |
| Linode 2GB | 1 | 2GB | 50GB | $10 | 2TB |
| Linode 4GB | 2 | 4GB | 80GB | $20 | 4TB |
| Linode 8GB | 4 | 8GB | 160GB | $40 | 5TB |
### 优点
- ✅ 性价比极高
- ✅ 界面简洁友好
- ✅ 部署快速（通常 < 2 分钟）
- ✅ 稳定可靠
- ✅ 账单清晰
- ✅ 支持一键部署应用
### 缺点
- ❌ 只有一个多伦多数据中心
- ❌ 没有免费套餐
- ❌ 功能相对简单
### 适用场景
- 个人使用
- 中小型项目
- 需要高性价比的场景
---
## DigitalOcean (Toronto)
### 基本信息
- **成立时间**：2011年
- **公司总部**：美国纽约
- **加拿大区域**：Toronto 1
- **数据中心数量**：1个
### 价格详情
| 配置 | vCPU | 内存 | 存储 | 月价格 | 流量 |
|------|------|------|------|--------|------|
| Basic | 1 | 1GB | 25GB | $6 | 1TB |
| Basic | 1 | 2GB | 50GB | $12 | 2TB |
| Basic | 2 | 4GB | 80GB | $24 | 4TB |
| Basic | 2 | 8GB | 160GB | $48 | 5TB |
### 优点
- ✅ 用户体验优秀
- ✅ 有丰富的一键镜像（Marketplace）
- ✅ 社区活跃，文档丰富
- ✅ 支持团队协作
- ✅ 部署非常快速
### 缺点
- ❌ 价格略高于 Linode
- ❌ 超售情况有时发生
- ❌ 网络偶有波动
### 适用场景
- 开发者
- 需要丰富镜像的用户
- 团队协作
---
## Vultr (Toronto)
### 基本信息
- **成立时间**：2014年
- **公司总部**：美国新泽西
- **加拿大区域**：Toronto
- **数据中心数量**：1个
### 价格详情
| 配置 | vCPU | 内存 | 存储 | 月价格 | 流量 |
|------|------|------|------|--------|------|
| Cloud Compute | 1 | 1GB | 25GB | $6 | 1TB |
| Cloud Compute | 1 | 2GB | 55GB | $12 | 2TB |
| Cloud Compute | 2 | 4GB | 80GB | $24 | 3TB |
| Cloud Compute | 2 | 8GB | 160GB | $48 | 4TB |
### 优点
- ✅ 支持支付宝（对国内用户友好）
- ✅ 小时计费
- ✅ 有 $100 试用额度（新用户）
- ✅ 支持自定义 ISO
- ✅ 数据中心多（全球 30+）
### 缺点
- ❌ 后台界面相对复杂
- ❌ 有时会遇到 IP 被封禁问题
- ❌ 新用户验证较严格
### 适用场景
- 习惯用支付宝的用户
- 需要临时测试的用户
- 全球多区域部署
---
## AWS (ca-central-1 - Montreal)
### 基本信息
- **公司**：Amazon
- **加拿大区域**：加拿大中部（蒙特利尔）
- **可用区**：3个
- **成立时间**：2016年开服
### 价格详情（按需）
| 实例类型 | vCPU | 内存 | 月价格估算 | 备注 |
|---------|------|------|-----------|------|
| t3.micro | 2 | 1GB | ~$10 | eligible for free tier |
| t3.small | 2 | 2GB | ~$20 | |
| t3.medium | 2 | 4GB | ~$40 | |
### 优点
- ✅ 最稳定可靠
- ✅ 3个可用区，支持高可用
- ✅ 生态系统最完善
- ✅ 企业级支持
- ✅ 免费套餐（t3.micro 12个月免费）
### 缺点
- ❌ 价格相对较高
- ❌ 控制台复杂，学习曲线陡峭
- ❌ 账单复杂，容易产生意外费用
- ❌ 需要绑定信用卡
### 适用场景
- 企业级应用
- 需要高可用性的场景
- 已经在使用 AWS 生态的用户
---
## Azure (Canada Central - Toronto)
### 基本信息
- **公司**：Microsoft
- **加拿大区域**：Canada Central（多伦多）, Canada East（魁北克城）
- **可用区**：各3个
### 价格详情（按需）
| 实例类型 | vCPU | 内存 | 月价格估算 |
|---------|------|------|-----------|
| B1s | 1 | 1GB | ~$9 |
| B1ms | 1 | 2GB | ~$18 |
| B2s | 2 | 4GB | ~$36 |
### 优点
- ✅ 与 Microsoft 产品集成好
- ✅ 企业级服务
- ✅ 多个区域选择
- ✅ 有免费试用额度
### 缺点
- ❌ 价格较高
- ❌ 界面复杂
- ❌ 容易产生额外费用
### 适用场景
- 企业用户
- 使用 Microsoft 生态的用户
---
## Google Cloud Platform (northamerica-northeast1 - Montreal)
### 基本信息
- **公司**：Google
- **加拿大区域**：Montreal
- **可用区**：3个
### 价格详情（按需）
| 实例类型 | vCPU | 内存 | 月价格估算 |
|---------|------|------|-----------|
| e2-micro | 2 | 1GB | ~$8 |
| e2-small | 2 | 2GB | ~$16 |
| e2-medium | 2 | 4GB | ~$32 |
### 优点
- ✅ Google 网络质量优秀
- ✅ 价格合理
- ✅ 300美元免费额度
- ✅ 持续使用折扣
### 缺点
- ❌ 文档相对较少
- ❌ 生态不如 AWS/Azure
- ❌ 控制台需要适应
### 适用场景
- 需要 Google 网络质量的用户
- 喜欢 Google 技术栈的用户
---
## 选择建议
### 个人使用/测试
**首选：Linode Toronto ($5/月)**
- 理由：性价比最高，界面简单，稳定可靠
**备选：Vultr Toronto ($6/月)**
- 理由：支持支付宝，有试用额度
### 企业使用/生产环境
**首选：AWS ca-central-1**
- 理由：最稳定，有 SLA 保障，生态完善
**备选：Azure Canada Central**
- 理由：企业级服务，与 Microsoft 产品集成好
### 需要支付宝
**首选：Vultr Toronto**
- 理由：直接支持支付宝付款
---
## 付款方式对比
| 服务商 | 信用卡 | PayPal | 支付宝 | 微信支付 |
|--------|--------|--------|--------|---------|
| Linode | ✅ | ✅ | ❌ | ❌ |
| DigitalOcean | ✅ | ✅ | ❌ | ❌ |
| Vultr | ✅ | ✅ | ✅ | ❌ |
| AWS | ✅ | ❌ | ❌ | ❌ |
| Azure | ✅ | ❌ | ❌ | ❌ |
| GCP | ✅ | ❌ | ❌ | ❌ |
---
*对比表更新时间：2026年3月*
jiangwei-platform/research/canada-proxy-research/加拿大云主机中转方案调研报告.md
+388
View File
@@ -0,0 +1,388 @@
# 加拿大云主机中转方案调研报告
## 1. 概述
本报告对加拿大区域的云主机中转方案进行了全面调研，涵盖云服务商选择、技术方案选型、实施步骤、成本估算以及风险提示。
---
## 2. 云服务商选择与价格对比
### 2.1 主要云服务商加拿大区域概况
| 云服务商 | 加拿大区域 | 可用区数量 | 主要城市 |
|---------|----------|----------|---------|
| AWS | ca-central-1 | 3 | 蒙特利尔 |
| Azure | Canada Central, Canada East | 各3个 | 多伦多, 魁北克城 |
| GCP | northamerica-northeast1 | 3 | 蒙特利尔 |
| DigitalOcean | Toronto 1 | 1 | 多伦多 |
| Vultr | Toronto | 1 | 多伦多 |
| Linode | Toronto | 1 | 多伦多 |
### 2.2 价格对比（基础配置实例）
#### AWS (ca-central-1)
| 实例类型 | vCPU | 内存 | 月费用 (按需) | 月费用 (预留1年) |
|---------|------|------|--------------|----------------|
| t3.micro | 2 | 1GB | ~$10 | ~$6 |
| t3.small | 2 | 2GB | ~$20 | ~$12 |
| t3.medium | 2 | 4GB | ~$40 | ~$24 |
#### Azure (Canada Central)
| 实例类型 | vCPU | 内存 | 月费用 (按需) | 月费用 (预留1年) |
|---------|------|------|--------------|----------------|
| B1s | 1 | 1GB | ~$9 | ~$5 |
| B1ms | 1 | 2GB | ~$18 | ~$10 |
| B2s | 2 | 4GB | ~$36 | ~$20 |
#### GCP (northamerica-northeast1)
| 实例类型 | vCPU | 内存 | 月费用 (按需) | 月费用 (预留1年) |
|---------|------|------|--------------|----------------|
| e2-micro | 2 | 1GB | ~$8 | ~$5 |
| e2-small | 2 | 2GB | ~$16 | ~$10 |
| e2-medium | 2 | 4GB | ~$32 | ~$19 |
#### DigitalOcean (Toronto)
| 配置 | vCPU | 内存 | 月费用 |
|------|------|------|--------|
| Basic | 1 | 1GB | $6 |
| Basic | 1 | 2GB | $12 |
| Basic | 2 | 4GB | $24 |
#### Vultr (Toronto)
| 配置 | vCPU | 内存 | 月费用 |
|------|------|------|--------|
| Cloud Compute | 1 | 1GB | $6 |
| Cloud Compute | 1 | 2GB | $12 |
| Cloud Compute | 2 | 4GB | $24 |
#### Linode (Toronto)
| 配置 | vCPU | 内存 | 月费用 |
|------|------|------|--------|
| Nanode | 1 | 1GB | $5 |
| Linode 2GB | 1 | 2GB | $10 |
| Linode 4GB | 2 | 4GB | $20 |
---
## 2.3 CN2 GIA 说明
### 2.3.1 基本概念
CN2 GIA（China Telecom Next Generation Carrier Network - Global Internet Access）是**中国电信**推出的优质国际专线产品，专为需要高速、稳定国际访问的用户设计。
### 2.3.2 核心优势对比
| 特性 | 普通路由 | CN2 GIA |
|------|----------|----------|
| **延迟** | 180-250ms | 120-160ms |
| **丢包率** | 0.5%-3% | <0.5% |
| **稳定性** | 高峰时段可能拥堵 | 高峰时段依然稳定 |
| **价格** | 便宜（包含在普通宽带中） | 较贵（需额外付费办理） |
### 2.3.3 适用场景
- 需要稳定访问国际服务（如 Google、AWS 等）
- 对延迟和丢包率要求高（如高频交易、远程办公）
- 普通路由无法满足需求时
---
## 3. 技术方案选型
### 3.1 可选技术方案对比
| 方案类型 | 优点 | 缺点 | 适用场景 |
|---------|------|------|---------|
| SSH 隧道 | 配置简单，无需额外软件，加密性好 | 单端口转发，需要保持连接 | 临时使用，开发调试 |
| SOCKS5 代理 | 灵活，支持多种应用 | 需要客户端配置 | 浏览器、部分应用 |
| VPN (OpenVPN/WireGuard) | 全流量转发，安全性高 | 配置略复杂 | 长期稳定使用 |
| Shadowsocks | 轻量，快速，易于部署 | 协议特点可能受限制 | 个人使用 |
| V2Ray/Xray | 功能强大，支持多种协议 | 配置相对复杂 | 需要高级功能 |
### 3.2 推荐方案
综合考虑易用性、稳定性、性能和安全性，推荐以下方案：
#### 首选方案：WireGuard VPN
- **理由**：
- 现代、轻量、高性能
- 配置相对简单
- 内核级支持，性能优异
- 跨平台支持好
#### 备选方案：Shadowsocks + v2ray-plugin
- **理由**：
- 部署快速
- 资源占用小
- 在特定网络环境下表现良好
### 3.3 Clash/ClashX 配置方案
#### 适用场景
- **Clash**：Windows/Linux 客户端
- **ClashX**：macOS 客户端
- 支持多协议（Shadowsocks、VMess、Trojan 等）
- 支持规则分流、节点管理
#### 服务器端配置（以 Shadowsocks 为例）
与 4.3 Shadowsocks 实施方案相同，先配置好服务器端 Shadowsocks。
#### 客户端配置（Clash/ClashX）
1. **下载安装客户端**
- Clash：https://github.com/Dreamacro/clash/releases
- ClashX（macOS）：https://github.com/yichengchen/clashX/releases
2. **创建配置文件**（`config.yaml`）
```yaml
port: 7890
socks-port: 7891
allow-lan: true
mode: Rule
log-level: info
external-controller: 127.0.0.1:9090
proxies:
- name: "Canada-Linode"
type: ss
server: <服务器IP>
port: 8388
cipher: chacha20-ietf-poly1305
password: "your-strong-password"
proxy-groups:
- name: "PROXY"
type: select
proxies:
- "Canada-Linode"
rules:
- DOMAIN-SUFFIX,google.com,PROXY
- DOMAIN-SUFFIX,gstatic.com,PROXY
- DOMAIN-SUFFIX,youtube.com,PROXY
- MATCH,DIRECT
```
3. **导入配置文件**
- Clash：启动后选择配置文件
- ClashX：拖拽 `config.yaml` 到菜单栏图标
4. **启动代理**
- 开启系统代理（HTTP/HTTPS/SOCKS5）
- 配置代理端口为 7890（HTTP）或 7891（SOCKS5）
---
## 4. 端到端实施步骤
### 4.1 准备工作
1. **选择云服务商并注册账号**
2. **创建加拿大区域的云主机实例**
- 推荐配置：1GB 内存，1 vCPU，20GB 存储
- 操作系统：Ubuntu 22.04 LTS 或 Debian 12
3. **配置安全组/防火墙**
- 开放 SSH 端口 (22)
- 开放 VPN/代理所需端口
### 4.2 WireGuard 实施方案
#### 服务器端配置
1. **更新系统并安装 WireGuard**
```bash
sudo apt update && sudo apt upgrade -y
sudo apt install wireguard -y
```
2. **生成密钥对**
```bash
wg genkey | tee privatekey | wg pubkey > publickey
```
3. **创建 WireGuard 配置文件**
```bash
sudo nano /etc/wireguard/wg0.conf
```
配置内容示例：
```
[Interface]
PrivateKey = <服务器私钥>
Address = 10.0.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
[Peer]
PublicKey = <客户端公钥>
AllowedIPs = 10.0.0.2/32
```
4. **启用并启动 WireGuard**
```bash
sudo systemctl enable wg-quick@wg0
sudo systemctl start wg-quick@wg0
```
#### 客户端配置
1. **安装 WireGuard 客户端**
- Windows/macOS: 从官网下载
- Linux: `sudo apt install wireguard`
- iOS/Android: 从应用商店下载
2. **创建客户端配置文件**
```
[Interface]
PrivateKey = <客户端私钥>
Address = 10.0.0.2/24
DNS = 8.8.8.8, 8.8.4.4
[Peer]
PublicKey = <服务器公钥>
Endpoint = <服务器IP>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
```
### 4.3 Shadowsocks 实施方案（备选）
#### 服务器端配置
1. **安装 Shadowsocks-libev**
```bash
sudo apt update
sudo apt install shadowsocks-libev -y
```
2. **创建配置文件**
```bash
sudo nano /etc/shadowsocks-libev/config.json
```
配置内容：
```json
{
"server": "0.0.0.0",
"server_port": 8388,
"password": "your-strong-password",
"method": "chacha20-ietf-poly1305",
"timeout": 300
}
```
3. **启动服务**
```bash
sudo systemctl enable shadowsocks-libev
sudo systemctl start shadowsocks-libev
```
---
## 5. 成本估算
### 5.1 基础方案成本
| 项目 | 低成本方案 | 标准方案 | 高可用方案 |
|------|----------|---------|----------|
| 云主机 | $5-$6/月 | $10-$12/月 | $20-$24/月 |
| 带宽 (1TB) | 通常包含 | 通常包含 | 通常包含 |
| 存储 | 20GB | 40GB | 80GB |
| **月总计** | **$5-$6** | **$10-$12** | **$20-$24** |
### 5.2 成本优化建议
1. **选择合适的配置**：对于中转服务，1GB 内存通常足够
2. **使用预留实例**：长期使用可节省 30-50% 成本
3. **监控流量使用**：避免超出免费流量额度
4. **考虑多家服务商**：促销期间价格差异较大
---
## 6. 需要注意的问题
### 6.1 法律法规
- **加拿大本地法律**：
- 遵守加拿大《个人信息保护和电子文档法》(PIPEDA)
- 注意数据留存相关规定
- **使用场景合规**：
- 确保使用目的合法合规
- 不用于任何非法活动
- 尊重版权和知识产权
### 6.2 稳定性 considerations
- **网络稳定性**：
- 监控服务器状态和网络延迟
- 考虑使用多台服务器做冗余
- 选择有多个可用区的云服务商
- **服务可用性**：
- 设置自动重启机制
- 配置监控告警
- 定期备份配置
### 6.3 安全性
- **服务器安全**：
- 及时更新系统补丁
- 使用 SSH 密钥登录，禁用密码登录
- 配置防火墙，只开放必要端口
- 考虑使用 Fail2Ban 防止暴力破解
- **传输安全**：
- 使用强加密算法
- 定期更换密钥和密码
- 避免使用默认端口
### 6.4 性能优化
- **选择合适的区域**：根据您的位置选择网络延迟最低的加拿大区域
- **优化 MTU 设置**：调整最大传输单元以获得最佳性能
- **使用 BBR 拥塞控制**：启用 TCP BBR 提高传输速度
---
## 7. 推荐方案总结
### 7.1 推荐组合
1. **云服务商**：Linode Toronto 或 DigitalOcean Toronto（性价比高）
2. **技术方案**：WireGuard VPN（性能好，配置简单）
3. **实例配置**：1GB 内存，1 vCPU（足够中转使用）
### 7.2 实施Checklist
- [ ] 注册云服务商账号
- [ ] 创建加拿大区域实例
- [ ] 配置安全组/防火墙
- [ ] 登录服务器并更新系统
- [ ] 安装并配置 WireGuard
- [ ] 生成密钥对
- [ ] 配置客户端
- [ ] 测试连接
- [ ] 设置监控和自动重启
- [ ] 定期备份配置
---
## 8. 附录
### 8.1 有用的资源
- WireGuard 官方文档：https://www.wireguard.com/
- Shadowsocks 文档：https://shadowsocks.org/
- AWS 加拿大区域：https://aws.amazon.com/ca/
- Azure 加拿大区域：https://azure.microsoft.com/en-ca/
### 8.2 故障排查
- 检查防火墙设置
- 验证密钥是否正确
- 查看服务日志
- 测试网络连通性
---
*报告生成时间：2026年3月*
jiangwei-platform/research/canada-proxy-research/快速入门指南.md
+175
View File
@@ -0,0 +1,175 @@
# 快速入门指南
> 🚀 10分钟快速部署加拿大中转服务器
---
## 第一步：选择云服务商（2分钟）
### 推荐选择
- **首选：Linode Toronto** ($5/月)
- 性价比最高
- 界面简单
- 稳定可靠
- **备选：Vultr Toronto** ($6/月)
- 支持支付宝
- 有 $100 试用金
### 注册账号
- Linode：https://www.linode.com/
- Vultr：https://www.vultr.com/
---
## 第二步：创建服务器实例（3分钟）
### 配置选项
1. **区域（Region）**：选择 Toronto / Canada
2. **操作系统（OS）**：Ubuntu 22.04 LTS
3. **配置（Plan）**：选择最便宜的 $5-$6 套餐（1GB 内存）
4. **其他选项**：默认即可
5. **创建（Deploy）**
### 获取登录信息
- 服务器 IP 地址
- root 密码（或上传 SSH 密钥）
---
## 第三步：服务器初始化（3分钟）
### 登录服务器
```bash
ssh root@your-server-ip
```
### 一键脚本（推荐）
执行以下命令一键完成所有配置：
```bash
# 更新系统
apt update && apt upgrade -y
# 安装 WireGuard
apt install wireguard -y
# 启用 IP 转发
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p
# 启用 BBR
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p
# 配置防火墙
apt install ufw -y
ufw allow 22/tcp
ufw allow 51820/udp
ufw --force enable
# 生成密钥
mkdir -p /etc/wireguard/keys
cd /etc/wireguard/keys
wg genkey | tee server_privatekey | wg pubkey > server_publickey
wg genkey | tee client1_privatekey | wg pubkey > client1_publickey
# 显示密钥
echo "=========================================="
echo "请保存以下密钥："
echo "服务器私钥: $(cat server_privatekey)"
echo "服务器公钥: $(cat server_publickey)"
echo "客户端私钥: $(cat client1_privatekey)"
echo "客户端公钥: $(cat client1_publickey)"
echo "=========================================="
```
---
## 第四步：配置 WireGuard（2分钟）
### 创建服务器配置文件
```bash
nano /etc/wireguard/wg0.conf
```
### 复制以下内容并替换密钥
```
[Interface]
PrivateKey = <服务器私钥>
Address = 10.0.0.1/24
ListenPort = 51820
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
SaveConfig = true
[Peer]
PublicKey = <客户端公钥>
AllowedIPs = 10.0.0.2/32
```
### 启动 WireGuard
```bash
chmod 600 /etc/wireguard/wg0.conf
systemctl enable wg-quick@wg0
systemctl start wg-quick@wg0
wg show
```
---
## 第五步：配置客户端（2分钟）
### 下载 WireGuard 客户端
- **Windows/macOS**: https://www.wireguard.com/download/
- **iOS**: App Store 搜索 "WireGuard"
- **Android**: Google Play 搜索 "WireGuard"
### 创建客户端配置
```
[Interface]
PrivateKey = <客户端私钥>
Address = 10.0.0.2/24
DNS = 8.8.8.8, 1.1.1.1
[Peer]
PublicKey = <服务器公钥>
Endpoint = <服务器IP>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
```
### 激活连接
点击 "Activate" 或 "激活" 按钮
---
## 完成！🎉
现在您应该可以使用加拿大中转服务器了。
---
## 常见问题
### Q: 连接成功但无法上网？
A: 检查 IP 转发是否启用：`sysctl net.ipv4.ip_forward`，确认返回 1。
### Q: 无法连接到服务器？
A: 检查防火墙设置：`ufw status`，确认 51820/udp 端口已开放。
### Q: 速度很慢？
A: 确认已启用 BBR，尝试优化 MTU 设置（在客户端配置中添加 `MTU = 1420`）。
---
## 下一步
- 阅读《WireGuard详细操作手册.md》了解更多配置
- 查看《风险提示与注意事项.md》确保安全使用
- 根据《云服务商详细对比表.md》选择最适合您的服务商
---
*快速入门指南版本：1.0*
jiangwei-platform/research/canada-proxy-research/风险提示与注意事项.md
+294
View File
@@ -0,0 +1,294 @@
# 风险提示与注意事项
## ⚠️ 重要声明
本报告仅供技术研究和学习交流使用。使用任何中转服务时，请严格遵守当地法律法规，不得用于任何非法用途。
---
## 一、法律法规风险
### 1.1 加拿大相关法律法规
#### 个人信息保护
- **《个人信息保护和电子文档法》(PIPEDA)**
- 规范私人机构如何收集、使用和披露个人信息
- 适用于所有在加拿大商业活动中处理个人信息的组织
#### 数据留存
- 加拿大没有强制的数据本地化法律
- 但某些特定行业可能有特殊要求
- 建议了解您所在行业的具体规定
#### 电信法规
- 加拿大广播电视及电信委员会 (CRTC) 监管电信行业
- 某些通信服务可能需要获得许可
### 1.2 用户所在国家/地区法律
⚠️ **重要提示**：
- 您必须同时遵守加拿大法律和您所在国家/地区的法律
- 不同国家对中转服务的规定差异很大
- 请在使用前咨询专业法律意见
### 1.3 合规使用建议
✅ **合法使用场景**：
- 远程办公和访问公司资源
- 跨国业务交流
- 学习和研究目的
- 合法的内容访问
❌ **禁止使用场景**：
- 任何形式的非法活动
- 侵犯版权和知识产权
- 网络攻击或恶意行为
- 散布非法内容
- 逃避合法的监管
---
## 二、技术风险
### 2.1 服务器安全风险
#### 常见安全威胁
- **暴力破解攻击**：SSH、VPN 账户密码被尝试破解
- **DDoS 攻击**：服务器被大规模流量攻击
- **漏洞利用**：未及时修补的系统漏洞被利用
- **中间人攻击**：传输过程中数据被窃取
#### 安全加固措施
1. **SSH 安全**
```bash
# 禁用密码登录，只使用密钥
PasswordAuthentication no
# 更改默认 SSH 端口
Port 22222
# 禁止 root 直接登录
PermitRootLogin no
# 使用 Fail2Ban 防止暴力破解
apt install fail2ban -y
```
2. **防火墙配置**
```bash
# 只开放必要的端口
ufw allow 22222/tcp # SSH
ufw allow 51820/udp # WireGuard
ufw default deny incoming
ufw enable
```
3. **定期更新**
```bash
# 设置自动安全更新
apt install unattended-upgrades -y
dpkg-reconfigure -plow unattended-upgrades
```
### 2.2 网络稳定性风险
#### 可能遇到的问题
- 服务器 IP 被封禁
- 网络路由不稳定
- 带宽受限
- 服务商网络维护
#### 应对措施
- 准备备用服务器
- 使用监控服务（如 UptimeRobot）
- 选择有多个数据中心的服务商
- 定期备份配置
### 2.3 数据安全风险
#### 数据泄露风险
- 服务器被入侵导致数据泄露
- 日志记录包含敏感信息
- 第三方服务商数据泄露
#### 保护措施
- 不要在服务器上存储敏感数据
- 加密重要数据
- 定期清理日志
- 选择有良好隐私政策的服务商
---
## 三、运营风险
### 3.1 服务中断风险
#### 可能原因
- 云服务商故障
- 数据中心维护
- DDoS 攻击
- 账户问题
#### 应对策略
- 建立监控告警（邮件、短信通知）
- 准备备用方案
- 定期备份配置和数据
- 了解服务商的 SLA 政策
### 3.2 成本风险
#### 可能的额外费用
- 超出流量限制的费用
- 存储费用
- 备份费用
- 技术支持费用
#### 成本控制建议
- 选择合适的套餐，不要过度配置
- 设置账单告警
- 监控资源使用情况
- 利用预留实例或长期优惠
### 3.3 账户风险
#### 可能问题
- 账户被冻结
- 支付问题
- 验证失败
#### 预防措施
- 使用稳定的支付方式
- 保持账户信息更新
- 保存好账号凭证
- 了解服务商的服务条款
---
## 四、隐私风险
### 4.1 日志记录
#### 服务商可能记录的信息
- 连接时间和时长
- 流量使用量
- 源 IP 地址
- 连接协议信息
#### 保护隐私的建议
- 了解服务商的隐私政策
- 选择有明确隐私保护的服务商
- 不要在传输中包含明文敏感信息
- 使用端到端加密
### 4.2 数据留存
#### 建议做法
- 定期清理服务器日志
- 配置日志轮转
- 不要长期保留不必要的数据
- 删除服务器前彻底擦除数据
---
## 五、性能风险
### 5.1 网络延迟
#### 影响因素
- 物理距离
- 网络路由
- 带宽限制
- 服务器负载
#### 优化建议
- 选择离您最近的加拿大区域
- 测试不同服务商的网络质量
- 优化 MTU 设置
- 启用 BBR 拥塞控制
### 5.2 带宽限制
#### 注意事项
- 了解套餐的流量限制
- 监控流量使用情况
- 超出流量可能产生额外费用
- 考虑使用流量压缩
---
## 六、应急处理预案
### 6.1 服务器无法连接
#### 排查步骤
1. 检查网络连接（本地网络是否正常）
2. 确认服务器是否运行（通过云服务商控制台）
3. 检查防火墙设置
4. 查看服务日志
5. 尝试通过控制台 VNC 连接
### 6.2 服务器被入侵
#### 应急处理
1. 立即断开网络连接（或停止服务器）
2. 保存现有日志作为证据
3. 重建服务器（不要尝试修复）
4. 使用新的密钥和密码
5. 检查其他服务器是否也被入侵
### 6.3 账户被冻结
#### 应对措施
1. 联系客服了解原因
2. 准备好身份证明材料
3. 如果有数据，请求导出
4. 考虑迁移到备用服务商
---
## 七、最佳实践清单
### 7.1 安全检查清单
- [ ] 使用 SSH 密钥登录，禁用密码
- [ ] 更改默认 SSH 端口
- [ ] 配置防火墙，只开放必要端口
- [ ] 安装 Fail2Ban
- [ ] 启用自动安全更新
- [ ] 定期备份重要数据
- [ ] 使用强密码或密钥
- [ ] 定期检查日志
### 7.2 运营检查清单
- [ ] 设置监控告警
- [ ] 准备备用方案
- [ ] 了解服务商 SLA
- [ ] 设置账单告警
- [ ] 定期备份配置
- [ ] 保存服务商联系方式
- [ ] 了解退款政策
### 7.3 合规检查清单
- [ ] 了解相关法律法规
- [ ] 确保使用目的合法
- [ ] 不从事任何非法活动
- [ ] 尊重版权和知识产权
- [ ] 咨询专业法律意见（如有需要）
---
## 八、总结
使用加拿大云主机中转服务需要谨慎考虑多方面的风险。最重要的是：
1. **合法合规**：始终遵守相关法律法规
2. **安全第一**：做好服务器安全加固
3. **准备充分**：有应急预案和备用方案
4. **持续监控**：定期检查服务状态和安全情况
5. **保持学习**：关注最新的安全动态和最佳实践
---
*本风险提示仅供参考，不构成法律建议。如有法律问题，请咨询专业律师。*
*文档版本：1.0 | 更新时间：2026年3月*
jiangwei-platform/research/joinquant_articles/analysis_report.md
+273
View File
@@ -0,0 +1,273 @@
# 聚宽社区回测与实盘文章分析报告
**分析时间**：2026年3月25日
**分析人员**：姜维（子agent）
**任务目标**：筛选5篇回测/实盘相关文章，提炼核心观点，总结对框架改进的价值
---
## 一、文章筛选与概览
### 筛选标准
- 主题：回测框架优化、实盘交易经验
- 质量：社区高赞、实用性强
- 领域：覆盖回测优化、回测陷阱、实盘风控等
### 选定文章列表
| 序号 | 文章标题 | 分类 | 核心方向 |
|------|---------|------|---------|
| 1 | 高效使用聚宽回测平台的技巧 | 回测框架 | 平台使用优化 |
| 2 | 聚宽策略性能优化实战指南 | 回测框架 | 代码性能优化 |
| 3 | 量化回测中的常见陷阱及规避方法 | 回测框架 | 回测质量控制 |
| 4 | 从回测到实盘：聚宽实盘交易入门指南 | 实盘经验 | 实盘流程 |
| 5 | 聚宽实盘交易中的常见问题与解决方案 | 实盘经验 | 实盘问题解决 |
---
## 二、各篇文章核心观点提炼
### 文章1：高效使用聚宽回测平台的技巧
**核心观点**：
1. **合理设置回测参数**
- 策略开发初期：使用较短时间范围（1-2年）和日频数据快速迭代
- 策略验证阶段：使用较长时间范围（3-5年）和分钟级数据验证
- 避免一开始就使用全量历史数据进行回测
2. **数据获取优化**
- 充分利用聚宽的数据缓存机制
- 将常用数据预处理逻辑封装成函数
- 批量获取数据，避免在循环中重复调用数据API
3. **回测效率提升**
- 使用历史回放功能验证策略逻辑，而非全量回测
- 利用聚宽的`history`函数进行批量数据获取
- 合理设置回测频率，平衡精度和速度
**实践案例**：
某量化团队通过将日频回测中的数据获取从循环内移到循环外，回测速度提升了5倍以上。
---
### 文章2：聚宽策略性能优化实战指南
**核心观点**：
1. **避免在handle_data中进行耗时计算**
- 将复杂计算移到`before_trading_start`或`after_trading_end`
- handle_data中只保留必要的交易决策逻辑
2. **合理使用缓存机制**
- 使用全局变量缓存中间结果
- 避免重复计算相同的技术指标
3. **向量化操作替代循环**
- 使用Pandas的向量化操作
- 利用TA-Lib库替代自行实现的指标计算
- 避免Python原生循环
4. **减少不必要的输出**
- 策略逻辑与数据记录分离
- 只记录关键指标，减少I/O操作
**实践案例**：
一位聚宽用户通过将技术指标计算从`handle_data`移到`before_trading_start`，并使用TA-Lib库，策略回测速度从30分钟缩短到5分钟。
---
### 文章3：量化回测中的常见陷阱及规避方法
**核心观点**：
1. **警惕过拟合**
- 使用样本外数据验证策略稳健性
- 避免过度优化参数
- 采用"三段式"回测验证：训练集（60%）、验证集（20%）、测试集（20%）
2. **避免幸存者偏差**
- 确保回测使用包含退市股票的完整数据集
- 聚宽平台提供了完整的历史数据集，需正确配置
3. **防止未来函数**
- 仔细检查策略逻辑，避免使用未来数据
- 使用当前时点可获得的数据进行决策
4. **合理设置交易成本**
- 不要低估交易成本和滑点
- 根据不同市场和策略类型设置合理的成本参数
**实践案例**：
某资深量化投资者建议：只有在三个数据集上表现都稳定的策略才考虑实盘，且策略在样本外的表现不应比样本内差太多。
---
### 文章4：从回测到实盘：聚宽实盘交易入门指南
**核心观点**：
1. **实盘与回测的差异**
- 市场环境变化：历史不会简单重复
- 执行差异：滑点、订单成交率等
- 心理因素：实盘时的情绪影响
2. **渐进式实盘上线**
- 模拟交易验证（3-6个月）
- 小资金实盘（总资金的5-10%）
- 逐步加仓（验证稳定后）
3. **建立监控和风控机制**
- 实时监控策略表现
- 设置止损和风险限额
- 建立异常告警机制
4. **保持执行一致性**
- 制定详细的实盘操作手册
- 避免情绪化操作
- 定期回顾评估，但不要频繁调整
**实践案例**：
某量化团队的实盘上线流程：每个阶段都有明确的通过标准，如模拟交易阶段最大回撤不超过5%，夏普比率大于2等。
---
### 文章5：聚宽实盘交易中的常见问题与解决方案
**核心观点**：
1. **订单执行问题**
- 合理设置订单类型和价格
- 分批下单，减少单笔订单的市场冲击
- 考虑使用算法交易执行大单
2. **系统稳定性**
- 建立备用系统和人工干预机制
- 监控网络连接和系统状态
- 准备应急方案
3. **市场冲击成本**
- 评估策略容量，避免资金规模过大
- 优化下单时机和方式
- 考虑流动性因素
4. **监控与复核**
- 实盘初期每天进行人工复核
- 建立"熔断机制"：单日亏损超阈值自动停止
- 定期检查订单执行情况
**实践案例**：
一位资深实盘交易者建议：在实盘前进行至少一个月的"仿真交易"，完全模拟实盘环境但不实际下单，验证系统和策略的稳定性。
---
## 三、对我们框架改进的价值总结
### 3.1 回测框架优化方向
#### 1. 性能优化模块
- **建议1**：实现分层回测机制
- 快速回测模式（日频、短周期）用于策略开发
- 精确回测模式（分钟级、长周期）用于策略验证
- **建议2**：建立数据缓存层
- 缓存常用的历史数据和计算结果
- 支持数据预加载和批量获取
#### 2. 代码优化工具
- **建议3**：开发策略性能分析工具
- 自动识别策略中的性能瓶颈
- 提供优化建议（如向量化替代循环）
- **建议4**：提供最佳实践模板
- 标准化策略代码结构
- 分离计算逻辑和交易逻辑
#### 3. 回测质量保证
- **建议5**：集成回测陷阱检测
- 自动检测潜在的未来函数
- 检查过拟合风险（参数敏感性分析）
- **建议6**：建立"回测体检"清单
- 数据质量检查
- 回测设置验证
- 风险指标分析
- 交易明细抽查
---
### 3.2 实盘框架改进方向
#### 1. 实盘上线流程标准化
- **建议7**：建立渐进式上线流程
- 模拟交易阶段标准
- 小资金实盘阶段标准
- 全资金实盘阶段标准
- **建议8**：开发实盘 readiness 检查清单
- 策略稳定性验证
- 系统可靠性检查
- 风控机制完备性
#### 2. 实盘监控与风控
- **建议9**：建立实时监控系统
- 策略表现监控（收益、回撤、换手等）
- 订单执行监控（成交率、滑点等）
- 风险指标监控（敞口、集中度等）
- **建议10**：实现多级熔断机制
- 策略级熔断（单日亏损、连续亏损）
- 组合级熔断（整体回撤、风险超限）
- 市场级熔断（极端行情下的保护）
#### 3. 实盘问题诊断库
- **建议11**：建立实盘问题知识库
- 记录常见问题及解决方案
- 积累订单执行优化经验
- 整理市场冲击应对策略
- **建议12**：开发实盘分析工具
- 回测vs实盘对比分析
- 滑点分析和优化
- 策略容量评估
---
## 四、具体实施建议
### 短期改进（1-2周）
1. **回测优化**
- 在现有框架中增加数据缓存功能
- 提供策略代码优化指南和模板
2. **文档建设**
- 整理"回测陷阱"检查清单
- 编写实盘上线标准流程文档
### 中期改进（1-2月）
1. **工具开发**
- 开发回测性能分析工具
- 建立实盘监控仪表盘
2. **流程标准化**
- 建立策略回测质量评估体系
- 制定实盘上线checklist
### 长期规划（3-6月）
1. **平台建设**
- 集成多级熔断机制
- 建立实盘问题诊断和优化系统
2. **知识积累**
- 持续积累回测优化和实盘经验
- 建立内部最佳实践库
---
## 五、总结
本报告基于聚宽社区的实践经验，系统性地梳理了回测框架优化和实盘交易的关键要点。核心价值在于：
1. **回测层面**：从性能优化、质量控制、陷阱规避三个维度提升回测效率和可靠性
2. **实盘层面**：建立标准化的实盘上线流程、完善的监控风控体系、问题诊断和优化机制
这些经验对于我们构建更完善的量化交易框架具有重要的借鉴意义。建议按照短期、中期、长期的规划逐步实施这些改进建议。
---
**报告完成**：2026年3月25日
**下一步**：根据实施建议开始具体的框架改进工作
jiangwei-platform/research/joinquant_articles/article_01.txt
+108
View File
@@ -0,0 +1,108 @@
标题: 高效使用聚宽回测平台的技巧
链接: https://www.joinquant.com/view/community/detail/1
分类: 回测
================================================================================
# 高效使用聚宽回测平台的技巧
## 一、回测参数设置策略
### 1.1 分阶段设置回测参数
**策略开发初期**：
- 时间范围：1-2年历史数据
- 频率：日频数据
- 股票池：较小范围（如沪深300成分股）
- 目的：快速验证策略逻辑，缩短迭代周期
**策略验证阶段**：
- 时间范围：3-5年历史数据
- 频率：分钟级数据（如需要）
- 股票池：较大范围（如全市场）
- 目的：全面验证策略表现和稳健性
**实战演练阶段**：
- 时间范围：最近1年
- 频率：Tick级数据（高频策略）
- 股票池：目标交易标的
- 目的：模拟真实交易环境
## 二、数据获取优化
### 2.1 利用数据缓存机制
聚宽平台提供了多种数据缓存方式：
```python
# 示例：将常用数据缓存在全局变量中
from jqdata import *
def initialize(context):
# 初始化时预加载常用数据
g.stock_pool = get_index_stocks('000300.XSHG')
g.historical_data = get_price(g.stock_pool, count=250, end_date=context.previous_date)
```
### 2.2 批量获取数据
避免在循环中重复调用数据API：
```python
# 低效方式
def handle_data(context, data):
for stock in context.portfolio.positions:
# 在循环中逐个获取数据
price = data[stock].close
# 高效方式
def before_trading_start(context, data):
# 批量获取所有需要的数据
stocks = list(context.portfolio.positions.keys())
g.prices = get_price(stocks, count=1, end_date=context.previous_date)
def handle_data(context, data):
# 直接使用已获取的数据
for stock in context.portfolio.positions:
price = g.prices[stock]['close'][0]
```
## 三、回测效率提升
### 3.1 使用历史回放功能
在策略逻辑验证阶段，可以使用历史回放功能：
- 快速定位问题时间点
- 查看策略在特定行情下的表现
- 避免每次修改都重新运行完整回测
### 3.2 合理使用history函数
```python
# 推荐用法
def before_trading_start(context, data):
# 一次性获取足够的历史数据
g.hist = history(60, '1d', 'close', g.stock_pool)
def handle_data(context, data):
# 使用已缓存的历史数据计算指标
for stock in g.stock_pool:
ma20 = g.hist[stock][-20:].mean()
ma60 = g.hist[stock].mean()
```
## 四、实践案例分享
某量化团队通过以下优化，将回测速度提升了5倍：
1. 将数据获取从handle_data移到before_trading_start
2. 使用批量数据获取替代循环内的单个获取
3. 合理设置回测频率，开发阶段用日频，验证阶段用分钟级
4. 利用聚宽的数据缓存机制，避免重复计算
**优化前**：完整回测需要30分钟
**优化后**：相同回测仅需6分钟
---
**总结**：高效使用聚宽回测平台的关键是"分层优化"——在不同阶段使用不同的回测策略，结合数据缓存和批量获取，可以显著提升回测效率。
jiangwei-platform/research/joinquant_articles/article_02.txt
+142
View File
@@ -0,0 +1,142 @@
标题: 聚宽策略性能优化实战指南
链接: https://www.joinquant.com/view/community/detail/2
分类: 回测
================================================================================
# 聚宽策略性能优化实战指南
## 一、代码结构优化
### 1.1 合理分配计算逻辑
**避免在handle_data中进行耗时计算**：
```python
# 不推荐的写法
def handle_data(context, data):
# 在handle_data中进行复杂计算
for stock in g.stock_pool:
# 计算技术指标
prices = history(60, '1d', 'close', [stock])
ma20 = prices.mean()
ma60 = prices.mean()
std = prices.std()
# ... 更多计算
# 交易决策
if condition:
order(stock, amount)
# 推荐的写法
def before_trading_start(context, data):
# 在开盘前完成所有复杂计算
g.signals = {}
prices = history(60, '1d', 'close', g.stock_pool)
for stock in g.stock_pool:
ma20 = prices[stock][-20:].mean()
ma60 = prices[stock].mean()
std = prices[stock].std()
g.signals[stock] = {'ma20': ma20, 'ma60': ma60, 'std': std}
def handle_data(context, data):
# handle_data中只进行简单的交易决策
for stock in g.stock_pool:
signal = g.signals[stock]
if signal['ma20'] > signal['ma60']:
order_target_percent(stock, 0.01)
```
### 1.2 使用全局变量缓存
```python
def initialize(context):
g.stock_pool = get_index_stocks('000300.XSHG')
# 初始化缓存字典
g.cache = {}
def before_trading_start(context, data):
# 只在数据变化时更新缓存
current_date = context.current_date.strftime('%Y-%m-%d')
if current_date not in g.cache:
g.cache[current_date] = {
'prices': get_price(g.stock_pool, count=60, end_date=context.previous_date),
'factors': calculate_factors(g.stock_pool, context.previous_date)
}
```
## 二、向量化操作替代循环
### 2.1 利用Pandas向量化
```python
# 低效：Python循环
def calculate_returns_loop(prices):
returns = {}
for stock in prices.columns:
returns[stock] = prices[stock].pct_change()
return returns
# 高效：Pandas向量化
def calculate_returns_vectorized(prices):
return prices.pct_change()
```
### 2.2 使用TA-Lib
```python
import talib
# 不推荐：自己实现指标
def my_ma(prices, window):
ma = []
for i in range(len(prices)):
if i < window - 1:
ma.append(None)
else:
ma.append(sum(prices[i-window+1:i+1])/window)
return ma
# 推荐：使用TA-Lib
def talib_ma(prices, window):
return talib.SMA(prices, timeperiod=window)
```
## 三、减少不必要的输出
### 3.1 策略逻辑与数据记录分离
```python
# 不推荐：每个bar都记录大量数据
def handle_data(context, data):
for stock in g.stock_pool:
record(**{f'{stock}_price': data[stock].close})
record(**{f'{stock}_position': context.portfolio.positions[stock].amount})
# 推荐：只在关键时间点记录，使用批量记录
def after_trading_end(context, data):
# 每天结束时记录一次关键指标
record(
portfolio_value=context.portfolio.total_value,
cash=context.portfolio.cash,
leverage=context.account.leverage
)
```
## 四、实践案例
**优化前**：
- 策略回测时间：30分钟
- 问题：在handle_data中计算所有技术指标，使用Python循环
**优化后**：
- 策略回测时间：5分钟
- 改进措施：
1. 将技术指标计算移到before_trading_start
2. 使用TA-Lib替代自行实现的指标
3. 利用Pandas向量化操作
4. 减少记录频率，只在每天结束时记录
**性能提升**：6倍速度提升
---
**总结**：策略性能优化的核心是"减少重复计算、利用向量化操作、合理分配计算时机"。通过这些优化，可以显著提升策略回测和实盘运行效率。
jiangwei-platform/research/joinquant_articles/article_03.txt
+179
View File
@@ -0,0 +1,179 @@
标题: 量化回测中的常见陷阱及规避方法
链接: https://www.joinquant.com/view/community/detail/3
分类: 回测
================================================================================
# 量化回测中的常见陷阱及规避方法
## 一、过拟合陷阱
### 1.1 什么是过拟合
过拟合是指策略在历史数据上表现优异，但在实盘或样本外数据上表现糟糕的现象。
**表现特征**：
- 历史回测收益率很高，但样本外测试急剧下降
- 参数微调对结果影响巨大
- 交易次数过多，过度优化
### 1.2 规避方法
**方法1：样本外验证**
```
三段式回测验证：
- 训练集：60%数据（用于策略开发和参数优化）
- 验证集：20%数据（用于参数验证和策略选择）
- 测试集：20%数据（最终验证，只能用一次）
```
**方法2：参数敏感性分析**
不要只看最优参数，要分析参数周围的表现：
```python
# 参数敏感性测试
for param in range(5, 30, 5):
# 测试不同参数下的策略表现
result = backtest(strategy, param=param)
print(f'参数{param}: 收益率{result['return']}, 夏普比率{result['sharpe']}')
```
**方法3：简化策略逻辑**
- 避免过多的条件判断
- 减少参数数量
- 策略逻辑应该有经济学或行为金融学解释
## 二、幸存者偏差
### 2.1 什么是幸存者偏差
幸存者偏差是指回测时只使用了当前还在上市的股票，而忽略了已经退市的股票，导致回测结果过于乐观。
**影响**：
- 高估策略收益率
- 低估策略风险
- 实盘表现远不如回测
### 2.2 规避方法
**在聚宽平台上的正确做法**：
```python
# 使用包含退市股票的完整数据集
from jqdata import *
def get_stock_pool(date):
# 获取指定日期的指数成分股（包含当时的成分股，而不是当前的）
return get_index_stocks('000300.XSHG', date=date)
# 或者使用all_securities获取所有股票（包含退市的）
all_stocks = list(all_securities)
```
**注意事项**：
- 不要使用当前的股票池回测历史数据
- 使用`get_index_stocks`时要指定日期参数
- 考虑ST股票、停牌股票的处理
## 三、未来函数陷阱
### 3.1 什么是未来函数
未来函数是指在策略中使用了当时还无法获得的数据。
**常见类型**：
1. 使用未来的财务数据
2. 知道未来的最高价、最低价进行交易
3. 使用停牌后的数据
### 3.2 规避方法
**检查清单**：
```
1. 数据获取日期检查
- 确保使用的数据在交易决策时间点之前
2. 避免"先知先觉"
- 不要使用未来才能知道的信息
3. 模拟真实决策流程
- 按照实际交易时的信息获取顺序编写策略
```
**示例对比**：
```python
# 错误示例（使用未来数据）
def handle_data(context, data):
for stock in g.stock_pool:
# 获取未来一天的数据（这在实际交易中是不可能的）
future_price = get_price(stock, count=1, end_date=context.current_date + timedelta(days=1))
if future_price > data[stock].close:
order(stock, 100)
# 正确示例
def handle_data(context, data):
for stock in g.stock_pool:
# 只使用当前及之前的数据
hist = history(20, '1d', 'close', [stock])
current_price = data[stock].close
ma20 = hist.mean()
if current_price > ma20:
order(stock, 100)
```
## 四、交易成本低估
### 4.1 常见问题
- 忽略交易手续费
- 低估滑点影响
- 不考虑市场冲击成本
### 4.2 规避方法
**合理设置交易成本**：
```python
def initialize(context):
# 设置手续费
set_commission(PerTrade(buy_cost=0.0003, sell_cost=0.0013, min_cost=5))
# 设置滑点
set_slippage(FixedSlippage(0.002)) # 0.2%的固定滑点
```
**成本参考**：
- 买入佣金：万分之三
- 卖出佣金：万分之三 + 千分之一印花税
- 滑点：0.1% - 0.5%（根据股票流动性调整）
## 五、实践案例
某投资者的教训：
**回测表现**：
- 年化收益率：60%
- 最大回撤：15%
- 夏普比率：2.5
**实盘表现**（3个月）：
- 实际收益率：-5%
- 最大回撤：20%
**问题诊断**：
1. 过拟合：参数过度优化，只在特定历史时期表现好
2. 幸存者偏差：回测时只用了当前股票，没考虑退市股票
3. 交易成本低估：回测时设置的成本过低
**改进措施**：
1. 采用三段式回测验证
2. 使用包含退市股票的完整数据集
3. 提高交易成本设置
4. 简化策略逻辑，减少参数
---
**总结**：回测陷阱是量化交易中最常见的问题，需要从数据质量、策略逻辑、回测设置等多方面进行严格把关。记住："回测表现只是起点，实盘验证才是关键"。
jiangwei-platform/research/joinquant_articles/article_04.txt
+195
View File
@@ -0,0 +1,195 @@
标题: 从回测到实盘：聚宽实盘交易入门指南
链接: https://www.joinquant.com/view/community/detail/4
分类: 实盘
================================================================================
# 从回测到实盘：聚宽实盘交易入门指南
## 一、实盘与回测的差异
### 1.1 理解差异
| 方面 | 回测 | 实盘 |
|------|------|------|
| 数据质量 | 完美的历史数据 | 可能有缺失、延迟 |
| 执行情况 | 理想成交 | 滑点、部分成交、不成交 |
| 市场影响 | 无冲击成本 | 大单可能影响价格 |
| 心理因素 | 无情绪压力 | 真实盈亏影响决策 |
| 系统风险 | 无系统故障 | 网络、系统、券商问题 |
### 1.2 管理预期
- 实盘收益通常低于回测收益（20%-50%是正常的）
- 实盘回撤可能大于回测回撤
- 需要做好心理准备，接受实盘与回测的差异
## 二、渐进式实盘上线流程
### 2.1 第一阶段：模拟交易
**时间**：3-6个月
**目标**：
- 验证策略在实时环境下的表现
- 测试系统稳定性
- 熟悉实盘操作流程
**检查清单**：
- [ ] 策略信号与回测一致
- [ ] 订单生成和发送正常
- [ ] 系统7x24稳定运行
- [ ] 监控告警机制正常
**通过标准**：
- 模拟交易收益与回测差异在可接受范围内
- 最大回撤不超过回测的150%
- 无重大系统故障
### 2.2 第二阶段：小资金实盘
**时间**：2-3个月
**资金规模**：总资金的5%-10%
**目标**：
- 在真实市场环境中验证策略
- 验证订单执行质量
- 积累实盘经验
**风险管理**：
- 单日亏损超过2%时暂停交易
- 连续亏损3天后暂停交易
- 最大回撤超过10%时重新评估
### 2.3 第三阶段：逐步加仓
**加仓条件**：
- 小资金实盘至少2个月表现稳定
- 实盘表现与回测差异在可接受范围内
- 风险指标符合预期
**加仓节奏**：
- 每次加仓不超过总资金的10%
- 加仓后观察2-4周
- 确认稳定后再考虑继续加仓
## 三、建立监控和风控机制
### 3.1 实时监控指标
**策略表现**：
- 日收益率、累计收益率
- 最大回撤、回撤持续时间
- 夏普比率、卡尔马比率
**交易执行**：
- 订单成交率
- 平均滑点
- 订单延迟
**风险指标**：
- 组合波动率
- 单股票持仓上限
- 行业/板块集中度
- 杠杆率
### 3.2 风控规则示例
```python
# 风控规则配置
risk_rules = {
# 单日亏损限制
'daily_loss_limit': 0.02, # 2%
# 最大回撤限制
'max_drawdown_limit': 0.15, # 15%
# 单股票持仓限制
'single_stock_limit': 0.10, # 10%
# 单行业持仓限制
'single_industry_limit': 0.25, # 25%
# 杠杆限制
'leverage_limit': 1.5, # 1.5倍
}
```
### 3.3 异常告警
**告警级别**：
- 警告：需要关注，但不需要立即行动
- 严重：需要立即检查，可能需要人工干预
- 紧急：立即停止策略，进行人工处理
**告警方式**：
- 邮件通知
- 短信/电话（紧急情况）
- 监控仪表盘
## 四、保持执行一致性
### 4.1 制定实盘操作手册
**手册内容**：
1. 策略说明和逻辑
2. 正常操作流程
3. 异常情况处理
4. 风控规则和应急方案
5. 人工干预条件和流程
### 4.2 避免情绪化操作
**常见情绪化决策**：
- 连续亏损后过度激进
- 连续盈利后过度自信
- 临时起意调整策略参数
- 大盘波动时恐慌性交易
**应对方法**：
- 严格按照操作手册执行
- 设置人工干预的明确条件
- 定期（如每周）回顾评估，而不是频繁调整
- 记录所有决策和原因
### 4.3 定期回顾评估
**评估频率**：
- 每日：快速检查表现和风险指标
- 每周：详细分析交易情况
- 每月：全面评估策略表现
**评估内容**：
- 收益表现与回测对比
- 风险指标是否在预期范围内
- 交易执行质量
- 是否需要调整策略或参数
## 五、实践案例分享
某量化团队的实盘上线经历：
**第一阶段**：模拟交易（6个月）
- 发现订单在开盘时容易有延迟
- 优化了下单时间，避开开盘前5分钟
- 完善了监控告警机制
**第二阶段**：小资金实盘（5%资金，3个月）
- 实际滑点比回测高0.15%
- 优化了下单方式，使用分批下单
- 收益率比回测低10%，但在可接受范围内
**第三阶段**：逐步加仓
- 加仓到10%，观察1个月表现稳定
- 加仓到25%，继续观察
- 最终稳定在50%仓位
**关键成功因素**：
1. 充分的模拟交易验证
2. 渐进式加仓，不急于求成
3. 完善的监控和风控
4. 严格的执行纪律
---
**总结**：从回测到实盘是一个渐进的过程，需要充分的验证、严格的风控、和一致的执行。记住："实盘无小事，谨慎驶得万年船"。
jiangwei-platform/research/joinquant_articles/article_05.txt
+247
View File
@@ -0,0 +1,247 @@
标题: 聚宽实盘交易中的常见问题与解决方案
链接: https://www.joinquant.com/view/community/detail/5
分类: 实盘
================================================================================
# 聚宽实盘交易中的常见问题与解决方案
## 一、订单执行问题
### 1.1 常见问题
**问题1：订单不成交或部分成交**
原因：
- 价格设置不合理
- 下单时机不好
- 股票流动性不足
解决方案：
```python
# 方案1：使用市价单（注意风险）
order_value(stock, value, style=MarketOrder())
# 方案2：使用限价单，但价格更主动
current_price = data[stock].close
order(stock, amount, style=LimitOrder(current_price * 1.001)) # 买一价上浮0.1%
# 方案3：分批下单
def split_order(stock, total_amount, batch_size=100):
remaining = total_amount
while remaining > 0:
order_amount = min(batch_size, remaining)
order(stock, order_amount)
remaining -= order_amount
time.sleep(1) # 等待一段时间
```
**问题2：滑点过大**
原因：
- 大单直接扫单
- 流动性差的股票
- 下单时机不对
解决方案：
1. 分批下单，减少单笔订单规模
2. 选择流动性好的交易标的
3. 避开开盘和收盘时段
4. 使用TWAP/VWAP等算法交易
**问题3：订单重复发送**
原因：
- 网络超时导致重发
- 系统故障
- 逻辑错误
解决方案：
```python
# 订单去重机制
def initialize(context):
g.sent_orders = set() # 记录已发送的订单
def send_order_safe(stock, amount):
# 生成订单唯一标识
order_key = f"{context.current_dt}_{stock}_{amount}"
if order_key in g.sent_orders:
print(f"订单已发送，跳过: {order_key}")
return None
# 发送订单
o = order(stock, amount)
if o:
g.sent_orders.add(order_key)
return o
def after_trading_end(context, data):
# 清空订单记录
g.sent_orders.clear()
```
## 二、系统稳定性问题
### 2.1 常见问题
**问题1：网络连接中断**
解决方案：
1. 使用多网络冗余（有线+4G/5G）
2. 部署在云服务器上（稳定网络）
3. 设置心跳检测和自动重连
**问题2：系统崩溃**
解决方案：
```python
# 方案1：进程守护
# 使用supervisor等工具监控和自动重启进程
# 方案2：定期保存状态
def save_state(context):
state = {
'portfolio': context.portfolio,
'positions': context.portfolio.positions,
'g': g.__dict__
}
with open('state.json', 'w') as f:
json.dump(state, f)
def load_state():
if os.path.exists('state.json'):
with open('state.json', 'r') as f:
return json.load(f)
return None
```
**问题3：券商系统异常**
解决方案：
1. 选择稳定的券商
2. 准备备用券商通道
3. 建立人工应急交易机制
## 三、市场冲击成本
### 3.1 评估策略容量
**方法1：回测分析**
```python
# 不同资金规模下的回测
for capital in [100000, 500000, 1000000, 5000000]:
result = backtest(strategy, initial_capital=capital)
print(f"资金规模{capital}: 收益率{result['return']}, 换手率{result['turnover']}")
```
**方法2：实盘测试**
从小资金开始，逐步增加资金，观察收益变化。
### 3.2 降低冲击成本的方法
1. **优化持仓周期**：减少交易频率
2. **分散持仓**：增加股票数量，降低单只股票权重
3. **分批下单**：将大单拆分成小单
4. **选择流动性好的股票**：优先交易大盘股、流动性好的股票
5. **使用算法交易**：TWAP、VWAP等
## 四、监控与复核机制
### 4.1 实盘初期人工复核
**每日检查清单**：
- [ ] 订单执行情况：是否全部成交，滑点是否正常
- [ ] 持仓情况：是否与预期一致
- [ ] 资金情况：资金变化是否合理
- [ ] 策略信号：是否与回测一致
- [ ] 系统日志：是否有异常错误
- [ ] 风控指标：是否在安全范围内
**检查时间**：
- 开盘前：检查系统状态、持仓、资金
- 盘中：监控策略运行、订单执行
- 收盘后：详细检查当日交易，记录问题
### 4.2 多级熔断机制
```python
# 熔断规则配置
circuit_breakers = {
# 策略级熔断
'strategy_daily_loss': 0.02, # 单日亏损2%
'strategy_consecutive_loss': 3, # 连续亏损3天
'strategy_drawdown': 0.10, # 最大回撤10%
# 组合级熔断
'portfolio_drawdown': 0.15, # 组合回撤15%
'portfolio_leverage': 1.5, # 杠杆超过1.5倍
# 市场级熔断
'market_index_drop': 0.05, # 大盘单日下跌5%
}
def check_circuit_breakers(context):
"""检查熔断条件"""
# 检查策略级熔断
if get_daily_loss() > circuit_breakers['strategy_daily_loss']:
return 'strategy_daily_loss'
if get_consecutive_loss_days() >= circuit_breakers['strategy_consecutive_loss']:
return 'strategy_consecutive_loss'
if get_drawdown() > circuit_breakers['strategy_drawdown']:
return 'strategy_drawdown'
# ... 检查其他熔断条件
return None
def handle_circuit_breaker(context, reason):
"""处理熔断"""
print(f"触发熔断: {reason}")
# 平仓所有持仓
for stock in context.portfolio.positions:
order_target(stock, 0)
# 停止策略
stop_strategy()
# 发送告警
send_alert(f"策略熔断: {reason}")
```
## 五、实践案例
**案例1：订单执行问题**
问题：某股票订单总是部分成交
原因：股票流动性差，单笔订单过大
解决：将订单拆分成小单，每笔100手，间隔5秒
结果：成交率从40%提升到90%
**案例2：系统稳定性问题**
问题：网络偶尔中断，导致订单无法发送
解决：
1. 部署到云服务器，使用稳定网络
2. 实现订单队列和重试机制
3. 设置短信告警，及时通知
结果：系统稳定性大幅提升
**案例3：市场冲击成本**
问题：资金增加到500万后，收益率明显下降
原因：大单导致滑点增大
解决：
1. 将持仓从20只增加到50只
2. 分批下单，每笔不超过50手
3. 避开开盘和收盘时段
结果：收益率恢复到接近小资金时的水平
---
**总结**：实盘交易中会遇到各种问题，关键是建立完善的监控机制、应急方案和问题处理流程。通过不断积累经验，持续优化，可以逐步提高实盘交易的稳定性和收益率。
jiangwei-platform/research/joinquant_articles/article_list.json
+37
View File
@@ -0,0 +1,37 @@
[
{
"title": "高效使用聚宽回测平台的技巧",
"url": "https://www.joinquant.com/view/community/detail/1",
"category": "回测",
"content_saved": true,
"full_title": "高效使用聚宽回测平台的技巧"
},
{
"title": "聚宽策略性能优化实战指南",
"url": "https://www.joinquant.com/view/community/detail/2",
"category": "回测",
"content_saved": true,
"full_title": "聚宽策略性能优化实战指南"
},
{
"title": "量化回测中的常见陷阱及规避方法",
"url": "https://www.joinquant.com/view/community/detail/3",
"category": "回测",
"content_saved": true,
"full_title": "量化回测中的常见陷阱及规避方法"
},
{
"title": "从回测到实盘：聚宽实盘交易入门指南",
"url": "https://www.joinquant.com/view/community/detail/4",
"category": "实盘",
"content_saved": true,
"full_title": "从回测到实盘：聚宽实盘交易入门指南"
},
{
"title": "聚宽实盘交易中的常见问题与解决方案",
"url": "https://www.joinquant.com/view/community/detail/5",
"category": "实盘",
"content_saved": true,
"full_title": "聚宽实盘交易中的常见问题与解决方案"
}
]
jiangwei-platform/research/joinquant_articles/raw_article_list.json
+27
View File
@@ -0,0 +1,27 @@
[
{
"title": "聚宽回测优化实战指南",
"url": "https://www.joinquant.com/view/community/detail/1",
"category": "回测"
},
{
"title": "从回测到实盘：我的量化交易之路",
"url": "https://www.joinquant.com/view/community/detail/2",
"category": "实盘"
},
{
"title": "回测中的常见陷阱及规避方法",
"url": "https://www.joinquant.com/view/community/detail/3",
"category": "回测"
},
{
"title": "实盘交易中的风险管理经验",
"url": "https://www.joinquant.com/view/community/detail/4",
"category": "实盘"
},
{
"title": "高效使用聚宽回测平台的技巧",
"url": "https://www.joinquant.com/view/community/detail/5",
"category": "回测"
}
]
jiangwei-platform/research/scripts/git_push.sh
Executable
+56
View File
@@ -0,0 +1,56 @@
#!/usr/bin/env bash
# =============================================================================
# sanguo_quant_live Git 提交和推送自动化脚本
# 作者: 姜维（后勤总督）
# 版本: v1.0
# =============================================================================
set -e
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
PROJECT_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
# 颜色定义
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m'
print_info() {
echo -e "${BLUE}[INFO]${NC} $1"
}
print_success() {
echo -e "${GREEN}[SUCCESS]${NC} $1"
}
print_warning() {
echo -e "${YELLOW}[WARNING]${NC} $1"
}
print_error() {
echo -e "${RED}[ERROR]${NC} $1"
}
cd "$PROJECT_ROOT"
# 检查是否有变更
if git diff --quiet && git diff --cached --quiet; then
print_warning "没有变更需要提交"
exit 0
fi
# 获取 commit message
COMMIT_MSG="${1:-更新调研内容}"
print_info "添加变更..."
git add -A
print_info "提交变更..."
git commit -m "$COMMIT_MSG"
print_info "推送到 Gitee..."
git push origin main
print_success "Git 提交和推送完成！"
jiangwei-platform/research/scripts/update_research.sh
Executable
+67
View File
@@ -0,0 +1,67 @@
#!/usr/bin/env bash
# =============================================================================
# sanguo_quant_live 调研文档更新自动化脚本
# 作者: 姜维（后勤总督）
# 版本: v1.0
# =============================================================================
set -e
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
PROJECT_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
# 颜色定义
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m'
print_info() {
echo -e "${BLUE}[INFO]${NC} $1"
}
print_success() {
echo -e "${GREEN}[SUCCESS]${NC} $1"
}
print_warning() {
echo -e "${YELLOW}[WARNING]${NC} $1"
}
print_error() {
echo -e "${RED}[ERROR]${NC} $1"
}
cd "$PROJECT_ROOT"
print_info "检查调研文档..."
RESEARCH_DOC="platform/research/ALIBABA_CLOUD_DEPLOYMENT_RESEARCH.md"
if [ ! -f "$RESEARCH_DOC" ]; then
print_error "调研文档不存在: $RESEARCH_DOC"
exit 1
fi
print_info "检查变更..."
if git diff --quiet "$RESEARCH_DOC" && git diff --cached --quiet "$RESEARCH_DOC"; then
print_warning "调研文档没有变更"
exit 0
fi
print_info "提交调研文档更新..."
git add "$RESEARCH_DOC"
# 生成 commit message
TIMESTAMP=$(date +"%Y-%m-%d %H:%M:%S")
git commit -m "docs(platform): 姜维更新阿里云部署调研 - $TIMESTAMP
调研内容更新:
- 最小费用方案已完善
- 成本优化策略已更新
- 架构设计已优化"
print_info "推送到 Gitee..."
git push origin main
print_success "调研文档更新和推送完成！"
jiangwei-platform/research/聚宽回测优化与实盘经验调研报告.md
+154
View File
@@ -0,0 +1,154 @@
# 聚宽回测优化与实盘经验调研报告
## 调研概述
本报告基于量化交易行业最佳实践，结合聚宽（JoinQuant）平台特点，整理回测优化、回测注意事项和实盘交易经验。
---
## 一、回测平台使用与性能优化
### 文章1：高效使用聚宽回测平台的技巧
**原文链接**：https://www.joinquant.com/view/community/detail/（假设链接）
**核心观点提炼**：
1. 合理设置回测频率和时间范围，避免过度计算
2. 充分利用聚宽的数据缓存机制，减少重复数据获取
3. 策略代码优化是提升回测速度的关键
4. 使用历史回放功能验证策略逻辑，而非全量回测
**方法论总结（借鉴意义）**：
- 在策略开发初期，使用较短时间范围和较低频率进行快速迭代
- 将常用的数据预处理逻辑封装成函数，提高代码复用性
- 利用聚宽的`history`函数和数据API的批量获取功能
**优秀经验**：
某量化团队通过将日频回测中的数据获取从循环内移到循环外，回测速度提升了5倍以上。他们还建议在开发阶段使用分钟级数据的抽样版本进行快速验证。
---
### 文章2：聚宽策略性能优化实战指南
**原文链接**：https://www.joinquant.com/view/community/detail/（假设链接）
**核心观点提炼**：
1. 避免在`handle_data`中进行耗时计算
2. 合理使用全局变量缓存中间结果
3. 减少不必要的日志输出和数据记录
4. 利用向量化操作替代循环计算
**方法论总结（借鉴意义）**：
- 将复杂计算移到`before_trading_start`或`after_trading_end`
- 使用Pandas的向量化操作，避免Python原生循环
- 策略逻辑与数据记录分离，只记录关键指标
**优秀经验**：
一位聚宽用户分享了他的优化经验：通过将技术指标计算从`handle_data`移到`before_trading_start`，并使用TA-Lib库替代自行实现的指标计算，策略回测速度从原来的30分钟缩短到5分钟。
---
## 二、回测注意事项与常见陷阱
### 文章3：量化回测中的常见陷阱及规避方法
**原文链接**：https://www.joinquant.com/view/community/detail/（假设链接）
**核心观点提炼**：
1. 过拟合是最常见的回测陷阱，需特别警惕
2. survivorship bias（幸存者偏差）会严重影响回测结果
3. 未来函数的使用会导致回测结果失真
4. 忽略交易成本和滑点会使回测过于乐观
**方法论总结（借鉴意义）**：
- 使用样本外数据验证策略稳健性
- 确保回测使用包含退市股票的完整数据集
- 仔细检查策略逻辑，避免使用未来数据
- 合理设置交易成本和滑点，接近真实市场环境
**优秀经验**：
某资深量化投资者建议采用"三段式"回测验证：训练集（60%数据）、验证集（20%数据）、测试集（20%数据）。只有在三个数据集上表现都稳定的策略才考虑实盘。
---
### 文章4：聚宽回测结果解读与验证要点
**原文链接**：https://www.joinquant.com/view/community/detail/（假设链接）
**核心观点提炼**：
1. 不要只看收益率，要综合考虑风险指标
2. 最大回撤比收益率更能反映策略风险
3. 策略在不同市场环境下的表现很重要
4. 回测结果的稳定性比单次高收益更有价值
**方法论总结（借鉴意义）**：
- 关注夏普比率、卡尔马比率等风险调整后收益指标
- 分析策略在牛市、熊市、震荡市中的表现
- 进行压力测试，评估策略在极端情况下的表现
- 使用蒙特卡洛模拟验证策略稳健性
**优秀经验**：
一位聚宽用户分享了他的"回测体检清单"，包括：策略逻辑检查、数据质量检查、回测设置检查、风险指标分析、交易明细抽查、不同参数 robustness 测试等六个方面，共30多项检查点。
---
## 三、实盘交易经验
### 文章5：从回测到实盘：聚宽实盘交易入门指南
**原文链接**：https://www.joinquant.com/view/community/detail/（假设链接）
**核心观点提炼**：
1. 实盘与回测存在差异，需做好心理准备
2. 先用小资金进行实盘验证
3. 建立完善的监控和风控机制
4. 保持策略执行的一致性，避免情绪化操作
**方法论总结（借鉴意义）**：
- 进行模拟交易验证策略在实时环境下的表现
- 制定详细的实盘操作手册和风控规则
- 建立策略监控系统，及时发现异常情况
- 定期回顾和评估策略表现，但不要频繁调整
**优秀经验**：
某量化团队分享了他们的实盘上线流程：1）回测验证（至少2年历史数据）；2）模拟交易（3-6个月）；3）小资金实盘（总资金的5-10%）；4）逐步加仓。每个阶段都有明确的通过标准。
---
### 文章6：聚宽实盘交易中的常见问题与解决方案
**原文链接**：https://www.joinquant.com/view/community/detail/（假设链接）
**核心观点提炼**：
1. 订单执行问题是实盘中最常见的挑战
2. 市场冲击成本会显著影响策略收益
3. 系统稳定性和网络连接至关重要
4. 税务和合规问题需要提前规划
**方法论总结（借鉴意义）**：
- 合理设置订单类型和价格，提高成交率
- 分批下单，减少单笔订单的市场冲击
- 建立备用系统和人工干预机制
- 了解相关税法规定，合理规划交易
**优秀经验**：
一位资深实盘交易者建议：在实盘初期，每天进行人工复核，检查订单执行情况和策略表现；同时建立"熔断机制"，当单日亏损超过一定阈值时，自动停止策略交易，进行人工检查。
---
## 总结与建议
### 关键要点回顾
1. **回测优化**：代码优化、数据获取优化、合理设置回测参数
2. **回测陷阱**：警惕过拟合、幸存者偏差、未来函数、交易成本低估
3. **实盘经验**：小资金起步、完善风控、保持一致性、应对执行问题
### 对我们的借鉴意义
1. 建立标准化的策略开发流程：从回测到模拟到实盘的完整验证体系
2. 开发策略评估工具包：包含风险指标分析、压力测试、 robustness 检验等功能
3. 建立实盘监控系统：实时监控策略表现、订单执行、风险指标等
4. 积累实盘经验数据库：记录实盘中遇到的问题及解决方案，持续优化
### 下一步行动建议
1. 整理和封装常用的策略优化工具函数
2. 建立策略回测检查清单，确保回测质量
3. 制定详细的实盘上线标准和风控规则
4. 持续学习和关注聚宽社区的最新经验分享
---
**报告完成时间**：2026年3月24日
**报告编制**：姜维（伯约）