HarmonyOS 鸿蒙Next分布式文件系统实现跨设备文件访问的N个秘密|分布式数据管理解析（三）

HarmonyOS 鸿蒙Next分布式文件系统实现跨设备文件访问的N个秘密|分布式数据管理解析（三） 之前的推文中，我们已经对用于实现跨设备数据存储和同步的分布式数据库进行了详细解读，为开发者们揭开了分布式数据管理强大功能的一角。

内容传送门：

第一期：
“超级虚拟终端”数据如何流转？HarmonyOS为你探秘！|分布式数据管理解析（一）

第二期：
分布式数据实现跨设备数据同步的N个秘密 | 分布式数据管理解析（二）

本期让我们继续走进分布式数据管理另一核心功能——分布式文件系统的解读，看看分布式文件系统如何实现跨设备文件的访问。

分布式文件系统的定义及应用场景

众所周知，每个设备都会有自己的本地文件系统，用于存储设备上用户和应用产生的包括图片、视频、音频、文档等在内的各种文件，每个设备上的本地文件系统彼此之间是互相独立的。但随着个人智能设备的增多，大家时常面临多设备间文件共享问题，比如说手机与PAD之间的文件传输分享问题。

目前对于这种问题常见做法是借助网络传输工具例如华为share或微信，或者借助应用云服务，这当中的实现非常复杂。分布式文件系统就是为了解决文件传输业务上的痛点而存在的。分布式文件系统将各个设备上孤立的本地文件系统进行连通，组成一个“虚拟的超级文件系统”，打破设备之间的存储边界，文件可以在多设备间完成自由、安全的流转和访问。

我们来看一个常见的例子。很多人使用手机拍照后会借助PAD对图片进行编辑，毕竟PAD的界面更大，编辑能力也更强，完成编辑后会将图片从PAD重新发回到手机，通过手机分享到朋友圈，这中间至少需要完成手机—PAD—手机这样复杂的传输操作及流程。

但是，如果通过分布式文件系统，用户可直接在PAD就可以看到该图片，直接使用PAD打开图片进行编辑，编辑保存后的图片仍然存在手机上原来的文件位置，无需借助网络传输工具或云服务，即可方便地实现图片在多设备上流转编辑。在这个过程中，PAD和手机操作的始终是同一个文件，都是在手机上拍摄到的那个图片。

通过上述例子，我们不难看出分布式文件系统是一种系统能力，它可以为应用提供跨设备的文件访问能力，这使得应用在多个设备间需要使用和编辑同一个文件时，无需在设备之间传递文件，使用起来非常方便。

那么分布式文件系统究竟如何提供跨设备访问的能力，下面让我们来打开它的架构视图和运行视图，深入了解一下。

分布式文件系统的架构视图

分布式文件系统采用的是一个堆叠式的设计，其堆叠在本地文件系统之上，本身没有存储能力。

分布式文件系统向下调用本地文件系统的存储能力，将分布式文件目录树和文件内容存储到本地文件系统上，向上又是一个标准的文件系统，负责管理和存储文件信息，同时兼容POSIX接口，减少开发者学习成本。

在分布式文件系统中，各个模块承担了不同的职责，从而实现文件跨设备访问的能力。

通信组件

通过内核态的通信组件，分布式文件系统实现与其他设备上的分布式文件系统进行互通，从而实现文件的跨设备访问。

存储管理

通过存储管理模块，分布式文件系统完成对于存储“空间”的管理。

Dentry管理

通过Dentry管理模块，分布式文件系统实现对于文件夹及最终文件的目录项管理。所有目录项将构成一棵目录树，而Dentry管理就是对这棵大树的管理。

Cache管理

通过Cache管理模块，分布式文件系统可以实现Cache的智能预读跟管理，提高文件跨设备访问的性能。

分布式文件系统的运行视图

当多个设备完成分布式组网之后，各个设备上的分布式文件系统就可以通过软总线这一分布式设备的通信基座，实现互联，组成一个“虚拟的超级文件系统”。

分布式软总线介绍：
分布式软总线介绍

通过“虚拟的超级文件系统”，各个设备上的应用可以访问存储在其他设备上的分布式文件。我们用现实中的一个例子来做一下类比，帮助大家理解一下：

各个设备就相当于一个孤立的城市。单设备上的本地文件系统相当于这座城市的一个仓库，文件相当于这个仓库内的一些货物。应用就相当于这个城市里的一些工厂。工厂负责将这些货物存储在仓库里面，同时也会从仓库内取出货物并进行加工处理，加工完毕后再存储到这个仓库里。

如上图所示，设备A即城市A，设备B即城市B，app1就是城市A当中的工厂1，负责从城市A的仓库（本地文件系统）中取出货物并进行加工处理和再存储。app1和app2是城市B中的工厂1和工厂2两座工厂。

由于城市A和城市B是相互孤立的，所以城市A中的工厂1不能接触到城市B中的工厂1里面的货物。软总线的出现，就相当在城市A和城市B间建立了公路和铁路，分布式文件系统就相当于依托公路和铁路建立起来的仓库物流系统，有了这个物流系统，城市A和城市B中的工厂就可以协同起来，依靠这个物流系统来进行调度。

如此一来，城市A中的工厂1也可以使用城市B中的工厂1的货物，城市B中的工厂1也可以使用城市A中的工厂1中的货物，这个过程都是由分布式文件系统这个物流系统来进行货物的调度和运输。

有了这个物流系统，城市A的工厂1使用其它城市的货物，就像使用本城市仓库的货物一样简单，因为它屏蔽了底层的差异。

既然文件可以跨设备访问，那么到底如何保证访问安全呢？分布式文件系统已经思考到这一点并提供了完备的安全模型，我们一起来看一下。

分布式文件系统的安全模型

我们都知道，在HarmonyOS的本地文件系统中，应用是在一个独立的沙箱中运行，不同应用的本地文件是分开存放的，都是存在自身的沙箱目录下，相互之间是隔离的，无法互相访问。也就是说，微信不能访问支付宝沙箱里面的文件。

沙箱模型这个安全特性，在分布式文件系统里同样有效。各应用的分布式文件系统也是分开存放的，相互之间也是不能访问的。应用必须通过分布式文件系统提供的专用接口来获取属于自己的沙箱目录，将文件放在沙箱目录里面。应用既不能通过拼接路径的方式将自己的文件放到其他应用的沙箱目录里面，也不能通过拼接路径的方式在没有权限的情况下访问其他应用的分布式沙箱文件。

这就保证分布式文件系统的安全性与本地文件系统的安全性是一致的

如上图所示，同一设备的不同应用间是相互隔离的，因此不能互相访问。如设备A上的app1，由于两个应用之间是隔离的，所以没有权限访问设备A上的app2的分布式目录和分布式文件。

而当多个设备存在相同应用时，它们的沙箱是互通的，也就是说在不同设备上，同一应用的分布式文件视图是一样的，使用的也是同一个分布式的沙箱。就像上面这个图里所示设备A上的app1，与设备B上的app1，它们的沙箱是一样的。因此，设备A上的app1能够同时看到放在自身设备上的file1和放在设备B上的file2，并且能够访问到这两个文件。同样设备B上的app1也能同时访问这两个文件。

需要注意的是这里说的不同设备的相同应用，指的是Bundle Name相同、华为签名相同的应用。如果仅仅是说Bundle Name一样，但是签名不一样，那它们之间的沙箱也是不同的。

这样的做法是为了防止单个设备上的应用被仿冒之后，通过分布式文件系统去访问其他设备上的被仿冒的那个应用的分布式文件。比如说别人写了一个假的微信，Bundle Name跟微信一样，不法分子通过假微信去访问其他设备上真微信的数据。而通过Bundle Name+签名的机制，能从根本上杜绝跨设备仿冒应用的访问。

声明：

本文转自“HarmonyOS开发者”公众号