预约与工单类小系统的一机部署方案

十几个人用的小预约或工单系统，需要拆成应用一台、数据库一台吗？多数情况不需要。一台配置合适的云服务器把应用、数据库、反向代理全跑起来，维护简单，成本也低。 ## 为什么一机就够了 这类系统的特点是请求量小、数据量小：一天几十到几百条记录，峰值并发往往不超过十个，瓶颈远没到。拆分架构只会多出跨机网络配置和备份链路这些额外负担，小团队多两台机器就多两份监控和升级工作量。真正需要拆的信号是数据库 CPU 长期过半、报表查询拖慢录入页面，到那时再拆也不迟，迁移本身并不复杂。 ## 单机上的三层怎么摆 一台 2 核 4G 的机器，建议这样分工：数据库用 MySQL 或 PostgreSQL，只监听本机 127.0.0.1，不对公网开放端口；应用用 systemd 托管，进程崩了自动拉起；前面挡一层 Nginx 做反向代理，负责 HTTPS 证书和静态文件。代理配置的核心几行： ``` location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } ``` 应用本身只监听内网端口，公网能碰到的只有 80 和 443，攻击面一下子小很多。 ## 备份要跟上 数据都在一台机器上，备份就是最后的安全绳。数据库每天冷备一次，保留最近七天，加进 crontab： ``` 0 3 * * * mysqldump -ubackup -p"密码" dbname | gzip > /backup/db-$(date +\%F).sql.gz ``` 再加一条 rsync 把 /backup 同步到另一台机器或对象存储。注意备份账号只给读权限，密码别和应用配置混用同一个。恢复演练每季度做一次，把备份文件实际导入到测试库跑一遍，没验证过的备份不算备份。 ## 扩容预留 一机部署不等于一条路走到黑。几个预留动作现在就能做：应用配置里的数据库地址写成域名或环境变量，以后拆分改一行就够；磁盘选挂了独立数据盘的机型，数据不跟系统盘混放；反向代理层保留，以后加缓存、限流都在这层改。等预约量涨到单机吃力，先拆数据库出去，再考虑加应用节点。 一台机器把小系统跑稳，比半吊子的分布式架构实用得多。真正值得花时间的不是架构图，而是备份、监控和升级流程这几件小事。