first
This commit is contained in:
Your Name
796
docs/16_domainCheck_多机检测与跨地域部署设计.md
Normal file
796
docs/16_domainCheck_多机检测与跨地域部署设计.md
Normal file
@@ -0,0 +1,796 @@
|
||||
# 16 domainCheck 多机检测与跨地域部署设计
|
||||
|
||||
## 一、目标
|
||||
|
||||
本文档用于固化 `domainCheck` 的正式多机落地方案，满足下面这些约束：
|
||||
|
||||
- Web 后台、管理 API 必须部署在国外机器
|
||||
- 检测执行、代理、Redis、运行态存储部署在大陆机器
|
||||
- 最终结果、配置、归档、备份以国外机器为主
|
||||
- 初期部署不复杂，支持从 `国外 1 台 + 大陆 1 台` 起步
|
||||
- 后期不够时，优先横向增加大陆 Worker，不推翻整体架构
|
||||
|
||||
一句话原则：
|
||||
|
||||
> 国外负责“管、看、存、备份”，大陆负责“跑、调度、抢任务、贴近代理资源”。
|
||||
|
||||
## 二、当前落地状态
|
||||
|
||||
截至 `2026-04-16`，第一阶段多机运行骨架已经完成，当前代码已具备：
|
||||
|
||||
- 控制面节点注册与心跳
|
||||
- 执行面节点注册与心跳
|
||||
- 运行库骨架表自动初始化
|
||||
- 集群节点快照接口
|
||||
- 国外/大陆两套部署脚手架
|
||||
|
||||
当前已落地的运行态表：
|
||||
|
||||
- `detect_worker_nodes`
|
||||
- `detect_jobs`
|
||||
- `detect_job_items`
|
||||
- `detect_run_events`
|
||||
- `detect_sync_records`
|
||||
|
||||
当前可直接验证的接口：
|
||||
|
||||
- `GET /api/v1/runtime/status`
|
||||
- `GET /api/v1/runtime/readiness`
|
||||
- `GET /api/v1/runtime/cluster`
|
||||
- `GET /api/v1/detect/job/active`
|
||||
- `GET /api/v1/detect/jobs`
|
||||
- `GET /api/v1/detect/queue-summary`
|
||||
|
||||
当前 `runtime/cluster` 还补充了 `summary` 摘要，至少会返回：
|
||||
|
||||
- `status_counts`
|
||||
- `role_counts`
|
||||
- `region_counts`
|
||||
- `online_worker_nodes`
|
||||
- `online_control_nodes`
|
||||
- `busy_nodes`
|
||||
- `stale_nodes`
|
||||
- `offline_nodes`
|
||||
|
||||
当前还补充了同步观测骨架：
|
||||
|
||||
- `GET /api/v1/runtime/sync-summary`
|
||||
- `GET /api/v1/runtime/sync-records`
|
||||
|
||||
可用于提前观察：
|
||||
|
||||
- 当前节点是否启用同步推送
|
||||
- 源地域 / 目标地域配置是否正确
|
||||
- `detect_sync_records` 最近状态分布
|
||||
|
||||
当前代码还补了一层“运行态自动投影”：
|
||||
|
||||
- 控制面在读取 `runtime/status` 时，会把当前运行摘要按去重策略写入 `detect_sync_records`
|
||||
- 当前记录类型为：
|
||||
- `runtime_projection`
|
||||
- 当前还新增了“结果摘要投影”：
|
||||
- `detect_result_projection`
|
||||
- 用于把当前活跃任务的摘要、最近阶段事件、任务收敛进度先沉淀到统一同步面板
|
||||
- 其作用不是替代后续真正的 `sync-service`
|
||||
- 而是先保证跨地域部署阶段已经有统一可观察的“同步记录面板”
|
||||
|
||||
当前还补上了正式同步最小闭环骨架：
|
||||
|
||||
- 大陆执行面可通过 `SYNC_TARGET_API_BASE_URL` 指向国外控制面
|
||||
- 若 `SYNC_PUSH_ENABLED=true`，应由大陆 `domaincheck-sync-agent` 按轮询间隔自动推送最新运行态投影
|
||||
- 国外控制面通过：
|
||||
- `POST /api/v1/runtime/sync-ingest`
|
||||
接收投影
|
||||
- 若配置了 `SYNC_SHARED_TOKEN`，接收端会校验：
|
||||
- `X-Domaincheck-Sync-Token`
|
||||
|
||||
因此当前虽然还没有完整业务结果同步服务，但“同步协议、发送端、接收端、记录面板、独立同步代理”都已经有了第一版可运行骨架
|
||||
|
||||
当前同步骨架已经支持的记录类型包括：
|
||||
|
||||
- `runtime_projection`
|
||||
- `runtime_ingest`
|
||||
- `detect_result_projection`
|
||||
- `detect_result_ingest`
|
||||
- `runtime_push`
|
||||
|
||||
当前这一轮还补上了“结果批次同步可观测”能力：
|
||||
|
||||
- `GET /api/v1/runtime/sync-summary` 现在会额外返回：
|
||||
- `detect_result_batches`
|
||||
- 可直接按最近检测任务查看：
|
||||
- 是否已生成结果投影
|
||||
- 是否已推送
|
||||
- 是否已被目标地域接收
|
||||
- 最近一次失败原因
|
||||
- 当前同步策略也已细化为：
|
||||
- `runtime_projection`
|
||||
只推最新一条，避免把历史运行态投影整批补传
|
||||
- `detect_result_projection`
|
||||
按批次补推，确保检测结果积压可以自动追平
|
||||
- 大陆 `controller` 的环境模板也已固定为：
|
||||
- `NODE_ROLE=control`
|
||||
避免把 controller 误注册成普通 Worker，导致运行中心和 sync-agent 承载判断失真
|
||||
|
||||
当前这一轮还额外补齐了“检测会话追踪”能力：
|
||||
|
||||
- `POST /api/v1/detect/start` 会生成本轮 `cycle_token`
|
||||
- `cycle_token` 会进入 Worker 控制指令
|
||||
- Worker 心跳元数据会回写 `cycle_token / job_id / job_code`
|
||||
- `domain_started / domain_completed / domain_failed` 事件会附带 `cycle_token`
|
||||
- `GET /api/v1/detect/job/active` 已支持按当前 `cycle_token` 聚合“本轮事件”
|
||||
|
||||
当前运行态还补齐了“代理执行语义”：
|
||||
|
||||
- 代理可用时显示 `代理正常`
|
||||
- 代理暂时不可用但允许直连时显示 `降级直连`
|
||||
- 代理暂时不可用且不允许直连时显示 `等待代理`
|
||||
- 当代理源全部 `HTTP 200` 但 `raw_items=0` 时，会额外标记为“供应池为空”，避免误判成程序异常
|
||||
|
||||
当前阶段的准确表述应为：
|
||||
|
||||
> 多机运行骨架已经落地，分布式调度与跨地域结果同步进入下一阶段。
|
||||
|
||||
截至当前这一轮代码，最小任务闭环也已经接上：
|
||||
|
||||
- `POST /api/v1/detect/start` 会先创建 `detect_jobs`
|
||||
- Worker 会优先从 `detect_job_items` 领取任务
|
||||
- 运行中心已能显示当前活跃任务摘要
|
||||
- 节点状态里已能反映 `busy / current_load`
|
||||
- Worker 已支持小批量领取、任务续租、过期租约回收
|
||||
- API 控制面节点已支持定时心跳，避免集群视图把控制面误判为离线
|
||||
- 活跃任务接口已支持节点分布、进度百分比和最近事件回看
|
||||
- Worker 进程重启后会主动回收当前节点遗留的 `running / claimed` 运行态，避免后台出现“进程已重启但旧任务仍显示运行中”的残影
|
||||
|
||||
这意味着后续新增第二台大陆 Worker 时，已经不再是“完全从零设计”的状态，而是可以在现有骨架上继续细化调度策略。
|
||||
|
||||
当前最小联调命令也已经固定为：
|
||||
|
||||
```bash
|
||||
cd /opt/domaincheck/domain-api
|
||||
bash deploy/multi-region/check_cluster.sh http://127.0.0.1:8100
|
||||
```
|
||||
|
||||
这条命令会连续检查：
|
||||
|
||||
- `/health`
|
||||
- `/api/v1/runtime/cluster`
|
||||
- `/api/v1/detect/status`
|
||||
- `/api/v1/detect/job/active`
|
||||
|
||||
如需单独检查“跨地域同步骨架是否已接上”，建议再补两条：
|
||||
|
||||
```bash
|
||||
curl http://127.0.0.1:8100/api/v1/runtime/sync-summary
|
||||
curl http://127.0.0.1:8100/api/v1/runtime/sync-records?limit=10
|
||||
```
|
||||
|
||||
如需快速拿到“当前这套多机部署是否已进入可联调 / 待处理 / 阻断”结论，当前也已经固定了：
|
||||
|
||||
```bash
|
||||
curl http://127.0.0.1:8100/api/v1/runtime/readiness
|
||||
```
|
||||
|
||||
该接口会直接给出：
|
||||
|
||||
- `status`
|
||||
- `ready`
|
||||
- `attention`
|
||||
- `blocking`
|
||||
- `summary`
|
||||
- `blocking_issues`
|
||||
- `warnings`
|
||||
- `info`
|
||||
|
||||
如果这两条接口已经能看到：
|
||||
|
||||
- `source_region / target_region`
|
||||
- `records_total > 0`
|
||||
- 最近记录里出现 `runtime_projection`
|
||||
|
||||
则说明当前测试服已经具备：
|
||||
|
||||
- 同步配置观测入口
|
||||
- 同步记录落库入口
|
||||
- 后续接入正式 `sync-service` 的最小运行骨架
|
||||
|
||||
如果要在大陆 controller 节点本机确认“这台机器本身是否配成了 controller，而不是普通 Worker”，当前也已经固定了一条本机检查命令：
|
||||
|
||||
```bash
|
||||
cd /opt/domaincheck/domain-api
|
||||
bash deploy/multi-region/check_mainland_controller.sh
|
||||
```
|
||||
|
||||
这条命令会直接校验：
|
||||
|
||||
- `/etc/default/domaincheck-worker`
|
||||
- `NODE_ROLE=control`
|
||||
- `SYNC_PUSH_ENABLED=true`
|
||||
- `SYNC_TARGET_API_BASE_URL` 是否已填写
|
||||
- `domaincheck-worker`
|
||||
- `domaincheck-sync-agent`
|
||||
是否已经启动
|
||||
|
||||
如果当前客观条件下还不能把代码真正部署到大陆机器，当前也支持先在国外测试机上做“模拟多节点联调”：
|
||||
|
||||
```bash
|
||||
cd /opt/domaincheck/domain-api
|
||||
bash deploy/multi-region/simulate_multi_region.sh http://127.0.0.1:8100
|
||||
```
|
||||
|
||||
这条命令会临时模拟：
|
||||
|
||||
- 一个大陆 `controller`
|
||||
- 一个大陆 `worker`
|
||||
|
||||
它的目的不是替代真实部署，而是先把下面这些提前跑通：
|
||||
|
||||
- `runtime/readiness`
|
||||
- `runtime/cluster`
|
||||
- 运行中心的多机就绪度提示
|
||||
- 文档、脚本、状态面板三者是否一致
|
||||
|
||||
如果测试服之前已经跑过旧节点、旧 worker，当前还残留陈旧心跳记录，也可以先清一次 `detect_worker_nodes` 里的历史残影，再观察 readiness：
|
||||
|
||||
```bash
|
||||
cd /opt/domaincheck/domain-api
|
||||
bash deploy/multi-region/prune_cluster_nodes.sh --minutes 30 --dry-run
|
||||
bash deploy/multi-region/prune_cluster_nodes.sh --minutes 30
|
||||
```
|
||||
|
||||
它的作用是：
|
||||
|
||||
- 清掉很久没心跳的旧节点记录
|
||||
- 避免运行中心长期被历史离线节点污染成 `attention`
|
||||
- 让单机模拟多节点联调时，看到更接近真实接入后的状态
|
||||
|
||||
## 三点五、当前实测结论
|
||||
|
||||
截至 `2026-04-16 18:56`，测试服已经验证通过：
|
||||
|
||||
- `domaincheck-api` 与 `domaincheck-worker` 可在 `systemd` 下稳定重启
|
||||
- `worker_mode=linux-systemd`
|
||||
- `runtime/cluster` 可同时看到：
|
||||
- `overseas-control-01`
|
||||
- `mainland-worker-01`
|
||||
- 大陆 Worker 节点元数据已显示：
|
||||
- `phase`
|
||||
- `detail`
|
||||
- `job_id`
|
||||
- `job_code`
|
||||
- `cycle_token`
|
||||
- `detect/job/active` 的 `current_cycle_events` 已只回看当前这一轮检测事件，不再混入旧轮次历史
|
||||
|
||||
当前测试服最新一轮实测 `cycle_token` 示例：
|
||||
|
||||
- `aec105737f`
|
||||
|
||||
该轮已确认能看到：
|
||||
|
||||
- `job_dispatch_requested`
|
||||
- `job_dispatch_sent`
|
||||
- `domain_started`
|
||||
- `domain_completed`
|
||||
|
||||
这说明“控制面发起一次检测”到“执行面逐域名回写事件”的会话闭环已经打通。
|
||||
也说明当前后台已经不再只会显示“有告警”，而是能明确说明任务到底是在正常代理、降级直连，还是被代理卡住。
|
||||
|
||||
## 四、推荐架构
|
||||
|
||||
### 1. 国外控制面
|
||||
|
||||
国外机器负责：
|
||||
|
||||
- `domain-web`
|
||||
- `domain-api`
|
||||
- 国外主 PostgreSQL
|
||||
- 配置中心
|
||||
- 导出、审核、运营后台
|
||||
- 最终结果归档
|
||||
- 国外备份与日志归档
|
||||
|
||||
国外控制面的职责：
|
||||
|
||||
- 对外提供访问入口
|
||||
- 保存最终业务结果
|
||||
- 保存系统配置和审计记录
|
||||
- 接收大陆执行面的结果同步
|
||||
- 为后续灾备提供稳定的权威数据源
|
||||
|
||||
### 2. 大陆执行面
|
||||
|
||||
大陆机器负责：
|
||||
|
||||
- `detect-worker`
|
||||
- 大陆 Redis
|
||||
- 大陆运行库 PostgreSQL
|
||||
- 代理池配置与网络环境
|
||||
- 本地运行日志
|
||||
- 调度和任务租约
|
||||
|
||||
大陆执行面的职责：
|
||||
|
||||
- 抢任务
|
||||
- 续租
|
||||
- 运行检测链路
|
||||
- 写入本地运行态
|
||||
- 汇总并同步结果到国外
|
||||
|
||||
### 3. 初期物理部署
|
||||
|
||||
当前最优起步方案：
|
||||
|
||||
- 国外 `1` 台：
|
||||
- `domain-web`
|
||||
- `domain-api`
|
||||
- `postgresql_main`
|
||||
- 大陆 `1` 台：
|
||||
- `redis`
|
||||
- `postgresql_runtime`
|
||||
- `scheduler`
|
||||
- `detect-worker`
|
||||
|
||||
说明：
|
||||
|
||||
- 这个起步方案的优先目标是先把跨地域职责边界定清楚
|
||||
- 大陆机器当前可以先把 Redis、运行库、调度和 Worker 放在同一台
|
||||
- 但逻辑上必须按不同角色设计，避免后续扩容时重新返工
|
||||
- 各节点身份建议统一通过 `/etc/default/domaincheck-api` 与 `/etc/default/domaincheck-worker` 管理，不直接修改 service 文件正文
|
||||
|
||||
### 4. 后续扩容
|
||||
|
||||
当大陆执行压力不够时，扩容顺序建议为：
|
||||
|
||||
1. 新增大陆 Worker 机器
|
||||
2. 如果 Redis 压力增大，再拆 Redis
|
||||
3. 如果运行库写入压力增大，再拆运行库
|
||||
4. 国外主库继续作为最终结果主库，不参与高频任务调度
|
||||
|
||||
后续结构示意：
|
||||
|
||||
```text
|
||||
国外
|
||||
├── web + api + postgresql_main
|
||||
└── backup / archive
|
||||
|
||||
大陆
|
||||
├── redis + postgresql_runtime + scheduler
|
||||
├── worker-01
|
||||
├── worker-02
|
||||
├── worker-03
|
||||
└── worker-N
|
||||
```
|
||||
|
||||
## 五、数据分层
|
||||
|
||||
### 1. 结果态数据
|
||||
|
||||
这类数据保存在国外主库：
|
||||
|
||||
- 域名主数据
|
||||
- 检测最终结果
|
||||
- 黑名单结论
|
||||
- 导出记录
|
||||
- 审核记录
|
||||
- 系统配置
|
||||
- 操作审计
|
||||
|
||||
特点：
|
||||
|
||||
- 最终一致
|
||||
- 生命周期长
|
||||
- 提供给后台页面和运营使用
|
||||
|
||||
### 2. 运行态数据
|
||||
|
||||
这类数据优先保存在大陆执行面：
|
||||
|
||||
- 任务领取状态
|
||||
- 任务租约
|
||||
- 节点心跳
|
||||
- 当前阶段
|
||||
- 实时日志事件
|
||||
- 重试信息
|
||||
- 本地暂存结果
|
||||
|
||||
特点：
|
||||
|
||||
- 高频读写
|
||||
- 延迟敏感
|
||||
- 主要服务于 Worker 协作和调度
|
||||
|
||||
## 六、任务模型
|
||||
|
||||
当前项目还偏向单机 Worker 直接扫描 `domains` 表的模式。正式多机化后，建议改为显式任务模型。
|
||||
|
||||
### 1. 核心表建议
|
||||
|
||||
建议新增：
|
||||
|
||||
- `detect_jobs`
|
||||
- `detect_job_items`
|
||||
- `detect_worker_nodes`
|
||||
- `detect_run_events`
|
||||
- `detect_sync_records`
|
||||
|
||||
### 2. detect_jobs
|
||||
|
||||
表示一轮检测任务。
|
||||
|
||||
建议字段：
|
||||
|
||||
- `id`
|
||||
- `job_code`
|
||||
- `source`
|
||||
- `plan_hash`
|
||||
- `status`
|
||||
- `created_at`
|
||||
- `started_at`
|
||||
- `finished_at`
|
||||
- `created_by`
|
||||
- `remark`
|
||||
|
||||
说明：
|
||||
|
||||
- `plan_hash` 用于标识本轮检测所使用的规则版本和参数快照
|
||||
- 一轮任务可以对应大量域名任务项
|
||||
|
||||
### 3. detect_job_items
|
||||
|
||||
表示单个域名的具体任务项。
|
||||
|
||||
建议字段：
|
||||
|
||||
- `id`
|
||||
- `job_id`
|
||||
- `domain_id`
|
||||
- `status`
|
||||
- `claimed_by`
|
||||
- `claim_token`
|
||||
- `lease_expires_at`
|
||||
- `attempt_count`
|
||||
- `last_error`
|
||||
- `started_at`
|
||||
- `finished_at`
|
||||
- `result_version`
|
||||
- `updated_at`
|
||||
|
||||
建议唯一约束：
|
||||
|
||||
- `unique(job_id, domain_id)`
|
||||
|
||||
说明：
|
||||
|
||||
- 多台 Worker 只抢 `status=pending` 且未被占用或租约已过期的任务
|
||||
- `claim_token` 用于避免状态回写串单
|
||||
- `lease_expires_at` 用于机器故障后的任务回收
|
||||
|
||||
### 4. detect_worker_nodes
|
||||
|
||||
表示 Worker 节点。
|
||||
|
||||
建议字段：
|
||||
|
||||
- `node_code`
|
||||
- `region`
|
||||
- `role`
|
||||
- `hostname`
|
||||
- `ip`
|
||||
- `status`
|
||||
- `worker_version`
|
||||
- `last_heartbeat_at`
|
||||
- `current_load`
|
||||
- `remark`
|
||||
|
||||
说明：
|
||||
|
||||
- 后台后续可以直接展示“哪个节点在线、哪个节点在跑、当前负载多少”
|
||||
|
||||
### 5. detect_run_events
|
||||
|
||||
表示高价值阶段日志。
|
||||
|
||||
建议字段：
|
||||
|
||||
- `id`
|
||||
- `job_id`
|
||||
- `job_item_id`
|
||||
- `node_code`
|
||||
- `event_type`
|
||||
- `level`
|
||||
- `message`
|
||||
- `payload_json`
|
||||
- `created_at`
|
||||
|
||||
说明：
|
||||
|
||||
- 页面展示优先依赖事件流，不直接硬依赖某一台机器本地日志文件
|
||||
- 原始大日志仍保留在大陆 Worker 本地
|
||||
|
||||
## 七、多机抢任务与去重
|
||||
|
||||
### 1. 抢任务方式
|
||||
|
||||
推荐使用数据库租约模型：
|
||||
|
||||
- Worker 从 `detect_job_items` 中领取一批待处理任务
|
||||
- 使用 `FOR UPDATE SKIP LOCKED` 或原子更新方式抢占
|
||||
- 领取后写入：
|
||||
- `claimed_by`
|
||||
- `claim_token`
|
||||
- `lease_expires_at`
|
||||
|
||||
### 2. 去重原则
|
||||
|
||||
多机环境下，去重不能依赖“约定不重复”，必须依赖数据库约束和租约。
|
||||
|
||||
至少保证：
|
||||
|
||||
- 同一轮 `job_id` 下，同一域名只出现一条任务项
|
||||
- 同一任务项同一时刻只允许被一个 `claim_token` 持有
|
||||
- 回写结果时校验 `claim_token`
|
||||
|
||||
### 3. 续租机制
|
||||
|
||||
Worker 执行过程中应定期续租：
|
||||
|
||||
- 每 `30-60` 秒续租一次
|
||||
- 续租时更新 `lease_expires_at`
|
||||
- 如果节点挂掉，租约到期后其他 Worker 可重新领取
|
||||
|
||||
当前代码已实现的原则是：
|
||||
|
||||
- 任务被领取后进入 `claimed / running`
|
||||
- 检测步骤执行过程中会持续续租
|
||||
- 若任务长期未续租且租约过期，会自动回收到 `pending`
|
||||
|
||||
这样可以避免：
|
||||
|
||||
- 长任务跑到一半租约失效
|
||||
- Worker 异常退出后任务永远卡死
|
||||
- 后续多机扩容时出现大量“假占用”
|
||||
|
||||
### 4. 失败重试
|
||||
|
||||
建议对失败进行分类：
|
||||
|
||||
- 网络失败
|
||||
- 代理失败
|
||||
- 第三方目标站异常
|
||||
- 程序逻辑失败
|
||||
|
||||
可按类型控制重试次数，不要无限重试。
|
||||
|
||||
### 5. 当前代码与目标模型的关系
|
||||
|
||||
当前代码里，运行态表和节点心跳已经具备，但主检测流程仍以现有 `domains` / `detect_status` 链路为主。
|
||||
|
||||
这意味着：
|
||||
|
||||
- 现在已经可以先把“多机可见性”和“节点骨架”跑起来
|
||||
- 下一步要把“检测入口”从直接扫 `domains`，逐步切到 `detect_jobs + detect_job_items`
|
||||
- 切换时必须保留旧链路回退能力，避免一次性重写导致现网不稳
|
||||
|
||||
## 八、同步策略
|
||||
|
||||
### 1. 国外到大陆
|
||||
|
||||
同步内容：
|
||||
|
||||
- 系统配置
|
||||
- 检测规则
|
||||
- 敏感词版本
|
||||
- 任务创建命令
|
||||
|
||||
特点：
|
||||
|
||||
- 低频
|
||||
- 要求可靠
|
||||
- 可版本化
|
||||
|
||||
### 2. 大陆到国外
|
||||
|
||||
同步内容：
|
||||
|
||||
- 任务进度摘要
|
||||
- 关键阶段事件
|
||||
- 最终检测结果
|
||||
- 黑名单结论
|
||||
- 归档日志包索引
|
||||
|
||||
特点：
|
||||
|
||||
- 高频部分只传摘要和关键事件
|
||||
- 最终结果必须幂等
|
||||
|
||||
### 3. 幂等要求
|
||||
|
||||
结果同步到国外时，必须支持幂等：
|
||||
|
||||
- 同一 `job_item_id` 重复上报不应产生重复结果
|
||||
- 同一域名同一轮任务只保留最终有效状态
|
||||
|
||||
### 4. 推荐同步落地方式
|
||||
|
||||
第一阶段不建议直接做数据库双向复制，更推荐独立同步服务：
|
||||
|
||||
- 大陆执行面负责写本地运行态
|
||||
- `sync-service` 负责批量汇总结果与事件
|
||||
- 国外控制面负责接收、落库、归档
|
||||
|
||||
推荐第一阶段同步内容：
|
||||
|
||||
- 最终检测结果
|
||||
- 关键阶段事件
|
||||
- 失败摘要
|
||||
- 节点健康摘要
|
||||
- 配置快照版本
|
||||
|
||||
不建议第一阶段同步：
|
||||
|
||||
- 全量原始日志
|
||||
- 高频心跳明细
|
||||
- 临时抓取中间产物
|
||||
|
||||
原因：
|
||||
|
||||
- 成本高
|
||||
- 跨地域网络抖动会放大耦合
|
||||
- 对运营后台价值不成比例
|
||||
|
||||
## 九、部署建议
|
||||
|
||||
### 1. 国外机器
|
||||
|
||||
目录建议：
|
||||
|
||||
```text
|
||||
/opt/domaincheck
|
||||
├── domain-api
|
||||
├── domain-web
|
||||
└── shared
|
||||
```
|
||||
|
||||
部署角色：
|
||||
|
||||
- `web`
|
||||
- `api`
|
||||
- `postgresql_main`
|
||||
|
||||
### 2. 大陆调度中心
|
||||
|
||||
目录建议：
|
||||
|
||||
```text
|
||||
/opt/domaincheck
|
||||
├── domainCheck
|
||||
├── runtime-db
|
||||
├── redis
|
||||
└── shared
|
||||
```
|
||||
|
||||
部署角色：
|
||||
|
||||
- `scheduler`
|
||||
- `redis`
|
||||
- `postgresql_runtime`
|
||||
- `worker`
|
||||
|
||||
### 3. 大陆纯 Worker 节点
|
||||
|
||||
目录建议：
|
||||
|
||||
```text
|
||||
/opt/domaincheck
|
||||
├── domainCheck
|
||||
└── shared
|
||||
```
|
||||
|
||||
部署角色：
|
||||
|
||||
- `worker`
|
||||
|
||||
### 4. 一键化原则
|
||||
|
||||
部署脚本必须满足：
|
||||
|
||||
- 新机器只需要少量环境变量
|
||||
- 不要求现场手工改很多路径
|
||||
- 国外机和大陆机各自有独立入口脚本
|
||||
- 后续新增大陆 Worker 节点继续复用同一脚本
|
||||
|
||||
### 5. 当前建议的最小部署
|
||||
|
||||
当前最适合正式起步的形态：
|
||||
|
||||
- 国外 `1` 台：
|
||||
- `domain-web`
|
||||
- `domain-api`
|
||||
- 国外主 PostgreSQL
|
||||
- 大陆 `1` 台：
|
||||
- `redis`
|
||||
- 大陆运行库 PostgreSQL
|
||||
- `detect-worker`
|
||||
- 后续可补 `sync-service`
|
||||
|
||||
扩容时优先：
|
||||
|
||||
1. 新增大陆 Worker
|
||||
2. 再视压力拆分大陆运行库与 Redis
|
||||
3. 国外控制面保持稳定，不跟着高频扩缩
|
||||
|
||||
## 十、阶段性落地建议
|
||||
|
||||
### 第一阶段
|
||||
|
||||
先完成：
|
||||
|
||||
- 国外控制面部署
|
||||
- 大陆单机执行面部署
|
||||
- 节点注册与心跳
|
||||
- 当前后台继续可用
|
||||
|
||||
### 第二阶段
|
||||
|
||||
再完成：
|
||||
|
||||
- 任务项模型
|
||||
- 多 Worker 抢任务
|
||||
- 事件日志流
|
||||
- 结果异步同步回国外
|
||||
|
||||
### 第三阶段
|
||||
|
||||
最后完成：
|
||||
|
||||
- 大陆多 Worker 横向扩容
|
||||
- 运行库与调度中心独立拆分
|
||||
- 国外归档和监控补齐
|
||||
|
||||
## 十一、运行与观测建议
|
||||
|
||||
多机之后，不能再只靠“登录某台机器 tail 日志”来判断系统状态。
|
||||
|
||||
建议分层：
|
||||
|
||||
- 大陆 Worker 本地保留完整原始日志
|
||||
- `detect_run_events` 保存关键阶段事件
|
||||
- 国外后台优先展示事件流、节点负载和同步状态
|
||||
- 真排障时再下钻到具体节点原始日志
|
||||
|
||||
后台建议优先展示：
|
||||
|
||||
- 当前在线节点数
|
||||
- 每节点最近心跳
|
||||
- 每节点当前负载
|
||||
- 当前活跃任务数
|
||||
- 队列积压与最老待领年龄
|
||||
- 租约是否过期、是否即将到期
|
||||
- 近 15 分钟每节点吞吐
|
||||
- 最近失败摘要
|
||||
- 最近同步结果
|
||||
- 最近结果摘要投影
|
||||
|
||||
## 十二、下一阶段开发清单
|
||||
|
||||
接下来建议按下面顺序继续落地：
|
||||
|
||||
1. 后台创建 `detect_jobs / detect_job_items`
|
||||
2. Worker 实现批量 claim / renew / finish / fail
|
||||
3. 增加租约超时回收
|
||||
4. 将检测阶段事件写入 `detect_run_events`
|
||||
5. 增加 `sync-service`
|
||||
6. 完成第二台大陆 Worker 接入演练
|
||||
|
||||
## 十三、最终建议
|
||||
|
||||
对当前项目来说，最优解不是“全部放国外”，也不是“全部放大陆”，而是：
|
||||
|
||||
- 国外做控制面和主结果库
|
||||
- 大陆做执行面和运行态调度
|
||||
- 先从 `国外 1 台 + 大陆 1 台` 起步
|
||||
- 后续优先横向增加大陆 Worker
|
||||
|
||||
一句话总结：
|
||||
|
||||
> 先把职责边界设计对，再让部署简单；后续扩容时只加 Worker，不再重构核心架构。
|
||||
Reference in New Issue
Block a user