基于FastDFS的协同办公系统应用
2020-02-03何文民
何文民
（中国直升机设计研究所 江西省景德镇市 333001）
协同办公系统是包括公文管理、协同办公、数据交换、信息安全的企业办公系统。随着协同办公系统的深入使用，尤其是附件数据量的急剧膨胀，通过数据库存储附件方式给协同办公系统带了很多负面的影响，不但降低系统响应速度，而且数据备份与恢复也变得更加困难，一旦系统发生故障，很难在短时间内完成系统恢复工作。协同办公系统是一套包括公文管理、协同办公、数据交换、安全管理的企业协同办公系统，其业务范围涵盖了收文、发文、呈批件、事务督办、会议管理、电子数据输入输出、VPN 数据输入输出等，可大大提高我所办公效率，降低企业运行成本。然而，随着系统的深入使用与两地协同办公，我所也对现有系统提出了更高的要求，不但肩负着日常办公的重要任务，还成为大文件传输、存储、共享的工具。在大数据时代的背景下，用户数据与存储文件呈爆炸式的增长，原有数据存储方式给系统带了很多负面的影响，不但降低系统响应速度，而且数据备份与恢复也变得更加困难，一旦系统发生故障，很难在短时间内完成系统恢复工作。
为了使协同办公系统高效稳定运行、异地办公、系统容灾备份的可操作性和可行性，必须实现系统数据分离和异地存储。为了解决系统数据分离和异地存储问题，本文结合系统工程和IT 架构等方面的思想方法，对系统进行重新构建，提出通过FastDFS 对系统中附件进行存储管理，更好的解决系统数据分离和异地存储，加快系统访问。
1 相关工作
1.1 业务分析
协同办公系统是基于BS 框架，并与BPM 流程关联，数据存储是通过Oracle 数据库进行存储与访问。系统架构是AD 认证层、业务功能层和系统支持层由三层组成。通过AD 域用户统一身份登入，业务功能主要有公文管理、协调办公、数据交换与安全管理等功能模块，其中业务都与BPM 流程关联，系统在J2EE 平台进行实现。但是随业务表单与附件数据日益增加，新增业务流程不断增加，特别是业务表单附件，通过数据库BLOB 类型数据进行存储，导致系统数据库中数据急剧增大，每周都要不定时对系统数据库进行扩容，同时还造成用户访问效率变慢，对系统数据库备份十分困难。
随着我所异地办公，对系统进行访问，访问效率十分慢。常用发文管理与收文管理进行流程审批很慢，数据输出表单在上传附件时，时常无法上传。通过对现有系统架构与使用场景的分析，发现系统附件是通过oracle 数据库Bolg 进行存储，导致oracle 数据库存储空间不足和Bolg 空间的浪费，随着附件数量增加，文件的检索速度会减慢。因此，必须对系统架构和服务部署进行改造。将表单附件必须从系统数据库分离，减轻系统对数据库的访问；两地对服务访问进行分布式部署，减少并发量，提高访问效率。
1.2 FastDFS文件存储
图1：系统架构
图2：附件上传时序图
Hadoop 计算平台被广泛的用来处理海量的大数据，Hadoop 分布式文件系统是为处理流式访问大文件提出[1]的，在处理大量小文件上，效率很低，会导致内存空间不足和Block内存空间的大量浪费，并随着小文件数量的增加，文件的检索速度会受影响；FastDFS 是一个开源的轻量级分布式文件系统[2]，与其它应用级的分布式文件系统相比，它是一款量级轻的软件，能满足大量用户的并发访问与存储，在客户端发送存取文件请求，跟踪服务器（tracker）进行调度，存储服务器(storage)进行文件存储。它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。文件服务器中存储的文件都经过了AES 加密处理，保证文件的安全性，一旦发生文件被窃取的情况，也能防止文件中的信息泄露。
表1：附件数据表的结构
图3：服务两地部署
2 总体设计
2.1 系统架构
鉴于对现有系统分析与FastDFS 存储特点，结合分布式系统的架构模型，可以将系统架构改造为基于FastDFS 分布式存储系统架构，如图1 所示。
主要由四部分组成，从上至下分别是：AD 认证层、业务功能层、系统支持层和数据存储层。AD 认证层是基于B/S 模式，通过域帐号进行AD 域认证登入系统，系统通过Web 浏览器展现系统各个功能。业务功能层主要是由各个功能模块所组成，来实现系统主要功能，其中主要有公文管理、协调办公、数据交换与安全管理等功能模块，收发文管理、呈批件、事务督办、会议管理和数据输入输出子模块业务都与BPM 流程关联，进行相应流程审批；安全管理主要进行日志与用户安全监控管理，实现系统进行三员管理。系统支撑层主要支撑系统正常运行，系统是在J2EE 平台下实现，由jdk 基础开发包和新增FastDfsUtil 插件组成，其中FastDfsUtil 对FastDFS 进行文件上传、下载与删除。数据存储层主要是对系统数据和附件进行存储，主要由Oracle 数据库和FastDFS 分布式文件服务器组成，其中Oracle 数据库存储系统表单、流程和系统数据，而FastDFS 分布式文件服务器主要存储系统附件。
2.2 附件访问运行机制
结合改进系统架构，对系统的异地附件上传与下载运行机制进行分析与设计，storage 服务器将定时向tracker 上传状态信息，如图2 中第1 步与第2 步。
当用户要上传附件时，根据用户所在地址，如A 地用户上传附件，过程如下所述：首先，用户通过Web 浏览器向应用服务器发送上传附件，应用服务器向tracker 服务器发送上传请求；其次，tracker 服务器根据访问地址进行判断是A 地，获取部署在A 地可用的storage 服务器，并向应用服务器返回storage 服务器的ip 和port；然后，应用服务器根据storage 服务器的ip 和port 向相应的storage 服务器上传附件，storage 服务器会生成fid 和存储附件，并向应用服务器返回fid；最后，应用服务器把fid 存储到Oracle 数据库中，如图2中第3步到第11步所示。当在B地用户进行上传附件时，同理，如图2 中第12 步到第20 步所示。
生成的文件标识符fid 信息主要由四部分组成，即：分组的组名，磁盘路径，两级目录和HASH 算法生成新的文件名称。具体形式如下所示，
3 系统设计与实现
3.1 服务器部署设计
根据系统架构与附件访问分析，由于A 地与B 地局域网连接是通过专用网互联，公司总部是在A 地，对系统访问量也比较大，因此，将应用服务器和数据库部署在A 地。分别在两地都部署一套文件服务器，便于存储空间扩容，两地都部署相应的磁盘阵列，系统相关服务器部署如图3 所示。在文件服务器A 上安装tracker服务和storage 服务，文件服务器B 上安装storage 服务。在应用服务器设置两个secretkey，分别为secretkeyA 与secretkeyB，便于应用服务器根据上传地址，判断使用A 地的存储服务器，还是使用B地的存储服务器上传附件。
3.2 附件上传下载实现
根据系统架构和服务器两地部署情况，要实现附件上传下载功能，如下所述：首先，在文件服务器A安装tracker服务和storage服务，文件服务器B 安装storage 服务；其次，在应用服务器上实现附件上传、下载功能与数据库附件存储结构。
附件在系统数据存储结构如，表1 所示，其中根据附件上传地址，来确定是在A 地还是B 地，来确定存储到文件服务器A，还是文件服务器B；FID 是FastDFS 文件服务器上传成功后，返回附件在文件服务物理地址与加密后文件名。
4 结论
本文通过将原有的系统架构改造为基于FastDFS 分布式存储系统架构，在两点地部署FastDFS 文件服务器与实现附件上传下载等功能，解决系统数据分离和异地存储，不仅加快系统响应速度，保证系统稳定运行，而且数据备份与恢复也变得更加便捷。即使在系统访问高峰期，两地人员在系统中上传下载也十分方便。系统出现故障次数也减少很多，运维管理人员也不需要时不时对系统数据库进行存储空间扩容。
