已部署實驗性項目

服務A 跨機器 AI 影片處理平台

局域網內「上傳即處理」的 AI 影片處理 Web 服務—— 前端部署於 Linux 服務器,後端運行於 Windows 主機, 通過 SCP 跨機器傳輸文件,遠程調度服務A執行推理,完成後供用戶下載。

📡 部署資訊

🖥️
前端
運行於 Linux 服務器(Python HTTP Server),端口 3001
純靜態 HTML + JS,提供拖放上傳、進度追蹤、任務管理 UI
🪟
後端
運行於 Windows 主機(局域網內部 IP)
Node.js 服務,處理上傳、調度服務A推理、回傳結果
🔗
通訊方式
前端透過 HTTP API 與後端通訊(上傳、查詢任務、下載)
後端透過 SCP + SSH 與 Windows 主機傳輸文件並觸發推理

設計架構

1

用戶在瀏覽器上傳影片 → 前端發送至後端

2

後端接收文件,透過 SCP 傳輸至推理用主機的指定目錄

3

遠端觸發服務A進行 AI 推理處理

4

處理完成後 SCP 回傳結果,前端顯示下載按鈕

使用的技術

Node.jsPython HTTP ServerSCP / SSHJob Persistence (JSON)SSE PollingREST API局域網服務

🔀 前後端分離架構

項目採用前後端分離設計,前端和後端可以部署在不同的機器上:

前端(Linux 服務器)
  • • 純靜態 HTML + CSS + JS
  • • Python HTTP Server 託管
  • • 拖放上傳、即時進度、任務管理
  • • 後端地址可線上配置
  • • 支援 URL 參數 ?server=
  • • 純靜態 HTML + CSS + JS
  • • Python HTTP Server 託管
  • • 拖放上傳、即時進度、任務管理
  • • 後端地址可線上配置
  • • 支援 URL 參數 ?server=
後端(Windows 主機)
  • • Node.js + Multer 處理上傳
  • • SCP 跨機器文件傳輸
  • • SSH 遠程執行推理
  • • Job JSON 持久化
  • • RESTful API
  • • Node.js + Multer 處理上傳
  • • SCP 跨機器文件傳輸
  • • SSH 遠程執行推理
  • • Job JSON 持久化
  • • RESTful API

做到了什麼

  • 完整上傳 UI:拖放上傳、進度條、狀態反饋
  • 前後端分離:前端獨立部署,後端地址可動態配置
  • 跨設備文件傳輸:透過 SCP 將影片傳至 Windows 主機
  • Job 持久化:以 JSON 記錄任務狀態,服務重啟或關閉瀏覽器後任務仍在
  • 即時進度回報:前端輪詢後端取得處理階段(上傳中 → 處理中 → 完成)
  • 下載功能:處理完成後出現下載按鈕取回結果影片

📤 上傳方案分析

採用 HTTP POST + Raw Binary Body 方式上傳——最簡單直接的上傳方案,適合局域網場景。

方式HTTP POST,raw binary body檔名傳遞URL query parameter ?filename=xxx進度追蹤XHR 原生 upload.progress event分段上傳❌ 沒有(整個檔案一次傳)斷點續傳❌ 沒有多部分表單❌ 不是 FormData / Multipart

前端(index.html)

// 檔案直接作為 request body 發送(不是 FormData)
// 檔名透過 URL 參數傳遞
xhr.open('POST', `${API}/api/upload?filename=${encodeURIComponent(file.name)}`, true);
xhr.send(file);  // 直接傳整個檔案

// 追蹤上傳進度
xhr.upload.addEventListener('progress', (e) => {
  if (e.lengthComputable) {
    const pct = Math.round((e.loaded / e.total) * 100);
    // 更新進度條...
  }
});

後端(server.py)

# 從 Content-Length 讀取檔案大小
# 從 self.rfile 逐塊讀取原始位元組,寫入磁碟
# 每次讀 64KB(65536 bytes)

while read_bytes < length:
    chunk = self.rfile.read(min(65536, length - read_bytes))
    f.write(chunk)

限制:大檔案如果中斷需從頭上傳。適合一般影片大小(數百 MB 以內), 如果需要處理超大檔案(數 GB),可以考慮加入分段上傳或斷點續傳機制。

經驗總結

1. 先驗證核心,再建外圍

整個 pipeline 的核心是「能否遠程執行 Windows 程序」。這個問題應該在 Day 1 就用最小腳本驗證,而不是在上傳、UI、進度系統都建完後才發現核心走不通。原則:spike 先行,基礎設施後建。

2. Server 默認監聽 0.0.0.0

局域網服務若只綁定 127.0.0.1,局域網其他設備完全無法訪問。 開發局域網服務時應默認用 0.0.0.0,並在防火牆層面控制訪問。

3. 跨平台遠程執行需要明確的憑證計劃

Linux 遠程執行 Windows 程序有多種方案(OpenSSH for Windows、WinRM、PowerShell Remoting),每種都需要提前配置好。 跨平台異構架構在設計階段就必須明確「誰執行、怎麼認證、有沒有憑證」,否則到後期才踩坑代價極大。

4. Job Persistence 是異步任務的必備設計

影片處理往往耗時數分鐘,用戶可能中途關閉瀏覽器。 把任務狀態持久化到磁碟(哪怕只是 JSON 文件),讓任務生命週期獨立於瀏覽器會話,是這類服務的基本要求,不是可選功能。

5. 前後端分離讓部署更靈活

將前端從後端獨立出來後,前端可以部署在任何有瀏覽器能訪問到的機器上, 只需要在頁面上填入後端地址即可對接。這種設計讓局域網內的服務分佈變得非常靈活。