102 lines
5.7 KiB
Markdown
102 lines
5.7 KiB
Markdown
# 开源技术栈选型决策
|
|
|
|
## 1. 决策目标与原则
|
|
|
|
本文档用于对 AODB 技术栈做唯一主选决策，避免多方案并列导致实施阶段反复。
|
|
|
|
决策原则：
|
|
|
|
1. 满足中型机场场景下的稳定性与可维护性。
|
|
2. 优先选择成熟开源生态和团队可落地能力。
|
|
3. 对核心路径采用单一主选，备选仅定义触发条件。
|
|
4. 支持私有化部署和后续多机场扩展。
|
|
5. 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/` 下文件为准。
|