用于处理文件的服务方法、系统、电子设备和存储介质

技术领域

本发明涉及文件传输技术领域，尤其涉及一种用于处理文件的服务方法、系统、电子设备和存储介质。

背景技术

随着系统复杂度的提升，对系统扩展性的要求也越来越高。然而传统的单一架构模式，由于不具备稳定性和高可用性，业务和功能糅合性及其严重，不再适用于敏捷开发，任何开发的人员都不能完全理解，因此在修复漏洞和添加新功能时，变得复杂，不易维护；且模块越大，启动越慢，小的改动也需要部署整个项目；对于新的技术框架融入极其不易。

因此，如何让业务和功能进行分离，以满足松耦合、敏捷开发和快速迭代部署的需求，已经成为目前本领域技术人员亟待解决的问题。

发明内容

为了解决上述问题，第一方面，本发明实施例提供一种用于处理文件的服务方法，包括：接收文件上传请求，获得文件；对所述文件生成文件ID，并存储所述文件；反馈所述文件的存储信息，所述存储信息包含所述文件ID；接收文件处理请求，该文件处理请求携带所述文件ID，处理与所述文件ID对应的所述文件，并反馈处理结果。

可选的，所述的存储所述文件，具体为：将所述文件的基本信息、存储路径和所述文件ID存入结构型数据库。

可选的，所述文件处理请求包括更新请求、删除请求和访问请求中的至少一种请求。

可选的，所述的接收文件处理请求，该文件处理请求携带所述文件ID，处理所述文件ID对应的所述文件，包括：接收文件处理请求，该文件处理请求携带所述文件ID；过滤所述文件处理请求；针对过滤后的请求，根据请求内容和所述文件ID生成文件对象；对所述文件对象进行处理。

可选的，所述文件处理请求为Http请求，所述的过滤所述文件处理请求，包括：过滤Token未通过认证的所述Http请求；过滤Header不满足RFC2047规则的所述Http请求。

可选的，所述请求内容包括文件的内容、文件的名称、文件的存储路径、应用的ClientId、用户的Token和请求的路径。

可选的，所述的对所述文件生成文件ID，具体为：根据所述文件的类型和上传时间，利用Instant的Seconds和Nanos两个属性值以及所述类型后缀自动拼装成文件ID。

第二方面，本发明实施例提供一种用于处理文件的服务系统，包括应用终端和服务端，其中，所述应用终端用于发送文件上传请求和文件处理请求；所述服务端用于接收所述文件上传请求，获得文件；对所述文件生成文件ID，并存储所述文件；向所述应用终端反馈所述文件的存储信息，所述存储信息包含所述文件ID；接收所述文件处理请求，该文件处理请求携带所述文件ID，处理与所述文件ID对应的所述文件，并向所述应用终端反馈处理结果。

第三方面，本发明实施例提供一种电子设备，包括处理器和存储有计算机程序的存储介质，所述计算机程序被所述处理器执行时实现上述任一项所述的用于处理文件的服务方法。

第四方面，本发明实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任一项所述的用于处理文件的服务方法。

根据上述内容，本发明实施例的用于处理文件的服务方法包括：接收文件上传请求，获得文件；对所述文件生成文件ID，并存储所述文件；反馈所述文件的存储信息，所述存储信息包含所述文件ID；接收文件处理请求，该文件处理请求携带所述文件ID，处理与所述文件ID对应的所述文件，并反馈处理结果。能够将与文件相关的操作独立成一个服务，每个不同的应用可以通过文件服务实现不同需要的文件操作，极大的简化了单体应用的复杂性，将业务和功能进行解耦合；同时也为文件提供统一的管理和维护接口，不同应用上的文件可以通过文件服务实现统一的维护，极大的简化了升级和维护的成本。

附图说明

图1是本发明实施例1的用于处理文件的服务方法的流程示意图；

图2是本发明实施例2的应用和文件服务的交互流程示意图；

图3是本发明实施例2的用于处理文件的服务系统的结构示意图；

图4是本发明实施例3的电子设备的结构示意图。

具体实施方式

本申请的发明人考虑到微服务架构中，每个微服务都是独立部署的，由于松耦合关系，可快速迭代，有效的将业务和功能分离，更有利于维护，更符合敏捷开发的模式。而文件作为网络信息的重要载体的一部分，如何利用文件服务来管理文件，有着重要的存在的意义。本发明实施形态中，需要对业务和功能进行分离，将功能进行模块化处理，一个服务能够接入多个应用同时使用，统一在文件服务里面维护与文件相关的操作，而传统的单一架构模式并不支持这种需求。

以下将结合附图，对本发明进行更为详细的描述，需要说明的是，以下参照附图对本发明进行的描述仅是示意性的，而非限制性的。各个不同实施例之间可以进行相互组合，以构成未在以下描述中示出的其他实施例。

实施例1

请参阅图1所示，本实施例的用于处理文件的服务方法，包括以下流程：

S1：接收文件上传请求，获得文件；

S2：对所述文件生成文件ID，并存储所述文件；

S3：反馈所述文件的存储信息，所述存储信息包含所述文件ID；

S4：接收文件处理请求，该文件处理请求携带所述文件ID，处理与所述文件ID对应的所述文件，并反馈处理结果。

通过上述内容，能够将与文件相关的操作独立成一个服务，每个不同的应用可以通过文件服务实现不同需要的文件操作，极大的简化了单体应用的复杂性，将业务和功能进行解耦合；同时也为文件提供统一的管理和维护接口，不同应用上的文件可以通过文件服务实现统一的维护，极大的简化了升级和维护的成本。

基于上述原理，应用可以通过接口向文件服务(例如服务端)发送请求，文件服务过滤应用的请求，然后处理应用的请求，并返回处理结果给应用。

例如，当应用向文件服务接口发送上传请求、更新请求、删除请求或访问请求中的至少一种请求，文件服务根据请求的Token，请求认证中心进行认证权限，并通过Header所设置的方法，对请求进行过滤，然后对过滤后的请求进行处理。那么应用可以上传文件资源至文件服务，文件服务处理文件资源并返回文件ID；然后应用可以根据文件ID从文件服务获取文件资源，也可以根据文件ID修改文件服务中的文件资源，还可以根据文件ID删除文件服务中的文件资源。能够根据实际应用场景，对文件访问进行控制，以实现对文件及文件路径的增、删、改、查操作，从而完成文件资源隔离和文件的读写。

作为一个示例，所述的存储所述文件，具体为：将所述文件的基本信息、存储路径和所述文件ID存入结构型数据库。

作为一个示例，所述文件处理请求包括更新请求、删除请求和访问请求中的至少一种请求。

作为一个示例，所述的接收文件处理请求，该文件处理请求携带所述文件ID，处理所述文件ID对应的所述文件，包括：接收文件处理请求，该文件处理请求携带所述文件ID；过滤所述文件处理请求；针对过滤后的请求，根据请求内容和所述文件ID生成文件对象；对所述文件对象进行处理。

作为一个示例，所述文件处理请求为Http请求，所述的过滤所述文件处理请求，包括：过滤Token未通过认证的所述Http请求；过滤Header不满足RFC2047规则的所述Http请求。

作为一个示例，所述请求内容包括文件的内容、文件的名称、文件的存储路径、应用的ClientId、用户的Token和请求的路径。

作为一个示例，所述的对所述文件生成文件ID，具体为：根据所述文件的类型和上传时间，利用Instant的Seconds和Nanos两个属性值以及所述类型后缀自动拼装成文件ID。

实施例2

请参阅图2和图3所示，本实施例提供了一种用于处理文件的服务系统，可以作为远程的文件服务中台系统，旨在实现对文件的操作进行统一口径处理，相比于传统单体应用，通过文件微服务部署，实现业务和功能的解耦，所有和文件相关的操作都在文件服务(即服务端)进行，且适用于各种应用终端的所有文件操作。除此之外，通过对文件的归一化处理，能根据需求进行应用升级，功能业务的分离，更有益于实际生产中的运维。

作为一个示例，当应用终端通过接口向文件服务发送请求，文件服务过滤请求，具体包括了如下步骤：应用终端根据实际需求向文件服务发送Http请求和请求体；文件服务过滤Http请求和请求体，生成一个文件对象。

优选地，Http请求和请求体包括了文件的内容、文件的名称、文件存储的路径、应用的ClientId、用户的Token和请求的路径等等，这些请求内容可以根据当前的业务需求来指定。

优选地，上述文件服务过滤Http请求和请求体，包括以下步骤：判断请求体所携带的参数和方法是否有效，若有效，则将请求体的内容拼装成用户对象；若无效，则返回“错误”信息至应用终端。

上述的请求体所携带的参数包括了常见的Header所具备的一些属性和常见的方法，例如包括了GET,POST,PUT,DELETE,OPTIONS的方法。

优选地，上述文件服务过滤Http请求和请求体，还包括了以下步骤：

判断请求中用户的Token是否通过认证中心的认证，若通过，则得到应用终端的基本信息；若未通过，则返回“未认证”信息给应用终端。还可以判断请求的Header是否满足RFC2047规则，若满足，则文件服务对请求进行处理；若不满足，将返回“不符合RFC2047规则”信息给应用终端。

优选地，存储文件的流程，包括以下步骤：生成文件的名称及文件的存储路径；将文件对象的信息写入结构化数据库；将文件的资源上传至存储介质。

具体地，如图2所示，应用终端向文件服务接口发送请求，文件服务预处理，解析该请求，提取预处理必要的信息，根据预处理的结果，从结构化数据库中获取已经生成文件的存储路径，根据文件对象信息，提取文件所在的存储介质中持久化的路径，提取文件的后缀，根据当前时间，使用NanoTimes的NanoTimestamp属性值生成此文件唯一的替代名称(即文件ID)，用于避免持久化介质中文件重名的情况。针对上传的文件资源，将生成的文件信息持久化到存储介质中。

在上传文件资源的过程中，可以判断文件ID是否为零；若是，则返回“错误”信息给应用终端，以提示上传文件错误；若否，则将文件资源持久化处理。作为一个示例，各种文件资源可以由各应用终端上传至服务端例如公有云和/或私有云(如图3所示)，也可以上传至当前机器(例如当前机器为服务端)的存储介质。

本实施例所使用的持久化存储介质包括但不限于本地磁盘存储、阿里云OSS存储、华为SFS弹性文件服务以及自定义云存储。

以阿里云OSS的存储介质为例，通过文件服务自启动时候初始化的阿里云私有桶和公有桶的配置，并生成AliyunOSSUtils存储通用对象信息，包括了endpoint、accessKeyId、accessKeySecret、bucketName和bucketName实例变量。

例如，根据应用终端发送的请求，将文件存放如指定的桶内，提供对外访问的接口，包括了不需要认证的公有桶和需要带私钥认证的私有桶这两种方式。

根据文件上传和持久话数据库的结果，将生成的文件对象返回给应用，该文件对象包含文件ID，从而能够通过文件服务来控制与文件操作相关的业务。

实施例3

本实施例提供一种电子设备的结构示意图，如图4所示，该电子设备包括处理器310、存储器320、输入装置330和输出装置340；计算机设备中处理器310的数量可以是一个或多个，图3中以一个处理器310为例；电子设备中的处理器310、存储器320、输入装置330和输出装置340可以通过总线或其他方式连接，图3中以通过总线连接为例。

存储器320作为一种计算机可读存储介质，可用于存储软件程序、计算机可执行程序以及模块，如本发明实施例中的可配置化数据传输及监控方法对应的程序指令/模块。处理器310通过运行存储在存储器320中的软件程序、指令以及模块，从而执行电子设备的各种功能应用以及数据处理，即实现实施例1的可配置化数据传输及监控方法。

存储器320可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据终端的使用所创建的数据等。此外，存储器320可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件。在一些实例中，存储器320可进一步包括相对于处理器310远程设置的存储器，这些远程存储器可以通过网络连接至电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

输入装置330可用于获取任务配置信息，输出装置340可用于输出并显示日志信息。

本实施例的电子设备能够实现本发明任一种实施例的用于处理文件的服务方法。

实施例4

本实施例提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于实现一种用于处理文件的服务系统方法，该方法包括：

应用通过接口向文件服务发送请求，文件服务过滤应用的请求；

文件服务处理应用请求，返回处理结果给应用。

当然，本发明实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的方法操作，还可以执行本发明任意实施例所提供的一种惯用语处理文件的服务系统中的相关操作。

通过以上关于实施方式的描述，所属领域的技术人员可以清楚地了解到，本发明可借助软件及必需的通用硬件来实现，当然也可以通过硬件实现，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如计算机的软盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(RandomAccess Memory，RAM)、闪存(FLASH)、硬盘或光盘等，包括若干指令用以使得一台电子设备(可以是手机，个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的用于处理文件的服务方法。

对本领域的技术人员来说，可根据以上描述的技术方案以及构思，做出其它各种相应的改变以及形变，而所有的这些改变以及形变都应该属于本发明权利要求的保护范围之内。