3. 评分接口协议设计：RESTful vs gRPC vs 自定义TCP协议，序列化选型

在量化因子评分系统中，接口协议与序列化方式直接决定了端到端的延迟、吞吐量以及系统复杂度。本章从低延迟实战角度出发，对比三种主流通信协议与三种高性能序列化方案，并给出量化场景下的选型建议。

3.1 协议选型对比：RESTful vs gRPC vs 自定义TCP

三种协议在延迟、吞吐、开发效率与运维成本上差异显著。下表从量化因子评分场景的关键维度进行对比：

3.2 序列化选型：Protobuf vs FlatBuffers vs Cap'n Proto

序列化是接口延迟的核心瓶颈之一。三种方案均支持二进制编码，但在内存布局、零拷贝能力与访问速度上存在本质区别。

3.3 自定义TCP + FlatBuffers 实战架构

以下 SVG 图展示了一个典型的低延迟评分接口架构，采用自定义 TCP 协议承载 FlatBuffers 序列化的因子数据：

3.4 自定义TCP协议头部设计示例

一个最小化的自定义 TCP 协议头部通常包含以下字段，用于支持粘包处理与快速路由：

// 固定 16 字节头部
struct ScoreProtocolHeader {
    uint32_t magic;          // 魔数: 0xSC0E (用于校验)
    uint32_t body_length;    // 载荷长度 (FlatBuffers 字节数)
    uint16_t api_version;    // API 版本号
    uint16_t message_type;   // 消息类型: 0=请求, 1=响应, 2=心跳
    uint32_t sequence_id;    // 序列号 (用于请求-响应匹配)
    // 载荷紧随头部之后
};

3.5 选型决策树

根据量化系统的不同层级，推荐以下选型路径：

• 核心评分链路 (延迟 < 20μs)： 自定义 TCP + FlatBuffers 或 Cap'n Proto。推荐 FlatBuffers 因为其 C++ 生态更成熟，且支持 mmap 持久化。
• 中频数据订阅 (延迟 100μs~1ms)： gRPC + Protobuf。利用 HTTP/2 的多路复用减少连接数，Protobuf 保证跨语言兼容性。
• 管理面/配置查询 (延迟 > 1ms)： RESTful + JSON。开发效率优先，延迟不敏感。
• 进程间通信 (同一主机)： 共享内存 + Cap'n Proto。利用 Cap'n Proto 的 mmap 能力实现真正的零拷贝 IPC。

3.6 本章小结

评分接口的协议与序列化选型需要根据延迟预算分层决策：

• RESTful 适合管理面，gRPC 适合中频服务间调用，自定义 TCP 是核心链路的唯一选择。
• Protobuf 是通用二进制格式，但反序列化开销在高频场景下不可忽视。
• FlatBuffers 和 Cap'n Proto 通过零拷贝和 O(1) 访问，将序列化延迟降低到亚微秒级。
• 自定义 TCP 头部设计应保持固定长度、包含魔数与序列号，以支持流水线与快速校验。