低规格服务器下的分层部署取舍

我的几个项目不是跑在大规格服务器上。更多时候，我面对的是 2C1G 这类小机器。

这会逼着我做取舍。项目上线不能只想“能不能部署”，还要想哪些服务应该放在自有服务器，哪些可以交给托管平台，哪些只需要做监控和反代。

教育机构管理系统

教育机构管理系统采用的是分层部署。

后端运行在自有 Linux 节点上，由 systemd 负责进程自启和守护，Caddy 负责反向代理和 HTTPS。前端使用 Azure Static Web Apps，数据库使用 Azure MySQL Flexible Server。

这样拆的原因很直接。前端静态资源没有必要占用小服务器资源，数据库也不适合和后端长期抢内存。自有服务器只承载后端服务，压力更稳定，也方便排查。

成绩分析系统

成绩分析系统的个人服务器版本由 vm5-japan 承载 Node.js 应用服务，数据库使用 Azure MySQL 托管。

这个项目还有学校实际环境落地记录。学校环境里，方案曾经考虑应用服务器和数据库服务器分离。现场执行时又根据服务器条件调整过部署方式，先把系统跑通，再围绕服务启动、健康检查、代码同步和差异对比继续维护。

这段经历让我意识到，部署方案不是写出来就结束。真实环境会有资源、网络、权限和维护成本的限制。能根据现场条件调整，同时保留文档和回退路径，才是更可靠的上线方式。

监控和入口

Beszel 监控接入后，我可以从一个面板观察多台节点的 CPU、内存、磁盘和网络状态。它不是项目作品，但能补上运行状态证据。

公开展示只保留只读监控入口和脱敏后的节点角色。管理员入口、连接凭据和完整运维命令留在私有侧。

这条经验留下了什么

这几次部署让我形成了一个固定判断。

低规格服务器不适合承担所有东西。静态前端可以交给静态托管，数据库可以交给托管数据库，业务服务放在自有节点，监控单独接入。这样并不华丽，但更适合个人项目长期运行。

它也让我在写作品集时不再只写“已上线”。更有价值的，是说明项目如何上线，为什么这样拆，以及哪些内容需要脱敏。