# 技术方案架构设计执行手册

## 手册概览

| 项目 | 说明 |
|------|------|
| **适用场景** | 交通技术解决方案的架构设计——从需求理解到可落地的技术方案，覆盖智能交通管理平台、综合交通运行协调中心、车路协同、智慧高速、MaaS平台等典型交通系统 |
| **核心理念** | "业务驱动架构，架构服务业务"——交通技术架构的本质是为交通业务问题找到最优的技术表达 |
| **总周期** | 4-8周（含需求分析→架构设计→技术选型→方案撰写→评审） |
| **交付成果** | 需求分析文档、架构设计说明书、技术选型报告、实施计划、风险评估报告 |
| **设计团队** | 方案架构师1人 + 交通业务专家1人 + 技术域专家（数据/AI/安全/集成）按需 + 技术写作1人 |

---

## 第一阶段：需求理解与建模（第1-2周）

### 1.1 交通业务建模方法

交通技术方案的起点不是技术选型，而是对交通业务的深度理解。使用以下框架梳理业务需求：

**五层业务分析框架：**

| 层次 | 分析内容 | 输出 | 关键问题 |
|------|------|------|------|
| **用户层** | 出行者/运营者/管理者/维护者的痛点和期望 | 用户画像+用户旅程图 | 谁在用？痛点在哪？ |
| **场景层** | 具体交通场景（如"早高峰信号控制""ETC收费异常处理"） | 场景卡片(5-10个) | 什么场景？频率？后果？ |
| **流程层** | 端到端业务流程（如"事故检测→确认→派警→处置→恢复"） | 业务流程图 | 流程如何走？瓶颈在哪？ |
| **数据层** | 数据流/数据源/数据质量/数据标准 | 数据流图+数据字典 | 数据从哪来？到哪去？质量如何？ |
| **系统层** | 已有系统/接口/约束/迁移需求 | 系统上下文图 | 与什么系统交互？有什么约束？ |

### 1.2 从业务需求到技术需求的映射

| 业务需求 | 技术翻译 | 示例 |
|------|------|------|
| "管理者想实时看到全市交通态势" | 实时数据接入+大屏可视化+<500ms延迟 | 数据接入层Flink+OLAP引擎+WebGL渲染 |
| "信号配时员希望AI辅助配时" | 交通流预测模型+优化求解器+人机协同工作流 | 强化学习信控模型+方案推荐引擎+一键下发 |
| "公众希望手机查看实时公交位置" | 高并发查询API+位置缓存+GPS数据清洗 | Redis集群+位置服务微服务+公网API网关 |

---

## 第二阶段：架构设计（第3-5周）

### 2.1 架构设计四层法

#### 2.1.1 逻辑架构（做什么）

定义系统的功能模块划分和职责：

```
┌────────────────────────────────────────────┐
│             应用层 (Application)            │
│  信号控制 │ 事件管理 │ 诱导发布 │ 态势感知    │
├────────────────────────────────────────────┤
│             服务层 (Service)                │
│  数据接入 │ 流计算 │ AI推理 │ API Gateway  │
├────────────────────────────────────────────┤
│             数据层 (Data)                   │
│  实时库 │ 历史库 │ 数据湖 │ 缓存 │ 消息队列  │
├────────────────────────────────────────────┤
│          基础设施层 (Infrastructure)         │
│  计算 │ 存储 │ 网络 │ 安全 │ 容器编排       │
└────────────────────────────────────────────┘
```

**设计原则：**
- 层间单向依赖（上层依赖下层，下层不知上层）
- 每层内按业务域横向拆分（如应用层拆分信号控制/事件管理）
- 跨层共享组件下沉（如认证/日志/配置）

#### 2.1.2 物理架构（部署在哪）

定义系统的物理部署拓扑：

| 部署节点 | 部署内容 | 规模参考 | 关键约束 |
|------|------|------|------|
| 路侧边缘 | 感知融合/信号控制/事件检测 | 每路口1-2台MEC | 延迟<10ms/工业级环境 |
| 区域汇聚节点 | 路段协调/区域优化 | 每50-200路口1个节点 | 延迟<100ms |
| 中心云/IDC | 大数据分析/AI训练/管理平台 | 主备双活 | 可用性>99.9% |
| 灾备中心 | 数据备份/冷备应用 | 异地 | RPO<1小时/RTO<4小时 |

#### 2.1.3 数据架构（数据如何流转和存储）

```
数据源 → 数据接入(Kafka) → 流处理(Flink) → 实时库(Redis/ClickHouse)
                            ↓                    ↓
                        数据湖(Iceberg) → 离线数仓(StarRocks) → BI/报表
                            ↓
                        特征工程 → AI训练 → 模型服务
```

**数据分类策略：**

| 数据类型 | 存储引擎 | 保留周期 | 访问模式 |
|------|------|------|------|
| 实时感知数据（雷达/视频轨迹） | Kafka→Redis | 24小时 | 实时流+短窗口查询 |
| 业务状态数据（信号配时/诱导内容） | PostgreSQL | 永久 | OLTP读写 |
| 历史分析数据（日/周/月报表） | StarRocks/ClickHouse | 3年 | OLAP聚合查询 |
| 归档数据（合规留存） | 对象存储(Iceberg) | 10年+ | 低频批量查询 |

#### 2.1.4 安全架构（如何保护）

遵循SKILL.md第七部分"四横三纵"安全框架，重点设计：

1. **网络分段**：OT域(信号控制/感知)/IT域(管理平台/数据分析)/DMZ(对外服务)三层隔离
2. **身份认证**：统一身份认证(IAM)+多因素认证(MFA)+细粒度RBAC
3. **数据安全**：分类分级→脱敏引擎→动态数据脱敏→审计日志
4. **零信任**：微隔离+持续验证，尤其是OT/IT融合场景

### 2.2 交通系统关键架构决策

| 架构决策 | 轻量方案（小规模/单模态） | 标准方案（中等规模/多模态） | 旗舰方案（大规模/城市级） |
|------|------|------|------|
| **接入层** | REST API | API网关(Kong/APISIX) | API网关+服务网格(Istio) |
| **消息队列** | Redis Streams | Kafka | Pulsar(多租户) |
| **实时计算** | 应用内流处理 | Flink/Flink SQL | Flink+RisingWave |
| **数据库** | PostgreSQL | PostgreSQL+Redis+Elasticsearch | 多引擎(PostgreSQL+Redis+ES+StarRocks+Cassandra) |
| **容器编排** | Docker Compose | K3s | Kubernetes+Istiomesh |
| **监控运维** | Prometheus+Grafana | Prometheus+Loki+Tempo+Grafana | 统一可观测平台(SkyWalking) |

---

## 第三阶段：技术选型（第4-6周）

### 3.1 技术选型决策树

遵循以下原则排序选型优先级：

1. **业务适配优先**：选最能解决交通业务问题的，不是最"先进"的
2. **开放标准优先**：优先开放协议/开放API/开源项目，减少供应商锁定
3. **生态成熟度优先**：优先有活跃社区/丰富文档/充足人才的生态
4. **性能与成本平衡**：在满足性能要求的前提下选择TCO最优方案

### 3.2 关键选型对比模板

| 技术域 | 候选A | 候选B | 候选C | 推荐 | 推荐理由 |
|------|------|------|------|:---:|------|
| 消息队列 | Kafka | Pulsar | Redis Streams | | |
| 流计算 | Flink | Spark Streaming | RisingWave | | |
| OLAP引擎 | StarRocks | ClickHouse | Doris | | |
| 时序数据库 | TDengine | TimescaleDB | InfluxDB | | |
| 搜索引擎 | Elasticsearch | OpenSearch | Meilisearch | | |

### 3.3 供应商独立性与可替代性评估

| 组件 | 当前选择 | 锁定风险(1-5) | 迁移成本 | 替代方案 | 替代可行性 |
|------|------|:---:|------|------|:---:|
| [组件名] | [供应商/产品] | [评分] | [高/中/低] | [替代产品] | [评估] |

**核心原则**：对每个"5分锁定风险"的组件，必须有书面化的迁移方案和成本估算。

---

## 第四阶段：方案撰写与评审（第6-8周）

### 4.1 技术方案文档结构

一份完整的技术方案应包含：

```
1. 方案摘要（1页）
2. 业务理解与需求分析
3. 总体架构设计
   3.1 逻辑架构
   3.2 物理架构
   3.3 数据架构
   3.4 安全架构
4. 关键技术说明
   4.1 核心算法/模型说明
   4.2 关键技术选型理由
   4.3 技术创新点与差异化
5. 系统集成方案
6. 实施计划与资源需求
7. 运维方案与SLA
8. 风险评估与缓解
9. 参考案例
附录：技术规格书/接口规范/测试方案
```

### 4.2 架构评审检查清单

| 评审维度 | 检查项 | 通过标准 |
|------|------|------|
| **完整性** | 逻辑/物理/数据/安全四架构是否都有？ | 四项齐全且无重大缺失 |
| **一致性** | 逻辑架构的模块是否映射到物理架构的节点？ | 映射关系可追溯 |
| **可行性** | 是否有不切实际的设计（如单点瓶颈/过高复杂度）？ | 经2名以上架构师确认可行 |
| **可扩展性** | 业务量3倍增长是否需要架构重构？ | 3倍增长仅需水平扩容 |
| **安全性** | 安全设计能否通过安全评审？ | 满足对应等保级别要求 |
| **可运维性** | 监控/日志/告警/备份是否覆盖？ | 运维人员认可可运维性 |

### 4.3 常见架构设计反模式

| 反模式 | 表现 | 后果 | 纠正方法 |
|------|------|------|------|
| **过度设计** | 10个路口的项目设计了数据网格+事件溯源+Service Mesh | 实施成本翻倍/团队无法驾驭 | 根据规模选择架构复杂度（见2.2） |
| **大屏驱动设计** | 以"领导看什么"为架构决策依据 | 系统脆弱/数据不更新/沦为摆设 | 以业务流和数据流驱动架构，大屏是输出而非输入 |
| **技术堆砌** | 为用新技术而用新技术（如简单的CRUD上区块链） | 复杂度爆炸/可靠性下降 | 每个技术选型有明确理由和替代对比 |
| **供应商锁定设计** | 架构深度绑定单一供应商私有协议 | 升级困难/成本失控 | 接口标准化/数据可导出/定期竞争评估 |
| **幻灯片架构** | 只有漂亮架构图，无详细设计和接口定义 | 开发阶段架构推倒重来 | 架构设计必须下沉到接口和数据模型级别 |

---

> **本手册与SKILL.md的关系：** SKILL.md为知识参考（知道"是什么"），本手册为执行指南（知道"怎么做"）。架构设计时，参考SKILL.md第十部分的架构模式进行模式匹配，使用本手册的阶段流程进行系统化推进。
