getDomain/docs/ops_center_runtime/IMPLEMENTATION_STATUS.md

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%

在那之前，当前口径应保持保守。