refine aodb high-level design and planning docs
This commit is contained in:
windyboy
@@ -10,73 +10,83 @@
|
||||
2. 优先选择成熟开源生态和团队可落地能力。
|
||||
3. 对核心路径采用单一主选，备选仅定义触发条件。
|
||||
4. 支持私有化部署和后续多机场扩展。
|
||||
5. MVP 优先收敛复杂度，不以技术先进性替代交付确定性。
|
||||
|
||||
## 2. 技术栈总览（主选）
|
||||
## 2. 技术栈总览
|
||||
|
||||
| 分层 | 主选方案 | 说明 |
|
||||
| ------------ | ------------------------------------ | ---------------------------- |
|
||||
| 主数据存储 | PostgreSQL 16 | 关键业务数据强一致事务 |
|
||||
| 时序存储 | TimescaleDB | 里程碑与遥测时序数据 |
|
||||
| 缓存与实时态 | Redis 7 (Valkey) | 高频状态读取与短期流式缓存 |
|
||||
| 搜索分析 | OpenSearch 2.x | 全文检索、日志分析、开源友好 |
|
||||
| 事件总线 | Apache Kafka 3.x | 高吞吐与持久化事件骨干 |
|
||||
| 流处理 | Apache Flink 1.19 | 低延迟有状态流计算与 CEP |
|
||||
| 协议集成 | Apache Camel | AIDX/AFTN/SITA 协议适配 |
|
||||
| API 网关 | Kong Gateway OSS | 鉴权、限流、路由治理 |
|
||||
| GraphQL 层 | Hasura | 实时订阅与快速 API 暴露 |
|
||||
| 规则引擎 | Drools | 复杂规则可配置与可追溯 |
|
||||
| 工作流编排 | Temporal | 长事务与补偿流程编排 |
|
||||
| 认证授权 | Keycloak 24 | OIDC/OAuth2 与 RBAC |
|
||||
| 可观测性 | Prometheus + Grafana + Jaeger + Loki | 指标、追踪、日志统一观测 |
|
||||
| 容器平台 | Kubernetes + Helm | 标准化部署与扩缩容 |
|
||||
| 服务网格 | Linkerd | 轻量 mTLS 与服务治理 |
|
||||
| 对象存储 | MinIO | S3 兼容对象存储 |
|
||||
| 前端与终端 | React + TypeScript + PWA | 看板与移动访问统一前端栈 |
|
||||
### 2.1 MVP 主选
|
||||
|
||||
| 分层 | 主选方案 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| 主数据存储 | PostgreSQL 16 | 关键业务数据强一致事务 |
|
||||
| 时序存储 | TimescaleDB | 里程碑、观测与审计时间序列 |
|
||||
| 缓存与热点读 | Redis 7 (Valkey) | 高频读、短期缓存、去重辅助 |
|
||||
| 事件总线 | Apache Kafka 3.x | 统一事件骨干和可回放能力 |
|
||||
| 协议集成 | Apache Camel | AIDX / AFTN / SITA 协议适配 |
|
||||
| API 网关 | Kong Gateway OSS | 鉴权、限流、路由治理 |
|
||||
| 认证授权 | Keycloak 24 | OIDC / OAuth2 与 RBAC |
|
||||
| 可观测性 | Prometheus + Grafana + Loki | 指标、看板、日志观测 |
|
||||
| 容器平台 | Kubernetes + Helm | 标准化部署与环境一致性 |
|
||||
|
||||
### 2.2 后续启用组件
|
||||
|
||||
| 组件 | 定位 | 启用触发条件 | 当前决策 |
|
||||
| --- | --- | --- | --- |
|
||||
| Flink | 有状态流处理、预测、CEP | EIBT / EXIT / EXOT 预测进入上线范围，且简单流式处理无法满足延迟和可恢复性目标 | P1 |
|
||||
| Drools | 复杂规则平台 | 规则量、规则变更频率和回放需求超过代码化规则可维护边界 | P1 |
|
||||
| Temporal | 长流程编排与补偿 | 人工复核、跨系统补偿和状态机复杂度超出单服务事务编排能力 | P1 |
|
||||
| Hasura | 快速 GraphQL 查询与订阅暴露 | 前端字段裁剪、实时订阅和权限编排复杂度显著上升 | 可选 |
|
||||
| OpenSearch | 搜索与分析投影 | 全文检索、复杂检索、跨字段搜索成为上线能力 | P1 |
|
||||
| Linkerd | 服务间 mTLS 与服务治理 | 服务数量、零信任要求和多团队治理复杂度显著增加 | 可选 |
|
||||
| MinIO | 对象存储 | 需要保存批量导入文件、报文附件和复核证据对象 | 可选 |
|
||||
| React + TypeScript + PWA | 运营终端前端栈 | 本期建设自研终端而非只做系统接口时启用 | 可选 |
|
||||
|
||||
## 3. 关键决策与备选触发条件
|
||||
|
||||
| 决策项 | 主选 | 备选 | 触发备选条件 | 说明 |
|
||||
| ------------ | ---------- | ------------- | ---------------------------------------------------- | --------------------------------- |
|
||||
| 搜索引擎 | OpenSearch | Elasticsearch | 必须依赖特定商业插件时 | 优先开源许可证与成本可控 |
|
||||
| GraphQL 引擎 | Hasura | PostGraphile | 已有团队深度 PostgreSQL 函数驱动实践且无需订阅增强时 | Hasura 对实时订阅和权限模型更直接 |
|
||||
| 工作流引擎 | Temporal | Airflow | 主要需求转为离线批任务编排时 | AODB 更偏在线长事务与补偿 |
|
||||
| 服务网格 | Linkerd | Istio | 多集群高级流量治理和复杂策略显著增加时 | 中型机场先以轻量可运维为优先 |
|
||||
| 移动端策略 | PWA | React Native | 必须深度离线和原生硬件能力时 | PWA 可降低交付复杂度和维护成本 |
|
||||
| 决策项 | 主选 | 备选 | 触发备选条件 | 说明 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 搜索引擎 | 暂不纳入 MVP | OpenSearch | 上线阶段需要全文检索、复杂筛选和日志联动检索时 | MVP 不为未来检索需求预埋过重组件 |
|
||||
| GraphQL 引擎 | 暂不纳入核心路径 | Hasura / PostGraphile | 面向运营终端的字段选择和订阅编排复杂度上升时 | 查询接口与事件骨干分离 |
|
||||
| 工作流引擎 | 暂不纳入 MVP | Temporal | 人工复核和补偿流程演进为复杂长事务时 | MVP 先用应用服务内状态机 |
|
||||
| 服务网格 | 暂不纳入 MVP | Linkerd / Istio | 服务间零信任、mTLS 和流量治理要求增强时 | 中型机场首期不引入服务网格 |
|
||||
| 流处理引擎 | 暂不纳入 MVP | Flink | 预测 / CEP / 大规模乱序处理成为上线前提时 | 首期不以预测能力为闭环前提 |
|
||||
| 规则引擎 | 代码化规则 + 版本化配置 | Drools | 规则规模和运营配置频率显著增长时 | 降低首期认知与运维成本 |
|
||||
|
||||
## 4. 分层选型理由（精要）
|
||||
|
||||
### 4.1 数据层
|
||||
|
||||
- PostgreSQL + TimescaleDB 统一 SQL 体验，降低多数据库运维复杂度。
|
||||
- Redis 负责热点读和实时态缓存，减轻主库读取压力。
|
||||
- OpenSearch 负责检索和日志分析，不承载强一致事务。
|
||||
- Redis 负责热点读、去重辅助和临时缓存，减轻主库读取压力。
|
||||
- 首期不引入搜索引擎，避免为非关键路径增加一套额外状态系统。
|
||||
|
||||
### 4.2 消息与计算层
|
||||
### 4.2 消息与处理层
|
||||
|
||||
- Kafka 作为唯一事件骨干，保障事件可回放与可追溯。
|
||||
- Flink 承担里程碑计算、异常检测和实时指标聚合。
|
||||
- Temporal 承担长流程编排（例如异常补偿和人工复核闭环）。
|
||||
- 首期不引入 Flink，先聚焦标准化、裁决、发布事实和资源冲突闭环。
|
||||
- 首期规则逻辑采用应用内代码化实现，并以版本化配置和回放测试约束演进。
|
||||
|
||||
### 4.3 集成与接口层
|
||||
|
||||
- Camel 统一协议适配，减少自研连接器维护成本。
|
||||
- Kong 提供统一北向入口及治理能力。
|
||||
- Hasura 提供面向运营终端的订阅能力，降低 API 开发负担。
|
||||
- 查询接口和事件订阅接口分离，避免将查询层误用为事实事件骨干。
|
||||
|
||||
### 4.4 安全与基础设施层
|
||||
|
||||
- Keycloak 提供统一身份与授权管理。
|
||||
- Linkerd 提供轻量服务间 mTLS 与可观测能力。
|
||||
- Kubernetes + Helm 提供标准化部署与环境一致性。
|
||||
- 可观测性先聚焦指标、日志和告警，链路追踪和服务网格在服务规模扩大后再引入。
|
||||
|
||||
## 5. 风险与缓解
|
||||
|
||||
| 风险 | 影响 | 缓解措施 |
|
||||
| ------------------------ | ------------------ | -------------------------------------------- |
|
||||
| Kafka/Flink 运维门槛高 | 实施初期效率下降 | 提供标准化模板、最小可运行拓扑和 SRE Runbook |
|
||||
| 多协议接入数据质量不稳定 | 里程碑计算误差 | 建立标准化校验、死信队列和人工复核流程 |
|
||||
| 规则引擎规则膨胀 | 告警误报或漏报 | 规则分层管理、灰度发布和回放测试 |
|
||||
| 文档与实现偏离 | 评审通过后落地失真 | 将关键决策同步为 ADR 并纳入变更流程 |
|
||||
| 风险 | 影响 | 缓解措施 |
|
||||
| --- | --- | --- |
|
||||
| Kafka 运维门槛高 | 实施初期效率下降 | 提供最小可运行拓扑、标准化 Topic 规划和 SRE Runbook |
|
||||
| 多协议接入数据质量不稳定 | 里程碑发布事实误差 | 建立标准化校验、死信队列和人工复核流程 |
|
||||
| 规则逻辑散落在服务代码 | 规则可维护性下降 | 统一规则目录、版本化配置和回放测试 |
|
||||
| 未来再引入 Flink / Temporal 成本上升 | 迁移复杂度提升 | 通过事件契约、聚合边界和 ADR 先锁死演进接口 |
|
||||
| 文档与实现偏离 | 评审通过后落地失真 | 将关键决策同步为 ADR 并纳入变更流程 |
|
||||
|
||||
## 6. 版本与升级策略
|
||||
|
||||
@@ -86,5 +96,6 @@
|
||||
|
||||
## 7. 与架构文档的边界
|
||||
|
||||
- 本文档回答“选什么、为什么选、何时切备选”。
|
||||
- 本文档回答“首期选什么、为什么选、何时启用后续组件”。
|
||||
- 具体数据模型、事件契约、流程编排细节在 `开源机场运营数据库（AODB）高层设计文档.md` 中定义。
|
||||
- 本文档不替代 ADR；关键决策以 `airport-wiki/concepts/aodb/adr/` 下文件为准。
|
||||
|
||||
Reference in New Issue
Block a user