签到打卡类小应用的部署

签到打卡类应用逻辑不复杂，麻烦都在细节里：定时任务不跑、统计差八个小时、月底账对不上。部署时把这几处盯住，低配机器也能长期跑得稳。 一、架构可以从简 一台入门云服务器足够。Nginx 加一个常驻应用进程，数据库用 SQLite 或 MySQL 都行，日活几千以内没有压力。操作系统选 Debian 或 Ubuntu LTS 都可以，别追太新的版本。PHP 或 Python 写的小应用单机足够，不必刻意动静分离，日志和程序放同一块盘也构不成瓶颈。选型上高防云服务器 S2 就能覆盖，标配 60G DDoS 防御，小应用也不怕被流量扫垮。 二、定时任务写进 crontab 每日重置、连续签到统计都靠定时任务。约定用 URL 触发，crontab 里这样写： 0 0 * * * /usr/bin/curl -s -m 30 http://127.0.0.1:8000/cron/daily > /dev/null 2>&1 注意三点：路径用绝对路径；输出重定向避免邮件轰炸；加 -m 超时防止进程堆积。验证办法简单，把执行时间临时改成两分钟后，盯着任务是否如期触发，验证完再改回来。crontab 编辑用 crontab -e，查看用 crontab -l，改完务必确认保存成功。 三、时区统一 服务器默认可能是 UTC，数据库、应用、定时任务三处时区必须一致。系统层执行 timedatectl set-timezone Asia/Shanghai；MySQL 在配置文件里加 default-time-zone = '+08:00'；改完用 date 命令和 SELECT now() 分别确认。时区不一致的典型症状：凌晨零点的签到被记到了前一天，用户投诉对不上账。如果用了 Docker，容器里还要同步设置 TZ 环境变量，宿主机对了容器照样可能是错的。 四、低配机器的稳定措施 日志用 logrotate 按天切割，别让单个文件撑满磁盘；数据库每晚 mysqldump 一份并传到本机之外保存；应用进程交给 systemd 守护，配置 Restart=always，崩了自动拉起。磁盘使用率设一条 80% 的告警，小盘最容易被日志悄悄撑爆。这三件事做完，半年不重启也不慌。 小应用拼的不是功能多，是不出幺蛾子。部署完自己先签到一周，比什么测试都实在。上线时间选工作日白天，出问题有人盯着。