系统架构收口：45+ 项目生态与微服务试错
把前面所有支线（产品/风险/监管）放进同一张系统地图——并看清"为什么迁移这么慢"。
前面八节我们分别看了产品、生命周期、风险、监管。这一节收口：它们跑在什么系统上。核心结论对 PM/BA 极有用——理解架构负债，才能合理评估”为什么改个字段要 3 天""为什么微服务拆不动”。
tradedesign 的 1,709 个 Proto 定义通信契约，有两个给出略微不同答案的定价引擎（hedging-as vs eds-web-app），靠基于文件的集成和 shell 脚本粘在一起。多年微服务迁移进展缓慢——只有 report-processing-service 真正活下来。一、万米高空：两个世界
| 维度 | 世界 1：hedging-as | 世界 2：eds-web-app |
|---|---|---|
| 框架 | JFinal + Protobuf + 直接 SQL | Spring Boot + MyBatis + REST |
| 定位 | 原系统（2016–17），定价/风险/保证金一体 | 新系统，拟取代 hedging-as |
| 优点 | 快、完整、经实战 | 标准框架、易招人、可独立部署 |
| 缺点 | 小众框架、原始 SQL、紧耦合、无测试 | 功能不全、迁移 5+ 年未完成 |
二、共享数据库的惨痛教训（架构负债根源）
业务代价：所有服务读写同一个 Oracle schema。一个服务的 bug 可能损坏另一个服务的数据；schema 变更要协调所有服务；无法独立扩展。
系统锚点（IT 侧）
2019 年事故：eds-web-app 把 EDS_CONTRACT.remark 从 VARCHAR2(500) 改到 (1000)（界面显示用）。一周后 hedging-as 的 EOD 批处理随机失败——旧 SQL 用 CHAR 截断 remark 到 500 字节，超长插入即异常 → 当天保证金催缴延迟 4 小时。
根因：不是”改字段的人没通知”，而是”两个应用共享同一张表，一个不知道另一个的 SQL 逻辑”。有独立 DB 和服务边界，这个风险不存在。
三、协议注册中心 tradedesign
业务：37 个子系统之间的全部通信格式，由 1,709 个 .proto 文件（15,014 commits）定义。“接口先行”在 2015 年很领先。
系统锚点
所有 Java 项目编译时依赖 tradedesign JAR。2021 年某次 proto 字段变更：团队 A 发了新 JAR，团队 B（eds-web-app）没同步 → 旧版反序列化失败 → 交易同步中断 2 天。教训：接口契约没有强制的向前/向后兼容检查，就成了隐式依赖链。2022 年后新项目改用 REST+JSON，tradedesign 历史停在 2022 初。
四、odyssey 微服务：四个试三个死
业务：2022 年起尝试把单体拆微服务。真实结果（用 git 活跃度而非本地陈旧数据判断）：
| 服务 | 周期 | 结果 |
|---|---|---|
| report-processing-service | 4 年持续（至 2026-07） | ✅ 唯一成功（独立子域） |
| internal-gateway | 2.5 年 | 2024 年底停 |
| cash-manager-service | 2 个月 | 未上线（耦合太深） |
| quotation-service | 1 commit | 概念验证 |
cash-manager 3 人 2 个月 30 万投入、0 行进生产：资金管理逻辑与 eds-web-app 的 sblbooking/reckoning 包高度耦合，拆出后发现"没有 eds-web-app 的表什么都做不了"。
odts-linear-web 是务实赢家：Vue3 + AG Grid 换掉旧 JSP 前端，但后端几乎没动——"新前端+旧后端"。
五、理想架构（为什么没做）
API Gateway → 交易/定价/保证金 服务（各自独立 DB）
│
事件总线 (Kafka)
│
结算/市场数据/报告 服务收益：每服务独立 DB、事件总线替代文件轮询、单一真相源、实时通知、独立扩展、死信队列。但 35+ 项目重构成本高、业务方不愿资助”无可见功能改进的多年迁移”——所以进展缓慢。report-processing-service 成功恰恰因为它本就是独立子域（报表），不必和单体抢同一张表。
六、测验（Recall 练习）
凭记忆作答，不要回看。每题选项等长，避免暗示。
odyssey 微服务尝试中，唯一真正存活的是？
"两个引擎两个真相"指的是？
2019 年 EOD 中断事故的根因是？
tradedesign 定义了多少个 .proto 通信契约文件？
最务实成功的现代化尝试是？
tradedesign JAR 更新不同步会导致什么问题？
微服务迁移成功的关键判断标准是？
odts-linear-web 的成功在于？
六、错题本与复习
本课错题记录
八、延伸阅读（Primary Source）
- 内部：ODTS-25 系统架构总览 —— 45+ 项目生态、两个世界、四大架构问题母文档。
- 内部：ODTS-39 odyssey 微服务 —— 四个试三个死的真实 git 活跃度复盘。
- 内部：ODTS-09 单体迁移 —— 为什么迁移慢、理想架构为何难落地。
错题追踪 0011 错题本 · Lesson 0009 · 上游 0008 监管报送 · 母文档 ODTS-25 · MISSION: 产品 + IT 双线精通 · 样式 base.css