在銀行系統(tǒng)待久了就明白大文件上傳從來不只是“把文件丟到服務(wù)器”那么簡單。柜面掃描的影像件、批量對賬的流水包、信貸審批的合同附件、遠(yuǎn)程辦公要傳的報(bào)表隨便一個就奔著幾百M(fèi)B甚至幾個GB去。選錯了上傳控件內(nèi)網(wǎng)里看起來一切正常一旦用戶換到外網(wǎng)、跨運(yùn)營商甚至用手機(jī)熱點(diǎn)就開始各種超時、斷傳、服務(wù)端內(nèi)存飆升。我在銀行系統(tǒng)的運(yùn)維和架構(gòu)崗位上待了快十年前前后后經(jīng)手過三個上傳組件的選型替換踩過的坑能列一長串。這篇內(nèi)容就把銀行場景下選擇高效大文件上傳控件這件事掰開揉碎從需求分析、技術(shù)方案對比、落地實(shí)操到問題排查完整過一遍。適合正在做選型評估的架構(gòu)師也適合被上傳問題反復(fù)折騰的開發(fā)同學(xué)參考。先亮明一個觀點(diǎn)選上傳控件本質(zhì)上是選一套“傳輸協(xié)議加服務(wù)端處理策略”而不是挑一個花哨的前端組件。進(jìn)度條、拖拽上傳這些是面子分片、斷點(diǎn)續(xù)傳、失敗重試、服務(wù)端合并、完整性校驗(yàn)才是里子。銀行系統(tǒng)尤其講究穩(wěn)定、安全、可審計(jì)所以下面所有內(nèi)容都會圍繞這幾點(diǎn)展開不繞彎子。1. 銀行場景的上傳需求先把賬算清楚1.1 銀行文件上傳的特殊性不只是“大”這么簡單銀行系統(tǒng)里的文件上傳和其他行業(yè)的差別非常大。最大的差異在于文件本身的業(yè)務(wù)價值和風(fēng)險。一筆信貸審批的影像材料傳輸中途少了一個分片事后審計(jì)調(diào)檔發(fā)現(xiàn)材料缺失就是風(fēng)險事件。所以銀行對上傳的要求從來不只是“越快越好”而是要在保證完整、可追溯的前提下盡量快。具體來看銀行系統(tǒng)里的文件上傳有幾個典型特征。第一是文件類型多樣除了常見的圖片和PDF還有批量導(dǎo)入的賬務(wù)文件、格式固定的對賬單、加密壓縮包、甚至柜面錄制的視頻。不同類型的文件對傳輸和存儲的要求完全不一樣視頻對實(shí)時性要求低但對完整性要求極高批量賬務(wù)文件則可能在導(dǎo)入后馬上被下游跑批上傳慢一分鐘整條業(yè)務(wù)鏈就往后推一分鐘。第二是網(wǎng)絡(luò)環(huán)境極端復(fù)雜柜面走內(nèi)網(wǎng)帶寬穩(wěn)定延遲低客戶自助端走公網(wǎng)可能處于弱網(wǎng)環(huán)境行員移動辦公走的內(nèi)網(wǎng)接入通道也可能不穩(wěn)定。第三是并發(fā)和峰值明顯月末、季末、年末批量處理期間大量網(wǎng)點(diǎn)同時上傳報(bào)表瞬間流量可能比平時高出一個數(shù)量級。這些特殊性決定了選型不能簡單照搬互聯(lián)網(wǎng)公司的方案?；ヂ?lián)網(wǎng)公司可以接受一定失敗率靠重試和補(bǔ)償保證最終一致但銀行系統(tǒng)對失敗必須提前設(shè)計(jì)降級方案和手工補(bǔ)傳通道。選型時如果只盯著“快”很容易忽視這些前提。1.2 選型前必須回答的八個問題在做任何技術(shù)對比之前我強(qiáng)烈建議先做一輪需求梳理。我每次參加選型評審都會要求業(yè)務(wù)方和開發(fā)一起回答下面八個問題答完再談控件選型。第一個問題是單個文件的最大值是多少。很多業(yè)務(wù)方張口就說“一般也就幾十兆”但實(shí)際生產(chǎn)環(huán)境里出現(xiàn)過單文件4GB的影像合集。最大值直接決定要不要上分片以及分片大小怎么設(shè)計(jì)。第二個問題是日傳輸總量和峰值并發(fā)是多少這決定控件要不要支持并發(fā)上傳以及服務(wù)端需要預(yù)留多少處理能力。第三個問題是終端環(huán)境固定柜面PC、行員自帶筆記本、客戶手機(jī)瀏覽器這三類終端的瀏覽器版本和系統(tǒng)能力差異很大有些老終端根本跑不動新特性。第四個問題是網(wǎng)絡(luò)環(huán)境內(nèi)網(wǎng)還是公網(wǎng)帶寬大概多少是否跨運(yùn)營商是否需要支持弱網(wǎng)和斷線重連。第五個問題是安全合規(guī)要求文件要不要加密傳輸落盤后要不要做病毒掃描上傳日志要不要留存這些必須在選型前明確否則后面全是返工。第六個問題是后端現(xiàn)有技術(shù)棧Java、其他語言還是混合架構(gòu)存儲用本地磁盤、分布式文件系統(tǒng)還是對象存儲接口風(fēng)格是RESTful還是別的上傳控件必須和后端無縫對接。第七個問題是團(tuán)隊(duì)對開源組件的掌控力有沒有人能讀懂源碼、會修bug如果出了問題是找商業(yè)廠商支持還是自己扛。第八個問題是使用環(huán)境是否有信創(chuàng)適配要求有些銀行要求控件必須在特定的國產(chǎn)芯片、操作系統(tǒng)和瀏覽器環(huán)境下正常運(yùn)行這一步不確認(rèn)前面做得再多也可能全部推翻。這八個問題看起來很基礎(chǔ)但幾乎每次選型失敗追根溯源都是因?yàn)槟骋粋€問題的答案和實(shí)際不符。比如只想著文件挺大沒想到有弱網(wǎng)結(jié)果上傳控件沒有斷點(diǎn)續(xù)傳客戶用手機(jī)傳一個200MB的文件眼看著到99%斷了全部重來投訴電話很快就會打進(jìn)客服。需求整理清楚接下來才進(jìn)入技術(shù)方案對比階段。2. 主流上傳方案對比選型前先看清楚路2.1 三類基礎(chǔ)傳輸方式表單直傳、二進(jìn)制流、分片上傳先講技術(shù)底層的傳輸方式因?yàn)樗猩蟼骺丶谋举|(zhì)都跑不出這三類。第一類是傳統(tǒng)的表單直傳也就是瀏覽器提交multipart/form-data把整個文件一次性POST到服務(wù)器。這種方式的優(yōu)點(diǎn)是實(shí)現(xiàn)極其簡單后端一個上傳接口就能接住兼容性最好缺點(diǎn)也很明顯文件稍大就容易觸發(fā)網(wǎng)關(guān)超時傳輸過程沒有進(jìn)度條一旦失敗就要整體重傳。在銀行內(nèi)網(wǎng)環(huán)境里10MB以內(nèi)的文件用表單直傳問題不大但超過這個量級就不建議了。第二類是AJAX二進(jìn)制流上傳用XMLHttpRequest的send方法直接把文件二進(jìn)制發(fā)過去。相比表單直傳它的進(jìn)步在于可以實(shí)時拿到上傳進(jìn)度也能在傳輸過程中取消請求。但本質(zhì)上還是一次性把整個文件讀入內(nèi)存再發(fā)送對大文件來說內(nèi)存占用高而且依然沒有斷點(diǎn)續(xù)傳。我在實(shí)際項(xiàng)目里見過有人用這種方式傳500MB的文件前端頁面直接卡死服務(wù)端內(nèi)存被打滿最后整個應(yīng)用容器都受影響。第三類是分片上傳把文件按固定大小切成若干片逐片或并發(fā)上傳到服務(wù)器最后在服務(wù)端合并。這是當(dāng)前解決大文件上傳的主流方案核心價值有三點(diǎn)支持?jǐn)帱c(diǎn)續(xù)傳某一分片失敗后只需重傳該分片支持并發(fā)傳輸可以同時傳多個分片充分利用帶寬能夠?qū)崟r計(jì)算總體進(jìn)度用戶體驗(yàn)要好得多。代價是協(xié)議變復(fù)雜前端要做切片邏輯后端要負(fù)責(zé)分片接收、校驗(yàn)和合并整體工作量上一個臺階。銀行系統(tǒng)選擇上傳控件我?guī)缀醪豢紤]表單直傳直接用分片上傳作為基座因?yàn)樗娜蒎e能力是所有方案里最適合生產(chǎn)環(huán)境的。2.2 商業(yè)控件、開源框架、自研組件三種供給方式怎么選確定技術(shù)路線是分片上傳之后接下來要回答的問題是組件從哪里來市面上大致有三條路商業(yè)控件、開源框架、自研組件。商業(yè)控件的優(yōu)點(diǎn)是一站式交付前端控件、服務(wù)端SDK、技術(shù)支持都齊了功能上通常還附帶秒傳、批量上傳、壓縮預(yù)覽等增強(qiáng)能力。銀行選用商業(yè)控件的謹(jǐn)慎點(diǎn)在于授權(quán)費(fèi)用的持續(xù)性以及源碼不可見帶來的排查障礙。在信創(chuàng)環(huán)境下不是所有商業(yè)控件都能適配國產(chǎn)瀏覽器和國產(chǎn)服務(wù)器這個要提前拿到廠商測試報(bào)告或者做一輪實(shí)際驗(yàn)證。我參與過的一個項(xiàng)目中廠商承諾適配某國產(chǎn)瀏覽器結(jié)果現(xiàn)場演示時控件直接加載不出來場面相當(dāng)尷尬。開源框架是很多團(tuán)隊(duì)的首選好處是免費(fèi)、源碼開放、社區(qū)案例多出了問題可以自己看代碼。但“免費(fèi)”不等于“沒成本”。引入開源上傳組件實(shí)際上承擔(dān)了維護(hù)責(zé)任包括版本升級、安全漏洞修復(fù)、瀏覽器兼容性調(diào)整這些都需要有人力投入。銀行如果完全沒有前端和后端的技術(shù)儲備建議謹(jǐn)慎引入否則遇到問題連求助都不知道怎么描述。自研組件看起來最可控實(shí)際上也最容易被低估成本。一套基本可用的分片上傳體系前端要處理切片、并發(fā)、進(jìn)度、重試、秒傳后端要處理元數(shù)據(jù)、分片存儲、合并、一致性校驗(yàn)還要考慮負(fù)載均衡多節(jié)點(diǎn)下的文件合并和臨時文件清理按三到六個人年估算并不夸張。如果只是為一兩個上傳場景自研成本太高。我的建議是有明顯的強(qiáng)需求例如超大文件、極致弱網(wǎng)要求且團(tuán)隊(duì)有技術(shù)底子的優(yōu)先基于成熟開源框架做二次封裝沒有技術(shù)底子的直接買商業(yè)控件把錢花在服務(wù)上只有數(shù)據(jù)量特別龐大、業(yè)務(wù)定制要求極高的場景才認(rèn)真考慮自研。銀行選型最怕的就是什么都自己造最后留下一堆無人維護(hù)的技術(shù)債。另外要提醒一點(diǎn)不管選商業(yè)還是開源都要把“可替換性”寫進(jìn)評價指標(biāo)。上傳控件應(yīng)該是業(yè)務(wù)系統(tǒng)的一個外部適配層接口設(shè)計(jì)成可插拔的最好不要讓上游業(yè)務(wù)代碼直接依賴控件的內(nèi)部對象。這樣將來因?yàn)楹弦?guī)、成本、性能原因換掉底層實(shí)現(xiàn)時業(yè)務(wù)代碼可以不動只替換適配層。這個原則等于給系統(tǒng)上了一層保險時間越久價值越明顯。2.3 把“高效”量化成可打分的評估表說完供給方式再講怎么評估。很多銀行在選型時容易犯的錯是把“高效”理解成“傳得快”。實(shí)際上對上傳控件而言“高效”至少包含傳輸性能、穩(wěn)定性、資源占用、開發(fā)效率和運(yùn)維友好度五個維度。我列一張?jiān)u估表每項(xiàng)按0到5分打分總分高的不一定就選它但至少把主觀印象變成可比較的數(shù)據(jù)。評估維度考察要點(diǎn)建議權(quán)重穩(wěn)定性重試機(jī)制、斷點(diǎn)續(xù)傳可靠性、意外斷網(wǎng)恢復(fù)能力30%安全合規(guī)加密傳輸、審計(jì)日志、權(quán)限控制、防濫用能力25%傳輸性能單文件速度、批量效率、大文件并發(fā)性能20%資源占用瀏覽器端內(nèi)存/CPU、服務(wù)端內(nèi)存/磁盤IO15%開發(fā)與運(yùn)維API設(shè)計(jì)、文檔完整度、日志與監(jiān)控接入難度10%傳輸性能要看真實(shí)網(wǎng)絡(luò)環(huán)境下的實(shí)測數(shù)據(jù)不要看文檔里的理論值。測的時候分內(nèi)網(wǎng)、跨運(yùn)營商、弱網(wǎng)環(huán)境分別記錄拉一張對比表。穩(wěn)定性方面重點(diǎn)驗(yàn)證重試機(jī)制是否完善、斷點(diǎn)續(xù)傳是否準(zhǔn)確、意外斷網(wǎng)后能否恢復(fù)。資源占用方面用同一臺低配PC分別跑不同控件觀察任務(wù)管理器里的內(nèi)存和CPU數(shù)據(jù)差異可能非常大。開發(fā)與運(yùn)維方面看控件API設(shè)計(jì)是否清晰、文檔是否完整、日志能否方便接入監(jiān)控告警一個黑盒上傳組件運(yùn)維團(tuán)隊(duì)是不敢接的。權(quán)重分配也是門學(xué)問。我習(xí)慣把穩(wěn)定性和安全合規(guī)權(quán)重調(diào)高傳輸性能只占兩成。道理很簡單對銀行來說一次上傳失敗造成的時間成本和合規(guī)風(fēng)險遠(yuǎn)大于傳輸峰值快幾秒帶來的收益。這個評分表做完再結(jié)合商務(wù)條件和團(tuán)隊(duì)情況選型結(jié)果往往已經(jīng)很清楚了。3. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)落地一個可用的分片上傳方案3.1 協(xié)議設(shè)計(jì)先行前端后端各自要做什么選型最終要落到實(shí)現(xiàn)。不管選的是商業(yè)組件還是開源框架都需要理解分片上傳的協(xié)議設(shè)計(jì)否則出了問題根本無從下手。一個標(biāo)準(zhǔn)的分片上傳協(xié)議至少包含三個接口創(chuàng)建上傳任務(wù)、上傳分片、合并文件。創(chuàng)建上傳任務(wù)的接口入?yún)⒁话闶俏募?、文件大小、分片大小和文件唯一?biāo)識后端根據(jù)這些信息生成一個上傳任務(wù)ID并在存儲端創(chuàng)建臨時目錄。這個接口同時承擔(dān)初始化工作如果文件已經(jīng)存在可以直接返回“秒傳”標(biāo)記省去整個傳輸過程。上傳分片的接口入?yún)⑹侨蝿?wù)ID、分片序號和分片數(shù)據(jù)。后端把分片寫入臨時目錄文件名按規(guī)則命名例如任務(wù)ID加序號加擴(kuò)展名。這里必須做冪等處理如果同一分片被重復(fù)上傳應(yīng)該直接覆蓋或者返回成功而不是報(bào)錯因?yàn)榍岸耸≈卦嚂r很可能把同一個分片提交兩次。合并文件的接口入?yún)⑹侨蝿?wù)ID后端把所有分片按順序讀出來以流式方式拼接成完整文件然后做一次完整性校驗(yàn)。校驗(yàn)通過后再轉(zhuǎn)入業(yè)務(wù)存儲目錄進(jìn)入病毒掃描、內(nèi)容審核這些下游環(huán)節(jié)。前端的核心邏輯主要有四塊文件切片利用瀏覽器的文件讀取能力把File對象按指定大小切出分片并發(fā)控制同時啟動N路上傳任務(wù)每路負(fù)責(zé)一個分片進(jìn)度計(jì)算用已成功上傳的分片數(shù)除以總分片數(shù)得到百分比異常處理分片失敗時自動重試達(dá)到重試上限后標(biāo)記為失敗并允許用戶手動續(xù)傳。這里要特別說明分片上傳不等于必須自研底層協(xié)議。用開源成熟框架時這些接口基本都實(shí)現(xiàn)好了只需要理解協(xié)議原理然后在后端SDK基礎(chǔ)上做業(yè)務(wù)適配。選商業(yè)控件的更是開箱即用。但我仍然強(qiáng)烈建議至少自己動手寫一遍簡化版這樣當(dāng)生產(chǎn)環(huán)境出現(xiàn)“合并的文件不完整”“重試后產(chǎn)生臟數(shù)據(jù)”這類問題時能快速定位是協(xié)議設(shè)計(jì)問題還是實(shí)現(xiàn)缺陷。拿一個簡單的偽代碼來說明前端切片邏輯// 簡化示例切分文件并逐個上傳 const CHUNK_SIZE 5 * 1024 * 1024; // 5MB let start 0; let index 0; while (start file.size) { const blob file.slice(start, start CHUNK_SIZE); const formData new FormData(); formData.append(taskId, taskId); formData.append(index, index); formData.append(chunk, blob); await uploadChunk(formData); // 并發(fā)場景下可改為批量發(fā)起 start CHUNK_SIZE; }這只是一個最簡模型真實(shí)系統(tǒng)還要加并發(fā)控制、進(jìn)度回調(diào)、錯誤重試和任務(wù)狀態(tài)持久化但協(xié)議骨架就是這個樣子。想清楚這三個接口前端后端各司其職選型時就多了不少底氣。3.2 幾個關(guān)鍵參數(shù)的計(jì)算邏輯分片大小、并發(fā)數(shù)、重試策略分片大小和并發(fā)數(shù)的設(shè)置直接決定上傳體驗(yàn)和后端壓力。很多團(tuán)隊(duì)直接照搬網(wǎng)上某個方案用5MB分片加10并發(fā)結(jié)果內(nèi)網(wǎng)環(huán)境跑得很歡一旦遇到弱網(wǎng)小分片反而被大量反復(fù)重傳拖慢。正確的做法是根據(jù)實(shí)測帶寬和目標(biāo)延遲來計(jì)算而不是拍腦袋。先說分片大小。一個樸素的目標(biāo)是讓單個分片的傳輸時間控制在0.5秒到3秒之間。假設(shè)實(shí)測帶寬是10Mbps也就是約1.25MB/s那么5MB分片約4秒傳完對弱網(wǎng)偏大改成2MB分片差不多1.6秒一片體感會好很多。反過來帶寬是100Mbps時10MB分片傳輸時間約0.8秒服務(wù)端合并次數(shù)又少更合適。所以分片大小要和帶寬匹配弱網(wǎng)用小分片強(qiáng)網(wǎng)用大分片。成熟的框架支持動態(tài)調(diào)整分片大小銀行場景我建議把這一點(diǎn)加入選型要求。再說并發(fā)數(shù)。并發(fā)太高瀏覽器容易把連接占滿服務(wù)端也扛不住并發(fā)太低帶寬利用率上不去。我的經(jīng)驗(yàn)值在3到6路之間具體要看后端處理能力和網(wǎng)絡(luò)情況。一個簡單的估算方法是把期望取得的傳輸帶寬除以單分片傳輸帶寬再加一點(diǎn)冗余。例如目標(biāo)是要跑滿20Mbps帶寬單分片在2Mbps下工作并發(fā)4到6路基本足夠。并發(fā)不是越大越好超過一定閾值吞吐量反而下降因?yàn)榉制喜?、網(wǎng)絡(luò)握手本身也要消耗資源。重試策略也很關(guān)鍵。分片上傳失敗的原因很多網(wǎng)絡(luò)抖動、服務(wù)端臨時不可用、請求超時。一個健壯的重試機(jī)制應(yīng)該采用指數(shù)退避第一次失敗后等1秒第二次等2秒第三次等4秒最多重試五次。這里有兩個容易忽略的細(xì)節(jié)一是重試必須攜帶相同的分片序號和服務(wù)端給出的上傳任務(wù)ID否則重試會變成新增分片合并時數(shù)據(jù)就亂了二是前端斷開網(wǎng)絡(luò)后頁面即使刷新也要能通過本地記錄的任務(wù)狀態(tài)繼續(xù)上傳剩余分片實(shí)現(xiàn)真正的斷點(diǎn)續(xù)傳。有些控件只做了內(nèi)存級的斷點(diǎn)刷新就失效這種不算真正的續(xù)傳。3.3 服務(wù)端接收與合并的設(shè)計(jì)重點(diǎn)服務(wù)端的設(shè)計(jì)容易被低估。很多人在前端花了大量時間后端只給個簡單的接收接口就上線結(jié)果生產(chǎn)環(huán)境一跑問題全在后端。第一個重點(diǎn)是臨時目錄的管理。分片文件不應(yīng)該直接寫業(yè)務(wù)存儲區(qū)而是先落在臨時目錄。臨時目錄要有命名規(guī)范和生命周期同一個上傳任務(wù)的所有分片放同一個子目錄。還要有一個守護(hù)任務(wù)定期清理超時未合并的臨時分片。我早期沒做清理某次批量上傳任務(wù)失敗后幾萬個分片留在臨時磁盤上差點(diǎn)把存儲空間打滿。清理策略要考慮正在上傳中的任務(wù)不能誤刪建議用上傳任務(wù)創(chuàng)建時間和活動時間共同判定而不是只看任務(wù)創(chuàng)建時間。第二個重點(diǎn)是合并方式。合并時要求按分片序號嚴(yán)格排序用流式讀寫逐片寫入目標(biāo)文件而不是一次性把所有分片讀入內(nèi)存。假設(shè)一個4GB的文件分成800個5MB分片如果全部讀入內(nèi)存再合并內(nèi)存開銷是災(zāi)難性的。正確做法是每讀一片寫一片邊讀邊寫這樣內(nèi)存占用始終很小。合并完成后還要做完整性校驗(yàn)。前端在創(chuàng)建任務(wù)時可以傳一個文件哈希值后端合并后重新計(jì)算一遍哈希不一致就返回錯誤由前端決定是否重新上傳。這一步是銀行場景必須有的不能省因?yàn)槲募趥鬏?、斷點(diǎn)續(xù)傳過程中任何一步出錯都可能產(chǎn)生一個“能打開但內(nèi)容錯誤”的文件這種錯誤比完全失敗更隱蔽更危險。第三個重點(diǎn)是防濫用。銀行系統(tǒng)的上傳接口要防止被惡意請求刷爆。常見措施包括限制單次請求上傳分片的大小、限制單個上傳任務(wù)的總大小、對同一客戶端的上傳頻率做限流。另外上傳接口必須走統(tǒng)一認(rèn)證體系不能把臨時目錄路徑暴露給前端避免用戶通過構(gòu)造請求非法訪問他人未合并的分片。這些雖然是安全基線但不少開源控件的示例里默認(rèn)都沒做接入時一定要加上。3.4 UI交互和安全審計(jì)的落地細(xì)節(jié)傳輸層的方案對齊后UI交互也不能忽視。銀行柜員每天要傳大量文件交互不好會直接拖累業(yè)務(wù)效率。一個合格的上傳控件至少要有進(jìn)度條、批量上傳、拖拽上傳、失敗提示和重試入口。進(jìn)度條要精確到百分比如果前端能做到按分片粒度計(jì)算百分比的精度就會很高不會出現(xiàn)“卡在99%不動”的情況?？?9%的常見原因是最后一片沒傳完但前端已經(jīng)顯示所有分片完成這種隱藏問題在驗(yàn)收時很難發(fā)現(xiàn)一定要用大文件實(shí)測。秒傳功能在銀行場景里很實(shí)用。同一客戶上傳同樣的身份證影印件如果系統(tǒng)已經(jīng)存在完全相同內(nèi)容的文件就沒必要重新傳一遍。實(shí)現(xiàn)秒傳的關(guān)鍵是文件哈希比對在創(chuàng)建上傳任務(wù)時先計(jì)算文件哈希去服務(wù)器查詢是否已存在。這個功能能極大減少重復(fù)傳輸尤其適合批量掃描件的重復(fù)提交場景。但從合規(guī)角度要小心哈希比對本身不泄露文件內(nèi)容可用于去重不過要明確文件內(nèi)容相同不等于業(yè)務(wù)權(quán)限可復(fù)用是否允許復(fù)用由業(yè)務(wù)規(guī)則決定。安全審計(jì)方面銀行對上傳動作有明確要求。每次上傳事件要記錄操作人、操作時間、文件名、文件大小、任務(wù)結(jié)果、失敗原因日志要防篡改并留存足夠長時間。如果控件支持回調(diào)可以讓前端上傳成功后自動觸發(fā)審計(jì)日志記錄而不是依賴后端日志拼湊。傳輸過程是否加密要看業(yè)務(wù)分類敏感數(shù)據(jù)必須在傳輸層啟用加密協(xié)議同時文件落盤后還要加密存儲。選型時要確認(rèn)控件支持自定義請求頭過濾器方便接入統(tǒng)一加密和審計(jì)組件避免上線時再打補(bǔ)丁。4. 常見問題與排查技巧實(shí)錄4.1 四個高頻故障的排查過程第一個高頻問題是“上傳到一半突然失敗刷新頁面后進(jìn)度丟失”。這種問題十有八九是前端沒有做持久化的任務(wù)狀態(tài)。排查時先看本地存儲里有沒有記錄任務(wù)ID和已完成分片數(shù)如果沒有說明控件沒有真正實(shí)現(xiàn)刷新續(xù)傳。如果是自己二次開發(fā)的要檢查斷點(diǎn)信息寫入的時機(jī)是在分片成功回調(diào)里同步寫入還是等整個任務(wù)完成后一次性寫入。第二個高頻問題是“并發(fā)高了以后服務(wù)端頻繁報(bào)錯”。通常不是上傳接口本身的問題而是后端臨時目錄寫入沖突或連接數(shù)超限。排查時先看錯誤日志如果集中在分片保存失敗或連接池滿就要回到并行度設(shè)置上看是否超過后端承受能力。這種情況建議把并發(fā)數(shù)調(diào)低比持續(xù)報(bào)錯再重試更劃算。第三個高頻問題是“弱網(wǎng)環(huán)境下小文件反而比大文件更容易失敗”。原因是小文件通常走普通表單上傳而不是分片上傳弱網(wǎng)上更容易觸發(fā)網(wǎng)關(guān)超時。解決方法是設(shè)置文件大小閾值超過閾值的文件走分片上傳小于閾值的也要走帶超時配置的普通上傳不要單純依賴控件默認(rèn)行為。我習(xí)慣把閾值設(shè)為2MB這個值可以根據(jù)業(yè)務(wù)實(shí)際調(diào)整。第四個高頻問題是“多節(jié)點(diǎn)部署后分片合并失敗或者文件內(nèi)容殘缺”。這是典型的臨時目錄不共享問題。兩個節(jié)點(diǎn)同時接收同一個任務(wù)的分片分片A存到了節(jié)點(diǎn)一的臨時目錄分片B存到了節(jié)點(diǎn)二合并請求被負(fù)載均衡轉(zhuǎn)發(fā)到節(jié)點(diǎn)二節(jié)點(diǎn)二找不齊分片合并必然失敗。解決辦法是讓所有節(jié)點(diǎn)共享一個網(wǎng)絡(luò)存儲目錄來放臨時分片或者把分片寫入對象存儲保證任何節(jié)點(diǎn)都能訪問同一份數(shù)據(jù)。也可以通過負(fù)載均衡會話保持讓同一個上傳任務(wù)的請求固定到一個節(jié)點(diǎn)但這種方案容錯性差節(jié)點(diǎn)一旦重啟任務(wù)就斷了不建議。4.2 性能調(diào)優(yōu)的實(shí)測方法論做完故障排查再分享一套性能調(diào)優(yōu)的實(shí)測方法論。換控件或者調(diào)參數(shù)之前先建一個和業(yè)務(wù)環(huán)境一致的測試環(huán)境包括同樣的服務(wù)器配置、同樣的網(wǎng)絡(luò)帶寬、同樣的客戶端機(jī)器。然后準(zhǔn)備一組測試文件建議覆蓋小文件、中等文件、大文件、超大文件分別跑一遍基線測試?；€測試要記錄三個數(shù)據(jù)平均傳輸速度、失敗率、服務(wù)端峰值內(nèi)存。參數(shù)調(diào)整時每次只改一個變量例如先固定并發(fā)數(shù)分片大小從1MB一路試到16MB記錄不同分片下的傳輸速度和失敗率再固定最優(yōu)分片大小并發(fā)數(shù)從1試到10。最后畫一張簡單的對比表大概率能看出來最佳區(qū)間。我在一個真實(shí)項(xiàng)目里遇到過這種情況默認(rèn)參數(shù)下用戶從遠(yuǎn)程網(wǎng)點(diǎn)上傳一個800MB的視頻素材平均速度只有8Mbps失敗率20%。我把分片從5MB改成2MB并發(fā)從8降到4結(jié)果平均速度提升到15Mbps失敗率接近于零。原因就是現(xiàn)場網(wǎng)絡(luò)抖動大大分片一旦失敗重傳代價太高并發(fā)太高又加劇擁塞。這類問題不改業(yè)務(wù)代碼只改參數(shù)就能解決前提是你得做實(shí)測。另一條重要經(jīng)驗(yàn)是對銀行系統(tǒng)不要只看平均值還要看P95和P99耗時。因?yàn)樯蟼魇敲嫦蛴脩舻牟僮髯畲蟮耐袋c(diǎn)不是平均速度慢而是個別請求長時間卡住。如果把P99控制在用戶可接受的范圍內(nèi)即使平均值不是最優(yōu)整體的用戶滿意度也會提升。4.3 容易被忽略的隱藏坑最后列幾個我在文檔里基本沒見過的坑個個都是實(shí)戰(zhàn)踩出來的。第一臨時目錄清理任務(wù)的時間設(shè)置。如果你在凌晨跑批前做清理恰好有業(yè)務(wù)在凌晨傳輸大文件清理任務(wù)可能會把正在活躍的任務(wù)分片誤刪。解決方法是把“最后活動時間”作為清理依據(jù)而不是“創(chuàng)建時間”。一個分片只要在最近30分鐘內(nèi)有活動就不能清理。第二容器環(huán)境下的臨時存儲。如果服務(wù)端跑在容器里臨時目錄要掛到持久化存儲卷上。否則容器重啟所有未合并的分片全部丟失前端已經(jīng)顯示上傳完成用戶只能重傳。這個問題的隱蔽之處在于它不是必然發(fā)生只在容器滾動更新時概率出現(xiàn)。第三瀏覽器兼容性降級?，F(xiàn)在主流瀏覽器對分片切割和并發(fā)上傳支持都不錯但銀行網(wǎng)點(diǎn)偶爾還能碰到老版本瀏覽器。如果控件不做降級老瀏覽器可能直接不支持分片API連上傳入口都打不開。選型時要把目標(biāo)瀏覽器清單列給廠商現(xiàn)場驗(yàn)收時安排老舊終端跑一遍。第四代理和網(wǎng)關(guān)的超時機(jī)制。不少銀行內(nèi)網(wǎng)有代理網(wǎng)關(guān)默認(rèn)空閑超時可能是60秒或120秒。如果分片上傳請求在網(wǎng)關(guān)層被判定為空閑連接而中斷前端無論如何重試都是白搭。排查技巧是看用戶上傳失敗的時間點(diǎn)是否穩(wěn)定在一個固定值附近把抓包工具接到服務(wù)器端確認(rèn)請求是否到達(dá)應(yīng)用服務(wù)器如果到達(dá)且沒有超時記錄再回頭查網(wǎng)關(guān)配置。關(guān)于服務(wù)端合并時的哈希校驗(yàn)順序我再補(bǔ)一句。最好在合并過程中就同步計(jì)算哈希不要合并完成后再單獨(dú)讀一遍文件算。文件越大第二遍讀取的時間成本越高合并過程同步計(jì)算哈希能省出接近一倍的IO時間。這套東西我前前后后在不同項(xiàng)目里驗(yàn)證過三輪最深的體會是選上傳控件不能光看墻上貼的測試數(shù)據(jù)一定要在自己的網(wǎng)絡(luò)環(huán)境里跑真實(shí)業(yè)務(wù)文件。供應(yīng)商給的演示環(huán)境永遠(yuǎn)是理想網(wǎng)絡(luò)生產(chǎn)環(huán)境的復(fù)雜程度遠(yuǎn)超想象。另外無論最終選了哪家都要保留好替換的接口設(shè)計(jì)不要把業(yè)務(wù)代碼和某個具體控件的API焊死。我在一次組件升級中就是因?yàn)榈讓訌姆桨窤切換成方案B業(yè)務(wù)代碼幾乎沒動只改了適配層整個切換耗時不到一天。這一點(diǎn)比控件本身多一兩個花哨功能有價值得多。如果你正在頭疼選型建議先從列需求清單開始把八個問題答完再看任何一份產(chǎn)品資料能少走一半彎路。