数据传输方法、装置、设备、介质及产品

技术领域

本申请属于大数据处理技术领域，尤其涉及一种数据传输方法、装置、设备、介质及产品。

背景技术

大数据平台的各类跨中心源数据的统一数据采集，以及跨中心、跨异构集群之间的多种类型数据交换共享是业务中非常重要的一步，也是保障日常业务运行的一项重要日常工作。

在大数据认证领域中，Kerberos是一种计算机网络授权/认证协议，它允许某实体在非安全网络环境下通信，向另一个实体以一种安全的方式证明自己的身份。

相关技术中，在跨Kerberos认证的数据交换场景下，通常采用中间件或文件存储系统中转的方式进行数据传输。

然而，通过中间件和文件存储系统中转的方式进行数据传输，增加了数据传输系统的复杂度，数据传输系统的可维护性和可用性较差。

发明内容

本申请实施例提供一种数据传输方法、装置、设备、介质及产品，能够解决数据传输系统复杂度高、可维护性和可用性较差的问题。

第一方面，本申请实施例提供一种数据传输方法，包括：

获取基于Kerberos协议的两个计算机集群的认证配置文件；

根据认证配置文件，确定数据传输方式；

根据数据传输方式，在两个计算机集群之间传输数据。

第二方面，本申请实施例提供一种数据传输装置，包括：

获取模块，用于获取基于Kerberos协议的两个计算机集群的认证配置文件；

确定模块，用于根据认证配置文件，确定数据传输方式；

传输模块，用于根据数据传输方式，在两个计算机集群之间传输数据。

第三方面，本申请实施例提供一种电子设备，该电子设备包括：处理器以及存储有计算机程序指令的存储器；处理器执行计算机程序指令时实现第一方面的数据传输方法。

第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现第一方面的数据传输方法。

第五方面，本申请实施例提供了一种计算机程序产品，计算机程序产品中的指令由电子设备的处理器执行时，使得电子设备执行如第一方面的数据传输方法。

在本申请实施例中，通过获取基于Kerberos协议的两个计算机集群的认证配置文件；根据认证配置文件，确定数据传输方式；根据数据传输方式，在两个计算机集群之间传输数据。如此，能够在两个计算机集群之间以所确定的数据传输方式传输数据，无需中间件和文件存储系统，降低了数据传输系统的复杂度，提高了数据传输系统的可维护性和可用性。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单的介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的数据传输方法的流程示意图；

图2是本申请实施例提供的比较逻辑的示意图；

图3是本申请实施例提供的数据传输装置的结构示意图；

图4是本申请实施例提供的电子设备的结构示意图。

具体实施方式

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本申请，而不是限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的数据传输方法、装置、设备、介质及产品进行详细地说明。

图1是本申请实施例提供的数据传输方法的流程示意图。如图1所示，数据传输方法可以包括：

步骤101：获取基于Kerberos协议的两个计算机集群的认证配置文件；

步骤102：根据认证配置文件，确定数据传输方式；

步骤103：根据数据传输方式，在两个计算机集群之间传输数据。

上述各个步骤的具体实现方式将在下文中进行详细描述。

在本申请实施例中，通过获取基于Kerberos协议的两个计算机集群的认证配置文件；根据认证配置文件，确定数据传输方式；根据数据传输方式，在两个计算机集群之间传输数据。如此，能够在两个计算机集群之间以所确定的数据传输方式传输数据，无需中间件和文件存储系统，降低了数据传输系统的复杂度，提高了数据传输系统的可维护性和可用性。

在本申请实施例的一些可能实现中，本申请实施例中的认证配置文件可以为krb5.conf文件。

在本申请实施例的一些可能实现中，可以从当前数据传输系统中获取源集群的krb5.conf文件以及目标集群的krb5.conf文件，如果运行集群中也存在认证，则同样需要获取运行集群的krb5.conf文件。

在本申请实施例的一些可能实现中，本申请实施例中的认证配置文件中可以包括：领域名称信息、领域网络地址信息和认证信息；步骤102可以包括：判断两个计算机集群的领域名称信息是否一致；在两个计算机集群的领域名称信息一致的情况下，判断两个计算机集群的领域网络地址信息是否一致；在两个计算机集群的领域网络地址信息一致的情况下，确定数据传输方式为跨密钥分配中心(Key Distribution Center，KDC)的管道传输方式；在两个计算机集群的领域网络地址信息不一致的情况下，判断两个计算机集群的认证信息是否一致；在两个计算机集群的认证信息一致的情况下，确定数据传输方式为非跨KDC的传输方式；在两个计算机集群的认证信息不一致的情况下，确定数据传输方式为跨KDC的认证配置文件合并策略传输方式。

在本申请实施例的一些可能实现中，本申请实施例提供的数据传输方法还可以包括：在两个计算机集群的领域名称信息不一致的情况下，判断两个计算机集群的认证信息是否一致；在两个计算机集群的认证信息一致的情况下，确定数据传输方式为非跨KDC的传输方式；在两个计算机集群的认证信息不一致的情况下，确定数据传输方式为跨KDC的认证配置文件合并策略传输方式。

本申请实施例中的管道包括但不限于：未命名管道(即匿名管道)、命名管道。

需要说明的是，本申请实施例中的认证配置文件合并策略传输方式指将不同的认证配置文件合并为一个认证配置文件，利用合并后的认证配置文件进行认证及传输。

具体地，可以对上述源集群和目标集群的krb5.conf文件进行分析，获取上述源集群和目标集群的主要信息，包括领域名称信息、领域网络地址信息和认证信息。

当获取到源集群和目标集群的领域名称信息、领域网络地址信息和认证信息后，首先，比较源集群和目标集群的领域名称信息是否一致。比较源集群和目标集群的领域名称信息是否一致主要是依据krb5.conf文件中的realms字段，realms字段示例如下：

其中，KDC1.LOCAL是此KDC认证的领域名称。

当源集群和目标集群的领域名称信息一致时，比较源集群和目标集群的领域网络地址信息是否一致，当源集群和目标集群的领域网络地址信息不一致时，源集群和目标集群使用的是不同KDC，此时，使用管道传输方式进行跨KDC数据传输。

当源集群和目标集群的领域网络地址信息一致时，比较源集群和目标集群的认证信息是否一致，当源集群和目标集群的认证信息一致时，源集群和目标集群使用的是同一KDC，此时，无需跨KDC进行数据传输；当源集群和目标集群的认证信息不一致时，源集群和目标集群使用的是不同KDC，此时，使用认证配置文件合并策略传输方式进行跨KDC数据传输。

当源集群和目标集群的领域名称信息不一致时，比较源集群和目标集群的认证信息是否一致，当源集群和目标集群的认证信息一致时，源集群和目标集群使用的是同一KDC，此时，无需跨KDC进行数据传输；当源集群和目标集群的认证信息不一致时，源集群和目标集群使用的是不同KDC，此时，使用认证配置文件合并策略传输方式进行跨KDC数据传输。

本申请实施例并不对比较源集群和目标集群的认证信息是否一致所采用的方式进行限定，任何可用的方式均可应用于本申请实施例中。例如，可以判断是否为同一用户、用户的认证文件是否发向同一个KDC等，判断所依据的文件是用户所使用的keytab文件、principal文件等。

比较源集群和目标集群的认证信息是否一致主要是krb5.conf文件中的realms字段和domain_realm字段，domain_realm字段示例如下：

[domain_realm]

.test.com＝KDC1.LOCAL

test.com＝KDC1.LOCAL

191.0.0.1＝KDC1.LOCAL

上述比较逻辑过程如图2所示。图2是本申请实施例提供的比较逻辑的示意图。

在本申请实施例的一些可能实现中，当确定的数据传输方式为跨KDC的认证配置文件合并策略传输方式时，本申请实施例提供的数据传输方法还可以包括：判断两个计算机集群的认证配置文件是否能够合并，在两个计算机集群的认证配置文件不能合并的情况下，将数据传输方式更新为跨KDC的管道传输方式。

在本申请实施例的一些可能实现中，本申请实施例提供的数据传输方法还可以包括：在两个计算机集群的认证配置文件能够合并的情况下，将两个计算机集群的认证配置文件合并为具有同时认证两个计算机集群对应的两个KDC功能的策略合并配置文件；利用策略合并配置文件对两个KDC进行认证。

本申请实施例并不对判断两个计算机集群的认证配置文件能否合并所采用的方式进行限定，任何可用的方式均可以应用于本申请实施例中。

在本申请实施例的一些可能实现中，合并后的策略合并配置文件可以采用合并前的认证配置文件的文件结构。其中，认证配置文件的文件结构如表1所示。

表1

当判断两个计算机集群的认证配置文件能够合并的情况下，加载两个计算机集群的认证配置文件，按照预定格式对这两个计算机集群的认证配置文件进行解析，生成内部对象。再按照预设的文件合并逻辑生成相对应的新的krb5.conf文件，即策略合并配置文件。

当生成策略合并配置文件之后，还可以根据任务创建时指定的JS对象简谱(JavaScript Object Notation，JSON)格式数据，生成插件列表，安全相关类的加载信息，然后，将这些信息共同存储在任务级配置文件中。

该任务级配置文件可以包括：新的认证文件(即策略合并配置文件)地址和用户名等相关信息、任务的插件信息、根据插件选择的安全相关加载类类名、任务的额外必要参数。其中，任务的插件是任务交换的连接器，用于与其他端进行连接。

任务级配置文件中，占据重要位置的部分是关于认证的相关数据。程序在生成这些数据时，会根据上文中提到的krb5.conf文件元数据结构来解析认证文件的字段，并根据它们生成新的认证文件，涉及到的字段包括：realms(中文名领域)、domain_realm、libdefaults和其它字段。

其中，文件的realms部分中的每个子集都是Kerberos领域的名称。子集所标记的值定义了该特定领域的属性。对于每个领域，可以在领域的小节中指定若干属性值。

Realms的属性“管理服务器(admin_server)”标识正在运行管理服务器的主机，在安装部署时，这一块是主Kerberos服务器。将其指定一个值，使JVM进程能与领域的kadmind服务器通信。在新生成的文件中，会将这部分内容拷贝过来。

Realms的属性“kdc”指该领域运行KDC的主机的名称或地址。可以包括一个可选的端口号，与主机名用冒号分隔。当地址中包含了IPv6时，将其括在方括号中，以将冒号与端口分隔符区分开来。为了使进程能够与每个领域的KDC通信，在文件生成策略时，必然会添加此值，虽然也可以在DNS中配置解析KDC，但数据传输引擎运行的进程是无法修改DNS服务器的，所以所有的KDC在此处指定。

domain_realm提供从域名或主机名到Kerberos领域名的转换。这里的键可以是主机名或域名，其中，域名可由句点(.)的前缀表示，值是该特定主机或域的Kerberos领域名，主机名关系隐式提供相应的域名关系，除非提供了显式域名关系。在此部分，数据传输引擎将根据要连接的目标库进行主机名、IP、域名进行解析，分析出与对应的Kerberos领域所有的主机(IP、域名)列表，将这些列表放入到此处。

需要从libdefaults中提取出运行集群的default_realm字段，将这个字段复制到新的文件中，舍弃目标集群的值。目标集群的值之所以可以安全舍弃，主要是因为在domain_realm中配置了相应的映射关系。此值主要是为了给任务本身认证运行集群使用。

对于两个krb5.conf文件中的其它部分，需要以运行集群的文件内容为基准进行合并，即遇到重复的key时以运行集群的value为最终结果，写入到新文件中。

当完成上述步骤之后，数据传输引擎将得到可以同时认证两个Kerberos认证中心(即KDC)的策略合并配置文件，这个策略合并配置文件的地址同时会放入任务级配置文件中。

在本申请实施例的一些可能实现中，在利用策略合并配置文件对两个密钥分配中心进行认证之前，本申请实施例提供的数据传输方法还可以包括：利用策略合并配置文件，更新对两个KDC进行认证的认证配置。

具体地，可以利用策略合并配置文件覆盖JVM原有的认证配置，并配置模块ZooKeeperModule、HadoopModule和JaasModule。

其中，作为底层相关的Zookeeper由ZooKeeperModule负责；Hadoop相关的，比如涉及到的HDFS，由HadoopModule负责。

当程序需要连接HDFS、HBase、Hive等组件时，都会涉及使用hadoop common中UserGroupInformation类来进行用户/组信息的处理，主要进行登录、认证、获取身份信息等。

当程序中要链接Kafka时，需要选择使用JaasModule来进行认证覆盖，使连接Kafka的部分可以转发到对应的认证中心。

具体地，可以通过设置环境变量KR5_CONFIG来使新生成的认证配置文件覆盖原有的认证配置文件，例如，通过函数System.setProperty(JAVA_SECURITY_KRB5_CONF,krb5FilePath)进行覆盖。然后，执行Config.refresh()来刷新认证配置。

在进行ZooKeeperModule认证时，覆盖ZookeeperModuleFactory；在进行HadoopModule认证时，覆盖HadoopModuleFactory；在进行JaasModule认证时，覆盖JaasModuleFactory。

下面以认证JaasModule为例进行说明。

当数据传输引擎判断本次认证需要使用Jaas时，会根据jaas认证方式的特点，在与目标库连接的插件内部生成与目标端KDC认证所需要使用的Jaas文件内容，该文件的内容示例如下：

上述示例中，表明了本次认证禁止使用缓存配置，每次认证都需要使用keytab，且指定了keytab文件的本地存储地址是“/path/krb.keytab”，使用的principal是“test@HADOOP.COM”。

当按此配置进行认证时，上述这些值会存储在javax.security.auth.login.Configuration中，数据传输引擎就会去寻找指定的认证文件，该认证文件中存储了认证的KDC，数据传输引擎的当前插件会去合并后的krb5.conf内去查找KDC的位置并进行后续认证动作，认证完成后，数据传输引擎进行数据的后续关联运算及交换。

本申请实施例还构建了一套管道管理方案。该管道管理方案具有数据源和数据类型无关性、流批一体性和面向切面的生命周期控制等特点。

其中，数据源和数据类型无关性指管道数据与数据源高度分离，任何数据源都可以使用此管道进行数据传输，且支持任何数据类型。

流批一体性指管道可以控制数据流的开启、关闭，并支持无限管道数据传输，可以支持高时效、高吞吐的数据传输需求。当使用批数据传输时，管道文件可以在数据流结束后自然关闭，不占用多余空间；当使用流数据传输时，管道的read()阻塞特性以及数据传输引擎的基于Akka的RPC命令交互机制，可以保障管道的长期存活以及实时写入与读取。不管是处理批式还是流式数据，在数据传输过程中，管道文件都不会无限增长，它有着固定长度的缓冲区，此缓冲区的大小可以为4K。

面向切面的生命周期控制指数据传输引擎对整个管道的生命周期预置了对应函数，可以在管道准备、启动、运行、关闭前、关闭后等阶段进行流程控制。插件可以在管道的任意生命周期钩子函数中添加自定义动作，包括初始化、预置数据、清理认证、测试连接等。

在数据传输方面，创建Source与Sink接口的实现类。

Source的实现类中包含了Built-in plug-ins、ReadProcessInstance两个实现，其中，Built-in部分实现内置数据流转逻辑，将数据从外部传输到数据传输引擎内部；ReadProcessInstance是子进程处理类，它会启动一个子进程，用来与源集群进行交互，数据传输引擎根据要连接的源集群的类型，选择不同的Handler进行交互。

ReadProcessInstance的各子Handler继承InputHandler接口，该接口定义了数据传输过程中Input部分的接口，对数据在子进程的读取进行了抽象定义。

Sink的实现类中包含了Bilt-in plug-ins、WriteProcessInstance两个实现，其中，Build-in部分实现Sink数据发送的内置数据流转逻辑，将数据从数据传输引擎中发送到外部存储，WriteProcessInstance是子进程处理类，它会启动一个数据写出子进程，用来与目标集群进行交互，数据传输引擎根据要连接的目标类型，选择不同的Handler进行交互。

WriteProcessInstance的各子Handler继承Output接口，该接口定义了数据传输过程中Output部分的接口，对数据在子进程的写出传输进行了抽象定义。

当程序启动时，对比源集群、目标集群、运行群集三者的Kerberos认证关系，判断出需要启动的运行逻辑。

当判断源存储需要命名管道时，Source初始化时启动ReadProcessInstance子进程，子进程接收Source的信号，在working dir目录下使用mkfifo创建命名管道并在进程内部根据源集群类型创建数据连接，将数据发送到命名管道中，Source确认子进程启动后，创建命名管道的读取单元，将子进程的发送到命名管道的数据读取出来，加载到框架内部。

当判断目标存储需要命名管道时，Sink初始化时启动WriteProcessInstance子进程，子进程接收Sink的信号，在working dir目录下使用mkfifo创建命名管道并在进程内部根据目标集群类型创建数据连接。Sink负责从框架内接收数据并将数据发送到子进程创建的命名管道中，WriteProcessInstance子进程读取管道内的数据，将其发送到目标集群中。

本申请实施例还提供一种数据传输装置，如图3所示。图3是本申请实施例提供的数据传输装置的结构示意图，该数据传输装置300可以包括：

获取模块301，用于获取基于Kerberos协议的两个计算机集群的认证配置文件；

确定模块302，用于根据认证配置文件，确定数据传输方式；

传输模块303，用于根据数据传输方式，在两个计算机集群之间传输数据。

在本申请实施例中，通过获取基于Kerberos协议的两个计算机集群的认证配置文件；根据认证配置文件，确定数据传输方式；根据数据传输方式，在两个计算机集群之间传输数据。如此，能够在两个计算机集群之间以所确定的数据传输方式传输数据，无需中间件和文件存储系统，降低了数据传输系统的复杂度，提高了数据传输系统的可维护性和可用性。

在本申请实施例的一些可能实现中，认证配置文件中包括：领域名称信息、领域网络地址信息和认证信息；确定模块302具体可以用于：

判断两个计算机集群的领域名称信息是否一致；

在两个计算机集群的领域名称信息一致的情况下，判断两个计算机集群的领域网络地址信息是否一致；

在两个计算机集群的领域网络地址信息一致的情况下，确定数据传输方式为跨KDC的管道传输方式；

在两个计算机集群的领域网络地址信息不一致的情况下，判断两个计算机集群的认证信息是否一致；

在两个计算机集群的认证信息一致的情况下，确定数据传输方式为非跨KDC的传输方式；

在两个计算机集群的认证信息不一致的情况下，确定数据传输方式为跨KDC的认证配置文件合并策略传输方式。

在本申请实施例的一些可能实现中，确定模块302还可以用于：

在两个计算机集群的领域名称信息不一致的情况下，判断两个计算机集群的认证信息是否一致；

在两个计算机集群的认证信息一致的情况下，确定数据传输方式为非跨KDC的传输方式；

在两个计算机集群的认证信息不一致的情况下，确定数据传输方式为跨KDC的认证配置文件合并策略传输方式。

在本申请实施例的一些可能实现中，本申请实施例提供的数据传输装置300还可以包括：

判断模块，用于在确定数据传输方式为跨KDC的认证配置文件合并策略传输方式的情况下，判断两个计算机集群的认证配置文件是否能够合并；

第一更新模块，用于在两个计算机集群的认证配置文件不能合并的情况下，将数据传输方式更新为跨KDC的管道传输方式。

在本申请实施例的一些可能实现中，本申请实施例提供的数据传输装置300还可以包括：

合并模块，用于在两个计算机集群的认证配置文件能够合并的情况下，将两个计算机集群的认证配置文件合并为具有同时认证两个计算机集群对应的两个密钥分配中心功能的策略合并配置文件；

认证模块，用于利用策略合并配置文件对两个KDC进行认证。

在本申请实施例的一些可能实现中，本申请实施例提供的数据传输装置300还可以包括：

更新模块，用于利用策略合并配置文件，更新对两个KDC进行认证的认证配置。

图4是本申请实施例提供的电子设备的结构示意图。

该电子设备可以包括处理器401以及存储有计算机程序指令的存储器402。

具体地，上述处理器401可以包括中央处理器(Central Processing Unit，CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器402可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器402可包括硬盘驱动器(Hard Disk Drive，HDD)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(Universal Serial Bus，USB)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器402可以包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器402可在电子设备的内部或外部。在一些特定实施例中，存储器402是非易失性固态存储器。

在一些特定实施例中，存储器可包括只读存储器(Read-Only Memory，ROM)，随机存取存储器(Random Access Memory，RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本申请的数据传输方法所描述的操作。

处理器401通过读取并执行存储器402中存储的计算机程序指令，以实现本申请实施例提供的数据传输方法。

在一个示例中，该电子设备还可以包括通信接口403和总线410。其中，如图4所示，处理器401、存储器402、通信接口403通过总线410连接并完成相互间的通信。

通信接口403，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。

总线410包括硬件、软件或两者，将电子设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(Accelerated Graphics Port，AGP)或其他图形总线、增强工业标准架构(Extended Industry Standard Architecture，EISA)总线、前端总线(Front Side Bus，FSB)、超传输(Hyper Transport，HT)互连、工业标准架构(IndustryStandard Architecture，ISA)总线、无限带宽互连、低引脚数(Low Pin Count，LPC)总线、存储器总线、微信道架构(Micro channel architecture，MCA)总线、外围组件互连(Peripheral Component Interconnect，PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(Serial Advanced Technology Attachment，SATA)总线、视频电子标准协会局部(Video electronics standards association Local Bus，VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线410可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

该电子设备可以执行本申请实施例提供的数据传输方法，从而实现本申请实施例提供的数据传输方法的相应技术效果。

另外，结合上述实施例中的数据传输法，本申请实施例还提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现本申请实施例提供的数据传输方法。计算机可读存储介质的示例包括非暂态计算机可读介质，如ROM、RAM、磁碟或者光盘等。

本申请实施例提供一种计算机程序产品，该计算机程序产品中的指令由电子设备的处理器执行时，使得电子设备执行本申请实施例提供的数据传输方法，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要明确的是，本申请并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本申请的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本申请的精神后，做出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(Application SpecificIntegrated Circuit，ASIC)、适当的固件、插件、功能卡等等。当以软件方式实现时，本申请的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、ROM、闪存、可擦除只读存储器(Erasable Read Only Memory，EROM)、软盘、只读光盘(Compact Disc Read-Only Memory，CD-ROM)、光盘、硬盘、光纤介质、射频(RadioFrequency，RF)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本申请中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本申请不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

上面参考根据本公开的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

以上所述，仅为本申请的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。