484 lines
15 KiB
Markdown
484 lines
15 KiB
Markdown
# IMPLEMENTATION_STATUS
|
||
|
||
更新时间：2026-04-19 21:25 CST
|
||
|
||
## 当前真实状态
|
||
|
||
阶段判断：
|
||
|
||
- 海外单脑接管能力：约 `97%`
|
||
- 发布闭环真实可用度：约 `65%~70%`
|
||
- 分布式检测真实执行能力：约 `80%~85%`
|
||
- 距离“可稳定上线并放心用后台发起检测”：约 `78%~82%`
|
||
|
||
## 21:17 最新校正
|
||
|
||
刚完成的 `mainland-worker-01` 正式 rollout 已给出最终根因：
|
||
|
||
- `job 211 / rollout 6 / release 7`
|
||
- 发布包下载成功
|
||
- release 解压成功
|
||
- `current` 软链切换成功
|
||
- 最终失败在服务重启：
|
||
- `restart failed: domaincheck-worker`
|
||
- `Failed to restart domaincheck-worker.service: Interactive authentication required.`
|
||
|
||
这说明：
|
||
|
||
- 当前 ReleaseHub 主链路本身已可推进到“切换 current”
|
||
- 真正未闭环的是 mainland node-agent 的 systemd 权限
|
||
- 只要 node-agent 仍以 `www` 运行，后续 `deploy.release / service.restart` 都会在 systemd 这一跳失败
|
||
|
||
已完成的代码侧修正：
|
||
|
||
- `domain-api/deploy/systemd/domain-node-agent.service`
|
||
- 改为 `User=root`
|
||
- 改为 `Group=root`
|
||
- `domain-api/deploy/multi-region/fix_mainland_release_base.sh`
|
||
- 改为给 node-agent drop-in 写入 `User=root` / `Group=root`
|
||
|
||
因此当前真实上线完成度需要再补一句校正：
|
||
|
||
- 发布闭环真实可用度：
|
||
- 不是“发布包模型还没修”
|
||
- 而是“node-agent 权限模型还差最后一次现网切换”
|
||
|
||
## 21:25 最新进展
|
||
|
||
worker 侧的现网切换已经完成验证成功：
|
||
|
||
- `mainland-worker-01`
|
||
- 已把 `domaincheck-node-agent` 切为 `root`
|
||
- 随后重新发起：
|
||
- `rollout_id = 7`
|
||
- `job_id = 214`
|
||
- 最终结果：
|
||
- `job 214 = success`
|
||
- `rollout 7 = completed`
|
||
|
||
正式成功证据：
|
||
|
||
- `agent_completed`
|
||
- `summary_text = release deployed`
|
||
- `restart_results[domaincheck-worker].returncode = 0`
|
||
- `health_check.ok = true`
|
||
- `systemd ExecStart` 已对齐：
|
||
- `/opt/domaincheck/current/domainCheck/detect_worker.py`
|
||
|
||
因此当前关于发布闭环的真实判断应更新为：
|
||
|
||
- worker 发布闭环：
|
||
- 已从“卡在 systemd restart 权限”推进到“真实成功”
|
||
- 当前剩余风险不再在 worker
|
||
- 当前剩余预防项在 controller：
|
||
- `domaincheck-node-agent` 也应同步切为 `root`
|
||
|
||
## 顶部校正
|
||
|
||
今天晚上的最新结论，需要覆盖前面一部分偏乐观判断：
|
||
|
||
- 最新发布包问题已经定位并修复：
|
||
- 之前发布包漏掉了 `domainCheck/`
|
||
- 现在最新签收包 `domaincheck_release_20260419_205437` 已经包含 `domainCheck/`
|
||
- 但对 `mainland-worker-01` 的正式发布验证证明：
|
||
- 线上 mainland 节点目前还不满足现有 ReleaseHub 发布模型
|
||
- 已确认的真实阻塞有两个：
|
||
- `deploy.release` 在 `mainland-worker-01` 上会因为
|
||
- `Permission denied: /opt/domaincheck/downloads`
|
||
- 而直接失败
|
||
- mainland 两台节点当前 `domaincheck-worker` 的 `ExecStart` 都直接指向：
|
||
- `/opt/domaincheck/domainCheck/detect_worker.py`
|
||
- 而不是 `/opt/domaincheck/current/domainCheck/detect_worker.py`
|
||
|
||
这两个事实组合起来说明：
|
||
|
||
- 当前发布链虽然在控制面上已经成型
|
||
- 但 mainland 线上节点的安装形态还是旧模式
|
||
- 所以当前不能再把“已能稳定 rollout 新版本”算进上线完成度
|
||
|
||
## 今晚新增硬证据
|
||
|
||
- `mainland-worker-01`
|
||
- `job 204 / rollout 5` 已正式失败回写
|
||
- 失败原因已收口为：
|
||
- `install_root not writable: /opt/domaincheck/downloads`
|
||
- 只读核验得到的实际服务状态仍是旧进程：
|
||
- `Active since Sun 2026-04-19 18:18:50 CST`
|
||
- `Main PID = 635924`
|
||
- `CPU = 18.994s`
|
||
- 说明 worker 当前并没有切到新包，也没有形成可信的新吞吐样本
|
||
- `mainland-controller-01`
|
||
- 当前 `domaincheck-worker` 虽然在高负载运行
|
||
- 但服务启动路径同样是：
|
||
- `/opt/domaincheck/domainCheck/detect_worker.py`
|
||
- 说明 controller 也没有对齐 `current` 软链发布模型
|
||
|
||
## 本轮代码侧新增收口
|
||
|
||
- 已补齐发布包构建：
|
||
- `package_domain_release.sh`
|
||
- `verify_domain_release.sh`
|
||
- `package_domain_release.ps1`
|
||
- `verify_domain_release.ps1`
|
||
- 现在发布包会包含 `domainCheck/`
|
||
- 已补齐发布执行器的失败可观测性：
|
||
- `domain-api/app/services/ops_release_executor_core.py`
|
||
- 现在会在发布目录不可写时显式返回失败结果
|
||
- 同时补充 `ExecStart` 与 `current` 软链的对齐观测
|
||
- 已补齐 node-agent 的兜底失败回写：
|
||
- `domain-api/app/node_agent.py`
|
||
- 避免以后再出现任务已经炸掉但控制面一直卡在 `running`
|
||
|
||
## 本轮最新结论
|
||
|
||
新增结论：
|
||
|
||
- 检测页观察面已完成一轮线上收口：
|
||
- `任务日志控制台` 已移到事件表上方
|
||
- `检测事件流` 已改成独立滚动区
|
||
- 已在真实线上静态目录重建生产包并通过本机 `3201` 端口验证
|
||
- 当前如果用户仍看到旧布局，优先判断为浏览器缓存而不是部署未生效
|
||
- 代理链已完成策略切换：
|
||
- worker 启动后会主动刷新代理池
|
||
- 配置更新后也会主动刷新代理池
|
||
- 后台已能区分：
|
||
- `等待首刷`
|
||
- `proxy_validation_zero`
|
||
- `直入池`
|
||
- 当前本机最新真实结果是：
|
||
- 原始代理 `270`
|
||
- 预验证 `0`
|
||
- 直入池 `270`
|
||
- 说明当前问题已经从“代理校验过严导致池为空”切换为“真实任务内动态淘汰失效代理”
|
||
|
||
- `mainland-controller-01`
|
||
- 已确认解除“代理不足即同步刷新、反向压死并发”的旧限制
|
||
- 海外后台当前已能看到：
|
||
- `active_threads = 99~100`
|
||
- `max_threads = 100`
|
||
- 说明 controller 的 `100` 并发已经真实生效
|
||
- `mainland-worker-01`
|
||
- 已重新部署最新版 `detect_worker.py`
|
||
- 已重新接收新的 `sync-pull` 批次并重进检测：
|
||
- `开始执行域名检测任务`
|
||
- `开始检测，刷新代理池`
|
||
- `代理池刷新完成，共 23 个可用代理`
|
||
- `开始创建线程，当前批次域名数: 400，最大线程数: 50`
|
||
- 当前 worker 进程本机线程量已到：
|
||
- `152` 个 OS 线程
|
||
- 说明它并不是没启动，而是已经进入新批次执行
|
||
- 当前剩余偏差：
|
||
- overseas 后台对 `mainland-worker-01.active_threads/current_load` 的显示仍偏低
|
||
- 这已经从“真实执行问题”收敛为“运行态上报 / 显示口径问题”
|
||
|
||
这一轮不是只修了显示问题，而是把“大陆节点真实执行 + worker 日志回传”一起补齐了。
|
||
|
||
当前最新结论：
|
||
|
||
- controller 的 `pull_tasks -> 本地队列` 断点已经修通
|
||
- 两台大陆 worker 都已经进入真实镜像队列执行
|
||
- `mainland-worker-01` 的 `worker_log` 已开始直接回灌 overseas `detect_debug_events`
|
||
- `runtime_projection` 权限问题已经修复，后台运行态同步恢复
|
||
- `/api/v1/ops/nodes` 已能证明 controller 的高并发真实生效
|
||
- 当前剩余问题已经收敛为：
|
||
- `mainland-worker-01` 运行态显示口径仍需继续对齐
|
||
- 检测页主计数口径是否完全跟上
|
||
- 结果统计回推是否持续稳定
|
||
|
||
## 当前证据拆分
|
||
|
||
### 1. 代码闭环
|
||
|
||
已经完成：
|
||
|
||
- `sync_push_service.ingest_detect_task_projection`
|
||
- 不再只导入 `domains`
|
||
- 已改为同时创建本地 `detect_jobs`
|
||
- 已改为同时创建本地 `detect_job_items`
|
||
- 已把 `target_job_id / target_job_code / queued_count / worker_start_ok` 回写到同步结果
|
||
- `sync_agent`
|
||
- controller 现在会在每轮 `pull_tasks` 后自动唤起本地 worker
|
||
- `detect_worker._set_active_cycle_context`
|
||
- 已兼容 `sync-pull` 控制消息
|
||
- 不再只读取 `job_id / job_code`
|
||
- 现在会回退读取 `target_job_id / target_job_code`
|
||
- 运行态同步链
|
||
- controller `runtime/detect_runs.json` 权限已修正为 `www:www`
|
||
- `runtime_projection` 已恢复成功推送
|
||
|
||
本地代码验证已通过：
|
||
|
||
- `python -m py_compile domain-api/app/services/sync_push_service.py`
|
||
- `python -m py_compile domain-api/app/services/runtime_control_service.py`
|
||
- `python -m py_compile domain-api/app/sync_agent.py`
|
||
- `python -m py_compile domainCheck/detect_worker.py`
|
||
|
||
### 2. 接管 / 外部条件闭环
|
||
|
||
已经完成：
|
||
|
||
- `remote_access_ready = 3/3`
|
||
- `ssh_ready = 2`
|
||
- 大陆 controller / worker 都可远程运维
|
||
- controller `domaincheck-sync-agent` 在线
|
||
- mainland 两台 `domaincheck-node-agent` 在线
|
||
|
||
当前仍依赖你额外输入的部分：
|
||
|
||
- 暂无新的 SSH / 接管前置输入缺口
|
||
- 如果页面仍显示旧状态，最多只需要你浏览器强刷确认，不需要再补 SSH 信息
|
||
|
||
### 2.1 前端部署闭环
|
||
|
||
已经完成：
|
||
|
||
- 在线静态根目录确认：
|
||
- `/www/wwwroot/getDomain/domain-web/dist`
|
||
- 在线 Nginx 配置确认：
|
||
- `/www/server/panel/vhost/nginx/domaincheck_3201.conf`
|
||
- `/www/server/panel/vhost/nginx/domaincheck_152.53.37.118.conf`
|
||
- 生产包重建确认：
|
||
- `vite build` 成功
|
||
- 线上资源确认：
|
||
- `DetectView-B9S1WMRT.js`
|
||
- `DetectView-BFxMNRNR.css`
|
||
|
||
说明：
|
||
|
||
- 检测页布局调整不是只停留在源码
|
||
- 已经进入线上可访问静态产物
|
||
|
||
### 2.2 代理运行态闭环
|
||
|
||
已经完成：
|
||
|
||
- worker 启动即触发代理池首刷
|
||
- 配置变更后自动补刷
|
||
- API 状态页已能准确显示：
|
||
- `proxy_not_refreshed_yet`
|
||
- `proxy_validation_zero`
|
||
- `宽松入池`
|
||
|
||
当前最新证据：
|
||
|
||
- `proxy_last_refresh_status = 直入池 270 个（跳过预验证）`
|
||
- `proxy_last_refresh_total_items = 270`
|
||
- `proxy_last_validated_count = 0`
|
||
- `proxy_last_available_count = 270`
|
||
|
||
说明：
|
||
|
||
- 代理配置本身已成功下发
|
||
- 代理源接口本身也能返回大量原始代理
|
||
- 当前不再把“预验证是否通过”作为入池门槛
|
||
- 现在改为让真实检测来完成失效代理淘汰
|
||
|
||
### 3. 检测执行闭环
|
||
|
||
这一块现在已经从“怀疑恢复”进入“确认恢复”：
|
||
|
||
- `mainland-controller-01`
|
||
- 已出现：
|
||
- `从任务队列获取到 800 个需要检测的域名`
|
||
- `最大线程数: 100`
|
||
- `当前实际线程数量: 1/100 ... 6/100`
|
||
- `mainland-worker-01`
|
||
- 已出现：
|
||
- `从任务队列获取到 400 个需要检测的域名`
|
||
- `开始创建线程，当前批次域名数: 400，最大线程数: 50`
|
||
- `当前实际线程数量: 1/50 ... 3/50`
|
||
- `开始检测域名: 0-demagogo.com`
|
||
- `开始检测域名: 00123321.com`
|
||
- `开始检测域名: 001dm.com`
|
||
|
||
这说明：
|
||
|
||
- `100/50` 已不是“配置已写入但没生效”
|
||
- 它已经进入真实任务消费
|
||
- worker 的远端日志也已经跟着真实执行一起回传
|
||
|
||
### 4. 海外后台可视证据
|
||
|
||
`/api/v1/ops/nodes` 当前已显示：
|
||
|
||
- `summary.remote_access_ready = 3`
|
||
- `summary.participating = 3`
|
||
- `summary.dispatch_active = 1`
|
||
|
||
并且大陆两台都已经被判定为真实参与者：
|
||
|
||
- `mainland-controller-01`
|
||
- `agent_state = online_busy`
|
||
- `participation_state = recent_throughput`
|
||
- `processed_recent = 115`
|
||
- `processed_per_minute = 7.67`
|
||
- `detect_runtime.max_threads = 100`
|
||
- `mainland-worker-01`
|
||
- `agent_state = online_busy`
|
||
- `participation_state = recent_throughput`
|
||
- `processed_recent = 632`
|
||
- `processed_per_minute = 42.13`
|
||
- `detect_runtime.max_threads = 50`
|
||
|
||
这说明：
|
||
|
||
- 海外后台已经不只是看到“在线”
|
||
- 现在已经能看到大陆节点的实际吞吐
|
||
|
||
## 本轮新增硬证据
|
||
|
||
### 证据 1：controller 的镜像队列已经真正落库
|
||
|
||
`sync-agent` 现场日志已出现：
|
||
|
||
- `target_job_code = sync-overseas-7380`
|
||
- `queued_count = 200`
|
||
- `worker_start_ok = True`
|
||
|
||
并持续产生：
|
||
|
||
- `sync-overseas-7383`
|
||
- `sync-overseas-7386`
|
||
- `sync-overseas-7392`
|
||
- `sync-overseas-7417`
|
||
|
||
说明：
|
||
|
||
- 大陆 controller 现在不是只拉数据
|
||
- 而是在持续形成可执行批次
|
||
|
||
### 证据 2：两台大陆 worker 都已转入真实队列
|
||
|
||
现场日志已明确出现：
|
||
|
||
- controller：
|
||
- `从任务队列获取到 800 个需要检测的域名`
|
||
- worker：
|
||
- `从任务队列获取到 400 个需要检测的域名`
|
||
|
||
说明：
|
||
|
||
- 当前不是兼容旧链路假运行
|
||
- 是镜像队列真运行
|
||
|
||
### 证据 3：runtime_projection 已恢复成功
|
||
|
||
修复前：
|
||
|
||
- `refresh runtime_projection failed: [Errno 13] Permission denied`
|
||
|
||
修复后：
|
||
|
||
- 最新 `sync-agent` 日志已出现：
|
||
- `sync_state = success`
|
||
- `runtime_projection -> 投影推送成功`
|
||
|
||
说明：
|
||
|
||
- 后台运行态刷新和日志窗口不再被 controller 本地权限卡死
|
||
|
||
### 证据 4：`mainland-worker-01` 的 `worker_log` 已进入 overseas
|
||
|
||
`/api/v1/runtime/debug-events` 当前已能看到：
|
||
|
||
- `mainland-worker-01 -> 开始执行检测任务，来源: redis-control`
|
||
- `mainland-worker-01 -> 开始执行域名检测任务，正在加载配置`
|
||
- `mainland-worker-01 -> 开始检测，正在刷新代理池`
|
||
- `mainland-worker-01 -> 代理池刷新完成，共 7 个可用代理，来源链接 6 个，原始 265 个，验证 150 个`
|
||
- `mainland-worker-01 -> 从任务队列获取到 400 个需要检测的域名`
|
||
- `mainland-worker-01 -> 开始创建线程，当前批次域名数: 400，最大线程数: 50`
|
||
- `mainland-worker-01 -> 当前实际线程数量: 1/50`
|
||
- `mainland-worker-01 -> 当前实际线程数量: 2/50`
|
||
- `mainland-worker-01 -> 当前实际线程数量: 3/50`
|
||
|
||
说明：
|
||
|
||
- worker 的真实执行链已经进入 overseas 的日志视图
|
||
- “后台看不到大陆 worker 在干活”这一层已经闭合
|
||
|
||
## 当前口径说明
|
||
|
||
这里有一个非常关键的判断口径已经变化：
|
||
|
||
- 大陆节点当前执行的是“海外任务在大陆本地落镜像队列，再把运行态和结果同步回海外”
|
||
- 因此不能再只盯中央原生 `detect_job_items.claimed/running`
|
||
- 现在应该同时看：
|
||
- `/api/v1/ops/nodes`
|
||
- `processed_recent`
|
||
- `processed_per_minute`
|
||
- `detect_runtime.active_threads/max_threads`
|
||
- 大陆 controller 本地 `sync-overseas-*` 队列
|
||
|
||
如果只看中央原生队列，会误判“大陆没有参与”。
|
||
|
||
## 当前已闭合的问题
|
||
|
||
已闭合：
|
||
|
||
- controller `pull_tasks` 只导入 domain、不导入本地队列
|
||
- 大陆 worker 长时间卡在旧检测会话导致忽略新启动指令
|
||
- controller `runtime_projection` 因文件属主错误无法推送
|
||
- 大陆两台“在线但不确定是否真实执行”的状态模糊
|
||
|
||
## 当前剩余问题
|
||
|
||
当前剩余问题已经缩成两个最小项：
|
||
|
||
- Detect 页面主计数 `pending/completed/running` 是否继续推进
|
||
- 结果统计回推是否稳定，而不只是日志链路先恢复
|
||
|
||
换句话说：
|
||
|
||
- 现在不是接管问题
|
||
- 不是链路不通问题
|
||
- 不是日志完全回不来问题
|
||
- 而是最后一层“主计数推进 + 结果统计收口”问题
|
||
|
||
## 当前是否可以继续跑检测测试
|
||
|
||
当前结论：
|
||
|
||
- 可以继续跑检测测试
|
||
- 而且现在已经具备“后台可观测 + 大陆真实参与”的条件
|
||
|
||
## 当前是否建议直接上线
|
||
|
||
当前结论：
|
||
|
||
- 已接近可上线状态
|
||
- 但我仍建议把它视为“准上线收口态”，不是最终完全签收态
|
||
|
||
原因：
|
||
|
||
- 主执行链已经恢复
|
||
- 但还需要再确认 1 到 2 个同步周期内页面口径与吞吐稳定性
|
||
|
||
## 当前优先级判断
|
||
|
||
最高优先级：
|
||
|
||
- `J2-检测执行收口批`
|
||
|
||
当前不应继续推进：
|
||
|
||
- 新控制面功能
|
||
- 新模块
|
||
- 新页面
|
||
- 发布动作
|
||
- 与检测执行收口无关的工作
|
||
|
||
## 完成下一轮后的预期
|
||
|
||
如果下一轮确认：
|
||
|
||
- Detect 页面主计数已跟上
|
||
- 日志窗口持续刷新
|
||
- `detect_result_projection` 持续推进
|
||
- `processed_recent / processed_per_minute` 持续增长
|
||
|
||
则整体可上线程度预计可提升到：
|
||
|
||
- `96%~98%`
|
||
|
||
在那之前，当前口径应保持保守。
|