先说个题外话。量化交易这东西很多人一开始都是在本地电脑上跑策略的白天盯盘、晚上回测数据落在自己的硬盘里策略跑在自己机器上。前几个月我也这么干直到有一天晚上策略在跑夜盘小区突然停电路由器跟着罢工第二天一看该止损的单子没止损该进场的信号也错过了一整段行情。那一刻我就明白期货量化策略部署实战这件事从本地到云端不是“锦上添花”而是“早晚要做”。这篇博文主要想聊的就是我自己把一套期货量化策略从本地电脑搬到云服务器上完整过程从方案选型、环境准备、数据接入、回测检验到模拟盘切换、进程守护和监控告警。适合正在本地跑策略、准备上云的朋友参考也适合刚接触量化的新手了解一下整个部署链路里有哪些坑。1. 方案与框架选型先想清楚为什么要上云1.1 本地运行的三个真实痛点本地跑策略表面看只是“电脑开着就行”实际操作过的人都知道问题不少。第一是稳定性。家用电脑和路由器不是为7x24小时运行设计的系统更新会重启内存泄漏会卡顿网络闪断更是家常便饭。期货夜盘到晚上十一点很多策略恰恰在夜盘出信号机器一断策略就变成瞎子。第二是延迟。本地到期货公司柜台系统的网络链路中间经过多少跳谁也不知道。行情先到你家宽带再从中转发出去下单指令多了好几层传输。对于日内高频或者抢单型策略这种延迟会直接吃掉利润即便是普通分钟级策略网络抖动也会导致信号时间戳不准确后续分析白瞎。第三是托管成本。白天要上班、晚上要睡觉策略却要一直盯盘。总不可能凌晨两点起来看看进程还活着没有。上云之后服务器在机房跑你只需要看监控告警省心太多。1.2 从本地到云端的整体架构部署本质上就是把原来“单机跑一切”拆成几个清晰模块。我按下面这个结构来组织行情模块负责连接期货公司行情服务器接收实时行情推送同时管理历史数据的补下载和落盘。策略模块接收行情事件触发信号生成目标持仓和委托指令。交易模块连接柜台交易接口负责报单、撤单、查询成交、管理持仓。风控模块独立于策略检查单笔下单量、持仓上限、亏损限额异常时直接拦截。监控模块采集策略运行状态、账户资金、持仓变化通过日志和告警通知到手机。架构上我是刻意把风控独立出来的不能让它和策略代码混在一起。你永远无法保证策略代码没bug但风控逻辑必须简单可靠越简单越不容易出问题。风控没过什么都不允许发出去。1.3 框架选型开源量化框架还是自己写量化框架的选择直接影响后续开发效率。我个人的建议是不要一上来就用特别重型的框架。很多开源量化框架功能齐全但学习成本高、黑盒多出了问题不好排查。我自己用的是轻量级框架思路核心就是事件循环加回调函数行情来了触发策略函数策略函数返回指令交易模块负责执行。选择轻量方案的理由有三点。第一代码完全可控每一行都清楚在干什么出了问题能快速定位第二部署时依赖少不需要装一整套复杂环境第三期货策略相对股票来说标的集中、信号频率没那么高轻量架构完全够用。如果你已经有现成的策略代码不必强行迁移到某个框架只要把策略逻辑和数据接口解耦保持行情接入、策略计算、交易报单三个环节独立整体架构就不会太乱。2. 环境准备与代码工程化2.1 云服务器选型与初始化服务器配置不用太高但有几项必须达标。CPU方面普通分钟级期货策略2核就够用低频策略甚至1核也能跑内存的话4G起步因为要加载历史数据、保存行情快照策略进程本身也常驻带宽选固定1M就够行情推送和交易指令都是小数据包不需要大带宽。关键是硬盘建议至少50G SSD日志会慢慢涨历史数据也会积累。系统我用的是主流Linux发行版。选Linux不是因为它时髦而是因为稳定性和资源占用确实比Windows有优势一个策略进程跑几个月不重启也很正常。另外云厂商控制台的防火墙和安全组设置要注意只放行需要用到的端口不要把所有端口裸奔到公网。交易接口连接通常由服务器主动外连不需要对外开放入站端口所以安全配置其实很简单。初始化的时候有几项系统参数得调不调后面容易出问题。比如最大文件句柄数默认1024可能不够调大一些还有TCP连接复用参数减少频繁建立连接带来的延迟。这些都是基础运维活但直接影响策略稳定运行。2.2 代码目录结构与配置管理上云之后代码不可能还像本地那样散落一堆。我习惯按功能模块组织大致是这个样子/home/deploy/futures_quant/ ├── config/ │ ├── strategy.yaml │ └── deploy.env ├── collector/ │ ├── market_data.py │ └── history_loader.py ├── strategy/ │ ├── strategy_base.py │ └── trade_signal.py ├── trader/ │ ├── order_manager.py │ └── risk_check.py ├── monitor/ │ ├── heartbeat.py │ └── alert.py ├── logs/ │ ├── market/ │ ├── strategy/ │ └── trade/ └── run_main.py配置管理的核心原则是代码和配置分离。策略参数、账户信息、服务器地址这些全部放到yaml或env文件里代码里面不写死任何环境相关的值。这样做的好处是本地测试、云端模拟盘、云端实盘共用一套代码切环境只需要改配置。特别提醒一下账户密码和API密钥不要明文提交到仓库。我的做法是部署时通过环境变量注入配置文件里留占位符真正运行的时候从单独的文件读取。这个习惯能避免很多麻烦。2.3 日志体系不能只靠print本地调试时print够了但云端跑策略print等于裸奔。日志系统至少要满足几点要求。按模块分类。行情日志、策略日志、交易日志分开写不然出了问题要在几百万行日志里翻找。按级别过滤。平时记录INFO调试时开DEBUGERROR单独输出到一个文件方便第一时间看。日志滚动。单个日志文件不能无限增长我按天分文件同时设置单文件大小上限超过自动切割。日志内容方面要把关键信息都打出来行情时间、策略信号、委托价格、成交回报、资金变化、异常堆栈。宁可日志多而全不要少而缺。很多事故复盘到最后都是因为日志记录不全面事后根本无法还原当时的完整状态。3. 数据链路与行情接入3.1 历史数据准备和校验策略要跑先得有历史数据。很多初学者上来就回测但回测用的历史数据和实盘行情不一致最后跑出来结果全是噪音。历史数据我用两种方式准备一部分从公开数据源下载一部分在本地用行情模块持续录制积累一段时间后自然形成自己的数据库。自己录的数据最可靠因为格式、时间、复权处理都清楚但需要花时间积累。下载的数据要注意合约换月问题期货有到期日不同月份的合约价格不连续回测时需要做拼接或使用主力连续合约。数据校验是个容易被忽视的环节。拿到数据后一定要检查时间戳是否连续、是否有跳变、价格是否有异常极值、成交量是否为负数这些低级错误。我曾经下载过一组数据其中某个交易日少了一个小时如果不检查直接回测策略在那个时段的行为完全是虚构的结果自然不可信。3.2 实时行情接入与重连机制实时行情是期货量化的血液。国内期货行情一般通过期货公司提供的柜台接口获取连接之后会推过来行情快照和逐笔委托数据。接入行情的核心不是“连上就完事”而是重连机制。网络闪断是常态长连接不可能永远不变。我的行情模块里专门写了自动重连逻辑心跳检测每隔几秒检查与行情服务器的连接状态超过阈值没有收到行情数据判定为异常。指数退避重连第一次断开后等待几秒重连失败后等待时间翻倍避免疯狂重连给服务器造成压力。数据补拉重连成功后主动请求断开期间缺失的K线保证数据完整性。实测下来这套机制能让行情断线的影响降到最低。关键是补拉数据这一步很多新手容易忽略结果行情期间断了几分钟策略用的K线少了信号计算就偏了。3.3 时钟同步与数据时间对齐期货行情对时间非常敏感但服务器时钟不一定准。第一次上云时我犯过这个错误以为云服务器的系统时间肯定没问题结果日志时间和行情时间差了十几秒排查了半天才发现是NTP没配置。在服务器上必须启用时间同步服务让系统时钟自动和标准时间源对齐。同时所有数据处理统一使用行情时间戳而不是本地系统时间。比如某根K线的开始时间应以行情源推送的时间戳为准本地接收时间只做参考。行情数据落盘时尽量存原始格式的tick数据。不要把tick合成K线的逻辑做在采集端否则后续想换K线周期、改复权方式就要重新回测。tick是原始数据K线是加工产物保留原始数据永远是正确的选择。4. 策略回测与参数检验4.1 回测环境先搭好别裸跑本地部署前策略大概率已经在本地跑过回测但上云之后回测环境可能会变化。建议在云端先搭建一套与实盘一致的回测环境包括相同的数据接口、相同的撮合逻辑、相同的费率设置。一开始我们用的是简化撮合默认按当前价格成交、不考虑滑点回测收益曲线非常漂亮。后来把手续费、滑点、涨跌停限制加进去收益立刻缩水一半。这不是策略变差了是之前的回测太理想化。回测环境里对撮合逻辑的要求至少要注意三点开盘集合竞价如何处理、涨停跌停时能否成交、排队造成的成交概率如何模拟。如果复杂撮合实现不了简单的做法是保守一点假设所有信号都只能以不利价格成交相当于给策略人为加滑点收益曲线虽然难看但更接近实盘。4.2 手续费和滑点设置的经验值期货的手续费因品种而异有些是按固定金额有些是按成交金额比例。滑点则根据品种流动性不同差异很大。我的经验参考值螺纹、热卷这类流动性好的品种单跳滑点可能就够农产品和部分化工品流动性差的要多预留一些。计算过程不复杂比如某品种手续费是成交金额的万分之几一手合约乘数多少当前价格多少就能算出单次往返手续费。滑点则按不利方向多走两跳来估算。把这些加总到每次交易成本里回测才算靠谱。就算回测时设置了相对理想的手续费和滑点实盘也会更差一点。所以我的原则是回测能给多少利润实盘先按七折考虑回测如果本身就贴着零轴挣扎那这个策略最好别上实盘。4.3 过拟合与样本内外检验上云之前策略到底能不能上线不能只看全样本回测收益还要做样本外验证。这是我踩过最深的坑之一。常见做法是把历史数据分成两段前70%用于参数优化后30%当作未知行情做验证。如果在后30%上策略依然稳定盈利说服力就强很多。另外一个更稳妥的做法是滚动窗口验证不断往前推进训练窗口和验证窗口看看策略在不同市场环境下的表现是否一致。参数上也要留意过拟合。有些策略参数特别多通过网格搜索总能找到一组历史收益极高的参数但换一段行情就失效。我的判断标准是最优参数附近的邻域策略收益不应该急剧下降。如果参数稍微调一点点收益就从正翻负那这组参数基本是过拟合的产物不能上线。5. 从模拟盘切实盘的关键操作5.1 模拟盘阶段要跑多久从回测到实盘之间模拟盘是必经之路。但很多人把模拟盘当成形式跑几天没问题就急着上实盘这个心态要不得。模拟盘的主要作用不是验证策略盈利能力而是验证整个部署系统是否正确运转。代码在实盘环境下的表现、网络连接是否稳定、订单管理是否有遗漏、日志是否完整这些才是模拟盘要回答的问题。模拟盘建议至少跑两到四周。这两周里不光要观察策略信号还要故意制造一些异常手动断开网络、重启服务器、切换行情源看看系统能不能自己恢复。只有把这些故障场景都演练过实盘才不会手忙脚乱。5.2 订单管理和风控前置订单管理是交易模块的核心。期货下单不是发一条指令就结束而是要经历委托提交、排队、部分成交、全部成交、撤单、废单等各种状态。订单管理器必须能正确追踪每一步状态变化。最重要的原则是任何情况下不要让策略逻辑直接送单到柜台。中间必须隔着订单管理器。策略只表达“我要以什么价格买多少”订单管理器负责拆分、排队、幂等检查、和成交回报对账。这样可以避免重复下单、漏单这些问题。风控前置是另一条生命线。我代码里设置了多道检查单笔下单量不得超过设定上限。同一合约同方向持仓不得超过账户资金对应杠杆上限。日内亏损达到阈值停止开新仓。持仓超过规定的合约范围直接拒绝。这些检查必须在交易链路的最前端独立于策略逻辑。策略可以出错风控不能出 bug。哪怕某天策略突然抽风狂发信号风控也能把它拦下。5.3 小资金实盘的灰度策略模拟盘跑顺了直接上正常资金量也不是好选择。我的做法是先放最小资金量跑一段时间比如账户只放计划资金的十分之一目标不是赚钱而是观察实盘滑点和回测预估差多少。柜台接口在真实报撤单过程中的表现。策略信号到成交之间的延迟是否符合预期。系统长时间运行的内存、CPU、网络状态。小资金阶段至少跑一周。如果这一周里系统稳定、滑点可控、成交逻辑正确再逐步加资金量。量化部署的每一步都应该是渐进式的千万不要跨大步。6. 进程守护、自动重启与监控告警6.1 systemd 守护进程配置云端部署后系统进程必须能自启动、掉线自动拉起。我用的是 systemd 服务配置非常简单关键是 Restart 策略要设置合理。实际配置大致如下[Unit] DescriptionFutures Quant Strategy Service Afternetwork-online.target [Service] Typesimple Userdeploy WorkingDirectory/home/deploy/futures_quant EnvironmentFile/home/deploy/futures_quant/config/deploy.env ExecStart/home/deploy/futures_quant/venv/bin/python run_main.py Restartalways RestartSec10 StartLimitIntervalSec0 [Install] WantedBymulti-user.target注意几个细节Ensure 使用虚拟环境里的 Python不要用系统 PythonRestartSec 设置成 10 秒避免频繁重启把系统资源耗干StartLimitIntervalSec 这个参数要注意默认配置下系统如果检测到多次启动失败会放弃重启实盘场景下这个限制通常要关掉因为行情中断比无限重启更危险。当然这个取舍要根据实际风险来权衡。配置完后用 systemctl enable 让服务开机自启再用 systemctl start 启动平时查看状态用 systemctl status。6.2 自动重启脚本与行情补回纯依赖 systemd 可能还不够因为致命异常下进程可能会直接进入假死状态。所以我额外写了一个看门狗脚本定期检测策略进程是否还活着、有没有正常处理行情。看门狗脚本逻辑不复杂定时向策略进程发一个轻量探测信号或者检查最近一次日志更新时间。如果超过设定阈值没有动静就触发重启。重启后第一件事是补拉错过的K线把断档的数据补回再继续运行。行情补回这块我在行情模块里预留了一个接口重启时读取本地数据库里最新K线时间戳然后向行情源请求从那个时间点到当前时间的数据。没有这个机制策略重启后会拿着不完整的K线算信号结果会非常离谱。6.3 监控告警把系统状态送到手机服务器放在机房人不在旁边告警就是唯一的眼睛。我的告警层级从三条线来设计第一层是系统级监控。CPU、内存、磁盘、网络这些会崩溃基础设施的指标用简单的脚本加定时任务检查异常就发送告警。第二层是业务级监控。比如行情连续N秒没有更新、策略进程心跳停止、订单状态异常、可用资金不足。第三层是异常交易监控。成交回报和策略预期不一致时立刻触发告警并暂停新交易。推送渠道我用的是消息推送服务配置好之后直接推到手机App。坚持“宁多勿漏”的原则。刚开始我嫌告警吵把很多阈值调得很宽松结果有一次行情源断流半小时都没发现。后来学乖了告警宁可误报多一点也不能漏掉真异常。7. 常见问题与排障实录7.1 常见问题速查表现象可能原因排查方向策略进程还在但没有新信号行情流断线而重连失败检查行情心跳日志、网络连接状态日志里大量重复报单订单状态没有正确更新检查成交回报回调是否正常处理回测收益好实盘完全跑不出撮合假设过于理想重新评估滑点和手续费假设服务器内存持续增长内存泄漏或日志缓存堆积用内存分析工具定位泄漏点重启后策略信号异常历史K线没有补回检查补拉数据接口日志盘中网络闪断恢复后大幅亏损缺少重连和补拉机制完善自动重连和数据补偿逻辑这些基本是上线初期最常见的问题每一条背后都有人踩过坑。7.2 印象较深的一次故障行情源静默有次系统跑了两周都好好的突然某天盘中一条告警都没有但我直觉不对劲登录服务器一看策略进程活着日志也停在正常输出的样子但实际上行情已经停了将近半小时。原因是行情源推送异常但不是直接断开心跳机制没检测到因为心跳包和行情数据是分开通道的行情断了但心跳通道还正常。后来我把检测逻辑改为连续N秒没有行情K线更新就告警而不是只看连接状态。这个问题的教训是量化系统的健康检查必须以业务指标为准不能只看系统层面是否“活着”。7.3 部署过程中的避坑清单火墙和安全组检查双份都不嫌多但端口不要全部开放公网。生产环境不要用 root 用户跑策略用低权限用户。配置文件里的账户密码要做脱敏处理。任何变更先备份改完先重启验证再等下一根K线。升级策略代码时先并行运行新旧版本对比信号是否一致。行情数据和日志都属于重要资产定期同步备份到本地。自己踩过一圈之后回头看这些条目每一条背后都对应过一次真实的故障处理。最后说几句从本地到云端表面上只是换了一台机器跑代码实际是把一套业余流程改造成专业生产系统的过程。我自己的体会是前期多花点时间在环境工程、容错机制和监控告警上后面就能省下很多个失眠的夜晚。真正让策略稳定盈利的除了策略本身还有它运行的环境是否足够可靠。这个道理只有经历过半夜爬起来处理故障的人才会懂。如果你正准备把本地策略搬到云端我的建议很简单先把系统架构画清楚再动手搭环境。风控模块、日志体系、进程守护这些看起来不性感、不核心的工作恰恰是决定策略能不能长期稳定跑下去的关键。希望这篇部署实战的梳理能帮到正在这条路上摸索的你。
