实战案例十：做市策略的部署与监控系统设计
做市策略写好了，回测也跑通了，然后呢？
很多新手会卡在这一步——策略在本地跑得挺好，一上实盘就各种幺蛾子。我见过太多人，策略代码写得漂漂亮亮，结果部署上去三天没看，服务器宕机了都不知道。
说白了，做市策略的部署和监控，才是真正考验工程能力的地方。今天我就把我在生产环境中摸爬滚打的经验，一次性讲清楚。
一、部署架构的核心思路
我个人习惯把做市系统拆成三个独立模块：
- 策略引擎：负责计算报价、管理订单
- 数据管道：负责行情接入、数据清洗
- 监控看板：负责状态展示、告警通知
为什么要拆？我在项目中遇到过，一开始把所有逻辑写在一个进程里，结果行情数据稍微大一点，整个系统就卡住了。拆开之后，每个模块可以独立扩缩容，出问题也容易定位。
核心原则：每个模块只做一件事，并且做好一件事。
下面这张图是我常用的部署架构，你可以直接拿来用：
二、部署环境的选择
做市策略对延迟要求很高。我个人建议用云服务器，但要注意选对机房。
| 环境 | 延迟 | 成本 | 适用场景 |
|---|---|---|---|
| 本地服务器 | 最低 | 高 | 高频做市 |
| 云服务器（同机房） | 低 | 中 | 中频做市 |
| 云服务器（跨机房） | 较高 | 低 | 低频/回测 |
我曾经犯过一个错误——把策略部署在离交易所很远的机房，结果每次报价都比别人慢几百毫秒。你想想看，做市拼的就是速度，慢一拍可能就吃不到单了。
小技巧：选云服务器时，先跑个ping测试。延迟超过5ms的，直接pass。
三、监控系统的设计要点
监控系统不是摆设，它是你的第二双眼睛。我设计监控系统时，重点关注三个维度：
- 系统健康度：CPU、内存、网络、磁盘
- 策略运行状态：持仓、盈亏、订单成交率
- 市场异常检测：价格跳空、流动性骤降
嗯，这里要注意——不要什么指标都往监控里塞。我在项目中见过有人监控了50多个指标，结果真正出问题时，反而被噪音淹没了。
避坑指南：我曾经把告警阈值设得太敏感，结果半夜被钉钉消息轰炸了十几次。后来学乖了，告警要分级：
- P0（致命）：系统宕机、资金异常 → 电话通知
- P1（严重）：策略停止、网络断开 → 即时消息
- P2（警告）：延迟升高、成交率下降 → 邮件通知
四、代码实现：一个轻量级监控框架
下面是我常用的监控框架，用Python写的，简单实用：
import time
import json
import requests
from datetime import datetime
class Monitor:
def __init__(self, webhook_url):
self.webhook_url = webhook_url
self.metrics = {}
def record(self, name, value):
"""记录指标"""
self.metrics[name] = {
'value': value,
'timestamp': datetime.now().isoformat()
}
def check_health(self):
"""检查系统健康度"""
alerts = []
# 检查策略是否在运行
if 'last_trade_time' in self.metrics:
elapsed = time.time() - self.metrics['last_trade_time']['value']
if elapsed > 60: # 超过60秒没有交易
alerts.append(('P1', '策略可能已停止'))
# 检查持仓是否异常
if 'position' in self.metrics:
pos = self.metrics['position']['value']
if abs(pos) > 1000: # 持仓超过阈值
alerts.append(('P2', f'持仓异常: {pos}'))
return alerts
def send_alert(self, level, message):
"""发送告警"""
payload = {
'msgtype': 'text',
'text': {
'content': f'[{level}] {message}'
}
}
requests.post(self.webhook_url, json=payload)
# 使用示例
monitor = Monitor('https://your-webhook-url')
monitor.record('position', 500)
monitor.record('last_trade_time', time.time())
alerts = monitor.check_health()
for level, msg in alerts:
monitor.send_alert(level, msg)
个人经验：这个框架我用了两年，最大的好处是轻量。你不需要引入Prometheus、Grafana那些重型武器，一个脚本就能搞定大部分监控需求。
五、部署流程自动化
手动部署？别闹了。我见过有人每次更新策略都要SSH登录服务器，然后手动拉代码、重启进程。万一哪天忘了，策略跑的还是旧版本。
我的做法是用Docker + CI/CD：
# Dockerfile
FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "main.py"]
配合GitHub Actions，每次push代码后自动构建镜像、推送到仓库、然后在服务器上拉取最新镜像并重启。整个过程不到30秒。
关键点：自动化部署不只是省事，更重要的是——它消除了人为操作带来的风险。你想想看，凌晨两点出bug了，你是手动修复还是让CI/CD自动回滚？
六、日志管理
日志是排查问题的第一手资料。我要求所有日志必须包含：
- 时间戳（精确到毫秒）
- 日志级别（DEBUG/INFO/WARNING/ERROR）
- 模块名称
- 关键上下文（订单ID、价格、数量）
举个例子：
2024-01-15 14:23:45.123 | INFO | strategy | 订单已发送 | id=12345, price=0.0012, qty=1000
2024-01-15 14:23:45.456 | WARNING | strategy | 订单部分成交 | id=12345, filled=500
2024-01-15 14:23:46.001 | ERROR | exchange | 连接超时 | retry=3
我曾经靠这种日志格式，半小时就定位到一个bug——原来是某个交易所的API在整点时会重置连接，导致订单丢失。如果没有日志，这种问题可能要排查好几天。
注意：日志不要打太多。我见过有人每笔订单打20行日志，结果一天下来日志文件几十个G。合理的做法是：正常运行时只打INFO级别，出问题时再切到DEBUG。
七、总结
部署与监控，说白了就是让你的策略能稳定运行，出了问题能快速发现、快速定位、快速恢复。
我个人觉得，做市策略的部署比策略本身更考验功底。你策略再牛，部署不好也是白搭。反过来，部署做得好，哪怕策略一般，也能稳定赚钱。
嗯，今天就聊到这儿。记住一句话：部署是策略的最后一公里，也是最重要的一公里。
无相订单流研究社 微信Lucian808555