订单信息的处理方法、装置、设备和可读存储介质与流程

1.本技术涉及数据处理技术领域，尤其涉及一种订单信息的处理方法、装置、设备和可读存储介质。


背景技术：

2.在用户使用移动终端下单的过程中，用户需要先在移动终端的应用软件中发起下单请求并上传下单信息，例如用户账号信息、送货地址以及下单物品的数量等，然后再通过服务器调用一系列的审核准则对这些下单信息进行审核确认，生成对应的订单。
3.现有技术中，为了避免应用软件审核订单信息花费大量时间，影响订单延迟生成，提高订单生成的响应速度，当用户上传好订单信息之后，服务器会使用后置审核策略，即优先生成对应的订单，后续再使用审核准则对该订单进行审核。
4.但是现有技术中的这种后置审核策略依然还是会使用大量的审核准则对下单信息进行审核，占用大量的审核时间，并且在订单生成之后，若后续发现该订单存在问题，又需要花费更多的人力物力去对该订单进行拦截，造成对用户发起的下单请求的处理效率低。


技术实现要素：

5.本技术提供一种订单信息的处理方法、装置、设备和可读存储介质，用以解决用户发起的下单请求的处理效率低问题。
6.第一方面，本技术提供一种订单信息的处理方法，包括：
7.根据从客户端提交的用户的物品下单请求，获取与所述物品下单请求对应的订单信息；
8.根据预设的信息校验规则，对所述订单信息进行校验得到校验结果，所述校验结果用于指示所述物品下单请求对应的订单是否存在风险，所述信息校验规则为：先采用短策略对订单信息进行校验，并在所述短策略无法确定风险后采用长策略对订单信息进行校验，所述短策略中包括的风控规则的数量少于所述长策略中包括的风控规则的数量；
9.根据所述校验结果和所述物品下单请求，对所述物品下单请求进行处理。
10.第二方面，本技术提供一种订单信息的处理装置，包括：
11.信息获取模块，用于根据从客户端提交的用户的物品下单请求，获取与所述物品下单请求对应的订单信息；
12.校验模块，用于根据预设的信息校验规则，对所述订单信息进行校验得到校验结果，所述校验结果用于指示所述物品下单请求对应的订单是否存在风险，所述信息校验规则为：先采用短策略对订单信息进行校验，并在所述短策略无法确定风险后采用长策略对订单信息进行校验，所述短策略中包括的风控规则的数量少于所述长策略中包括的风控规则的数量；
13.处理模块，用于根据所述校验结果和所述物品下单请求，对所述物品下单请求进
行处理。
14.第三方面，本技术提供一种处理设备，包括：至少一个处理器和存储器；
15.所述存储器存储计算机执行指令；
16.所述至少一个处理器执行所述存储器存储的计算机执行指令，使得所述至少一个处理器执行如上述的方法。
17.第四方面，本技术提供一种可读存储介质，所述可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如上述的方法。
18.第五方面，本技术提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述的方法。
19.本技术提供的订单信息的处理方法、装置、设备和可读存储介质，通过设置风控规则数量不相同的短策略和长策略，在用户提交物品下单请求之后，可以采用风控规则数量较少的短策略，先对订单进行校验，若短策略能够校验出结果，则直接根据该校验结果生成物品订单或者请求失败提示，避免使用风控规则数量多的长策略进行校验，缩短校验所花费的时间，提高校验性能，避免使用后置审核策略花费更多人力物力去取消已生成的订单，提高用户提交的下单请求的处理效率。
附图说明
20.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理；
21.图1为本技术实施例提供的订单信息的处理方法的应用场景示意图；
22.图2为本技术实施例提供的订单信息的处理方法实施例一的流程示意图；
23.图3为本技术实施例提供的订单信息的处理方法实施例二的流程示意图；
24.图4为本技术实施例提供的订单信息的处理方法实施例三的流程示意图；
25.图5为本技术实施例提供的订单信息的处理装置的结构示意图；
26.图6为本技术实施例提供的处理设备的结构示意图；
27.通过上述附图，已示出本技术明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本技术构思的范围，而是通过参考特定实施例为本领域技术人员说明本技术的概念。
具体实施方式
28.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的装置和方法的例子。
29.风控规则是用于判断对象是否存在相关风险的标准准则，由多条风控规则可以组成一个长策略或者短策略，包含的风控规则越多，则判断的准确性越高，同时也需要花费更多的判断时间，占用更多的服务器性能。现有技术中，在用户通过移动终端上的客户端发起物品下单请求，例如购票时，为了避免一些恶意下单的情况，服务器会采用后置审核策略，先根据物品下单请求，生成对应的订单数据，然后再使用风控规则对用户提交的订单信息
进行校验，如果判定存在风险，则后续又需要再取消该订单，如此造成了大量的物力人力成本，而如果不采用后置审核策略，先采用风控规则对物品下单请求进行校验，当不存在风险再生成订单，又会占用较多的校验时间，使得订单生成滞后，影响订单生成的时效性。
30.针对上述问题，本技术实施例提供订单信息的处理方法、装置、设备和可读存储介质，其具体技术构思如下：通过采用两种不同的长策略和短策略，在用户提交物品下单请求之后，先采用短策略进行校验，确定订单信息是否有风险，在没有风险时可以直接生成订单，避免使用包括有大量风控规则的长策略进行校验，提高订单生成的时效性，也避免了后置审核策略所带来的资源浪费。
31.图1为本技术实施例提供的订单信息的处理方法的应用场景示意图，如图1所示，该订单信息的处理方法可以应用于后台的服务器12，用户可以通过移动终端11，例如手机等在客户端上发起物品下单请求，物品下单请求由服务器12接收之后，服务器12解析得到对应的订单信息，其中，订单信息包括有各种与订单相关的信息，例如用户的账号信息、物品的下单数量、物品的配送地址和物品的配送方式等等，服务器12根据预设的信息校验规则，对订单信息进行校验，若订单信息存在风险，则返回订单请求失败提示至移动终端11，若订单信息不存在风险，则会生成订单，并将生成的订单信息返回至移动终端11。
32.其中，预设的信息校验规则可以包括长策略和短策略，短策略中包括的风控规则的数量少于长策略包括的风控规则的数量，具体可以先采用短策略中的风控规则对订单信息进行校验，在短策略无法确定风险后采用长策略对订单信息进行校验。
33.示例性的，预设的信息校验规则还可以包括多种不同的策略，每一个策略中包括有不同数量的风控规则，根据包括的风控规则的数量，确定每一个策略的优先级，包括的风控规则的数量少的策略可以具有更高的优先级，服务器优先采用优先级高的策略对订单信息进行校验，当优先级高的策略无法确定风险后，再采用优先级次之的策略继续对订单进行校验，根据优先级高低依次进行校验，直到得到校验结果，确定订单信息是否存在风险。
34.下面以具体地实施例对本技术的技术方案以及本技术的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本技术的实施例进行描述。
35.图2为本技术实施例提供的订单信息的处理方法实施例一的流程示意图，如图2所示，该方法可以应用于后台的服务器，以服务器作为执行主体为例，该方法具体包括以下步骤：
36.s201、根据从客户端提交的用户的物品下单请求，获取与物品下单请求对应的订单信息。
37.具体的，物品下单请求可以由用户从客户端发起，并又客户端上传到后台服务器，示例性的，用户可以对一些限量的物品进行下单，下单之后产生对应的订单信息，订单信息中可以包括有用户的身份信息，例如电话号码、实名信息等，还可以包括有物品的下单数量、配送地址、配送方式、物品折扣卷等等。
38.示例性的，用户可以在移动终端的客户端上完成订单信息的填写，然后进行点击操作，例如点击“确认下单”，以生成物品下单请求。
39.s202、根据预设的信息校验规则，对订单信息进行校验得到校验结果。
40.其中，校验结果用于指示物品下单请求对应的订单是否存在风险，信息校验规则
为：先采用短策略对订单信息进行校验，并在短策略无法确定风险后采用长策略对订单信息进行校验，短策略中包括的风控规则的数量少于长策略中包括的风控规则的数量。
41.具体的，预设的信息校验规则中包括有短策略和长策略，短策略中可以包括有多个风控规则，长策略中也可以包括多个风控规则，且短策略中的风控规则与长策略中的风控规则不相同，在对订单信息进行校验时，先使用短策略中的风控规则对订单信息进行校验，当短策略中的风控规则无法确定订单信息是否有风险时，再采用长策略中的风控规则对订单信息进行校验，以确定该订单信息对应的订单是否存在风险。
42.示例性的，短策略中的风控规则可以是一些关键的风控规则，例如用户是否实名、物品数量是否符合要求、用户的信用是否达到要求等，长策略中的风控规则可以是一些详细的风控规则，具体可以是配送地址、配送方式、用户是否使用折扣卷、礼品卡等虚拟资产。
43.当订单信息不满足短策略中的所有风控规则时，则表示该订单存在风险，而当订单信息满足短策略中的所有风控规则时，则表示该订单不存在风险，当订单信息只满足短策略中的部分风控规则时，则表示短策略无法确定订单是否存在风险，需要使用长策略中的风控规则继续进行校验。
44.s203、根据校验结果和物品下单请求，对物品下单请求进行处理。
45.具体的，校验结果包括有两种，一种为确定订单存在风险，另一种为确定订单不存在风险，当确定订单不存在风险时，则根据该物品下单请求，生成对应的物品订单，当确定订单存在风险时，则根据该物品下单请求，生成对应的下单请求失败提示，该下单请求失败提示用于提示用户下单请求被后台服务器拦截，无法下单。
46.示例性的，若服务器生成下单请求失败提示，可以将下单请求失败提示返回至客户端，客户端可以通过页面显示出下单请求失败提示，示例性的，下单请求失败提示可以包括有不符合风控规则的订单信息，以提示用户对订单信息进行增删修改。
47.示例性的，若服务器生成物品订单，则可以将物品订单返回至客户端，客户端可以通过页面显示出生成的物品订单，示例性的，用户可以通过物品订单查看到订单信息。
48.本技术实施例通过在订单生成之前，根据校验准则的数量，优先选择校验准则数量较少的段策略，对订单信息进行校验，若短策略无法确定是否为风险订单，再采用长策略进行校验，最终根据校验结果，确定生成该订单或者拦截该订单，如此一方面避免了风控后置策略需要逆向取消订单的问题，也能够有效的提高校验性能，提高订单请求的处理效率。
49.图3为本技术实施例提供的订单信息的处理方法实施例二的流程示意图，如图3所示，示例性的，在一些实施例中，上述步骤s202具体可以通过如下步骤实现：
50.s301、根据短策略对订单信息进行校验，若订单信息符合短策略中的所有风控规则，则确定订单不存在风险；
51.s302、若订单信息不符合短策略中的所有风控规则，则确定订单存在风险；
52.s303、若订单信息符合短策略中的部分风控规则，则采用长策略对订单信息进行校验，确定订单是否存在风险。
53.在本实施例中，订单信息中包括有各种不同类型的信息，短策略中的每一条风控规则分别对应校验订单信息中一种类型的信息是否存在风险。
54.进一步的，短策略的风控规则包括有下单数量风控规则，用户信用风控规则和身份信息风控规则，其中，
55.下单数量风控规则可以对订单信息中物品的下单数量进行校验，例如订单信息中物品的下单数量不能少于1，高于99等等；用户信用风控规则可以对订单芯中用户的信用进行校验，具体可以根据用户的历史下单请求，来给用户的信用进行打分，若用户的信用分低于80分，则不符合用户信用风控规则；身份信息风控规则用于对订单信息中用户的身份信息进行校验，例如用户的身份信息不够完善，缺乏实名信息，则不符合身份信息风控规则。
56.本技术实施例中，通过先使用短策略中的风控规则对订单信息进行校验，若短策略能够确定订单存在或不存在风险，则直接得到校验结果，根据该校验结果可以快速的对物品下单请求进行处理，避免使用包括有大量风控策略的长策略对订单信息进行校验，提高物品下单请求的处理效率。
57.进一步的，在一些实施例中，上述“采用长策略对订单信息进行校验，确定订单是否存在风险”，具体可以通过如下步骤实现：
58.根据长策略对订单信息进行校验，若订单信息符合长策略中的所有风控规则，则确定订单不存在风险；
59.若订单信息符合长策略中的部分风控规则或不符合长策略中的所有风控规则，则确定订单存在风险。
60.具体的，长策略包括的风控规则较多，长策略中的每一条风控规则都会对订单信息进行校验，当订单信息中任一种信息不符合长策略中的某一条风控规则，则确定该订单存在风险。
61.示例性的，长策略的风控规则包括有配送地址风控规则、配送方式风控规则、物品折扣券风控规则、用户虚拟资产风控规则，其中，
62.配送地址风控规则可以对订单信息中的配送地址进行校验，示例性的，配送地址可以是用户填写的，配送地址的数量可以是多个，用户可以设置其中的一个作为常用地址，当订单信息中的配送地址与常用地址不相同或者用户所填写的多个配送地址都不相同时，则表示该订单信息中的配送地址存在风险，不符合配送地址风控规则。
63.进一步的，配送方式风控规则用于对订单信息中用户填写的配送方式进行校验、物品折扣卷风控规则用于对订单信息中用户使用的物品折扣卷进行校验，用户虚拟资产风控规则用于对订单信息中用户使用的积分、消费券等进行校验。
64.本技术实施例中，通过使用风控规则数量多且校验详细的长策略，对订单信息进行校验，能够准确的确定出该订单是否存在有风险，可以提高检验的准确性。
65.在上述实施例的基础上，在一些实施例中，上述步骤s203具体可以通过如下步骤实现：
66.若校验结果指示订单存在风险，则生成下单请求失败提示；
67.若校验结果指示订单不存在风险，则生成物品下单请求对应的物品订单。
68.具体的，物品订单的生成流程具体包括如下：用户通过客户端发起物品下单请求，服务器对物品下单请求对应的订单信息进行校验，确定该物品下单请求对应的订单是否存在风险，若存在风险，则将该物品下单请拦截，若不存在风险，则生成物品订单。
69.示例性的，每一个物品下单请求都对应有一个订单，当订单存在风险时，则该物品下单请求将会被服务器拦截，服务器返回表征审核不通过的下单请求失败提示至客户端，示例性的，下单请求失败提示中可以包括有存在风险的订单信息，用户通过查看下单请求
失败提示，来确定订单信息中哪些信息是存在风险的。
70.当订单不存在风险时，服务器根据客户端提交的物品下单请求，生成物品订单，并返回该物品订单给客户端，物品订单中包括有前述的订单信息。
71.本技术实施例通过对校验结果进行分析，确定订单是否存在风险，避免存在风险的订单生成，造成后续花费大量的资源来取消该存在风险的订单，提高资源的利用率，以及订单处理效率。
72.在上述实施例的基础上，在一些实施例中，上述步骤s202具体可以包括如下步骤：
73.若根据短策略对订单信息进行校验得到校验结果，则将短策略校验得到的校验结果存储至预设第一队列中；
74.若根据长策略对订单信息进行校验得到校验结果，则将长策略校验得到的校验结果存储至预设第二队列中。
75.具体的，服务器若使用短策略中的风控规则能够确定该订单不存在风险，则将校验结果存储至预设第一队列中，可选的，服务器若使用短策略中的风控规则能够确定该订单存在风险，也可以将校验结果存储至预设第一队列中。
76.若使用短策略中的风控规则无法确定该订单是否存在风险，则服务器使用长策略中的风控规则继续对该订单信息进行校验，确定该订单是否存在风险，并将校验结果存在到预设第二队列中。
77.示例性的，预设第二队列中可以采用键值对的形式存储校验结果，例如订单1：存在风险，订单2：不存在风险。
78.示例性的，预设第一队列中可以只存储订单的标识信息，标识信息可以是数字编码，例如订单1、订单2、订单3。
79.示例性的，服务器可以并行处理多个物品下单请求，将服务器划分为下单系统和风控系统，下单系统接收从客户端上传的物品下单请求，而风控系统则采用短策略、长策略对物品下单请求对应的订单信息进行校验，校验结果存储到预设第一队列或预设第二队列中，下单系统先从预设第一队列查找，若没有查找到校验结果，则再去预设第二队列中查找得到校验结果，并根据校验结果，对物品下单请求进行处理。
80.示例性的，服务器可以设置等待时长，等待时长用于指示服务器在该等待时长内，从预设第一队列中查找校验结果，若超过该等待时长，则服务器将不再在预设第一队列中查找校验结果，转而去预设第二队列中查找校验结果，示例性的，由于短策略对订单信息进行校验所花费的时间较少，等待时长可以设置的比较短。
81.本技术实施例通过将短策略的校验结果和长策略的校验结果存储到不同的队列中，能够使得服务器确认短策略是否能够校验出订单信息存在风险，方便服务器实时的反馈信息至客户端。
82.在上述实施例的基础上，在一些实施例中，在采用短策略对订单信息进行校验之后，还包括：
83.在短策略无法确定风险时，输出信息展示页面至客户端。
84.其中，信息展示页面包括有倒计时，倒计时用于指示采用长策略对订单信息进行校验的进程。
85.具体的，当短策略无法确定风险时，服务器再使用长策略对订单信息进行校验，同
时，服务器会反馈信息展示页面给客户端，客户端显示信息展示页面给用户查看。
86.示例性的，倒计时可以是10秒钟，倒计时的时长可以根据长策略对订单信息进行校验所花费的时长进行设置。
87.示例性的，当长策略对订单信息进行校验确定该订单存在风险时，可以直接在信息展示页面展示下单请求失败提示给用户。
88.图4为本技术实施例提供的订单信息的处理方法实施例三的流程示意图，如图4所示，该方法可以应用于服务器，服务器包括有下单系统、风控系统和过渡页，该方法具体包括如下步骤：
89.s401、提交订单。
90.具体的，下单系统获取用户从客户端提交的物品下单请求，确定物品下单请求对应的订单信息。
91.s402、执行风控；s403、短策略规则，判断订单是否有风险。
92.具体的，风控系统首先执行短策略中的风控规则，对订单信息进行校验，确定该订单是否存在有风险。
93.s404、当没有风险时，短策略结果队列。
94.具体的，当确定订单没有风险或者有风险时，则将校验结果存储到预设第一队列(即短策略结果队列)。
95.s405、当有风险时长策略规则，长策略结果队列。
96.具体的，当短策略无法确定订单是否有风险时，则采用长策略中的风控规则对订单信息进行校验，得到校验结果并保存在预设第二队列(即长策略结果队列)。
97.s406、获取风控结果；s407、判断是否获取到风控结果，当获取到风控结果时，生成订单。
98.具体的，下单系统从短策略结果队列中查找，判断是否查找到校验结果，若短策略结果队列中有结果，则表明订单没有风险，生成订单。
99.s408、当没有获取到风控结果时，获取长策略判断结果，判断是否有风险。
100.具体的，当没有查找到校验结果时，过渡系统从长策略结果队列中查找获取长策略判断结果，并根据长策略判断结果，判断订单是否存在风险。
101.s409、当没有风险时，生成订单；s410、当有风险时提示下单失败。
102.具体的，当订单不存在风险时，则生成物品订单，当订单存在风险时，过渡系统将反馈下单失败提示至客户端，以提示用户。
103.本技术实施例提供的订单信息的处理方法，通过采用短策略和长策略对订单信息进行校验，在短策略能够确定订单是否存在风险时，可以直接生成订单或者提示下单失败，不需要再使用风控规则多的长策略进行校验，提高订单信息的处理效率。
104.下述为本技术装置实施例，可以用于执行本技术方法实施例。对于本技术装置实施例中未披露的细节，请参照本技术方法实施例。
105.图5为本技术实施例提供的订单信息的处理装置的结构示意图，如图5所示，该处理装置50包括有信息获取模块51、校验模块52、处理模块53，其中，
106.信息获取模块51，用于根据从客户端提交的用户的物品下单请求，获取与物品下单请求对应的订单信息。
107.校验模块52，用于根据预设的信息校验规则，对订单信息进行校验得到校验结果。
108.处理模块53，用于根据校验结果和物品下单请求，对物品下单请求进行处理。
109.其中，校验结果用于指示物品下单请求对应的订单是否存在风险，信息校验规则为：先采用短策略对订单信息进行校验，并在短策略无法确定风险后采用长策略对订单信息进行校验，短策略中包括的风控规则的数量少于长策略中包括的风控规则的数量。
110.在一些实施例中，校验模块52具体可以用于：
111.根据短策略对订单信息进行校验，若订单信息符合短策略中的所有风控规则，则确定订单不存在风险；
112.若订单信息不符合短策略中的所有风控规则，则确定订单存在风险；
113.若订单信息符合短策略中的部分风控规则，则采用长策略对订单信息进行校验，确定订单是否存在风险。
114.在一些实施例中，校验模块52具体可以用于：
115.根据长策略对订单信息进行校验，若订单信息符合长策略中的所有风控规则，则确定订单不存在风险；
116.若订单信息符合长策略中的部分风控规则或不符合长策略中的所有风控规则，则确定订单存在风险。
117.在一些实施例中，处理模块53具体用于：
118.若校验结果指示订单存在风险，则生成下单请求失败提示；
119.若校验结果指示订单不存在风险，则生成物品下单请求对应的物品订单。
120.在一些实施例中，校验模块52具体可以用于：
121.若根据短策略对订单信息进行校验得到校验结果，则将短策略校验得到的校验结果存储至预设第一队列中；
122.若根据长策略对订单信息进行校验得到校验结果，则将长策略校验得到的校验结果存储至预设第二队列中。
123.在一些实施例中，处理装置50还可以包括页面过渡模块，用于在短策略无法确定风险时，输出信息展示页面至客户端，信息展示页面包括有倒计时，倒计时用于指示采用长策略对订单信息进行校验的进程。
124.本技术实施例提供的装置，可用于执行图2至图4所示实施例中的方法，其实现原理和技术效果类似，在此不再赘述。
125.图6为本技术实施例提供的处理设备的结构示意图，如图6所示，该处理设备60包括有存储器61和至少一个处理器62；
126.存储器61存储计算机执行指令，该处理设备60还包括有总线63，其中，存储器61通过总线63与处理器62连接。
127.在具体的实现过程中，至少一个处理器62执行存储器61存储的计算机执行指令，使得至少一个处理器62执行如上述的方法。
128.示例性的，存储器61还可以用于存储预设的短策略的风控规则以及长策略的风控规则等，存储器61可以是云存储或者本地存储。
129.示例性的，处理设备可以是计算机设备或者服务器。
130.示例性的，总线可以是工业标准体系结构(industry standard architecture，
isa)总线、外部设备互连(peripheral component interconnect，pci)总线或扩展工业标准体系结构(extended industry standard architecture，eisa)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本技术附图中的总线并不限定仅有一根总线或一种类型的总线。
131.处理器的具体实现过程可参见上述方法实施例，其实现原理和技术效果类似，本实施例此处不再赘述。
132.可选的，本技术还提供一种可读存储介质，可读存储介质中存储有计算机执行指令，当处理器执行计算机执行指令时，实现如上述的方法的步骤。
133.可选的，本技术实施例还提供一种计算机程序产品，包括计算机程序/指令，该计算机程序被处理器执行时实现上述方法的步骤。
134.本技术中，“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b的情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。
135.可以理解的是，在本技术的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本技术的实施例的范围。
136.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本技术的真正范围和精神由下面的权利要求书指出。
137.应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求书来限制。