文件服務(wù)器系統(tǒng)遷移改造之路

1

前言文件服務(wù)器系統(tǒng)以FTP服務(wù)為基礎(chǔ)，為民生銀行兩百多套應(yīng)用系統(tǒng)提供臨時文件傳輸服務(wù)功能。自投入生產(chǎn)使用以來，老文件服務(wù)器系統(tǒng)已經(jīng)連續(xù)服役運(yùn)行超過了十年。全行兩百多套應(yīng)用系統(tǒng)的聯(lián)機(jī)和批量文件交互場景強(qiáng)依賴文件服務(wù)器系統(tǒng)，每天有幾百萬次文件的上傳、下載傳輸請求。老文件服務(wù)器系統(tǒng)的架構(gòu)比較傳統(tǒng)陳舊，高可用采用HPUNIX的HA主備集群模式，無論是系統(tǒng)的負(fù)載能力，還是快速恢復(fù)業(yè)務(wù)已經(jīng)很難滿足需求。文件服務(wù)器系統(tǒng)的遷移改造急需完成，自遷移改造項(xiàng)目啟動到完成歷時兩年的時間，期間經(jīng)歷了遷移方案的更換，也遇到了各種復(fù)雜的技術(shù)難題，最終在主動性維護(hù)窗口之內(nèi)順利完成新老服務(wù)器的遷移切換。本文主要介紹民生銀行的文件服務(wù)器系統(tǒng)遷移改造的過程和方案，適合架構(gòu)規(guī)劃師、系統(tǒng)管理員、技術(shù)開發(fā)人員等閱讀。文中重點(diǎn)介紹大的思路和方向，您可以再深入研究技術(shù)細(xì)節(jié)，相信您會更加熟悉文件服務(wù)器系統(tǒng)。

2

文件服務(wù)器系統(tǒng)的業(yè)務(wù)功能應(yīng)用系統(tǒng)在文件服務(wù)器系統(tǒng)上都有對應(yīng)的FTP用戶名和組，且通常以系統(tǒng)的小寫英文名命名。文件服務(wù)器系統(tǒng)為應(yīng)用系統(tǒng)提供公共的FTP目錄，存放臨時文件用于數(shù)據(jù)交互。數(shù)據(jù)文件的交互形式主要有兩種：1）系統(tǒng)間交互，即FTP目錄上的文件，如系統(tǒng)A將文件放在FTP目錄下等待系統(tǒng)B處理，系統(tǒng)B處理完成后將結(jié)果文件放回FTP目錄待系統(tǒng)A取回。2）公共文件共享，即FTP目錄上的文件共享給多個系統(tǒng)使用，如系統(tǒng)A將公共文件放在FTP目錄給系統(tǒng)B、C、D等訪問。這樣一個簡單又“免費(fèi)”的FTP功能，在系統(tǒng)之間實(shí)現(xiàn)業(yè)務(wù)功能的時候，從幾KB到幾百GB的文件都可以安全的交互使用，便捷的服務(wù)性價比非常高。業(yè)務(wù)場景根據(jù)業(yè)務(wù)需求種類繁多，小到個人客戶的某個賬戶交易明細(xì)聯(lián)機(jī)查詢，大到企業(yè)客戶的代發(fā)工資文件批量處理，以及銀行系統(tǒng)各種貸款批扣、理財(cái)申購、對賬處理等日終作業(yè)的處理等。FTP目錄下的文件在不同系統(tǒng)之間流轉(zhuǎn)加工，既要有快速的實(shí)時響應(yīng)速度，又要確保文件內(nèi)容的完整性。

3

文件服務(wù)器系統(tǒng)老環(huán)境的困境文件服務(wù)器系統(tǒng)上的文件大規(guī)模嵌入到業(yè)務(wù)流程中，這對文件服務(wù)器系統(tǒng)的服務(wù)能力提出了很高的要求。幾千臺應(yīng)用服務(wù)器日均幾百萬次的文件傳輸請求，文件服務(wù)器系統(tǒng)7*24小時不間斷對外服務(wù)，大量的FTP連接和傳輸請求與底層的基礎(chǔ)環(huán)境和網(wǎng)絡(luò)穩(wěn)定性又有著密切依賴，任何環(huán)節(jié)出現(xiàn)異常，都會影響正常的業(yè)務(wù)。傳統(tǒng)的HA主備集群架構(gòu)無法橫向擴(kuò)展，集群出現(xiàn)異常的切換時間是分鐘級別，如果切換導(dǎo)致文件異常對銀行業(yè)務(wù)的影響范圍不可估量。為了支撐未來文件交互的業(yè)務(wù)增長，以及UNIX小型機(jī)下移到Linux開放平臺，文件服務(wù)器系統(tǒng)的遷移改造正式啟動。圖1是文件服務(wù)器系統(tǒng)老環(huán)境的部署示意圖：圖1文件服務(wù)器系統(tǒng)老環(huán)境

4

遷移改造的挑戰(zhàn)整體的遷移改造整體思路是將當(dāng)前的主備HA集群架構(gòu)改造成DNS+F5+GPFS集群架構(gòu)，服務(wù)器由4臺HPUNIX更換成5臺SuseLinux服務(wù)器，其中2臺是同城災(zāi)備服務(wù)器，實(shí)際對外服務(wù)的服務(wù)器由1臺變成了3臺。老文件服務(wù)器系統(tǒng)上默認(rèn)保留了7天之內(nèi)的文件，需要將這些存量數(shù)據(jù)文件同步遷移到新文件服務(wù)器系統(tǒng)上。遷移改造主要面臨三方面的挑戰(zhàn)：1）技術(shù)方面：新老環(huán)境是兩套完全不同的環(huán)境，操作系統(tǒng)由UNIX更換成Linux，文件系統(tǒng)由單機(jī)更換成GPFS共享文件系統(tǒng)，HA主備更換成F5負(fù)載均衡集群，F(xiàn)TP功能由UNIX更換成Linux平臺的vsftpd。2）應(yīng)用方面：兩百多套應(yīng)用系統(tǒng)在老服務(wù)器上存放了約1000萬個總共1.5T大小的歷史文件，120萬個文件子目錄，所有的用戶名密碼、文件目錄結(jié)構(gòu)權(quán)限、歷史文件等全部需要遷移到新服務(wù)器上。3）業(yè)務(wù)方面：應(yīng)用系統(tǒng)需要提前將通過浮動IP訪問修改成通過域名訪問文件服務(wù)器系統(tǒng)，這樣新老環(huán)境只需要更換域名下的IP地址就幾乎不影響應(yīng)用系統(tǒng)的正常運(yùn)行。另外，新老環(huán)境遷移歷史文件需要離線停機(jī)窗口，但是停機(jī)窗口的時間又受限于銀行系統(tǒng)的日終批量任務(wù)。

5

遷移改造的四個階段文件服務(wù)器系統(tǒng)作為基礎(chǔ)服務(wù)平臺，在做遷移改造計(jì)劃的時候，原則上是不影響應(yīng)用系統(tǒng)的正常業(yè)務(wù)。整改的遷移改造計(jì)劃分成了四大階段：第一階段：測試環(huán)境域名改造，入訪的應(yīng)用系統(tǒng)安裝DNS解析域名工具，將應(yīng)用配置由IP訪問修改成域名訪問。第二階段：生產(chǎn)環(huán)境域名改造，入訪的應(yīng)用系統(tǒng)安裝DNS域名解析工具，按照從低到高的系統(tǒng)優(yōu)先，將入訪的應(yīng)用系統(tǒng)由IP訪問修改成域名訪問。第三階段：測試環(huán)境新老服務(wù)器遷移，由HPUNIX更改成Linux操作系統(tǒng)的服務(wù)器，同時將歷史文件遷移到新服務(wù)器，將域名下掛的F5member指向新服務(wù)器。測試環(huán)境的應(yīng)用系統(tǒng)切換之后，驗(yàn)證各種使用FTP服務(wù)的場景。第四階段：生產(chǎn)環(huán)境新老服務(wù)器遷移，由HPUNIX更換成Linux操作系統(tǒng)的服務(wù)器，操作步驟與測試環(huán)境相同，但是只能在有限的維護(hù)窗口之內(nèi)實(shí)施。其中，第一、二階段涉及到兩百多套系統(tǒng)的幾千臺應(yīng)用服務(wù)器修改配置，分成多個批次在變更窗口實(shí)施，時間跨度超過一年，期間遇到了各種應(yīng)用配置修改的問題，在此不再描述。下面三張示意圖展示了生產(chǎn)環(huán)境的不同階段，最終新環(huán)境的服務(wù)器代替老環(huán)境的服務(wù)器對外提供服務(wù)。圖2文件服務(wù)器系統(tǒng)遷移前圖3新老環(huán)境并行過渡期圖4文件服務(wù)器系統(tǒng)新環(huán)境

6

數(shù)據(jù)文件的遷移方案6.1方案選擇測試遷移改造第三、四階段最關(guān)鍵的環(huán)節(jié)，是關(guān)于歷史數(shù)據(jù)文件的遷移同步，根據(jù)現(xiàn)有的技術(shù)，制定了下表中的四種方案：模擬生產(chǎn)環(huán)境，分別測試了四種方案的可行性，首先否定了NBU備份恢復(fù)和SRDF數(shù)據(jù)復(fù)制的方案。針對shell遷移腳本和rsync也在驗(yàn)證環(huán)境分別測試了遷移功能和效率，詳細(xì)的記錄如下表：圖5通過FTP日志文件重建拷貝文件圖6rsync命令同步復(fù)制目錄和文件關(guān)于自主設(shè)計(jì)的shell遷移腳本和rsync命令工具都能夠滿足我們的遷移需求，但是仍然存在一定的風(fēng)險和難度，下面簡單介紹一下兩種方案的思路。6.2方案對比整合1）Shell遷移腳本：通過NFS技術(shù)將老環(huán)境的文件系統(tǒng)共享掛載到新環(huán)境服務(wù)器上，根據(jù)FTP日志文件，過濾出每個上傳文件的記錄，然后提取出文件名、目錄、用戶名等信息，格式化生成需要遷移的文件列表和目錄列表。通過shell腳本提取目錄列表，通過操作系統(tǒng)的mkdir、chmod、chown命令在新環(huán)境重建目錄，再根據(jù)文件列表并發(fā)批量拷貝（cp）到新環(huán)境。2）Rsync命令工具：Rsync是操作系統(tǒng)自帶的一個快速、多功能的遠(yuǎn)程和本地文件拷貝工具，通過遞歸方式傳輸文件并保持所有文件的屬性，可以支持全量和增量的同步方式。通過NFS技術(shù)將老環(huán)境的文件系統(tǒng)共享掛載到新環(huán)境服務(wù)器上，以目錄為最小單位，將目錄下所有的子目錄和文件全部同步拷貝到新環(huán)境服務(wù)器上。rsync命令簡潔明了，除了-av還有幾十個參數(shù)選項(xiàng)，可以跨平臺將目錄old_file下所有的數(shù)據(jù)全部同步拷貝到目錄new_file下。兩種遷移方案的對比：通過對兩種方案的對比測試，發(fā)現(xiàn)兩種方案各有利弊，shell遷移腳本是效率高，但是依賴FTP日志文件并且邏輯處理復(fù)雜；rsync命令性能差，但是數(shù)據(jù)一致性有保證。生產(chǎn)環(huán)境上應(yīng)用系統(tǒng)對文件的處理有操作類型可能有特殊操作，比如重命名文件、更新文件內(nèi)容、主動刪除文件等未記錄到FTP日志文件中。為了兼顧遷移性能和數(shù)據(jù)一致性，最終決定將兩種遷移方案結(jié)合在一起。主要是將shell遷移腳本中重建目錄和拷貝文件的邏輯簡化成通過rsync命令來實(shí)現(xiàn)。文件服務(wù)器系統(tǒng)上兩百多套應(yīng)用系統(tǒng)共分配了480個用戶和目錄，計(jì)劃將這480個目錄分成10組，每組單獨(dú)設(shè)計(jì)shell遷移腳本，10個并發(fā)恰好能夠?qū)⒎?wù)器資源利用率最大化。

7

新老環(huán)境遷移切換7.1遷移切換的過程新老環(huán)境的數(shù)據(jù)遷移切換其實(shí)在停機(jī)維護(hù)窗口前的T-30日已經(jīng)開始準(zhǔn)備了，但是在生產(chǎn)上提前遷移的時候發(fā)現(xiàn)遷移時間仍然超過10個小時，瓶頸是rsync命令在執(zhí)行的過程中會先去遞歸掃描目錄下面所有的目錄和文件信息。當(dāng)單個目錄下小文件數(shù)量超過100萬個，或者單個目錄下的嵌套子目錄數(shù)量超過1萬個的時候，再疊加生產(chǎn)環(huán)境的文件頻繁更新，遷移的性能急劇下降。必須在正式遷移切換之前解決性能問題，否則遷移任務(wù)將無法完成。這些問題目錄涉及了多套使用文件服務(wù)器系統(tǒng)存放文件的應(yīng)用系統(tǒng)，只能將這些有問題的目錄列舉出來，逐個去梳理目錄的業(yè)務(wù)場景、清理策略、文件和子目錄用途等。在得到每個應(yīng)用系統(tǒng)負(fù)責(zé)人的確認(rèn)后，清理了約800萬個歷史文件，總?cè)萘考s500G，刪除了約90萬個嵌套子目錄。這個過程是冒著很高生產(chǎn)操作風(fēng)險，每一次刪除命令都不允許出錯！但是，當(dāng)將問題目錄全部處理完成之后，效果也出現(xiàn)了，在線遷移數(shù)據(jù)只需要1個小時，最終在維護(hù)窗口離線遷移數(shù)據(jù)時只花了30分鐘。而且，因?yàn)榻?jīng)過“瘦身”之后的系統(tǒng)，也有足夠的時間對遷移狀態(tài)做全量檢查，新老環(huán)境的文件和目錄遷移之后完全一致。除了遷移數(shù)據(jù)文件之外，新老環(huán)境服務(wù)器上是完全不同的操作系統(tǒng)，F(xiàn)TP服務(wù)的底層實(shí)現(xiàn)差異很大，需要將FTPserver端的配置參數(shù)逐一對比修改。主要是從FTP的傳輸模式、權(quán)限控制、用戶控制、連接控制、日志格式等方面考慮，這里不再具體描述，建議系統(tǒng)管理員結(jié)合實(shí)際的應(yīng)用需求去修改/etc/vsftpd.conf里面的配置參數(shù)。7.2遷移切換的效果文件服務(wù)器系統(tǒng)遷移到新環(huán)境之后，由單臺服務(wù)器變成多臺服務(wù)器同時對外服務(wù)，新環(huán)境的架構(gòu)支持橫向擴(kuò)展，變成了真正意義上的多活架構(gòu)。從交易性能監(jiān)控平臺的數(shù)據(jù)（21端口的控制連接）可以看到，文件服務(wù)器系統(tǒng)的白天平均交易響應(yīng)時間由平均約7.9毫秒，下降到了約2毫秒，而且交易高峰時間段的響應(yīng)時間由起伏波動變成了十分平穩(wěn)。圖7老環(huán)境的交易性能數(shù)據(jù)（2021.10.11）圖8新環(huán)境的交易性能數(shù)據(jù)（2021.11.01）

8

生產(chǎn)問題案例文件服務(wù)器系統(tǒng)提供的FTP服務(wù)看似簡單，在應(yīng)用系統(tǒng)調(diào)用時如果沒有考慮異常處理機(jī)制，可能引起交易失敗。本章節(jié)按照FTP服務(wù)異常的分類，簡單分享了個關(guān)于文件服務(wù)器系統(tǒng)的生產(chǎn)案例，供參考學(xué)習(xí)。1）

FTPServer端的端口被占用問題現(xiàn)象：某應(yīng)用系統(tǒng)產(chǎn)品信息發(fā)布后，應(yīng)用本地生成了產(chǎn)品交易狀態(tài)的文件，通過FTP命令上傳到文件服務(wù)器系統(tǒng)后，異步通知渠道系統(tǒng)同步文件。渠道系統(tǒng)下載了文件并入庫，但是入庫后的產(chǎn)品交易狀態(tài)內(nèi)容為空，導(dǎo)致所有的產(chǎn)品狀態(tài)無法在渠道正常展示。原因分析：通過網(wǎng)絡(luò)抓包分析，應(yīng)用系統(tǒng)訪問文件服務(wù)器系統(tǒng)時，是通過“F5VIP地址”映射方式實(shí)現(xiàn)，且F5VIP采用單一SNATIP進(jìn)行轉(zhuǎn)換與后端真實(shí)文件服務(wù)器建立連接。兩次文件傳輸過程中，由于部分客戶端拆連接時為按標(biāo)準(zhǔn)控制指令，進(jìn)行拆連接，導(dǎo)致第1次的數(shù)據(jù)連接未拆鏈完成，F(xiàn)TPServer端占用的臨時隨機(jī)端口不釋放，此時第2次（與第1次的客戶端不同）建立新連接如果也使用相同的端口，導(dǎo)致FTPServer端無法建立數(shù)據(jù)連接。所以第2次傳輸?shù)奈募谖募?wù)器上未正常完成,實(shí)際上是個空文件。解決方案a：應(yīng)用系統(tǒng)連接FTP的方式由被動模式改成主動模式，這樣建立數(shù)據(jù)連接的時候，F(xiàn)TPServer端主動與FTPClient端的隨機(jī)端口建立連接，相對于被動模式，避免FTPServer端連接數(shù)多的情況下，隨機(jī)端口被占用的情況。解決方案b：文件服務(wù)器系統(tǒng)的F5由SNAPIP修改成透傳源IP地址，這樣FTPClient端和Server端之間由映射IP對ServerIP（一對一）變成ClientIP對ServerIP（多對一），避免了FTPServer端隨機(jī)端口被占用的情況。2）

FTPServer端上的連接被reset問題現(xiàn)象：文件服務(wù)器系統(tǒng)在某個時間段，F(xiàn)TPServer端的流量突然下降。當(dāng)時部分應(yīng)用系統(tǒng)正在做日終批量處理，由于批量處理的文件需要在貸款系統(tǒng)、公共支付、銀行核心等多個系統(tǒng)之間加工交互，作業(yè)鏈條被迫中斷，需要人工進(jìn)入干預(yù)。原因分析：文件服務(wù)器系統(tǒng)的FTP服務(wù)是正常狀態(tài)，而且未做任何操作的情況下，流量又恢復(fù)了。但是，操作系統(tǒng)日志顯示文件服務(wù)器系統(tǒng)的服務(wù)器（即member）到上層的F5VIP有大量“l(fā)ostconnection”報錯，應(yīng)用系統(tǒng)Client端到FTPServer端的連接被reset。應(yīng)用系統(tǒng)訪問文件服務(wù)器系統(tǒng)時，F(xiàn)5VIP采用單一SNATIP進(jìn)行轉(zhuǎn)換與后端真實(shí)文件服務(wù)器建立連接，由于部分客戶端拆連接時未按標(biāo)準(zhǔn)控制指令進(jìn)行拆連接，導(dǎo)致F5偶發(fā)性與后端FTPServer連接未能正常拆除，當(dāng)新建連接發(fā)起請求時，采用了與異常拆連接同樣的SNATIP+端口時產(chǎn)生了隨機(jī)端口沖突，F(xiàn)5在端口轉(zhuǎn)換機(jī)制上出現(xiàn)了短時間的異常，對于新建連接進(jìn)行了Reset拆鏈，導(dǎo)致調(diào)用FTP的請求無法正常轉(zhuǎn)發(fā)到FTPMember上。解決方案：文件服務(wù)器系統(tǒng)的F5由SNAPIP修改成透傳源IP地址，降低由于個別客戶端不規(guī)范拆除連接，帶來單一SNATIP地址轉(zhuǎn)換機(jī)制問題，并且文件服務(wù)器由主備HA集群架構(gòu)改造成DNS+F5+GPFS集群架構(gòu)，解決FTPserver端單點(diǎn)的問題，提升文件服務(wù)器FTP整體對外服務(wù)能力。3）

FTPServer端和Client端的文件大小不一致問題現(xiàn)象：某應(yīng)用系統(tǒng)通過FTP命令傳輸數(shù)據(jù)文件和校驗(yàn)文件（filelist）到文件服務(wù)器系統(tǒng)，下游數(shù)據(jù)管理系統(tǒng)（MDS）獲取到數(shù)據(jù)文件和校驗(yàn)文件，但是在通過filelist校驗(yàn)文件時，發(fā)現(xiàn)數(shù)據(jù)文件的實(shí)際大小和filelist里面記錄的大小不匹配，導(dǎo)致MDS下載數(shù)據(jù)文件失敗。原因分析：文件服務(wù)器系統(tǒng)由HPUNIX遷移到SuseLinux平臺后，應(yīng)用客戶端傳輸文件到文件服務(wù)器系統(tǒng)由同平臺變成了跨平臺傳輸，在傳輸文本文件時，系統(tǒng)默認(rèn)選擇文字模式（ASCII）傳輸，導(dǎo)致文件格式和大小發(fā)生變化。解決方案a：應(yīng)用客戶端在傳輸文件的時候，顯示的指定二進(jìn)制模式（BIN），這樣傳輸文本文件的時候，格式和大小就不會發(fā)生改變。解決方案b：在文件服務(wù)器系統(tǒng)的FTP參數(shù)配置文件里面，設(shè)置ascii_upload_enable和ascii_download_enable參數(shù)，官方文檔里面關(guān)于這兩個參數(shù)的解釋是設(shè)置是否啟用ASCII模式上傳下載數(shù)據(jù)，默認(rèn)值為NO。實(shí)際上，根據(jù)測試結(jié)果，當(dāng)將兩個參數(shù)設(shè)置成YES后，應(yīng)用客戶端在傳輸文件的時候，無論以ASCII還是BIN模式傳輸文件，都不改變文件的格式和大小。4）

FTPnlist命令查詢文件慢問題現(xiàn)象：某應(yīng)用系統(tǒng)在文件服務(wù)器系統(tǒng)遷移到新環(huán)境之后，聯(lián)機(jī)交易平均響應(yīng)時間由0.2秒上升到10秒。應(yīng)用日志顯示，交易耗時主要在應(yīng)用系統(tǒng)與FTPServer端之間的交互。原因分析：該應(yīng)用系統(tǒng)聯(lián)機(jī)交易會先查詢（nlist）文件服務(wù)器系統(tǒng)目錄下的文件，判定是否存在。通過網(wǎng)絡(luò)抓包分析，再結(jié)合vsftpd的代碼，Linux平臺的vsftpd和UNIX的ftp功能實(shí)現(xiàn)有差異，vsftpd里nlist不僅會查詢文件，還會對目錄下所有文件概要信息做遍歷，然后通過filter和sort返回結(jié)果到客戶端。當(dāng)目錄下的文件越多，nlist的查詢效率越慢。當(dāng)應(yīng)用系統(tǒng)短時間查詢不到結(jié)果時，嘗試發(fā)起重試，應(yīng)用邏輯處理慢疊加nlist查詢效率慢，最終導(dǎo)致聯(lián)機(jī)交易的整體響應(yīng)時間變長。解決方案a：該目錄下累計(jì)存放了20萬個左右的歷史文件，臨時將不再使用的歷史文件清理掉，nlist的查詢速度恢復(fù)到1秒以內(nèi)。解決方案b：建議應(yīng)用程序在使用nlist的時候，需要結(jié)合應(yīng)用程序進(jìn)行性能壓測，或者通過其它方式判斷文件是否正常上傳，規(guī)避nlist查詢效率慢帶來的影響。5）

FTPClient端下載文件慢問題現(xiàn)象：某應(yīng)用系統(tǒng)日終批量作業(yè)在老環(huán)境上下載機(jī)構(gòu)信息文件時（4MB大?。┖臅r0.1秒，但是在新環(huán)境是下載同樣文件時卻消耗了700秒，導(dǎo)致了批量作業(yè)整體超時失敗。原因分析：通過網(wǎng)絡(luò)抓包分析，客戶端到新環(huán)境的rtt（網(wǎng)絡(luò)時延）比老環(huán)境快了50倍，達(dá)到了0.018毫秒，甚至比javaftp客戶端處理1152字節(jié)數(shù)據(jù)的速度（0.8毫秒）還要快。這導(dǎo)致FTPServer端不斷收到來自Client端的zerowindow，每收到一次，Server端都需要等待200毫秒后才能發(fā)送數(shù)據(jù)。相當(dāng)于每200毫秒才發(fā)送1152字節(jié)的數(shù)據(jù)，這樣發(fā)送4MB的數(shù)據(jù)就需要728秒。圖9TCPWindowFull的網(wǎng)絡(luò)數(shù)據(jù)圖解決方案：發(fā)現(xiàn)問題的應(yīng)用系統(tǒng)使用的是commons-net-3.2.jar包實(shí)現(xiàn)FTP傳輸功能，默認(rèn)未設(shè)置緩存大小，建議設(shè)置成8192或者更大，可以解決該問題。6）

FTPClient端判斷FTP返回碼異常問題現(xiàn)象：某應(yīng)用系統(tǒng)日終批量作業(yè)下載文件服務(wù)器系統(tǒng)上的某個文件，如果該文件不存在，則開始定時輪詢，直到查詢成功后開始下載該文件，輪詢結(jié)束。但是文件服務(wù)器遷移到新環(huán)境后，該日志批量作業(yè)查詢到文件不存在時，直接退出輪詢，導(dǎo)致作業(yè)異常失敗。原因分析：經(jīng)測試，在UNIX平臺上如果文件不存在則返回FTP550的報錯碼，但是，在Linux平臺上如果文件不存在，在查詢的時候直接返回空信息（FTP返回碼226），應(yīng)用程序FtpUtil.java無法判斷返回碼226的狀態(tài)，則跳出定時輪詢，導(dǎo)致下載文件失敗。解決方案：應(yīng)用程序?qū)τ谖募欠翊嬖诘呐袛?，需要兼容考慮不同平臺的返回碼，或者增加對文件數(shù)量的判斷邏輯，否則會影響正常的業(yè)務(wù)邏輯判斷。7）

FTPClient端未響應(yīng)Server端的SYN請求問題現(xiàn)象：某應(yīng)用系統(tǒng)通過FTP命令登錄FTPServer，但是在下載數(shù)據(jù)文件的時候失敗，導(dǎo)致后續(xù)的交易場景未正常執(zhí)行完成。原因分析：通過網(wǎng)絡(luò)抓包分析，該Client端已經(jīng)建立控制連接，在開始傳輸數(shù)據(jù)之前（主動模式），Server端到Client端需要建立數(shù)據(jù)連接，但是Server端連續(xù)發(fā)了3次SYN請求，Client端都未正常響應(yīng)，報錯“Failedtoestablishconnection”，最終數(shù)據(jù)傳輸失敗。（細(xì)心讀者應(yīng)該發(fā)現(xiàn)7個問題案例中，有4次是“通過網(wǎng)絡(luò)抓包”，分析了FTP交互數(shù)據(jù)過程中的每一步操作，才最終找到問題原因。）圖10FTPServer端連續(xù)3次SYN請求解決方案：某應(yīng)用系統(tǒng)在某個時間段業(yè)務(wù)繁忙，F(xiàn)TPClient端無法正常響應(yīng)Server端的數(shù)據(jù)連接請求，在不調(diào)整業(yè)務(wù)的情況下，臨時將傳輸文件的模式由主動模式調(diào)整成被動模式（跟第1個問題案例的模式相反），這樣數(shù)據(jù)連接方向變成了從Client到Server端。

9

遷移改造的總結(jié)和展望文件服務(wù)器系統(tǒng)的遷移改造項(xiàng)目時間跨度兩年，在多個部門團(tuán)隊(duì)的共同合作下，順利完成。期間遇到過各種