311 lines
9.5 KiB
Markdown
311 lines
9.5 KiB
Markdown
# 碰撞避免系统架构分析报告
|
||
|
||
**版本**: 3.0 | **更新日期**: 2024-12-20 | **基于需求**: requirements.md (2025-05-01)
|
||
|
||
> 📋 **更新说明**: 本版本基于3个月快速交付目标，简化架构设计，去除MongoDB采用MySQL单一数据库方案，专注核心业务功能的MVP实现。
|
||
|
||
本文档对当前碰撞避免系统的架构进行全面分析，识别设计问题、缺失模块，并提出改进建议。
|
||
|
||
## 🔍 **当前架构优势**
|
||
|
||
1. **模块化设计良好**：项目采用了清晰的分层架构，模块职责相对明确
|
||
2. **空间计算基础扎实**：JTS库和MySQL空间索引为地理查询提供强大支持
|
||
3. **配置管理完善**：支持YAML配置文件和属性绑定机制
|
||
4. **实时通信支持**：WebSocket实现了基本的实时数据推送
|
||
|
||
## 🎯 **3个月MVP目标**
|
||
|
||
基于业务需求和开发效率考虑，制定3个月快速交付计划：
|
||
|
||
**月度1**：基础信息管理 + 数据库重构
|
||
**月度2**：超速监控 + 电子围栏 + 基础告警
|
||
**月度3**：轨迹回放 + API完善 + 系统优化
|
||
|
||
## ⚠️ **架构设计问题**
|
||
|
||
### 1. **技术栈过于复杂**
|
||
|
||
**问题**：
|
||
- 同时使用Redis + MongoDB + 未来计划的PostgreSQL，技术栈过重
|
||
- JTS空间计算与数据库空间功能重复
|
||
- 过度工程化导致开发周期过长
|
||
|
||
**MVP简化方案**：
|
||
```yaml
|
||
# 简化的技术栈
|
||
数据存储: MySQL 8.0+（单一数据库解决方案）
|
||
缓存: Redis（仅用于实时数据缓存）
|
||
空间查询: MySQL原生空间函数（ST_Contains, ST_Distance等）
|
||
实时通信: WebSocket（保持现有实现）
|
||
```
|
||
|
||
### 2. **功能模块设计过于复杂**
|
||
|
||
**问题**：
|
||
- 过多的子模块和分层，增加开发复杂度
|
||
- 事件驱动、规则引擎等高级架构增加学习成本
|
||
- MVP阶段不需要如此复杂的架构设计
|
||
|
||
**MVP简化方案**：
|
||
```java
|
||
// 简化的模块结构（仅保留核心功能）
|
||
├── controller/ // 统一控制器层
|
||
├── service/ // 业务服务层（合并相关服务）
|
||
├── repository/ // 数据访问层
|
||
├── model/ // 数据模型
|
||
├── config/ // 配置管理
|
||
└── common/ // 通用工具类
|
||
```
|
||
|
||
## 🚫 **MVP核心功能缺失**
|
||
|
||
### 1. **基础信息管理模块**（第1个月实现）
|
||
|
||
**现状**：完全缺失车辆和驾驶员基础信息管理
|
||
|
||
**MVP实现**：
|
||
```java
|
||
// 简化的基础信息管理（避免过度设计）
|
||
management/
|
||
├── VehicleService.java // 车辆管理服务
|
||
├── DriverService.java // 驾驶员管理服务
|
||
├── VehicleRepository.java // 车辆数据访问
|
||
├── DriverRepository.java // 驾驶员数据访问
|
||
└── model/
|
||
├── Vehicle.java // 车辆实体
|
||
├── Driver.java // 驾驶员实体
|
||
└── VehicleDriver.java // 车辆-驾驶员关联
|
||
```
|
||
|
||
### 2. **超速监控模块**（第2个月实现）
|
||
|
||
**现状**：基础功能存在但需要增强为完整的超速监控系统
|
||
|
||
**MVP实现**：
|
||
```java
|
||
// 增强现有功能，简化实现
|
||
speeding/
|
||
├── SpeedMonitorService.java // 超速监控服务（增强现有）
|
||
├── SpeedLimitService.java // 限速管理服务
|
||
├── SpeedViolationRepository.java // 违章记录存储
|
||
└── model/
|
||
├── SpeedViolation.java // 超速违章记录
|
||
└── SpeedLimit.java // 限速配置
|
||
```
|
||
|
||
### 3. **电子围栏模块**（第2个月实现）
|
||
|
||
**现状**：areas模块存在但缺乏围栏监控功能
|
||
|
||
**MVP实现**：
|
||
```java
|
||
// 基于现有areas模块扩展（利用MySQL空间查询）
|
||
geofence/
|
||
├── GeofenceService.java // 围栏监控服务
|
||
├── ZoneViolationService.java // 违规检测服务
|
||
├── GeofenceRepository.java // 围栏数据访问
|
||
└── model/
|
||
├── GeofenceEvent.java // 围栏事件
|
||
└── ZoneViolation.java // 区域违规记录
|
||
```
|
||
|
||
### 4. **轨迹回放模块**（第3个月实现）
|
||
|
||
**现状**：完全缺失历史轨迹查询和回放功能
|
||
|
||
**MVP实现**：
|
||
```java
|
||
// 简化的轨迹回放（基于MySQL存储和查询）
|
||
trajectory/
|
||
├── TrajectoryService.java // 轨迹查询服务
|
||
├── TrajectoryReplayService.java // 轨迹回放服务
|
||
├── TrajectoryRepository.java // 轨迹数据访问（MySQL分区表）
|
||
└── model/
|
||
├── TrajectoryPoint.java // 轨迹点
|
||
└── TrajectoryQuery.java // 查询条件
|
||
```
|
||
|
||
### 5. **基础告警系统**（第2个月实现）
|
||
|
||
**现状**：缺乏统一的告警管理机制
|
||
|
||
**MVP实现**：
|
||
```java
|
||
// 简化的告警系统（基于WebSocket + 数据库）
|
||
alert/
|
||
├── AlertService.java // 告警服务
|
||
├── AlertRepository.java // 告警记录存储
|
||
└── model/
|
||
├── Alert.java // 告警实体
|
||
└── AlertType.java // 告警类型（枚举）
|
||
```
|
||
|
||
## 🔧 **技术实现简化**
|
||
|
||
### 1. **MySQL统一数据存储策略**
|
||
|
||
**简化方案**：
|
||
```yaml
|
||
# 统一的数据存储架构
|
||
MySQL 8.0+:
|
||
- 车辆和驾驶员基础信息
|
||
- 实时位置数据（近期数据，定期清理）
|
||
- 历史轨迹数据（分区表按时间分区）
|
||
- 告警记录和配置数据
|
||
- 空间数据（POINT, POLYGON类型）
|
||
|
||
Redis:
|
||
- 实时位置数据缓存（提高查询性能）
|
||
- WebSocket会话管理
|
||
- 临时计算结果缓存
|
||
|
||
移除: MongoDB（简化技术栈）
|
||
```
|
||
|
||
### 2. **空间查询简化实现**
|
||
|
||
**技术方案**：
|
||
```sql
|
||
-- 利用MySQL原生空间查询替代复杂的JTS计算
|
||
-- 点在多边形内查询
|
||
SELECT * FROM vehicles v
|
||
WHERE ST_Contains(
|
||
(SELECT boundary FROM airport_zones WHERE zone_id = ?),
|
||
POINT(v.longitude, v.latitude)
|
||
);
|
||
|
||
-- 距离查询
|
||
SELECT *, ST_Distance(POINT(longitude, latitude), POINT(?, ?)) as distance
|
||
FROM vehicles
|
||
WHERE ST_Distance_Sphere(POINT(longitude, latitude), POINT(?, ?)) < ?;
|
||
```
|
||
|
||
### 3. **数据验证简化**
|
||
|
||
**MVP方案**：
|
||
```java
|
||
// 基础数据验证（避免过度设计）
|
||
@Component
|
||
public class DataValidator {
|
||
public boolean validateLocation(Double lat, Double lng) {
|
||
return lat != null && lng != null &&
|
||
lat >= -90 && lat <= 90 && lng >= -180 && lng <= 180;
|
||
}
|
||
|
||
public boolean validateSpeed(Double speed) {
|
||
return speed != null && speed >= 0 && speed <= 200; // 机场内合理速度范围
|
||
}
|
||
}
|
||
```
|
||
|
||
## 📋 **3个月MVP开发计划**
|
||
|
||
### **第1个月：基础设施建设**
|
||
|
||
**Week 1-2: 数据库重构**
|
||
- 移除MongoDB配置，统一使用MySQL
|
||
- 设计核心数据表结构（车辆、驾驶员、位置、告警等）
|
||
- 配置MySQL空间索引和分区表
|
||
|
||
**Week 3-4: 基础信息管理**
|
||
- 实现车辆管理功能（CRUD操作）
|
||
- 实现驾驶员管理功能
|
||
- 完成基础API和数据验证
|
||
|
||
### **第2个月：核心监控功能**
|
||
|
||
**Week 5-6: 超速监控系统**
|
||
- 增强现有SpeedCalculationService
|
||
- 实现超速违章检测和记录
|
||
- 集成告警系统
|
||
|
||
**Week 7-8: 电子围栏功能**
|
||
- 基于MySQL空间查询实现围栏监控
|
||
- 实现区域进出检测
|
||
- 完成违规记录和告警
|
||
|
||
### **第3个月：数据分析和优化**
|
||
|
||
**Week 9-10: 轨迹回放功能**
|
||
- 实现历史轨迹查询（基于MySQL分区表）
|
||
- 开发轨迹回放API
|
||
- 前端轨迹可视化（简化版）
|
||
|
||
**Week 11-12: 系统优化和集成**
|
||
- API接口完善和文档
|
||
- 性能优化（索引、缓存）
|
||
- 系统测试和部署准备
|
||
|
||
## 🎯 **MVP架构路线图**
|
||
|
||
```mermaid
|
||
graph TD
|
||
A[当前架构] --> B[数据库重构MySQL]
|
||
B --> C[基础信息管理]
|
||
C --> D[超速监控]
|
||
D --> E[电子围栏]
|
||
E --> F[告警系统]
|
||
F --> G[轨迹回放]
|
||
G --> H[API完善]
|
||
H --> I[MVP完成]
|
||
|
||
style B fill:#ff6b6b
|
||
style C fill:#ff6b6b
|
||
style D fill:#4ecdc4
|
||
style E fill:#4ecdc4
|
||
style F fill:#4ecdc4
|
||
style G fill:#95e1d3
|
||
style H fill:#95e1d3
|
||
```
|
||
|
||
**时间线说明**：
|
||
- 🔴 月度1：数据库重构 + 基础信息管理
|
||
- 🟢 月度2：监控功能 + 告警系统
|
||
- 🟦 月度3：数据分析 + 系统优化
|
||
|
||
## 💡 **总结**
|
||
|
||
基于3个月快速交付目标，本架构分析提出了大幅简化的MVP方案：
|
||
|
||
### **关键简化决策**
|
||
|
||
1. **技术栈简化**：去除MongoDB，统一使用MySQL + Redis架构
|
||
- MySQL处理所有持久化数据存储和空间查询
|
||
- Redis仅作为实时数据缓存和会话管理
|
||
- 大幅降低技术复杂度和学习成本
|
||
|
||
2. **功能模块简化**：摒弃过度设计，专注核心业务价值
|
||
- 基础信息管理（车辆/驾驶员）
|
||
- 超速监控和电子围栏
|
||
- 基础告警和轨迹回放
|
||
- 避免复杂的规则引擎、事件架构等
|
||
|
||
3. **空间查询简化**：直接使用MySQL原生空间函数
|
||
- ST_Contains, ST_Distance等原生函数替代复杂JTS计算
|
||
- 性能满足需求，开发效率更高
|
||
|
||
### **MVP成功关键因素**
|
||
|
||
1. **技术选型务实**：选择团队熟悉、文档完善的技术栈
|
||
2. **需求聚焦**：专注最核心的业务价值，避免功能蔓延
|
||
3. **渐进式交付**：每月都有可演示的功能增量
|
||
4. **架构适度**：既不过度简陋，也不过度复杂
|
||
|
||
### **最终数据存储架构**
|
||
|
||
```yaml
|
||
# 简化统一的存储架构
|
||
MySQL 8.0+:
|
||
- 所有业务数据（车辆、驾驶员、轨迹、告警等）
|
||
- 空间数据存储和查询
|
||
- 历史数据分区管理
|
||
|
||
Redis:
|
||
- 实时位置数据缓存
|
||
- WebSocket会话缓存
|
||
- 计算结果临时缓存
|
||
|
||
移除: MongoDB（降低复杂度）
|
||
```
|
||
|
||
这种**极简化但不简陋**的架构设计，确保在3个月内交付实用的系统，同时为未来扩展保留了足够的架构弹性。 |