refine aodb high-level design and planning docs
This commit is contained in:
windyboy
@@ -25,24 +25,47 @@ MVP（首期必须）：
|
|||||||
- 机位/登机口/行李转盘/值机柜台基础资源分配
|
- 机位/登机口/行李转盘/值机柜台基础资源分配
|
||||||
- A-CDM 核心里程碑管理与变更发布
|
- A-CDM 核心里程碑管理与变更发布
|
||||||
- 运营告警（延误、资源冲突）
|
- 运营告警（延误、资源冲突）
|
||||||
- 外部数据共享接口（REST/GraphQL 订阅）
|
- 外部数据共享接口（查询 + 事件订阅）
|
||||||
|
- 审计、裁决、人工复核闭环
|
||||||
|
|
||||||
非 MVP（后续迭代）：
|
非 MVP（后续迭代）：
|
||||||
|
|
||||||
- 高级优化排班（全局优化/仿真）
|
- 高级优化排班（全局优化/仿真）
|
||||||
- 深度 AI 预测（跨季节模型、异常解释）
|
- 深度 AI 预测（跨季节模型、异常解释）
|
||||||
- 多机场统一调度与集团化运营
|
- 多机场统一调度与集团化运营
|
||||||
|
- 起飞排序和复杂流处理平台化能力
|
||||||
|
|
||||||
|
### 2.3 路线分层（MVP / P1 / P2）
|
||||||
|
|
||||||
|
| 能力 | MVP | P1 | P2 | 备注 |
|
||||||
|
| --- | --- | --- | --- | --- |
|
||||||
|
| 航班计划导入 | 是 | | | SSIM / 计划批量导入 |
|
||||||
|
| 动态更新 | 是 | | | AIDX / AFTN 等运行态接入 |
|
||||||
|
| 里程碑管理 | 是 | | | 关键里程碑统一治理 |
|
||||||
|
| 航班配对与过站关联 | 是 | | | 以 `Turnaround` 最小建模 |
|
||||||
|
| 基础资源分配 | 是 | | | Stand / Gate / Belt / Counter |
|
||||||
|
| 冲突检测与告警 | 是 | | | 时间冲突、适配冲突、状态冲突 |
|
||||||
|
| 查询接口 | 是 | | | 面向外部系统和运营终端 |
|
||||||
|
| 事件订阅 | 是 | | | 至少一次投递、支持重连补偿 |
|
||||||
|
| 审计与人工裁决 | 是 | | | 关键写入必须可追溯 |
|
||||||
|
| EIBT / EXIT / EXOT 预测 | | 是 | | 有状态流处理增强能力 |
|
||||||
|
| TSAT / TTOT 计算 | | 是 | | 与 PDS 衔接 |
|
||||||
|
| 复杂 CEP | | 是 | | 实时模式识别和复杂聚合 |
|
||||||
|
| 全局优化排班 | | | 是 | 不属于首期闭环 |
|
||||||
|
| AI 调度与异常解释 | | | 是 | 在数据基础稳定后引入 |
|
||||||
|
| 多机场统一调度 | | | 是 | 单机场稳定后再扩展 |
|
||||||
|
|
||||||
## 3. 功能需求清单
|
## 3. 功能需求清单
|
||||||
|
|
||||||
| 功能域 | 核心能力 | 输入 | 输出 | MVP |
|
| 功能域 | 核心能力 | 输入 | 输出 | MVP |
|
||||||
| ----------------- | ----------------------------------------------------- | -------------------------- | ------------------------ | --- |
|
| --- | --- | --- | --- | --- |
|
||||||
| 航班数据管理 | 航班计划导入、动态更新、历史回放、航班配对（Linking） | SSIM、AIDX、AFTN | 标准化航班主数据与状态流 | 是 |
|
| 航班数据管理 | 航班计划导入、动态更新、历史回放、航班配对（Linking） | SSIM、AIDX、AFTN | 标准化航班主数据与状态流 | 是 |
|
||||||
| 资源管理 | 机位/登机口/行李转盘/值机柜台分配与冲突检测 | 航班状态、资源可用性、规则 | 资源分配结果、冲突事件 | 是 |
|
| 资源管理 | 机位/登机口/行李转盘/值机柜台分配与冲突检测 | 航班状态、资源可用性、规则 | 资源分配结果、冲突事件 | 是 |
|
||||||
| A-CDM 里程碑 | 里程碑采集、校验、发布、追踪 | ANSP/航司/地服事件 | 里程碑状态、时序记录 | 是 |
|
| A-CDM 里程碑 | 里程碑采集、校验、发布、追踪 | ANSP/航司/地服事件 | 里程碑状态、时序记录 | 是 |
|
||||||
| 实时计算引擎 | EIBT/EXIT/EXOT 预测、TSAT 计算 | 运行态事件、历史统计 | 预测结果、排序建议 | 是 |
|
| 裁决与复核 | 数据冲突复核、人工覆盖、事件重放 | 冲突事件、复核任务 | 裁决记录、发布事实 | 是 |
|
||||||
| 告警与预警 | 延误告警、冲突告警、超阈值告警 | 实时事件、规则配置 | 告警通知、处置状态 | 是 |
|
| 告警与预警 | 延误告警、冲突告警、超阈值告警 | 实时事件、规则配置 | 告警通知、处置状态 | 是 |
|
||||||
| 信息共享（ACISP） | 面向航司/管制/地服的数据订阅 | 业务实体与事件 | 外部查询/订阅接口 | 是 |
|
| 信息共享（ACISP） | 面向航司/管制/地服的数据查询与订阅 | 业务实体与事件 | 外部查询/订阅接口 | 是 |
|
||||||
|
| 实时计算增强 | EIBT/EXIT/EXOT 预测、TSAT 计算 | 运行态事件、历史统计 | 预测结果、排序建议 | P1 |
|
||||||
| 起飞排序（PDS） | TSAT/TTOT/EXOT 规则计算与可追溯 | 里程碑、滑行预测、管制约束 | 排序建议与调整记录 | P1 |
|
| 起飞排序（PDS） | TSAT/TTOT/EXOT 规则计算与可追溯 | 里程碑、滑行预测、管制约束 | 排序建议与调整记录 | P1 |
|
||||||
|
|
||||||
## 4. 标准与集成要求
|
## 4. 标准与集成要求
|
||||||
@@ -57,11 +80,12 @@ MVP（首期必须）：
|
|||||||
1. 所有外部输入必须经过标准化映射层，生成统一内部事件模型。
|
1. 所有外部输入必须经过标准化映射层，生成统一内部事件模型。
|
||||||
2. 所有关键写入必须具备幂等键和可追溯来源字段。
|
2. 所有关键写入必须具备幂等键和可追溯来源字段。
|
||||||
3. 解析失败消息必须进入死信队列并提供人工复核入口。
|
3. 解析失败消息必须进入死信队列并提供人工复核入口。
|
||||||
|
4. 当前权威值不得直接由多个系统并行写入，必须经过字段级权威矩阵和裁决逻辑。
|
||||||
|
|
||||||
## 5. 非功能需求（SLO）
|
## 5. 非功能需求（SLO）
|
||||||
|
|
||||||
| 维度 | 目标值 | 最低可接受值 | 验收方式 |
|
| 维度 | 目标值 | 最低可接受值 | 验收方式 |
|
||||||
| ------------ | ----------------------------- | ----------------------------- | ------------------ |
|
| --- | --- | --- | --- |
|
||||||
| 可用性 | 月度 99.95% | 月度 99.9% | 监控报表与故障统计 |
|
| 可用性 | 月度 99.95% | 月度 99.9% | 监控报表与故障统计 |
|
||||||
| 事件处理延迟 | P95 <= 2 秒 | P95 <= 5 秒 | 压测与生产观测 |
|
| 事件处理延迟 | P95 <= 2 秒 | P95 <= 5 秒 | 压测与生产观测 |
|
||||||
| 数据一致性 | 关键实体强一致 | 最终一致 <= 30 秒 | 对账任务与抽检 |
|
| 数据一致性 | 关键实体强一致 | 最终一致 <= 30 秒 | 对账任务与抽检 |
|
||||||
@@ -73,31 +97,39 @@ MVP（首期必须）：
|
|||||||
|
|
||||||
- 单机场优先，跨机场能力不作为首期交付前提。
|
- 单机场优先，跨机场能力不作为首期交付前提。
|
||||||
- 首期仅覆盖核心运行场景，不包含深度历史迁移改造。
|
- 首期仅覆盖核心运行场景，不包含深度历史迁移改造。
|
||||||
- 2 至 4 周快速上线仅适用于 MVP 范围和数据源受控场景。
|
- 2 至 4 周快速上线只适用于受控数据源、缩减版 MVP、单团队交付场景，不包含复杂流处理、复杂工作流平台和多机场能力。
|
||||||
- 若外部系统接口稳定性不足，需预留灰度和人工兜底流程。
|
- 若外部系统接口稳定性不足，需预留灰度、手工复核和数据质量标记兜底流程。
|
||||||
|
- 首期架构优先保证“当前态统一、事件可追溯、人工可介入”，不以复杂优化能力为上线前提。
|
||||||
|
|
||||||
## 7. 术语与缩写（权威定义）
|
## 7. 术语与缩写（权威定义）
|
||||||
|
|
||||||
| 缩写 | 定义 |
|
| 缩写 | 定义 |
|
||||||
| ----- | --------------------------------------------------- |
|
| --- | --- |
|
||||||
| AODB | Airport Operational Database，机场运营数据库 |
|
| AODB | Airport Operational Database，机场运营数据库 |
|
||||||
| SSOT | Single Source of Truth，单一事实源 |
|
| SSOT | Single Source of Truth，单一事实源 |
|
||||||
| A-CDM | Airport Collaborative Decision Making，机场协同决策 |
|
| A-CDM | Airport Collaborative Decision Making，机场协同决策 |
|
||||||
| TSAT | Target Start-up Approval Time，目标放行时间 |
|
| TSAT | Target Start-up Approval Time，目标放行时间 |
|
||||||
| TTOT | Target Take-off Time，目标起飞时间 |
|
| TTOT | Target Take-off Time，目标起飞时间 |
|
||||||
| EXOT | Estimated Exit/Taxi-Out Time，预计滑出时间 |
|
| EXOT | Estimated Taxi-Out Time，预计滑出时间 |
|
||||||
| EXIT | Estimated Taxi-In Time，预计滑入时间 |
|
| EXIT | Estimated Taxi-In Time，预计滑入时间 |
|
||||||
| EIBT | Estimated In-Block Time，预计靠桥时间 |
|
| EIBT | Estimated In-Block Time，预计靠桥时间 |
|
||||||
|
| Turnaround | 航班过站对象，关联到达航班、离港航班与飞机周转上下文 |
|
||||||
|
|
||||||
## 8. 验收清单（DoD）
|
## 8. 验收清单（DoD）
|
||||||
|
|
||||||
1. MVP 功能域全部具备可演示业务闭环。
|
1. MVP 功能域全部具备可演示业务闭环。
|
||||||
2. 关键非功能指标达到最低可接受值。
|
2. 关键非功能指标达到最低可接受值。
|
||||||
3. 核心实体和关键事件具备统一主键与幂等规则。
|
3. 核心实体和关键事件具备统一主键、幂等规则和写主边界。
|
||||||
4. 对外接口具备鉴权、限流、审计能力。
|
4. 对外接口具备鉴权、限流、审计和重连补偿能力。
|
||||||
5. 文档与实现一致，可用于排期拆解与测试用例编制。
|
5. 字段级权威矩阵、事件契约、容灾策略和人工复核流程具备文档化定义。
|
||||||
|
6. 文档与实现一致，可用于排期拆解、测试用例编制和 ADR 评审。
|
||||||
|
|
||||||
## 9. 关联文档
|
## 9. 关联文档
|
||||||
|
|
||||||
- `airport-wiki/concepts/aodb/开源技术栈选型决策.md`
|
- `airport-wiki/concepts/aodb/开源技术栈选型决策.md`
|
||||||
- `airport-wiki/concepts/aodb/开源机场运营数据库（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`
|
||||||
|
|||||||
@@ -10,72 +10,82 @@
|
|||||||
2. 优先选择成熟开源生态和团队可落地能力。
|
2. 优先选择成熟开源生态和团队可落地能力。
|
||||||
3. 对核心路径采用单一主选，备选仅定义触发条件。
|
3. 对核心路径采用单一主选，备选仅定义触发条件。
|
||||||
4. 支持私有化部署和后续多机场扩展。
|
4. 支持私有化部署和后续多机场扩展。
|
||||||
|
5. MVP 优先收敛复杂度，不以技术先进性替代交付确定性。
|
||||||
|
|
||||||
## 2. 技术栈总览（主选）
|
## 2. 技术栈总览
|
||||||
|
|
||||||
|
### 2.1 MVP 主选
|
||||||
|
|
||||||
| 分层 | 主选方案 | 说明 |
|
| 分层 | 主选方案 | 说明 |
|
||||||
| ------------ | ------------------------------------ | ---------------------------- |
|
| --- | --- | --- |
|
||||||
| 主数据存储 | PostgreSQL 16 | 关键业务数据强一致事务 |
|
| 主数据存储 | PostgreSQL 16 | 关键业务数据强一致事务 |
|
||||||
| 时序存储 | TimescaleDB | 里程碑与遥测时序数据 |
|
| 时序存储 | TimescaleDB | 里程碑、观测与审计时间序列 |
|
||||||
| 缓存与实时态 | Redis 7 (Valkey) | 高频状态读取与短期流式缓存 |
|
| 缓存与热点读 | Redis 7 (Valkey) | 高频读、短期缓存、去重辅助 |
|
||||||
| 搜索分析 | OpenSearch 2.x | 全文检索、日志分析、开源友好 |
|
| 事件总线 | Apache Kafka 3.x | 统一事件骨干和可回放能力 |
|
||||||
| 事件总线 | Apache Kafka 3.x | 高吞吐与持久化事件骨干 |
|
|
||||||
| 流处理 | Apache Flink 1.19 | 低延迟有状态流计算与 CEP |
|
|
||||||
| 协议集成 | Apache Camel | AIDX / AFTN / SITA 协议适配 |
|
| 协议集成 | Apache Camel | AIDX / AFTN / SITA 协议适配 |
|
||||||
| API 网关 | Kong Gateway OSS | 鉴权、限流、路由治理 |
|
| API 网关 | Kong Gateway OSS | 鉴权、限流、路由治理 |
|
||||||
| GraphQL 层 | Hasura | 实时订阅与快速 API 暴露 |
|
|
||||||
| 规则引擎 | Drools | 复杂规则可配置与可追溯 |
|
|
||||||
| 工作流编排 | Temporal | 长事务与补偿流程编排 |
|
|
||||||
| 认证授权 | Keycloak 24 | OIDC / OAuth2 与 RBAC |
|
| 认证授权 | Keycloak 24 | OIDC / OAuth2 与 RBAC |
|
||||||
| 可观测性 | Prometheus + Grafana + Jaeger + Loki | 指标、追踪、日志统一观测 |
|
| 可观测性 | Prometheus + Grafana + Loki | 指标、看板、日志观测 |
|
||||||
| 容器平台 | Kubernetes + Helm | 标准化部署与扩缩容 |
|
| 容器平台 | Kubernetes + Helm | 标准化部署与环境一致性 |
|
||||||
| 服务网格 | Linkerd | 轻量 mTLS 与服务治理 |
|
|
||||||
| 对象存储 | MinIO | S3 兼容对象存储 |
|
### 2.2 后续启用组件
|
||||||
| 前端与终端 | React + TypeScript + PWA | 看板与移动访问统一前端栈 |
|
|
||||||
|
| 组件 | 定位 | 启用触发条件 | 当前决策 |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| Flink | 有状态流处理、预测、CEP | EIBT / EXIT / EXOT 预测进入上线范围，且简单流式处理无法满足延迟和可恢复性目标 | P1 |
|
||||||
|
| Drools | 复杂规则平台 | 规则量、规则变更频率和回放需求超过代码化规则可维护边界 | P1 |
|
||||||
|
| Temporal | 长流程编排与补偿 | 人工复核、跨系统补偿和状态机复杂度超出单服务事务编排能力 | P1 |
|
||||||
|
| Hasura | 快速 GraphQL 查询与订阅暴露 | 前端字段裁剪、实时订阅和权限编排复杂度显著上升 | 可选 |
|
||||||
|
| OpenSearch | 搜索与分析投影 | 全文检索、复杂检索、跨字段搜索成为上线能力 | P1 |
|
||||||
|
| Linkerd | 服务间 mTLS 与服务治理 | 服务数量、零信任要求和多团队治理复杂度显著增加 | 可选 |
|
||||||
|
| MinIO | 对象存储 | 需要保存批量导入文件、报文附件和复核证据对象 | 可选 |
|
||||||
|
| React + TypeScript + PWA | 运营终端前端栈 | 本期建设自研终端而非只做系统接口时启用 | 可选 |
|
||||||
|
|
||||||
## 3. 关键决策与备选触发条件
|
## 3. 关键决策与备选触发条件
|
||||||
|
|
||||||
| 决策项 | 主选 | 备选 | 触发备选条件 | 说明 |
|
| 决策项 | 主选 | 备选 | 触发备选条件 | 说明 |
|
||||||
| ------------ | ---------- | ------------- | ---------------------------------------------------- | --------------------------------- |
|
| --- | --- | --- | --- | --- |
|
||||||
| 搜索引擎 | OpenSearch | Elasticsearch | 必须依赖特定商业插件时 | 优先开源许可证与成本可控 |
|
| 搜索引擎 | 暂不纳入 MVP | OpenSearch | 上线阶段需要全文检索、复杂筛选和日志联动检索时 | MVP 不为未来检索需求预埋过重组件 |
|
||||||
| GraphQL 引擎 | Hasura | PostGraphile | 已有团队深度 PostgreSQL 函数驱动实践且无需订阅增强时 | Hasura 对实时订阅和权限模型更直接 |
|
| GraphQL 引擎 | 暂不纳入核心路径 | Hasura / PostGraphile | 面向运营终端的字段选择和订阅编排复杂度上升时 | 查询接口与事件骨干分离 |
|
||||||
| 工作流引擎 | Temporal | Airflow | 主要需求转为离线批任务编排时 | AODB 更偏在线长事务与补偿 |
|
| 工作流引擎 | 暂不纳入 MVP | Temporal | 人工复核和补偿流程演进为复杂长事务时 | MVP 先用应用服务内状态机 |
|
||||||
| 服务网格 | Linkerd | Istio | 多集群高级流量治理和复杂策略显著增加时 | 中型机场先以轻量可运维为优先 |
|
| 服务网格 | 暂不纳入 MVP | Linkerd / Istio | 服务间零信任、mTLS 和流量治理要求增强时 | 中型机场首期不引入服务网格 |
|
||||||
| 移动端策略 | PWA | React Native | 必须深度离线和原生硬件能力时 | PWA 可降低交付复杂度和维护成本 |
|
| 流处理引擎 | 暂不纳入 MVP | Flink | 预测 / CEP / 大规模乱序处理成为上线前提时 | 首期不以预测能力为闭环前提 |
|
||||||
|
| 规则引擎 | 代码化规则 + 版本化配置 | Drools | 规则规模和运营配置频率显著增长时 | 降低首期认知与运维成本 |
|
||||||
|
|
||||||
## 4. 分层选型理由（精要）
|
## 4. 分层选型理由（精要）
|
||||||
|
|
||||||
### 4.1 数据层
|
### 4.1 数据层
|
||||||
|
|
||||||
- PostgreSQL + TimescaleDB 统一 SQL 体验，降低多数据库运维复杂度。
|
- PostgreSQL + TimescaleDB 统一 SQL 体验，降低多数据库运维复杂度。
|
||||||
- Redis 负责热点读和实时态缓存，减轻主库读取压力。
|
- Redis 负责热点读、去重辅助和临时缓存，减轻主库读取压力。
|
||||||
- OpenSearch 负责检索和日志分析，不承载强一致事务。
|
- 首期不引入搜索引擎，避免为非关键路径增加一套额外状态系统。
|
||||||
|
|
||||||
### 4.2 消息与计算层
|
### 4.2 消息与处理层
|
||||||
|
|
||||||
- Kafka 作为唯一事件骨干，保障事件可回放与可追溯。
|
- Kafka 作为唯一事件骨干，保障事件可回放与可追溯。
|
||||||
- Flink 承担里程碑计算、异常检测和实时指标聚合。
|
- 首期不引入 Flink，先聚焦标准化、裁决、发布事实和资源冲突闭环。
|
||||||
- Temporal 承担长流程编排（例如异常补偿和人工复核闭环）。
|
- 首期规则逻辑采用应用内代码化实现，并以版本化配置和回放测试约束演进。
|
||||||
|
|
||||||
### 4.3 集成与接口层
|
### 4.3 集成与接口层
|
||||||
|
|
||||||
- Camel 统一协议适配，减少自研连接器维护成本。
|
- Camel 统一协议适配，减少自研连接器维护成本。
|
||||||
- Kong 提供统一北向入口及治理能力。
|
- Kong 提供统一北向入口及治理能力。
|
||||||
- Hasura 提供面向运营终端的订阅能力，降低 API 开发负担。
|
- 查询接口和事件订阅接口分离，避免将查询层误用为事实事件骨干。
|
||||||
|
|
||||||
### 4.4 安全与基础设施层
|
### 4.4 安全与基础设施层
|
||||||
|
|
||||||
- Keycloak 提供统一身份与授权管理。
|
- Keycloak 提供统一身份与授权管理。
|
||||||
- Linkerd 提供轻量服务间 mTLS 与可观测能力。
|
|
||||||
- Kubernetes + Helm 提供标准化部署与环境一致性。
|
- Kubernetes + Helm 提供标准化部署与环境一致性。
|
||||||
|
- 可观测性先聚焦指标、日志和告警，链路追踪和服务网格在服务规模扩大后再引入。
|
||||||
|
|
||||||
## 5. 风险与缓解
|
## 5. 风险与缓解
|
||||||
|
|
||||||
| 风险 | 影响 | 缓解措施 |
|
| 风险 | 影响 | 缓解措施 |
|
||||||
| ------------------------ | ------------------ | -------------------------------------------- |
|
| --- | --- | --- |
|
||||||
| Kafka/Flink 运维门槛高 | 实施初期效率下降 | 提供标准化模板、最小可运行拓扑和 SRE Runbook |
|
| Kafka 运维门槛高 | 实施初期效率下降 | 提供最小可运行拓扑、标准化 Topic 规划和 SRE Runbook |
|
||||||
| 多协议接入数据质量不稳定 | 里程碑计算误差 | 建立标准化校验、死信队列和人工复核流程 |
|
| 多协议接入数据质量不稳定 | 里程碑发布事实误差 | 建立标准化校验、死信队列和人工复核流程 |
|
||||||
| 规则引擎规则膨胀 | 告警误报或漏报 | 规则分层管理、灰度发布和回放测试 |
|
| 规则逻辑散落在服务代码 | 规则可维护性下降 | 统一规则目录、版本化配置和回放测试 |
|
||||||
|
| 未来再引入 Flink / Temporal 成本上升 | 迁移复杂度提升 | 通过事件契约、聚合边界和 ADR 先锁死演进接口 |
|
||||||
| 文档与实现偏离 | 评审通过后落地失真 | 将关键决策同步为 ADR 并纳入变更流程 |
|
| 文档与实现偏离 | 评审通过后落地失真 | 将关键决策同步为 ADR 并纳入变更流程 |
|
||||||
|
|
||||||
## 6. 版本与升级策略
|
## 6. 版本与升级策略
|
||||||
@@ -86,5 +96,6 @@
|
|||||||
|
|
||||||
## 7. 与架构文档的边界
|
## 7. 与架构文档的边界
|
||||||
|
|
||||||
- 本文档回答“选什么、为什么选、何时切备选”。
|
- 本文档回答“首期选什么、为什么选、何时启用后续组件”。
|
||||||
- 具体数据模型、事件契约、流程编排细节在 `开源机场运营数据库（AODB）高层设计文档.md` 中定义。
|
- 具体数据模型、事件契约、流程编排细节在 `开源机场运营数据库（AODB）高层设计文档.md` 中定义。
|
||||||
|
- 本文档不替代 ADR；关键决策以 `airport-wiki/concepts/aodb/adr/` 下文件为准。
|
||||||
|
|||||||
@@ -1,448 +1,515 @@
|
|||||||
# 开源机场运营数据库（AODB）初步高层设计
|
# 开源机场运营数据库（AODB）高层设计文档
|
||||||
|
|
||||||
## 1. 目标
|
## 1. 目标
|
||||||
|
|
||||||
本设计给出 AODB 的初步高层方案，重点回答三件事：
|
本设计给出 AODB 的首期可开工高层方案，重点回答六件事：
|
||||||
|
|
||||||
1. 系统由哪些核心模块组成。
|
1. 首期上线到底做什么、不做什么。
|
||||||
2. 关键业务数据如何流转。
|
2. 系统由哪些核心聚合和服务组成。
|
||||||
3. 首期上线应覆盖哪些能力。
|
3. 关键业务数据如何在“观测、裁决、发布事实”之间流转。
|
||||||
|
4. 资源分配、冲突、告警和人工复核如何闭环。
|
||||||
|
5. 对外查询与事件订阅如何解耦。
|
||||||
|
6. SLO 与部署、容灾和审计如何对齐。
|
||||||
|
|
||||||
适用范围：年旅客吞吐量 500 万至 3000 万机场。
|
适用范围：年旅客吞吐量 500 万至 3000 万机场，单机场优先。
|
||||||
|
|
||||||
## 2. 设计原则
|
## 2. 设计原则
|
||||||
|
|
||||||
- 单一事实源（SSOT）：航班与资源状态统一归口到 AODB。
|
- 单一事实源：AODB 对外只发布单一当前权威事实，不暴露“谁最后写入”式伪一致。
|
||||||
- 事件驱动：状态变化通过事件广播，减少系统耦合。
|
- 事实分层：原始观测、裁决记录、发布事实必须分层建模。
|
||||||
- 标准优先：优先兼容 AIDX、SSIM、AFTN/SITA。
|
- 事件驱动：状态变化通过事件传播，系统间通过契约解耦。
|
||||||
- 渐进建设：先实现核心闭环，再扩展高级能力。
|
- 规则可解释：字段权威、冲突裁决、人工覆盖都必须能解释来源和原因。
|
||||||
|
- 渐进建设：先做稳定闭环，再引入预测、CEP 和复杂编排能力。
|
||||||
|
|
||||||
## 3. 总体架构
|
## 3. 范围与阶段
|
||||||
|
|
||||||
### 3.1 架构分层
|
### 3.1 MVP 范围
|
||||||
|
|
||||||
| 层级 | 主要能力 | 代表组件 |
|
首期上线只覆盖以下闭环：
|
||||||
| ------------ | ---------------------------------------- | ------------------------------------------------------------------ |
|
|
||||||
| 接入层 | 外部系统接入、协议解析、统一北向入口 | Kong Gateway、Apache Camel、SSIM 导入器 |
|
|
||||||
| 业务层 | 航班管理、资源分配、里程碑管理、告警处理 | Flight Service、Resource Service、Milestone Service、Alert Service |
|
|
||||||
| 事件与计算层 | 事件总线、流处理与预测、规则判定与编排 | Kafka、Flink、Drools、Temporal |
|
|
||||||
| 数据层 | 事务存储、时序存储、缓存、检索 | PostgreSQL、TimescaleDB、Redis、OpenSearch |
|
|
||||||
| 平台层 | 身份认证、部署运行、观测与服务治理 | Keycloak、Kubernetes、Prometheus/Grafana、Jaeger、Loki、Linkerd |
|
|
||||||
|
|
||||||
### 3.2 核心模块职责
|
- 航班计划导入与实时状态更新
|
||||||
|
- 航班配对与过站上下文最小建模
|
||||||
|
- 基础资源分配（Stand、Gate、Belt、Counter）
|
||||||
|
- 关键里程碑跟踪与发布事实治理
|
||||||
|
- 延误、资源冲突和数据质量告警
|
||||||
|
- 对外查询接口与事件订阅
|
||||||
|
- 审计、人工裁决、重放与复核闭环
|
||||||
|
|
||||||
- Flight Service：维护航班计划、动态状态和历史记录。
|
### 3.2 非 MVP 范围
|
||||||
- Resource Service：进行机位/登机口/行李转盘/值机柜台等资源分配与冲突检查，支持人工覆盖与审计。
|
|
||||||
- Milestone Service：维护 A-CDM 关键里程碑时间点。
|
|
||||||
- Alert Service：统一处理延误、冲突等运营告警。
|
|
||||||
- ACISP 接口层：向航司、地服、AOC 提供查询与订阅能力。
|
|
||||||
|
|
||||||
### 3.3 核心实体标识约定（最小集）
|
|
||||||
|
|
||||||
- Flight：`carrier + flight_number + op_date + leg_no` 作为业务唯一标识。
|
|
||||||
- Milestone：`flight_id + milestone_type + source + event_time` 作为幂等写入键。
|
|
||||||
- ResourceAssignment：`resource_type + resource_id + time_window + flight_id` 作为分配唯一键。
|
|
||||||
|
|
||||||
### 3.4 权威边界（SSOT）与写入治理（MVP）
|
|
||||||
|
|
||||||
为实现“单一事实源（SSOT）”，AODB 必须对外明确两类信息：
|
|
||||||
|
|
||||||
1. **状态事实（Fact）**：AODB 对外提供的“当前状态”是唯一权威输出。
|
|
||||||
2. **来源与裁决（Provenance）**：每个关键状态字段必须可追溯其来源、可信度与裁决过程。
|
|
||||||
|
|
||||||
#### 3.4.1 状态写入三元信息（最小要求）
|
|
||||||
|
|
||||||
所有关键状态写入（航班动态、里程碑、资源分配、告警）必须携带以下最小三元信息并持久化：
|
|
||||||
|
|
||||||
- `source`：来源系统/组织（如 ANSP/航司/地服/机场运行/人工裁决），并可扩展到具体系统标识。
|
|
||||||
- `confidence`：可信度等级（建议：`confirmed`/`estimated`/`reported`/`suspect`），用于表示数据质量与可用性。
|
|
||||||
- `decision`：裁决信息（可为空）。若发生冲突或人工覆盖，必须记录：裁决人/系统、裁决原因、裁决时间与裁决依据。
|
|
||||||
|
|
||||||
#### 3.4.2 权威边界与冲突裁决原则（MVP）
|
|
||||||
|
|
||||||
为避免“多系统同写同字段”导致不可控冲突，MVP 采用以下治理原则：
|
|
||||||
|
|
||||||
- **分层权威**：以“字段/里程碑”为粒度定义权威优先级（不同字段可不同）。例如：
|
|
||||||
- **到离港实际时间类（如 ALDT）**：优先 ANSP/机场运行权威源，其次航司上报，最后为人工裁决。
|
|
||||||
- **协同计划时间类（如 TOBT）**：优先航司/地服协同上报，其次机场运行，最后为人工裁决。
|
|
||||||
- **资源分配类（机位/登机口/行李转盘/值机柜台）**：优先机场运行系统计算与人工调度，外部源仅作为建议输入。
|
|
||||||
- **可信度优先**：在同等来源优先级下，`confidence` 更高者覆盖更低者。
|
|
||||||
- **更正优先**：当上游明确发送“更正/撤销”语义（或带更高版本号/序列号）时，允许对既有事实进行修正，但必须保留历史与审计轨迹。
|
|
||||||
- **不可判定进入旁路**：无法自动裁决的冲突必须进入“人工复核队列”，同时对外输出“冲突标记/数据质量标记”，避免静默覆盖。
|
|
||||||
|
|
||||||
#### 3.4.3 审计与可追溯要求（MVP）
|
|
||||||
|
|
||||||
- **审计覆盖范围**：
|
|
||||||
- 航班关键状态字段的变更（计划/预计/实际时间、关键里程碑状态）
|
|
||||||
- 资源分配变更（分配/释放/人工覆盖/回滚）
|
|
||||||
- 告警生命周期变更（触发/确认/关闭/抑制）
|
|
||||||
- **审计最小字段**：`who/what/when/why`（操作者或系统、变更字段、变更前后值、时间、原因/关联事件）。
|
|
||||||
- **对外可见性**：对外查询接口必须能返回“当前值 + source/confidence + 最近一次裁决摘要”，以便订阅方正确解读数据质量。
|
|
||||||
|
|
||||||
### 3.5 核心实体与关系（ER 概念级，MVP）
|
|
||||||
|
|
||||||
本节定义 AODB 的最小“可落地”概念模型，用于约束后续数据字典与接口契约的一致性。
|
|
||||||
|
|
||||||
- Flight：航班在指定运行日（op_date）的运行对象，包含计划/预计/实际时间与当前态字段集合。
|
|
||||||
- Milestone：A-CDM 里程碑事件记录（含来源、可信度、审计信息），与 Flight 关联。
|
|
||||||
- Resource：资源主数据，MVP 覆盖：
|
|
||||||
- Stand（机位）、Gate（登机口）、Belt（行李转盘）、Counter（值机柜台）
|
|
||||||
- ResourceAssignment：资源占用/分配记录（含时间窗口、分配来源、是否人工覆盖），与 Flight 与 Resource 关联。
|
|
||||||
- Alert：告警实体（延误/冲突/超阈值），含生命周期（触发、确认、关闭、抑制）与处置轨迹。
|
|
||||||
- DataQualityFlag（可选但建议纳入 MVP）：对“冲突/不可判定/低可信度”等数据质量问题的结构化标记，便于对外呈现与内部对账。
|
|
||||||
|
|
||||||
实体关系（概念级）：
|
|
||||||
|
|
||||||
- 一个 Flight 对应多个 Milestone（1:N）。
|
|
||||||
- 一个 Flight 在同一时间窗口内可占用多个资源（例如 Stand + Gate + Belt + Counter），每类资源对应多个 ResourceAssignment（1:N）。
|
|
||||||
- 一个 Resource 在时间轴上对应多个 ResourceAssignment（1:N），但同一资源的占用窗口不得重叠（冲突即告警）。
|
|
||||||
- Alert 可关联到 Flight，亦可关联到具体 Resource/ResourceAssignment（N:1）。
|
|
||||||
|
|
||||||
#### 3.5.1 主键与唯一性约束（高层口径）
|
|
||||||
|
|
||||||
- Flight：建议区分
|
|
||||||
- `flight_key`（业务唯一键）：`carrier + flight_number + op_date + leg_no`
|
|
||||||
- `flight_id`（系统主键）：内部生成的不可变 ID（推荐 UUID/雪花 ID）。
|
|
||||||
- Resource：`resource_type + resource_code`（或 `resource_id`）唯一。
|
|
||||||
- ResourceAssignment：同一 `resource_type + resource_id` 的 `time_window` 不允许重叠；若发生则必须产生冲突告警并进入人工/规则裁决。
|
|
||||||
|
|
||||||
### 3.6 Flight 状态模型（最小状态机，MVP）
|
|
||||||
|
|
||||||
为支撑“当前态查询”和“事件订阅”，AODB 对 Flight 的当前态至少需要统一以下字段口径：
|
|
||||||
|
|
||||||
- 时间类：计划（Scheduled）、预计（Estimated）、实际（Actual）三组时间；MVP 强制覆盖里程碑相关时间（如 EOBT/TOBT/TSAT/ALDT/EIBT）。
|
|
||||||
- 资源类：当前生效的 Stand/Gate/Belt/Counter 分配（可为空），并能追溯来源与覆盖原因。
|
|
||||||
- 质量类：是否存在冲突/待裁决标记（可由 DataQualityFlag/Alert 汇总而来）。
|
|
||||||
|
|
||||||
最小状态机（示意，非穷尽）：
|
|
||||||
|
|
||||||
- Planned：已导入计划但无运行动态。
|
|
||||||
- Active：已接收运行动态/里程碑并持续更新。
|
|
||||||
- Completed：已到达关键收敛里程碑（例如到位/关舱等）并可进入归档策略。
|
|
||||||
- Cancelled：取消/无效（保留审计与历史，避免硬删除）。
|
|
||||||
|
|
||||||
状态迁移原则：
|
|
||||||
|
|
||||||
- 状态迁移由“里程碑事实”驱动，不直接由单个外部系统声明。
|
|
||||||
- 若存在冲突或裁决，状态不回滚到更早阶段，但可产生“更正事件/裁决事件”并更新当前态字段，同时保留历史。
|
|
||||||
|
|
||||||
### 3.7 历史、快照与可追溯（MVP）
|
|
||||||
|
|
||||||
为兼顾实时查询与审计追溯，MVP 推荐采用以下高层模式：
|
|
||||||
|
|
||||||
- CurrentState（可变）：保存 Flight/Resource 的当前态，用于低延迟查询与看板展示。
|
|
||||||
- EventLog（追加）：保存标准化后的业务事件与关键变更（MilestoneUpserted、ResourceAssigned、AlertRaised 等），用于回放、对账与审计。
|
|
||||||
|
|
||||||
要求：
|
|
||||||
|
|
||||||
- CurrentState 的任何关键字段变更都必须能在 EventLog 中找到对应的原因事件（或裁决事件）。
|
|
||||||
- 对外“历史回放”能力通过 EventLog/时间范围过滤实现；不要求首期提供全量任意时点快照，但必须支持“关键链路回放与审计抽样”。
|
|
||||||
|
|
||||||
### 3.8 计算、规则与工作流职责边界（Flink / Drools / Temporal，MVP）
|
|
||||||
|
|
||||||
为对齐“实时计算引擎为 MVP”以及可追溯与可审计要求，MVP 对计算/规则/编排做明确分工：
|
|
||||||
|
|
||||||
- Flink（流处理/实时计算）：
|
|
||||||
- 里程碑派生与聚合（例如从多源事件推导统一里程碑视图）。
|
|
||||||
- 预测类计算的在线聚合与发布（EIBT/EXIT/EXOT 等的估计值生成/更新）。
|
|
||||||
- 复杂事件检测（CEP）：异常模式识别与实时指标聚合。
|
|
||||||
- Drools（规则判定/可配置/可追溯）：
|
|
||||||
- 延误/冲突/阈值告警规则与资源分配约束校验规则。
|
|
||||||
- 规则版本管理与灰度：规则变更必须可回放验证，避免误报/漏报。
|
|
||||||
- 规则执行结果必须可追溯（输出触发条件、命中规则、输入快照摘要）。
|
|
||||||
- Temporal（工作流编排/长事务/补偿）：
|
|
||||||
- DLQ/人工复核闭环：解析失败→任务分派→复核结果→重放/裁决事件输出。
|
|
||||||
- 跨系统补偿流程：当外部源延迟/更正导致状态回补时，编排补偿与通知。
|
|
||||||
- 关键处置流程：告警处置、资源冲突裁决的状态流转与审计留存。
|
|
||||||
|
|
||||||
验收口径（与 6.4 对齐）：
|
|
||||||
|
|
||||||
- 对任一预测/告警/裁决结果，能够通过事件链路回放解释“数据从哪来、规则如何命中、流程如何流转”。
|
|
||||||
|
|
||||||
## 4. 关键数据流（初版）
|
|
||||||
|
|
||||||
### 4.1 航班计划导入流
|
|
||||||
|
|
||||||
1. 外部系统提交 SSIM/AIDX 数据。
|
|
||||||
2. 接入层完成解析与标准化。
|
|
||||||
3. Flight Service 写入 AODB 主库。
|
|
||||||
4. 业务层发布航班状态事件给订阅方。
|
|
||||||
|
|
||||||
### 4.2 运行态更新流
|
|
||||||
|
|
||||||
1. 空管/航司发送运行动态（如 ALDT、TOBT）。
|
|
||||||
2. Milestone Service 更新关键节点。
|
|
||||||
3. Resource Service 根据最新状态重算资源占用。
|
|
||||||
4. Alert Service 在冲突或延误时触发通知。
|
|
||||||
|
|
||||||
### 4.3 事件一致性与异常处理约束
|
|
||||||
|
|
||||||
#### 4.3.1 事件类型清单（MVP，建议最小集）
|
|
||||||
|
|
||||||
- FlightImported：航班计划已导入并标准化。
|
|
||||||
- FlightUpdated：航班关键字段（计划/预计/实际/取消等）发生变更。
|
|
||||||
- MilestoneUpserted：里程碑写入/更正（含来源、可信度与裁决）。
|
|
||||||
- ResourceAssigned：资源已分配（Stand/Gate/Belt/Counter）。
|
|
||||||
- ResourceUnassigned：资源已释放/撤销分配。
|
|
||||||
- ResourceConflictDetected：资源占用冲突被检测到（需人工/规则裁决）。
|
|
||||||
- AlertRaised：告警触发（延误/冲突/超阈值）。
|
|
||||||
- AlertAcknowledged：告警已确认（进入处置中）。
|
|
||||||
- AlertCleared：告警已关闭或解除。
|
|
||||||
- DataQualityFlagged：产生数据质量标记（冲突、不可判定、低可信度等）。
|
|
||||||
- ManualDecisionRecorded：人工裁决已记录（覆盖原因与证据）。
|
|
||||||
|
|
||||||
#### 4.3.2 事件最小字段（Envelope）
|
|
||||||
|
|
||||||
所有业务事件必须具备统一事件信封，确保可追溯、可回放、可演进：
|
|
||||||
|
|
||||||
- `event_id`：全局唯一 ID（用于去重与审计）。
|
|
||||||
- `event_type`：事件类型（见 4.3.1）。
|
|
||||||
- `schema_version`：事件 schema 版本（向后兼容为原则）。
|
|
||||||
- `occurred_at`：业务发生时间（来自上游或由系统推断）。
|
|
||||||
- `produced_at`：AODB 产生该事件的时间。
|
|
||||||
- `source`：来源（与 3.4 一致）。
|
|
||||||
- `idempotency_key`：幂等键（见 4.3.3）。
|
|
||||||
- `correlation_id`：关联 ID（用于串联同一业务链路，如同一条 AFTN 报文/同一次导入批次）。
|
|
||||||
- `flight_id`：关联航班（若适用）。
|
|
||||||
- `payload`：事件负载（各事件类型自定义）。
|
|
||||||
|
|
||||||
#### 4.3.3 幂等与更正语义（MVP）
|
|
||||||
|
|
||||||
1. 所有写入事件必须携带 `idempotency_key`，重复事件不得产生重复副作用（至少做到 at-least-once 输入下的“结果幂等”）。
|
|
||||||
2. 幂等键的生成原则：尽量使用上游“不可变消息标识/序列号”（如报文 ID、批次+行号），避免仅用 `event_time` 作为幂等锚点。
|
|
||||||
3. 更正（Correction）必须显式：
|
|
||||||
- 若上游具备更正/撤销语义，则映射为 `MilestoneUpserted`（含更正标记或更高序列），同时保留旧值审计。
|
|
||||||
- 若上游无更正语义，则 AODB 只能通过“裁决事件（ManualDecisionRecorded）”修正当前态，并保留冲突与裁决轨迹。
|
|
||||||
|
|
||||||
#### 4.3.4 顺序保证边界与乱序处理（MVP）
|
|
||||||
|
|
||||||
1. 顺序保证以 `flight_id` 为最小粒度：同一 `flight_id` 的事件按分区键落到同一顺序通道（例如 Kafka 分区），确保消费端可按序处理。
|
|
||||||
2. 同一 `flight_id` 内部的处理顺序以 `occurred_at` 优先，其次以 `source_sequence`（若上游提供）或 AODB 生成的 `ingest_sequence` 作为并列消歧。
|
|
||||||
3. 过旧/乱序事件处理策略：
|
|
||||||
- 允许在可配置“乱序窗口”内重排；超窗事件进入旁路审计并生成 DataQualityFlag。
|
|
||||||
- 不允许静默覆盖已确认事实；需触发冲突标记或进入人工复核。
|
|
||||||
|
|
||||||
#### 4.3.5 写库与发事件一致性（Outbox/CDC，高层约束）
|
|
||||||
|
|
||||||
为避免“写库成功但没发事件/发了事件但没落库”的不可审计空洞，MVP 必须采用可验证的一致性策略之一：
|
|
||||||
|
|
||||||
- 主选：**Outbox Pattern + CDC**
|
|
||||||
- 业务服务在同一数据库事务内：更新 CurrentState，并写入 Outbox 表。
|
|
||||||
- CDC/发布器将 Outbox 可靠发布到 Kafka，并在成功后标记已发布。
|
|
||||||
- 约束：
|
|
||||||
- 事件发布必须可重试；失败不得丢失，且必须可回放。
|
|
||||||
- 对外订阅以 Kafka 事件为事实流（或由 Kafka 驱动 Hasura 订阅层的投影），避免多路源头。
|
|
||||||
|
|
||||||
#### 4.3.6 解析失败、DLQ 与人工复核闭环（MVP）
|
|
||||||
|
|
||||||
1. 解析失败或校验失败消息进入 DLQ，并生成“人工复核任务”（可由工作流编排系统承接）。
|
|
||||||
2. 人工复核结果必须形成结构化输出：要么生成可重放的标准化事件，要么生成裁决事件（ManualDecisionRecorded）。
|
|
||||||
|
|
||||||
#### 4.3.7 一致性口径（对齐需求）
|
|
||||||
|
|
||||||
- 关键实体（Flight 当前态、ResourceAssignment 生效集、Alert 生命周期）在同一服务内采用强一致事务写入。
|
|
||||||
- 跨服务/跨投影（例如检索、订阅投影、指标聚合）采用最终一致，目标：**最终一致收敛 <= 30 秒**。
|
|
||||||
- 验收方式：对账任务 + 抽检回放，必须能解释每一次不一致的根因（延迟、乱序、裁决、外部源缺陷等）。
|
|
||||||
|
|
||||||
#### 4.3.8 降级策略（MVP）
|
|
||||||
|
|
||||||
外部源异常抖动时启用降级策略：保留最近可信状态并标记数据可信度；对外订阅必须包含数据质量标记，避免下游误用。
|
|
||||||
|
|
||||||
### 4.4 资源分配规则（MVP）
|
|
||||||
|
|
||||||
MVP 资源管理覆盖：Stand（机位）、Gate（登机口）、Belt（行李转盘）、Counter（值机柜台）。资源分配的目标不是“全局最优”，而是保证冲突可检测、可裁决、可追溯，并能支撑秒级传播与对外可解释。
|
|
||||||
|
|
||||||
#### 4.4.1 时间窗口（time_window）口径
|
|
||||||
|
|
||||||
- **分配窗口组成**：`[start_time, end_time] + buffer_before + buffer_after`。
|
|
||||||
- **锚点选择（MVP）**：
|
|
||||||
- Stand：以 `ALDT/EIBT`（到达侧）与 `AOBT/ATOT`（离港侧）相关里程碑推导占用区间；若缺失则回退到 Estimated。
|
|
||||||
- Gate：以旅客流程相关里程碑（如登机开始/结束、关舱/推出）推导；缺失时回退到 TOBT/TSAT 近似。
|
|
||||||
- Belt：以 `AIBT/EIBT` 起算，结合航班机型/行李量经验参数给出默认占用时长（可配置）。
|
|
||||||
- Counter：以航班计划起飞前固定窗口（如 T-3h 至 T-45min）为默认规则（可配置并可按航司差异化）。
|
|
||||||
- **滑动更新**：当关键里程碑变更（延误、提前、取消、更正）时，ResourceAssignment 必须重算窗口并触发冲突检测。
|
|
||||||
|
|
||||||
#### 4.4.2 冲突定义与缓冲策略
|
|
||||||
|
|
||||||
- **冲突定义**：同一 `resource_type + resource_id` 的生效占用窗口发生重叠即为冲突。
|
|
||||||
- **缓冲策略**：缓冲时间为规则参数（按资源类型/机场策略配置）。缓冲引入的冲突必须可解释（在告警中记录触发原因）。
|
|
||||||
|
|
||||||
#### 4.4.3 分配优先级与人工覆盖
|
|
||||||
|
|
||||||
MVP 采用“规则优先 + 人工可覆盖”的策略：
|
|
||||||
|
|
||||||
- 自动分配/调整由规则或简单启发式完成（不做全局优化），输出 ResourceAssigned/Unassigned 事件。
|
|
||||||
- 人工覆盖（override）必须：
|
|
||||||
- 记录 `decision`（原因/证据/操作者）并产生 ManualDecisionRecorded。
|
|
||||||
- 可回滚（回滚同样写审计）。
|
|
||||||
|
|
||||||
#### 4.4.4 与航班变更联动（延误/取消/换机型）
|
|
||||||
|
|
||||||
- 延误：窗口整体右移或重新估算，先“保持原资源”并检测后续冲突；若冲突不可自动消解则触发 ResourceConflictDetected + AlertRaised。
|
|
||||||
- 取消：释放资源并触发 ResourceUnassigned；若取消为更正则需保留历史并标记更正原因。
|
|
||||||
- 换机型/机位限制变化：触发资源适配性校验，不满足则产生冲突并进入裁决流程。
|
|
||||||
|
|
||||||
#### 4.4.5 输出与审计（最小要求）
|
|
||||||
|
|
||||||
- 任何资源变更都必须能回答：谁分配的（规则/人工）、为什么分配、影响了哪些航班、是否引发冲突告警。
|
|
||||||
|
|
||||||
## 5. 首期上线范围（MVP）
|
|
||||||
|
|
||||||
首期建议只覆盖以下最小闭环：
|
|
||||||
|
|
||||||
- 航班计划导入与实时状态更新。
|
|
||||||
- 基础资源分配（机位、登机口、行李转盘、值机柜台）。
|
|
||||||
- 关键里程碑跟踪（EOBT/TOBT/TSAT/ALDT/EIBT）。
|
|
||||||
- 延误与资源冲突告警。
|
|
||||||
- 对外查询接口与订阅推送（REST + GraphQL Subscription）。
|
|
||||||
|
|
||||||
不纳入首期：
|
不纳入首期：
|
||||||
|
|
||||||
- 复杂优化排班（全局优化模型）。
|
- 复杂优化排班（全局优化模型）
|
||||||
- 深度 AI 预测与自适应调度。
|
- 深度 AI 预测与自适应调度
|
||||||
- 多机场统一调度中心能力。
|
- Flink 驱动的复杂 CEP 和预测平台
|
||||||
|
- Temporal 驱动的复杂长事务工作流平台
|
||||||
|
- 多机场统一调度中心能力
|
||||||
|
|
||||||
### 5.1 上线门禁（Go/No-Go）
|
### 3.3 分阶段演进
|
||||||
|
|
||||||
- 功能门禁：航班导入、里程碑更新、资源分配、冲突告警链路可端到端演示。
|
- Phase 1：完成 MVP 闭环并上线单机场。
|
||||||
- 性能门禁：在峰值吞吐与订阅并发条件下，端到端事件延迟达到最低可接受值（见 6.1/6.4/6.5 的压测口径）。
|
- Phase 2：引入预测能力、复杂规则平台和补偿编排能力。
|
||||||
- 数据门禁：核心实体对账通过率 >= 99.9%，无高危不一致项。
|
- Phase 3：增强容量、容灾和多机场扩展。
|
||||||
- 安全门禁：统一认证鉴权生效，关键接口通过授权与审计检查。
|
|
||||||
- 演练门禁：完成容灾恢复与回滚演练，RTO/RPO 达到最低可接受值并留存记录。
|
|
||||||
|
|
||||||
### 5.2 关键场景走读（MVP）
|
## 4. 总体架构
|
||||||
|
|
||||||
本节用于评审阶段快速验证“闭环是否成立、可追溯是否可用、异常是否可处置”。
|
### 4.1 架构分层
|
||||||
|
|
||||||
#### 场景 1：SSIM 导入 → 标准化 → 发布 → 订阅
|
| 层级 | 主要能力 | 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 |
|
||||||
|
|
||||||
1. SSIM 导入进入接入层（解析/校验/标准化）。
|
### 4.2 领域划分与聚合边界
|
||||||
2. Flight Service 在事务内写 CurrentState + Outbox。
|
|
||||||
3. CDC/发布器将 Outbox 事件发布到 Kafka（FlightImported/FlightUpdated）。
|
|
||||||
4. Hasura/订阅层向终端/外部系统推送订阅事件或提供查询读。
|
|
||||||
|
|
||||||
验收点：重复导入不产生重复副作用；订阅可重连补偿；可追溯到导入批次与来源。
|
为避免多服务共同修改同一业务对象，MVP 采用以下聚合边界：
|
||||||
|
|
||||||
#### 场景 2：多源里程碑冲突（以 ALDT 为例）→ 裁决 → 审计 → 对外呈现
|
| 聚合 | 职责 | 主键 | 写主 | 发布事件 | 只读依赖 |
|
||||||
|
| --- | --- | --- | --- | --- | --- |
|
||||||
|
| FlightOperation | 航班当前权威态、运行状态、发布事实 | `flight_id` | Flight Operation Service | `FlightUpdated`、`PublishedFactUpdated` | Turnaround、MilestoneObservation、ResourceAllocation |
|
||||||
|
| MilestoneObservation | 里程碑原始观测、标准化观测、候选事实 | `observation_id` | Milestone Service | `MilestoneObserved`、`MilestoneNormalized` | FlightOperation |
|
||||||
|
| Turnaround | 到达航班、离港航班、飞机周转上下文 | `turnaround_id` | Flight Operation Service | `TurnaroundLinked`、`TurnaroundCorrected` | FlightOperation |
|
||||||
|
| ResourceAllocation | 资源占用、锁定、冲突、覆盖 | `allocation_id` | Resource Service | `ResourceAssigned`、`ResourceUnassigned`、`ResourceConflictDetected` | FlightOperation、Turnaround |
|
||||||
|
| AlertCase | 告警和处置对象 | `alert_id` | Alert Service | `AlertRaised`、`AlertAcknowledged`、`AlertCleared` | FlightOperation、ResourceAllocation |
|
||||||
|
|
||||||
1. 两个来源上报同一航班 ALDT，发生冲突（source/confidence/序列不一致）。
|
边界约束：
|
||||||
2. 系统按 3.4 裁决原则尝试自动裁决；不可判定则产生 DataQualityFlagged + 进入人工复核。
|
|
||||||
3. 人工复核通过工作流记录 ManualDecisionRecorded，更新当前态并保留历史。
|
|
||||||
4. 对外查询返回“当前值 + source/confidence + 裁决摘要”；订阅推送裁决事件。
|
|
||||||
|
|
||||||
验收点：冲突不静默覆盖；审计可还原变更前后与原因；最终一致收敛 <= 30 秒。
|
- Flight 当前权威态只能由 `Flight Operation Service` 写入。
|
||||||
|
- Milestone Service 负责观测和候选事实，不直接改写 Flight 当前态。
|
||||||
|
- Resource Service 只拥有资源占用与冲突事实，不直接修改 Flight 当前态中的非资源字段。
|
||||||
|
- Alert Service 不产生业务事实，只管理处置状态和告警生命周期。
|
||||||
|
|
||||||
#### 场景 3：延误导致资源冲突（以 Stand 为例）→ 告警 → 覆盖/回滚
|
### 4.3 核心服务职责
|
||||||
|
|
||||||
1. 延误触发 ResourceAssignment 窗口右移，检测到同机位窗口重叠。
|
- `Flight Operation Service`
|
||||||
2. 产生 ResourceConflictDetected + AlertRaised；规则可给出建议（可选）。
|
- 管理 FlightOperation 当前态。
|
||||||
3. 调度人工覆盖资源分配（记录 decision），触发 ResourceAssigned + ManualDecisionRecorded。
|
- 维护 Published Fact。
|
||||||
4. 如需回滚，回滚同样形成事件与审计。
|
- 负责 Turnaround 建模和关联修正。
|
||||||
|
- `Milestone Service`
|
||||||
|
- 接收外部运行动态。
|
||||||
|
- 解析、标准化并形成 MilestoneObservation。
|
||||||
|
- 依据字段权威矩阵给出候选事实。
|
||||||
|
- `Resource Service`
|
||||||
|
- 管理资源主数据和资源分配。
|
||||||
|
- 进行适配校验、冲突检测、人工覆盖和回滚。
|
||||||
|
- `Alert Service`
|
||||||
|
- 管理告警、确认、关闭、抑制和处置轨迹。
|
||||||
|
- `External API Service`
|
||||||
|
- 提供查询接口。
|
||||||
|
- 提供事件订阅接口或订阅分发适配层。
|
||||||
|
- 不作为权威事实生成者。
|
||||||
|
|
||||||
验收点：冲突检测可解释；覆盖/回滚全链路可追溯；订阅方能收到变更并理解可信度。
|
## 5. 核心模型
|
||||||
|
|
||||||
## 6. 非功能目标（初步）
|
### 5.1 核心标识约定
|
||||||
|
|
||||||
- 可用性：支持 7x24 运行。
|
- Flight：
|
||||||
- 实时性：核心状态更新达到秒级可见。
|
- `flight_key`：`carrier + flight_number + op_date + leg_no`
|
||||||
- 可追溯：关键状态变化具备审计记录。
|
- `flight_id`：内部不可变主键
|
||||||
- 安全性：统一认证鉴权与最小权限控制。
|
- Turnaround：
|
||||||
|
- `turnaround_id`
|
||||||
|
- 可关联一个到达航班和一个离港航班
|
||||||
|
- MilestoneObservation：
|
||||||
|
- `observation_id`
|
||||||
|
- 幂等键优先使用上游报文 ID、序列号或批次 + 行号
|
||||||
|
- Resource：
|
||||||
|
- `resource_id`
|
||||||
|
- `resource_type + resource_code` 唯一
|
||||||
|
- ResourceAllocation：
|
||||||
|
- `allocation_id`
|
||||||
|
- 幂等键由 `resource_id + validity_window + assignment_source + correlation_id` 组合约束
|
||||||
|
|
||||||
### 6.2 对外接口（MVP 合同口径）
|
### 5.2 核心实体与关系
|
||||||
|
|
||||||
MVP 对外提供“查询 + 订阅”两类能力，并明确北向治理边界：
|
- FlightOperation：指定运行日上的航班运行对象，包含当前发布事实和状态摘要。
|
||||||
|
- Turnaround：将到达航班、离港航班和飞机周转上下文关联起来，用于资源和时序联动。
|
||||||
|
- MilestoneObservation：里程碑观测记录，保留原始来源、标准化结果和候选事实。
|
||||||
|
- Resource：资源主数据，MVP 覆盖 Stand、Gate、Belt、Counter。
|
||||||
|
- ResourceAllocation：资源分配记录，含有效窗口、锁定类型、来源和覆盖原因。
|
||||||
|
- AlertCase：告警对象，关联 FlightOperation 或 ResourceAllocation。
|
||||||
|
- DataQualityFlag：对冲突、低可信度、超窗乱序、待裁决等问题做结构化标记。
|
||||||
|
|
||||||
- **北向入口**：统一经 API Gateway（Kong）进入，执行认证鉴权、限流、审计与路由治理。
|
关系约束：
|
||||||
- **接口形态**：
|
|
||||||
- REST：面向外部系统的标准查询与批量拉取。
|
|
||||||
- GraphQL（Hasura）：面向运营终端与需要实时订阅的消费者，提供订阅与细粒度字段选择。
|
|
||||||
|
|
||||||
#### 6.2.1 查询（Query）最小约束
|
- 一个 FlightOperation 对应多个 MilestoneObservation。
|
||||||
|
- 一个 Turnaround 可关联一个到达航班和一个离港航班，也允许只有单侧航班待补全。
|
||||||
|
- 一个 Resource 在时间轴上可关联多个 ResourceAllocation，但硬冲突不允许同时生效。
|
||||||
|
- AlertCase 可关联具体 FlightOperation、Turnaround 或 ResourceAllocation。
|
||||||
|
|
||||||
- 核心查询对象：Flight（当前态）、Milestone（明细/时间序列）、ResourceAssignment（生效集）、Alert（生命周期）。
|
### 5.3 FlightOperation 最小字段组
|
||||||
- 过滤维度：`op_date`、`flight_key/flight_id`、状态（Planned/Active/Completed/Cancelled）、资源类型与资源编号。
|
|
||||||
- 分页与一致性：必须支持稳定分页（cursor/offset 任选其一作为主选并写清），并能返回“数据版本/更新时间”以支持下游对账。
|
|
||||||
- 数据质量：关键字段必须返回 `source/confidence`，存在冲突时必须返回“冲突标记/待裁决标记”。
|
|
||||||
|
|
||||||
#### 6.2.2 订阅（Subscription）最小约束
|
- 主键：`flight_id`、`flight_key`
|
||||||
|
- 属性：`carrier`、`flight_number`、`op_date`、`leg_no`、`direction`
|
||||||
|
- 机体上下文：`aircraft_type`、`tail_number`（可空）
|
||||||
|
- 状态：`flight_status`
|
||||||
|
- 发布事实：计划 / 预计 / 实际时间类字段
|
||||||
|
- 当前资源摘要：Stand / Gate / Belt / Counter
|
||||||
|
- 质量摘要：冲突标记、待裁决标记、最近裁决摘要
|
||||||
|
- 关联：`turnaround_id`（可空）
|
||||||
|
|
||||||
- 订阅源：以 AODB 标准化业务事件为事实流（见 4.3 事件契约）。
|
### 5.4 Turnaround 最小字段组
|
||||||
- 订阅粒度：按 `event_type` 与 `flight_id/op_date` 过滤；支持“关键事件流”订阅（只推 Flight/Milestone/Resource/Alert 的变更摘要）。
|
|
||||||
- 可靠性：至少提供 at-least-once 投递语义；订阅必须支持断线重连与补偿（基于 `event_id` 或可回放游标）。
|
|
||||||
- 限流与隔离：对外订阅连接数、推送速率、单租户资源上限必须可配置并可观测。
|
|
||||||
|
|
||||||
#### 6.2.3 鉴权、限流与审计（Kong 治理边界）
|
- `turnaround_id`
|
||||||
|
- `arrival_flight_id`
|
||||||
|
- `departure_flight_id`
|
||||||
|
- `tail_number`
|
||||||
|
- `aircraft_type`
|
||||||
|
- `turnaround_status`
|
||||||
|
- `link_source`
|
||||||
|
- `link_confidence`
|
||||||
|
|
||||||
- 鉴权：OIDC/OAuth2（Keycloak）为统一入口；按角色/Scope 控制 Flight/Resource/Alert 的读写与订阅权限。
|
约束：
|
||||||
- 限流：对“查询 QPS、订阅连接数、推送速率”分别限流，且需要能按租户/客户端维度配置。
|
|
||||||
- 审计：所有“写入类操作”（包含人工裁决、资源覆盖、告警处置）必须审计；对外查询/订阅的访问也需记录最小审计日志（用于追溯与合规）。
|
|
||||||
|
|
||||||
### 6.3 安全与合规（MVP）
|
- 配对可以晚于航班导入发生。
|
||||||
|
- 配对修正必须产生 `TurnaroundCorrected` 事件并保留审计。
|
||||||
|
- 若未知配对，FlightOperation 仍可独立运行，但资源和里程碑解释能力下降。
|
||||||
|
|
||||||
- 认证授权：OIDC/OAuth2 + RBAC（Keycloak），最小权限原则。
|
## 6. 事实分层模型
|
||||||
- 传输安全：北向 TLS；服务间建议启用 mTLS（与服务网格能力对齐）。
|
|
||||||
- 数据分级：至少区分“运营敏感字段”和“可共享字段”，并在接口层实现字段级权限控制（GraphQL 尤其需要明确）。
|
|
||||||
|
|
||||||
### 6.1 最小 SLO（评审口径）
|
### 6.1 三层模型
|
||||||
|
|
||||||
|
| 层 | 含义 | 是否可变 | 用途 |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| Observation | 上游原始或标准化观测 | 否 | 追溯、回放、取证 |
|
||||||
|
| Decision | 规则或人工裁决结果 | 否 | 解释为什么当前事实成立 |
|
||||||
|
| Published Fact | 当前对外权威事实 | 是 | 查询、订阅、共享 |
|
||||||
|
|
||||||
|
### 6.2 SSOT 定义
|
||||||
|
|
||||||
|
AODB 的 SSOT 不等于“数据库中的最后一次写入”，而是：
|
||||||
|
|
||||||
|
- 由 Observation 输入
|
||||||
|
- 经字段级权威矩阵与裁决逻辑处理
|
||||||
|
- 最终形成并发布的 Published Fact
|
||||||
|
|
||||||
|
### 6.3 状态写入三元信息
|
||||||
|
|
||||||
|
所有关键状态写入都必须附带：
|
||||||
|
|
||||||
|
- `source`
|
||||||
|
- `confidence`
|
||||||
|
- `decision`（可空）
|
||||||
|
|
||||||
|
其中：
|
||||||
|
|
||||||
|
- Observation 必须保存原始来源和原始时序。
|
||||||
|
- Decision 必须保存裁决者、依据、原因和裁决时间。
|
||||||
|
- Published Fact 必须能追溯到 Observation 和 Decision。
|
||||||
|
|
||||||
|
### 6.4 字段级权威矩阵（最小集）
|
||||||
|
|
||||||
|
| 字段 | 主来源 | 次来源 | 更正规则 | 人工覆盖 | 对外可见性 |
|
||||||
|
| --- | --- | --- | --- | --- | --- |
|
||||||
|
| ALDT | ANSP / 机场运行 | 航司 | 明确更正或高版本号优先 | 允许 | 返回当前值 + 来源 |
|
||||||
|
| AIBT | 地服 / 机场运行 | 航司 | 同上 | 允许 | 返回当前值 + 来源 |
|
||||||
|
| EIBT | 系统计算 | 运行动态派生 | 新计算覆盖旧计算并留历史 | 允许 | 返回当前值 + 可信度 |
|
||||||
|
| TOBT | 航司 / 地服 | 机场运行 | 最新有效更正优先 | 允许 | 返回当前值 + 裁决摘要 |
|
||||||
|
| TSAT | AODB / P1 PDS | 机场运行 | 新计算版本优先 | 允许 | 返回当前值 + 算法版本 |
|
||||||
|
| Stand Assignment | 机场运行系统 | 人工调度 | 人工覆盖优先并保留原因 | 必须审计 | 返回当前值 + 覆盖摘要 |
|
||||||
|
| Gate Assignment | 机场运行系统 | 人工调度 | 同上 | 必须审计 | 返回当前值 + 覆盖摘要 |
|
||||||
|
| Belt Assignment | 机场运行系统 | 人工调度 | 同上 | 必须审计 | 返回当前值 + 覆盖摘要 |
|
||||||
|
| Counter Assignment | 机场运行系统 | 人工调度 | 同上 | 必须审计 | 返回当前值 + 覆盖摘要 |
|
||||||
|
|
||||||
|
## 7. Flight 状态模型
|
||||||
|
|
||||||
|
### 7.1 最小状态机
|
||||||
|
|
||||||
|
- Planned：已导入计划但尚无有效运行动态。
|
||||||
|
- Active：已有运行动态、里程碑或资源变更。
|
||||||
|
- Completed：已达到收敛里程碑并进入归档策略。
|
||||||
|
- Cancelled：取消或无效，但保留完整历史。
|
||||||
|
|
||||||
|
### 7.2 状态迁移原则
|
||||||
|
|
||||||
|
- 状态迁移由 Published Fact 驱动，而不是由单个外部系统直接声明。
|
||||||
|
- 若存在冲突或裁决，不回滚 Observation 历史，只更新 Published Fact 和当前状态摘要。
|
||||||
|
- 状态修正必须能通过事件和审计链路回放。
|
||||||
|
|
||||||
|
## 8. 历史、审计与回放
|
||||||
|
|
||||||
|
### 8.1 数据存储视图
|
||||||
|
|
||||||
|
- `ObservationLog`
|
||||||
|
- 保存原始或标准化观测
|
||||||
|
- `DecisionLog`
|
||||||
|
- 保存规则命中和人工裁决
|
||||||
|
- `PublishedCurrentState`
|
||||||
|
- 保存当前对外权威事实
|
||||||
|
- `AuditTrail`
|
||||||
|
- 保存 `who / what / when / why`
|
||||||
|
|
||||||
|
### 8.2 基本约束
|
||||||
|
|
||||||
|
- PublishedCurrentState 的任何关键字段变更都必须能在 ObservationLog 和 DecisionLog 中找到原因链路。
|
||||||
|
- 人工覆盖不得改写原始 Observation，只能新增 Decision 并更新 Published Fact。
|
||||||
|
- 历史回放以事件和日志为准，不以任意时点快照为首期前提。
|
||||||
|
|
||||||
|
## 9. 资源模型与冲突治理
|
||||||
|
|
||||||
|
### 9.1 Resource 模型
|
||||||
|
|
||||||
|
每个 Resource 至少具备：
|
||||||
|
|
||||||
|
- `resource_id`
|
||||||
|
- `resource_type`
|
||||||
|
- `resource_code`
|
||||||
|
- `status`
|
||||||
|
- `capability_profile`
|
||||||
|
- `compatibility_constraints`
|
||||||
|
- `parent_resource_id`（可空）
|
||||||
|
- `operational_calendar`
|
||||||
|
|
||||||
|
### 9.2 ResourceAllocation 模型
|
||||||
|
|
||||||
|
每个 ResourceAllocation 至少具备：
|
||||||
|
|
||||||
|
- `allocation_id`
|
||||||
|
- `resource_id`
|
||||||
|
- `flight_id`
|
||||||
|
- `turnaround_id`（可空）
|
||||||
|
- `allocation_status`
|
||||||
|
- `assignment_source`
|
||||||
|
- `lock_type`（`soft` / `hard`）
|
||||||
|
- `validity_window`
|
||||||
|
- `override_reason`（可空）
|
||||||
|
- `derived_from_event`
|
||||||
|
- `conflict_flags`
|
||||||
|
|
||||||
|
### 9.3 冲突分类
|
||||||
|
|
||||||
|
| 冲突类型 | 说明 | 是否阻断 | 是否允许人工覆盖 |
|
||||||
|
| --- | --- | --- | --- |
|
||||||
|
| 时间冲突 | 占用时间窗重叠 | 是 | 是 |
|
||||||
|
| 适配冲突 | 机型、能力或运行属性不匹配 | 是 | 受限 |
|
||||||
|
| 状态冲突 | 资源停用、维护、冻结 | 是 | 否 |
|
||||||
|
| 策略冲突 | 本地策略或运营规则违反 | 视规则 | 是 |
|
||||||
|
|
||||||
|
### 9.4 四类资源规则口径
|
||||||
|
|
||||||
|
- Stand
|
||||||
|
- 关注机型适配、拖曳、到离港时间窗、过站联动。
|
||||||
|
- Gate
|
||||||
|
- 关注旅客流程时间窗、国际国内属性、步行距离和能力约束。
|
||||||
|
- Belt
|
||||||
|
- 关注到港时序、机型、行李量经验参数和恢复能力。
|
||||||
|
- Counter
|
||||||
|
- 关注值机开放窗口、航司差异化规则和共享柜台能力。
|
||||||
|
|
||||||
|
### 9.5 人工覆盖原则
|
||||||
|
|
||||||
|
- 自动分配只产生建议或默认分配。
|
||||||
|
- 人工覆盖必须记录原因、证据、操作者和影响范围。
|
||||||
|
- 回滚必须和覆盖一样事件化和审计化。
|
||||||
|
|
||||||
|
## 10. 事件模型与一致性
|
||||||
|
|
||||||
|
### 10.1 事件分类
|
||||||
|
|
||||||
|
| 事件类别 | 说明 | 示例 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| Domain Events | 聚合内部事实变化 | `FlightUpdated`、`ResourceAssigned` |
|
||||||
|
| Integration Events | 对外共享的标准化事件 | `PublishedFactUpdated`、`AlertRaised` |
|
||||||
|
| Audit Events | 审计和裁决事件 | `ManualDecisionRecorded` |
|
||||||
|
| Case Events | 人工复核和告警处置状态变化 | `ReviewTaskOpened`、`AlertAcknowledged` |
|
||||||
|
|
||||||
|
### 10.2 MVP 事件清单
|
||||||
|
|
||||||
|
- `FlightImported`
|
||||||
|
- `FlightUpdated`
|
||||||
|
- `TurnaroundLinked`
|
||||||
|
- `TurnaroundCorrected`
|
||||||
|
- `MilestoneObserved`
|
||||||
|
- `MilestoneNormalized`
|
||||||
|
- `PublishedFactUpdated`
|
||||||
|
- `ResourceAssigned`
|
||||||
|
- `ResourceUnassigned`
|
||||||
|
- `ResourceConflictDetected`
|
||||||
|
- `AlertRaised`
|
||||||
|
- `AlertAcknowledged`
|
||||||
|
- `AlertCleared`
|
||||||
|
- `DataQualityFlagged`
|
||||||
|
- `ManualDecisionRecorded`
|
||||||
|
- `ReviewTaskOpened`
|
||||||
|
- `ReviewTaskClosed`
|
||||||
|
|
||||||
|
### 10.3 事件归属表
|
||||||
|
|
||||||
|
| 事件 | 归属聚合 | 触发条件 | 是否对外发布 | 是否可回放 |
|
||||||
|
| --- | --- | --- | --- | --- |
|
||||||
|
| `MilestoneObserved` | MilestoneObservation | 收到有效运行动态 | 否 | 是 |
|
||||||
|
| `PublishedFactUpdated` | FlightOperation | 当前权威事实发生变化 | 是 | 是 |
|
||||||
|
| `ResourceAssigned` | ResourceAllocation | 资源分配生效 | 是 | 是 |
|
||||||
|
| `ResourceConflictDetected` | ResourceAllocation | 检测到冲突 | 是 | 是 |
|
||||||
|
| `ManualDecisionRecorded` | Decision / Audit | 人工裁决完成 | 是 | 是 |
|
||||||
|
| `AlertRaised` | AlertCase | 达到告警条件 | 是 | 是 |
|
||||||
|
|
||||||
|
### 10.4 统一事件信封
|
||||||
|
|
||||||
|
所有业务事件必须具备：
|
||||||
|
|
||||||
|
- `event_id`
|
||||||
|
- `event_type`
|
||||||
|
- `schema_version`
|
||||||
|
- `occurred_at`
|
||||||
|
- `produced_at`
|
||||||
|
- `source`
|
||||||
|
- `idempotency_key`
|
||||||
|
- `correlation_id`
|
||||||
|
- `aggregate_id`
|
||||||
|
- `payload`
|
||||||
|
|
||||||
|
### 10.5 幂等、顺序和更正语义
|
||||||
|
|
||||||
|
- 所有写入事件必须携带 `idempotency_key`。
|
||||||
|
- 顺序保证以 `flight_id` 为最小粒度。
|
||||||
|
- 更正必须显式表达，不允许静默覆盖已发布事实。
|
||||||
|
- 乱序允许在可配置窗口内重排，超窗进入审计旁路并打数据质量标记。
|
||||||
|
|
||||||
|
### 10.6 写库与发事件一致性
|
||||||
|
|
||||||
|
MVP 采用 `Outbox Pattern + CDC`：
|
||||||
|
|
||||||
|
- 业务服务在同一事务内更新 PublishedCurrentState 并写入 Outbox。
|
||||||
|
- CDC / 发布器将 Outbox 可靠发布到 Kafka。
|
||||||
|
- 发布失败必须可重试、可恢复、可审计。
|
||||||
|
|
||||||
|
## 11. 查询接口与事件订阅
|
||||||
|
|
||||||
|
### 11.1 接口分离原则
|
||||||
|
|
||||||
|
- 查询接口负责读取 Published Fact、历史明细和告警状态。
|
||||||
|
- 事件订阅负责分发标准化事件流。
|
||||||
|
- 查询接口不是事实流；订阅接口不承担读模型查询职责。
|
||||||
|
|
||||||
|
### 11.2 查询接口
|
||||||
|
|
||||||
|
最小查询对象：
|
||||||
|
|
||||||
|
- FlightOperation 当前态
|
||||||
|
- MilestoneObservation 明细
|
||||||
|
- ResourceAllocation 生效集
|
||||||
|
- AlertCase 生命周期
|
||||||
|
|
||||||
|
最小要求：
|
||||||
|
|
||||||
|
- 支持按 `op_date`、`flight_id / flight_key`、资源类型、状态过滤
|
||||||
|
- 返回更新时间和数据版本
|
||||||
|
- 关键字段返回 `source / confidence / decision summary`
|
||||||
|
|
||||||
|
### 11.3 事件订阅接口
|
||||||
|
|
||||||
|
最小要求：
|
||||||
|
|
||||||
|
- 按 `event_type`、`flight_id`、`op_date` 过滤
|
||||||
|
- 至少一次投递
|
||||||
|
- 支持断线重连和补偿
|
||||||
|
- 基于 `event_id` 或游标回放
|
||||||
|
- 支持租户隔离、连接数和推送速率限流
|
||||||
|
|
||||||
|
### 11.4 消费者契约
|
||||||
|
|
||||||
|
- 顺序仅保证到 `flight_id`
|
||||||
|
- 消费者必须按 `event_id` 去重
|
||||||
|
- 消费者必须处理数据质量标记和裁决摘要
|
||||||
|
- 回放窗口和游标语义必须文档化并纳入验收
|
||||||
|
|
||||||
|
## 12. 规则体系与人工复核
|
||||||
|
|
||||||
|
### 12.1 规则分类
|
||||||
|
|
||||||
|
- `authority rules`
|
||||||
|
- `validation rules`
|
||||||
|
- `conflict rules`
|
||||||
|
- `alert rules`
|
||||||
|
- `allocation heuristics`
|
||||||
|
|
||||||
|
### 12.2 规则最小模板
|
||||||
|
|
||||||
|
每条规则都必须定义：
|
||||||
|
|
||||||
|
- 输入
|
||||||
|
- 输出
|
||||||
|
- 优先级
|
||||||
|
- 命中条件
|
||||||
|
- 可解释字段
|
||||||
|
- 回放测试方式
|
||||||
|
|
||||||
|
### 12.3 人工复核对象
|
||||||
|
|
||||||
|
- 解析失败复核
|
||||||
|
- 里程碑冲突复核
|
||||||
|
- 资源冲突裁决
|
||||||
|
- 人工覆盖审批
|
||||||
|
|
||||||
|
### 12.4 Case 状态机
|
||||||
|
|
||||||
|
- `open`
|
||||||
|
- `assigned`
|
||||||
|
- `reviewing`
|
||||||
|
- `decided`
|
||||||
|
- `replayed`
|
||||||
|
- `closed`
|
||||||
|
|
||||||
|
原则：
|
||||||
|
|
||||||
|
- 所有人工动作都必须事件化。
|
||||||
|
- 所有人工动作都必须形成审计记录。
|
||||||
|
|
||||||
|
## 13. 非功能与部署
|
||||||
|
|
||||||
|
### 13.1 最小 SLO
|
||||||
|
|
||||||
| 指标 | 目标值 | 最低可接受值 |
|
| 指标 | 目标值 | 最低可接受值 |
|
||||||
| ------------ | ----------------------------- | ----------------------------- |
|
| --- | --- | --- |
|
||||||
| 可用性 | 月度 99.95% | 月度 99.9% |
|
| 可用性 | 月度 99.95% | 月度 99.9% |
|
||||||
| 事件处理延迟 | P95 <= 2 秒 | P95 <= 5 秒 |
|
| 事件处理延迟 | P95 <= 2 秒 | P95 <= 5 秒 |
|
||||||
| 容灾恢复 | RTO <= 30 分钟，RPO <= 5 分钟 | RTO <= 2 小时，RPO <= 15 分钟 |
|
| 容灾恢复 | RTO <= 30 分钟，RPO <= 5 分钟 | RTO <= 2 小时，RPO <= 15 分钟 |
|
||||||
| 审计覆盖率 | 100% 关键变更可追溯 | 99.9% 可追溯 |
|
| 审计覆盖率 | 100% 关键变更可追溯 | 99.9% 可追溯 |
|
||||||
|
|
||||||
### 6.4 验收与可观测口径（MVP）
|
### 13.2 最小部署拓扑
|
||||||
|
|
||||||
为确保 SLO 可被验证，MVP 至少需要定义并采集以下运行指标：
|
| 组件 | 部署方式 | 高可用方式 | 失败影响 | 恢复方式 |
|
||||||
|
| --- | --- | --- | --- | --- |
|
||||||
|
| PostgreSQL / TimescaleDB | Stateful 部署 | 主备切换 + 定时备份 | 当前态和审计写入受影响 | 备份恢复 + 故障切换 |
|
||||||
|
| Kafka | 多副本集群 | 副本和 ISR 保障 | 事件流中断或降级 | Broker 恢复 + 消费追赶 |
|
||||||
|
| CDC / 发布器 | 无状态服务 | 多副本 + 幂等发布 | Outbox 堆积 | 断点续传 + 重试 |
|
||||||
|
| API / 业务服务 | 无状态部署 | 多副本 | 查询或写入能力降级 | 滚动恢复 |
|
||||||
|
| Redis | 主从或哨兵 | 缓存级高可用 | 热点查询性能下降 | 重建缓存 |
|
||||||
|
|
||||||
- 事件端到端延迟：ingest → commit(CurrentState/Outbox) → publish(Kafka) → deliver(订阅端)（按 P95/P99 统计）。
|
### 13.3 关键容灾约束
|
||||||
- DLQ 率：解析失败/校验失败/旁路审计占比与趋势。
|
|
||||||
- 幂等命中率：重复事件去重命中比例（用于评估上游质量与系统健壮性）。
|
|
||||||
- 冲突率与 MTTR：资源冲突/里程碑冲突发生频率与平均处置时间。
|
|
||||||
- 订阅健康：订阅连接数、推送速率、订阅落后量（按租户/客户端）。
|
|
||||||
|
|
||||||
验收方式（与需求对齐）：
|
- PostgreSQL 必须具备 PITR 或等价恢复能力。
|
||||||
|
- Kafka 必须明确 `replication factor`、`min ISR`、保留窗口和重放策略。
|
||||||
|
- Outbox / CDC 必须具备断点恢复和重复投递幂等能力。
|
||||||
|
- 容灾演练必须覆盖数据库切换、事件堆积、订阅重连和回放。
|
||||||
|
|
||||||
- 压测：在峰值吞吐假设下验证 P95 延迟达标。
|
### 13.4 SLO 映射表
|
||||||
- 对账与抽检：验证强一致实体与最终一致收敛（<= 30 秒）的抽样结果可解释。
|
|
||||||
- 容灾演练：验证 RTO/RPO 达到最低可接受值并留存演练记录。
|
|
||||||
|
|
||||||
### 6.5 容量基线与伸缩策略（MVP 口径）
|
| SLO | 设计支撑 | 验收方式 |
|
||||||
|
| --- | --- | --- |
|
||||||
|
| 可用性 | 多副本 API、DB HA、Kafka 副本 | 演练和月度故障统计 |
|
||||||
|
| 延迟 | 单聚合写主、Kafka 事件骨干、缓存热点读 | 压测和生产观测 |
|
||||||
|
| RTO / RPO | DB 备份恢复、Kafka 重放、CDC 恢复 | 容灾演练 |
|
||||||
|
| 审计覆盖 | Observation / Decision / AuditTrail | 抽样链路回放 |
|
||||||
|
|
||||||
本节用于把“500 万至 3000 万吞吐机场”的范围，映射为可评审、可压测的容量假设（范围值即可，后续以压测修正）。
|
## 14. 上线门禁（Go / No-Go）
|
||||||
|
|
||||||
#### 6.5.1 容量假设（建议范围）
|
- 功能门禁：计划导入、动态接入、里程碑发布事实、资源分配、冲突告警、人工裁决链路可端到端演示。
|
||||||
|
- 数据门禁：核心实体对账通过率 >= 99.9%，无高危不一致项。
|
||||||
|
- 一致性门禁：Outbox / CDC、重放、幂等和断线补偿完成验证。
|
||||||
|
- 安全门禁：统一认证鉴权生效，关键接口通过授权与审计检查。
|
||||||
|
- 演练门禁：完成数据库恢复、事件重放和订阅补偿演练。
|
||||||
|
|
||||||
- 航班量：约 150–900 架次/日（按机场规模与航班结构波动）。
|
## 15. 文档边界与引用
|
||||||
- 事件密度：每航班 20–80 条关键事件（计划导入、动态更新、里程碑、资源变更、告警与裁决）。
|
|
||||||
- 峰值事件速率：10–200 events/s（含短时抖动与重放）。
|
|
||||||
- 订阅规模：10–500 并发订阅连接（运营终端、航司、地服、AOC 等），推送速率按租户限额。
|
|
||||||
|
|
||||||
#### 6.5.2 伸缩策略（高层约束）
|
- 本文档定义首期可开工的高层设计，不展开字段级数据字典和实现细节。
|
||||||
|
- 技术栈主选、后续启用条件以 `airport-wiki/concepts/aodb/开源技术栈选型决策.md` 为准。
|
||||||
- 事件骨干（Kafka）：按 `flight_id` 分区保证同航班顺序；通过增加分区与消费组并行度扩展吞吐。
|
|
||||||
- 流处理（Flink）：关键作业（预测/CEP/聚合）支持水平扩展；必须具备状态一致性与可恢复能力（与 RTO/RPO 对齐）。
|
|
||||||
- 事务库（PostgreSQL/TimescaleDB）：写路径优先保证强一致与审计；读路径通过缓存与只读副本（可选）缓解压力。
|
|
||||||
- 检索（OpenSearch）：仅承载检索/分析投影，不作为强一致事实源；索引延迟纳入最终一致指标。
|
|
||||||
|
|
||||||
#### 6.5.3 压测口径（最小）
|
|
||||||
|
|
||||||
- 压测必须覆盖：
|
|
||||||
- 峰值事件速率 + 乱序/重复输入（验证幂等与乱序策略）。
|
|
||||||
- 订阅并发 + 推送速率上限（验证网关限流与订阅补偿）。
|
|
||||||
- DLQ 率提升场景（验证人工复核闭环与系统降级）。
|
|
||||||
|
|
||||||
## 7. 迭代方向
|
|
||||||
|
|
||||||
Phase 1：完成 MVP 闭环并上线单机场。
|
|
||||||
|
|
||||||
Phase 2：补充预测能力和规则优化，提高运行效率。
|
|
||||||
|
|
||||||
Phase 3：增强容量与容灾，支持多机场扩展。
|
|
||||||
|
|
||||||
## 8. 文档边界与引用
|
|
||||||
|
|
||||||
- 本文档仅定义初步高层设计，不展开详细数据字典、接口字段级协议和部署参数。
|
|
||||||
- 技术栈主选、备选触发条件以 `airport-wiki/concepts/aodb/开源技术栈选型决策.md` 为准。
|
|
||||||
- 需求边界、验收基线以 `airport-wiki/concepts/aodb/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 为准。
|
||||||
|
|||||||
Reference in New Issue
Block a user