从实验代码到产品：DPDK 行情接入网关的产品化实践

前三篇讲完了协议栈、WebSocket 和性能优化。这一篇把视角切到产品：
如何把这套技术栈包装成一个金融行情接入网关（app/market_feed.c），
以及它的部署方式、商用评估和演进路线。

一、产品定位：金融行业最典型的低延迟场景

在量化交易链路中，行情数据（股票、期货的实时报价）的到达延迟直接影响策略的成交质量。典型的接入形态：

交易所 / 行情提供商 → [WebSocket 行情流] → 行情接入网关 → 下游交易系统
                                              ↑
                                    本项目占据的位置

网关要做的事：订阅多品种行情 → 以微秒级延迟接收 → 解析 → 转发/统计。用自研 TCP 栈的收益在这里被放大——行情消息高频、小包、长连接，正是内核协议栈开销占比最大的流量形态。

二、产品功能（app/market_feed.c，约 420 行）

架构与基础客户端同构（lcore0 RX/TX + lcore1 协议处理），产品层增加的是延迟测量和统计展示：

flowchart LR
    subgraph S["行情服务端 (demo/market_data_server.py)"]
        S1["AAPL / GOOGL / MSFT / TSLA<br/>每条消息带 timestamp"]
    end
    subgraph G["DPDK 行情网关 (app/market_feed.c)"]
        L0["lcore0: RX burst +<br/>ws_recv_frame"]
        L0 -->|"ring→in"| L1["lcore1: TCP/WS<br/>状态机处理"]
        L1 -->|"rcvbuf + cond"| L0
        subgraph STATS["统计层 (lcore0)"]
            H["延迟直方图<br/>64 桶 × 1μs 分辨率"]
            R["per-symbol<br/>msg/s 速率"]
        end
        L0 --> STATS
        STATS -->|"每 5s"| OUT["终端统计表输出"]
    end
    S1 -->|"WS 行情流 (TCP)"| G

三、延迟直方图：64 桶 × 1μs 分辨率的极简实现

延迟 = 消息携带的服务端 timestamp 到网关收到时刻的差值。测量与统计实现非常轻量（app/market_feed.c）：

#define LAT_BUCKETS      64    /* 直方图桶数 (1us 分辨率) */

typedef struct {
    uint64_t buckets[LAT_BUCKETS];   /* 延迟分布直方图 */
    uint64_t min_us, max_us, sum_us; /* 累计值 */
    uint64_t count;
} symbol_stats_t;

• 每收一条行情，算 now - msg_timestamp，buckets[min(lat, 63)]++；
• 百分位直接在累计分布上找分位点（P50/P95/P99）；
• min/max/avg 用累计值 O(1) 维护；
• 输出时打印 ASCII 表格（见下文），无需外部依赖。

这套实现约 100 行 C，换来了产品的核心卖点：可量化的延迟证据。

四、端到端演示

# 1. 编译产品
make app                          # → build/market_feed

# 2. 启动模拟行情服务端（零依赖 Python，100 msg/s）
python3 demo/market_data_server.py 8080 100

# 3. 启动 DPDK 行情网关
./build/market_feed -l 0-1 -n 2 \
    -d $DPDK_DRV/librte_mempool_ring.so \
    -d $DPDK_DRV/librte_net_ixgbe.so \
    -- -a <SERVER_IP> -p 8080 -l <LOCAL_IP> \
       -s '{"action":"subscribe","symbols":["AAPL","GOOGL"]}' -t 5

每 5 秒输出一次延迟统计表：

┌────────┬──────────┬────────┬────────┬────────┬────────┬──────┐
│ Symbol │  Msgs    │  Rate  │  Min   │  Avg   │  P50   │ P99  │
├────────┼──────────┼────────┼────────┼────────┼────────┼──────┤
│ AAPL   │      498 │     99 │    598 │    821 │    780 │ 1245 │
│ GOOGL  │      497 │     99 │    587 │    815 │    772 │ 1230 │
└────────┴──────────┴────────┴────────┴────────┴────────┴──────┘

延迟口径：服务端 timestamp → 网关 rte_get_timer_cycles 的端到端时间，
包含服务端序列化 + 内核 TCP 发送 + 网络传输 + DPDK 协议栈 + WS 解码全链路。

五、部署清单

生产部署需要三样东西（详见仓库 README / CLAUDE.md）：

1. Hugepages：echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
2. 网卡绑定：dpdk-devbind --bind=vfio-pci <pci_addr>（DPDK 24.11 usertools）
3. PMD 插件：运行参数 -d 指定 mempool/NIC 驱动（Makefile 按共享库链接，PMD 运行时加载）

云上部署：AWS c5n.large+（ENA PMD）或 c5n.metal（SR-IOV），安全组放行行情端口。

六、商用评估：什么能卖，什么不能

就绪度分级

竞品对比

推荐切入路径：金融行情网关（1-2 月 MVP）→ 微服务 RPC（3-4 月）→ 5G 边缘（6 月+）→ CDN 推送（12 月+）。

不适合的场景（要诚实）

七、演进路线图

flowchart LR
    P5["P5 修复多核 RSS<br/>active_head 并发"] --> P6["P6 WS 分片发送<br/>header+payload 分离"]
    P6 --> P7["P7 网卡 checksum offload<br/>省 5% CPU"]
    P7 --> P8["P8 事件驱动替代忙轮询<br/>空闲降功耗"]
    P8 --> P9["P9 TSO/GRO 软件实现<br/>大消息吞吐翻倍"]

    M["商业路线: Prometheus 指标<br/>JSON 配置 → 多核 RSS + TLS<br/>→ HA 双活 + 热升级"] --> P5

其中 P5 已有实验骨架：feature/multi-core 分支实现了 per-worker TCB 表、ring 数组与 RX 哈希分流，当前被主线程与 worker 对 active_head 链表的并发竞争阻塞（表现为 TCP 连接超时）。修好后吞吐可望随核数线性扩展。

八、总结

从 6000 行实验代码到可演示产品，中间只隔了 100 行直方图 + 1 张统计表 + 1 个演示脚本——但这一步把"技术能力"变成了"客户能看懂的东西"。低延迟基础设施类产品的说服力，永远来自一张带 P99 的延迟表。

相关文件：app/market_feed.c（产品实现）、app/README.md（产品文档）、demo/market_data_server.py（模拟行情源）、PRODUCT_ANALYSIS.md（商用场景分析）、PERF_REPORT.md（性能数据）

系列目录：① 用户态 TCP 协议栈 · ② WebSocket 实战 · ③ 性能优化实战 · ④ 产品化实践