本文是「自主工厂底层操作系统」系列的第二篇。
上一篇讲了全景：一个人，一个树莓派，一个工厂的底层操作系统。
这一篇，我拆开讲后端——为什么一个沾着灰的树莓派5，能撑起80人工厂的全部业务，CPU占用常年20%以下，内存不到2G。
一、先看三张图
图1：跑了快两年的“服务器”
这就是我的“数据中心”。
没有恒温恒湿机房，没有机架，没有双路电源。一个几百块的树莓派5，塑料壳上沾着车间的灰，塞在墙角的电控柜旁边。
但它跑了快两年。80人工厂的全部核心数据都在它身上。
图2：htop实时截图
PS：这是我在连续不停的点击刷新时候的服务状态
CPU占用常年20%以下，内存不到2G。一个树莓派5，同时跑着FastAPI、MySQL，还挂着几个数据同步脚本。
不是硬件强，是架构省。
图3：API响应时间实测
| API | 数据量 | 响应时间 |
|---|---|---|
| /get-gongdan | 100条工单 | 147ms |
| /get-dabaodan | 50条打包单 | 89ms |
| /get-kucunfenxi | 库存汇总 | 112ms |
| /create-ruku | 入库保存 | 95ms |
100条工单147ms——包含网络传输、AES加解密、数据库查询、JSON序列化。
树莓派做到的。换好服务器只会更快。
二、一个反共识的起点
开始写这套系统之前，我问了自己一个问题：
我是要写一套“教科书级”的代码，还是要写一套“能在车间跑起来”的代码？
我选了后者。
这意味着变量名可能随意，API命名可能不统一，代码里有重复，一个文件几千行。
但系统在工厂跑了快两年，没崩过。
代码的艺术性是给程序员看的，系统的稳定性是给工厂用的。
三、代码不完美，但实用、稳定、好维护
我承认我的代码不完美。
变量名随意，API命名草率，没严格遵守驼峰还是下划线，一个文件几千行，重复代码到处都是。
但这是故意的。
为什么允许重复？
每个API都有自己的加解密、分页、查询构建。看着臃肿，但换来的是：
- 故障隔离：一个API出问题，不影响其他
- 独立修改：改某个API不需要担心影响别的
- 部署灵活：未来需要拆成微服务，直接复制就行
- 认知负担低：看一个API文件，就能理解全部逻辑
重复的代价（代码臃肿）vs 复用的代价（耦合、共享状态、调试复杂）。在我的场景里，重复的代价更小。
维护成本高吗？不高。
因为有DeepSeek。
以前改一个API要翻半天代码，现在直接把文件丢给DeepSeek，说“把这里改成那样”，它几秒钟就帮我改好。
代码不优雅没关系，AI能读能改就行。
我不是在写“给人看的代码”，我是在写“人和AI都能维护的代码”。这个标准低很多，但效率高很多。
四、为什么我敢用树莓派做服务器？
很多人觉得树莓派是个玩具。但在我的架构里，它是最理想的“压榨对象”。
我的逻辑很简单：
如果这套系统能在树莓派上跑稳，换任何服务器都只会更好。
树莓派5是我能找到的、性能最低的、还能跑Python+MySQL的硬件。我用它做“下限测试”——它能跑通，说明架构没问题；能跑两年，说明架构够稳；CPU只用20%，说明架构够省。
我不是在省钱，我是在验证架构的下限。
换一台正经服务器，性能翻10倍，代码一行不改。
五、当前技术栈（极简但够用）
| 组件 | 选择 | 理由 |
|---|---|---|
| Web框架 | FastAPI | 异步、高性能、自带API文档 |
| ORM | SQLAlchemy (异步) | 异步支持成熟 |
| 数据库 | MySQL | 稳定、够用 |
| 通信加密 | AES-128-ECB | 简单、够安全 |
| 部署 | 直接跑在树莓派上 | 无Docker、无K8s、无负担 |
你可能会问：AES用ECB模式？
我的回答：在我的场景里，够了。
六、为什么能跑这么稳？
1. 异步优先，用尽可能少的线程
FastAPI + 异步SQLAlchemy，是低占用的基石。
python
复制下载
@app.post("/get-gongdan")
async def get_gongdan(request: UserListRequestAES, db: AsyncSession = Depends(get_db)):
result = await db.execute(query)
return response
一个Python进程处理所有并发请求，数据库查询时不阻塞，没有线程切换开销。
配合上面的htop图，你能看到——4个核基本没怎么动。
2. 固定密钥 + 主动控制
AES密钥写死在代码里——又一个“不优雅”的决策。
但固定密钥有一个被很多人忽略的好处：它是CS架构下的管理工具。
我的客户端是C++编译的，密钥嵌在里面。如果哪天我需要强制所有用户更新客户端——比如修复了重要bug、增加了新功能、或者怀疑密钥泄露——我只需要做一件事：
换密钥。
服务端一换，旧客户端全部失效。用户必须下载新版本才能继续使用。
这不是安全漏洞，这是版本控制手段。不是被动防御，是主动管理。
我的防御逻辑是这样的：
| 层级 | 防御手段 |
|---|---|
| 第一层 | 内网隔离，攻击者进不来 |
| 第二层 | 客户端是QT C++，逆向门槛极高 |
| 第三层 | 固定密钥，但监控日志 |
| 第四层 | 发现异常，换密钥 + 强制更新客户端 |
我不是在防御国家级黑客。我防御的是外部扫描器、内部误操作、依赖库漏洞。在这个模型下，固定密钥+强制更新，完全够用，而且好用。
3. 性能数据说话
回到最上面的API响应时间图。
100条工单147ms——包含网络传输、AES加解密、数据库查询、JSON序列化。
树莓派做到的。
这个速度，工人点一下屏幕，眨个眼的功夫就回来了。没人觉得慢。
七、接下来，我要压榨出更优的方案
系统跑了两年，很稳。但我很清楚它还能更好。
当前系统装的是Ubuntu Desktop，带了一整套我用不到的东西：图形界面、ROS2、Snapd、ModemManager……这些软件不光占空间，更关键的是它们会在后台默默跑进程、占CPU、占内存、写日志。
下一步，我要把这些无用负载全部剔除，换成Ubuntu Server最小化安装。
这不是“优化”，这是减负。把树莓派从桌面系统改造成纯粹的服务器，让它把全部资源用在刀刃上。
除此之外，还有几个方向：
- 热点数据入内存：库存、工单这类高频查询数据，从MySQL搬到内存里，读性能从50ms降到1ms以内
- Python协程 → C++协程：等Python真的不够用了再换，现在CPU才20%，不急
- 加大与AI服务器的数据同步：增量同步、批量压缩、断点续传，让AI吃上最新鲜的数据
八、演进路线图
text
复制下载
当前（树莓派，跑了两年）
CPU 15-20% | 内存 1.8G | API响应 100-200ms
│
├─ 第一步（近期待办）
│ └─ 剔除无用软件（图形界面/ROS2等），换Ubuntu Server
│ → 释放500MB-1GB内存，减少20+后台进程
│
├─ 第二步（3个月内）
│ └─ 热点数据入内存 → 读性能从50ms降到1ms
│
├─ 第三步（6-12个月，按需）
│ └─ 热点模块用C++重写 → 性能提升5-10倍
│
└─ 第四步（持续）
└─ 数据同步优化 → AI吃上新鲜数据
每一步，都是可逆的、可度量的、不伤害现有系统的。
我不追求一步到位。我只追求下一步比上一步好。树莓派还能跑，我就继续用Python。等到它扛不住了，换服务器就是降维打击。
九、关于DeepSeek的辅助
最后说一句：这套代码能维护下来，DeepSeek帮了大忙。
以前改一个贯穿多个文件的逻辑，要翻半天，还容易改出bug。现在直接把代码片段丢给DeepSeek，说清楚要改什么，它几秒钟就给出版本。
代码不优雅没关系，AI能读能改就行。
十、写在最后
（插入树莓派实物图、htop图、API响应时间图的位置）
三张图，浓缩了这套系统的全部：
- 一个沾灰的树莓派
- 20%的CPU占用
- 100多毫秒的响应
树莓派只是最便宜的验证样板。
它能跑通，说明架构没问题；能跑两年，说明架构够稳；CPU只用20%，说明架构够省。
换好服务器，只有更好。
下一篇讲桌面客户端——C++/Qt完整工业应用，如何与树莓派后端配合。
欢迎围观，欢迎验证。
