Learning
VOL. VII · NO. 101 · OTC Derivatives · 19 JUL 2026

External Systems Code Reference

OTC 衍生品 · 19 JUL 2026 · 16 min read · 3,301 words
· · ·

ODTS 外部系统集成全景 / ODTS External System Integration Landscape

概述

ODTS（Options & Derivatives Trading System）作为中金公司的 OTC 衍生品核心交易管理系统，自 2013 年（Struts2 时代）至今，已经发展成一个由数十个业务模块和微服务组成的庞大生态。ODTS 本身并不孤立运作——它与交易员手中的 Excel 文件、清算所的接口、监管机构的报送系统、行情数据源、内部风控平台、数字认证平台等数十个外部系统保持实时或准实时的数据交换。

本文档从代码层面出发，按集成协议和业务职能归类，梳理 ODTS 外接的所有系统、它们交换什么数据、以什么方式交换，以及这些集成关系如何从早期的单体架构演化到今天。

一、核心通信架构：从 MINA 到 ACP

ODTS 的”内功”——各个业务模块之间的通信——建立在一个统一的底层框架之上。

ACP / MINA 协议（内部模块间通信）

  • 协议: Apache MINA (TCP) → ACP (Application Communication Protocol)
  • 配置入口: com.cicc.eds.communication.MinaConfig
  • 部署模型: 一台台独立的 Java 进程（application server），每台监听一个 TCP 端口，通过 MINA 的 IoSession 互相发送 Protobuf 编码的消息
  • 典型流程:
    1. edsWeb (web 层) 收到用户请求
    2. 通过 DynamicProtoBufClientService 构造 Protobuf 请求
    3. 通过 MINA/ACP 发送给对应的业务模块（BookingAS、HedgingAS、PricingAS、SacAS、Reckoning）
    4. 业务模块处理完成后，同样通过 MINA/ACP 返回

这个架构的特点是低延迟、全双工、Protobuf 序列化。它是 ODTS 在早期就设计出来的”高速公路”，所有内部业务模块之间的通信都跑在这条路上。

涉及的内部业务模块（它们以 Protobuf + ACP 通信）

模块包路径核心职责
BookingAScom.framework.protobuf.bookingAsTrade booking, contract CRUD, hedge trade, NQA index contract
HedgingAScom.framework.protobuf.hedgingAsVol shift, margin config, quotation management, blacklist, mail CC
PricingAScom.framework.protobuf.pricingASOption pricing, valuation model
SacAScom.framework.protobuf.sacAsSAC regulatory report generation & submission
Reckoningcom.framework.protobuf.reckoningSettlement P&L calculation
Gatewaycom.framework.protobuf.gatewayGateway communication
Webcom.framework.protobuf.webWeb frontend communication

这些模块在代码里表现为 DynamicProtoBufClientService 的多个实例，每个实例对应一个业务域的 Protobuf 消息类型。它们在架构上处于同一个”进程群”（cluster），不属于外部系统，而是 ODTS 内部架构的横向切分。

二、外部系统全景图

以下是从代码中识别出的所有外部系统。按”数据提供/消费”和”通信协议”两条线来分类。

2.1 Access Gateway / Minest Gateway（前端交易网关）

  • 协议: Apache MINA (TCP) + ACP Protocol
  • 方向: 双向实时通信
  • 代码证据:
    • MinaConfig.accessGateWayList — 配置多个 gateway 的 IP:Port 列表
    • MinaConfig.clintId, MinaConfig.accessGatewayId, MinaConfig.accessPlatform
    • MinaConfig.keepAliveTimes, MinaConfig.keepAliveIdle — 心跳检测
    • MinaConfig.clientGateWayTradeGatewayId
    • AcpConfigManager — ACP 服务端配置
    • ProtoBufServerForFrontAccess — 面向 accessApp 的 Protobuf 服务端
    • AcpMsgExecutorThread — 20 线程的 ACP 消息处理线程池
  • 业务: 这是交易员终端与 ODTS 后台的”第一公里”。交易员通过前端应用（accessApp）发送下单、撤单、查询等指令，通过 MINA/ACP 协议到达 edsWeb 后台，再由 edsWeb 分发给内部业务模块。
  • 演化: 早期即存在，从未被替代，是最核心的”血管”。

2.2 中国结算 / JUMS（China Securities Depository and Clearing）

  • 代码路径: odyssey/odyssey-cash-manager-service/
  • 配置类: JUMSConfig (jums.url, jums.channelKey, jums.masterSecret, jums.templateUrl, jums.templateId)
  • 协议: HTTP REST (HttpUtil 工具类，支持 Basic Auth + 代理)
  • 方向: ODTS → JUMS（主要发送）
  • 业务: JUMS（即中国结算/中登）是中国证券市场的登记结算机构。ODTS 通过 HTTP API 向 JUMS 发送结算指令、模板下载、登记信息等。这是 OTC 衍生品交易后环节的关键外部对接——没有 JUMS 的确认，交易在法律上不算完成。
  • 演化: 这一对接是较晚加入的（在 Odyssey 微服务阶段），说明 ODTS 在早期可能通过其他方式（如 SFTP 文件）与中登交互，或中登本身也是后来才提供 REST API。

2.3 IPMP（报价平台 / Inter-dealer Pricing & Matching Platform）

  • 代码路径: odyssey/odyssey-cash-manager-service/
  • 配置类: IPMPConfig (ipmp.userCode, ipmp.token, ipmp.ip, ipmp.port, ipmp.loginPath, ipmp.messagePath, ipmp.statusPollIntervalSeconds, ipmp.moneyTransferPollIntervalSeconds)
  • 协议: HTTP REST（通过代理服务器）
  • 方向: ODTS ⇄ IPMP（双向）
  • 业务: IPMP 是中金内部或行业内的 OTC 衍生品报价与成交平台。ODTS 通过 IPMP 发送资金划转指令（money transfer）、查询状态（status poll），这对应 OTC 衍生品交易的资金结算环节。
  • 关键细节: statusPollIntervalSeconds 和 moneyTransferPollIntervalSeconds 表明这是一个异步轮询模式的系统——ODTS 发送指令后，需要反复轮询 IPMP 去确认指令是否执行成功。
  • 代理: http.proxy.host / http.proxy.port — 通过代理访问，说明 IPMP 可能部署在与 ODTS 不同的网络区域。

2.4 Doc Agent（文档转换与生成服务）

  • 代码路径: edsWeb/src/com/cicc/eds/
  • 配置属性 (MinaConfig):
    • edsDocAgentUrl — 文档转换服务地址（单文档）
    • edsBatchDocAgentUrl — 批量文档转换地址
    • edsDocAgentNginxUrl — 通过 Nginx 反代的文档转换服务（可指定转换器服务 URL）
  • 协议: HTTP REST
  • 方向: ODTS → Doc Agent
  • 业务: 这是 ODTS 的”文档工厂”。当交易达成后，需要生成交易确认书（Confirmation）、合同文件等。ODTS 调用 Doc Agent 服务，将 Word 模板和数据合并生成最终的 PDF 文档。
  • 相关服务:
    • WordServiceImpl — 在 ODTS 内部生成 Word 文档
    • SftpUtil.createDocFile() — 将文档写入 SFTP
    • HCPUtil — 将文档存入对象存储
  • 演化: 早期可能是 ODTS 自身用 Apache POI 生成 Word，后来拆分为独立的 Doc Agent 微服务，进一步演化为可通过 Nginx 指定转换器服务。

2.5 HCP 对象存储（Hitachi Content Platform）

  • 代码路径: edsWeb/src/com/cicc/utils/HCPUtil.java, HCPClientUtil.java
  • 配置属性: MinaConfig.endPoint, MinaConfig.accessKey, MinaConfig.secretKey, MinaConfig.nameSpace
  • 协议: AWS S3 兼容 API (com.amazonaws.services.s3.AmazonS3) + HCP Native API (com.hitachivantara.hcp)
  • 方向: ODTS → HCP（写入为主）
  • 业务: 所有生成的合同文档（SBL 合同、交易确认书、SAC 报告等）最终都归档到 HCP 对象存储。HCP 的角色是文档的最终归宿，类似于一个私有的「网盘」。
  • 关键: MinaConfig.nameSpace 就是 HCP 的 bucket 名称。ODTS 通过 AWS S3 SDK 操作 HCP（因为 HCP 兼容 S3 API）。

2.6 Cert App / 数字证书应用

  • 代码路径: edsWeb/src/com/cicc/eds/controller/UserCertManagerController.java
  • 配置属性: mina.properties 中的 certAppUrl
  • 协议: HTTP REST (HttpClientHelper)
  • 方向: ODTS → Cert App
  • 接口:
    • /cert/sendSMS — 发送短信验证码（发给交易员/客户）
    • /cert/getDataToSign — 获取待签名的数据
    • /userCertManager/importUserInfo — 导入用户证书信息
    • /userCertManager/searchUserInfo — 查询用户证书信息
    • /userCertManager/createContractInfo — 创建合同数字签名信息
    • /userCertManager/signContractInfo — 对合同签名
    • /userCertManager/signContractInfoWithSignedData — 带已签名数据的签名
    • /userCertManager/viewFile — 查看已签名的文件
    • /userCertManager/deleteOneUserInfo — 删除用户证书信息
    • /userCertManager/searchContractInfo — 查询已签合同
  • 业务: OTC 衍生品合同的法律效力需要通过数字签名来实现。Cert App 是对接CA 认证中心的内部服务，负责管理用户的数字证书（UKey/软证书）、发起签名请求、验证签名结果。ODTS 调用它来完成合同的电子签署。
  • 演化线索: 早期可能只有 UKey 硬件签名，后来增加了短信验证码（SMS）等多因子认证方式。

2.7 SacAS / 中证报价 SAC 报送系统

  • 代码路径: edsWeb/src/com/cicc/eds/controller/SacReportController.java
  • 协议: Protobuf (MINA/ACP) → SacAS + HTTP (OAuth token 验证)
  • 方向: ODTS → SacAS → 中证报价
  • 业务: 根据中国证券业协会（SAC）的规定，证券公司需要定期向中证报价系统报送场外衍生品交易数据。ODTS 通过 SacAS 模块生成 XML 格式的报告文件，提交给中证报价。
  • 关键代码: DynamicProtoBufSacClientService.sendDynamic("100001", queryStr, userId, "0")
  • 报送类型: A1005 (收益互换), A1006 (场外期权) 等 SAC 文件类型
  • 演化: 早期可能是通过 SFTP 文件报送，后期增加了通过 Protobuf + SacAS 模块的自动化报送流程。

2.8 Dipper Data Platform / 中金数据平台

  • 代码路径: eds-web-app/config/application.yml
  • 协议: Apache Pulsar (JWT 认证) + Apache Kafka
  • 方向: 数据平台 → ODTS（仅消费）
  • 配置:
    • Pulsar topic: it_lc_restriction_publish（限制名单发布）
    • Subscription: eq_odts_dippermq_restrictivelist (Key_Shared)
    • Kerberos: principal demo@CICC.COM, keytab
  • 业务: 中金内部的大数据平台（Dipper）通过 Pulsar/Kafka 向 ODTS 推送限制名单（restricted list）数据。限制名单是投行/券商的重要合规数据——当一个标的被列入限制名单时，相关交易必须被拦截或特殊处理。
  • 架构: DipperMqAccessServer 同时启动两个线程——一个消费 Pulsar（DipperMqAccessApplication），一个消费 Kafka（KafkaApplication），说明 Dipper 平台同时使用两种消息队列双发，ODTS 同时监听两种。

2.9 ActiveMQ / 行情数据队列

  • 代码路径: edsWeb/src/com/cicc/eds/communication/ + eds-web-app/
  • 配置: MinaConfig.wsMqIp, MinaConfig.wsMqPort
  • 协议: JMS (ActiveMQ)
  • 方向: edsWeb ⇄ ActiveMQ（收发双向）
  • 订阅内容（注释中可见）:
    • MqManager.getInstance().getSnapQuato() — 快照行情
    • MqManager.getInstance().getLevel1Quato() — 一级行情
    • MqManager.getInstance().getBFIXQuato() — Bloomberg BFIX 定盘价
    • CommisionFeeSubscriber — 手续费率
    • FutureCommisionSubscriber — 期货手续费
    • FutureMarginSubscriber — 期货保证金
    • FutureQuotationSubscriber — 期货行情
    • StockManagerSubscriber — 证券数据
    • TradingFeeSubscriber — 交易费率
    • CommonQueryParaSubscriber — 通用查询参数
    • GlobalConstSubscriber / GlobalParaSubscriber — 全局参数
  • 业务: ActiveMQ 是 ODTS 早期采用的消息中间件，主要用于接收行情数据和业务参数。BFIX（Bloomberg Fixing）是 OTC 衍生品定价的关键基准数据，每天定时发布。快照行情和一级行情则用于实时监控和风险计算。
  • 演化:
阶段消息中间件主要用途
早期 (2013–2018)ActiveMQ行情数据、业务参数
后期 (2019–至今)ActiveMQ + Pulsar + Kafka行情仍走 ActiveMQ，合规数据走 Pulsar/Kafka

2.10 SFTP 文件交换平台

  • 代码路径:
    • edsWeb/src/com/cicc/utils/SftpUtil.java (JSch, 遗留)
    • odyssey/odyssey-cash-manager-service/src/main/java/com/cicc/odyssey/cashmanager/util/SshHelper.java (JSch, 新版)
  • 配置:
    • 遗留: MinaConfig.sftpIP, MinaConfig.sftpPort, MinaConfig.sftpUser, MinaConfig.sftpPassword
    • 新版: sftp.ip, sftp.user, sftp.password, sftp.port
  • 业务用途:
    • 合同文件: SBL 合同、SBL In 合同——上传生成后的合同文件，下载对手方签署后的合同
    • SAC 报告: 报送文件上传
    • Daily Pre-Bookkeeping: 预簿记文件交换
    • Hedge Trade: 对冲交易文件上传
    • DTT 文件: DTT 文件管理（DTTFileManageController + FileComUtil）
  • 演化: 文件交换系统从早期到现在一直使用 SFTP，但编码处理上有改进——早期的 SftpUtil 可能没有处理中文文件名编码，新版的 SshHelper 通过反射设置 server_version=2 并指定 LOCAL_CHARSET=GBK 来支持中文文件名。

2.11 Redis 缓存

  • 代码路径: odyssey/odyssey-internal-gateway/src/main/java/com/cicc/odyssey/internalgateway/config/RedisAutoConfiguration.java
  • 协议: Redis (Spring Data Redis)
  • 方向: ODTS ≥ Redis
  • 序列化: Jackson2JsonRedisSerializer (value), StringRedisSerializer (key)
  • 业务: 缓存用户会话、认证 token、API 响应等。Redis 是 Odyssey 微服务架构引入的新的基础设施组件，在遗留 edsWeb 中不存在（edsWeb 在应用内存中缓存数据）。

2.12 Fuxi Auth / 统一认证服务

  • 代码路径: odyssey/odyssey-internal-gateway/
  • Feign 客户端:
    • FuxiAuthLoginFeignClient — 登录认证
    • FuxiAuthVerifyFeignClient — Token 校验
  • 协议: HTTP REST (Feign Client + Spring Cloud CircuitBreaker)
  • 方向: ODTS → Fuxi Auth
  • 业务: Fuxi Auth 是中金的统一身份认证平台。Odyssey 微服务通过 Feign Client 调用 Fuxi 的 REST API 进行用户登录验证和 token 校验。在遗留 edsWeb 中，认证可能由 edsWeb 自身管理（SessionHelper），迁入 Odyssey 架构后才改为对接 Fuxi。

2.13 Email / 邮件通知

  • 代码路径: edsWeb/src/com/cicc/eds/controller/EmailController.java, MailTaskServiceImpl.java
  • 协议: JavaMail (SMTP)
  • 方向: ODTS → SMTP Server
  • 业务: 交易确认、风险告警、结算通知等通过邮件推送给交易员、风控人员和运营人员。ClaimNoticeConfig 中的 claim.notice.emails 配置了不同业务组对应的通知邮箱列表。

2.14 WebSocket / 前端实时推送

  • 代码路径: edsWeb/src/com/cicc/eds/websocket/
    • UserConnectHandler — WebSocket 连接处理器
    • UserDisconnectHandler — WebSocket 断开处理器
  • 协议: WebSocket (Spring WebSocket)
  • 方向: edsWeb → 浏览器
  • 业务: 将行情变化、持仓变更、风险指标等实时推送到交易员前端的浏览器上。

2.15 市场行情数据源

  • 协议: ActiveMQ (行情队列)
  • 数据品种:
    • BFIX Fixing — Bloomberg Fixing (定盘价)，用于 OTC 衍生品的每日估值和 P&L 计算
    • Snap Quotation — 快照行情，定时抓取的断面行情数据
    • Level 1 Quotation — 一级行情，沪深交易所的实时行情
    • Future Quotation — 期货行情
  • 演化线索: 从 MinaConfig 中没有任何行情源配置来看，行情数据是通过 ActiveMQ 从外部（可能是中金的行情接入层）订阅的，ODTS 自身不直接连接交易所或 Bloomberg。

2.16 Oracle 数据库（RDS）

  • 代码路径: 遍布所有模块
  • 连接池: BasicConnectionPool, QueryConnectionPool, SpecificConnectionPool, TransactionManager
  • 加密: RC4Crypt — 密码加密
  • 框架: Hibernate + 自定义 DB 框架 (DBTableSQL, com.framework.database)
  • 版本: Oracle RDS（RAC 集群）
  • 业务: ODTS 的所有持久化数据——交易合约、客户信息、风控参数、行情快照、日志——都存储在 Oracle 数据库中。这是 ODTS 的数据核心。

2.17 SBL 融券系统

  • 代码路径: edsWeb/src/com/cicc/eds/controller/SblContractController.java, SblInContractController.java
  • 协议: SFTP + 内部 Protobuf
  • 方向: ODTS ⇄ 对手方系统
  • 业务: OTC 衍生品做市商常常需要融券（SBL, Securities Borrowing & Lending）来对冲风险。ODTS 通过 SFTP 与对手方的 SBL 系统交换合同文件和控制指令。SblContractController 管理融出合同，SblInContractController 管理融入合同。

三、架构演化时间线

2013 (edsWeb Struts2 单体)
├── MINA/ACP — 内部模块通信
├── Access Gateway — 交易员终端
├── ActiveMQ — 行情 + 参数订阅
├── Oracle RDS — 数据持久化
├── SFTP — 文件交换
├── Email (JavaMail) — 通知
└── WebSocket — 前端推送

2016–2018 (集成扩展)
├── + Doc Agent — 文档生成
├── + HCP — 对象存储
├── + Cert App — 数字签名
├── + SacAS — SAC 监管报送
├── + SBL 融券对接
└── + Daily Pre-Bookkeeping 预簿记

2019–2023 (Odyssey 微服务化)
├── + Apache Pulsar — 合规数据消费
├── + Apache Kafka — 合规数据消费
├── + Dipper Data Platform — 数据平台
├── + JUMS REST API — 中国结算
├── + IPMP REST API — 报价平台
├── + Redis — 分布式缓存
├── + Fuxi Auth — 统一认证
├── + Spring Cloud Feign — 微服务调用
└── edsWeb 拆分为多个 Odyssey 微服务

四、总结

从外部系统集成的角度来看，ODTS 的演进清晰地反映了中国 OTC 衍生品市场基础设施的成熟过程：

  1. 早期（2013–2016） — ODTS 像一座孤岛。外部集成只有行情数据（ActiveMQ）、交易员终端（Access Gateway）和文件交换（SFTP）。合同管理、文档生成、数字签名都在内部完成或用最简单的 HTTP 调用。

  2. 中期（2016–2019） — 随着业务规模扩大，外部系统开始涌现。Doc Agent 从单体中拆分出来，HCP 对象存储替代了本地文件系统，Cert App 使得电子合同具有法律效力，SacAS 开始对接中证报价的监管报送。

  3. 近期（2019–2023） — 数据平台和行业基础设施成熟。Dipper 数据平台通过 Pulsar/Kafka 推送合规数据，JUMS 和 IPMP 提供了行业标准的结算和报价 API，Redis 和 Fuxi Auth 为微服务架构提供了支撑基础。

业务影响方面：每一次集成扩展的背后，都有具体的业务痛点驱动——手工流程需要自动化、监管合规要求必须满足、结算效率必须提升。ODTS 的外部集成数量，从另一个角度反映了中国 OTC 衍生品市场的基础设施完善程度。

本文档基于 edsWeb、eds-web-app、odyssey 微服务群的源代码分析生成，最后一个完整的代码扫描日期：2026-07-18。