第2章报价引擎架构

报价引擎架构：核心组件与低延迟设计

做市商报价引擎，说白了就是一个在极短时间内完成定价、风控、发单的系统。我做了这么多年量化，见过太多团队把报价引擎搞成「大泥球」——所有逻辑揉在一起，最后改个参数都要提心吊胆。今天咱们就来拆解一下，一个靠谱的报价引擎到底该怎么搭。

一、报价引擎的核心组件

我个人习惯把报价引擎拆成四个模块：行情接入、定价引擎、风控模块、订单管理。每个模块各司其职，互不干扰。

组件	职责	延迟要求
行情接入	解析交易所行情，去重、对齐时间戳	< 10μs
定价引擎	根据订单簿、库存、波动率计算报价	< 50μs
风控模块	检查净头寸、最大订单量、自成交	< 20μs
订单管理	维护挂单状态、处理撤单重发	< 30μs

你想想看，如果行情接入和定价引擎混在一起，行情来了还得等定价算完才能发单？那延迟就炸了。我在项目中遇到过这种情况：一开始图省事把行情解析和定价写在一个线程里，结果行情波动一大，报价就卡住。后来拆成独立线程，用无锁队列通信，延迟直接降了60%。

二、低延迟架构设计

低延迟的核心就一句话：减少一切不必要的操作。嗯，这里要注意，不是「优化」，而是「砍掉」。

2.1 数据路径优化

行情数据从网卡到应用层，每经过一层都会增加延迟。我建议的做法是：

使用内核旁路技术（如DPDK、Solarflare），跳过内核协议栈
内存池预分配，避免运行时malloc
数据序列化用FlatBuffers或Cap'n Proto，别用JSON

关键指标：从行情到达CPU到报价发出，总延迟应控制在100μs以内。超过这个数，你的报价可能已经过时了。

2.2 线程模型

我见过最糟糕的设计是：一个线程干所有事。行情来了、算价格、发单、写日志全在一个线程里。行情一密集，日志I/O就把CPU吃光了。

正确的做法是每个核心一个线程，线程之间通过无锁环形缓冲区通信。举个例子：

// 伪代码：无锁队列通信
struct MarketData {
    uint64_t timestamp;
    double bid, ask;
    uint32_t bid_vol, ask_vol;
};

// 行情线程 -> 定价线程
LockFreeQueue<MarketData, 1024> data_queue;

void market_thread() {
    while (true) {
        MarketData md = parse_packet();
        data_queue.push(md);  // 无锁，O(1)
    }
}

void pricing_thread() {
    while (true) {
        MarketData md = data_queue.pop();
        Price quote = calculate_price(md);
        // 发送报价
    }
}

小技巧：队列大小设为2的幂次，用位运算替代取模。我曾经因为这个优化，把队列操作从30ns降到了8ns。

三、事件驱动模型

报价引擎本质上是一个事件响应系统。行情来了是事件，成交回报来了也是事件。用事件驱动模型，天然适合这种场景。

我习惯用Reactor模式：一个事件循环（Event Loop）监听多个事件源，事件到来后分发到对应的处理器。这样做的好处是：

避免轮询浪费CPU
事件处理天然异步
容易扩展新的事件类型

举个例子，事件类型可以这样定义：

enum EventType {
    MARKET_DATA_UPDATE,   // 行情更新
    ORDER_FILL,           // 订单成交
    ORDER_REJECT,         // 订单被拒
    RISK_BREACH,          // 风控触发
    TIMER_TICK            // 定时器
};

struct Event {
    EventType type;
    uint64_t timestamp;
    union {
        MarketData md;
        FillReport fill;
        RejectReport reject;
    } data;
};

事件循环的核心逻辑：

void event_loop() {
    while (running) {
        Event evt = wait_for_event();  // epoll / kqueue
        dispatch(evt);
    }
}

为什么会这样设计？因为事件驱动让每个模块只关心自己该做的事。定价引擎不用管订单怎么发，订单管理不用管行情怎么来。耦合度降到最低。

避坑指南：我曾经在事件处理器里做了耗时操作（比如写数据库），结果阻塞了事件循环，导致后续行情全部延迟。记住：事件处理器里绝对不能有阻塞调用。耗时操作请扔到后台线程池。

四、模块化设计原则

模块化不是把代码拆成几个文件就完事了。真正的模块化，是每个模块可以独立测试、独立替换、独立部署。

4.1 接口隔离

每个模块只暴露必要的接口。比如定价引擎对外只提供一个函数：

class PricingEngine {
public:
    // 唯一对外接口
    Price get_quote(const MarketData& md, const Position& pos);
    
private:
    // 内部实现细节，外部不可见
    double calculate_spread(double volatility);
    double calculate_inventory_skew(double net_position);
};

这样做的好处是：你想换一个定价模型，只需要实现同一个接口，其他模块完全不用改。

4.2 依赖注入

模块之间不要硬编码依赖。比如风控模块需要知道当前持仓，不要直接new一个PositionManager，而是通过接口传入：

class RiskManager {
public:
    RiskManager(IPositionProvider* pos_provider, 
                IOrderManager* order_mgr) 
        : pos_provider_(pos_provider)
        , order_mgr_(order_mgr) {}
    
    bool check_risk(const Quote& quote) {
        auto pos = pos_provider_->get_position();
        // 检查净头寸是否超限
        if (abs(pos.net) > MAX_POSITION) return false;
        return true;
    }
    
private:
    IPositionProvider* pos_provider_;
    IOrderManager* order_mgr_;
};

你想想看，这样写单元测试多方便？传个mock对象进去就行了。我在项目中用这个模式，把测试覆盖率从30%提到了85%。

4.3 配置驱动

所有参数都从配置文件读取，不要硬编码。包括：

报价参数（价差、深度、刷新频率）
风控参数（最大订单量、净头寸上限）
连接参数（交易所IP、端口、账户）

我习惯用YAML格式，可读性好，也容易解析：

# config.yaml
pricing:
  spread_bps: 2.5
  max_depth: 5
  refresh_interval_ms: 100

risk:
  max_order_value: 100000
  max_net_position: 500
  self_trade_prevention: true

exchange:
  name: "binance"
  ws_url: "wss://stream.binance.com:9443"
  api_key: "${API_KEY}"  # 环境变量注入

个人经验：配置文件的变更要记录版本。我曾经因为改了参数没记录，回测时怎么都对不上实盘数据。后来加了配置版本号，每次变更自动打tag，再也没出过这种问题。

五、架构总览

说了这么多，咱们用一张图把整个架构串起来：

从图上你能看到：行情数据从左到右流动，经过定价、风控，最终到达订单管理。而事件总线像一条「高速公路」，让各个模块之间可以异步通信。配置中心和日志监控作为基础设施，贯穿整个系统。

六、总结

报价引擎架构的核心，说白了就是拆分、解耦、异步。把一个大系统拆成独立模块，模块之间通过事件驱动通信，每个模块只做一件事，并且做到极致。

我在做第一个报价引擎时，把所有逻辑写在一个文件里，3000行代码，改一个bug要花三天。后来重构成了模块化架构，同样的功能，代码量少了40%，开发效率翻了一倍。嗯，这就是架构的力量。

📚 课程目录

报价引擎架构：核心组件与低延迟设计

一、报价引擎的核心组件

二、低延迟架构设计

2.1 数据路径优化

2.2 线程模型

三、事件驱动模型

四、模块化设计原则

4.1 接口隔离

4.2 依赖注入

4.3 配置驱动

五、架构总览

六、总结