文件服务器系统迁移改造之路.docx

1前言文件服务器系统以FrP服务为把础，为民生银行两百多供应用系统提供临时文件传输服务功能.自投入生产使用以来,老文件服务器系统已经连续服役运行超过了I年。全行两百多套应用系统的联机和批量文件交互场景强依赖文件服务系统，每天有几百万次文件的上传、下找传输请求，老文件服务器系统的架构比较传统陈旧，高可用采用HPUNIX的HA主备集群模式，无论是系统的负效能力，还是快速恢发业务已经很难满足需求，文件服务器系统的迁移改造急需完成自迁移改造项目启动到完成历时两年的时间.期间经历了迁移方案的更换,也遇到了各种复杂的技术难跑,最终在主动性维护窗口之内顺利完成新老服务器的迁移切换。本文主要介绍民生银行的文件服分器系统迁移改造的过程和方案，适合架构规划师、系统管理员、技术开发人员等阅读。文中重点介绍大的思路和方向,您可以再深入研究技术细节,相信您会更加熟悉文件服务器系统。2文件服务器系统的业务功能应用系统在文件服务器系统上都有对应的FTP用户名和细，且通常以系统的小n英文名命名.文件服务器系统为应用系统提供公共的p目录,存放临时文件用于数据交互数据文件的交互形式主要有两种：1）系统间交互,即FTPIl录上的文件,如系统A将文件放在FTP目录下等待系统B处理，系统B处理完成后将结果文件放回FTP目录待系统A取回。2）公共文件共享，HHFTP目录上的文件共享给多个系统使用，如系统A将公共文件放在FTP目录给系统B、C、D等访问。这样一个的的又“免费”的HT功能，在系统之间实现业务功能的时候.从几KB到几百GB的文件都可以安全的交互使用，便捷的服务性价比非常高.业务场景根据业务需求种类繁多，小到个人客户的某个账户交易明细联机查询，大到企业客户的代发工资文件批信处理，以及银行系统各种贷款批力1、理财申购、对账处理等口终作业的处理等，FTPEI录卜的文件在不同系统之间流转加工,既要有快速的实时响应速度,又要确保文件内容的完第性.3文件服务器系统老环境的困境文件服务器系统上的文件大规模嵌入到业务流程中，这对文件服务器系统的服务能力提出了很高的要求，几千行应用服务器日均几百万次的文件传输请求，文件服务器系统7*24小时不间断对外服务,大量的TP连接和传输请求与底层的掂础环境和网络稳定性又有着密切依赖，任何环节出现片常，都会影响正常的业务。传统的HA主备集群架构无法横向扩展，集群出现异常的切换时间是分钟级别,如果切换导致文件异常对银行业务的影响范围不可估量。为了支撑未来文件交互的业务增长，以及UNIX小型机下移到1.inUX开放平台，文件服务器系统的迁移改造正式启动。图1是文件服务系统老环境的部署示意图：9nr:«IMB-Kt1RVtBWKfM忏R<l*</Mff共计200，套外!！访问泰爱图I文件服务器系统老环境4迁移改造的挑战整体的迁移改造整体思路是将当前的主备HA集群架构改造成DNS+F5+GPFS集群架构.服务器由4台HPUNIX更换成5台Suse1.inux服务器,其中2台是同城灾备服务港,实际对外服务的服务器由I台变成了3台.老文件服务涔系统上默认保留了7天之内的文件,福要将这些存砧数据文件同步迁移到新文件服务着系统上。迁移改造主要面临三方面的挑战：1）技术方面：新老环境是两官完全不同的环境，操作系统由UNlX更换成1.inUX,文件系统由单机更换成GPFS共享文件系统UA主备更换成F5负载均衡集群,FTP功能由UNIX更换成1.inUX平台的VSftPd,2）应用方面:两百多套应用系统在老服务器上存放J'约100o万个总共1.5T大小的历史文件，120万个文件子目录，所有的用户名密码、文件目录结构权限、历史文件等全部需要迂移到新服务器匕3）业务方面：应用系统需要提前将通过浮动IP访问修改成通过域名访问文件服务器系统,这样新老环境只需要更换域名下的IP地址就几乎不影响应用系统的正常运行。另外，新老环境迁移历史文件褂要熟线停机窗口，但是停机窗口的时间又受限于银行系统的口终批量任务。5迁移改造的四个阶段文件服务器系统作为菸础服务平台，在做迁移改造计划的时候，原则上是不影响应用系统的正常业分。整改的迁移改造计划分成r四大阶段：第一阶段：测试环境域名改造，入访的应用系统安装IwS解析域名工具，将应用配置由IP访问修改成域名访问。笫二阶段：生产环境域名改造,入访的应用系统安装I）NS域名解析工具,按照从低到高的系统优先，将入访的应用系统由IP访问修改成域名访问.笫三阶段：测试环境新老服务器迁移，由HPuNIX更改成1.inUX操作系统的噂务器,同时将历史文件迂杼到新服务器，将域名下挂的F5member指向新服务器。测试环境的应用系统切换之后,脸证各种使用FTp服务的场景.第四阶段：生产环境新老服务器迁移，由HPUNIX更换成1.inUX操作系统的服务，操作步骤与测试环境相同，但是只能在有限的维护窗口之内实施,其中，第一、二阶段涉及到两百多套系统的几千台应用服务器修改配置，分成多个批次在变更窗口实俯，时间跨度超过一年，期间遇到了各种应用配置修改的问题，在此不再描述。卜面三张示意图展示了生产环境的不同阶段,最终新环境的服务戏代杵老环境的服务涔对外提供服务.图2文件服务器系统迁移前图3新老环境并行过渡期入访应用系统图4文件服务器系统新环境6数据文件的迁移方案6.1方案选异常试迁移改造第三、四阶段最关键的环节.是关于历史数据文件的迂移同步，根据现有的技术，制定了下表中的四种方案：迁移方案同介是否看用备注加：齐伶修复或熟的各馀和饯豆工具不沌用电此画：从制EIX文件装葩铁艮列1.inuxGM-S文传东找再京,不支N时早台玲文件靠及恢复数*SDFft««W质熟的磁，复制工具.<.可以投第在战复M不够用SRW-»««««:*rfi用于春记复创.不上物身也操作S桃s敷相复制Bit5hcl1：t修算*极卷FTP朦务上收的日忠文件遍址自主设计的地。U悔*丑修历史我隹文华用迁移文件的内新设簿今过ShPllW÷tft.<tt椎速实际脩况用时周整rync牛工具IINlXZlimiM东Jt下的敷据健/搏风令工.支持区线同步包去*用生产数将文件笈*大子日录多.小文件多H更新«*.我修敬提时向可他H长模拟生产M'境，分别测试了四种方案的可行性，首先否定了NBU备份恢亚和SRDI-数据复制的方案.针对ShelI迁移脚本和rsync也在验证环境分别测试/迁移功能和效率，详细的记录如下表:Bfi,MFQ予任，$仃1.J闻】矽I&M1.<依空X3X5B±.ml4f*rM刈?11122019111】.一11:04三frlc<.2019111320iin:.黑二n：«13:22Itna川<eX42ZaKfelk1.m1911142019UU.W三12J1.Z1：叫诩】财1<2<3<w<frlc«.刈翅；1920191H4.111，：2013:02ItnMl461TWe»*xfE咨初911162O19U15.WS10:56,0X££±£网旄加4723adIfer1«291911172019111«.六Ml0:391oiirl3<W15fto9lf«rle«.to>m20l1111.H10:4631:47皿IH3<<4S38ITXfeHiiJSlilUi«-3：5T11.22I然m6KZIx”l<.719112O2OI911I9.二机”)1：JOItt髀分I<«卬3三图5通过FTPH志文件重建拷贝文件sran3kjaohskhboramiaorahoae)34S?.9G0:220:00W.ETOht*hhand1*tm<hhA11K'*22>2.8；1"C3'*"l0:00.7三8MMEMKTFWW7BBI7V.Mbtt<hhandlecd2T261.K0:090:001.VZ4BZbaUhhand卜”dl9724,(0：l?0:00MlBjgvlTMl11oM¾lWlfe¾741,TC0：060:0011rmnIi1.MUKRTIat<hhandleccd235713.X0:180:00KSIKIK!Hl>>KHbrchhaMeMllbx凡hndijgIT：址骰HIHMrffU1Mil用HZY4!口：t>S，：l,iwtm，似11市rm11Bmh>t<hIiAndlebed53372.4C0:07KBi三niKimn”.JlKS>3i“Gt,H，gTTOl/bitch-handleS8J8J333.Knmy-nnmira卬:Myhhandle5201:34BW11gBT¾5¾l35TC2:570:00CTggvBMM111o/ADDAeenr«班2.IC0：090:00n11rvinI0：Ml0KJm/bitchhandle5J7485.K0:380:00skshKBEE图6rsync命令同步更制目录和文件关于自主设计的SheIl迁移脚本和rsync命令工具都能够满足我们的迁移能求，但是仍然存在一定的风磁和难度，下面简单介绍下两种方案的思路，6.2方案对比强冷1)SheIl迂移脚本：通过NFS技术将老环境的文件系统共享挂载到新环境服务器匕根据FTP日志文件,过谑出每个上传文件的汜录,然后提取出文件名、目录、用户名等信息，格式化生成需要迁移的文件列表和目录列表.通过Shell脚本提取目录列表，通过操作系统的mkdir、Chln(X1、Chwn命令在新环境重建目录，再根据文件列表并发批量拷贝(cp)到新环境。2)RSynC命令工具：RSynC是操作系统自带的一个快速、多功能的远程和本地文件拷贝工具,通过递归方式传输文件并保持所有文件的屈性，可以支持全量和地量的同步方式.通过Mt技术将老M,境的文件系统共享挂载到新环境服务器上，以目录为最小的位，将目录下所有的了耳录和文件全部同步拷贝到新环境服务器上。rsync命令简沽明了，除了-av还有几十个参数选项，可以聘平台将目录。Idfile卜所有的数据全部同步拷贝到目录nefile可r.sync.-av/oldfile/newfiIe两种迁移方案的对比:迁移方案自主设计SheII迁移脚本回。会命令工具复杂度自主编写的SheU脚本，复杂操作系统自带命令工具，简单迁移性能支持并发，全量目录重建约1个小时，每天增量的目录和文件复制约1.5个小时支持并发，全量目录和文件复制约20个小时，每天增量的目录和文件复制约15个小时在线/离线都支持梆支持异常处理Shell脚本捕获异常日志，再重新处理RSynC命令复制过程中记录异常日志.再重新处理属性一致性目录和文件数货特别多，抽样对其属性做检杳RSynC命令确保同步成功的目录和文件属性一致文件一致性部分文件抽伴检查部分文件抽样检查通过对两种方案的对比测试,发现两种方案各有利弊，Sheil迁移脚本是效率高,但是依赖FTP日志文件并且逻辑处理复杂：rsync命令性能装，但是数据一致性有保证.生产环境上应用系统对文件的处理有操作类型可能有特殊操作，比如更命名文件、更新文件内容、主动删除文件等未记录到FTP日志文件中。为了兼顾迁移性能和数据一致性，最终决定将两种迁移方案结合在一起。主螯是将SheIl迁移脚本中里建目录和拷贝文件的逻辑简化成通过rsync命令来实现,文件服务器系统上两百多套应用系统共分配了480个用户和目录,计划将这480个目录分成10组，每蛆单独设计ShelI迁移脚本，10个并发恰好能够将服务器资源利用率以大化，7新老环境迁移切换7.1迁移切换的过程新老环境的数据迂移切换其实在停机维护窗口前的T-M日已经开始准备了，但是在生产上提前迁移的时候发现迁移时间仍然超过10个小时，瓶颈是rsync命令在执行的过程中会先去通也扫描目录下面所有的目录和文件信息。当单个目录下小文件数他超过100万个，或者单个目录下的做袋子目录数量超过1万个的时候再强加生产环境的文件频繁更新,迁移的性能急剧卜降。必须在正式迁移切换之前解决性俄问题.否则迁移任务将无法完成.这些问题目录涉及了多套使用文件服务器系统存放文件的应用系统，只能将这些有问题的目录列举出来，逐个去梳理目录的业务场景、清理策略、文件和子目录用途等。在得到每个应用系统负货人的确认后,清理了约800万个历史文件总容量约500G删除了约90万个嵌套子目录。这个过程是自若很高生产操作风险，每一次删除命令都不允许出错！但是，当将问题目录全部处理完成之后，效果也出现人在畿迁移数据只种要1个小时，最终在维护窗口离线迂移数据时只花了30分钟。而旦，因为经过“救身”之后的系统，也有足够的时间对迁移状态做全城检查,新老环境的文件和目录迁移之后完全一致。除了迁移数据文件之外,新老环境服务上是完全不同的操作系统FTP服务的底层实现差异很大，需要将FTPSerVer端的配翼参数逐一对比修改,主要是从FTP的传输模式、权限控制、用户控制、连接控制、口志格式等方面考虑，这里不再具体描述，建议系统管理员结合实际的应用需求去修改etcvs11pd.Conf里面的配置参数.7.2迁移切换的效果文件服务器系统迁移到新M境之后，由单台服务器变成多台服务器同时对外服务,新环境的架构支持横向犷展，变成真正意义上的多活架构。从交易性能监控平台的数据21端口的控制连接)可以看到,文件服务器系统的白天平均交易响应时可由平均约7.9秒,卜降到了约2名杪,而且交易口峰时间段的响应时间由起伏波动变成了I分平检。老环境的交易性能数据(2021.10.11)图8新环境的交易性能数据2021,11.01）8生产何题案例文件服务器系统提供的FrP服务看似检单,在应用系统调用时如果没有考虑并常处理机制，可能引起交易失败。本章节按照FTP服务异常的分类，简单分享了个关于文件服务器系统的生产案例，供参考学习UFTpSerVer端的端口被占用问题现象：某应用系统产品信息发布后，应用本地生成了产品交易状态的文件,通过FTP命令上传到文件服务器系统后，异步通知渠道系统同步文件.渠道系统下载了文件并入底，但是入库后的产M交易状态内容为空，导致所有的产丛状态无法在架道正俯展示,原因分析：通过网络抓包分析，应用系统访问文件服务器系统时，是通过“F5YIP地址”映射方式实现且F5VIP采用单一SMTIp进行转换与后端真实文件服务器建立连接.两次文件传输过程中，由于部分客户端拆连接时为按标准控制指令，进行拆连接，导致第1次的数据连接未拆处完成，FTPServer端占用的临时的机端口不糕放，此时第2次（与第1次的客户相不同）建立新连接如果也使用相同的端口，导致FTPServer端无法建立数据连接。所以第2次传输的文件在文件服务器匕未正常完成,实际上是个空文件.解决方案“：应用系统连接FrP的方式由被动模式改成主动模式，这样建立数据连接的时候，FTPSeryer端主动与FTPCIienl端的随机端口建立连接，相对于被动模式，避免FrPSCrVer端连接数多的情况下,随机端口被占用的情况。解决方案b：文件服务器系统的F5SNAPIP修改成透传源IP地址,这样FTPClient端和SerVer端之间由映射IP对SerVerIP（一对一）变成ClientIP对SerYerIP（多对一），避免FTPServer端附机端口被占用的情况。2）FTPServer端上的连接被reset问8现象：文件服务器系统在某个时间段，FTPServer湘的流城突然下降,当时部分应用系统正在做日终批量处理,由于批量处理的文件需要在贷款系统、公共支付、银行核心等多个系统之间加工交互，作业琏条被迫中断，需要人工进入干预.原因分析：文件服务器系统的FTP服务是正常状态，而口未做任何操作的情况下，流Iil又快宏J但是，操作系统口志显示文件版务器系统的服务器（即member）到上层的F5VlP有大量“lostconnection"报错,应用系SEClienl端到FTPSerVer端的连接被reset。应用系统访问文件服务器系统时，F5VIP采用单一SNTIP进行转换与后端其实文件服务搭建立连接，由于部分客户端拆连接时未按标准控制指令进行拆连接，导致F5偶发性与后端FTPSCrVer连接未能正常拆除，当新建连接发起请求时，采用了与异常拆连接同样的SNATIP+端口时产生了随机端口冲突，F5在端口转换机制上出现了短时间的异常,对于新建连接进行了Reset拆健，导致谢用FTP的请求无法正常转发到FTPMember上,解决方案：文件服务器系统的F5由SNAPIP修改成透传源IP地址,降低由于个别客户端不规范拆除连接，带来单一SNATIP地址转换机制问题,并I1.文件服务器由主笛HA集群架构改造成DNS+F5+GPFS集群架构,解决FTPSerYer端单点的问题,提升文件服务器ITP整体对外服务能力.3）FTPSerVer端和CIient端的文件大小不一致问题现象：某应用系统通过FTP命令传输数据文件和校验文件filelist）到文件服务器系统，下游数据管理系统（MDS）获取到数据文件和校验文件，但是在通过CiIeIiSl校脸文件时，发现数据文件的实际大小和filelist里面记录的大小不匹配,导致MDS卜我数据文件失败.原因分析:文杵服务渊系统由HPUNIX迁移到SUSe1.inUX平台后,应用客户端传输文件到文件服务器系统由同平台变成f跨平台传输，在传输文本文件时，系统默认选择文字模式（ASCll）传输，导致文件格式和大小发生变化。解决方案a：应用客户端在传输文件的时候,显示的指定二进制模式B1N）,这样传输文本文件的时候,格式和大小就不会发生改变.解决方案b：在文件服务器系统的FTP参数配置文件里面，设置asciiUPlaad.enable和asciidownloadenable参数，官方文档里面关于这两个参数的解择是设汉是否启用ASCll模式上传下载数据,默认值为Noe实际上,根据测试结果，当将两个参数设置成YES后，应用客户端在传输文件的时候，无论以ASCIl还是BlN模式传输文件，都不改变文件的格式和大小.4）FTPnlist命令查询文件慢问题现象：某应用系统在文件服务器系统迁移到新环境之后，联机交易平均响应时间由02秒上升到10秒。应用日志显示,交易耗时主要在应用系统与FrPSerVer端之间的交互。（S因分析：该应用系统联机交易会先查询（nlist）文件服务器系统目录卜的文件,判定是否存在.通过网络抓包分析，再结合Vsftpd的代码，1.inux平台的vsftpd和UNIX的ftp功能实现有养芹，vsftpd里nlist不仅会查询文件，还会对目录下所有文件极要信息做遍历，然后通过filter和SOrt返回结果到客户端。当目录下的文件越多，nlist的查询J效率越慢.当应用系统短时间查询不到结果时,尝试发起重试,应用逻辑处理慢比加nlist查询效率慢，最终导致联机交易的整体响应时间变长。talicroMMi14jjjr_Hx5g<M"jutC-A*4f<f.hiasc，“jm.或城会皿w相最+于文/4三<MX4.*trCtwlbtMffRganJ/7m三rMir,rtr/H*urtr>i4-W*<iH,击S次Aat7i三l必0mx5；if(dn9it)/MW/然j(懿_/aMrJM代MSM4y.if<mv(W(WfUAddfUmaatMe*rm117Hnt-nrtingby/Var，XmA)r2hiU(D'解决方案h：该目录卜飞计存放了20万个左右的历史文件，临时将不再使用的历史文件清理掉，nlist的查询速度恢史到1杪以内.解决方案b：建议应用程序在使用11list的时候，需要结合应用程序进行性能压测，或者通过其它方式判断文件是否正常上传，规避nlist查询效率慢带来的影响。5）FTPClient端下载文件慢问题现象：某应用系统日终批批作业在老环境上卜教机构信息文件时（MB大小）耗时0.1杪,但是在新环境是下我同样文件时却消耗了700秒，导致了批fit作业整体超时失败,原因分析：通过网络抓包分析，客户端到新环境的rtt网络时延）比老环境快50倍，达到了0.018皂秒，甚至比javaftp客户湘处理1152字节数据的速度（0.8皂秒）还要快。这导致FTPSerer端不断收到来自CIienl端的ZerOWindOw,每收到一次,SerVer端都需要等待200是秒后才货发送数据.相当于每200卷秒才发送1152字母的数据,这样发送MB的数据就需要728秒。图9TCPWindowFUU的网络数据图解决方案:发现何时的应用系统使用的是ComnOnS-nei-3.2.jar包实现FrP传输功能，默认未设置馈存大小，建设设置成8192或者更大，可以解决该问题。疼图connect(IP)；g0gin(uor.pai90rd)：C!颂,setF11cv(rTP.B1XYH1.EJPE):葭量缓存大小0上K0”,§£!典一逸®?£(8192)：6） FTPCIient端判断FTP返回码异常问题现望：某应用系统日终批量:作业下载文件服务器系统上的某个文件，如果该文件不存在，则开始定时轮沏，百到杳询成功后开始下载该文件，轮询结束.但是文件服务器迁移到新环境后，该日忐批量作业查询到文件不存在时，直接退出轮询，导致作业异常失败。原因分析：经测试，在UNlX平台上如果文件不存在则返问FTP550的报错码，但是，在1.inUX平台上如果文件不存在，在查闻的时候直接返回空佶息（FrP返回码226）,应用程序FlPUti1.jaVa无法判断返回码226的状态，则跳出定时轮询，V致下或文件失败。解决方案：应用程序对于文件是否存在的刊断,需要兼容考虑不同平台的返回码,或者增加对文件数St的列断逻辑.否则会影响正常的业务逻辑判断.金钱文育裕仔建tiW经送S吗8文常aX制豪StrifSHJ/Z/哨MKS-(fA74FXwt:(三EWfd效暮ZaM2-*/金费文存曼苔有/遮E陋世，0)：/"/-RUSSO!CaAu¾/(12赛.JnC整*文身之苏弹畲：CAWK的转IaMm；A.9*"。必谈CZH说:。力/Wxr.ArCCP/弁Zg*ZtfcSMSJif(ffAC5"EnIWgAIEh.'6USSO!Ca松M<"J(Eil侬Xi丸$-true：/&rryZr:2fd弊，缗-G,0£!，哂宴，；7） FTPClient端未响应Server端的SYN访求问题现象：某应用系统通过FTP命令登录FrPServer,但是在卜载数据文件的时候失败,导致后续的交易场景未正常执行完成.原因分析：通过网络抓包分析，该CIient端已经建立控制连接，在开始传输数据之的主动模式），SerVer端到CIient端需要建立数据连接，但是SerVer端连续发了3次SYN请求，CIienI端都未正常响应，wFailedtoestablishconnection",M终数据传输失败，（细心读者应该发现7个问题案例中，有4次是“通过网络抓包”.分析了FTP交互数据过程中的每一步操作，才最终找到问题原因.）图10FTPSeryer端连续3次SYN请求解淡方案：某应用系统在某个时间段业务繁忙，FrpClielH端无法正常响应SerVer端的数据连接诂求，在不调整业务的情况下，临时将传输文件的模式由主动模式调整成被动模式（跟第1个问题案例的模式相反,这样数据连接方向变成了从Client到Server端.9迁移改造的总结和展望文件服务SS系统的迁移改造项目时间跨度两年，在多个部门团队的共同合作卜顺利完成，期间遇到过各种技术难题严重的甚至影响到应用系统的正常运行，上一章节的案例中也简单分享了.IUI顾将个迁移改造项目过程，总结了些经验教训,9.1经验总结1）架构和项目规划系统的架构规划好坏决定了系统的健壮性，项目进度的规划决定了任务完成的技术性。技术方案充分讨论测试，项目任务提前协调考虑,做好充分的准爵工作,自然能第顺利完成。2）团队合作文件服务器系统的迁移改造不仅仅是这个系统项目组的任务,整个过程中需要基础讣境、网络、应用运维、应用开发等多个技术团队的支持。从底层技术，到应用场景，以及整改优化，团队之间的沟通讨论十分卡要。3）测试脸证事实上，正式迁移切换到新环境之后，是很难再回退到老环境,切换之后如果在新环境出现异常,影响的范困将非常大,风险很高。但是，所有的迁移改造任务都是在测试环境先验证，住测试环境提葡大范围的腌证，基本上确保应用系统在新环境能够正常使用文件服务器系统的服务。9.2后埃展加1文件服务器系统的使用规范FrP技术提供了高性价比的文件传输服务，对于FTP技术在底层代码实现的迈辑需要深入研究分析清楚,再结合应用系统的使用场景,做好文件的正确性校验和传输过程中的异常处理.后续将根据已知的何牌,继续更新文件服务器系统的使用规范，2)FTPClienl客户端组件封装开发技术人员根据FTP使用规范可以去优化应用系统，但是在实现时每个人的理解可能会有差异，趋础技术团队也会统一收柒考虑希求，由专业的团队研究FTPClienl的技术实现，将FTp的APl规蔺统一封装成FTP组件，集成到TES1.A开发平台中.3)应用系统的联机和批St拆分目前，应用系统的联机和批破都会通过文件服务器系统去交互临时文件，但是两种方式时于文件传输服务的要求不同，后续计划将文件服务器系统拆分成联机服务和批量服务的两大模块。另外一方面,随着新技术的发展，非结构化数据平台在管理文本、图片、音视频等数据时,能够提供比FTP更加高可靠、高性能的服务,根据应用系统的场景分类，计划将部分服务尝试迁移到非结构化数据平台。