自托管开源行情监控系统OpenStock搭建指南：从数据采集到Docker部署

如果你也有过这种想法——把感兴趣的那批股票行情数据按自己的节奏存下来自己写指标、自己做提醒而不是每天打开好几个App翻来翻去——那OpenStock这套自托管的开源行情监控系统值得你花一个下午把它搭起来。OpenStock定位很简单它不是一个又一个现成的炒股软件而是一套跑在你自己的服务器或者本地电脑上的数据管道把行情采集、入库、展示、告警全部串起来数据是你自己的规则也是你自己的。这篇文章我按自己实际搭建过的路径来写从环境准备到抓数据从定时任务到Docker部署每一步都给可复现的命令和配置。适合对Python和Linux有一点点基础、想把行情数据抓在自己手里的折腾型选手就算你是纯新手只要照着做也基本能跑通。1. OpenStock到底解决什么问题1.1 自建行情系统的核心价值很多人一开始会问我用同花顺、东方财富、雪球不就够了为什么还要自己搭一套这句话本身没错如果你只是每天收盘后瞄一眼持仓现成App体验确实更好。但OpenStock要解决的从来不是“看行情”这个动作而是“数据资产归属”的问题。现成的行情软件有几个天然痛点。第一历史数据你导不出去想算个三年回测K线还得自己一份份抠第二筛选逻辑和提醒规则都是别人定义好的你想找一个“连续三天缩量且收盘价站上20日均线”的标的在App里基本做不了第三数据粒度不够灵活有些场景你需要分钟级数据、需要复权后的价格序列App给的往往是一份“高度包装”的结果。OpenStock的价值在于它把数据采集层、存储层、展示层和告警层都拆开全部跑在你自己的环境里。你拉下来的每一根K线、每一条企业基本信息都落在你自己的数据库里。你可以写任意指标、做任意切片甚至把数据喂给其他量化框架。用一句话概括就是主流系统给你“鱼”OpenStock给你“渔”的整套工具链。1.2 它和券商App、行情网站的本质区别区别其实在“架构”而不在“功能”。券商App是中心化服务服务器在对方那边数据权限完全由对方决定哪天接口关了、规则改了你的数据颗粒度就得跟着变。OpenStock是自托管架构代码在GitHub上数据源是公开行情接口采集逻辑在你手里数据落在你自己的磁盘里。这就带来三个实际好处。一是稳定性预期不同免费接口偶尔波动但你的采集程序有重试机制、有数据补偿整体数据链路是可控的。二是分析能力不受UI限制你可以用Python直接连数据库跑pandas也可以用前端页面做可视化数据打通后玩法完全由你定。三是学习价值极高一套完整的行情系统涉及定时调度、API封装、数据库设计、前端图表渲染哪怕不碰股票把它当成一个全栈项目来做也值回时间。当然有一个前提我必须说清楚OpenStock是一套技术基础设施不是投资决策工具。它里面跑的告警、指标、涨跌幅排序都只是数据结果不构成任何投资建议。如果你抱着“搭完就能跟着提示赚钱”的心态建议趁早调转方向。2. 搭建前的环境规划与选型逻辑2.1 主机与操作系统选型先说一个最实际的问题OpenStock跑在什么机器上实践下来有三类选择取决于你的使用强度。第一类本地电脑。Windows、macOS、Linux都行适合开发调试和只盯几十只股票的场景。本地跑的优势是零成本缺点是不能7x24小时开机盘中盯盘和定时任务会受断电、休眠影响。第二类云服务器。2核4G内存、20G硬盘左右的入门机型就能带起来适合长期运行。注意选网络稳定一点的厂商行情抓取对网络质量有一定要求。第三类树莓派或者NAS上的Docker。这类设备功耗低适合放家里长期跑但要注意存储别用SD卡容易损坏数据库文件。操作系统我推荐Debian系的Linux发行版比如Ubuntu 22.04 LTS。理由很简单Docker支持最成熟、Python环境干净、Nginx配置资料多。Windows也能跑但坑不少比如路径分隔符、编码、计划任务每个都要单独处理。注意如果完全没接触过Linux建议先在本地虚拟机上练习一遍再用云服务器正式部署。别直接在生产机器上边学边操作容易把环境弄乱。2.2 核心依赖清单OpenStock的典型技术栈由以下组件构成Python负责数据采集和接口服务Node.js负责前端构建Docker负责统一打包Nginx负责反向代理。下面这张表是我搭建时实际使用的版本和用途按依赖顺序排列组件版本建议用途Python3.10后端服务、数据抓取、定时任务Node.js18前端Vue应用构建Docker20.10容器化运行可选Docker Composev2多容器编排PostgreSQL / SQLite14 / 内置数据存储Nginx1.18反向代理、前端静态托管除了运行时依赖Python侧还需要几个关键库FastAPI作为Web框架SQLAlchemy做ORMAPScheduler做定时任务AkShare作为行情数据抓取库pandas做数据处理。这些都会在requirements.txt里统一声明后面我会给出具体安装步骤。2.3 数据库选型SQLite还是PostgreSQLOpenStock在数据库设计上做了兼容支持SQLite和PostgreSQL两种后端配置切换只改一行连接串就行。那到底怎么选我给出的标准是看“数据量”和“写入并发”。如果只是跟踪沪深两市几千只股票做日线级别数据数据量也就每天几千行一年下来不到百万行SQLite完全扛得住。它的好处是零运维一个文件就是整个数据库备份直接拷贝文件适合个人使用。但如果你要存分钟级K线或者打算长期积累五到十年行情数据写入量会大很多。分钟级数据每周就几十万行这时候SQLite单文件写锁的问题会逐渐暴露读和写互相阻塞。这种情况建议直接用PostgreSQL它在高并发写入和多条件查询上明显更从容。数据库表结构方面OpenStock有三张核心表股票基础信息表stock_basic、行情日线表daily_quote、告警记录表price_alert。以下是简化的建表逻辑CREATE TABLE stock_basic ( id SERIAL PRIMARY KEY, code VARCHAR(10) UNIQUE NOT NULL, name VARCHAR(32) NOT NULL, industry VARCHAR(32), list_date DATE ); CREATE TABLE daily_quote ( id SERIAL PRIMARY KEY, code VARCHAR(10) NOT NULL, trade_date DATE NOT NULL, open NUMERIC(10, 3), close NUMERIC(10, 3), high NUMERIC(10, 3), low NUMERIC(10, 3), volume BIGINT, amount NUMERIC(16, 2), UNIQUE(code, trade_date) );daily_quote里的UNIQUE(code, trade_date)约束很关键这是数据去重的兜底方案后面抓数据章节你就能体会到它的用处。3. 源码获取与前后端初始化3.1 获取OpenStock源码OpenStock的源码托管在GitHub上仓库名就叫OpenStock。打开终端克隆代码到指定目录git clone https://github.com/openstock/openstock.git cd openstock克隆完成后看下目录结构。一个规范的开源项目会明确分好前后端和部署文件通常长这样openstock/ ├── backend/ │ ├── app/ │ │ ├── api/ # 接口路由 │ │ ├── models/ # ORM模型 │ │ ├── services/ # 业务逻辑 │ │ ├── collectors/ # 数据采集器 │ │ └── main.py # 后端入口 │ ├── requirements.txt │ └── .env.example ├── frontend/ │ ├── src/ │ ├── package.json │ └── vite.config.js ├── docker/ │ ├── Dockerfile.backend │ ├── Dockerfile.frontend │ └── docker-compose.yml └── README.md我建议优先clone最新的release标签而不是直接拉main分支。因为main分支可能处于功能迭代中偶尔会有临时改动影响稳定性。release版本通常是发布前测试过的对第一次搭建的朋友友好得多。等跑通了再切回main体验新功能不迟。3.2 后端配置与依赖安装后端基于Python第一步是创建虚拟环境避免依赖冲突cd backend python3 -m venv venv source venv/bin/activate pip install -r requirements.txtrequirements.txt里包含前面提到的FastAPI、SQLAlchemy、APScheduler、AkShare等库。安装过程可能需要几分钟如果网络环境不好建议配置国内pip镜像源加速。安装完成后需要初始化环境变量。项目里提供了一个.env.example文件复制为.env然后按需修改cp .env.example .env.env里最重要的几个配置项如下# 时区影响K线日期和告警时间判断 TIMEZONEAsia/Shanghai # 数据库连接SQLite或PostgreSQL DATABASE_URLsqlite:///./openstock.db # DATABASE_URLpostgresql://openstock:passwordlocalhost:5432/openstock # 行情数据源akshare / sina / tencent DATA_SOURCEakshare # 抓取失败重试次数 FETCH_RETRY3 # 告警通知地址可留空 SERVER_CHAN_KEY DINGTALK_WEBHOOK SMTP_HOST SMTP_USER SMTP_PASSWORD我踩过一个坑是忘记改时区。默认的UTC会导致K线日期和交易日历错位数据存进去都是前一天或后一天的时间前端展示曲线看起来总怪怪的。建议第一时间把TIMEZONE固定为Asia/Shanghai。初始化数据库结构项目使用Alembic管理迁移alembic upgrade head3.3 前端构建与本地开发服务器接下来是前端。OpenStock的前端基于Vue 3和Vite构建图表用的是ECharts整体交互比较轻量。cd ../frontend npm installnpm install的耗时取决于网络情况如果公司在用私服或者网络受限设置好registry镜像就行。依赖装完可以先启动本地开发服务器试试npm run dev默认端口是5173浏览器打开就能看到前端页面。这时前后端还没对接页面会提示API请求失败先不用管等后端也启动就好。前后端分离是现在主流做法看起来多了一道构建步骤实际很划算。前端只管渲染和交互后端只出JSON接口两者通过HTTP通信。调试的时候一个浏览器标签页开前端DevServer一个开后端Swagger文档两边互不干扰改前端不用重启后端效率高很多。启动后端开发服务器的方式是cd backend uvicorn app.main:app --reload --port 8000后端起来后访问http://localhost:8000/docs能看到FastAPI自动生成的接口文档能直接测试行情查询、自选股管理等接口。前端要联调后端只需要在Vite配置文件里设置代理把/api前缀代理到8000端口。4. 行情数据源接入与抓取策略4.1 常见免费数据源对比OpenStock的数据采集层是插件化设计的默认支持多个数据源。我实际用过的有三类AkShare聚合接口、新浪财经接口、腾讯财经接口。它们的对比如下数据源稳定性字段丰富度请求限制适用场景AkShare中上依赖上游源高覆盖行情/财务/宏观无明显限制但需控制频率通用抓取推荐首选新浪财经稳定中有实时和日K频率太高会临时封IP日线级数据备份腾讯财经稳定中近年接口调整较频繁同样有频率限制实时行情推送先说结论日常跑日线行情用AkShare是最省事的。它对新浪、东财等公开接口做了统一封装你不需要关心具体请求URL和参数格式直接拿Python函数调用就行。但要注意AkShare本质是聚合库上游接口一旦调整它也可能跟着变动。所以OpenStock里我做了一层抽象不直接绑死某个源。4.2 构建统一抓取接口为了避免业务代码被数据源细节污染采集层设计了一个基类# backend/app/collectors/base.py from abc import ABC, abstractmethod from datetime import date class BaseQuoteCollector(ABC): abstractmethod def fetch_daily_quote(self, code: str, start_date: date, end_date: date) - list[dict]: 获取日线行情 abstractmethod def fetch_stock_list(self) - list[dict]: 获取股票基础列表AkShare的实现长这样# backend/app/collectors/akshare_collector.py import akshare as ak import pandas as pd from .base import BaseQuoteCollector class AkshareCollector(BaseQuoteCollector): def fetch_daily_quote(self, code: str, start_date: date, end_date: date) - list[dict]: df ak.stock_zh_a_hist( symbolcode, perioddaily, start_datestart_date.strftime(%Y%m%d), end_dateend_date.strftime(%Y%m%d), adjustqfq ) records [] for _, row in df.iterrows(): records.append({ code: code, trade_date: row[日期].strftime(%Y-%m-%d), open: row[开盘], close: row[收盘], high: row[最高], low: row[最低], volume: row[成交量], amount: row[成交额], }) return records只要实现同一个接口多数据源就可以随时切换。今天用AkShare跑明天换成新浪配置文件里改一行DATA_SOURCEsina就完事。这种设计看起来多花了一点抽象成本实际运维时能救你于水深火热之中——免费接口说变就变需要备用源的时刻迟早会来。4.3 请求频率控制与数据去重免费行情源最大的隐形规则是“别把人家打挂了”。A股五千多只股票如果不做控制几分钟就能把日K全量拉一遍很容易触发临时封禁。OpenStock在采集层内置了限速器用最简单的令牌桶思路实现保证每秒最多N次请求# backend/app/collectors/rate_limiter.py import time import threading class RateLimiter: def __init__(self, max_calls_per_second2): self.min_interval 1.0 / max_calls_per_second self._lock threading.Lock() self._last_ts 0.0 def wait(self): with self._lock: now time.time() wait_time self.min_interval - (now - self._last_ts) if wait_time 0: time.sleep(wait_time) self._last_ts time.time()初次全量抓取时我建议用每秒1到2次的速度慢慢跑五千只股票大概需要四十多分钟到一小时。这个速度虽然慢但胜在安全。之后每天增量更新只需要拉当天的行情几百个请求一会儿就跑完了。数据去重同样重要。daily_quote表里的联合唯一约束已经能兜底但代码层也要做好判断避免重复请求浪费流量。我采用的策略是“先查库再抓取”对每个股票在抓取前查一下库里已有的最新交易日只抓最新日期往后的数据。这样既能完成增量更新又能确保断点续跑时不重复劳动。4.4 数据清洗与复权处理行情数据抓下来不能直接入库。原始数据常见的问题有几个除权日价格断层、停牌股成交量缺失、个别接口返回字符串类型数值。这些都会影响后续分析的质量。复权处理是最需要重视的。股票分红送股后价格会突然跳空不复权的话K线图上会留下一个假缺口。OpenStock支持前复权和后复权两种口径实际使用时我推荐历史回测统一用后复权。原因很简单后复权是以股票上市首日价格为基准把所有分红送股都累加回去历史价格曲线是连续的计算收益率时直接拿后复权价格做差即可不会因为区间不同产生口径偏差。清洗逻辑的伪代码如下def clean_quote(record: dict) - dict: # 过滤停牌或无效数据 if record[volume] is None or record[volume] 0: return None # 数值类型处理 for field in [open, close, high, low]: record[field] float(record[field]) record[volume] int(record[volume]) record[amount] float(record[amount]) if record[amount] else 0.0 return record我在实际抓取中发现停牌日的成交量返回的数据形态不统一有的返回0有的返回空字符串有的直接缺行。统一在清洗阶段处理掉数据库里的数据质量才能保证。5. 定时任务、异动告警与通知5.1 定时调度设计OpenStock作为自托管系统一旦部署到服务器上就得可靠地按天运行。定时调度我选用APScheduler它的CronTrigger和Linux crontab语法接近上手成本低而且可以直接嵌入FastAPI进程不用额外起一个独立的调度服务。核心配置如下from apscheduler.schedulers.background import BackgroundScheduler from apscheduler.triggers.cron import CronTrigger def init_scheduler(): scheduler BackgroundScheduler(timezoneAsia/Shanghai) # 每天15:10抓取当日日线数据等交易所收盘清算完 scheduler.add_job( job_daily_fetch, CronTrigger(day_of_weekmon-fri, hour15, minute10), iddaily_fetch, replace_existingTrue, ) # 每5分钟检查一次告警规则 scheduler.add_job( job_alert_check, CronTrigger(day_of_weekmon-fri, hour9-15, minute*/5), idalert_check, replace_existingTrue, ) scheduler.start()时间点选择是有讲究的。A股15:00收盘15:10抓数据比较合适既能覆盖清算后的最终结果又不会因为过早请求而拿到不完整的数据。盘中检查告警频次我设为5分钟这个粒度对个人玩家足够了抓太频容易给免费数据源增加压力。我自己实际还遇到一个情况程序因为网络问题挂了一会儿等恢复时会发现当天定时任务没有执行。为此我准备了一个启动补偿函数在每次启动时检查当天数据是否已抓取完成没完成就立刻补抓。这类“自愈”机制对长期运行的小系统很重要。5.2 自选股异动告警告警功能是OpenStock的另一个重头戏。它的核心思想很简单给自选股配置一组规则当实时或收盘数据满足条件时触发通知。规则以JSON配置存储不用改代码就能加新规则。一个典型的告警规则配置长这样{ name: 放量上涨监控, enabled: true, scope: [600519.SH, 000858.SZ], conditions: { change_pct: { gt: 5.0 }, volume_ratio: { gt: 2.0 } }, notify_channels: [serverchan, dingtalk], cooldown_minutes: 60 }cooldown_minutes字段特别说一下官方叫“冷却时间”。如果没有它某只股票在一个小时内持续触发条件你可能会收到十几条相同推送手机直接被打爆。加上冷却时间后同一标的发生相同规则只推送一次等过了冷却窗口才会再次触发。5.3 通知渠道接入OpenStock支持三种通知渠道Server酱、钉钉机器人、SMTP邮件。三者的接入方式差异很大。Server酱是个人消息推送服务绑定微信后通过一个Webhook就能把消息推送到手机微信。它最大的优点是接入简单只要在配置里填一个Key即可是我个人最喜欢的渠道。钉钉机器人需要先在钉钉群里添加自定义机器人获得一个Webhook地址。请求体是JSON格式curl -X POST https://oapi.dingtalk.com/robot/send?access_token你的TOKEN \ -H Content-Type: application/json \ -d { msgtype: text, text: { content: OpenStock告警600519.SH 涨幅5.2%成交量放大2.3倍 } }SMTP邮件是最后的兜底方案但我不太推荐作为主力通知渠道因为邮件容易进垃圾箱而且推送延迟不可控盘中告警的意义会打折扣。通知渠道的优先级我建议这样排Server酱或钉钉走实时推送邮件只做每日摘要。比如每天收盘后推送一份“今日行情概览”邮件记录哪些股票触发了规则既给了完整记录又不会过度打扰。6. 部署上线Docker容器化与反向代理6.1 用Docker Compose编排整套服务本地开发跑通后正式部署我强烈建议用Docker Compose把后端、前端、数据库全部容器化。这样做最大的好处是环境一致性换一台服务器不会有“在我机器上明明是好的”这种问题。项目里已经提供了生产用的docker-compose.yml内容大致如下version: 3.8 services: backend: build: context: . dockerfile: docker/Dockerfile.backend env_file: - backend/.env volumes: - openstock-data:/app/data restart: unless-stopped ports: - 8000:8000 frontend: build: context: . dockerfile: docker/Dockerfile.frontend restart: unless-stopped nginx: image: nginx:1.24-alpine ports: - 80:80 - 443:443 volumes: - ./docker/nginx.conf:/etc/nginx/conf.d/default.conf - ./certbot/www:/var/www/certbot - ./certbot/conf:/etc/letsencrypt depends_on: - backend - frontend restart: unless-stopped postgres: image: postgres:14-alpine environment: POSTGRES_USER: openstock POSTGRES_PASSWORD: change_me POSTGRES_DB: openstock volumes: - openstock-postgres:/var/lib/postgresql/data restart: unless-stopped volumes: openstock-data: openstock-postgres:后端容器里跑的是uvicorn服务同时由supervisor管理APScheduler定时任务保证两个进程都能存活。前端容器构建的时候会把Vue打包成静态文件由Nginx统一托管。启动命令非常简单docker compose up -d --build在项目根目录执行这条命令Compose会依次构建镜像、启动容器。第一次构建较慢因为要拉基础镜像和安装Python/Node依赖之后增量构建就快很多。6.2 Nginx反向代理与HTTPS容器起来后所有服务都绑定在Docker内部网络外部只暴露Nginx的80和443端口。Nginx配置里需要注意两点。第一前端静态资源和后端API要区分路由。前端打包产物放在/usr/share/nginx/html后端接口走/api前缀反向代理到backend容器。这样同一个域名既能访问页面也能访问数据接口不需要额外开端口。第二HTTPS证书。现在申请免费证书很方便推荐用Lets Encrypt。第一次手动申请之后配置自动续期脚本就行。server { listen 80; server_name stock.example.com; location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://backend:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }需要注意很多免费接口对User-Agent和Referer有校验而且proxy_pass后面的域名取决于Docker网络里的服务名。实际配置时backend的地址要写成Docker Compose中的服务名backend不要写localhost这一点对新手特别容易踩坑。6.3 数据备份策略跑了半年后你数据库里的行情数据会越来越珍贵备份这件事必须提前做。我的实践是双保险容器里用cron每天凌晨把PostgreSQL数据导出为SQL文件然后同步一份到本机磁盘或对象存储。docker compose exec -T postgres pg_dump -U openstock openstock backup/openstock_$(date %Y%m%d).sql备份文件保留近30天超过的自动清理。万一哪天误操作删了数据直接导入备份文件就能恢复。我建议每季度手动验证一次备份能否正常恢复别等真出事才发现备份文件是坏的。7. 我踩过的坑与建议7.1 时区问题导致K线错位我在前面提过时区问题这里展开说下具体症状。第一次部署时我用默认的UTC时区运行结果入库的trade_date比实际晚了8小时。日线级别还好只是日期错位一天但分钟级数据直接全乱——K线图上一根根柱子跟实际盘面完全对不上。排查过程很简单打开数据库查几条记录对比接口返回的时间一下子就发现了。解决办法也简单在配置文件的数据库连接串里明确时区在Python侧设置pytz.timezone(Asia/Shanghai)同时在APScheduler启动时指定相同时区。三处统一后问题彻底消失。这类坑非常隐蔽排查一次后就记住了。7.2 停牌股造成的数据异常停牌股是另一个高发坑。某只股票停牌期间当日K线要么缺行要么返回成交量0但价格沿用上一交易日数据。如果后端直接拿原始数据算涨幅会出现“明明停牌了却显示上涨5%”的怪相。我的处理方案是在清洗阶段过滤掉volume 0或trade_date为空的记录。同时在告警模块里增加一条规则当日无成交量的股票不参与任何涨幅计算。这样既保证了计算合理性也避免误报。7.3 免费数据源接口突然改动运营了几个月后大概率会碰到一件事某个免费数据源突然调整了接口参数或字段名抓取程序开始报错。AkShare这类聚合库通常是上游变了之后跟着发新版本如果你锁了旧版本号就得手动升级。我的应对方式是组合拳。首先采集模块保持多源冗余设计主源挂了立刻切备用源。其次给抓取任务加失败告警只要连续N次失败就推送通知到手机及早发现。最后给周末留一个固定的“自检窗口”批量把前五天的数据重抓一遍用来弥补日常漏抓。7.4 后续还能扩展什么OpenStock跑顺以后很多朋友会问我下一步能加什么。我自己的经验是可以从三个方向入手。一是指标计算层在采集数据之上加MA、MACD、布林带等常用技术指标存成独立表供前端绘图。二是市场热度统计计算每日涨跌停数、涨停连板高度、成交额分布生成一个简单的大盘情绪面板。三是接入模拟盘或paper trading把告警规则直接对接模拟交易环境验证自己的策略逻辑而不用真金白银。这些扩展的共同前提是OpenStock已经把数据底座搭好了剩下的只是自由发挥。数据在手想怎么折腾都行。最后再分享一个实际运营的小技巧如果发现有时候行情数据出现零散缺失不用急着全量重抓。可以写一个简单的补偿脚本拉取最近10个交易日的数据按联合唯一约束做“冲突忽略”插入。这样即能补上缺失的数据又不会影响已经存在的正确记录。这样运行了半年下来我的OpenStock数据库基本没有断档过数据质量比我预想中要好得多。