windy/my-vault
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

refactor aodb design docs around technical architecture

Browse Source
This commit is contained in:
windyboy
2026-04-13 17:39:10 +08:00
parent 99d66a9601
commit abce5516e4
6 changed files with 365 additions and 445 deletions
Download Patch File Download Diff File Expand all files Collapse all files
airport-wiki/concepts/aodb/AODB 实施 Backlog.md
-257
View File
@@ -1,257 +0,0 @@
# AODB 实施 Backlog
## 1. 文档定位
本文档将 AODB 高层设计拆解为可执行实施 backlog，用于排期、分工、估算和测试准备。
- 上位输入：
- `AODB 核心需求提炼.md`
- `开源机场运营数据库（AODB）高层设计文档.md`
- `开源技术栈选型决策.md`
- 输出对象：
- Epic / Story / Task
- 验收条件
- 测试关注点
## 2. 里程碑视图
| 里程碑 | 目标 | 完成标准 |
| --- | --- | --- |
| M1 | 建立核心文档和 ADR 基线 | 需求、架构、技术栈、ADR 对齐 |
| M2 | 完成核心数据接入和当前态闭环 | SSIM / AIDX / AFTN 接入后能形成 Published Fact |
| M3 | 完成资源分配、冲突和告警闭环 | Stand / Gate / Belt / Counter 的分配和冲突可追溯 |
| M4 | 完成查询、订阅、审计和人工复核闭环 | 外部读取、事件回放、人工裁决可运行 |
| M5 | 完成容灾、压测和上线门禁 | SLO、演练、对账、补偿全部达标 |
## 3. Epic 清单
### Epic 1：领域模型与数据契约落地
目标：
- 将高层设计中的聚合、字段、事件和权威矩阵落到实现契约。
Stories：
1. 建立 `FlightOperation` 数据模型
2. 建立 `Turnaround` 数据模型
3. 建立 `MilestoneObservation` 和 `DecisionLog` 数据模型
4. 建立 `Resource` / `ResourceAllocation` 数据模型
5. 建立 `AlertCase` / `DataQualityFlag` 数据模型
验收条件：
- 所有核心对象具备主键、唯一键、幂等键和状态字段定义
- Published Fact 可追溯到 Observation 和 Decision
测试关注点：
- 主键稳定性
- 幂等键生成
- 配对修正一致性
### Epic 2：接入与标准化
目标：
- 接入 SSIM、AIDX、AFTN 并形成统一内部事件模型。
Stories：
1. 实现 SSIM 导入和批次标识
2. 实现 AIDX 标准化映射
3. 实现 AFTN / Type B 报文解析
4. 实现标准化失败进入 DLQ
5. 实现人工复核任务创建
验收条件：
- 三类输入都能进入标准化事件模型
- 解析失败可复核、可重放、可审计
测试关注点：
- 重复导入
- 报文乱序
- 格式错误
### Epic 3：Published Fact 与字段级权威治理
目标：
- 实现 Observation -> Decision -> Published Fact 的治理链路。
Stories：
1. 实现字段级权威矩阵加载与版本化
2. 实现候选事实评估
3. 实现自动裁决
4. 实现人工裁决写入
5. 实现 Published Fact 更新和审计
验收条件：
- ALDT、AIBT、TOBT、Stand Assignment 等关键字段完成治理闭环
- 当前值可返回来源、可信度和裁决摘要
测试关注点：
- 多源冲突
- 更正报文
- 超窗乱序
### Epic 4：资源分配与冲突治理
目标：
- 让资源分配具备最小可运营能力，而不是只有时间窗逻辑。
Stories：
1. 建立 Resource 主数据和能力约束
2. 实现 ResourceAllocation 软锁 / 硬锁
3. 实现时间冲突检测
4. 实现适配 / 状态 / 策略冲突检测
5. 实现人工覆盖与回滚
验收条件：
- 四类资源都具备分配、冲突、覆盖和审计能力
- 冲突能明确归类并生成告警
测试关注点：
- 延误引发冲突
- 换机型
- 资源停用
### Epic 5：告警、Case 和人工复核
目标：
- 把“人工介入”从口头方案变成有状态可追溯流程。
Stories：
1. 建立 AlertCase 状态机
2. 建立 ReviewTask 状态机
3. 实现 `ManualDecisionRecorded`
4. 实现 `ReviewTaskOpened / Closed`
5. 实现告警确认、关闭、抑制
验收条件：
- 告警和复核都有结构化状态流转
- 人工动作全部事件化和审计化
测试关注点：
- 告警重复触发
- 复核结果重放
- 覆盖与回滚
### Epic 6：事件骨干与订阅
目标：
- 构建可重放、可补偿、可隔离的标准化事件分发能力。
Stories：
1. 设计 Topic 与分区策略
2. 实现统一事件信封
3. 实现 Outbox + CDC 发布
4. 实现事件订阅接口
5. 实现断线重连与游标回放
验收条件：
- 对外事件以 Kafka 标准化事件为唯一源头
- 订阅具备至少一次投递和补偿能力
测试关注点：
- 重复投递
- CDC 断点恢复
- 消费者去重
### Epic 7：查询接口与权限治理
目标：
- 提供只读查询，不污染事实事件路径。
Stories：
1. 实现 FlightOperation 查询
2. 实现 MilestoneObservation 历史查询
3. 实现 ResourceAllocation 生效集查询
4. 实现 AlertCase 查询
5. 接入 OIDC / OAuth2 / RBAC
验收条件：
- 查询接口支持过滤、分页、更新时间和数据质量字段
- 读权限和订阅权限隔离
测试关注点：
- 稳定分页
- 字段权限
- 限流
### Epic 8：平台、容灾与观测
目标：
- 为 SLO 提供可验证支撑，而不是口头承诺。
Stories：
1. 实现 PostgreSQL HA 和备份恢复
2. 实现 Kafka 副本和保留策略
3. 实现 CDC / 发布器观测
4. 建立端到端延迟、DLQ、幂等命中率监控
5. 完成容灾与回放演练
验收条件：
- RTO / RPO 有演练记录
- P95 延迟、对账、订阅补偿可验证
测试关注点：
- DB 切换
- 事件堆积
- 订阅重连
## 4. Story 模板
每个 story 必须具备：
- 背景
- 范围
- 非范围
- 接口 / 数据影响
- 验收条件
- 回归风险
- 测试点
## 5. 建议实施顺序
1. Epic 1：领域模型与数据契约落地
2. Epic 2：接入与标准化
3. Epic 3：Published Fact 与字段级权威治理
4. Epic 4：资源分配与冲突治理
5. Epic 5：告警、Case 和人工复核
6. Epic 6：事件骨干与订阅
7. Epic 7：查询接口与权限治理
8. Epic 8：平台、容灾与观测
## 6. 进入开发前的 Gate
- 高层设计、技术栈、ADR 无结构性冲突
- 字段级权威矩阵完成首版
- 事件 schema 草案完成首版
- 最小部署拓扑完成首版
- Epic 级拆解得到负责人和初步估算
airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md
+3 -3
View File
@@ -2,7 +2,7 @@
## 1. 文档定位
本文档给出 AODB MVP 的最小部署拓扑、关键高可用策略和恢复思路，用于支撑高层设计中的 SLO 和上线门禁。
本文档给出 AODB MVP 的最小部署拓扑、关键高可用策略和恢复思路，用于细化高层设计中的部署、SLO 和容灾约束。
## 2. 目标
@@ -162,7 +162,7 @@
| conflict_mttr | 冲突平均处置时间 |
| review_task_open_count | 未关闭复核任务数 |
## 8. 上线前必须演练
## 8. 关键演练场景
1. PostgreSQL 主备切换
2. Kafka 单 broker 故障恢复
@@ -173,4 +173,4 @@
## 9. 与高层设计的关系
- 本文档细化 `开源机场运营数据库（AODB）高层设计文档.md` 中的部署与 SLO 章节。
- 它不是最终部署手册，但必须足以支撑架构评审和上线门禁定义。
- 它不是最终部署手册，但必须足以支撑架构评审、容灾设计和运维基线定义。
airport-wiki/concepts/aodb/AODB 核心需求提炼.md
+22 -46
View File
@@ -2,7 +2,7 @@
## 1. 文档定位
本文档定义 AODB 的业务目标、范围边界、功能清单和验收指标，用于立项评审、架构设计和实施排期对齐。
本文档定义 AODB 的业务目标、范围边界、核心能力和约束条件，作为高层设计和技术选型的上位输入。
- 目标对象：年旅客吞吐量 500 万至 3000 万的中型机场
- 目标系统：机场运营数据库（AODB）及其核心协同能力
@@ -28,32 +28,19 @@ MVP（首期必须）：
- 外部数据共享接口（查询 + 事件订阅）
- 审计、裁决、人工复核闭环
非 MVP（后续迭代）：
非 MVP：
- 高级优化排班（全局优化/仿真）
- 深度 AI 预测（跨季节模型、异常解释）
- 多机场统一调度与集团化运营
- 起飞排序和复杂流处理平台化能力
### 2.3 路线分层（MVP / P1 / P2）
### 2.3 范围约束
| 能力 | MVP | P1 | P2 | 备注 |
| --- | --- | --- | --- | --- |
| 航班计划导入 | 是 | | | SSIM / 计划批量导入 |
| 动态更新 | 是 | | | AIDX / AFTN 等运行态接入 |
| 里程碑管理 | 是 | | | 关键里程碑统一治理 |
| 航班配对与过站关联 | 是 | | | 以 `Turnaround` 最小建模 |
| 基础资源分配 | 是 | | | Stand / Gate / Belt / Counter |
| 冲突检测与告警 | 是 | | | 时间冲突、适配冲突、状态冲突 |
| 查询接口 | 是 | | | 面向外部系统和运营终端 |
| 事件订阅 | 是 | | | 至少一次投递、支持重连补偿 |
| 审计与人工裁决 | 是 | | | 关键写入必须可追溯 |
| EIBT / EXIT / EXOT 预测 | | 是 | | 有状态流处理增强能力 |
| TSAT / TTOT 计算 | | 是 | | 与 PDS 衔接 |
| 复杂 CEP | | 是 | | 实时模式识别和复杂聚合 |
| 全局优化排班 | | | 是 | 不属于首期闭环 |
| AI 调度与异常解释 | | | 是 | 在数据基础稳定后引入 |
| 多机场统一调度 | | | 是 | 单机场稳定后再扩展 |
- 单机场优先，跨机场能力不作为 MVP 前提。
- MVP 聚焦“当前态统一、事件可追溯、人工可介入”，不以复杂优化能力为前提。
- 若外部系统稳定性不足，必须预留灰度、手工复核和数据质量标记兜底流程。
- 首期不要求深度历史迁移，只要求新接入链路具备统一主键、幂等和审计能力。
## 3. 功能需求清单
@@ -82,24 +69,24 @@ MVP（首期必须）：
3. 解析失败消息必须进入死信队列并提供人工复核入口。
4. 当前权威值不得直接由多个系统并行写入，必须经过字段级权威矩阵和裁决逻辑。
## 5. 非功能需求（SLO）
## 5. 非功能需求
| 维度 | 目标值 | 最低可接受值 | 验收方式 |
| 维度 | 目标值 | 最低可接受值 | 说明 |
| --- | --- | --- | --- |
| 可用性 | 月度 99.95% | 月度 99.9% | 监控报表与故障统计 |
| 事件处理延迟 | P95 <= 2 秒 | P95 <= 5 秒 | 压测与生产观测 |
| 数据一致性 | 关键实体强一致 | 最终一致 <= 30 秒 | 对账任务与抽检 |
| 恢复能力 | RTO <= 30 分钟，RPO <= 5 分钟 | RTO <= 2 小时，RPO <= 15 分钟 | 容灾演练记录 |
| 审计追踪 | 100% 关键变更可追溯 | 99.9% 可追溯 | 审计抽样与链路回放 |
| 安全 | OIDC/OAuth2 + RBAC + 传输加密 | RBAC + 传输加密 | 安全测试与配置核查 |
| 可用性 | 月度 99.95% | 月度 99.9% | 保障核心运行时段可用 |
| 事件处理延迟 | P95 <= 2 秒 | P95 <= 5 秒 | 覆盖接入到发布事实主链路 |
| 数据一致性 | 关键实体强一致 | 最终一致 <= 30 秒 | 当前态和事件流必须可对账 |
| 恢复能力 | RTO <= 30 分钟，RPO <= 5 分钟 | RTO <= 2 小时，RPO <= 15 分钟 | 支撑单机场容灾恢复 |
| 审计追踪 | 100% 关键变更可追溯 | 99.9% 可追溯 | 覆盖自动裁决和人工动作 |
| 安全 | OIDC/OAuth2 + RBAC + 传输加密 | RBAC + 传输加密 | 对外查询和订阅必须受控 |
## 6. 上线假设与约束
## 6. 架构约束
- 单机场优先，跨机场能力不作为首期交付前提。
- 首期仅覆盖核心运行场景，不包含深度历史迁移改造。
- 2 至 4 周快速上线只适用于受控数据源、缩减版 MVP、单团队交付场景，不包含复杂流处理、复杂工作流平台和多机场能力。
- 若外部系统接口稳定性不足，需预留灰度、手工复核和数据质量标记兜底流程。
- 首期架构优先保证“当前态统一、事件可追溯、人工可介入”，不以复杂优化能力为上线前提。
- Flight 当前态必须只有一个写主，不允许多个系统直接并行改写权威字段。
- 所有关键写入必须带来源、时间、幂等键和关联 ID。
- 原始观测、裁决记录、发布事实必须分层保存，不允许只保留当前值。
- 查询接口和事件订阅接口必须分离，不允许把查询层当作事实流输出。
- 人工覆盖、回滚和复核必须事件化、审计化。
## 7. 术语与缩写（权威定义）
@@ -115,21 +102,10 @@ MVP（首期必须）：
| EIBT | Estimated In-Block Time，预计靠桥时间 |
| Turnaround | 航班过站对象，关联到达航班、离港航班与飞机周转上下文 |
## 8. 验收清单（DoD）
1. MVP 功能域全部具备可演示业务闭环。
2. 关键非功能指标达到最低可接受值。
3. 核心实体和关键事件具备统一主键、幂等规则和写主边界。
4. 对外接口具备鉴权、限流、审计和重连补偿能力。
5. 字段级权威矩阵、事件契约、容灾策略和人工复核流程具备文档化定义。
6. 文档与实现一致，可用于排期拆解、测试用例编制和 ADR 评审。
## 9. 关联文档
## 8. 关联文档
- `airport-wiki/concepts/aodb/开源技术栈选型决策.md`
- `airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md`
- `airport-wiki/concepts/aodb/AODB 高层设计修订计划.md`
- `airport-wiki/concepts/aodb/AODB 实施 Backlog.md`
- `airport-wiki/concepts/aodb/AODB 字段级权威矩阵.md`
- `airport-wiki/concepts/aodb/AODB 事件 Schema 草案.md`
- `airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md`
airport-wiki/concepts/aodb/AODB 高层设计修订计划.md
-79
View File
@@ -1,79 +0,0 @@
# AODB 高层设计修订计划
## 1. 修订目标
本轮修订目标不是继续扩展概念，而是把 AODB 设计收敛成可以进入开工评审的版本：
- 收缩 MVP，避免首期过载
- 锁定领域边界和写主归属
- 明确事实分层和字段级权威矩阵
- 将资源冲突从单一时间窗问题升级为可运营模型
- 分离查询接口与事件订阅
- 补齐部署、容灾、审计和演练要求
## 2. 当前主要问题
1. MVP 范围过重，和目标机场规模、交付周期不匹配。
2. 服务边界偏描述性，未锁定写主和聚合边界。
3. 缺少 `Turnaround` 等关键领域对象。
4. SSOT 仅有原则，缺少 Observation / Decision / Published Fact 分层。
5. 资源模型过薄，无法表达适配、冻结、软硬锁定等真实约束。
6. SLO 未充分映射到部署和容灾设计。
## 3. 分阶段任务
### 3.1 阶段 1：收缩范围
- 重写需求文档中的 MVP / P1 / P2 分层
- 在高层设计文档中删去首期不需要的平台化能力
- 在技术栈文档中区分 MVP 主选和后续启用组件
### 3.2 阶段 2：重构领域边界
- 新增聚合边界表
- 锁定 Flight 当前态唯一写主
- 引入 `Turnaround` 作为首期核心对象
### 3.3 阶段 3：补齐事实模型
- 引入 Observation / Decision / Published Fact 三层模型
- 增加字段级权威矩阵
- 明确人工覆盖和更正语义
### 3.4 阶段 4：补齐资源与事件模型
- 扩展 Resource / ResourceAllocation 模型
- 建立冲突分类
- 规范事件分类、事件归属和消费者契约
### 3.5 阶段 5：补齐部署与 ADR
- 增加最小部署拓扑、SLO 映射和容灾约束
- 写入关键 ADR，固化设计取舍
## 4. 决策记录索引
- `adr/ADR-001 MVP 不引入 Flink.md`
- `adr/ADR-002 Kafka 作为唯一事件骨干.md`
- `adr/ADR-003 事实分层模型.md`
- `adr/ADR-004 FlightOperation 写主归属.md`
- `adr/ADR-005 Turnaround 独立建模.md`
- `adr/ADR-006 资源锁定模型.md`
- `adr/ADR-007 查询与订阅分离.md`
- `adr/ADR-008 Outbox 与 CDC.md`
- `adr/ADR-009 PostgreSQL HA.md`
- `adr/ADR-010 人工裁决事件化.md`
## 5. 下层设计文档
- `AODB 实施 Backlog.md`
- `AODB 字段级权威矩阵.md`
- `AODB 事件 Schema 草案.md`
- `AODB 最小部署拓扑草案.md`
## 6. 完成标准
- 三份核心文档在范围、技术栈和边界定义上相互一致
- 关键设计取舍全部具备 ADR
- 文档可直接支持任务拆解、测试设计和架构评审
- 下层设计文档足以支撑实现前的细化评审
airport-wiki/concepts/aodb/开源机场运营数据库（AODB）高层设计文档.md
+55 -60
View File
@@ -1,35 +1,35 @@
# 开源机场运营数据库（AODB）高层设计文档
## 1. 目标
## 1. 文档目标
本设计给出 AODB 的首期可开工高层方案，重点回答六件事：
本文档定义 AODB MVP 的技术方案基线，重点回答以下问题：
1. 首期上线到底做什么、不做什么。
2. 系统由哪些核心聚合和服务组成。
3. 关键业务数据如何在“观测、裁决、发布事实”之间流转。
4. 资源分配、冲突、告警和人工复核如何闭环。
5. 对外查询与事件订阅如何解耦。
6. SLO 与部署、容灾和审计如何对齐。
1. AODB 在 MVP 内承载哪些业务闭环，以及哪些能力明确不做。
2. 系统如何划分聚合、服务、数据流和事件边界。
3. 航班、里程碑、资源、告警等核心对象如何建模。
4. 发布事实如何在观测、裁决、审计和订阅之间保持一致。
5. 查询、订阅、部署、容灾和可观测性如何落到可实现架构。
适用范围：年旅客吞吐量 500 万至 3000 万机场，单机场优先。
适用范围：年旅客吞吐量 500 万至 3000 万机场，优先支持单机场部署。
## 2. 设计原则
- 单一事实源：AODB 对外只发布单一当前权威事实，不暴露“谁最后写入”式伪一致。
- 单一事实源：AODB 对外发布单一当前权威事实，不暴露“谁最后写入”式伪一致。
- 事实分层：原始观测、裁决记录、发布事实必须分层建模。
- 事件驱动：状态变化通过事件传播，系统间通过契约解耦。
- 规则可解释：字段权威、冲突裁决、人工覆盖都必须能解释来源和原因。
- 渐进建设：先做稳定闭环，再引入预测、CEP 和复杂编排能力。
- 写主清晰：每个核心聚合只允许一个服务写入，避免跨服务共享可变状态。
- 事件驱动：状态变化通过事件传播，系统通过契约解耦。
- 规则可解释：字段权威、冲突裁决、人工覆盖必须可追溯、可回放、可解释。
- 渐进复杂度：MVP 先建立稳定闭环，不引入复杂优化平台和长事务编排平台。
## 3. 范围与阶段
## 3. 范围定义
### 3.1 MVP 范围
首期上线只覆盖以下闭环：
首期只覆盖以下闭环：
- 航班计划导入与实时状态更新
- 航班配对与过站上下文最小建模
- 基础资源分配（Stand、Gate、Belt、Counter）
- 基础资源分配：Stand、Gate、Belt、Counter
- 关键里程碑跟踪与发布事实治理
- 延误、资源冲突和数据质量告警
- 对外查询接口与事件订阅
@@ -37,33 +37,39 @@
### 3.2 非 MVP 范围
不纳入首期：
首期不纳入以下能力：
- 复杂优化排班（全局优化模型）
- 深度 AI 预测与自适应调度
- Flink 驱动的复杂 CEP 和预测平台
- 全局优化排班和复杂资源优化求解
- 深度 AI 预测和自适应调度
- Flink 驱动的复杂 CEP 平台
- Temporal 驱动的复杂长事务工作流平台
- 多机场统一调度中心能力
### 3.3 分阶段演进
- Phase 1：完成 MVP 闭环并上线单机场。
- Phase 2：引入预测能力、复杂规则平台和补偿编排能力。
- Phase 3：增强容量、容灾和多机场扩展。
## 4. 总体架构
### 4.1 架构分层
| 层级 | 主要能力 | MVP 主路径组件 | 后续增强组件 |
| 层级 | 主要能力 | MVP 主路径组件 | 说明 |
| --- | --- | --- | --- |
| 接入层 | 外部系统接入、协议解析、统一北向入口 | Kong Gateway、Apache Camel、SSIM 导入器 | 协议适配扩展插件 |
| 业务层 | 航班当前态、观测治理、资源分配、告警处置、对外接口 | Flight Operation Service、Milestone Service、Resource Service、Alert Service、External API Service | 独立 Case / Workflow Service |
| 事件层 | 事件骨干、重放、订阅分发 | Kafka、Outbox/CDC 发布器 | 订阅网关增强、Schema Registry |
| 数据层 | 事务存储、时序存储、缓存 | PostgreSQL、TimescaleDB、Redis | OpenSearch、对象存储 |
| 平台层 | 身份认证、部署、观测 | Keycloak、Kubernetes、Prometheus/Grafana/Loki | Linkerd、Jaeger |
| 接入层 | 外部系统接入、协议解析、统一北向入口 | Kong Gateway、Apache Camel、SSIM 导入器 | 接收计划、动态、资源和人工操作输入 |
| 业务层 | 航班当前态、观测治理、资源分配、告警处置、外部接口 | Flight Operation Service、Milestone Service、Resource Service、Alert Service、External API Service | 承担领域逻辑和对外契约 |
| 事件层 | 事件骨干、重放、订阅分发 | Kafka、Outbox/CDC 发布器 | 负责异步传播和回放 |
| 数据层 | 事务存储、时序存储、缓存 | PostgreSQL、TimescaleDB、Redis | 保存当前态、审计链路和热点读模型 |
| 平台层 | 认证鉴权、部署、观测 | Keycloak、Kubernetes、Prometheus/Grafana/Loki | 提供运行时底座 |
### 4.2 领域划分与聚合边界
### 4.2 核心技术链路
MVP 主链路采用“接入标准化 -> 观测入库 -> 裁决生成 -> 发布事实更新 -> 事件发布 -> 查询/订阅消费”的结构：
1. 外部计划或运行动态通过接入层进入系统。
2. Milestone Service 将输入标准化为 Observation，并按幂等键写入。
3. 规则引擎根据字段权威矩阵和当前上下文生成 Decision。
4. Flight Operation Service 更新 Published Fact 和当前状态摘要。
5. 同一事务内写入 Outbox，由 CDC 发布到 Kafka。
6. External API Service 对外提供查询接口和事件订阅接口。
7. 告警、人工裁决和重放都沿同一事实链路工作，不直接绕过 Published Fact。
### 4.3 领域划分与聚合边界
为避免多服务共同修改同一业务对象，MVP 采用以下聚合边界：
@@ -82,7 +88,7 @@
- Resource Service 只拥有资源占用与冲突事实，不直接修改 Flight 当前态中的非资源字段。
- Alert Service 不产生业务事实，只管理处置状态和告警生命周期。
### 4.3 核心服务职责
### 4.4 核心服务职责
- `Flight Operation Service`
- 管理 FlightOperation 当前态。
@@ -106,19 +112,19 @@
### 5.1 核心标识约定
- Flight：
- Flight
- `flight_key`：`carrier + flight_number + op_date + leg_no`
- `flight_id`：内部不可变主键
- Turnaround：
- Turnaround
- `turnaround_id`
- 可关联一个到达航班和一个离港航班
- MilestoneObservation：
- MilestoneObservation
- `observation_id`
- 幂等键优先使用上游报文 ID、序列号或批次 + 行号
- Resource：
- Resource
- `resource_id`
- `resource_type + resource_code` 唯一
- ResourceAllocation：
- ResourceAllocation
- `allocation_id`
- 幂等键由 `resource_id + validity_window + assignment_source + correlation_id` 组合约束
@@ -414,7 +420,7 @@ MVP 采用 `Outbox Pattern + CDC`：
- 顺序仅保证到 `flight_id`
- 消费者必须按 `event_id` 去重
- 消费者必须处理数据质量标记和裁决摘要
- 回放窗口和游标语义必须文档化并纳入验收
- 回放窗口和游标语义必须文档化
## 12. 规则体系与人工复核
@@ -486,30 +492,19 @@ MVP 采用 `Outbox Pattern + CDC`：
- Outbox / CDC 必须具备断点恢复和重复投递幂等能力。
- 容灾演练必须覆盖数据库切换、事件堆积、订阅重连和回放。
### 13.4 SLO 映射表
### 13.4 可观测性要求
| SLO | 设计支撑 | 验收方式 |
| --- | --- | --- |
| 可用性 | 多副本 API、DB HA、Kafka 副本 | 演练和月度故障统计 |
| 延迟 | 单聚合写主、Kafka 事件骨干、缓存热点读 | 压测和生产观测 |
| RTO / RPO | DB 备份恢复、Kafka 重放、CDC 恢复 | 容灾演练 |
| 审计覆盖 | Observation / Decision / AuditTrail | 抽样链路回放 |
- 所有写路径必须具备请求追踪、事件追踪和审计追踪三类关联 ID。
- 关键链路必须暴露延迟、失败率、积压量和重试次数指标。
- 人工裁决、资源覆盖和更正事件必须进入统一审计检索视图。
- 订阅接口必须暴露连接数、滞后量、推送速率和补偿次数指标。
## 14. 上线门禁（Go / No-Go）
## 14. 文档边界与引用
- 功能门禁：计划导入、动态接入、里程碑发布事实、资源分配、冲突告警、人工裁决链路可端到端演示。
- 数据门禁：核心实体对账通过率 >= 99.9%，无高危不一致项。
- 一致性门禁：Outbox / CDC、重放、幂等和断线补偿完成验证。
- 安全门禁：统一认证鉴权生效，关键接口通过授权与审计检查。
- 演练门禁：完成数据库恢复、事件重放和订阅补偿演练。
## 15. 文档边界与引用
- 本文档定义首期可开工的高层设计，不展开字段级数据字典和实现细节。
- 技术栈主选、后续启用条件以 `airport-wiki/concepts/aodb/开源技术栈选型决策.md` 为准。
- 需求边界、验收基线以 `airport-wiki/concepts/aodb/AODB 核心需求提炼.md` 为准。
- 本文档定义首期可开工的技术方案，不展开字段级数据字典和实现细节。
- 技术栈主选和启用条件以 `airport-wiki/concepts/aodb/开源技术栈选型决策.md` 为准。
- 需求边界以 `airport-wiki/concepts/aodb/AODB 核心需求提炼.md` 为准。
- 字段级权威矩阵以 `airport-wiki/concepts/aodb/AODB 字段级权威矩阵.md` 为准。
- 事件 envelope 和 payload 草案以 `airport-wiki/concepts/aodb/AODB 事件 Schema 草案.md` 为准。
- 最小部署拓扑和恢复策略草案以 `airport-wiki/concepts/aodb/AODB 最小部署拓扑草案.md` 为准。
- 实施拆解以 `airport-wiki/concepts/aodb/AODB 实施 Backlog.md` 为准。
- 关键设计取舍以 `airport-wiki/concepts/aodb/adr/` 下 ADR 为准。