处理业务数据的方法、装置及系统与流程

1.本公开涉及区块链技术领域，具体涉及一种处理业务数据的方法、装置及系统。


背景技术：

2.区块链技术具有存储的数据不可篡改、去中心化等特点，能够为人们提供非常安全的数据存储环境。因此，区块链业务的发展越来越快。
3.在处理区块链业务的过程中，业务客户端通常会调用业务客户端与业务服务器之间的应用程序接口(application programming interface，api)，从而通过业务服务器将业务数据上链。业务客户端生成的数据除了包括业务数据之外，有时还会包括与业务数据相关的文件数据(如图片、音频、视频等文件数据)。文件数据的数据量通常较大，如果同业务数据一起传输，会占用大量的接口资源，降低区块链业务的处理效率。此外，业务服务器在收到文件数据之后，还需要计算文件数据的哈希摘要(文件数据的数据量大，通常不会直接将文件数据上链，而是将文件数据的哈希摘要上链)，这又进一步降低了区块链业务的处理效率。


技术实现要素：

4.鉴于此，本公开提供一种处理业务数据的方法、装置及系统，以提高区块链业务的处理效率。
5.第一方面，提供一种处理业务数据的方法，所述方法应用于业务系统，所述业务系统包括业务客户端，业务服务器、文件服务器以及区块链，所述方法包括：所述业务客户端生成业务数据以及与所述业务数据相关的文件数据；所述业务客户端将所述文件数据上传至文件服务器；所述业务客户端将所述业务数据和所述文件数据对应的文件标识发送至所述业务服务器；所述文件服务器生成所述文件数据的哈希摘要，所述哈希摘要和文件标识关联；所述业务服务器基于所述文件标识从所述文件服务器获取所述文件数据的哈希摘要；所述业务服务器将所述业务数据和所述文件数据的哈希摘要存储至所述区块链。
6.第二方面，提供一种处理业务数据的方法，所述业务数据由业务客户端生成，所述业务客户端与业务服务器通信，以通过所述业务服务器将所述业务数据存储至区块链，所述方法包括：从所述业务客户端接收业务数据以及与所述业务数据相关的文件数据；将所述文件数据上传至文件服务器，以便所述文件服务器生成所述文件数据的哈希摘要，所述哈希摘要与文件标识关联；将所述业务数据和所述文件数据对应的所述文件标识发送至所述业务服务器，以便所述业务服务器根据所述文件标识从所述文件服务器获取所述文件数据的哈希摘要，并将所述业务数据和所述文件数据的哈希摘要存储至所述区块链。
7.第三方面，提供一种处理业务数据的方法，所述业务数据由业务客户端生成，所述业务客户端与业务服务器通信，以通过所述业务服务器将所述业务数据存储至区块链，所述方法包括：接收所述业务客户端发送的业务数据和文件标识；根据所述文件标识，从文件服务器获取与所述业务数据相关的文件数据的哈希摘要，所述哈希摘要和所述文件标识关
联；向所述业务服务器发送所述业务数据和所述文件数据的哈希摘要，以便所述业务服务器将所述业务数据和所述文件数据的哈希摘要存储至所述区块链。
8.第四方面，提供一种处理业务数据的系统，所述系统包括：业务客户端，用于生成业务数据以及与所述业务数据相关的文件数据；将所述文件数据上传至文件服务器；将所述业务数据和所述文件数据对应的文件标识发送至所述业务服务器；文件服务器，用于生成所述文件数据的哈希摘要，所述哈希摘要和所述文件标识关联；业务服务器，用于基于所述文件标识从所述文件服务器获取所述文件数据的哈希摘要；将所述业务数据和所述文件数据的哈希摘要存储至区块链。
9.第五方面，提供一种处理业务数据的装置，所述业务数据由业务客户端生成，所述业务客户端与业务服务器通信，以通过所述业务服务器将所述业务数据存储至区块链，所述装置包括：接收单元，用于从所述业务客户端接收业务数据以及与所述业务数据相关的文件数据；上传单元，用于将所述文件数据上传至文件服务器，以便所述文件服务器生成所述文件数据的哈希摘要，所述哈希摘要与文件标识关联；发送单元，用于将所述业务数据和所述文件数据对应的所述文件标识发送至所述业务服务器，以便所述业务服务器根据所述文件标识从所述文件服务器获取所述文件数据的哈希摘要，并将所述业务数据和所述文件数据的哈希摘要存储至所述区块链。
10.第六方面，提供一种处理业务数据的装置，所述业务数据由业务客户端生成，所述业务客户端与业务服务器通信，以通过所述业务服务器将所述业务数据存储至区块链，所述装置包括：接收单元，用于接收所述业务客户端发送的业务数据和文件标识；获取单元，用于根据所述文件标识，从文件服务器获取与所述业务数据相关的文件数据的哈希摘要，所述哈希摘要和所述文件标识关联；发送单元，用于向所述业务服务器发送所述业务数据和所述文件数据的哈希摘要，以便所述业务服务器将所述业务数据和所述文件数据的哈希摘要存储至所述区块链。
11.第七方面，提供一种处理业务数据的装置，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器被配置为执行所述可执行代码，以实现如第一方面至第三方面中任意一方面所述的方法。
12.第八方面，提供一种计算机可读存储介质，其上存储有可执行代码，当所述可执行代码被执行时，能够实现如第一方面至第三方面中任意一方面所述的方法。
13.第九方面，提供一种计算机程序产品，包括可执行代码，当所述可执行代码被执行时，能够实现如第一方面至第三方面中任意一方面所述的方法。
14.本公开实施例提供的处理数据的方法中，通过业务客户端将其生成的与业务数据相关的文件数据上传至文件服务器，并由文件服务器生成该文件数据的哈希摘要，由于该文件数据具有文件标识，且该哈希摘要与文件数据的文件标识关联，因此，当业务客户端需要经过业务服务器将业务数据和文件数据存储至区块链时，只需要业务客户端将业务数据和文件数据的文件标识发送给业务服务器，以便业务服务器从文件服务器中获取文件数据的哈希摘要以存储至区块链。这样可以避免相关技术中需要业务客户端和业务服务器之间直接传输文件数据和需要业务服务器将文件数据处理成对应的哈希摘要的过程，从而减少了业务服务器的相关接口的占用资源，能够极大的提高区块链的相关数据的处理效率。
附图说明
15.图1为本公开实施例中的区块链的系统框架示例图。
16.图2为本公开实施例中的处理业务数据的系统框架示例图。
17.图3为本公开一实施例提供的处理业务数据的方法的流程示意图。
18.图4为本公开又一实施例提供的处理业务数据的方法的流程示意图。
19.图5为本公开一实施例提供的处理业务数据的系统的结构示例图。
20.图6为本公开一实施例提供的处理业务数据的装置的结构示例图。
21.图7为本公开又一实施例提供的处理业务数据的装置的结构示例图。
22.图8为本公开另一实施例提供的处理业务数据的装置的结构示例图。
具体实施方式
23.下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本公开一部分实施例，而不是全部的实施例。
24.区块链(blockchain)
25.参见图1，区块链100是一个典型的分布式协同系统。该系统包括多个区块链节点110。该多个区块链节点110可以共同维护一个不断增长的分布式数据记录。这些记录的数据可以通过密码学技术保护内容和时序，使得任何一方难以篡改、抵赖、造假。区块链节点110可以是具有计算能力的设备，例如，服务器、服务器组、区块链芯片等，其中，服务器组可以是集中式的，也可以是分布式的。在另一些实现方式中，上述服务器还可以是为云平台提供服务的服务器。
26.在区块链中，数据(例如，交易信息、交易执行结果等)可以以区块(block)的形式被封装。区块彼此之间可以通过前向的引用彼此链接形成“链”，即区块链。通常，可以将区块链中的第一个区块称为“创始区块”或“初始区块”，将区块链中位于当前区块之前的一个区块称为“上一区块”，将区块链中位于当前区块之后的一个区块称为“后继块”。
27.通常，区块可以包括区块头和区块体。区块头可以包含当前区块的基本信息，用以保证当前区块能正确的进入区块链。例如，区块头可以记录当前区块的上一区块的区块哈希值。又如，区块头还可以记录当前区块的区块高度。区块高度简称“块高”，用来识别区块在区块链中的位置。通常，创始区块的块高为0。区块体可以用于记录交易信息。该交易信息例如可以包括交易数量和交易数据等信息。
28.区块链一般被划分为三种类型：公有链(public blockchain)，私有链(private blockchain)和联盟链(consortium blockchain)。此外，还可以有上述多种类型的结合，比如私有链+联盟链、联盟链+公有链等。本公开所提供的实施方式能够在合适类型的区块链中实现。
29.共识机制
30.共识机制可以理解为区块链中的负责记账的节点(或称记账节点)之间如何达成共识，以认定一个记录的有效性。
31.区块链的共识机制具备“少数服从多数”以及“人人平等”的特点，其中“少数服从多数”并不完全指节点个数，也可以是计算能力、股权数或者其他的计算机可以比较的特征量。“人人平等”是当节点满足条件时，所有节点都有权优先提出共识结果、直接被其他节点
认同后并最后有可能成为最终共识结果。以比特币为例，采用的是工作量证明，只有在控制了全网超过51％的记账节点的情况下，才有可能伪造出一条不存在的记录。当加入区块链的节点足够多的时候，这基本上不可能，从而杜绝了造假的可能。
32.区块链的自信任主要体现于分布于区块链中的用户无须信任交易的另一方，也无须信任一个中心化的机构，只需要信任区块链协议下的软件系统即可实现交易。这种自信任的前提是区块链的共识机制，即在一个互不信任的市场中，要想使各节点达成一致的充分必要条件是每个节点出于对自身利益最大化的考虑，都会自发、诚实地遵守协议中预先设定的规则，判断每一笔记录的真实性，最终将判断为真的记录记入区块链之中。换句话说，如果各节点具有各自独立的利益并互相竞争，则这些节点几乎不可能合谋欺骗你，而当节点们在网络中拥有公共信誉时，这一点体现得尤为明显。区块链技术正是运用一套基于共识的数学算法，在机器之间建立“信任”网络，从而通过技术背书而非中心化信用机构来进行全新的信用创造。
33.区块链的共识机制例如可以是以下共识机制中的一种：工作量证明机制(proof of work，pow)、权益证明机制、股份授权证明机制、验证池机制以及实用拜占庭容错(practical byzantine fault tolerance，pbft)。
34.在互联网信息高度发达的今天，数据的巨大价值越来越被更多的人认可。而如何将这些数据安全快速的保存下来成为了行业内的一个大问题。如前面所述，区块链的共识机制和其去中心化、安全、公开的特性给数据安全的存储带来了可能。将数据保存到区块链的过程，称之为数据上链。
35.待上链的数据由业务客户端(或者称为用户客户端)生成，其类型不仅包括业务客户端系统处理产生的业务数据，还包括与业务数据相关的文件数据。该文件数据例如可以包括与现实场景相关联的图片、音频、视频等数据中的一种或多种。文件数据一般具有数据量大、数量多的特点。当文件数据上链时，会遇到以下两方面的问题。一方面，文件数据和业务数据是两种不同的数据类型，其传输服务不同，传输需求也不同，那么如何将业务数据和文件数据一起传输至业务服务器，成为文件数据上链一个重要的问题。另一方面，区块链采用的是分布式存储技术，文件数据直接上链会给区块链的空间带来非常大的压力，那么业务服务器如何获取文件数据并上链也是文件数据上链中一个重要的问题。另外，在文件数据传输过程中还要考虑如何防止文件恶意传输，也就是如何防止不合适的用户、不合适的内容对业务接口的滥用的问题。
36.图2为一种处理业务数据的系统框架示例图。下面结合图2，对相关技术中处理业务数据的方法及其存在的问题进行更为详细的举例说明。
37.如图2所示，该系统可以包括业务客户端210、业务服务器220和区块链230。业务客户端210和业务服务器220之间进行业务数据传输的交互，业务服务器220到区块链230完成业务数据上链过程。区块链230例如可以是图1中描述的区块链100。
38.业务客户端210的系统处理产生的数据包含业务数据以及与业务数据有关的文件数据。文件数据例如可以是图片、视频、音频以及合同、发票等数据中的一种或多种。
39.由于区块链230一般不能直接暴露给用户使用，因而业务客户端210不能直接与区块链230进行数据交互。当业务客户端210需要将其生成的数据存储到区块链230时，要先将数据传输给业务服务器220，经过业务服务器220对数据进行处理后，上传至区块链230进行
存储。该过程即为数据上链过程。由此可见，数据上链过程可以包括上链前准备阶段和上链阶段。例如，业务客户端210和业务服务器220之间的数据传输以及业务服务器220对数据的处理属于上链前准备阶段，业务服务器220将处理好得数据存储到区块链230属于上链阶段。
40.业务客户端210和业务服务器220之间的数据传输交互，实质上是通过调用api接口实现的。业务客户端210通过调用业务服务器220为其提供的api接口服务，将数据发送到业务服务器220，同时业务服务器220也是通过调用api接口服务对所接收到数据进行处理的。
41.作为一个实施例，参照图2的实现场景，对业务客户端210将其生成的包含业务数据及与业务数据相关的文件数据一同存储至区块链230的具体过程进行详细的描述。
42.步骤s211，业务客户端对文件数据进行编码。
43.业务客户端210系统生成业务数据及与业务数据相关的文件数据，该文件数据例如可以包括与现实场景相关联的图片、音频、视频等数据中的一种或多种。业务客户端210首先要对该文件数据进行编码，例如，将文件数据编码转换成为适合传输的格式。业务客户端210的编码过程是通过调用api接口服务实现的。
44.步骤s212，业务客户端将编码后的文件数据和业务数据发送给业务服务器。
45.业务客户端210完成对文件数据的编码后，将编码后的文件数据作为业务数据的一部分一同传输给业务服务器220。
46.如前面描述，业务客户端210与业务服务器220之间的数据交互是通过调用api接口服务实现的。而传统的api接口设计为了具有较快的响应，对其传输的数据大小和数量是有所限制的，过大或过多的数据都会影响api接口的处理效率。因此，该过程对业务客户端210发送的文件数据会有所限制，不能太大，也不能太多。另外，文件数据同业务数据一同传输会占用大量的接口资源，从而降低了业务接口的处理效率。
47.步骤s221，业务服务器对文件数据解码、内容风控、保存、计算文件哈希摘要。
48.业务服务器220在接收到业务客户端210传输的业务数据和编码后的文件数据后，首先对文件数据进行解码，得到原文件数据。然后，对文件数据的内容进行风险控制。例如通过检查文件数据是否完整、是否适合上链、是否涉及不合法或不合规的信息等。接着，将文件数据保存到存储介质上。该存储介质例如可以是存储设备。最后，计算文件数据的哈希摘要。
49.如前面介绍，区块链采用的是分布式存储技术，文件数据直接上链会给区块链的空间带来很大的压力。因此，通过计算出文件数据的哈希摘要，将哈希摘要上链来解决。文件的哈希摘要例如可以通过哈希函数得到。哈希摘要实质上相当于一种加密算法，从文件数据中提取出的一小段信息。同样的一段数据通过哈希函数总是能得到相同的摘要。例如，可以通过事后验证哈希摘要是否一致来验证数据的完整性。
50.在该过程中，业务服务器220对文件数据进行解码、内容风控、保存、计算哈希摘要等处理都是通过调用api接口实现的。这样，api接口涉及的业务太多，给其带来非常大的压力，从而降低了业务接口的处理效率。
51.步骤s222，业务服务器将业务数据和文件数据的哈希摘要存储到区块链。
52.业务服务器220将其计算得到的文件数据的哈希摘要和业务数据一同发送至区块
链进行存储，完成数据上链过程。文件哈希摘要上链减轻区块链的空间压力，提高传输效率。
53.通过上述图2的实现过程可以看出，业务客户端210通过调用api接口服务将文件数据和业务数据一同传输到业务服务端220。但由于文件数据的数据量通常较大，导致该过程会占用大量的接口资源，从而降低了区块链业务的处理效率。另外，业务服务器220接收到文件数据后还要进行例如计算文件哈希摘要等一系列的处理后，才能存储至区块链230，这又进一步降低了区块链业务的处理效率。
54.又如，版权存证过程。ip版权的版权库(即文件数据)包含高清视频和图片，版权库的大小例如可以到达5g左右。用户(即业务客户端210)要将该版权库保存至区块链，即完成数据上链。首先，将版权库上传到公共云盘。公共云盘会为用户提供一个链接地址，例如可以是公共的统一资源定位器(uniform resource locator，url)地址。用户将公共的url地址和版权库相关信息一起传给区块链后端的业务服务器(即业务服务器220)。业务服务器根据公共的url地址对版权库进行下载，然后计算其哈希摘要，再将哈希摘要进行上链。
55.在上述过程中，业务服务器需要对版权库进行下载，下载后还要对版权库进行校验、保存和计算文件哈希摘要等处理。该过程中用户(即业务客户端210)与业务服务器之间虽然没有进行文件数据的传输，但是类似于图2实现场景中的步骤s221，业务服务器220的api接口要完成对文件数据的处理，就会影响其接口的处理效率和响应速度。另外，该过程复杂，使用公共云盘还存在一定的安全隐患。
56.综上，针对上链数据中包含文件数据时，亟需一种能够提高区块链业务的处理效率的方法。
57.为了解决上述问题，本公开实施例提出一种处理业务数据的方法，该方法不但能够提高区块链业务的处理效率，且对传输的文件数据的大小和数量不限制，另外，该方法还具有实现简单、安全性高的特点。
58.图3是本公开一实施例提供的处理业务数据的方法的流程示意图。下面结合图3，对本公开实施例进行详细的介绍说明。
59.图3的方法由业务客户端、业务服务器、文件服务器以及区块链执行。业务客户端例如可以是图2中描述的业务客户端210。业务服务器例如可以是图2中描述的业务服务器220。区块链例如可以是图2中描述的区块链230。文件服务器310是用于专门处理和传输文件数据的服务器。
60.在步骤s311，业务客户端生成业务数据以及与业务数据相关的文件数据。
61.业务客户端210例如可以是用户的手机、电脑等其他类型的计算机设备，其系统生成的数据可以是单纯的业务数据，也可以是业务数据以及与业务数据相关的文件数据。作为一个实施例，该文件数据包括以下中的至少一种：图片、音频和视频。例如，高清图片、高清视频等。
62.业务客户端210例如可以包含其上集成的软件开发工具包(software development kit，sdk)。sdk负责数据的传输和处理。也就是说，业务客户端210与业务服务器220之间的数据传输可以通过sdk实现，例如，通过sdk提供api接口实现。sdk可以提供多种不同的api接口服务。业务客户端210将生成的业务数据以及与业务数据相关的文件数据发送给其上集成的sdk，由sdk完成接下来的相关操作。
63.相比于图2的场景，业务客户端210不需要再对文件数据进行编码操作，从而提高了区块链业务的处理效率。
64.在步骤s312，业务客户端将文件数据上传至文件服务器，以便文件服务器生成文件数据的哈希摘要。
65.文件服务器310可以是任何类型的服务器设备。作为一个实施例，在业务客户端210将文件数据上传至文件服务器310之前，会先向文件服务器310发送请求消息，文件服务器310接收到请求消息后，对业务客户端210进行验证。例如可以是身份验证和/或权限验证，如验证业务客户端210是否为授权的身份和/或权限。
66.文件服务器310对业务客户端210的身份和/或权限验证无误后，会向业务客户端210返回一个上传路径。上传路径可以由文件服务器310生成，例如上传路径可以是文件服务器310在接收到业务客户端210的请求后，为业务客户端210提供的一个的网络传输通道，如基于tcp/i协议的网络通道，以便业务客户端210通过该网络通道将文件数据传输至文件服务器310。上传路径也可以是由文件服务器310为业务客户端210提供的一个接口服务，业务客户端210通过该接口将文件数据上传至文件服务器310。业务客户端210在接收到返回的上传路径后，将文件数据按照该上传路径上传到文件服务器310。例如，业务客户端210可以通过调用sdk实现文件数据上传至文件服务器310。
67.具体地，文件数据和业务数据是两种不同的数据类型，其传输服务也是不同的。例如图2实现场景中，文件数据和业务数据是使用同一个api接口服务进行传输的，从而降低了该接口的处理效率。本公开实施例为传输文件数据和传输业务数据提供了不同的接口服务。例如，业务客户端210上的sdk可以提供不同的接口服务。业务客户端210调用sdk服务实现将文件数据上传至文件服务器310。文件服务器310专门负责对文件数据的传输和处理，其只关注是否能够完整接收文件数据，不关注传输的数据对带宽和资源的占用，也不会限制其传输数据的大小和数量。因此，本公开解决了传统文件数据传输过程中，文件数据对业务接口处理效率的影响，以及接口对文件数据的大小和数量的限制的问题。
68.作为一个实施例，文件服务器310在接收到业务客户端210上传的文件数据后，会对文件数据进行处理。例如，文件服务器310收到文件数据后，可以对文件数据的内容进行校验。如可以是内容风控，以保证接受到的文件数据是合规、合法的。也可以是数据校验，以保证接收到的文件数据与业务客户端发送的文件数据是一致的。如果文件数据通过校验，文件服务器310还可以对文件数据进行相关处理，例如，可以是对文件数据的压缩、格式转换等。其次，将文件数据保存到存储介质上。最后，文件服务器310计算文件数据的哈希摘要。该过程虽然类似于图2中的步骤s221，但是相比于步骤s221中由业务服务器220对文件数据进行内容风控、保存、计算哈希摘要等处理，本公开实施例中关于文件数据的所有处理过程都是由文件服务器310完成的。业务客户端210和业务服务器220之间只进行业务数据和文件标识的传输，从而提高了区块链业务的处理效率。
69.在步骤s313，业务客户端将业务数据和文件数据对应的文件标识发送至业务服务器，以便业务服务器根据文件标识从文件服务器获取文件数据的哈希摘要。
70.参照图2的步骤s212，业务客户端210是将编码后的文件数据和业务数据发送到业务服务器220。文件数据和业务数据的一同传输，会占用大量的接口资源，需要持续占用带宽，影响业务接口的处理效率和吞吐性能。本公开实施例中业务客户端210和业务服务器
220之间只需要传输业务数据和文件标识，而文件标识的报文体积很小，不会占用太多的接口资源，因此大大地提升了接口处理效率和吞吐性能。作为一个实施例，这里的文件标识可以由文件服务器310分配，也可以由业务客户端210自定义。本公开对文件标识的来源不做限定，只要文件标识能够在文件服务器310中准确定位到文件数据。
71.作为一个实施例，业务服务器220在接收文件标识后，根据文件标识向文件服务器310发起获取处理和校验结果的请求消息，文件服务器310验证请求无误后，将会向业务服务器220返回文件路径和文件哈希摘要。作为另一个实施例，业务服务器220如果需要对文件数据进行进一步处理，可以通过文件路径在文件服务器310上下载该文件数据。同理，文件服务器310与业务服务器220之间文件数据的传输不会影响接口的处理效率和吞吐性能。
72.在步骤s314，文件服务器生成文件数据的哈希摘要，所述哈希摘要和文件标识关联。
73.参照图2的实现场景中的步骤s221，文件数据的哈希摘要是由业务服务器220生成的，对业务服务器220的api接口的处理效率会有影响。本公开实施例由文件服务器310完成文件数据的哈希摘要计算，为业务服务器220减轻了业务接口压力，提高接口的处理效率。
74.文件服务器生成的哈希摘要与文件标识是相关联的，也就是说，可以通过文件数据对应的文件标识从文件服务器上获取到该文件数据的哈希摘要。
75.在步骤s315，业务服务器基于文件标识从文件服务器获取文件数据的哈希摘要。
76.业务服务器220例如可以是区块链后端的服务器设备，如可以是网关设备。作为一个实施例，业务服务器220在接收到业务客户端210发送来的业务数据和文件标识后，根据文件标识，向文件服务器310发送请求消息获取文件数据的处理和校验结果。文件服务器310接收到请求消息后，通过对业务服务器220的身份和/权限验证无误后，会向业务服务器返回文件数据的路径和文件数据的哈希摘要。
77.在步骤s316，业务服务器将业务数据和文件数据的哈希摘要存储至区块链。
78.业务服务器220接收到业务数据和文件数据的文件哈希摘要，进行业务处理后，将业务数据和文件数据的哈希摘要存储到区块链230。
79.作为一个实施例，如果业务客户端210生成的业务数据只有单纯的业务数据，不包含与其业务数据相关的文件数据，业务客户端210可以直接将业务数据发送给业务服务器220，由业务服务器220直接存储至区块链230中。
80.作为另一个实施例，例如版权存证，可以参照图4的场景实现。图4是本公开又一实施例提供的处理业务数据的方法的流程示意图。
81.图4包括业务客户端，例如可以是前面描述的业务客户端210，业务客户端210上集成了sdk，例如可以是数据发送器420。业务服务器，例如可以是前面描述的业务服务器端220，业务服务器端220上集成了sdk，如可以是数据接收送器430。区块链，例如可以是前面描述的区块链230。文件服务器，例如可以是前面描述的专门用于处理和传输文件数据的文件服务器310。下面参照图4对版权库存证过程进行详细的描述。
82.步骤s401，业务客户端210将生成的版权库(即业务数据和文件数据)发送到数据发送器420；步骤s402，数据发送器420向文件服务器310获取文件上传路径；步骤s403～s404，文件服务器310对数据发送器420的身份和权限进行认证；步骤s405，认证通过后，文件服务器310向数据发送器420返回上传路径和文件标识；步骤s406，数据发送器420根据文
件上传路径将版权库上传至文件服务器310；步骤s407～s410，文件服务器310对版权库完成内容校验、文件处理、计算文件哈希摘要、保存文件到存储介质等操作；步骤s411，数据发送器420将业务数据和文件标识发送至数据接收送器430；步骤s412，数据接收送器430接收到文件标识后，根据文件标识向文件服务器310获取版权库的处理和校验结果；步骤s413，文件服务器310向数据接收送器430返回文件路径和文件哈希摘要；步骤s414，数据接收送器430将业务数据和文件哈希摘要发送给业务服务器220；步骤s415，业务服务器220对业务数据和哈希摘要进行业务处理，例如是文件压缩等；步骤s416，业务服务器220将业务处理后的数据存储到区块链230，完成版权库数据的上链过程。
83.综上，本公开实施例为文件数据的传输和处理提供了专门的文件服务器，因此，对区块链业务的处理效率不会有影响，且对文件数据的大小和数量不会有所限制。同时，业务客户端和业务服务器之间只完成业务数据和文件标识的传输，提升了业务接口的处理效率和吞吐性能。此外，相比于相关技术，本公开提供的技术方案还具有实现简单、安全性高的优点。
84.上文结合图3至图4详细描述了本公开提供的处理业务数据的方法实施例，下面结合图5详细描述本公开提供的装置实施例。应理解，方法实施例的描述与系统实施例的描述相互对应，因此，未详细描述的部分可以参考前面方法实施例。
85.图5是本公开一实施例提供的处理业务数据的系统的结构示例图。图5的处理业务数据的系统500包括业务客户端510(例如可以是前面描述的业务客户端210)、文件服务器520(例如可以是前面描述的文件服务器310)、业务服务器530(例如可以是前面描述的业务服务器220)和区块链540(例如可以是前面描述的区块链230)。
86.业务客户端510，可用于生成业务数据以及与所述业务数据相关的文件数据。将所述文件数据上传至文件服务器520；将所述业务数据和所述文件数据对应的文件标识发送至所述业务服务器。
87.文件服务器520，可用于生成所述文件数据的哈希摘要，哈希摘要和文件标识关联。
88.业务服务器530，用于基于文件标识从所述文件服务器获取所述文件数据的哈希摘要；将所述业务数据和所述文件数据的哈希摘要存储至区块链540。
89.可选地，所述业务客户端将所述文件数据上传至文件服务器，包括：所述业务客户端向所述文件服务器发送请求消息，以获取所述文件数据的上传路径；所述业务客户端根据所述上传路径将所述文件数据上传至所述文件服务器。
90.可选地，在所述业务客户端将所述文件数据上传至文件服务器之前，所述方法还包括：所述文件服务器用于对所述业务客户端的身份和/或权限进行验证。
91.可选地，所述文件服务器用于对所述文件数据的内容进行校验；如果所述文件数据的校验通过，所述文件服务器存储所述文件数据。
92.可选地，所述文件标识由所述文件服务器分配。
93.可选地，所述文件数据包括以下中的至少一种：图片、音频和视频。
94.图6是本公开一实施例提供的处理业务数据的装置的结构示例图。图6中所示的处理业务数据的装置600可以包括接收单元610、上传单元620及发送单元630。
95.接收单元610，可以用于所述业务客户端接收业务数据以及与所述业务数据相关
的文件数据。
96.上传单元620，可以用于将所述文件数据上传至文件服务器，以便所述文件服务器生成所述文件数据的哈希摘要，哈希摘要和文件标识关联。
97.发送单元630，可以用于将所述业务数据和所述文件数据对应的文件标识发送至所述业务服务器，以便所述业务服务器根据所述文件标识从所述文件服务器获取所述文件数据的哈希摘要，并将所述业务数据和所述文件数据的哈希摘要存储至所述区块链。
98.图7是本公开又一实施例提供的处理业务数据的装置的结构示例图。图7所述的处理业务数据的装置700包括接收单元710、获取单元720、发送单元730。
99.接收单元710，可以用于接收所述业务客户端发送的业务数据和文件标识。
100.获取单元720，可以用于根据所述文件标识，从文件服务器获取与所述业务数据相关的文件数据的哈希摘要，哈希摘要和文件标识关联。
101.发送单元730，可以用于向所述业务服务器发送所述业务数据和所述文件数据的哈希摘要，以便所述业务服务器将所述业务数据和所述文件数据的哈希摘要存储至所述区块链。
102.图8是本公开另一实施例提供的处理业务数据的装置的结构示例图。图8所示的装置800例如可以是具有计算功能的计算设备。比如，装置800可以是移动终端或者服务器。装置800可以包括存储器810和处理器820。存储器810可用于存储可执行代码。处理器820可用于执行所述存储器810中存储的可执行代码，以实现前文描述的各个方法中的步骤。在一些实施例中，该装置800还可以包括网络接口830，处理器820与外部设备的数据交换可以通过该网络接口830实现。
103.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其他任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本公开实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如，软盘、硬盘、磁带)、光介质(例如数字视频光盘(digital video disc，dvd))、或者半导体介质(例如固态硬盘(solid state disk，ssd))等。
104.本领域普通技术人员可以意识到，结合本公开实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。
105.在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以
通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
106.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
107.另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
108.以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。