67 lines
4.3 KiB
Markdown
67 lines
4.3 KiB
Markdown
|
# 系统框架结构评估与优化建议
|
|||
|
|
|
|||
|
|
本文档基于 `d:\Trae_space\SmartEDT\README.md` 与实际代码结构，对已生成的 SmartEDT 系统框架（后端 Python 3.13.1 + FastAPI + TimescaleDB，前端 Electron + Vue）进行评估与分析，并提出优化改进点。
|
|||
|
|
|
|||
|
|
## 1. 总体评估
|
|||
|
|
|
|||
|
|
**结论**：系统框架整体架构合理，层次清晰，符合《系统开发技术方案.md》的要求，能够支撑后续功能开发。
|
|||
|
|
|
|||
|
|
**亮点**：
|
|||
|
|
- **架构分层清晰**：后端按 `api`（接口）、`services`（业务逻辑）、`database`（存储）、`device`（硬件抽象）分层，职责单一。
|
|||
|
|
- **技术选型落地准确**：Python 3.13.1 + FastAPI + WebSocket + PostgreSQL/TimescaleDB 组合落地，前端 Electron + Vue 多窗口方案已具雏形。
|
|||
|
|
- **工程化细节完备**：包含 `config.ini` 配置加载、Mock 设备实现、Docker 友好的环境变量覆盖、静态文件安全映射、以及自动化的数据库 Schema 初始化。
|
|||
|
|
- **扩展性良好**：`SimulationManager` 封装了仿真生命周期，`MockVehicleDevice` 提供了设备接入的模板，便于后续替换为真实硬件驱动。
|
|||
|
|
|
|||
|
|
## 2. 不足与改进建议
|
|||
|
|
|
|||
|
|
尽管骨架已跑通，但在高频采集、健壮性与可维护性方面仍有优化空间：
|
|||
|
|
|
|||
|
|
### 2.1 后端（Backend）
|
|||
|
|
|
|||
|
|
1. **数据库连接池与异步写入优化**
|
|||
|
|
- **现状**：`SimulationManager._run_loop` 中每次采集都调用 `_persist_signal`，内部使用 `async with self._session_factory()` 创建新 Session 并提交。
|
|||
|
|
- **问题**：高频采集（如 50ms/20Hz）下，频繁创建/销毁 Session 会带来性能开销；且单条 Insert 效率较低。
|
|||
|
|
- **改进**：
|
|||
|
|
- 引入 **批量写入队列**（Batch Buffer），每 N 条或每 M 秒批量 `COPY` 或 `INSERT` 到 TimescaleDB。
|
|||
|
|
- 确保 `engine` 配置了合理的连接池大小（`pool_size`, `max_overflow`）。
|
|||
|
|
|
|||
|
|
2. **异常处理与优雅退出**
|
|||
|
|
- **现状**：`main.py` 的 `shutdown` 钩子中只处理了 `simulation_manager.stop`。
|
|||
|
|
- **问题**：如果 WebSocket 广播队列积压或数据库连接卡死，服务可能无法优雅退出。
|
|||
|
|
- **改进**：
|
|||
|
|
- 增加全局异常捕获（Global Exception Handler）。
|
|||
|
|
- 在 `Broadcaster` 中增加队列满或断连的防御性逻辑。
|
|||
|
|
|
|||
|
|
3. **配置热加载与验证**
|
|||
|
|
- **现状**：`settings.py` 仅在启动时加载一次。
|
|||
|
|
- **问题**：运行时无法动态调整日志级别或采集频率。
|
|||
|
|
- **改进**：虽然不需要完全热加载，但建议增加配置项的 Pydantic 校验（当前已用 `pydantic-settings`，符合预期，但可增强校验规则）。
|
|||
|
|
|
|||
|
|
4. **设备抽象层增强**
|
|||
|
|
- **现状**：`MockVehicleDevice` 直接返回字典。
|
|||
|
|
- **改进**：引入 Pydantic 模型或 TypedDict 定义设备数据协议，确保 `payload` 结构在代码层面有强类型约束。
|
|||
|
|
|
|||
|
|
### 2.2 前端（Frontend）
|
|||
|
|
|
|||
|
|
1. **状态管理缺失**
|
|||
|
|
- **现状**：各 `.vue` 页面独立通过 `useWebSocket` 订阅数据。
|
|||
|
|
- **问题**：多窗口间（如控制屏与大屏）可能需要共享某些全局状态（如当前仿真 ID、连接状态），各自维护连接可能造成资源浪费或状态不一致。
|
|||
|
|
- **改进**：引入 Pinia 进行全局状态管理（如 `useSimulationStore`），统一管理 WS 连接与消息分发。
|
|||
|
|
|
|||
|
|
2. **Electron 进程通信 (IPC) 封装**
|
|||
|
|
- **现状**：`main.cjs` 启动了后端，但未建立健壮的 IPC 通道来透传后端日志或状态给渲染进程。
|
|||
|
|
- **改进**：增加 `preload.js`，通过 `contextBridge` 暴露后端进程状态（PID、启动日志）给控制屏前端，便于运维排查。
|
|||
|
|
|
|||
|
|
3. **多屏窗口管理增强**
|
|||
|
|
- **现状**：`createWindows` 硬编码了 `others[0]`、`others[1]`。
|
|||
|
|
- **改进**：增加配置文件（`window-layout.json`）记录屏幕 ID 与窗口路由的绑定关系，实现“开机自动恢复上次布局”。
|
|||
|
|
|
|||
|
|
## 3. 优化计划
|
|||
|
|
|
|||
|
|
基于以上分析，将对代码进行以下针对性优化：
|
|||
|
|
|
|||
|
|
1. **后端**：优化 `SimulationManager` 的入库逻辑，改为 `Buffer` 批量写入模式。
|
|||
|
|
2. **后端**：增强 `device` 数据模型的类型定义。
|
|||
|
|
3. **前端**：引入 Pinia 并重构 WS 逻辑为 Store 模式。
|
|||
|
|
4. **工程**：补充 `docker-compose.yml` 以便快速拉起 PostgreSQL + TimescaleDB 环境。
|