windyboy
6211605cdb
Capture a clear baseline across requirements, stack choices, and high-level architecture so review and implementation can align on scope and quality gates.
121 lines
5.4 KiB
Markdown
121 lines
5.4 KiB
Markdown
# 开源机场运营数据库（AODB）初步高层设计
|
||
|
||
## 1. 目标
|
||
|
||
本设计给出 AODB 的初步高层方案，重点回答三件事：
|
||
|
||
1. 系统由哪些核心模块组成。
|
||
2. 关键业务数据如何流转。
|
||
3. 首期上线应覆盖哪些能力。
|
||
|
||
适用范围：年旅客吞吐量 500 万至 3000 万机场。
|
||
|
||
## 2. 设计原则
|
||
|
||
- 单一事实源（SSOT）：航班与资源状态统一归口到 AODB。
|
||
- 事件驱动：状态变化通过事件广播，减少系统耦合。
|
||
- 标准优先：优先兼容 AIDX、SSIM、AFTN/SITA。
|
||
- 渐进建设：先实现核心闭环，再扩展高级能力。
|
||
|
||
## 3. 总体架构
|
||
|
||
### 3.1 架构分层
|
||
|
||
| 层级 | 主要能力 | 代表组件 |
|
||
| ------------ | ---------------------------------------- | ------------------------------------------------------------------ |
|
||
| 接入层 | 外部系统接入、协议解析、统一 API | API Gateway、协议适配器、SSIM 导入器 |
|
||
| 业务层 | 航班管理、资源分配、里程碑管理、告警处理 | Flight Service、Resource Service、Milestone Service、Alert Service |
|
||
| 事件与计算层 | 事件总线、规则计算、基础预测 | Kafka、规则引擎、轻量预测服务 |
|
||
| 数据层 | 事务存储、时序存储、缓存、检索 | PostgreSQL、TimescaleDB、Redis、OpenSearch |
|
||
| 平台层 | 身份认证、部署运行、监控告警 | Keycloak、Kubernetes、Prometheus/Grafana |
|
||
|
||
### 3.2 核心模块职责
|
||
|
||
- Flight Service：维护航班计划、动态状态和历史记录。
|
||
- 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` 作为分配唯一键。
|
||
|
||
## 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 事件一致性与异常处理约束
|
||
|
||
1. 所有写入事件必须携带 `idempotency_key`，重复事件只更新一次。
|
||
2. 同一 `flight_id` 的事件按 `event_time + version` 排序处理，过旧版本进入旁路审计。
|
||
3. 解析失败或校验失败消息进入 DLQ，并生成人工复核任务。
|
||
4. 外部源异常抖动时启用降级策略：保留最近可信状态并标记数据可信度。
|
||
|
||
## 5. 首期上线范围（MVP）
|
||
|
||
首期建议只覆盖以下最小闭环：
|
||
|
||
- 航班计划导入与实时状态更新。
|
||
- 基础资源分配（机位、登机口）。
|
||
- 关键里程碑跟踪（EOBT/TOBT/TSAT/ALDT/EIBT）。
|
||
- 延误与资源冲突告警。
|
||
- 对外查询接口与基础订阅推送。
|
||
|
||
不纳入首期：
|
||
|
||
- 复杂优化排班（全局优化模型）。
|
||
- 深度 AI 预测与自适应调度。
|
||
- 多机场统一调度中心能力。
|
||
|
||
### 5.1 上线门禁（Go/No-Go）
|
||
|
||
- 功能门禁：航班导入、里程碑更新、资源分配、冲突告警链路可端到端演示。
|
||
- 性能门禁：关键状态事件处理延迟达到最低可接受值。
|
||
- 数据门禁：核心实体对账通过率 >= 99.9%，无高危不一致项。
|
||
- 安全门禁：统一认证鉴权生效，关键接口通过授权与审计检查。
|
||
|
||
## 6. 非功能目标（初步）
|
||
|
||
- 可用性：支持 7x24 运行。
|
||
- 实时性：核心状态更新达到秒级可见。
|
||
- 可追溯：关键状态变化具备审计记录。
|
||
- 安全性：统一认证鉴权与最小权限控制。
|
||
|
||
### 6.1 最小 SLO（评审口径）
|
||
|
||
| 指标 | 目标值 | 最低可接受值 |
|
||
| ------------ | ----------------------------- | ----------------------------- |
|
||
| 可用性 | 月度 99.95% | 月度 99.9% |
|
||
| 事件处理延迟 | P95 <= 2 秒 | P95 <= 5 秒 |
|
||
| 容灾恢复 | RTO <= 30 分钟，RPO <= 5 分钟 | RTO <= 2 小时，RPO <= 15 分钟 |
|
||
| 审计覆盖率 | 100% 关键变更可追溯 | 99.9% 可追溯 |
|
||
|
||
## 7. 迭代方向
|
||
|
||
Phase 1：完成 MVP 闭环并上线单机场。
|
||
|
||
Phase 2：补充预测能力和规则优化，提高运行效率。
|
||
|
||
Phase 3：增强容量与容灾，支持多机场扩展。
|
||
|
||
## 8. 文档边界与引用
|
||
|
||
- 本文档仅定义初步高层设计，不展开详细数据字典、接口字段级协议和部署参数。
|
||
- 技术栈主选、备选触发条件以 `airport-wiki/concepts/aodb/开源技术栈选型决策.md` 为准。
|
||
- 需求边界、验收基线以 `airport-wiki/concepts/aodb/AODB 核心需求提炼.md` 为准。
|