开源技术栈选型决策
1. 决策目标与原则
本文档用于对 AODB 技术栈做唯一主选决策，避免多方案并列导致实施阶段反复。
决策原则：
- 满足中型机场场景下的稳定性与可维护性。
- 优先选择成熟开源生态和团队可落地能力。
- 对核心路径采用单一主选，备选仅定义触发条件。
- 支持私有化部署和后续多机场扩展。
- MVP 优先收敛复杂度，不以技术先进性替代交付确定性。
2. 技术栈总览
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. 关键决策与备选触发条件
| 决策项 |
主选 |
备选 |
触发备选条件 |
说明 |
| 搜索引擎 |
暂不纳入 MVP |
OpenSearch |
上线阶段需要全文检索、复杂筛选和日志联动检索时 |
MVP 不为未来检索需求预埋过重组件 |
| GraphQL 引擎 |
暂不纳入核心路径 |
Hasura / PostGraphile |
面向运营终端的字段选择和订阅编排复杂度上升时 |
查询接口与事件骨干分离 |
| 工作流引擎 |
暂不纳入 MVP |
Temporal |
人工复核和补偿流程演进为复杂长事务时 |
MVP 先用应用服务内状态机 |
| 服务网格 |
暂不纳入 MVP |
Linkerd / Istio |
服务间零信任、mTLS 和流量治理要求增强时 |
中型机场首期不引入服务网格 |
| 流处理引擎 |
暂不纳入 MVP |
Flink |
预测 / CEP / 大规模乱序处理成为上线前提时 |
首期不以预测能力为闭环前提 |
| 规则引擎 |
代码化规则 + 版本化配置 |
Drools |
规则规模和运营配置频率显著增长时 |
降低首期认知与运维成本 |
4. 分层选型理由（精要）
4.1 数据层
- PostgreSQL + TimescaleDB 统一 SQL 体验，降低多数据库运维复杂度。
- Redis 负责热点读、去重辅助和临时缓存，减轻主库读取压力。
- 首期不引入搜索引擎，避免为非关键路径增加一套额外状态系统。
4.2 消息与处理层
- Kafka 作为唯一事件骨干，保障事件可回放与可追溯。
- 首期不引入 Flink，先聚焦标准化、裁决、发布事实和资源冲突闭环。
- 首期规则逻辑采用应用内代码化实现，并以版本化配置和回放测试约束演进。
4.3 集成与接口层
- Camel 统一协议适配，减少自研连接器维护成本。
- Kong 提供统一北向入口及治理能力。
- 查询接口和事件订阅接口分离，避免将查询层误用为事实事件骨干。
4.4 安全与基础设施层
- Keycloak 提供统一身份与授权管理。
- Kubernetes + Helm 提供标准化部署与环境一致性。
- 可观测性先聚焦指标、日志和告警，链路追踪和服务网格在服务规模扩大后再引入。
5. 风险与缓解
| 风险 |
影响 |
缓解措施 |
| Kafka 运维门槛高 |
实施初期效率下降 |
提供最小可运行拓扑、标准化 Topic 规划和 SRE Runbook |
| 多协议接入数据质量不稳定 |
里程碑发布事实误差 |
建立标准化校验、死信队列和人工复核流程 |
| 规则逻辑散落在服务代码 |
规则可维护性下降 |
统一规则目录、版本化配置和回放测试 |
| 未来再引入 Flink / Temporal 成本上升 |
迁移复杂度提升 |
通过事件契约、聚合边界和 ADR 先锁死演进接口 |
| 文档与实现偏离 |
评审通过后落地失真 |
将关键决策同步为 ADR 并纳入变更流程 |
6. 版本与升级策略
- 技术栈版本采用“年度主版本评审 + 季度补丁更新”策略。
- 升级优先级：安全补丁 > 稳定性修复 > 新功能。
- 升级前必须完成回归测试、性能基线对比和回滚演练。
7. 与架构文档的边界
- 本文档回答“首期选什么、为什么选、何时启用后续组件”。
- 具体数据模型、事件契约、流程编排细节在
开源机场运营数据库（AODB）高层设计文档.md 中定义。
- 本文档不替代 ADR；关键决策以
airport-wiki/concepts/aodb/adr/ 下文件为准。
