架构设计：文件服务存储设计

在架构设计：文件服务的设计与实现一文中，通过实现一个文件服务来梳理了一个架构设计的一般流程，并得到如下静态架构图

本文继续聊聊文件服务中的子模块：「存储模块」的设计，包括：

前面的架构没有对存储进行特别设计，直接使用了本地存储。考虑到后期文件数量可能会越来越多，本地存储可能无法支撑，且本地存储的安全性也没有保障。为了便于后期扩展，需要对「存储」部分进行设计。

存储的方式有很多，本地存储、NAS、分布式存储，为了能支持不同的存储方式，需要对「存储模块」进行抽象。考虑到「存储模块」涉及到IO，是一个相对底层的模块。「上传」这个核心模块不能依赖于具体的存储，所以这里也需要对其进行依赖反转。

见紫色部分，UploadService调用了FileInfoRepository来存储FileInfo，而FileInfoRepository是个接口，具体实现由存储模块中的实现类来实现。

我们先看本地存储。最简单的实现，就是直接使用IO将文件写到对应的目录下就可以了。但是，本地存储会有如下几个问题：

下面我们针对上面的问题，来一个个的解决。

首先，对于多租户来说，在我们的架构中，实际对应的是Group，我们按照Group的不同，来划分目录即可。即 不同的租户有不同的文件根目录 ，后期某个租户迁移时，直接迁移对应目录即可。这也稍微解决了单目录文件数量多的问题。

对于单目录下，随着文件数量的增加导致访问速度下降的问题，我们该如何解决呢？

如果你做过分布式系统，那么想一想， 我们是否可以把单目录看成是一个服务器，访问目录下的文件看成是一个个的请求呢 ？如果可以，那解决单目录下访问速度慢的问题是不是就变成了「如何解决单服务器下，负载过高」的问题了？那解决服务端负载过高的方法是否适用于解决目录访问速度下降的问题呢？

我们从下面几个方面来分析一下：

首先来看「解决服务端负载过高的方法」！答案很明显： 分流+负载均衡 ！

分布式服务的负载均衡有几种方式呢？

再来看「目录访问和服务器的区别」，虽然可以把目录看成服务器，但是两者还是有区别的：

也就是说，对于目录来说，我们不需要考虑创建成本。

那么针对服务器负载高的解决方案是否适合目录访问呢？或者哪种方式适合目录访问呢？我们一个个来分析：

可以看到，主要的问题就是创建目录的问题！如何保证在目录数量改变时，不需要调整程序呢？

实际上git已经给出了答案：

也就是说，根据sha1散列的前两位对文件进行归类。这样既解决了目录创建问题，也解决了文件分布问题。可能的问题是，「sha1散列2^80次，可能会发生一次碰撞」。这个问题对于一般文件系统来说，好像也没有担心的必要。

解决了「单目录文件过多，导致访问速度下降」的问题，我们来看下一个问题： 数据安全 。

文件数据是存放在电脑磁盘上的，如果硬盘损坏，可能导致文件的丢失。这实际还是一个「单点问题」！

「单点问题」的解决方案是什么呢？ 冗余 啊！

最简单的方案就是定时去备份数据，可以有如下几种方案：

我们继续一个个的讨论。

首先是 人工备份 ，这是最low的方案，当然也是最简单的，即有人定期去备份就行了。问题是时效性不高，例如一天备份一次，如果磁盘在备份前坏了，那就会丢失一天的数据。同时恢复比较耗时，需要人工处理。

第二个方案是 代码实现 ，即在上传文件时，程序就自动备份。以上面的架构为例，可以添加一个BackupListener，当上传完成后，通过事件，自动备份上传的文件。同时下载时需要判定文件是否完整，如果有问题则使用备份数据。此方案时效性得到了保障，但是将数据备份和业务放到了一起，且需要编码实现，增加了业务代码量。

第三个方案是 libfuse ，libfuse是用户态文件系统接口。下面是libfuse官方简介：

简单来说，就是可以用libfuse构建一个用户态文件系统。之前在老东家做了一个日志分析平台，日志的收集就使用了libfuse，大致架构如下：

业务系统写日志到挂载的用户态文件系统中，用户态文件系统自动转发到了后续的处理中间件：redis、消息队列、文件系统。

在这里也可以用类似的功能，即在文件上传后，用户态文件系统自动备份。此方案解耦了文件备案逻辑与业务逻辑。

最后一个方案是 RAID ，即廉价冗余磁盘阵列。RAID不但可备份文件，还支持并发读写，提高上传下载速率。

常用的RAID有：RAID0，RAID1，RAID01/RAID10，RAID5和RAID6等。我们来看看这几种RAID的特点，以及是否适用于我们的文件服务。你会发现从RAID0到RAID6，又是一个从单点到分布式的过程。

看下面的两张图应该能更好的理解：

无论是RAID10还是RAID01，对磁盘的使用效率都不高。那如何提高磁盘使用率呢？就有了RAID3。

对于本地存储来说，RAID是个相对实用的解决方案，既能提高数据安全、快速扩容，也提高了读写速率。但是无论扩展多少磁盘，容量还是相对有限，吞吐也相对有限，同时由于其还是单点，如果文件服务本身挂掉，就会导致单点故障。所以就有了分布式文件系统。

分布式文件系统下次单独讨论！

最后打个广告，帮朋友开的专栏《零基础Unity3D 游戏 开发》，适合没有基础、想从事 游戏 开发的小白！朋友从事 游戏 多年，开发了多款 游戏 ，收了30多个徒弟，技术杠杠的！

阁下在没有分布式集群部署经验的前提下能画出这样的架构图让人佩服

本来我是不敢回答这些问题的，因为本身我也没有集群部署经验，但是一来没有人帮忙回来二来我也看过一点这些相关的书籍，所以可以把我知道的给你说下，估计能帮助你30%。

整个架构部署用到了集群部署（1:2）、动静分离、缓存服务、拆分数据库等高并发处理技术，属于大型系统的模型。

据我所知，集群1:2是1负载分发器、2web服务器，（以Apache+tomcat集群为例），那么Director server应该安装Apache，而Real Server应该安装tomcat，至于java web项目在tomcat下面即可。

而你的架构图中还有动静分离机制，理论上静态文件服务器也应该有java web项目才对，不然静态文件服务器如何取静态文件呢。tomcat对静态文件处理不是很好，所以很多人推荐用Nginx作为载体。

缓存和集群数据库我不了解，不发表任何谬论。

session会话就是指的httpsession：一个客户端一个session会话，在客户端与服务器保持通信期间都会需要这个会话，所以集群服务器一定要保存这个session。问题是客户端的URL请求被director server均衡分发了，可能第一次访问的是第一个real server，第二次访问的是第四个real server，如果session只在第一个real server保存，而第四个real server就会认为客户掉线拒绝请求，所以你要考虑四个real server用一种机制保存共享所有客户的session。一些经典的共享session方式有：session复制、session粘连、session统一独立存储等。

建议看下一些集群架构方面的书籍，比如《大型网站系统与java中间件实践》。

B/S和C/S混合架构的文件管理系统设计

文件管理系统能够大大降低文件管理工作人员的负担，在实现无纸化文件传输流转的同时，也提高了办公效率。下面对分布式文件管理系统进行了设计与应用，提出了基于B/S模式和C/S模式相混合的应用架构，这对于分布式文件管理设计是一次有益的尝试，同时对其它分布式管理系统设计与应用也具有较好的指导和借鉴意义。

鉴于自动化控制系统在处理多任务信息开发和管理中所表露出来的优越性，本文件管理系统的开发设计也借鉴和应用了分布式管理系统的开发模式。目前，分布式管理系统的主流开发应用模式主要有两种：B/S模式和C/S模式。

1.1 B/S模式

B/S模式，即浏览器服务器模式，其主要应用模式是将多任务所涉及到的数据信息，统一交由数据库服务器进行管理和发布，而用户只需借助浏览器就能实现对多任务信息的统一访问及数据信息管理。如果文件管理系统采用B/S模式，则无需开发专门的文件管理信息系统，就能够轻松实现对文件信息的管理，而且只要有能够联网的电脑终端，且电脑终端配备了浏览器，就能够实现对文件信息的访问和管理。这种模式极大地减轻了开发人员的设计工作量，但同时也增加了数据库服务器的'负载压力，容易导致整个信息管理系统宕机，一旦数据库服务器宕机，则有可能导致整个文件管理系统失效。

1.2 C/S模式

C/S模式也称客户端/服务器模式，这种应用模式需要为用户配置专门开发的客户端，只有电脑终端安装了这种专门开发的客户端，才能够实现对系统内数据信息的访问、配置和管理。因此，该模式的最大弊端就是开发设计的工作量大，需要专门技术人员才能够实现对系统内文件信息的有效管理。同时，这种C/S模式将数据库服务器的负载压力平均分摊到了每一个客户终端，因此服务器的压力较小，提高了整个文件管理系统的稳定性和健壮性。

分析发现，B/S模式和C/S模式都有各自的优缺点，因此，考虑将B/S模式和C/S模式这两种分布式系统模式的优势相结合，设计基于B/S和C/S混合模式的文件管理系统。这种基于混合架构的文件管理系统具有如下特征：①文件管理系统的数据结构采用B/S模式，这样每一个客户端只需要借助于浏览器就能够实现对文件管理信息的访问和统一管理，而无需为每一个客户端配置专用的客户端程序，降低了开发设计人员的工作量②文件管理系统的分布式结构采用C/S模式，将数据库服务器统一管理模式交由若干个应用终端分担，能够极大地减轻数据库服务器的负荷压力，有利于提高整个文件管理系统的稳定性和健壮性③应用C/S模式可以有效实现在局域网内的联网通信管理能力，同时C/S模式所采用的异步确认机制也能够从根本上提高文件收发管理的实时性和准确性，有助于提高文件管理办公效率。

2.1 文件管理系统功能

基于B/S模式和C/S模式混合架构的文件管理系统，其管理功能主要包括以下几个方面：

(1)文件管理功能。文件管理主要是对文件收发进行相关信息记录，包括收发责任人、文件大小、传输信道、文件格式、时间戳等，所有数据信息统一在数据库服务器备份，以实现统一管理。

(2)文件收发功能。利用局域网通信组件能够实现自上而下及自下而上的文件收发、转发管理。同时，对文件信息内容进行按需过滤，建立文件检索关键词，以提高文件管理效率，并实现自动化、无纸化办公的目的。

(3)用户管理功能。对使用该文件管理系统的用户进行注册管理，分配统一的登陆账号和密码，确保文件信息的安全性另一方面，针对不同级别的用户，分别设置不同级别的权限，以实现对文件信息的分类管理和权限制访问管理，提高文件管理效率。

(4)联网安全管理功能。由于文件管理系统不可避免地会涉及到网络文件的收发，因此需要加强对系统的联网安全管理能力。可以通过采用用户账号登录、数据库矩阵机制、文件信息内容加密等措施，提高文件管理系统的安全性。在系统硬件架构上，可采取物理隔离、硬件防火墙等措施为文件管理系统的安全性提供保障。

2.2 系统架构与实现

基于B/S和C/S混合架构的文件管理系统，从硬件架构上来说，既要凸显C/S模式的优势，同时也要在数据库访问机制上保留B/S模式的优点，图1为基于B/S和C/S混合架构的文件管理系统架构原理图。整个文件管理系统，其硬件上主要从以下几个方面加以实现：

(1)文件服务器采用磁盘阵列。主要存放tiff格式的遥感影像文件及其影像产品的描述文件等，数据库服务器存放遥感印象产品的编目信息，FTP服务和IIS服务部署在同一台服务器上。并且，采取通关防火墙等安全隔离措施，以方便外网多用户通信。

(2)Web程序采用VS2010 C#语言，基于ASP.NET 开发。主要实现遥感影像产品编目信息查询、遥感印象产品管理、用户管理、文件分发计划制定、公告发布等功能。 (3)FTP服务提供文件下载服务。采用Windows自带的FTP服务，采用虚拟目录的形式将FTP的文件目录指向文件服务器。

(4)文件分发管理服务软件安装在中心的FTP和IIS服务器上，与IIS服务和FTP服务共用一台服务器。主要定时查询数据库中管理员制定的文件分发计划，解析文件分发计划内容，根据分发计划中的用户名将分发计划中的文件名和编目信息，以及访问FTP的用户名和密码发送到指定用户的文件下载客户端，文件下载客户端收到文件推送信息后根据信息的文件名和路径，以及访问FTP的用户名和密码自动下载文件。

(5)文件下载客户端软件，安装在用户终端上。用以实时接收文件分发管理服务软件推送的文件下载信息，并根据下载信息自动下载文件。

2.3 系统软件设计

基于B/S和C/S混合架构的文件管理系统，其主要功能是实现文件的收发传输，因此在软件设计上，需主要完成文件收发传输的工作流程设计。

(1)文件传输管理。由文件发送方选择文件类型、文件数量及文件内容，经过系统内部封装，打包发往指定的部门或者客户群，同时出于对文件安全性的考虑，支持增添密码访问功能。当指定用户打开由上游转发而来的文件时，在验证了用户身份和文件访问密码后，可进行文件打包下载，将相关下载信息反馈给文件发送方，并对整个文件传输信息进行记录备案。

(2)用户权限管理。用户必须完成注册，获取系统统一分配的用户名和密码，才能够登陆系统进行使用并且，针对用户注册时所选择用户类型的不同，分别赋予不同等级的权限，对文件管理系统内的所有文件信息标记不同权限等级访问标签，从而实现对用户和文件的双重分类管理，提高系统的安全性。

---