four-level-schedule/docs/tasks/04-architecture-evolution.md

架构演进规划

当前架构

schedule-producer → Kafka → schedule-consumer → parse-service → Kafka → schedule-embedding-api → ES
                                    ↑
                             计划用 Flink 替代

---

Flink 引入后的架构

阶段 1：Flink 替代 schedule-consumer（当前）

schedule-producer → Kafka → Flink → parse-service → schedule-embedding-api → ES
                        ↓
                   Async I/O + 重试 + 状态管理

职责划分：

• Flink：消费 Kafka、流程编排、容错、状态管理
• parse-service：文件解析（PDF/Office/图片/音视频）+ AI 模型调用
• schedule-embedding-api：向量化 + ES 索引
• schedule-manager：管理 parse-service 实例池

---

阶段 2：批流一体（未来）

批量数据（对象存储） ─┐
                     ├→ Flink → parse-service → embedding-api → ES
实时流（Kafka）───────┘

特点：

• 同一套代码处理批量和实时
• Savepoint 支持任务暂停/恢复/升级

---

阶段 3：生产环境高可用（未来）

         ┌─────────────┐
         │   Kafka     │ (高可用集群)
         └──────┬──────┘
                │
         ┌──────▼──────┐
         │   Flink     │ (HA 集群，多 JobManager)
         └──────┬──────┘
                │
    ┌───────────┼───────────┐
    │           │           │
┌───▼───┐  ┌──▼───┐   ┌──▼───┐
│parse-1│  │parse-2│   │parse-3│ (负载均衡)
└───┬───┘  └──┬───┘   └──┬───┘
    │           │           │
    └───────────┼───────────┘
                │
         ┌──────▼──────┐
         │embedding-api│ (多实例)
         └──────┬──────┘
                │
         ┌──────▼──────┐
         │     ES      │ (集群)
         └─────────────┘

---

模块职责重新划分

模块	当前职责	Flink 引入后	是否保留
schedule-producer	发送任务到 Kafka	保留（或扩展写对象存储）	✅
schedule-consumer	消费 + 调用解析	Flink 完全替代	❌
schedule-manager	实例管理 + 任务调度	简化：只管理 parse-service 实例池	✅
schedule-monitor	Kafka 监控	保留 + 扩展监控 Flink	✅
schedule-embedding-api	向量化	保留（Flink 调用它）	✅
parse-service	实际解析	完全保留（核心业务逻辑）	✅

---

是否需要 Kafka 在中间？

选项 A：Flink 直接调用 embedding-api（当前 RealFlinkJob）

Flink → parse-service → embedding-api → ES

优点：

• 架构简单，少一个 Kafka 跳
• 端到端延迟低

缺点：

• Flink 需要管理向量化失败重试
• parse-service 和 embedding-api 耦合

---

选项 B：parse-service 发 Kafka，embedding-api 消费（原架构）

Flink → parse-service → Kafka → embedding-api → ES

优点：

• parse-service 和 embedding-api 解耦
• 可以独立扩展/重试
• embedding-api 可以批量消费优化

缺点：

• 多一个 Kafka 跳
• 端到端延迟高一点

---

决策记录

决策	选项	原因
Flink 部署模式	Docker Compose（开发）/ Kubernetes（生产）	简单，云原生
状态后端	FileSystem（开发）/ RocksDB（生产）	平衡性能和可靠性
中间 Kafka	可选，看业务需求	解耦 vs 延迟的权衡

---

相关文件

• docker-compose-flink.yml
• schedule-flink/
• parse-service/
• schedule-embedding-api/