12、程序化交易框架：事件驱动架构设计、策略回测引擎搭建、实盘接口对接要点

各位同学，今天咱们聊点硬核的。基差交易做到一定阶段，你会发现手动盯盘、手动下单根本忙不过来。尤其是跨期套利、期现套利这种需要高频监控价差的策略，没有程序化框架，你连觉都睡不好。

我个人习惯，把程序化交易框架拆成三大块：事件驱动架构、回测引擎、实盘接口。这三块搞定了，你的策略就能从“手工小作坊”升级成“自动化流水线”。

12.1 事件驱动架构设计

先说说事件驱动。说白了，就是你的程序不能“傻等”，而要“监听”。市场行情来了、订单成交了、风控触发了——这些都是事件。你的程序要像雷达一样，捕捉到事件后立刻做出反应。

我在项目中遇到过一个问题：刚开始用轮询方式，每秒去查一次行情。结果CPU跑满，延迟还高。后来改成事件驱动，性能直接翻倍。

事件驱动架构的核心组件：

• 事件源：行情推送、成交回报、定时器、用户指令
• 事件队列：先进先出，保证事件顺序
• 事件处理器：策略逻辑、风控检查、订单管理
• 事件分发器：把事件路由到对应的处理器

下面这张图，是我自己项目里用的架构，你参考一下：

嗯，这里要注意：事件队列一定要用无锁队列或者高性能消息中间件。我早期用Python的queue.Queue，回测没问题，一上实盘就卡死。后来换成ZeroMQ，才搞定。

12.2 策略回测引擎搭建

回测引擎，说白了就是“时光机”。你拿着历史数据，模拟跑一遍策略，看看赚不赚钱。但这里坑很多，我一个个说。

回测引擎的核心模块：

• 数据加载器：读取历史K线、Tick数据、价差数据
• 模拟撮合器：模拟订单成交，考虑滑点和手续费
• 策略容器：运行你的策略逻辑，生成买卖信号
• 绩效计算器：计算夏普比率、最大回撤、胜率等

我曾经犯过一个低级错误：回测时没考虑“未来函数”。就是用了未来数据去判断当前信号。结果回测曲线漂亮得像假的一样，实盘直接亏成狗。你想想看，这种事多坑人。

下面是一个简单的回测引擎代码骨架，我用Python写的：

class BacktestEngine:
    def __init__(self, data, strategy):
        self.data = data          # 历史数据
        self.strategy = strategy  # 策略实例
        self.positions = []       # 持仓记录
        self.trades = []          # 成交记录
        
    def run(self):
        for i, bar in enumerate(self.data):
            # 1. 更新当前市场状态
            self.strategy.on_bar(bar)
            
            # 2. 获取策略信号
            signal = self.strategy.get_signal()
            
            # 3. 模拟撮合
            if signal is not None:
                trade = self.match_order(signal, bar)
                self.trades.append(trade)
                
            # 4. 更新持仓和资金
            self.update_portfolio(bar)
            
    def match_order(self, signal, bar):
        # 模拟成交，考虑滑点
        slippage = 0.5  # 0.5个tick
        fill_price = bar.close + slippage if signal.direction == 'buy' else bar.close - slippage
        return Trade(signal.size, fill_price, bar.timestamp)

回测还有一个关键点：过拟合检测。你调参数调得太多，回测曲线会很好看，但实盘一塌糊涂。我习惯用“样本外测试”来验证——把数据分成前70%和后30%，前段调参，后段验证。如果后段表现差，说明策略有问题。

12.3 实盘接口对接要点

实盘接口，这是最头疼的部分。每个交易所的API都不一样，而且动不动就改。我接过的接口不下10个，CTP、XTP、Futu、IB……各有各的脾气。

实盘对接的核心要点：

1. 连接管理：断线重连、心跳检测、会话保持
2. 行情订阅：按需订阅，不要全量拉取
3. 订单管理：订单状态机、撤单逻辑、异常处理
4. 资金风控：实时监控可用资金、持仓、保证金
5. 日志记录：所有操作都要留痕，方便排查问题

我个人习惯，把实盘接口封装成统一的抽象层。不管底层是CTP还是XTP，上层策略看到的接口都一样。这样换交易所时，只需要改底层实现，策略代码不用动。

下面是一个接口抽象层的示例：

class ExchangeInterface(ABC):
    @abstractmethod
    def subscribe(self, symbols: list):
        """订阅行情"""
        pass
    
    @abstractmethod
    def place_order(self, symbol, side, price, quantity):
        """下单"""
        pass
    
    @abstractmethod
    def cancel_order(self, order_id):
        """撤单"""
        pass
    
    @abstractmethod
    def get_position(self, symbol):
        """查询持仓"""
        pass

还有一个要点：风控前置。不要把风控逻辑放在交易所端，要在本地先检查。比如单笔下单量不能超过总资金的5%，日内亏损超过2%就停止交易。这些规则要在本地代码里写死，不要依赖交易所的限价。

模块	关键指标	我的建议值
连接管理	心跳间隔	3秒
行情订阅	最大订阅数	不超过50个合约
订单管理	超时重试次数	3次
资金风控	单笔最大资金占比	5%
日志记录	保留天数	30天

最后说一句：实盘上线前，一定要做模拟盘测试。用模拟资金跑一周，看看有没有bug，看看延迟是否在可接受范围。我见过太多人，回测完直接上实盘，结果第一天就爆仓。别急，稳一点。