第二章 技术选型与架构设计：Python生态选型与前后端分离
好，咱们直接进入正题。做设备数据可视化看板，第一步不是写代码，而是选工具。我见过太多人上来就撸代码，结果做到一半发现框架不合适，推倒重来。嗯，这种坑我踩过不止一次。
2.1 Python后端框架怎么选？
Python做后端，主流就三个：Flask、Django、FastAPI。很多人纠结选哪个，其实没那么复杂。我个人的经验是——看你的项目规模和实时性要求。
| 框架 | 适合场景 | 我的评价 |
|---|---|---|
| Flask | 轻量级、原型快速开发 | 灵活但需要自己搭很多东西 |
| Django | 大型项目、全栈开发 | 太重了，做看板有点杀鸡用牛刀 |
| FastAPI | 高性能API、实时数据 | 我目前最推荐的选择 |
为什么我推荐FastAPI？说白了，设备数据看板的核心就是「快」——数据更新快、接口响应快、开发速度也得快。FastAPI天然支持异步，处理大量设备上报数据时不会卡死。我在一个工厂项目中，用Flask接200个设备的数据就撑不住了，换成FastAPI后，2000个设备同时上报都没问题。
我的选择：FastAPI + Uvicorn
理由：异步支持好、自动生成API文档、性能接近Go语言
2.2 前后端分离架构
以前做看板，很多人用Django的模板系统，前端后端混在一起。说实话，维护起来太痛苦了。你想想看，前端改个样式要重启后端，后端改个接口又要前端配合调试。
前后端分离，说白了就是各干各的。后端只负责提供数据接口，前端只管展示和交互。我习惯用这种架构：
设备层 → 后端API(FastAPI) → 前端(Vue/React) → 用户浏览器
↓
数据库(PostgreSQL/InfluxDB)
这样做的好处很明显：
- 后端可以专心处理数据采集、清洗、存储
- 前端可以自由选择技术栈，Vue、React都行
- 部署时可以分开扩容，哪个压力大就加哪个的机器
小技巧：前后端分离后，接口文档一定要规范。我用FastAPI自带的Swagger文档，前端同事直接对着文档调接口，省了不少沟通成本。
2.3 数据流设计
数据流是看板的心脏。设备数据怎么从现场到屏幕？我画了一张图，你看完就明白了。
这张图我画了好几次才满意。你看，数据从设备出发，经过采集、处理、存储，最后通过API展示到前端。每一层各司其职，互不干扰。
避坑指南：我曾经在一个项目中，把数据清洗逻辑写在了前端。结果设备一多，浏览器直接卡死。记住，数据清洗一定要在后端做，前端只负责展示。
2.4 数据流中的关键设计
这里有几个点我想重点说一下：
- 数据缓冲：设备上报频率高的时候，直接用Redis做缓冲，防止数据库被打满。我习惯用Redis的列表结构，先进先出。
- 数据降采样：实时数据存原始值，历史数据做聚合。比如每秒的数据存一天，之后按分钟聚合存一周，再往后按小时聚合。
- 接口幂等性：设备可能重复上报同一条数据，接口要做好去重。我一般用设备ID+时间戳做唯一键。
核心原则：数据流设计要遵循「高内聚、低耦合」。每一层只做自己的事，层与层之间通过标准接口通信。这样后期维护、扩展都方便。
好了，技术选型和架构设计就聊到这儿。记住一句话：选型没有绝对的对错，只有适不适合你的场景。我见过用Django做小看板的，也见过用Flask做大项目的，关键是你得清楚自己要什么。