tamakyi
3db3ce570a
已实现：HTTP/TCP/Banner 探测、90 天可用率、表格/卡片视图、 数据源过滤、UptimeRobot 双向兼容、服务端驱动的刷新节奏、 刷新接口滥用防护与信息泄露控制。
133 lines
7.3 KiB
Markdown
133 lines
7.3 KiB
Markdown
# 部署方案详解
|
||
|
||
四种方案按「成本从低到要求、数据从准到轻」排列。所有方案共用同一份 `public/` 目录与 `public/monitors.json` 配置。
|
||
|
||
---
|
||
|
||
## 方案一：本地运行（Node）
|
||
|
||
最适合内网自用与开发调试，数据最实时。
|
||
|
||
```bash
|
||
node prober/node/index.js # 默认端口 8787
|
||
PORT=9000 node prober/node/index.js # 自定义端口
|
||
```
|
||
|
||
- 面板：`http://localhost:8787/`
|
||
- 状态 API：`http://localhost:8787/api/status`
|
||
- 改 `public/monitors.json` 后自动热重载，无需重启
|
||
- 历史心率存于 `public/status.json`，重启后自动恢复
|
||
- 90 天可用率按天累积在 `public/status.json`，重启不丢（每次探测先恢复分桶再追加）
|
||
- 面板刷新即重新检测（`/api/refresh` 等待本轮完成再返回）；多标签页同时刷新只触发一轮探测
|
||
- 后台常驻可用 pm2 / systemd / Windows 服务，按需自行封装
|
||
|
||
**适用**：监控内网服务（面板浏览器与目标同内网时，浏览器直连模式也能用）。
|
||
|
||
---
|
||
|
||
## 方案二：GitHub Pages + Actions（零成本公网）
|
||
|
||
架构：仓库里的 `public/` 整体作为 Pages 站点；Actions 每 5 分钟跑一轮 Node 探针，把 `public/status.json` 提交回仓库，面板以 `static` 模式读取。
|
||
|
||
步骤：
|
||
|
||
1. 推送代码到 GitHub 仓库（`main` 分支）
|
||
2. 仓库 **Settings → Pages → Build and deployment → Source** 选 **GitHub Actions**
|
||
3. 首次提交时建议带一份占位数据，避免页面空白：
|
||
```bash
|
||
node prober/node/index.js --once --demo # 生成演示 status.json
|
||
git add public/status.json && git commit -m "chore: demo status" && git push
|
||
```
|
||
4. 之后 `pages.yml` 负责每次推送自动部署；`monitor.yml` 每 5 分钟更新一次 `status.json`（提交信息为 `chore: update status snapshot`）
|
||
5. 访问 `https://<用户名>.github.io/<仓库名>/`
|
||
|
||
注意事项：
|
||
|
||
- Actions 计划任务最小粒度 5 分钟，数据最多 5 分钟延迟；心跳图按「检测次数」记录，5 分钟粒度下 48 格 ≈ 4 小时
|
||
- 90 天可用率同样按「检测次数」统计，5 分钟粒度约 288 次/天；每轮 Actions 会把当日分桶续写到 `status.json` 并提交，因此可用率数据跨运行累积（若某天 Actions 未运行，该日色条会显示「无数据」而不是 0%）
|
||
- **静态快照模式没有服务端，面板无法触发重新检测**：此方案下刷新只是重新读取仓库里的 `status.json`，数据新鲜度完全取决于 Actions 的运行频率（面板页脚会显示「数据源：静态快照」以作区分）
|
||
- 若仓库开启了分支保护，需允许 `github-actions[bot]` 推送（workflow 已声明 `contents: write` 权限）
|
||
- 免费额度对公开仓库无限量，私有仓库每月 2000 分钟，足够
|
||
|
||
---
|
||
|
||
## 方案三：Cloudflare Workers（边缘实时）
|
||
|
||
架构：Worker 每分钟由 cron 触发，用 `fetch` 探测 HTTP、用 `cloudflare:sockets` 探测 TCP，状态写入 KV；同 Worker 伺服 `public/` 静态资源与 `/api/*`。面板以 `api` 模式实时读取。
|
||
|
||
```bash
|
||
# 1. 安装 wrangler（任选其一，不影响本项目运行时）
|
||
npm install -g wrangler
|
||
|
||
# 2. 登录并创建 KV 命名空间
|
||
wrangler login
|
||
wrangler kv namespace create MONITOR_KV
|
||
# 把输出的 id 填到 edge/cloudflare/wrangler.toml 的 [[kv_namespaces]].id
|
||
|
||
# 3. 部署（wrangler.toml 已指向 ../../public 作为静态资产，monitors.json 随之部署，无需手动导入 KV）
|
||
cd edge/cloudflare
|
||
wrangler deploy
|
||
```
|
||
|
||
- 面板与 API：`https://<worker 域名>/` 与 `/api/status`
|
||
- 手动触发一轮：`curl https://<worker 域名>/api/refresh`（等待本轮完成后返回最新快照，与本地探针同语义）
|
||
- cron 表达式在 `wrangler.toml` 的 `[triggers].crons` 中调整（`* * * * *` = 每分钟）
|
||
|
||
注意事项：
|
||
|
||
- **TCP 出站连接（`cloudflare:sockets`）需要 Workers 付费计划（$5/月）**；免费计划下 `http` 类型探测与面板完全正常，`tcp` 类型会报错并记为离线
|
||
- KV 为最终一致存储，刚写入后立即读取可能有秒级延迟，对分钟级巡检无影响
|
||
- 90 天可用率分桶随 state 一起存于 KV，按 **UTC 日期** 分桶（边缘环境无本地时区）；每分钟 cron 约 1440 次/天
|
||
- 免费版 Worker 每日 10 万次请求，面板静态资源走 Assets 不计入 Worker 请求数
|
||
- 中国大陆访问 Worker 默认域名不稳定，可绑定自有域名（需 Cloudflare 账号管理 DNS）
|
||
|
||
---
|
||
|
||
## 方案四：EdgeOne Pages（国内加速）
|
||
|
||
EdgeOne Pages 当前以静态托管为主，采用与方案二相同的「静态 + 定时数据」路径，国内访问体验更好。
|
||
|
||
步骤：
|
||
|
||
1. 登录腾讯云 EdgeOne 控制台，进入 **Pages → 新建项目 → 导入 Git 仓库**（或直接上传 `public/` 目录）
|
||
2. 构建配置：无构建步骤，输出目录填 `public`
|
||
3. 数据更新二选一：
|
||
- **A. GitHub Actions 驱动**：保持方案二的 `monitor.yml` 不变，EdgeOne 侧开启「构建时拉取最新提交」或配置 Webhook 触发重新部署
|
||
- **B. CI 推送触发**：在 `monitor.yml` 末尾追加一步，调用 EdgeOne 的部署 API / Webhook（按控制台提示填写）
|
||
4. 绑定自定义域名（需要备案的域名走国内加速线路）
|
||
|
||
说明：EdgeOne Pages 若上线边缘函数（类 Pages Functions），可把 `edge/cloudflare/worker.js` 的 `/api/*` 部分平移过去，实现分钟级实时数据；当前初稿以静态路径交付，接口契约完全一致，迁移时面板无需改动。
|
||
|
||
---
|
||
|
||
## 90 天可用率在各方案下的表现
|
||
|
||
可用率按「探测次数」加权统计，因此**探测频率直接决定精度**，也决定色条填充速度：
|
||
|
||
| 方案 | 每次探测间隔 | 每天样本数 | 90 天色条填满所需时间 |
|
||
| --- | --- | --- | --- |
|
||
| 本地 Node | 按 `monitors.json` 的 `interval`（示例 60s） | ≈1440 | 90 天 |
|
||
| Cloudflare Workers | cron 每分钟 | ≈1440（UTC 日期分桶） | 90 天 |
|
||
| GitHub Pages + Actions | ≥5 分钟（Actions 下限） | ≈288 | 90 天 |
|
||
| EdgeOne Pages | 同 GitHub Pages | ≈288 | 90 天 |
|
||
|
||
注意：分桶数据随 `status.json`（或 KV state）持久化并滚动保留 90 天，**必须由探针持续写入才会累积**——静态快照方案下依赖 Actions 按计划运行；Actions 计划任务在仓库长期无活动时可能被 GitHub 自动暂停（后台重新启用即可）。
|
||
|
||
需要临时提升精度时，可把 `interval` 调到 30s 或更低（本地/Worker 均支持，注意目标站点的压力与自身限流）。
|
||
|
||
---
|
||
|
||
## 方案对比与选型建议
|
||
|
||
| 维度 | 本地 Node | GH Pages | CF Workers | EdgeOne Pages |
|
||
| --- | --- | --- | --- | --- |
|
||
| 数据延迟 | 秒级（interval） | ≤5 分钟 | ≤1 分钟 | ≤5 分钟 |
|
||
| 90 天可用率精度 | 高（≈1440 次/天） | 中（≈288 次/天） | 高（≈1440 次/天） | 中（≈288 次/天） |
|
||
| TCP 探测 | ✅ | ✅（Actions 内） | 付费版 ✅ / 免费版 ❌ | 同 GH Pages |
|
||
| 真实状态码 | ✅ | ✅ | ✅ | ✅ |
|
||
| 内网目标 | ✅（浏览器同网即可） | ❌ | ❌ | ❌ |
|
||
| 国内访问速度 | 本机最快 | 一般 | 一般 | 快 |
|
||
| 运维成本 | 需保活进程 | 零 | 零 | 零 |
|
||
|
||
建议：个人/演示用 **GitHub Pages**；生产公网监控用 **Cloudflare Workers**；服务对象在国内且以 HTTP 监控为主用 **EdgeOne Pages**；内网资产用 **本地 Node**。
|