一、業(yè)務背景

最近遇到這樣一個場景：在業(yè)務正式開始前1-2天，需要導入一批來自合作渠道的數(shù)據(jù)，在業(yè)務周期結束后，再將同一批數(shù)據(jù)導出，交付給渠道方；

簡單理解，就是數(shù)據(jù)的「導入」和「導出」；

但是場景復雜度的高低與否，與實現(xiàn)流程和邏輯的復雜度并無什么必然聯(lián)系，數(shù)據(jù)在「導入」和「導出」之間，通常還會橫著復雜的「業(yè)務邏輯」；

數(shù)據(jù)如果只是在文件和單表直接來回搗騰，解決的方案簡直花里胡哨，然而在應用中數(shù)據(jù)導入導出，更多還是要集成業(yè)務需求，自然也就繞不開業(yè)務的處理邏輯；

二、場景分析

1、文件特征

文件：「Excel」類型，并且表頭是固定格式，字段內(nèi)容雖然有要求，但是難免存在細微的誤差問題；

內(nèi)容：條數(shù)「1000」以內(nèi)，單條數(shù)據(jù)「150+」個字段，業(yè)務結束后導出，會添加業(yè)務結果和明細相關字段，最終在「200」個字段左右；

2、業(yè)務特征

文件導入后，數(shù)據(jù)在業(yè)務之間流轉時，需要構建相應的主體結構，比如基礎的「客戶檔案」，「業(yè)務檔案」，業(yè)務處理過程中會生成「明細」，處理完成后會生成「結果」；

3、數(shù)據(jù)規(guī)則

【客戶檔案】

數(shù)據(jù)在入庫的過程中，需要校驗「客戶歸屬」問題，庫內(nèi)已有的客戶基于「跟進時間」執(zhí)行「更新邏輯」，庫內(nèi)沒有的客戶需要「新增」并「分配跟進人員」；

【業(yè)務檔案】

跟隨「客戶檔案」的邏輯，如果客戶更新，則「業(yè)務檔案」更新，如果客戶不更新，則「業(yè)務檔案」不更新，如果客戶新增，則「業(yè)務檔案」直接新增即可；

【數(shù)據(jù)校驗】

客戶的「基礎檔案」和「業(yè)務檔案」的入庫邏輯，完全遵守產(chǎn)品體系現(xiàn)有的限制規(guī)則，在邏輯攔截時盡量輸出全面的攔截原因，方便商務人員對文件數(shù)據(jù)進行修改調(diào)整；

三、流程設計

1、業(yè)務流程

業(yè)務流程從整體上可以拆分四段來看：動作確認、動作監(jiān)聽、數(shù)據(jù)處理、業(yè)務處理；

【動作確認】

• 「導入」應用前端完成文件上傳OSS的處理，向應用后端提交數(shù)據(jù)導入的請求，接收請求后會異步處理；
• 「異常記錄下載」會實時響應，功能上看就是一個單表導出，需要返回業(yè)務攔截和異常信息；
• 「導出」因為交付時間不確定性，所以由商務人員手動觸發(fā)導出，后端組裝完成后提交OSS文件服務器，等待下載；

【動作監(jiān)聽】

• 「導入」和「導出」的動作監(jiān)聽，進而觸發(fā)相應的流程邏輯；

【數(shù)據(jù)處理】

• 「客戶檔案」提交給客戶服務處理，如果處理失敗，無法圍繞客戶構建業(yè)務流，直接中斷全部流程；
• 「業(yè)務檔案」提交給業(yè)務服務處理，這里指業(yè)務屬性的資料信息，并非場景流程；

【業(yè)務處理】

• 「數(shù)據(jù)導入」的真正目的，依賴系統(tǒng)的處理能力，從而實現(xiàn)相應的業(yè)務流程，在過程中會生成關鍵明細和結果數(shù)據(jù)；

2、導入流程

• 【1】應用后端接收用戶提交的「導入」請求，動作接收成功后立即響應；
• 【2】完成「導入」記錄的存儲之后，通過MQ消息隊列，解耦文件數(shù)據(jù)的處理流程；
• 【3】對文件進行解析，讀取源數(shù)據(jù)并存儲到明細表；
• 【4】遍歷明細數(shù)據(jù)分別實現(xiàn)「客戶」和「業(yè)務」的檔案存儲，此處會把失敗原因最大限度回寫到明細記錄中，方便商務二次導入；
• 【5】完成數(shù)據(jù)入庫后，更新「導入」動作的狀態(tài)，最核心的是提供失敗記錄的明細和下載功能；

3、導出流程

• 【1】應用后端接收用戶提交的「導出」請求，動作接收成功后立即響應，初始狀態(tài)為：「處理中」；
• 【2】完成「導出」記錄的存儲之后，通過MQ消息隊列，解耦文件的「創(chuàng)建」和「上傳」流程；
• 【3】文件數(shù)據(jù)分為兩部分，文件原內(nèi)容和業(yè)務處理結果，組裝為新的數(shù)據(jù)結構；
• 【4】創(chuàng)建新的文件，涉及數(shù)據(jù)表頭的合并，數(shù)據(jù)內(nèi)容的合并，以及「Excel」的格式構建，從而完成文件的生成過程；
• 【5】將生成的文件上傳到文件服務器，由商務人員自行下載并導出，然后交付給渠道方；

四、結構設計

數(shù)據(jù)導入的表結構，是由具體業(yè)務場景決定的，此處就不做展示了；這里只看一看導入導出的調(diào)度表結構，即操作記錄和狀態(tài)以及數(shù)據(jù)明細的存儲；

【動作記錄】

存儲「導入」和「導出」的請求記錄，都涉及文件信息的管理，至于「業(yè)務ID」和「批次ID」是指集成業(yè)務的處理流程，同時也可以基于該「ID」限制同批次下的重復動作，降低不必要的資源占用；

【數(shù)據(jù)明細】

在「導入」的時候，對文件數(shù)據(jù)的臨時記錄表，方便對數(shù)據(jù)的多次讀取和處理，避免流程中斷導致文件的重復解析；

在「導出」的時候，需要依賴原數(shù)據(jù)的構建新的「Excel」文件，在交付渠道方時保證原內(nèi)容的不變，只新增系統(tǒng)中業(yè)務的處理明細和結果；

五、實踐總結

雖然對于「Excel」或者其他文件的「導入」和「導出」的參考案例很多；

但是在研發(fā)實踐中，這依舊是一個不容易實現(xiàn)的過程，在數(shù)據(jù)和文件互相搬運的過程中，如何與「業(yè)務場景」進行平穩(wěn)的集成，才是真正的復雜邏輯；

從開始工作直到現(xiàn)在，關于「導入」和「導出」的實現(xiàn)方案參考或者落地過很多個，整體可以從兩個方向考慮；

【應用系統(tǒng)】

通常文件格式是「Excel」、「Word」、「Pdf」等，并且涉及的數(shù)據(jù)體量并不大，采取「異步」的方式解耦即可；

對于文件的「導入」來說，需要重點考慮的邏輯，在于如何與業(yè)務平穩(wěn)集成，在出現(xiàn)問題時，能夠給產(chǎn)品頁面準確的信息反饋，從而提高文件的二次處理效率；

對于數(shù)據(jù)的「導出」來說，是一個「高危」的操作，通常是不分配大量數(shù)據(jù)的導出「權限」，如果有需求則要對數(shù)據(jù)進行計算分「批次」導出；

【數(shù)據(jù)系統(tǒng)】

數(shù)據(jù)體量較大的情況下，不推薦從應用系統(tǒng)考慮「優(yōu)化」的策略；

如何確定「數(shù)據(jù)體量較大」的臨界值，需要測試系統(tǒng)的處理能力，系統(tǒng)業(yè)務流量高峰時，去「并發(fā)」執(zhí)行導入和導出，從而得出合理的數(shù)值，不過大部分產(chǎn)品都是限制單文件最大「5000」條；

從分布式架構中組裝大量的數(shù)據(jù)并「導出」文件，其資源占用過高，并非主流的實踐方案；

當下比較常見的方式，直接從「數(shù)據(jù)層面」入手，搭建「傳輸」或「轉換」的通道，以「API」或者「頁面入口」的方式，觸發(fā)流程即可；

在數(shù)據(jù)體量超過應用系統(tǒng)的處理能力時，會搭建專用的「數(shù)據(jù)傳輸通道」來處理；

這種模式在數(shù)據(jù)型業(yè)務中很常用，可以隔離大量數(shù)據(jù)的「IO流」操作，確保應用系統(tǒng)運行的安全穩(wěn)定，也可以極大提升數(shù)據(jù)和文件互相搬運的處理效率；