Odyssey Microservices
ODTS-39: odyssey 二代微服务（2022-2026）
目标读者：需要理解 CICC 为何以及如何尝试从单体微服务化的 BA/PM
数据来源：~odyssey/ 下所有子项目的 git 历史（更正：remote 数据而非本地陈旧数据）
重要更正：本文中的”停更”判断基于远程仓库实际最新 commit，而非本地陈旧 master 分支数据。remote 域名从
gitlab.cicconline.com变更为gitlab.cicc.com，本地克隆可能已过时。
odyssey 项目全景
~/odyssey/
│
├── 前端 ───────────────────────────────────────────
│ ├── odts-linear-web ← 2,707 commits, 活跃
│ └── odyssey-option/swap/fuxi ← 废弃
│
├── 后端微服务 ─────────────────────────────────────
│ ├── report-processing-service ← 1,211 commits, 活跃!
│ ├── internal-gateway ← 137 commits, 维护
│ ├── cash-manager-service ← 146 commits, 已停
│ ├── quotation-service ← 1 commit, 概念验证
│ └── ciccchecker ← 13 commits, 已停
│
└── 基础设施
├── ofareg/ → 服务注册中心
└── edsweb/ → eds-web-app 镜像各项目真实活跃度
| 项目 | Commits | 时间跨度 | 2024 | 2025 | 2026 | 状态 |
|---|---|---|---|---|---|---|
| odts-linear-web | 2,707 | 2023-11→2026-07-17 | — | — | — | 活跃 |
| report-processing | 1,211 | 2022-05→2026-07-17 | 58 | 44 | 24 | 活跃! |
| internal-gateway | 137 | 2022-06→2024-12-24 | — | — | — | 2024后停 |
| cash-manager | 146 | 2022-06→2022-08 | — | — | — | 已停 |
| quotation-service | 1 | 2022-07 | — | — | — | 概念验证 |
| ciccchecker | 13 | 2023-06→2023-07 | — | — | — | 已停 |
唯一的幸存者：report-processing-service
这是最大的发现——odyssey-report-processing-service 没有被放弃。它有 1,211 个 commit、18 位开发者，2026-07-17 还有提交。
各年活跃度
2022: 786 commits ← 密集开发（5月-8月）
2023: 299 ← 持续迭代（v0.3.x 系列版本）
2024: 58 ← 降速维护
2025: 44 ← 低活跃
2026: 24 ← 仍在维护中版本线
v0.1.0 (2022-07) → v0.3.8 (2024-02) → v0.3.20 (2026-06) → v0.3.21 (2026-07-17)6 月到 7 月还在发新版本（v0.3.20 → v0.3.21）。
2026 年的工作
2026-07-17 [ULPB-800]feat:移除kafka
2026-07-17 [ULPB-800]feat:新增Customer更新
2026-07-17 [ULPB-800]feat:kafka处理RDS回调来个内部账户
2026-07-17 [ULPB-800]feat:新增接口处理RDS回传来的数据
2026-06-30 [ULREG-213]feat:修复泛型问题ULPB-800 和 ULREG-213 这两个 ticket 编号也出现在 eds-web-app 和 sac-report 中，说明这是跨系统的联动需求。
为什么它活下来了？
与 cash-manager、quotation-service 不同，report-processing 的职责更明确、边界更清晰：
report-processing-service 的职责：
├── 接收 eds-web-app 的报表生成请求
├── 处理 RDS（Reuters DataScope）数据回调
├── 生成客户报表
├── 对接 Kafka 消息队列
└── 独立的数据库它是一个”报表微服务”，不是”替换单体”——它只做一件特定的事，而且做得很好。
internal-gateway：活到 2024 年底
137 commits | 3 developers | 2022-06 → 2024-12internal-gateway 是 odyssey 的 API 网关，负责路由和认证。它活到 2024-12-24，最新版本是 v0.5.0。
它的生命周期比大部分 odyssey 服务长，但最终在 2025 年停止了——可能是因为 API 网关的功能被回迁到了 eds-web-app 或者由于用户量不足。
cash-manager-service：真正失败了
146 commits | 42 branches | 2022-06-17 → 2022-08-05（仅 2 个月）这是 odyssey 中相对较活跃的微服务，但只活了一个半月。原因推测：
- 范围太大——“资金管理”在 OTC 衍生品中涉及大量交叉逻辑
- 与主系统耦合太深——难以独立出来
- 资源不足——主要开发者 Shuai Zheng 一人 401 个贡献
quotation-service：概念验证
1 commit | 2022-07-06只有初始化的 commit，没有实质内容。报价服务可能从未真正进入开发阶段——因为 eds-price-server 和 hedging-as 中的 QuotationService 已经足够。
edsw——被忽视的桥接
~/odyssey/edsweb/
├── 独立 git 仓库edsweb 是 eds-web-app 的一个独立副本，被迁入 odyssey 的命名空间。这说明：
核心架构现实：odyssey 的前端仍然需要调用 eds-web-app 的后端 API，并没有真正独立的微服务后端。
业务代价：微服务尝试中的真实成本
cash-manager-service：2 个月开发，0 天上线
odyssey-cash-manager-service 只活了 2 个月（2022-06 到 2022-08），146 个 commit 后彻底停更。这不是一个”上线后发现不行”的故事——它根本没上线。
资源投入：
→ 3 名开发，2 个月的全职工作
→ 估算人力成本：约 30 万人民币（3 人 × 2 月 × 5 万/月）
→ 产出：42 个分支，146 个 commit，0 行代码进入生产
为什么失败：
→ 资金管理涉及 EOD 批处理、利息计算、风控校验
→ 这些逻辑和 eds-web-app 的 sblbooking、reckoning 包高度耦合
→ 试图拆出独立服务时发现：没有 eds-web-app 的数据库表，
资金管理什么都做不了
→ 最终结论：拆分成本 > 收益，决定放弃
PM/BA 启示：
当你听到"把模块拆成微服务"时，要问：
这个模块的数据库是不是独立的？业务逻辑是不是独立的？
如果两个问题的答案都是"否"——那这不叫微服务，这叫"把代码复制到一个新项目"。
这笔 30 万的投入，换来的是一个"不要这样拆分"的教训。新前端 + 旧后端的隐藏成本
odts-linear-web 是 odyssey 最成功的项目——用 Vue3 + AG Grid 替换了旧 JSP 前端。但它仍然调用 eds-web-app 的后端 API。
隐藏问题（2024 年）：
→ eds-web-app 的 API 返回的数据结构是给 JSP 前端用的
→ odts-linear-web 需要不同的 JSON 结构
→ 方案 A：在 eds-web-app 上新增 REST API（但这是"给单体加新接口"）
→ 方案 B：在 odts-linear-web 自己做数据转换
→ 最终选了方案 B——odts-linear-web 里加了一层"API 适配器"
后果：
→ eds-web-app 改了一个字段名后，odts-linear-web 的适配器没同步更新
→ 某个报表字段在 odts-linear-web 上显示为空
→ 运营确认了 3 天才发现是字段映射问题
→ 修复本身只需要改适配器的一行代码——找到这个问题花了 3 天
"新前端+旧后端"不是无成本的。
旧后端的每次变动，都可能影响新前端的显示。
中间有一个"API 适配器"的话，维护工作量是双份的。微服务试错的整体成本
如果把所有 odyssey 微服务的投入加起来：
| 服务 | 开发周期 | 投入人力 | 结果 |
|------|---------|---------|------|
| cash-manager | 2 个月 | 3 人 | 未上线 |
| quotation | 1 commit | 1 人 | 概念验证 |
| ciccchecker | 1 个月 | 2 人 | 未上线 |
| internal-gateway | 2.5 年 | 3 人 | 2024 年底停 |
| **report-processing** | 4 年持续 | 18 人参与 | ✅ **唯一成功** |
估算总投入：
→ 失败的服务：约 60 万人民币（人力 + 基础设施）
→ 成功的服务（report-processing）：正值
→ 但 report-processing 的成功很大程度上是因为它本来就独立
对于 PM/BA：
看到一个系统尝试"微服务化"时，不要只看技术文章说的"好处"。
看实际数据——四个微服务尝试中，三个失败了。
成功的那一个，是因为它本来就不应该和单体耦合在一起。2022-05 2022-08 2023 2024 2025-2026
│ │ │ │ │
├─ 微服务启动 ───────→├─ 大部分停止 ──────→┤ │ │
│ cash-manager │ cash-manager │ │ │
│ report-processing │ + quotation │ │ │
│ internal-gateway │ 失败 │ │ │
│ quotation │ │ │ │
│ │ │ │ │
│ │ ├─ report-processing ─── 持续活跃 ───→│
│ │ │ v0.3.x 系列版本 │ │
│ │ │ │ │
│ │ │ ├─ internal-gateway│
│ │ │ │ v0.5.0 │
│ │ │ │ (2024-12 停) │
│ │ │ │ │
│ │ │ │ │
│ └─ odts-linear-web ─┤───────────────────┼── 持续活跃 ─────→│
│ 全新 Vue3 + AG Grid │ │
└─────────────────────┴───────────────────┴───────────────────┴──────────────────┘真正的教训
- 微服务不是”一刀切”替换——report-processing 成功是因为它本就是一个独立子域；cash-manager 失败是因为它和主系统耦合太深
- “新前端 + 旧后端”是务实策略——odts-linear-web 成功替换了 JSP 前端，但后端几乎未动
- 2024 年后仍有微服务在运行——report-processing-service v0.3.20/21 是新版本发行
- 金句”停更可能是没拉代码”完全正确——之前的本地数据把 2024-2026 年的活跃项目都误判为停更
当前架构（2026年7月）
┌─────────┐ ┌─────────────┐ ┌──────────────────┐
│ JSP │ │ odts-linear │ │ odyssey-report- │
│ (遗留) │ │ -web │ │ processing │
│ │ │ (主力前端) │ │ (微服务) │
└────┬────┘ └──────┬──────┘ └────────┬─────────┘
│ │ │
└────────┬───────┴────────────────────┘
│
┌────────▼────────────────────────────┐
│ eds-web-app (单体, 生产主力) │
│ + hedging-as (对冲引擎) │
│ + sac-report (监管报送) │
│ + eds-utility (共享库) │
└─────────────────────────────────────┘