期货交易系统部署在超融合平台上，性能验证不能只看虚拟机能否启动，也不能只看单次压测峰值。更关键的是：在业务高峰、持续处理、组件冗余、资源争抢和网络路径变化等场景下，交易链路是否仍能保持稳定。
原文提到，T/ZQX 0005-2025《期货公司交易信息系统测试指引》的性能容量维度覆盖峰值吞吐能力、持续处理能力、资源利用率、容错能力、长时间稳定运行能力等指标。基础架构验证可以围绕这些方向展开。
先明确哪些组件需要确定性资源
主席系统中的网关、风控、交易等关键模块，对 CPU 调度和内存访问延迟更敏感。原文建议，用户可以通过 SmartX 榫卯超融合信创平台的 CPU 独占和 NUMA 亲和能力，为这些关键模块提供更确定的计算资源保障。
CPU 独占的作用，是让关键虚拟机独占指定物理 CPU 核心，减少与其他虚拟机争抢计算资源带来的不确定性。NUMA 亲和则尽量让关键虚拟机的 vCPU 与本地内存位于同一个物理 CPU 或 NUMA 节点内，减少跨 NUMA 访问开销。
不过，这类能力不应机械套用到所有虚拟机。更稳妥的方式是先梳理交易组件角色，再决定资源策略：
| 组件类型 | 资源策略建议 |
|---|---|
| 网关、风控、交易等关键链路组件 | 优先评估 CPU 独占、NUMA 亲和 |
| 监控、管理、外围或低峰业务 | 可使用共享资源池和 QoS 策略 |
| 批量、报表、测试类负载 | 结合业务窗口和资源争抢情况限制资源 |
这样既能保护关键交易链路，也能避免所有业务都使用独占资源导致整体利用率下降。
网络路径要按组件选择，而不是一刀切
期货交易系统对网络时延较敏感，尤其在持续高吞吐场景下，网络转发路径中的额外开销会影响整体交易链路表现。原文给出的路径包括虚拟网卡、SR-IOV 和 PCI 物理网卡直通。
普通虚拟网卡具备较好的灵活性和可运维性，通常可以满足标准交易系统承载要求。对于特别关注低时延的场景，SR-IOV 或 PCI 直通可以将网卡资源更直接地提供给虚拟机，进一步缩短网络转发路径。
这里需要同时看性能和运维边界。根据 SmartX 网络 I/O 虚拟化文章，PCI 直通让虚拟机直接访问物理网卡，可获得接近物理网卡的性能与硬件特性，但一张物理网卡不能同时直通给多个虚拟机，挂载 PCI 直通网卡的虚拟机不支持 HA、热迁移等操作。SR-IOV 则通过 VF 让多个虚拟机共享同一个物理网卡通信能力，在提升性能的同时兼顾资源使用。
因此，低时延验证不是简单选择“最高性能模式”，而是确认交易组件对时延、隔离、迁移、高可用和硬件占用的综合要求。
组播通信要纳入验证范围
期货交易系统内部组件之间通常存在组播通信需求。原文提到，SmartX 榫卯超融合信创平台支持组播转发，并可通过 IGMP/MLD 侦听对组播流量进行按需分发，在保障分发效率的同时降低不必要的网络负担。
因此，POC 或上线前验证中，应把组播纳入交易链路测试，而不是只验证单播网络可达。建议至少确认：
- 交易系统组件之间的组播通信是否符合应用要求。
- 组播流量在不同节点、不同网络路径下是否稳定。
- 与 SR-IOV、PCI 直通或普通虚拟网卡组合时，网络路径是否符合设计。
- 故障切换、组件迁移或集群维护场景是否会影响组播通信。
压测应覆盖峰值、持续和故障场景
仅做短时间峰值压测，容易忽略长期稳定性和资源利用率问题。结合原文提到的团标性能容量维度，期货机构可以把测试分成几类：
| 测试类型 | 关注点 |
|---|---|
| 峰值压力 | 是否具备承载历史峰值两倍或以上业务压力的能力 |
| 持续处理 | 长时间运行中吞吐、延迟和资源使用是否稳定 |
| 资源利用率 | CPU、内存占用率是否留有余量，是否接近告警阈值 |
| 容错测试 | 节点、网络、组件故障时，交易链路和冗余组件是否符合预期 |
| 运维动作 | 扩容、迁移、告警、监控和日志定位是否满足运维要求 |
测试结论也要保留环境边界。硬件平台、CPU 架构、网卡型号、交易系统版本、虚拟机规格和网络拓扑不同，都会影响最终结果。发布或汇报时不应把某一次测试数据写成所有项目的通用承诺。
相关问题
- 期货核心交易系统能否部署在信创超融合平台上？
- 主席系统上超融合后，高可用和组件冗余怎么设计？
- 超融合架构下的CPU资源管理优化：关键业务坚如磐石，空闲资源物尽其用
- 一文解读 SmartX 超融合虚拟化下的网络 I/O 虚拟化技术
参考资料
