續(xù)傳方案解析)
1. 從一個(gè)幾十GB的BIM模型說起這個(gè)需求到底在解決什么1.1 場景還原國企工程建筑里的建模、審查與交付流程在建筑行業(yè)摸爬滾打過的朋友應(yīng)該都有體會(huì)央企國企的工程項(xiàng)目和普通商業(yè)項(xiàng)目有本質(zhì)區(qū)別體量大、周期長、參與方多而且對交付物有非常嚴(yán)格的歸檔要求。一個(gè)典型的大型公建項(xiàng)目結(jié)構(gòu)、建筑、機(jī)電、幕墻、景觀各專業(yè)都要出模型這些模型經(jīng)過深化設(shè)計(jì)、碰撞檢查、施工模擬之后往往還要整合成一套“綜合模型”用于審查和交底。我之前參與過一個(gè)國企項(xiàng)目的平臺化改造當(dāng)時(shí)碰到一個(gè)特別實(shí)際的問題各分包單位提交的BIM模型打包之后普遍在10GB到50GB之間單文件解包后更是動(dòng)輒上百GB的零散文件。模型本身是按一定目錄結(jié)構(gòu)組織的比如按樓棟號、按專業(yè)、按樓層、按構(gòu)件庫分包目錄層級復(fù)雜文件名也帶著版本信息。這些模型要上傳到統(tǒng)一的Web管理平臺用于后續(xù)的進(jìn)度對比、施工模擬和檔案留存。但問題來了普通的上傳方式根本扛不住。傳統(tǒng)的FormData整體提交瀏覽器端要讀整個(gè)文件到內(nèi)存再把二進(jìn)制數(shù)據(jù)拼進(jìn)請求體幾GB的文件大概率直接把瀏覽器干崩潰或者卡在進(jìn)度條上幾個(gè)小時(shí)不動(dòng)。再加上國企內(nèi)網(wǎng)環(huán)境的網(wǎng)絡(luò)波動(dòng)、文件大小限制、服務(wù)器超時(shí)設(shè)置一次失敗就意味著從頭再來非常痛苦。這個(gè)項(xiàng)目標(biāo)題里提到的“目錄結(jié)構(gòu)分片斷點(diǎn)續(xù)傳”其實(shí)就是在解決這個(gè)場景下的三大痛點(diǎn)大文件如何穩(wěn)定上傳、上傳中斷后如何恢復(fù)、以及上傳后如何保持模型原有的目錄結(jié)構(gòu)不亂。1.2 普通上傳為什么扛不住內(nèi)存、超時(shí)和重傳的三重困境先說到底為什么傳統(tǒng)方案行不通。首先是瀏覽器內(nèi)存問題。當(dāng)我們用formData.append(file, file)這種方式上傳時(shí)如果直接傳入一個(gè)Blob對象瀏覽器本質(zhì)上要把這個(gè)文件當(dāng)做一個(gè)整體來處理。雖然現(xiàn)代瀏覽器在大部分情況下不會(huì)真的把整個(gè)文件一次性載入內(nèi)存但部分老版本內(nèi)核或資源受限的瀏覽器確實(shí)會(huì)這樣干內(nèi)存直接被打滿。即便瀏覽器做了流式處理網(wǎng)絡(luò)層面的問題依然致命。內(nèi)網(wǎng)環(huán)境下雖然帶寬理論上很高但國企內(nèi)網(wǎng)往往有安全設(shè)備、審計(jì)網(wǎng)關(guān)、流量控制策略一條長連接很容易被中間設(shè)備超時(shí)掐斷。一個(gè)10GB的文件傳了8GB連接斷了服務(wù)器端接收到的臨時(shí)文件被清理掉前端只能重新開始。這個(gè)過程重復(fù)幾次現(xiàn)場工程師心態(tài)直接就崩了。整個(gè)文件上傳還有一個(gè)隱藏問題無法精確感知每一段的進(jìn)度。HTML5的xhr.upload.onprogress確實(shí)能提供一個(gè)整體進(jìn)度事件但那是基于當(dāng)前請求的傳輸量計(jì)算的一旦請求被中斷這個(gè)進(jìn)度就歸零。工程師看到的進(jìn)度條從90%跳回0%這種體驗(yàn)極其糟糕。所以分片上傳的思路本質(zhì)上很簡單把一個(gè)大文件在瀏覽器端切成若干小塊逐塊上傳。每一塊都是獨(dú)立的HTTP請求服務(wù)端收到所有分片后再拼接成完整文件。這樣做的好處是某一片失敗只需要重傳這一片而不是整個(gè)文件而且每一片的狀態(tài)都可以被記錄刷新頁面、斷網(wǎng)、甚至瀏覽器崩潰之后只要知道哪些片傳成功了就可以從失敗的位置繼續(xù)傳。1.3 目標(biāo)拆解分片、斷點(diǎn)續(xù)傳、目錄結(jié)構(gòu)、校驗(yàn)缺一不可在動(dòng)手寫代碼之前我習(xí)慣先把這個(gè)標(biāo)題拆成四個(gè)獨(dú)立的技術(shù)指標(biāo)每一項(xiàng)都要在方案設(shè)計(jì)階段就想清楚第一個(gè)指標(biāo)是“分片”。不管文件多大都要切割成可控大小的切片比如每片1MB到8MB前端逐片發(fā)送后端按順序拼接。第二個(gè)指標(biāo)是“斷點(diǎn)續(xù)傳”。這是整個(gè)方案的靈魂。它要求前端能持久化記錄每一片的上傳狀態(tài)后端也能識別哪些分片已經(jīng)存在允許前端跳過已上傳的片直接從缺失位置繼續(xù)。第三個(gè)指標(biāo)是“目錄結(jié)構(gòu)”。這個(gè)在普通文件分片上傳方案里不太被提起但BIM模型場景特別重要。模型文件不是一個(gè)孤零零的二進(jìn)制文件而是一個(gè)完整的目錄樹里面混著模型文件、貼圖資源、材質(zhì)庫、鏈接文件、明細(xì)表等等。如果上傳后目錄樹被打平、層級丟失下游的所有工具都識別不出來。第四個(gè)指標(biāo)是“完整性校驗(yàn)”。分片上傳不等于丟數(shù)據(jù)每片上傳后要有哈希校驗(yàn)合并完成后也要有整體校驗(yàn)確保拼接出來的文件和本地文件完全一致。BIM模型一旦某個(gè)字節(jié)損壞輕則模型打不開重則算量結(jié)果錯(cuò)誤這在工程領(lǐng)域是絕對不允許的。我的建議是先把這個(gè)需求搞清楚再想技術(shù)方案。很多人一上來就搜“分片上傳插件”往項(xiàng)目里裝了一個(gè)結(jié)果發(fā)現(xiàn)插件只能傳單個(gè)文件不保留目錄結(jié)構(gòu)也沒有斷點(diǎn)記錄最后還是得自己改。與其繞彎子不如直接基于原生JavaScript和File API來實(shí)現(xiàn)所有邏輯都握在自己手里后續(xù)調(diào)試和擴(kuò)展都方便。2. 技術(shù)方案設(shè)計(jì)先想清楚再寫代碼2.1 分片上傳的核心原理切片大小為什么通常選1MB到8MB分片上傳的第一件事就是確定切片大小。這個(gè)參數(shù)不是拍腦袋定的它直接影響上傳效率和重傳代價(jià)。切片太小比如256KB分片數(shù)量會(huì)非常夸張。一個(gè)10GB的文件要切4萬片每片一個(gè)HTTP請求光握手開銷就把帶寬吃掉了。切片太大比如64MB雖然請求數(shù)量少了但單片的傳輸時(shí)間變長一旦網(wǎng)絡(luò)抖動(dòng)導(dǎo)致某一片失敗重傳64MB數(shù)據(jù)的代價(jià)又太大同時(shí)服務(wù)端接收時(shí)對內(nèi)存緩沖區(qū)的壓力也大。我一般建議在1MB到8MB之間取一個(gè)平衡值。打個(gè)比方這就像搬家時(shí)選紙箱的大小紙箱太大裝滿后搬不動(dòng)一旦路上散了損失慘重紙箱太小一趟一趟跑腿累死而且紙箱本身占地方。1MB到8MB這個(gè)區(qū)間既能保證單片傳輸在幾秒內(nèi)完成又能控制總片數(shù)在一個(gè)可管理范圍內(nèi)。用節(jié)省流量的邏輯來算更直觀假設(shè)網(wǎng)絡(luò)平均傳輸速度是5MB/s選1MB切片每片大約0.2秒傳完選8MB切片每片大約1.6秒傳完兩者在WAN場景下差別并不大但在LAN場景下更小的切片反而因?yàn)檎埱髷?shù)量過多而拉低吞吐。所以我實(shí)際用下來5MB左右是一個(gè)比較舒服的閾值。如果走的是互聯(lián)網(wǎng)而非內(nèi)網(wǎng)再降到2MB會(huì)更穩(wěn)。每片切完之后要給每個(gè)分片生成一個(gè)唯一的標(biāo)識。比較通用的做法是相對路徑 _ 文件大小 _ 最后修改時(shí)間 _ 切片序號。這個(gè)標(biāo)識組合能大概率避免同名文件沖突而且方便定位。## 3. 前端實(shí)操目錄讀取、文件切片與斷點(diǎn)記錄的完整實(shí)現(xiàn)3.1 從目錄選擇到文件樹構(gòu)建讓瀏覽器“看到”BIM模型的目錄結(jié)構(gòu)BIM模型一般以文件夾形式交付文件夾內(nèi)部有清晰的層級。在Web端要保留這個(gè)層級首先得讓瀏覽器能遍歷目錄。HTML5里input typefile webkitdirectory可以做到這一點(diǎn)。const input document.createElement(input); input.type file; input.webkitdirectory true; input.addEventListener(change, (e) { const files Array.from(e.target.files); const tree {}; for (const file of files) { const relativePath file.webkitRelativePath; const segments relativePath.split(/); let current tree; for (let i 0; i segments.length - 1; i) { if (!current[segments[i]]) current[segments[i]] {}; current current[segments[i]]; } current[segments[segments.length - 1]] { size: file.size, lastModified: file.lastModified, type: file.type || }; } window.__fileTree tree; window.__files files; });需要注意的是webkitRelativePath在大多數(shù)Chromium內(nèi)核瀏覽器中都能正常返回類似結(jié)構(gòu)模型/B2號樓/結(jié)構(gòu).rvt這樣的相對路徑。拿到這個(gè)路徑之后我建議立刻生成一份JSON格式的目錄樹這份JSON有兩個(gè)用途一是上傳完成后給服務(wù)端做目錄重建依據(jù)二是前端自己展示文件列表時(shí)用。還有個(gè)容易被忽略的問題目錄里可能包含隱藏文件、臨時(shí)文件、回收站殘留之類的東西。在構(gòu)建文件樹時(shí)最好做一層過濾比如排除以.開頭的文件、排除__MACOSX這類常見打包殘留目錄。國企項(xiàng)目移交過來的模型經(jīng)常帶著各種莫名其妙的文件傳上去之后不僅浪費(fèi)流量后期清理還很麻煩。3.2 文件切片與標(biāo)識生成File.slice和穩(wěn)定ID的配合文件切割在瀏覽器端非常簡單核心就是一個(gè)APIfunction createChunks(file, chunkSize 5 * 1024 * 1024) { const chunks []; let start 0; while (start file.size) { chunks.push(file.slice(start, start chunkSize)); start chunkSize; } return chunks; }file.slice()返回的是一個(gè)Blob對象它并不會(huì)真的把文件內(nèi)容復(fù)制出來而是指向原始文件數(shù)據(jù)的某一段因此內(nèi)存消耗相對可控。不過這里有一個(gè)必須注意的細(xì)節(jié)如果對文件調(diào)用slice之后原文件對象被釋放某些瀏覽器下這些Blob會(huì)變成無效引用。所以在上傳期間最好用一個(gè)數(shù)組把所有切片引用保存住直到全部上傳完成。對于斷點(diǎn)續(xù)傳每個(gè)分片需要有一個(gè)穩(wěn)定且唯一的標(biāo)識。我建議把標(biāo)識拆成兩個(gè)層級文件級別ID和分片級別索引。function buildFileId(file) { const path file.webkitRelativePath || file.name; return ${path}_${file.size}_${file.lastModified}; } function buildChunkId(fileId, index) { return ${fileId}_chunk_${index}; }這里我刻意沒有使用基于文件內(nèi)容的哈希作為切片標(biāo)識因?yàn)閷Υ笪募?jì)算全量MD5或SHA-1在瀏覽器端是很慢的甚至可能造成主線程卡頓。用路徑 大小 最后修改時(shí)間來標(biāo)識文件雖然理論上存在極小概率沖突但對內(nèi)網(wǎng)交付的模型文件來說已經(jīng)足夠可靠。如果你需要更高強(qiáng)度的校驗(yàn)可以只對第一個(gè)切片和最后一個(gè)切片做部分哈希這樣既能兼顧性能又能防止明顯的文件損壞。3.3 上傳隊(duì)列與并發(fā)控制別把服務(wù)器打懵分片數(shù)量上來之后一次性把所有分片同時(shí)發(fā)出去是不現(xiàn)實(shí)的。一個(gè)10GB的文件按5MB切大約2048片如果全部并發(fā)發(fā)起瀏覽器光在建TCP連接就把資源耗盡了而且服務(wù)端也沒辦法同時(shí)處理這么多請求。正確的做法是控制并發(fā)數(shù)。async function uploadChunksInParallel(chunks, fileId, concurrency 6) { let index 0; const tasks []; for (let i 0; i concurrency; i) { tasks.push(run()); } async function run() { while (index chunks.length) { const current index; const chunk chunks[current]; await uploadOneChunk(fileId, current, chunk); } } await Promise.all(tasks); }并發(fā)數(shù)取多少合適我試過比較多的方案內(nèi)網(wǎng)環(huán)境下6到8路并發(fā)效果最佳外網(wǎng)環(huán)境下3到4路更快。這個(gè)數(shù)字取決于服務(wù)器配置、網(wǎng)關(guān)并發(fā)限制和網(wǎng)絡(luò)帶寬。如果并發(fā)設(shè)置太高網(wǎng)關(guān)可能會(huì)直接拒絕連接設(shè)置太低又無法利用多路并行加速。每一片的上傳請求需要包含三類信息文件標(biāo)識、分片序號、分片二進(jìn)制數(shù)據(jù)。服務(wù)端應(yīng)該以文件標(biāo)識 分片序號作為冪等鍵收到重復(fù)上傳時(shí)直接返回成功這樣前端在斷點(diǎn)續(xù)傳時(shí)反復(fù)嘗試同一片也不會(huì)出問題。3.4 IndexedDB記錄進(jìn)度刷新之后繼續(xù)傳不靠運(yùn)氣斷點(diǎn)續(xù)傳的核心在于“狀態(tài)記錄”。前端每次上傳完一片都應(yīng)該把這一片的成功狀態(tài)記錄下來。刷新頁面或者瀏覽器崩潰之后通過查詢已經(jīng)上傳的分片列表就能跳過這些分片從失敗位置繼續(xù)傳。localStorage雖然簡單但容量有限通常5MB左右而且只能存字符串。一個(gè)10GB的文件有2048片每片記錄一個(gè)ID雖然字符串不會(huì)太大但如果同時(shí)管理多個(gè)文件可能就把localStorage撐爆了。更麻煩的是localStorage的讀寫是同步的頻繁寫入會(huì)阻塞UI線程。我建議用IndexedDB來存上傳進(jìn)度。它容量大、異步、性能好非常適合做斷點(diǎn)恢復(fù)這種場景。先簡單封裝一個(gè)存儲(chǔ)工具const dbName bim-upload-db; const storeName chunk-status; function openDB() { return new Promise((resolve, reject) { const request indexedDB.open(dbName, 1); request.onupgradeneeded () { const db request.result; if (!db.objectStoreNames.contains(storeName)) { const store db.createObjectStore(storeName, { keyPath: chunkId }); store.createIndex(fileId, fileId, { unique: false }); } }; request.onsuccess () resolve(request.result); request.onerror () reject(request.error); }); } async function markChunkUploaded(fileId, chunkId) { const db await openDB(); return new Promise((resolve, reject) { const tx db.transaction(storeName, readwrite); tx.objectStore(storeName).put({ fileId, chunkId, uploaded: true }); tx.oncomplete resolve; tx.onerror () reject(tx.error); }); } async function getUploadedChunks(fileId) { const db await openDB(); return new Promise((resolve, reject) { const tx db.transaction(storeName, readonly); const store tx.objectStore(storeName); const index store.index(fileId); const request index.getAll(fileId); request.onsuccess () resolve(request.result.map(item item.chunkId)); request.onerror () reject(request.error); }); }有了這個(gè)進(jìn)度存儲(chǔ)上傳流程就變成了啟動(dòng)上傳前先查IndexedDB把已經(jīng)成功上傳的分片序號過濾掉只排尚未上傳的切片進(jìn)入隊(duì)列。這樣一來哪怕之前傳了一半瀏覽器崩了下次打開頁面選擇同一目錄系統(tǒng)自動(dòng)識別同一批文件ID直接跳過已傳部分。這里有個(gè)必須要提醒的點(diǎn)IndexedDB里的記錄是“前端視角”的它代表的只是瀏覽器曾經(jīng)發(fā)出過成功響應(yīng)。如果服務(wù)端在接收某一片之后、返回成功之前崩潰了前端記錄成功但實(shí)際上后端的這一片是殘缺的。所以服務(wù)端必須在每次分片上傳時(shí)做文件大小的校驗(yàn)拼接時(shí)再做一次整體校驗(yàn)雙保險(xiǎn)。3.5 合并請求與整體校驗(yàn)分片傳完了不代表文件沒問題所有分片都傳完之后前端需要調(diào)用一個(gè)合并接口通知服務(wù)端把臨時(shí)目錄里的分片按順序拼接成完整文件。合并請求里要帶上文件ID、總大小、總分片數(shù)、原始相對路徑。服務(wù)端在做合并之前會(huì)先檢查分片數(shù)量和大小是否吻合再執(zhí)行合并。合并完成后我強(qiáng)烈建議做一次文件級校驗(yàn)。最簡單的方式是前端在構(gòu)建文件ID時(shí)記錄文件總大小合并后由服務(wù)端返回合并后的文件大小和哈希值前端進(jìn)行比對。如果要做更嚴(yán)格的校驗(yàn)可以對整個(gè)文件做一次MD5計(jì)算但大文件的整體哈希計(jì)算在服務(wù)端也需要一定時(shí)間所以實(shí)際工程中我更傾向于讓前端對文件的第一個(gè)和最后一個(gè)切片做MD5作為強(qiáng)校驗(yàn)的近似替代其余切片用大小校驗(yàn)兜底。校驗(yàn)通過之后目錄樹JSON和文件實(shí)體是分離的。前端在上傳分片的同時(shí)應(yīng)該把目錄樹數(shù)據(jù)一并提交給服務(wù)端元數(shù)據(jù)表。服務(wù)端拿到目錄樹和數(shù)據(jù)文件后會(huì)按相對路徑在目標(biāo)存儲(chǔ)位置重建目錄結(jié)構(gòu)把文件落到對應(yīng)目錄節(jié)點(diǎn)下。這個(gè)過程可以在合并接口里一并處理省去一次請求。4. 后端配合接口設(shè)計(jì)、合并策略與存儲(chǔ)規(guī)劃4.1 三個(gè)核心接口初始化、上傳分片、合并前端做得再好后端接口設(shè)計(jì)跟不上也是白搭。我們只需要三個(gè)核心接口不復(fù)雜但每一步都要考慮邊界情況。第一個(gè)是初始化接口。前端在開始上傳前先調(diào)用它把自己要傳的文件ID、文件總大小、文件名、相對路徑發(fā)給服務(wù)端。服務(wù)端返回一個(gè)uploadId并在臨時(shí)目錄下創(chuàng)建以uploadId為名的子目錄后續(xù)該文件的所有分片都存在這個(gè)目錄里。第二個(gè)是上傳分片接口。請求參數(shù)包括uploadId、chunkIndex、chunkSize二進(jìn)制分片數(shù)據(jù)放在請求體中。服務(wù)端把分片寫入臨時(shí)目錄/uploadId/chunkIndex.part然后返回成功。如果這個(gè)分片已經(jīng)存在且大小一致直接返回200不上傳也沒問題。第三個(gè)是合并接口。參數(shù)包括uploadId、文件總大小、總分片數(shù)、目錄樹JSON。服務(wù)端先校驗(yàn)分片完整性然后按索引順序合并寫入最終存儲(chǔ)路徑最后重建目錄樹。合并成功之后刪除臨時(shí)目錄返回文件元數(shù)據(jù)。我遇到的比較常見的問題是很多團(tuán)隊(duì)在初始化接口里就做了大量業(yè)務(wù)判斷比如數(shù)據(jù)庫查重、權(quán)限校驗(yàn)、隊(duì)列檢查結(jié)果初始化慢得像龜速。工業(yè)級場景應(yīng)該把初始化接口做得盡量輕量只負(fù)責(zé)創(chuàng)建上傳會(huì)話所有業(yè)務(wù)判斷放在后續(xù)流程里異步執(zhí)行。4.2 服務(wù)端分片存儲(chǔ)與合并策略流式拼接比內(nèi)存拼接靠譜服務(wù)端接收分片時(shí)最容易犯的錯(cuò)誤是把所有分片讀入內(nèi)存再拼接。一個(gè)5MB的分片乘以2048片就是10GB內(nèi)存正常的服務(wù)器根本扛不住。正確的做法是分部落地。每收到一片直接使用文件流寫入磁盤路徑按uploadId 序號組織。合并時(shí)逐片打開文件使用流式方式將內(nèi)容追加到目標(biāo)文件尾部。Node.js里用createReadStream和createWriteStream配合管道操作每合并完一片就關(guān)閉資源內(nèi)存占用始終保持恒定。合并校驗(yàn)的策略也要細(xì)化。我通常會(huì)維護(hù)一個(gè)分片元信息表記錄每片的實(shí)際大小。合并前檢查兩件事已上傳分片的數(shù)量是否等于總分片數(shù)、每片的大小是否與預(yù)期一致。如果發(fā)現(xiàn)缺失或缺損返回前端一個(gè)“缺失分片列表”讓前端針對性重傳缺失的片而不是整個(gè)文件重傳。這種“按需補(bǔ)片”機(jī)制在弱網(wǎng)環(huán)境下尤其好用。關(guān)于磁盤規(guī)劃臨時(shí)目錄要有獨(dú)立的分區(qū)不能和系統(tǒng)目錄混在一起。之前我遇到過一次項(xiàng)目臨時(shí)目錄寫在系統(tǒng)盤模型上傳量一大系統(tǒng)盤被塞滿整個(gè)服務(wù)器直接無響應(yīng)。臨時(shí)目錄的清理策略也要有。合并成功之后立即刪除對應(yīng)分片這是最基礎(chǔ)的要求。還要加一個(gè)定時(shí)任務(wù)清理超過48小時(shí)仍處于未完成狀態(tài)的上傳目錄防止黑客或異常任務(wù)占滿磁盤。4.3 并發(fā)沖突與重復(fù)分片的冪等處理上傳過程中前端可能會(huì)因?yàn)榫W(wǎng)絡(luò)超時(shí)對同一個(gè)分片重復(fù)請求。服務(wù)端必須對這種情況做冪等處理。用uploadId chunkIndex作為主鍵如果發(fā)現(xiàn)同一個(gè)分片已經(jīng)存在且大小一致就直接返回成功不重復(fù)寫磁盤。合并操作的并發(fā)控制同樣重要。我建議用一個(gè)鎖標(biāo)記來防止同一個(gè)uploadId被多個(gè)合并請求同時(shí)操作。比如在數(shù)據(jù)庫會(huì)話表里加一個(gè)mergeStatus字段合并中、合并完成、合并失敗。前端偶爾會(huì)因?yàn)槌瑫r(shí)對合并接口重復(fù)請求一對服務(wù)端看到“合并中”狀態(tài)可以適當(dāng)阻塞等待看到“合并完成”直接返回結(jié)果避免合并邏輯執(zhí)行兩次產(chǎn)生臟數(shù)據(jù)。5. 國企工程場景下繞不開的坑與排查實(shí)錄5.1 網(wǎng)絡(luò)波動(dòng)與斷網(wǎng)恢復(fù)指數(shù)退避重試是基礎(chǔ)操作國企內(nèi)網(wǎng)雖然有專線但不算穩(wěn)定。特別是部分老辦公樓里的網(wǎng)絡(luò)設(shè)備高峰期經(jīng)常出現(xiàn)大量丟包。分片上傳遇到單次網(wǎng)絡(luò)失敗是常態(tài)所以前端必須有一套重試機(jī)制。我比較推薦指數(shù)退避策略第一次失敗等1秒重試第二次失敗等2秒第三次等4秒最多重試5次。如果連續(xù)5次失敗就把這個(gè)分片標(biāo)記為失敗但不中斷整個(gè)上傳流程而是繼續(xù)處理其他分片失敗的分片放到隊(duì)列末尾最后統(tǒng)一補(bǔ)傳。實(shí)際體驗(yàn)下來這種“邊傳邊補(bǔ)”的策略比“遇到失敗就停止整個(gè)上傳”強(qiáng)太多因?yàn)榫W(wǎng)絡(luò)抖動(dòng)通常是短暫的給一小段時(shí)間它自己就恢復(fù)了。斷網(wǎng)的情況更特殊。瀏覽器檢測到網(wǎng)絡(luò)斷開時(shí)所有請求會(huì)失敗。這時(shí)候前端應(yīng)該暫停整個(gè)上傳隊(duì)列監(jiān)聽online事件網(wǎng)絡(luò)恢復(fù)后重新查詢IndexedDB里的上傳狀態(tài)對未完成的分片繼續(xù)上傳。在這個(gè)過程中不需要刷新頁面體驗(yàn)是連續(xù)的。5.2 瀏覽器崩潰與內(nèi)存占用優(yōu)化用Web Worker把哈希計(jì)算挪到后臺瀏覽器崩潰是分片上傳最容易遇到的問題大多數(shù)原因是內(nèi)存占用過高。雖然File.slice()不會(huì)一次把整個(gè)文件載入內(nèi)存但部分場景下比如多個(gè)文件同時(shí)讀取、切片對象持有大量引用內(nèi)存還是會(huì)快速攀升。我的經(jīng)驗(yàn)是每次從磁盤讀取一個(gè)切片后立即上傳并釋放引用不要一次性把所有切片都放進(jìn)一個(gè)數(shù)組里。上面給出的createChunks示例雖然是全量創(chuàng)建但實(shí)際項(xiàng)目中我會(huì)改為懶加載切片function getChunk(file, chunkSize, index) { const start index * chunkSize; const end Math.min(start chunkSize, file.size); return file.slice(start, end); }這樣每次只保留當(dāng)前正在上傳的幾片內(nèi)存占用大幅降低。如果是做全量文件哈希校驗(yàn)一定不要在主線程做。一個(gè)10GB文件的全量MD5計(jì)算在瀏覽器里可能需要幾十秒甚至幾分鐘在這期間頁面會(huì)卡死。正確做法是把文件交給Web Worker在Worker線程里分片讀取并計(jì)算哈希計(jì)算完畢通過postMessage把結(jié)果傳回主線程。這樣用戶可以繼續(xù)操作界面不會(huì)出現(xiàn)“頁面已失去響應(yīng)”的尷尬。5.3 老舊瀏覽器與國產(chǎn)化內(nèi)核兼容降級方案要提前想好國企辦公環(huán)境里瀏覽器的實(shí)際情況可能超出技術(shù)人員想象。有大量存量電腦還在使用老版本的Chromium內(nèi)核瀏覽器有些國產(chǎn)瀏覽器默認(rèn)跑在兼容模式下。這些環(huán)境下webkitdirectory、IndexedDB這些特性可能是缺失的。我建議在頁面加載時(shí)做一次能力檢測分別檢測File.slice、webkitdirectory、indexedDB是否可用。如果某一項(xiàng)缺失就啟用降級方案。比如沒有IndexedDB就用localStorage存進(jìn)度沒有webkitdirectory就不支持目錄選擇改為讓用戶選擇單個(gè)文件或壓縮包實(shí)在不行就退回最原始的整包上傳方案。雖然這些降級方案體驗(yàn)差很多但總比“打開頁面什么都做不了”強(qiáng)。我遇到過某國企內(nèi)網(wǎng)瀏覽器連File.slice都不支持的情況那套系統(tǒng)所有文件上傳都只能走傳統(tǒng)方式這是平臺底層的硬傷前端只能盡量兼容沒法完全替代。### 5.4 安全與審計(jì)模型文件是核心資產(chǎn)不能裸奔BIM模型在工程項(xiàng)目里屬于核心數(shù)據(jù)資產(chǎn)里面包含了完整的建筑結(jié)構(gòu)信息、設(shè)備參數(shù)、工程量清單一旦泄露或者被篡改后果非常嚴(yán)重。所以上傳過程不能只想著“傳上去就行”還得考慮安全與審計(jì)。權(quán)限控制是第一層。上傳接口必須驗(yàn)證用戶身份不能匿名上傳。我當(dāng)時(shí)所在的系統(tǒng)對接了統(tǒng)一的身份認(rèn)證平臺上傳時(shí)每次請求都要攜帶token。分片上傳接口也同樣校驗(yàn)不能因?yàn)樗恰安糠謹(jǐn)?shù)據(jù)”就放寬權(quán)限。操作日志是第二層。上傳開始、分片接收、合并完成、文件刪除這些操作都要記錄到日志系統(tǒng)。日志里至少要包含操作人、操作時(shí)間、文件ID、分片序號、結(jié)果狀態(tài)。國企項(xiàng)目的審計(jì)是要落實(shí)到具體人和具體操作的這個(gè)不能省。文件校驗(yàn)是第三層。合并完成后對文件做一次病毒掃描和類型檢測。你可能會(huì)覺得奇怪模型文件怎么會(huì)有病毒但實(shí)際上從外部協(xié)作單位移交的模型包經(jīng)常混入各種可執(zhí)行文件、宏病毒、惡意鏈接。服務(wù)端在把文件暴露給其他系統(tǒng)訪問之前必須經(jīng)過安全檢測。這不僅是技術(shù)問題更是合規(guī)問題。6. 實(shí)測效果、踩坑記錄與可復(fù)用的經(jīng)驗(yàn)6.1 實(shí)測環(huán)境與最終效果在項(xiàng)目收尾階段我們做了幾輪壓測。測試環(huán)境是一套典型的國企內(nèi)網(wǎng)配置一臺4核8GB的應(yīng)用服務(wù)器一臺文件存儲(chǔ)服務(wù)器客戶端是普通辦公電腦。測試對象是一個(gè)約35GB的綜合BIM模型包包含5600多個(gè)文件目錄層級在5層左右。使用5MB分片、6路并發(fā)、開啟IndexedDB斷點(diǎn)恢復(fù)的方案整體上傳耗時(shí)大約2小時(shí)左右。期間人為中斷了兩次網(wǎng)絡(luò)每次恢復(fù)后系統(tǒng)都能自動(dòng)從斷點(diǎn)繼續(xù)沒有出現(xiàn)重復(fù)上傳已成功的分片。服務(wù)端合并完成后校驗(yàn)文件大小與源文件完全一致目錄結(jié)構(gòu)也按照原始樹狀關(guān)系落到了存儲(chǔ)區(qū)。相比之前用普通上傳方式“傳一天斷三次”的體驗(yàn)這套方案可以說是從“不可用”變成了“可用”。6.2 踩過的坑與對應(yīng)解決方法第一個(gè)坑是并發(fā)數(shù)設(shè)置過高導(dǎo)致服務(wù)端連接數(shù)被打滿。第一次測試時(shí)我圖快直接上了20路并發(fā)結(jié)果應(yīng)用服務(wù)器的連接池瞬間被耗盡所有請求全部排隊(duì)等待整個(gè)Web應(yīng)用的其他功能也跟著卡住。后來把并發(fā)數(shù)降到6問題消失。這個(gè)參數(shù)最好做成配置項(xiàng)根據(jù)實(shí)際服務(wù)器負(fù)載動(dòng)態(tài)調(diào)整。第二個(gè)坑是目錄名里包含中文、空格和特殊符號。模型交付方經(jīng)常用“B2號樓-裝修-2024-最終版”這種命名方式。如果文件ID直接用整個(gè)相對路徑拼接偶爾會(huì)出現(xiàn)空格導(dǎo)致的解析錯(cuò)誤。解決辦法是在生成文件ID時(shí)用編碼后的相對路徑或者把路徑單獨(dú)作為一個(gè)字段存放不在ID里直接拼接。第三個(gè)坑是合并時(shí)對大文件使用同步拼接導(dǎo)致服務(wù)端無響應(yīng)。最初的實(shí)現(xiàn)是把所有分片讀入數(shù)組再用Buffer.concat合并一個(gè)4GB的文件直接導(dǎo)致內(nèi)存溢出。改成流式合并之后就穩(wěn)定了。這就是我前面反復(fù)強(qiáng)調(diào)流式處理的原因——在這個(gè)場景里它不是一個(gè)可選項(xiàng)而是必須項(xiàng)。第四個(gè)坑是清理任務(wù)誤刪未完成的上傳目錄。定時(shí)清理我最初設(shè)置的閾值是24小時(shí)但有些超大模型文件因?yàn)榫W(wǎng)絡(luò)原因連續(xù)傳了超過24小時(shí)結(jié)果被清理任務(wù)在合并前刪掉了。后來我把閾值改成48小時(shí)并且加了個(gè)“有進(jìn)行中上傳任務(wù)”的保護(hù)判斷才徹底解決。6.3 一個(gè)很實(shí)用的小技巧服務(wù)端返回缺失分片列表最后分享一個(gè)我自己覺得特別實(shí)用的技巧。在合并接口的校驗(yàn)階段服務(wù)端除了返回“失敗”之外還要返回具體的缺失或異常分片序號列表。前端拿到這個(gè)列表后只需要重傳這幾片然后再次調(diào)用合并接口。這個(gè)過程可以循環(huán)直到合并成功。這種方法在處理“某些分片損壞但不清楚是哪些”的情況下非常高效比無腦全量重傳強(qiáng)一個(gè)量級。我之所以一直強(qiáng)調(diào)這個(gè)方案里的“分片斷點(diǎn)目錄結(jié)構(gòu)”三件套要組合起來看是因?yàn)樵谡鎸?shí)的國企工程建筑場景里這三個(gè)需求從來都是同時(shí)出現(xiàn)的。一個(gè)只支持分片上傳、不支持?jǐn)帱c(diǎn)恢復(fù)的插件在弱網(wǎng)條件下仍然會(huì)讓工程師崩潰一個(gè)支持?jǐn)帱c(diǎn)但忽略目錄結(jié)構(gòu)的上傳工具傳完之后下游工具用不了等于白傳。只有把三者打通才能真正解決生產(chǎn)環(huán)境里的問題。如果你也正在處理類似的需求建議先拿一個(gè)真實(shí)的BIM模型包做測試不要用幾個(gè)小文件模擬。真實(shí)場景下的大文件數(shù)量、目錄深度、命名習(xí)慣都會(huì)逼著你把邊界情況想清楚。這套方案跑通之后后續(xù)無論是擴(kuò)展上傳進(jìn)度展示、增加上傳任務(wù)隊(duì)列還是對接消息通知都是在現(xiàn)有骨架上做增量開發(fā)很順手。 BIM模型大文件分片上傳與斷點(diǎn)續(xù)傳方案解析
1. 從一個(gè)幾十GB的BIM模型說起這個(gè)需求到底在解決什么1.1 場景還原國企工程建筑里的建模、審查與交付流程在建筑行業(yè)摸爬滾打過的朋友應(yīng)該都有體會(huì)央企國企的工程項(xiàng)目和普通商業(yè)項(xiàng)目有本質(zhì)區(qū)別體量大、周期長、參與方多而且對交付物有非常嚴(yán)格的歸檔要求。一個(gè)典型的大型公建項(xiàng)目結(jié)構(gòu)、建筑、機(jī)電、幕墻、景觀各專業(yè)都要出模型這些模型經(jīng)過深化設(shè)計(jì)、碰撞檢查、施工模擬之后往往還要整合成一套“綜合模型”用于審查和交底。我之前參與過一個(gè)國企項(xiàng)目的平臺化改造當(dāng)時(shí)碰到一個(gè)特別實(shí)際的問題各分包單位提交的BIM模型打包之后普遍在10GB到50GB之間單文件解包后更是動(dòng)輒上百GB的零散文件。模型本身是按一定目錄結(jié)構(gòu)組織的比如按樓棟號、按專業(yè)、按樓層、按構(gòu)件庫分包目錄層級復(fù)雜文件名也帶著版本信息。這些模型要上傳到統(tǒng)一的Web管理平臺用于后續(xù)的進(jìn)度對比、施工模擬和檔案留存。但問題來了普通的上傳方式根本扛不住。傳統(tǒng)的FormData整體提交瀏覽器端要讀整個(gè)文件到內(nèi)存再把二進(jìn)制數(shù)據(jù)拼進(jìn)請求體幾GB的文件大概率直接把瀏覽器干崩潰或者卡在進(jìn)度條上幾個(gè)小時(shí)不動(dòng)。再加上國企內(nèi)網(wǎng)環(huán)境的網(wǎng)絡(luò)波動(dòng)、文件大小限制、服務(wù)器超時(shí)設(shè)置一次失敗就意味著從頭再來非常痛苦。這個(gè)項(xiàng)目標(biāo)題里提到的“目錄結(jié)構(gòu)分片斷點(diǎn)續(xù)傳”其實(shí)就是在解決這個(gè)場景下的三大痛點(diǎn)大文件如何穩(wěn)定上傳、上傳中斷后如何恢復(fù)、以及上傳后如何保持模型原有的目錄結(jié)構(gòu)不亂。1.2 普通上傳為什么扛不住內(nèi)存、超時(shí)和重傳的三重困境先說到底為什么傳統(tǒng)方案行不通。首先是瀏覽器內(nèi)存問題。當(dāng)我們用formData.append(file, file)這種方式上傳時(shí)如果直接傳入一個(gè)Blob對象瀏覽器本質(zhì)上要把這個(gè)文件當(dāng)做一個(gè)整體來處理。雖然現(xiàn)代瀏覽器在大部分情況下不會(huì)真的把整個(gè)文件一次性載入內(nèi)存但部分老版本內(nèi)核或資源受限的瀏覽器確實(shí)會(huì)這樣干內(nèi)存直接被打滿。即便瀏覽器做了流式處理網(wǎng)絡(luò)層面的問題依然致命。內(nèi)網(wǎng)環(huán)境下雖然帶寬理論上很高但國企內(nèi)網(wǎng)往往有安全設(shè)備、審計(jì)網(wǎng)關(guān)、流量控制策略一條長連接很容易被中間設(shè)備超時(shí)掐斷。一個(gè)10GB的文件傳了8GB連接斷了服務(wù)器端接收到的臨時(shí)文件被清理掉前端只能重新開始。這個(gè)過程重復(fù)幾次現(xiàn)場工程師心態(tài)直接就崩了。整個(gè)文件上傳還有一個(gè)隱藏問題無法精確感知每一段的進(jìn)度。HTML5的xhr.upload.onprogress確實(shí)能提供一個(gè)整體進(jìn)度事件但那是基于當(dāng)前請求的傳輸量計(jì)算的一旦請求被中斷這個(gè)進(jìn)度就歸零。工程師看到的進(jìn)度條從90%跳回0%這種體驗(yàn)極其糟糕。所以分片上傳的思路本質(zhì)上很簡單把一個(gè)大文件在瀏覽器端切成若干小塊逐塊上傳。每一塊都是獨(dú)立的HTTP請求服務(wù)端收到所有分片后再拼接成完整文件。這樣做的好處是某一片失敗只需要重傳這一片而不是整個(gè)文件而且每一片的狀態(tài)都可以被記錄刷新頁面、斷網(wǎng)、甚至瀏覽器崩潰之后只要知道哪些片傳成功了就可以從失敗的位置繼續(xù)傳。1.3 目標(biāo)拆解分片、斷點(diǎn)續(xù)傳、目錄結(jié)構(gòu)、校驗(yàn)缺一不可在動(dòng)手寫代碼之前我習(xí)慣先把這個(gè)標(biāo)題拆成四個(gè)獨(dú)立的技術(shù)指標(biāo)每一項(xiàng)都要在方案設(shè)計(jì)階段就想清楚第一個(gè)指標(biāo)是“分片”。不管文件多大都要切割成可控大小的切片比如每片1MB到8MB前端逐片發(fā)送后端按順序拼接。第二個(gè)指標(biāo)是“斷點(diǎn)續(xù)傳”。這是整個(gè)方案的靈魂。它要求前端能持久化記錄每一片的上傳狀態(tài)后端也能識別哪些分片已經(jīng)存在允許前端跳過已上傳的片直接從缺失位置繼續(xù)。第三個(gè)指標(biāo)是“目錄結(jié)構(gòu)”。這個(gè)在普通文件分片上傳方案里不太被提起但BIM模型場景特別重要。模型文件不是一個(gè)孤零零的二進(jìn)制文件而是一個(gè)完整的目錄樹里面混著模型文件、貼圖資源、材質(zhì)庫、鏈接文件、明細(xì)表等等。如果上傳后目錄樹被打平、層級丟失下游的所有工具都識別不出來。第四個(gè)指標(biāo)是“完整性校驗(yàn)”。分片上傳不等于丟數(shù)據(jù)每片上傳后要有哈希校驗(yàn)合并完成后也要有整體校驗(yàn)確保拼接出來的文件和本地文件完全一致。BIM模型一旦某個(gè)字節(jié)損壞輕則模型打不開重則算量結(jié)果錯(cuò)誤這在工程領(lǐng)域是絕對不允許的。我的建議是先把這個(gè)需求搞清楚再想技術(shù)方案。很多人一上來就搜“分片上傳插件”往項(xiàng)目里裝了一個(gè)結(jié)果發(fā)現(xiàn)插件只能傳單個(gè)文件不保留目錄結(jié)構(gòu)也沒有斷點(diǎn)記錄最后還是得自己改。與其繞彎子不如直接基于原生JavaScript和File API來實(shí)現(xiàn)所有邏輯都握在自己手里后續(xù)調(diào)試和擴(kuò)展都方便。2. 技術(shù)方案設(shè)計(jì)先想清楚再寫代碼2.1 分片上傳的核心原理切片大小為什么通常選1MB到8MB分片上傳的第一件事就是確定切片大小。這個(gè)參數(shù)不是拍腦袋定的它直接影響上傳效率和重傳代價(jià)。切片太小比如256KB分片數(shù)量會(huì)非常夸張。一個(gè)10GB的文件要切4萬片每片一個(gè)HTTP請求光握手開銷就把帶寬吃掉了。切片太大比如64MB雖然請求數(shù)量少了但單片的傳輸時(shí)間變長一旦網(wǎng)絡(luò)抖動(dòng)導(dǎo)致某一片失敗重傳64MB數(shù)據(jù)的代價(jià)又太大同時(shí)服務(wù)端接收時(shí)對內(nèi)存緩沖區(qū)的壓力也大。我一般建議在1MB到8MB之間取一個(gè)平衡值。打個(gè)比方這就像搬家時(shí)選紙箱的大小紙箱太大裝滿后搬不動(dòng)一旦路上散了損失慘重紙箱太小一趟一趟跑腿累死而且紙箱本身占地方。1MB到8MB這個(gè)區(qū)間既能保證單片傳輸在幾秒內(nèi)完成又能控制總片數(shù)在一個(gè)可管理范圍內(nèi)。用節(jié)省流量的邏輯來算更直觀假設(shè)網(wǎng)絡(luò)平均傳輸速度是5MB/s選1MB切片每片大約0.2秒傳完選8MB切片每片大約1.6秒傳完兩者在WAN場景下差別并不大但在LAN場景下更小的切片反而因?yàn)檎埱髷?shù)量過多而拉低吞吐。所以我實(shí)際用下來5MB左右是一個(gè)比較舒服的閾值。如果走的是互聯(lián)網(wǎng)而非內(nèi)網(wǎng)再降到2MB會(huì)更穩(wěn)。每片切完之后要給每個(gè)分片生成一個(gè)唯一的標(biāo)識。比較通用的做法是相對路徑 _ 文件大小 _ 最后修改時(shí)間 _ 切片序號。這個(gè)標(biāo)識組合能大概率避免同名文件沖突而且方便定位。## 3. 前端實(shí)操目錄讀取、文件切片與斷點(diǎn)記錄的完整實(shí)現(xiàn)3.1 從目錄選擇到文件樹構(gòu)建讓瀏覽器“看到”BIM模型的目錄結(jié)構(gòu)BIM模型一般以文件夾形式交付文件夾內(nèi)部有清晰的層級。在Web端要保留這個(gè)層級首先得讓瀏覽器能遍歷目錄。HTML5里input typefile webkitdirectory可以做到這一點(diǎn)。const input document.createElement(input); input.type file; input.webkitdirectory true; input.addEventListener(change, (e) { const files Array.from(e.target.files); const tree {}; for (const file of files) { const relativePath file.webkitRelativePath; const segments relativePath.split(/); let current tree; for (let i 0; i segments.length - 1; i) { if (!current[segments[i]]) current[segments[i]] {}; current current[segments[i]]; } current[segments[segments.length - 1]] { size: file.size, lastModified: file.lastModified, type: file.type || }; } window.__fileTree tree; window.__files files; });需要注意的是webkitRelativePath在大多數(shù)Chromium內(nèi)核瀏覽器中都能正常返回類似結(jié)構(gòu)模型/B2號樓/結(jié)構(gòu).rvt這樣的相對路徑。拿到這個(gè)路徑之后我建議立刻生成一份JSON格式的目錄樹這份JSON有兩個(gè)用途一是上傳完成后給服務(wù)端做目錄重建依據(jù)二是前端自己展示文件列表時(shí)用。還有個(gè)容易被忽略的問題目錄里可能包含隱藏文件、臨時(shí)文件、回收站殘留之類的東西。在構(gòu)建文件樹時(shí)最好做一層過濾比如排除以.開頭的文件、排除__MACOSX這類常見打包殘留目錄。國企項(xiàng)目移交過來的模型經(jīng)常帶著各種莫名其妙的文件傳上去之后不僅浪費(fèi)流量后期清理還很麻煩。3.2 文件切片與標(biāo)識生成File.slice和穩(wěn)定ID的配合文件切割在瀏覽器端非常簡單核心就是一個(gè)APIfunction createChunks(file, chunkSize 5 * 1024 * 1024) { const chunks []; let start 0; while (start file.size) { chunks.push(file.slice(start, start chunkSize)); start chunkSize; } return chunks; }file.slice()返回的是一個(gè)Blob對象它并不會(huì)真的把文件內(nèi)容復(fù)制出來而是指向原始文件數(shù)據(jù)的某一段因此內(nèi)存消耗相對可控。不過這里有一個(gè)必須注意的細(xì)節(jié)如果對文件調(diào)用slice之后原文件對象被釋放某些瀏覽器下這些Blob會(huì)變成無效引用。所以在上傳期間最好用一個(gè)數(shù)組把所有切片引用保存住直到全部上傳完成。對于斷點(diǎn)續(xù)傳每個(gè)分片需要有一個(gè)穩(wěn)定且唯一的標(biāo)識。我建議把標(biāo)識拆成兩個(gè)層級文件級別ID和分片級別索引。function buildFileId(file) { const path file.webkitRelativePath || file.name; return ${path}_${file.size}_${file.lastModified}; } function buildChunkId(fileId, index) { return ${fileId}_chunk_${index}; }這里我刻意沒有使用基于文件內(nèi)容的哈希作為切片標(biāo)識因?yàn)閷Υ笪募?jì)算全量MD5或SHA-1在瀏覽器端是很慢的甚至可能造成主線程卡頓。用路徑 大小 最后修改時(shí)間來標(biāo)識文件雖然理論上存在極小概率沖突但對內(nèi)網(wǎng)交付的模型文件來說已經(jīng)足夠可靠。如果你需要更高強(qiáng)度的校驗(yàn)可以只對第一個(gè)切片和最后一個(gè)切片做部分哈希這樣既能兼顧性能又能防止明顯的文件損壞。3.3 上傳隊(duì)列與并發(fā)控制別把服務(wù)器打懵分片數(shù)量上來之后一次性把所有分片同時(shí)發(fā)出去是不現(xiàn)實(shí)的。一個(gè)10GB的文件按5MB切大約2048片如果全部并發(fā)發(fā)起瀏覽器光在建TCP連接就把資源耗盡了而且服務(wù)端也沒辦法同時(shí)處理這么多請求。正確的做法是控制并發(fā)數(shù)。async function uploadChunksInParallel(chunks, fileId, concurrency 6) { let index 0; const tasks []; for (let i 0; i concurrency; i) { tasks.push(run()); } async function run() { while (index chunks.length) { const current index; const chunk chunks[current]; await uploadOneChunk(fileId, current, chunk); } } await Promise.all(tasks); }并發(fā)數(shù)取多少合適我試過比較多的方案內(nèi)網(wǎng)環(huán)境下6到8路并發(fā)效果最佳外網(wǎng)環(huán)境下3到4路更快。這個(gè)數(shù)字取決于服務(wù)器配置、網(wǎng)關(guān)并發(fā)限制和網(wǎng)絡(luò)帶寬。如果并發(fā)設(shè)置太高網(wǎng)關(guān)可能會(huì)直接拒絕連接設(shè)置太低又無法利用多路并行加速。每一片的上傳請求需要包含三類信息文件標(biāo)識、分片序號、分片二進(jìn)制數(shù)據(jù)。服務(wù)端應(yīng)該以文件標(biāo)識 分片序號作為冪等鍵收到重復(fù)上傳時(shí)直接返回成功這樣前端在斷點(diǎn)續(xù)傳時(shí)反復(fù)嘗試同一片也不會(huì)出問題。3.4 IndexedDB記錄進(jìn)度刷新之后繼續(xù)傳不靠運(yùn)氣斷點(diǎn)續(xù)傳的核心在于“狀態(tài)記錄”。前端每次上傳完一片都應(yīng)該把這一片的成功狀態(tài)記錄下來。刷新頁面或者瀏覽器崩潰之后通過查詢已經(jīng)上傳的分片列表就能跳過這些分片從失敗位置繼續(xù)傳。localStorage雖然簡單但容量有限通常5MB左右而且只能存字符串。一個(gè)10GB的文件有2048片每片記錄一個(gè)ID雖然字符串不會(huì)太大但如果同時(shí)管理多個(gè)文件可能就把localStorage撐爆了。更麻煩的是localStorage的讀寫是同步的頻繁寫入會(huì)阻塞UI線程。我建議用IndexedDB來存上傳進(jìn)度。它容量大、異步、性能好非常適合做斷點(diǎn)恢復(fù)這種場景。先簡單封裝一個(gè)存儲(chǔ)工具const dbName bim-upload-db; const storeName chunk-status; function openDB() { return new Promise((resolve, reject) { const request indexedDB.open(dbName, 1); request.onupgradeneeded () { const db request.result; if (!db.objectStoreNames.contains(storeName)) { const store db.createObjectStore(storeName, { keyPath: chunkId }); store.createIndex(fileId, fileId, { unique: false }); } }; request.onsuccess () resolve(request.result); request.onerror () reject(request.error); }); } async function markChunkUploaded(fileId, chunkId) { const db await openDB(); return new Promise((resolve, reject) { const tx db.transaction(storeName, readwrite); tx.objectStore(storeName).put({ fileId, chunkId, uploaded: true }); tx.oncomplete resolve; tx.onerror () reject(tx.error); }); } async function getUploadedChunks(fileId) { const db await openDB(); return new Promise((resolve, reject) { const tx db.transaction(storeName, readonly); const store tx.objectStore(storeName); const index store.index(fileId); const request index.getAll(fileId); request.onsuccess () resolve(request.result.map(item item.chunkId)); request.onerror () reject(request.error); }); }有了這個(gè)進(jìn)度存儲(chǔ)上傳流程就變成了啟動(dòng)上傳前先查IndexedDB把已經(jīng)成功上傳的分片序號過濾掉只排尚未上傳的切片進(jìn)入隊(duì)列。這樣一來哪怕之前傳了一半瀏覽器崩了下次打開頁面選擇同一目錄系統(tǒng)自動(dòng)識別同一批文件ID直接跳過已傳部分。這里有個(gè)必須要提醒的點(diǎn)IndexedDB里的記錄是“前端視角”的它代表的只是瀏覽器曾經(jīng)發(fā)出過成功響應(yīng)。如果服務(wù)端在接收某一片之后、返回成功之前崩潰了前端記錄成功但實(shí)際上后端的這一片是殘缺的。所以服務(wù)端必須在每次分片上傳時(shí)做文件大小的校驗(yàn)拼接時(shí)再做一次整體校驗(yàn)雙保險(xiǎn)。3.5 合并請求與整體校驗(yàn)分片傳完了不代表文件沒問題所有分片都傳完之后前端需要調(diào)用一個(gè)合并接口通知服務(wù)端把臨時(shí)目錄里的分片按順序拼接成完整文件。合并請求里要帶上文件ID、總大小、總分片數(shù)、原始相對路徑。服務(wù)端在做合并之前會(huì)先檢查分片數(shù)量和大小是否吻合再執(zhí)行合并。合并完成后我強(qiáng)烈建議做一次文件級校驗(yàn)。最簡單的方式是前端在構(gòu)建文件ID時(shí)記錄文件總大小合并后由服務(wù)端返回合并后的文件大小和哈希值前端進(jìn)行比對。如果要做更嚴(yán)格的校驗(yàn)可以對整個(gè)文件做一次MD5計(jì)算但大文件的整體哈希計(jì)算在服務(wù)端也需要一定時(shí)間所以實(shí)際工程中我更傾向于讓前端對文件的第一個(gè)和最后一個(gè)切片做MD5作為強(qiáng)校驗(yàn)的近似替代其余切片用大小校驗(yàn)兜底。校驗(yàn)通過之后目錄樹JSON和文件實(shí)體是分離的。前端在上傳分片的同時(shí)應(yīng)該把目錄樹數(shù)據(jù)一并提交給服務(wù)端元數(shù)據(jù)表。服務(wù)端拿到目錄樹和數(shù)據(jù)文件后會(huì)按相對路徑在目標(biāo)存儲(chǔ)位置重建目錄結(jié)構(gòu)把文件落到對應(yīng)目錄節(jié)點(diǎn)下。這個(gè)過程可以在合并接口里一并處理省去一次請求。4. 后端配合接口設(shè)計(jì)、合并策略與存儲(chǔ)規(guī)劃4.1 三個(gè)核心接口初始化、上傳分片、合并前端做得再好后端接口設(shè)計(jì)跟不上也是白搭。我們只需要三個(gè)核心接口不復(fù)雜但每一步都要考慮邊界情況。第一個(gè)是初始化接口。前端在開始上傳前先調(diào)用它把自己要傳的文件ID、文件總大小、文件名、相對路徑發(fā)給服務(wù)端。服務(wù)端返回一個(gè)uploadId并在臨時(shí)目錄下創(chuàng)建以uploadId為名的子目錄后續(xù)該文件的所有分片都存在這個(gè)目錄里。第二個(gè)是上傳分片接口。請求參數(shù)包括uploadId、chunkIndex、chunkSize二進(jìn)制分片數(shù)據(jù)放在請求體中。服務(wù)端把分片寫入臨時(shí)目錄/uploadId/chunkIndex.part然后返回成功。如果這個(gè)分片已經(jīng)存在且大小一致直接返回200不上傳也沒問題。第三個(gè)是合并接口。參數(shù)包括uploadId、文件總大小、總分片數(shù)、目錄樹JSON。服務(wù)端先校驗(yàn)分片完整性然后按索引順序合并寫入最終存儲(chǔ)路徑最后重建目錄樹。合并成功之后刪除臨時(shí)目錄返回文件元數(shù)據(jù)。我遇到的比較常見的問題是很多團(tuán)隊(duì)在初始化接口里就做了大量業(yè)務(wù)判斷比如數(shù)據(jù)庫查重、權(quán)限校驗(yàn)、隊(duì)列檢查結(jié)果初始化慢得像龜速。工業(yè)級場景應(yīng)該把初始化接口做得盡量輕量只負(fù)責(zé)創(chuàng)建上傳會(huì)話所有業(yè)務(wù)判斷放在后續(xù)流程里異步執(zhí)行。4.2 服務(wù)端分片存儲(chǔ)與合并策略流式拼接比內(nèi)存拼接靠譜服務(wù)端接收分片時(shí)最容易犯的錯(cuò)誤是把所有分片讀入內(nèi)存再拼接。一個(gè)5MB的分片乘以2048片就是10GB內(nèi)存正常的服務(wù)器根本扛不住。正確的做法是分部落地。每收到一片直接使用文件流寫入磁盤路徑按uploadId 序號組織。合并時(shí)逐片打開文件使用流式方式將內(nèi)容追加到目標(biāo)文件尾部。Node.js里用createReadStream和createWriteStream配合管道操作每合并完一片就關(guān)閉資源內(nèi)存占用始終保持恒定。合并校驗(yàn)的策略也要細(xì)化。我通常會(huì)維護(hù)一個(gè)分片元信息表記錄每片的實(shí)際大小。合并前檢查兩件事已上傳分片的數(shù)量是否等于總分片數(shù)、每片的大小是否與預(yù)期一致。如果發(fā)現(xiàn)缺失或缺損返回前端一個(gè)“缺失分片列表”讓前端針對性重傳缺失的片而不是整個(gè)文件重傳。這種“按需補(bǔ)片”機(jī)制在弱網(wǎng)環(huán)境下尤其好用。關(guān)于磁盤規(guī)劃臨時(shí)目錄要有獨(dú)立的分區(qū)不能和系統(tǒng)目錄混在一起。之前我遇到過一次項(xiàng)目臨時(shí)目錄寫在系統(tǒng)盤模型上傳量一大系統(tǒng)盤被塞滿整個(gè)服務(wù)器直接無響應(yīng)。臨時(shí)目錄的清理策略也要有。合并成功之后立即刪除對應(yīng)分片這是最基礎(chǔ)的要求。還要加一個(gè)定時(shí)任務(wù)清理超過48小時(shí)仍處于未完成狀態(tài)的上傳目錄防止黑客或異常任務(wù)占滿磁盤。4.3 并發(fā)沖突與重復(fù)分片的冪等處理上傳過程中前端可能會(huì)因?yàn)榫W(wǎng)絡(luò)超時(shí)對同一個(gè)分片重復(fù)請求。服務(wù)端必須對這種情況做冪等處理。用uploadId chunkIndex作為主鍵如果發(fā)現(xiàn)同一個(gè)分片已經(jīng)存在且大小一致就直接返回成功不重復(fù)寫磁盤。合并操作的并發(fā)控制同樣重要。我建議用一個(gè)鎖標(biāo)記來防止同一個(gè)uploadId被多個(gè)合并請求同時(shí)操作。比如在數(shù)據(jù)庫會(huì)話表里加一個(gè)mergeStatus字段合并中、合并完成、合并失敗。前端偶爾會(huì)因?yàn)槌瑫r(shí)對合并接口重復(fù)請求一對服務(wù)端看到“合并中”狀態(tài)可以適當(dāng)阻塞等待看到“合并完成”直接返回結(jié)果避免合并邏輯執(zhí)行兩次產(chǎn)生臟數(shù)據(jù)。5. 國企工程場景下繞不開的坑與排查實(shí)錄5.1 網(wǎng)絡(luò)波動(dòng)與斷網(wǎng)恢復(fù)指數(shù)退避重試是基礎(chǔ)操作國企內(nèi)網(wǎng)雖然有專線但不算穩(wěn)定。特別是部分老辦公樓里的網(wǎng)絡(luò)設(shè)備高峰期經(jīng)常出現(xiàn)大量丟包。分片上傳遇到單次網(wǎng)絡(luò)失敗是常態(tài)所以前端必須有一套重試機(jī)制。我比較推薦指數(shù)退避策略第一次失敗等1秒重試第二次失敗等2秒第三次等4秒最多重試5次。如果連續(xù)5次失敗就把這個(gè)分片標(biāo)記為失敗但不中斷整個(gè)上傳流程而是繼續(xù)處理其他分片失敗的分片放到隊(duì)列末尾最后統(tǒng)一補(bǔ)傳。實(shí)際體驗(yàn)下來這種“邊傳邊補(bǔ)”的策略比“遇到失敗就停止整個(gè)上傳”強(qiáng)太多因?yàn)榫W(wǎng)絡(luò)抖動(dòng)通常是短暫的給一小段時(shí)間它自己就恢復(fù)了。斷網(wǎng)的情況更特殊。瀏覽器檢測到網(wǎng)絡(luò)斷開時(shí)所有請求會(huì)失敗。這時(shí)候前端應(yīng)該暫停整個(gè)上傳隊(duì)列監(jiān)聽online事件網(wǎng)絡(luò)恢復(fù)后重新查詢IndexedDB里的上傳狀態(tài)對未完成的分片繼續(xù)上傳。在這個(gè)過程中不需要刷新頁面體驗(yàn)是連續(xù)的。5.2 瀏覽器崩潰與內(nèi)存占用優(yōu)化用Web Worker把哈希計(jì)算挪到后臺瀏覽器崩潰是分片上傳最容易遇到的問題大多數(shù)原因是內(nèi)存占用過高。雖然File.slice()不會(huì)一次把整個(gè)文件載入內(nèi)存但部分場景下比如多個(gè)文件同時(shí)讀取、切片對象持有大量引用內(nèi)存還是會(huì)快速攀升。我的經(jīng)驗(yàn)是每次從磁盤讀取一個(gè)切片后立即上傳并釋放引用不要一次性把所有切片都放進(jìn)一個(gè)數(shù)組里。上面給出的createChunks示例雖然是全量創(chuàng)建但實(shí)際項(xiàng)目中我會(huì)改為懶加載切片function getChunk(file, chunkSize, index) { const start index * chunkSize; const end Math.min(start chunkSize, file.size); return file.slice(start, end); }這樣每次只保留當(dāng)前正在上傳的幾片內(nèi)存占用大幅降低。如果是做全量文件哈希校驗(yàn)一定不要在主線程做。一個(gè)10GB文件的全量MD5計(jì)算在瀏覽器里可能需要幾十秒甚至幾分鐘在這期間頁面會(huì)卡死。正確做法是把文件交給Web Worker在Worker線程里分片讀取并計(jì)算哈希計(jì)算完畢通過postMessage把結(jié)果傳回主線程。這樣用戶可以繼續(xù)操作界面不會(huì)出現(xiàn)“頁面已失去響應(yīng)”的尷尬。5.3 老舊瀏覽器與國產(chǎn)化內(nèi)核兼容降級方案要提前想好國企辦公環(huán)境里瀏覽器的實(shí)際情況可能超出技術(shù)人員想象。有大量存量電腦還在使用老版本的Chromium內(nèi)核瀏覽器有些國產(chǎn)瀏覽器默認(rèn)跑在兼容模式下。這些環(huán)境下webkitdirectory、IndexedDB這些特性可能是缺失的。我建議在頁面加載時(shí)做一次能力檢測分別檢測File.slice、webkitdirectory、indexedDB是否可用。如果某一項(xiàng)缺失就啟用降級方案。比如沒有IndexedDB就用localStorage存進(jìn)度沒有webkitdirectory就不支持目錄選擇改為讓用戶選擇單個(gè)文件或壓縮包實(shí)在不行就退回最原始的整包上傳方案。雖然這些降級方案體驗(yàn)差很多但總比“打開頁面什么都做不了”強(qiáng)。我遇到過某國企內(nèi)網(wǎng)瀏覽器連File.slice都不支持的情況那套系統(tǒng)所有文件上傳都只能走傳統(tǒng)方式這是平臺底層的硬傷前端只能盡量兼容沒法完全替代。### 5.4 安全與審計(jì)模型文件是核心資產(chǎn)不能裸奔BIM模型在工程項(xiàng)目里屬于核心數(shù)據(jù)資產(chǎn)里面包含了完整的建筑結(jié)構(gòu)信息、設(shè)備參數(shù)、工程量清單一旦泄露或者被篡改后果非常嚴(yán)重。所以上傳過程不能只想著“傳上去就行”還得考慮安全與審計(jì)。權(quán)限控制是第一層。上傳接口必須驗(yàn)證用戶身份不能匿名上傳。我當(dāng)時(shí)所在的系統(tǒng)對接了統(tǒng)一的身份認(rèn)證平臺上傳時(shí)每次請求都要攜帶token。分片上傳接口也同樣校驗(yàn)不能因?yàn)樗恰安糠謹(jǐn)?shù)據(jù)”就放寬權(quán)限。操作日志是第二層。上傳開始、分片接收、合并完成、文件刪除這些操作都要記錄到日志系統(tǒng)。日志里至少要包含操作人、操作時(shí)間、文件ID、分片序號、結(jié)果狀態(tài)。國企項(xiàng)目的審計(jì)是要落實(shí)到具體人和具體操作的這個(gè)不能省。文件校驗(yàn)是第三層。合并完成后對文件做一次病毒掃描和類型檢測。你可能會(huì)覺得奇怪模型文件怎么會(huì)有病毒但實(shí)際上從外部協(xié)作單位移交的模型包經(jīng)常混入各種可執(zhí)行文件、宏病毒、惡意鏈接。服務(wù)端在把文件暴露給其他系統(tǒng)訪問之前必須經(jīng)過安全檢測。這不僅是技術(shù)問題更是合規(guī)問題。6. 實(shí)測效果、踩坑記錄與可復(fù)用的經(jīng)驗(yàn)6.1 實(shí)測環(huán)境與最終效果在項(xiàng)目收尾階段我們做了幾輪壓測。測試環(huán)境是一套典型的國企內(nèi)網(wǎng)配置一臺4核8GB的應(yīng)用服務(wù)器一臺文件存儲(chǔ)服務(wù)器客戶端是普通辦公電腦。測試對象是一個(gè)約35GB的綜合BIM模型包包含5600多個(gè)文件目錄層級在5層左右。使用5MB分片、6路并發(fā)、開啟IndexedDB斷點(diǎn)恢復(fù)的方案整體上傳耗時(shí)大約2小時(shí)左右。期間人為中斷了兩次網(wǎng)絡(luò)每次恢復(fù)后系統(tǒng)都能自動(dòng)從斷點(diǎn)繼續(xù)沒有出現(xiàn)重復(fù)上傳已成功的分片。服務(wù)端合并完成后校驗(yàn)文件大小與源文件完全一致目錄結(jié)構(gòu)也按照原始樹狀關(guān)系落到了存儲(chǔ)區(qū)。相比之前用普通上傳方式“傳一天斷三次”的體驗(yàn)這套方案可以說是從“不可用”變成了“可用”。6.2 踩過的坑與對應(yīng)解決方法第一個(gè)坑是并發(fā)數(shù)設(shè)置過高導(dǎo)致服務(wù)端連接數(shù)被打滿。第一次測試時(shí)我圖快直接上了20路并發(fā)結(jié)果應(yīng)用服務(wù)器的連接池瞬間被耗盡所有請求全部排隊(duì)等待整個(gè)Web應(yīng)用的其他功能也跟著卡住。后來把并發(fā)數(shù)降到6問題消失。這個(gè)參數(shù)最好做成配置項(xiàng)根據(jù)實(shí)際服務(wù)器負(fù)載動(dòng)態(tài)調(diào)整。第二個(gè)坑是目錄名里包含中文、空格和特殊符號。模型交付方經(jīng)常用“B2號樓-裝修-2024-最終版”這種命名方式。如果文件ID直接用整個(gè)相對路徑拼接偶爾會(huì)出現(xiàn)空格導(dǎo)致的解析錯(cuò)誤。解決辦法是在生成文件ID時(shí)用編碼后的相對路徑或者把路徑單獨(dú)作為一個(gè)字段存放不在ID里直接拼接。第三個(gè)坑是合并時(shí)對大文件使用同步拼接導(dǎo)致服務(wù)端無響應(yīng)。最初的實(shí)現(xiàn)是把所有分片讀入數(shù)組再用Buffer.concat合并一個(gè)4GB的文件直接導(dǎo)致內(nèi)存溢出。改成流式合并之后就穩(wěn)定了。這就是我前面反復(fù)強(qiáng)調(diào)流式處理的原因——在這個(gè)場景里它不是一個(gè)可選項(xiàng)而是必須項(xiàng)。第四個(gè)坑是清理任務(wù)誤刪未完成的上傳目錄。定時(shí)清理我最初設(shè)置的閾值是24小時(shí)但有些超大模型文件因?yàn)榫W(wǎng)絡(luò)原因連續(xù)傳了超過24小時(shí)結(jié)果被清理任務(wù)在合并前刪掉了。后來我把閾值改成48小時(shí)并且加了個(gè)“有進(jìn)行中上傳任務(wù)”的保護(hù)判斷才徹底解決。6.3 一個(gè)很實(shí)用的小技巧服務(wù)端返回缺失分片列表最后分享一個(gè)我自己覺得特別實(shí)用的技巧。在合并接口的校驗(yàn)階段服務(wù)端除了返回“失敗”之外還要返回具體的缺失或異常分片序號列表。前端拿到這個(gè)列表后只需要重傳這幾片然后再次調(diào)用合并接口。這個(gè)過程可以循環(huán)直到合并成功。這種方法在處理“某些分片損壞但不清楚是哪些”的情況下非常高效比無腦全量重傳強(qiáng)一個(gè)量級。我之所以一直強(qiáng)調(diào)這個(gè)方案里的“分片斷點(diǎn)目錄結(jié)構(gòu)”三件套要組合起來看是因?yàn)樵谡鎸?shí)的國企工程建筑場景里這三個(gè)需求從來都是同時(shí)出現(xiàn)的。一個(gè)只支持分片上傳、不支持?jǐn)帱c(diǎn)恢復(fù)的插件在弱網(wǎng)條件下仍然會(huì)讓工程師崩潰一個(gè)支持?jǐn)帱c(diǎn)但忽略目錄結(jié)構(gòu)的上傳工具傳完之后下游工具用不了等于白傳。只有把三者打通才能真正解決生產(chǎn)環(huán)境里的問題。如果你也正在處理類似的需求建議先拿一個(gè)真實(shí)的BIM模型包做測試不要用幾個(gè)小文件模擬。真實(shí)場景下的大文件數(shù)量、目錄深度、命名習(xí)慣都會(huì)逼著你把邊界情況想清楚。這套方案跑通之后后續(xù)無論是擴(kuò)展上傳進(jìn)度展示、增加上傳任務(wù)隊(duì)列還是對接消息通知都是在現(xiàn)有骨架上做增量開發(fā)很順手。