2026-05-25-10-21-17 部署并验证 ReVoxelSeg DICOM 服务
This commit is contained in:
58
工程分析/实现方案-2026-05-25-10-21-17.md
Normal file
58
工程分析/实现方案-2026-05-25-10-21-17.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# 实现方案-2026-05-25-10-21-17
|
||||
|
||||
## 实现方案文档路径
|
||||
|
||||
`工程分析/实现方案-2026-05-25-10-21-17.md`
|
||||
|
||||
## 修改目标
|
||||
|
||||
完成一次无源码变更的重新部署，恢复并验证 `https://revoxel.huijutec.cn/` 服务。
|
||||
|
||||
## 涉及路径
|
||||
|
||||
- `WebSite/`
|
||||
- `WebSite/server.ts`
|
||||
- `WebSite/vite.config.ts`
|
||||
- `工程分析/需求分析-2026-05-25-10-21-17.md`
|
||||
- `工程分析/实现方案-2026-05-25-10-21-17.md`
|
||||
- `工程分析/测试方案-2026-05-25-10-21-17.md`
|
||||
- `工程分析/经验记录.md`
|
||||
|
||||
## 技术路线
|
||||
|
||||
1. 检查工作区状态、`WebSite` 脚本和当前 `tmux`/端口占用情况。
|
||||
2. 在 `WebSite` 执行 `npm run build`，确认生产构建通过。
|
||||
3. 若公网首页被 Vite host 检查拦截，将 `revoxel.huijutec.cn` 加入 Vite `allowedHosts`。
|
||||
4. 使用 `tmux` 会话 `revoxelseg-dicom` 启动或重启：
|
||||
`npm run serve -- --host 0.0.0.0 --port 4000`
|
||||
5. 通过本机和公网地址验证服务。
|
||||
6. 追加经验记录，提交本次工程分析文档和明确属于本次部署修复的配置变更。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
- 执行前再次确认已读 `工程分析/经验记录.md`。
|
||||
- 若存在旧 `tmux` 服务，向会话发送 `Ctrl-C` 后重新启动。
|
||||
- 若不存在旧会话，创建 `tmux new-session -d -s revoxelseg-dicom`。
|
||||
- 使用 `curl` 验证：
|
||||
- `http://127.0.0.1:4000/api/health`
|
||||
- `http://127.0.0.1:4000/`
|
||||
- `https://revoxel.huijutec.cn/`
|
||||
|
||||
## 兼容性与回滚方案
|
||||
|
||||
- 若新服务启动失败，可保留构建日志并重新启动旧服务命令。
|
||||
- 若公网不可达但本机正常，需要继续排查 FRP、NPM 反向代理和域名链路。
|
||||
- 本次不改源码，回滚主要是停止新启动的 `tmux` 服务或恢复旧进程。
|
||||
|
||||
## 预计文件变更
|
||||
|
||||
- 新增本次三件套文档。
|
||||
- 追加 `工程分析/经验记录.md`。
|
||||
- `WebSite/server.ts` 和 `WebSite/vite.config.ts` 可能追加公网域名 allowedHosts。
|
||||
- `WebSite/dist/` 可能因构建更新，但不作为本次文档备份 commit 的目标。
|
||||
|
||||
## 提交与部署策略
|
||||
|
||||
- 先完成构建、部署与验证。
|
||||
- 暂存本次工程分析文档、经验记录和 allowedHosts 配置修复。
|
||||
- commit message 使用：`2026-05-25-10-21-17 部署并验证 ReVoxelSeg DICOM 服务`。
|
||||
48
工程分析/测试方案-2026-05-25-10-21-17.md
Normal file
48
工程分析/测试方案-2026-05-25-10-21-17.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# 测试方案-2026-05-25-10-21-17
|
||||
|
||||
## 测试方案文档路径
|
||||
|
||||
`工程分析/测试方案-2026-05-25-10-21-17.md`
|
||||
|
||||
## 静态检查
|
||||
|
||||
- 检查 `WebSite/package.json` 中构建和服务脚本存在。
|
||||
- 检查 `tmux` 会话与 `4000` 端口状态，避免重复服务冲突。
|
||||
|
||||
## 构建检查
|
||||
|
||||
- 在 `WebSite` 执行 `npm run build`。
|
||||
- 通过 Vite/TypeScript 构建输出确认无构建错误。
|
||||
|
||||
## 关键业务场景验证
|
||||
|
||||
- 验证 `/api/health` 返回健康状态。
|
||||
- 验证本机首页返回 HTML。
|
||||
- 验证公网域名 `https://revoxel.huijutec.cn/` 返回成功 HTTP 状态。
|
||||
- 若公网首页曾返回 Vite allowedHosts 403，需要重新验证首页不再出现 host 拦截文本。
|
||||
|
||||
## 医学影像数据相关边界验证
|
||||
|
||||
- 本次不修改 DICOM/STL 解析、分割映射、导出和位姿算法。
|
||||
- 部署验证只确认服务可访问，不重新生成医学数据或导出结果。
|
||||
|
||||
## 部署验证
|
||||
|
||||
- 服务命令：`npm run serve -- --host 0.0.0.0 --port 4000`。
|
||||
- 运行载体：`tmux` 会话 `revoxelseg-dicom`。
|
||||
- 验证地址：
|
||||
- `http://127.0.0.1:4000/api/health`
|
||||
- `http://127.0.0.1:4000/`
|
||||
- `https://revoxel.huijutec.cn/`
|
||||
|
||||
## Git/Gitea 备份验证
|
||||
|
||||
- 仅提交本次文档和经验记录。
|
||||
- commit message 包含 `2026-05-25-10-21-17`。
|
||||
- 提交前检查 `git status --short`，只混入本次 allowedHosts 配置修复和文档，避免混入无关源码或运行态产物。
|
||||
|
||||
## 风险与回归关注点
|
||||
|
||||
- 如果公网域名失败但本机成功，应归类为代理/隧道链路问题。
|
||||
- 如果构建失败，应停止部署并汇报具体错误。
|
||||
- 如果端口被非本项目进程占用，应先确认占用来源再处理。
|
||||
18
工程分析/经验记录.md
18
工程分析/经验记录.md
@@ -1887,3 +1887,21 @@ C. 解决问题方案
|
||||
D. 后续如何避免问题
|
||||
|
||||
自动优化类页面应优先提供可视化验证，而不是只展示候选表格。高精度 STL preview 继续使用 JSON 时，必须关注响应大小、压缩和代理限制；若后续仍遇到大模型传输问题，应考虑二进制 preview、分块流式加载或按切片局部计算，而不是继续扩大单次 JSON。
|
||||
|
||||
## 2026-05-25-10-21-17 公网部署需要同时验证首页和 API
|
||||
|
||||
A. 具体问题
|
||||
|
||||
用户要求重新部署 `https://revoxel.huijutec.cn/`。本机 `4000` 服务启动后，公网 `/api/health` 返回 200，但公网首页返回 403：`Blocked request. This host ("revoxel.huijutec.cn") is not allowed.`
|
||||
|
||||
B. 产生问题原因
|
||||
|
||||
当前约定的 `npm run serve` 默认未设置 `NODE_ENV=production`，Express 会挂载 Vite middleware，而不是只走 `dist/` 静态文件。Vite 6 会校验 Host，请求从公网域名进入时不在 `server.allowedHosts` 中，因此首页被 Vite 拦截；API 路由位于 Vite 中间件之前，所以 `/api/health` 仍然正常。
|
||||
|
||||
C. 解决问题方案
|
||||
|
||||
在 `WebSite/server.ts` 的 `createViteServer` 配置和 `WebSite/vite.config.ts` 中加入 `allowedHosts: ['revoxel.huijutec.cn']`，重新执行 `npm run build`，再用 `tmux` 会话 `revoxelseg-dicom` 启动 `npm run serve -- --host 0.0.0.0 --port 4000`。验证本机首页、本机 `/api/health`、公网首页和公网 `/api/health` 均返回 200。
|
||||
|
||||
D. 后续如何避免问题
|
||||
|
||||
部署验证不能只看 API 健康检查，还要同时验证首页 HTML，因为 Vite host 检查、静态资源路径和反代规则可能只影响页面入口。只要继续用 Vite middleware 方式提供公网访问，就要把公网域名写入 `allowedHosts`；如果后续改为 `NODE_ENV=production` 纯静态部署，也需要单独验证静态资源和 API 是否都通过同一反代链路。
|
||||
|
||||
45
工程分析/需求分析-2026-05-25-10-21-17.md
Normal file
45
工程分析/需求分析-2026-05-25-10-21-17.md
Normal file
@@ -0,0 +1,45 @@
|
||||
# 需求分析-2026-05-25-10-21-17
|
||||
|
||||
## 开始时间
|
||||
|
||||
2026-05-25-10-21-17
|
||||
|
||||
## 原始需求摘要
|
||||
|
||||
用户要求部署 `https://revoxel.huijutec.cn/` 对应的 ReVoxelSeg DICOM 项目，确保线上地址恢复可访问。
|
||||
|
||||
## 业务目标
|
||||
|
||||
- 使用当前项目约定方式构建并启动 `WebSite` 一体服务。
|
||||
- 优先沿用 `tmux` 会话 `revoxelseg-dicom`，将服务暴露在本机 `4000` 端口。
|
||||
- 验证本机健康检查、本机页面和公网域名访问状态。
|
||||
|
||||
## 输入与输出
|
||||
|
||||
- 输入：当前工作区代码、`WebSite/package.json` 脚本、已有 `tmux` 会话和网络转发链路。
|
||||
- 输出：重新部署后的本机服务与公网访问验证结果。
|
||||
|
||||
## 影响范围
|
||||
|
||||
- 运行态影响：`WebSite/dist/` 构建产物、`tmux` 中运行的 Node 服务。
|
||||
- 文档影响：本次需求分析、实现方案、测试方案和经验记录追加。
|
||||
- 不涉及源码逻辑修改、医学数据修改、Docker 镜像改动。
|
||||
|
||||
## 关键约束
|
||||
|
||||
- 必须先执行 `工程分析/代码编纂工作流.md`。
|
||||
- 部署优先使用 `cd WebSite && npm run build && npm run serve -- --host 0.0.0.0 --port 4000`。
|
||||
- 长期运行优先沿用 `tmux` 会话 `revoxelseg-dicom`。
|
||||
- 文档备份 commit message 必须包含 `2026-05-25-10-21-17`。
|
||||
|
||||
## 风险点
|
||||
|
||||
- 若 4000 端口已有进程占用，需要先识别并避免多服务冲突。
|
||||
- 若公网反代或 FRP 链路异常，本机服务可正常但 `https://revoxel.huijutec.cn/` 仍可能不可达。
|
||||
- 若构建失败，需要先定位依赖或 TypeScript/Vite 问题，不能强行重启旧包当成新部署。
|
||||
|
||||
## 默认假设
|
||||
|
||||
- 当前代码状态即为用户希望部署的版本。
|
||||
- 无需修改源码或 Docker 配置。
|
||||
- 若已有 `revoxelseg-dicom` 会话存在，可重用该会话并重启其中服务。
|
||||
Reference in New Issue
Block a user