免责声明
- 教程性质
本文档（以下简称“本教程”）仅用于技术交流与学习目的，旨在介绍腾讯 WorkBuddy 软件的基本安装与使用方法。本教程中提及的任何操作步骤、配置建议及第三方工具（如宝塔面板、Cloudflare 隧道等）均仅供参考，不构成任何形式的官方指导或承诺。
- 用户责任
用户在使用 WorkBuddy 软件及本教程涉及的任何操作前，应自行审阅并同意腾讯官方发布的《腾讯云 WorkBuddy 软件许可及服务协议》（EULA）及《隐私保护指引》。用户需自行承担因安装、配置、使用本教程所涉软件、工具及服务而产生的一切风险、责任及后果，包括但不限于数据丢失、隐私泄露、系统故障、账号封禁或违反相关法律法规及平台规则等。
- 第三方工具
本教程中可能提及的宝塔面板、Cloudflare 等均为独立的第三方服务，其使用受各自服务条款约束，与本教程作者无关。用户应自行判断其安全性与合规性。
- 禁止行为
本教程不鼓励且明确反对任何违反 WorkBuddy 用户协议、侵犯腾讯公司合法权益（包括但不限于使用“开心版”、“破解版”等非官方版本）或违反国家法律法规的行为。因用户从事上述行为而产生的一切法律后果，由用户自行承担。
- 无担保声明
本教程按“现状”提供，作者不对教程内容的准确性、完整性、及时性、可靠性或适用性作任何明示或暗示的担保。作者不对用户因使用本教程而遭受的任何直接或间接损失（包括但不限于经济损失、数据损失、业务中断等）承担任何责任。
- 权利归属
WorkBuddy 为腾讯公司（Tencent）的产品，其所有权利归腾讯公司所有。本教程与腾讯公司无任何关联，并非官方教程。
- 关于免费资源（“白嫖”）的特别提醒
本教程可能涉及利用 WorkBuddy 的免费试用额度、积分或实例等资源。用户应知悉，此类免费资源受腾讯官方使用政策约束，通常禁止用于商业用途、高负载运算、挖矿、违法违规内容等。用户自行承担因滥用免费资源（包括但不限于超额使用、违规操作、账号多开等）而导致的一切后果，如资源回收、账号封禁、法律追责等。作者不对此类后果承担任何责任。
使用本教程即视为您已阅读、理解并同意本免责声明的全部内容。
续：
https://linux.sb/topic/13711
（有人估计没看见这个链接，这是领取的方式）
可以把这个发给ai，它应该会按照这个保活
服务自动保活体系：实现原理与搭建指南
目标：在"休眠/重启会清空进程"的环境中，让常驻服务在无人干预下自动恢复。
本文只讲保活机制的实现原理与通用做法，不涉及任何具体业务数据。
一、为什么需要保活？
这类环境（沙箱/容器/按需恢复的服务器）有一个关键特性：
- 休眠或重启后：文件系统完整保留，但进程全部丢失
- 环境内自带的定时任务服务（cron）可能也会停止，不能作为唯一依赖
所以"装好服务就完事"是不够的——必须有一套不依赖单一组件的自动恢复机制，这就是保活体系。
二、保活体系的核心架构：三层互为兜底
┌─────────────────────────────────────────────────────┐
│ 第一层：平台托管（环境启动时自动拉起） │
│ → 解决"休眠/重启恢复" │
├─────────────────────────────────────────────────────┤
│ 第二层：自愈脚本（运行期崩溃 30 秒内自愈） │
│ → 解决"进程意外退出" │
├─────────────────────────────────────────────────────┤
│ 第三层：定时任务兜底（每 5 分钟汇总检查） │
│ → 解决"前两层都失效"的极端情况 │
└─────────────────────────────────────────────────────┘为什么是三层？ 因为任何单一手段都有失效场景：
| 手段 | 失效场景 |
|---|---|
| 平台托管 | 仅覆盖环境启动时刻，运行中崩溃不负责 |
| 自愈脚本 | 脚本进程本身也可能被杀 |
| 定时任务 | 服务可能自行停止；休眠恢复后不一定自动运行 |
三层叠加后，任意一层失效，其余两层仍能兜住。
三、每一层是怎么实现的？
第一层：平台托管（最关键的一层）
原理：运行环境通常提供一个"应用自启动清单"机制——把应用的启动命令注册进去后，环境每次启动时都会自动执行清单里的应用。它跟随环境的生命周期，所以能解决"休眠恢复后服务不再"这个最棘手的问题。
实现方式（以通用 autostart 接口为例）：
# 注册两个服务到平台托管清单
curl -s -X POST "http://127.0.0.1:65310/replaceCloudStudioConfig" \
-H "Content-Type: application/json" \
-d '{
"app": [
{"name": "service_a", "port": 9000, "cmd": "bash /opt/keepalive/service_a.sh"},
{"name": "service_b", "port": 9001, "cmd": "bash /opt/keepalive/service_b.sh"}
],
"restart": false
}'name：应用名；port：健康检查端口（探测服务是否活着）cmd：启动命令——必须指向一个保持前台运行的脚本（见第二层）- 平台按端口探测健康；进程退出时可按配置重启托管应用
没有平台托管的替代方案：注册为系统服务（systemd 的 enable / init.d 的 update-rc.d），实现开机自启。效果类似，但取决于环境对 init 系统的支持。
第二层：自愈脚本（运行期 30 秒自愈）
原理：一个常驻的前台 while 循环，每隔固定间隔检查服务的健康状态（端口是否监听、进程是否存在），发现异常立即执行拉起命令。
#!/bin/bash
# 自愈脚本模板：/opt/keepalive/service_a.sh
LOG=/opt/keepalive/keepalive.log
PORT=9000 # 服务监听端口
START_CMD="/opt/bin/service_a start" # 拉起命令
while true; do
if ! ss -tln 2>/dev/null | grep -q ":${PORT}"; then
eval "$START_CMD" >> "$LOG" 2>&1
echo "[$(date '+%F %T')] 服务已拉起" >> "$LOG"
fi
sleep 30
done关键设计点：
| 设计点 | 原因 |
|---|---|
while true 保持前台 | 脚本不能退出；平台按端口探测时，脚本进程就是"应用本体" |
| 间隔 30 秒 | 崩溃后恢复足够快，又不至于频繁探测 |
| 幂等 | 服务在跑时什么都不做——三层可能同时触发，重复拉起会产生多个实例 |
| 全量日志 | 每次动作写时间戳，方便事后排查"谁拉起了什么" |
ss 探测端口 | 端口监听是比"进程存在"更可靠的健康信号（进程在但端口没起来也算失败） |
无固定端口的服务（如隧道类），改用进程名探测：
if ! pgrep -x service_name > /dev/null 2>&1; then
service service_name start >> "$LOG" 2>&1
fi第三层：定时任务兜底（每 5 分钟）
原理：一个汇总检查脚本，覆盖所有服务 + 端到端链路自检，注册进 cron 每 5 分钟执行一次。即使前两层都失效，这里也会兜底恢复，并记录异常。
#!/bin/bash
# 汇总保活：/opt/keepalive/keepalive.sh
LOG=/opt/keepalive/keepalive.log
# 逐个检查服务，缺失即拉起（每个服务一段，结构同第二层）
if ! ss -tln 2>/dev/null | grep -q ":9000"; then
/opt/bin/service_a start >> "$LOG" 2>&1
fi
# 链路自检：模拟一次真实请求，期望返回 200
code=$(curl -s -m 8 -o /dev/null -w "%{http_code}" "http://127.0.0.1:9000/health" 2>/dev/null)
if [ "$code" != "200" ]; then
echo "[$(date '+%F %T')] 链路异常: HTTP $code" >> "$LOG"
fi注册定时任务并确保其运行：
chmod +x /opt/keepalive/keepalive.sh
service cron start # 先确保 cron 在跑
(crontab -l 2>/dev/null; echo "*/5 * * * * /opt/keepalive/keepalive.sh") | crontab -注意：cron 的启动命令因发行版而异（
service cron start/systemctl start cron）。
四、验收标准（必须实测）
只写脚本不算完成，必须做破坏性测试验证每一层：
| 测试 | 预期结果 |
|---|---|
| 杀掉服务进程 | 30 秒内自动恢复，端口重新监听 |
| 杀掉自愈脚本进程 | 定时任务（最迟 5 分钟）将其重新拉起 |
| 重启/休眠环境 | 平台托管清单生效，服务自动全部拉起 |
| 端到端请求 | 公网访问路径返回 200 |
五、实践中的坑
pkill -f会误杀自己
pkill -f "关键字" 会匹配包含该关键字的整条命令行——如果当前 shell 的命令行里恰好有同样的关键字（比如测试脚本本身），会把自己杀掉。
✅ 正确做法：用 ss -tlnp 提取端口对应的 PID，或用 pgrep -x（精确匹配进程名）。
- 脚本必须幂等
三层保活可能同时触发（例如自愈脚本刚拉起，cron 又检查了一遍）。不幂等的脚本会拉起多个实例，造成端口冲突。
- 只更新配置、不重启应用
平台托管的接口若带"立即重启所有应用"参数（restart:true），在服务较多时可能卡住或误杀正在运行的服务。稳妥做法：用 restart:false 只更新清单，再手动启动自愈脚本，让它们自己接管。
- 先备份再动配置
修改任何系统配置前 cp -a 备份，出问题可秒级回滚。
六、一图总结实现链路
环境休眠/重启
│
▼
平台托管清单被读取 ──► 自动执行自愈脚本（前台常驻）
│
┌─────────┼──────────┐
▼ ▼ ▼
检查面板端口 检查隧道进程 检查反代端口
│ │ │
└──── 缺失即拉起 + 记日志 ────┘
│
▼
cron 每 5 分钟汇总兜底 + 链路自检三层各自独立、职责互补：平台托管管"环境启动"，自愈脚本管"运行崩溃"，定时任务管"极端兜底"——这就是整套保活体系的实现逻辑。
（deepseek生成）
