业务降级的实现方法及装置与流程

本申请涉及业务处理技术领域，尤其涉及一种业务降级的实现方法及装置。

背景技术：

业务系统可以接收和处理来自请求方的业务处理请求，并返回相应的返回结果。在一些情况下，比如业务系统的处理压力过大、功能受限等，可能导致业务系统无法及时或顺利地处理该业务处理请求，从而需要对业务处理请求进行降级处理。

在相关技术中，由每一业务系统针对自身的业务降级需求，分别配置相应的业务降级处理功能。但是，业务降级处理功能往往对业务系统原有的业务功能具有较强的代码侵入性，不仅可能影响原有的业务功能，而且场景的扩展性不足；同时，各个业务系统基于各自配置的业务降级处理功能生成返回结果时，可能导致返回结果之间存在较大的装配差异，容易让用户产生对异常状况的感知，有悖于业务降级的“用户无感知”的初衷。

技术实现要素：

有鉴于此，本申请提供一种业务降级的实现方法及装置，可以根据业务降级处理需求的不同，对业务处理请求进行有效区分，以实现恰当的业务降级处理操作。

为实现上述目的，本申请提供技术方案如下：

根据本申请的第一方面，提出了一种业务降级的实现方法，包括：

接收针对关联业务系统的业务处理请求；

确定所述业务处理请求是否包含预定义的降级标识；

当包含所述降级标识时，对所述业务处理请求进行降级处理；

返回针对所述业务处理请求的返回结果。

根据本申请的第二方面，提出了一种业务降级的实现装置，包括：

接收单元，接收针对关联业务系统的业务处理请求；

确定单元，确定所述业务处理请求是否包含预定义的降级标识；

处理单元，当包含所述降级标识时，对所述业务处理请求进行降级处理；

返回单元，返回针对所述业务处理请求的返回结果。

根据本申请的第三方面，提出了一种业务降级的实现装置，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为实现如上述第一方面所述的方法。

由以上技术方案可见，本申请通过由业务平台在对接各个业务系统时，对各个业务系统的业务处理请求进行统一化的业务降级处理，一方面无需业务系统对自身的业务降级处理功能进行单独配置，便于对业务降级处理的统一管理，并且有助于扩展业务降级处理的应用场景，能够兼容业务系统的无缝接入，另一方面可以由业务平台对所有业务处理请求的返回结果进行统一装配，确保用户体验的一致性，以真正实现用户无感知。

附图说明

图1是本申请一示例性实施例提供的一种业务降级处理系统的架构示意图。

图2是本申请一示例性实施例提供的一种业务降级的实现方法的流程图。

图3是本申请一示例性实施例提供的一种金融业务服务端的原理示意图。

图4是本申请一示例性实施例提供的一种业务降级处理的交互示意图。

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

图6是本申请一示例性实施例提供的一种业务降级的实现装置的框图。

具体实施方式

本申请通过在业务平台上配置业务降级处理功能，可以适用于该业务平台对接的所有业务系统，便于实现对各个业务系统的统一业务降级管理，并实现对返回结果的统一装配与返回。为对本申请进行进一步说明，提供下列实施例：

图1是本申请一示例性实施例提供的一种业务降级处理系统的架构示意图。如图1所示，该系统可以包括业务平台服务器11、网络12、若干电子设备，比如手机13、pc14等，以及业务系统服务器15、业务系统服务器16。

业务平台服务器11、业务系统服务器15、业务系统服务器16可以为包含一独立主机的物理服务器，或者可以为主机集群承载的虚拟服务器，或者可以为云服务器。在运行过程中，业务平台服务器11可以运行某一应用的服务端侧的程序，以实现为相应的业务平台；而业务系统服务器15、业务系统服务器16可以运行并实现为业务系统，上述的业务平台可以对各个业务系统进行集中的功能实现以及统一的业务降级管理等。其中，上述的业务平台可以对接一个或多个业务系统，本申请并不限制业务系统的数量。

手机13、pc14只是用户可以使用的一种类型的电子设备。实际上，用户显然还可以使用诸如下述类型的电子设备：平板设备、笔记本电脑、掌上电脑(pdas，personaldigitalassistants)、可穿戴设备(如智能眼镜、智能手表等)等，本申请并不对此进行限制。在运行过程中，该电子设备可以运行某一应用的客户端侧的程序，以实现该应用的相关业务功能，比如向业务平台发起与业务系统相关的业务处理请求。

而对于手机13、pc14与业务平台服务器11之间，以及业务平台服务器11与业务系统服务器15、业务系统服务器16之间进行交互的网络12，可以包括多种类型的有线或无线网络。在一实施例中，该网络12可以包括公共交换电话网络(publicswitchedtelephonenetwork，pstn)和因特网。

下面结合实施例描述业务平台服务器11在本申请的技术方案中，如何实现集中化的业务降级方案。

图2是本申请一示例性实施例提供的一种业务降级的实现方法的流程图。如图2所示，该方法应用于诸如上述图1所示的业务平台服务器11，可以包括以下步骤：

步骤202，接收针对关联业务系统的业务处理请求。

在本实施例中，关联业务系统可以包括与业务平台具有关联关系的业务系统，比如由该业务平台分别与各个关联业务系统对接，使得关联业务系统仅需与该业务平台实现数据交互即可，而无需直接面对用户侧。基于业务平台与业务系统之间的关联关系，一方面便于降低业务系统的性能需求、降低业务系统的复杂程度，另一方面有助于业务平台对多个业务系统实现集中管理、便于提升业务处理效率。比如在图1所示的实施例中，对于业务平台服务器11承载的业务平台、业务系统服务器15承载的业务系统1、业务系统服务器16承载的业务系统2，可以认为该业务系统1和业务系统2为该业务平台的关联业务系统。

步骤204，确定所述业务处理请求是否包含预定义的降级标识。

在本实施例中，降级标识可以包括任何具有特殊性标识功能的信息，本申请并不对此进行限制。举例而言，该降级标识可以包括预定义的降级注解信息，比如该业务处理请求为基于java语言的请求数据时，该降级标识可以包括特定的java注解内容，譬如@sence、@sences等；当然，降级标识可以用于表达更多内容，比如@sence可以用于表示相应的业务处理请求存在一种对应的降级处理方式，@sences可以用于表示相应的业务处理请求存在多种对应的降级处理方式等。

步骤206，当包含所述降级标识时，对所述业务处理请求进行降级处理。

在本实施例中，可以确定所述业务处理请求对应的降级处理规则，然后根据所述降级处理规则定义的降级处理方式，对所述业务处理请求进行降级处理。通过采用基于降级处理规则的方式，使得对于每一业务系统的每种业务降级需求，均可以通过创建相应的降级处理规则即可实现，而无需侵入和影响到业务系统的原有功能，也不会侵入或影响业务平台的原有功能；同时，当业务平台需要增加与某一业务系统的业务关联时，仅需创建相应的降级处理规则即可，有助于业务系统的无缝接入，便于实现业务平台的功能与场景扩展。

在本实施例中，可以获取所述业务处理请求包含的传入参数，并根据预定义的传入参数与降级处理规则之间的对应关系，确定所述业务处理请求对应的降级处理规则。比如该传入参数可以包括业务处理请求对应的产品类型、业务处理请求对应的业务需求、业务处理请求对应的业务系统的所属机构、业务处理请求的请求方信息等各种类型的属性信息，本申请并不对此进行限制。

在本实施例中，降级处理方式可以包括以下至少之一：前置降级、后置降级、异常降级，当然本申请并不对此进行限制。其中，前置降级可以为在无需对业务处理请求进行正常处理的情况下予以业务降级处理，比如无需交由相应的业务系统进行处理；后置降级可以为在对业务处理请求进行正常处理，并在获得实际返回结果后予以业务降级处理，比如正常交由相应的业务系统进行处理；异常降级可以为在对业务处理请求的处理过程中抛出异常时，予以业务降级处理。

在本实施例中，降级处理规则可以被基于键-值(key-value)数据结构保存在业务平台服务器的虚拟机内存中，以便提升对该降级处理规则的访问效率。

在本实施例中，对于后置降级时业务系统返回的实际返回结果等需要装配为组装返回结果的情况下，可以对该实际返回结果中的相关字段反序列化后进行缓存，可使该反序列化结果适用于相同字段的不同取值，有助于提升对实际返回结果的访问效率，从而进一步提升对组装返回结果的组装效率。

在本实施例中，当业务平台被配置于分布式服务器集群时，该分布式服务器集群中与该业务平台相关的每一分布式节点可以向资源管理系统注册对所述降级处理规则的更新需求，使得当降级处理规则在任一分布式节点上更新后，其他已注册更新需求的分布式节点均可以接收该资源管理系统推送的针对所述降级处理规则的更新数据，以在分布式服务器集群中更新所述降级处理规则。

步骤208，返回针对所述业务处理请求的返回结果。

在本实施例中，在返回针对所述业务处理请求的返回结果时，可以包括以下至少之一：

当所述降级处理方式为前置降级时，可以返回包含预设调用内容的返回结果，该预设调用内容可以包括调用成功内容、调用失败内容或者其他任意的预设内容。

当所述降级处理方式为后置降级时，可以对所述业务处理请求的实际返回结果进行组装，并返回得到的组装返回结果。其中，当所述实际返回结果与所述降级处理规则定义的返回结果不一致时，对所述业务处理请求的实际返回结果进行组装，以使所述组装返回结果匹配于所述降级处理规则定义的返回结果。例如，当所述实际返回结果为调用失败时，如果降级处理规则定义的返回结果为调用成功，可以将所述实际返回结果组装为包含预设的调用成功内容的组装返回结果；当所述实际返回结果为调用成功时，如果降级处理规则定义的返回结果为调用失败，可以将所述实际返回结果组装为包含预设的调用失败内容的组装返回结果。而当所述实际返回结果与所述降级处理规则定义的返回结果一致时，可以不对所述业务处理请求的实际返回结果进行组装。

当所述降级处理方式为抛出异常时，可以返回所述业务处理请求发生异常的返回结果。

由以上技术方案可见，本申请通过由业务平台在对接各个业务系统时，对各个业务系统的业务处理请求进行统一化的业务降级处理，一方面无需业务系统对自身的业务降级处理功能进行单独配置，便于对业务降级处理的统一管理，并且有助于扩展业务降级处理的应用场景，能够兼容业务系统的无缝接入，另一方面可以由业务平台对所有业务处理请求的返回结果进行统一装配，确保用户体验的一致性，以真正实现用户无感知。

为了便于理解，以金融业务场景为例，对本申请的技术方案进行说明。假定手机13、pc14上运行有金融业务客户端、业务平台服务器11上运行有金融业务服务端，其中手机13、pc14上的金融业务客户端登录有用户账号，使得用户可以通过手机13、pc14上的金融业务客户端向金融业务服务端发起业务处理请求，以实现与该用户账号相关的金融业务处理。而业务系统服务器15、业务系统服务器16上运行有各个金融机构的业务系统，比如业务系统服务器15由金融机构a维护、运行有该金融机构a对应的业务系统1，而业务系统服务器16由金融机构b维护、运行有该金融机构b对应的业务系统2。金融业务服务端相当于本申请中的业务平台，该金融业务服务端与业务系统1、业务系统2分别对接，从而在接收到金融业务客户端发起的针对业务系统1或业务系统2的业务处理请求时，该金融业务服务端并不直接处理该业务处理请求，而是将该业务处理请求转交至相应的业务系统1或业务系统2进行处理，以及金融业务服务端将业务系统1或业务系统2的返回结果返回至金融业务客户端。

而在本申请的技术方案中，基于金融业务服务端与业务系统1、业务系统2等之间的集中管理架构，该金融业务服务端可以统一实现各个金融结构所需的业务降级处理功能，而无需各个金融机构对相应的业务系统1、业务系统2等进行单独的功能改进。下面结合金融业务客户端、金融业务服务端、业务系统1、业务系统2等之间的交互过程，对本申请的技术方案进行详细说明。

图3是本申请一示例性实施例提供的一种金融业务服务端的原理示意图；图4是本申请一示例性实施例提供的一种业务降级处理的交互示意图，如图4所示，该交互过程可以包括以下步骤：

步骤402，金融业务服务端接收到金融业务客户端发起的业务处理请求。

步骤404，金融业务服务端确认是否存在业务降级需求。

在本实施例中，金融业务服务端可以在预定义的降级条件被满足时，确认实时业务降级需求。比如，该降级条件可以与性能瓶颈相关，比如金融业务服务端自身出现性能瓶颈，或者业务系统1、业务系统2出现性能瓶颈等；再比如，降级条件可以与业务系统的功能部署相关，例如业务处理请求具有实时处理需求，而业务系统1不支持实时处理功能等。

当金融业务服务端确认存在业务降级需求时，转入步骤406进行后续处理；而当金融业务服务端确认不存在业务降级需求时，可以根据该业务处理请求对应的业务系统，将该业务处理请求转由相应的业务系统进行正常处理即可。

步骤406，金融业务服务端识别业务处理请求中是否包含特定的降级注解信息。

在本实施例中，降级注解信息可以采用预定义的任意信息格式，本申请并不对此进行限制。比如，当业务处理请求采用java语言时，该降级注解信息可以为java注解，例如@sence、@sences等。

例如，在图3所示的实施例中，可以由金融业务服务端处配置的拦截器对业务处理请求进行拦截，并检查该业务处理请求中是否包含上述的降级注解信息；而由服务方法配置拦截器关注的降级注解信息，以对包含该降级注解信息的业务处理请求进行拦截。例如，当服务方法配置的降级注解信息为@sence或@sences时，若上述的业务处理请求中包含诸如@sence或@sences降级注解信息，则拦截器可确定拦截相应的业务处理请求，以供实施业务降级处理；而当该业务处理请求中未包含上述的降级注解信息时，该拦截器可以对该业务处理请求进行放行，以按照正常流程处理该业务处理请求。在较为具体的实施例中，该拦截器可以采用java框架下的methodinterceptor(方法拦截器)作为实现接口，以实现对业务处理请求的拦截处理。

步骤408，金融业务服务端确定匹配于业务处理请求的降级处理规则。

在本实施例中，金融业务服务端可以根据业务处理请求中包含的传入参数(入参)，确定相匹配的降级处理规则。

例如，在图3所示的实施例中，业务系统1、业务系统2等均可以在金融业务服务端处创建相应的降级处理规则，这些降级处理规则被存储于数据库中。在一实施例中，该降级处理规则可以采用kv(即key-value)数据结构进行保存，其中key可以包括部分传入参数，value可以包括更多传入参数以及降级处理方式等内容。

表1

如上表1所示，假定在金融业务服务端记录有表1所示的两条降级处理规则。其中，key包含的传入参数为请求类型，比如第一条降级处理规则定义了key为redeem_apply(赎回申请)，第二条降级处理规则定义了key为purchse_notify(申购通知)；而value中包括参数“scope”定义的目标金融机构等传入参数，value中还包括参数“mode”定义的降级方式、参数“degrade”定义的是否降级、参数“default_value”定义的返回结果的内容等。

那么，基于已创建的降级处理规则，如图3所示的规则模块可以将金融业务服务端接收到的业务处理请求与缓存模块中的降级处理规则进行比较，以确定出匹配于该业务处理请求的降级处理规则。例如，当上述的业务处理请求的“业务类型”传入参数为“redeem_apply”时，可以确定该业务处理请求匹配于表1中的第一条降级处理规则；当上述的业务处理请求的“业务类型”传入参数为“purchse_notify”、“目标机构名称”为“cc1”或“cc2”时，可以确定该业务处理请求匹配于表1中的第二条降级处理规则。

在金融业务服务端启动时，动态加载模块可以将数据库中的降级处理规则加载至缓存模块中，比如该降级处理规则可以被保存在金融业务服务端的服务器虚拟机内存中，以便于提升对降级处理规则的访问效率。同时，当降级处理规则在一些情况下需要实施更新操作时，如果金融业务服务端被承载于分布式服务器集群上，还涉及到更新后的降级处理规则在各个分布式节点之间的同步问题；其中，当上述更新操作发生于任一分布式节点时，动态加载模块可以将更新后的降级处理规则动态加载于该分布式节点上，而对于其他分布式节点，可以通过下述方式获得更新后的降级处理规则：

与金融业务服务端相关的各个分布式节点，可以分别向资源管理系统预先注册对降级处理规则的更新需求；那么，当降级处理规则发生更新时，该资源管理系统可以向所有已注册更新需求的分布式节点推送相应的更新数据，以使这些分布式节点获得更新后的降级处理规则，并由所述动态加载模块对更新后的降级处理规则进行动态加载，以确保整个金融业务服务端能够完成对降级处理规则的动态更新和支持。

步骤410，金融业务服务端按照匹配的降级处理规则，对业务处理请求进行降级处理，并生成相应的返回结果。

步骤412，金融业务服务端向金融业务客户端发送返回结果。

在一实施例中，假定金融业务服务端接收到业务处理请求，该业务处理请求的请求类型为申购通知，且目标金融机构的id为金融机构a对应的cc1，那么按照正常流程，金融业务服务端应当将该业务处理请求转由金融机构a对应的业务系统1进行处理；但是，当该业务处理请求基于“请求类型”、“目标金融机构”等传入参数匹配于表1所示的第二条降级处理规则时，需要按照该降级处理规则予以降级处理。

在表1所示的第二条降级处理规则中，该降级处理规则定义了参数"mode"为"call"，表明降级方式为前置降级；该降级处理规则定义了参数"degrade"为"t"，表明需要实施降级处理。由于需要实施前置降级，因而金融业务服务端无需将该业务处理请求发送至业务系统1进行处理，而可以在不处理的情况下，直接向金融业务客户端返回预设内容的返回结果。其中，由于该降级处理规则定义了参数"defaultvalue"为{"success":"true","amount":"300000+"}，因而金融业务服务端可以向金融业务客户端返回包含“申购成功(对应于"success":"true")”、“申购额为300000+(对应于"amount":"300000+")”等内容的返回结果。

在另一实施例中，假定金融业务服务端接收到业务处理请求，该业务处理请求的请求类型为赎回申请，那么按照正常流程，金融业务服务端应当将该业务处理请求转由金融机构b对应的业务系统2进行处理；但是，当该业务处理请求基于“请求类型”等传入参数匹配于表1所示的第一条降级处理规则时，需要按照该降级处理规则予以降级处理。

在表1所示的第一条降级处理规则中，该降级处理规则定义了参数"mode"为"return"，表明降级方式为后置降级；该降级处理规则定义了参数"degrade"为"t"，表明需要实施降级处理。那么，区别于上述的步骤410-412，此处可以采用下述的步骤414-420：

步骤414，金融业务服务端向业务系统2发送业务处理请求。

步骤416，金融业务服务端接收业务系统2返回的实际返回结果。

步骤418，金融业务服务端根据实际返回结果和降级处理规则，生成组装返回结果。

步骤420，金融业务服务端将组装返回结果返回至金融业务客户端。

在本实施例中，由于表1中的第一条降级处理规则定义了参数"defaultvalue"为{"success":"true"}，因此金融业务服务端最终返回的组装返回结果必须记录为“赎回成功”。其中，如果金融机构b支持实时赎回，实际返回结果为“赎回成功”，那么金融业务服务端可以将该实际返回结果作为组装返回结果，以返回至金融业务客户端；如果金融机构b不支持实时赎回，实际返回结果为“无法实时赎回”，那么金融业务服务端可以通过图3所示的装配模块，生成内容为“赎回成功”的组装返回结果，并返回至金融业务客户端，而金融业务服务端可以与该金融机构b实施后续的数据对接，以确保该金融机构b确实能够完成相应的赎回操作。另外，如果金融机构b支持实时赎回，但是业务系统2由于处理压力过大等原因而未能够顺利实施赎回操作，导致实际返回结果为处理异常，那么金融业务服务端可以生成内容为“操作异常”的组装返回结果。

此外，图3所示的实施例中还可以包括降级视图模块，该降级视图模块可以基于数据库中记载的降级处理规则，向金融业务服务端的管理人员呈现所有业务系统对应的降级视图，便于对相应的业务降级处理功能进行高效、便捷的统一管理。

图5示出了根据本申请的一示例性实施例的电子设备的示意结构图。请参考图5，在硬件层面，该电子设备包括处理器502、内部总线504、网络接口506、内存508以及非易失性存储器510，当然还可能包括其他业务所需要的硬件。处理器502从非易失性存储器510中读取对应的计算机程序到内存508中然后运行，在逻辑层面上形成业务降级的实现装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图6，在软件实施方式中，该业务降级的实现装置可以包括：

接收单元61，接收针对关联业务系统的业务处理请求；

确定单元62，确定所述业务处理请求是否包含预定义的降级标识；

处理单元63，当包含所述降级标识时，对所述业务处理请求进行降级处理；

返回单元64，返回针对所述业务处理请求的返回结果。

可选的，所述降级标识包括：预定义的降级注解信息。

可选的，所述处理单元63具体用于：

确定所述业务处理请求对应的降级处理规则；

根据所述降级处理规则定义的降级处理方式，对所述业务处理请求进行降级处理。

可选的，所述处理单元63通过下述方式确定所述业务处理请求对应的降级处理规则：

获取所述业务处理请求包含的传入参数；

根据预定义的传入参数与降级处理规则之间的对应关系，确定所述业务处理请求对应的降级处理规则。

可选的，所述降级处理方式包括以下至少之一：

前置降级、后置降级、异常降级。

可选的，所述返回单元64通过下述方式中至少之一，返回针对所述业务处理请求的返回结果：

当所述降级处理方式为前置降级时，返回包含预设调用内容的返回结果；

当所述降级处理方式为后置降级时，对所述业务处理请求的实际返回结果进行组装，并返回得到的组装返回结果；

当所述降级处理方式为抛出异常时，返回所述业务处理请求发生异常的返回结果。

可选的，所述返回单元64通过下述方式对所述业务处理请求的实际返回结果进行组装：

当所述实际返回结果与所述降级处理规则定义的返回结果不一致时，对所述业务处理请求的实际返回结果进行组装，以使所述组装返回结果匹配于所述降级处理规则定义的返回结果。

可选的，所述降级处理规则被基于键-值数据结构保存在虚拟机内存中。

可选的，还包括：

注册单元65，向资源管理系统注册对所述降级处理规则的更新需求；

更新单元66，接收所述资源管理系统推送的针对所述降级处理规则的更新数据，以更新所述降级处理规则。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

在一个典型的配置中，计算机包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。