一种车辆订单管理方法、装置、设备及计算机存储介质与流程

1.本技术实施例涉及订单管理技术领域，尤其涉及一种车辆订单管理方法、装置、设备及计算机存储介质。


背景技术：

2.近年来，随着互联网的发展，网络购车逐渐成为很多人喜欢的购物方式，这也大大方便了用户的生活。
3.在用户使用用户端（如手机、平板等）中的购车app或者购车小程序进行选购车辆的过程中，对于同一车型，提供给用户选择的车辆属性很多，例如包括版本、电池、外观、内饰、轮毂、选装等等，每种车辆属性的属性值也不少，比如，以车辆属性包括外观为例，则属性值可包括白色、黑色和蓝色等。
4.然而目前的车辆选购过程中，虽然可以通过用户端选购车辆，但是在选购车辆时只能选择商家预先配置好的有限的几种属性组合的车辆，由于选择有限，因此无法按照用户需求定制不同属性。


技术实现要素：

5.本技术实施例提供一种车辆订单管理方法、装置、设备及计算机存储介质，用以解决现有技术中无法按照用户需求定制车辆的不同属性，从而造成车辆选购体验差的问题。
6.第一方面，本技术实施例中提供了一种车辆订单管理方法，应用于第一服务端，包括：获取用户端发送的下单请求，所述下单请求中携带所选的第一下单信息，其中，所述第一下单信息中包括所选的多个车辆属性、多个车辆属性对应的属性值；将所述第一下单信息以及所述下单请求发送至第二服务端，以使所述第二服务端根据所述第一下单信息以及所述下单请求执行下单操作；其中，至少一个车辆属性的属性值在所述第二服务端存储的属性名称与在所述用户端存储的属性名称不同。
7.可选地，还包括：根据所述第一下单信息中所包含的多个车辆属性，确定对应的车辆字符串；根据所述车辆字符串匹配对应的第二下单信息，所述第二下单信息包括第一下单信息对应的车辆sku；将所述第二下单信息以及所述下单请求发送至第二服务器，以使所述第二服务端根据所述第二下单信息以及所述下单请求执行下单操作。
8.可选地，在所述获取第一服务器发送的下单请求之前，还包括：向所述用户端发送第一车辆属性，所述第一车辆属性包括前台类目属性、spu属性、商品属性、销售属性，所述前台类目属性用于在所述用户端存储；向所述第二服务端发送第二车辆属性，所述第二车辆属性包括后台类目属性、spu
属性、商品属性、销售属性，所述后台类目属性用于在所述第二服务端存储。
9.可选地，所述多个车辆属性包括必选属性以及非必选属性；在所述根据所述车辆字符串匹配对应的第二下单信息之前，还包括：根据至少一个所述必选属性，或者根据至少一个所述必选属性以及至少一个所述非必选属性，生成对应的第二下单信息；存储多个所述第二下单信息至匹配库；所述根据所述车辆字符串匹配对应的第二下单信息，包括：确定匹配库中每个第二下单信息对应的车辆字符串；利用所述车辆字符串与匹配库中每个第二下单信息对应的车辆字符串进行比较，以确定所述车辆字符串对应的第二下单信息。
10.可选地，还包括：若所述第二下单信息包含所述必选属性以及所述非必选属性，从预先配置好的资源库中查询出所包含的必选属性对应的多媒体资源，并配置非必选属性所对应的多媒体资源，生成所述第二下单信息对应的多媒体资源，其中，所述必选属性对应的多媒体资源用于展示所述必选属性，所述非必选属性所对应的多媒体资源用于展示所述非必选属性，所述资源库中包括至少一个所述必选属性所对应的多媒体资源。
11.可选地，在所述生成所述第二下单信息对应的多媒体资源，还包括：实时计算所述第二下单信息对应的车辆价格。
12.可选地，在所述根据所述车辆字符串匹配对应的第二下单信息之后，还包括：校对所述第二下单信息所对应的多个车辆属性与所选的第一下单信息中所包含的多个车辆属性是否一致；若是，则匹配成功；若否，则重新匹配。
13.第二方面，本技术实施例提供了一种车辆订单管理方法，应用于用户端，包括：显示第一车辆属性中多个车辆属性对应的多媒体资源；根据用户对所述第一车辆属性中多个车辆属性的选择操作，生成下单请求，所述下单请求中携带根据选择操作所生成的第一下单信息，所述第一下单信息中包括多个车辆属性、多个车辆属性对应的属性值；将所述下单请求发送至第一服务端，其中，所述多个车辆属性中的至少一个车辆属性的属性值在所述用户端存储的属性名称与在第二服务端存储的属性名称不同。
14.可选地，在所述显示第一车辆属性中多个车辆属性对应的多媒体资源之前，还包括：接收所述第一服务端发送的第一车辆属性并存储，所述第一车辆属性包括前台类目属性、spu属性、商品属性、销售属性。
15.可选地，在所述显示第一车辆属性中多个车辆属性对应的多媒体资源之前，还包括：根据当前展示页面以及当前订单类型，确定所要展示的车辆属性，并依据对应的资源搜索路径，获取所要展示的车辆属性对应的多媒体资源。
16.可选地，所述当前展示页面为至少两个不同的展示页面之一，所述当前订单类型为至少两种不同的订单类型之一；
所述根据当前展示页面以及当前订单类型，确定所要展示的车辆属性，并依据对应的资源搜索路径，获取所要展示的车辆属性对应的多媒体资源，包括：根据预先建立的规则，确定所要展示的车辆属性对应的资源搜索路径，所述规则中包含不同展示页面与不同订单类型的组合下，所要展示的车辆属性对应的资源搜索路径，所述资源搜索路径为从资源库中搜索多媒体资源的路径。
17.可选地，两个不同的展示页面包括首页、详情页，两种不同的订单类型包括盲订、大订/小订，不同展示页面与不同订单类型的组合包括：展示页面为首页以及订单类型为盲订的组合、展示页面为首页以及订单类型为大订/小订的组合、展示页面为详情页以及订单类型为盲订的组合、展示页面为详情页以及订单类型为大订/小订的组合；所述根据预先建立的规则，确定所要展示的车辆属性对应的资源搜索路径，包括：若当前展示页面为首页、当前订单类型为盲订时，确定所要展示的车辆属性包括作为前台类目属性以及作为后台类目属性，并将前台类目属性以及后台类目属性对应的多媒体资源的存储路径作为资源搜索路径；或者，当当前展示页面为首页，当前订单类型为大订或者小订时，确定所要展示的车辆属性包括前台类目属性以及后台类目属性，并将前台类目属性以及后台类目属性对应的多媒体资源的存储路径作为资源搜索路径；或者，当当前展示页面为详情页，当前订单类型为盲订时，确定所要展示的车辆属性包括前台类目属性，并将前台类目属性对应的多媒体资源的存储路径作为资源搜索路径；或者，当当前展示页面为详情页，当前订单类型为大订或者小订时，确定所要展示的车辆属性包括后台类目属性，并将后台类目属性对应的多媒体资源的存储路径作为资源搜索路径。
18.可选地，还包括：修改至少一个车辆属性中属性值对应的属性名称。
19.第三方面，本技术实施例提供了一种车辆订单管理方法，应用于第二服务端，包括：接收第一服务端发送的下单请求以及第一下单信息，所述第一下单信息中包括所选的多个车辆属性、多个车辆属性对应的属性值；根据所述第一下单信息执行下单操作；其中，至少一个车辆属性的属性值在所述第二服务端存储的属性名称与在所述用户端存储的属性名称不同。
20.可选地，所述根据所述第一单信息执行下单操作，包括：将所述第一下单信息转化为生产代码以及选装包的密码值，以根据所述生产代码以及选装包的密码值进行现车匹配或者向车辆生产车间发送生产所述生产代码以及选装包的密码值所对应车辆的请求。
21.可选地，还包括：接收第一服务端发送的第二车辆属性并存储，所述第二车辆属性包括后台类目属性、spu属性、商品属性、销售属性；修改至少一个车辆属性中属性值对应的属性名称。
22.第四方面，本技术实施例提供了一种车辆管理系统，包括第一服务端、第二服务端
以及用户端。
23.第五方面，本技术实施例提供了一种电子设备，包括存储组件及处理组件；所述存储组件存储一条或多条计算机程序指令，所述计算机程序指令供所述处理组件调用执行，所述处理组件执行所述一条或多条计算机程序指令以实现如上述第一方面所述的车辆订单管理方法、第二方面所述的车辆订单管理方法、第三方面所述的车辆订单管理方法。
24.第六方面，本技术实施例提供了一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序被计算机执行时实现如上述第一方面所述的车辆订单管理方法、第二方面所述的车辆订单管理方法、第三方面所述的车辆订单管理方法。
25.本技术实施例中，通过获取用户端发送的下单请求，所述下单请求中携带所选的第一下单信息，其中，所述第一下单信息中包括所选的多个车辆属性、多个车辆属性对应的属性值； 将所述第一下单信息以及所述下单请求发送至第二服务端，以使所述第二服务端根据所述第一下单信息以及所述下单请求执行下单操作，能够按照用户需求定制车辆的不同属性，提升了车辆选购体验。
26.本技术的这些方面或其他方面在以下实施例的描述中会更加简明易懂。
附图说明
27.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
28.图 1为本技术实施例提供的车辆订单管理系统的架构图；图2为本技术实施例提供的车辆属性划分为多个结构的示意图；图3为本技术实施例提供的一种车辆订单管理方法的流程图；图4为本技术实施例提供的另一种车辆订单管理方法的流程图；图5为本技术实施例提供的一种四象限规则的示意图；图6为本技术实施例提供的一种车辆属性树状结构的示意图；图7为本技术实施例提供的另一种车辆订单管理方法的流程图；图8为本技术实施例提供的一种车辆订单管理装置的结构示意图；图9为本技术实施例提供的另一种车辆订单管理装置的结构示意图；图10为本技术实施例提供的另一种车辆订单管理装置的结构示意图；图11为本技术实施例提供的一种电子设备的结构示意图。
具体实施方式
29.为了使本技术领域的人员更好地理解本技术方案，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述。
30.在本技术的说明书和权利要求书及上述附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如101、102等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可
以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。
31.在对本技术技术方案进行介绍之前，先对本技术涉及的相关概念进行简要介绍：（1）车辆sku：至少一个车辆属性通过笛卡尔积组合生成的sku，其中，库存量单位（stock keeping unit，简称sku），可以是物理上不可分割的最小存货单元，以件、盒、托盘等为单位。sku在使用时可根据不同业态，不同管理模式来处理。例如，灰色 64g 的 iphone7 是一个sku；air max90、蓝色、40码的nike跑鞋是一个sku。以本技术实施例所涉及的车辆订单管理为例，则车辆sku可包括车型、电池、轮毂、外观、内饰、选装包等通过笛卡尔积组合生成的sku，具体可根据所选的车辆属性生成其对应的车辆sku。
32.（2）标准化产品单元（standard product unit ，简称spu），是指一组可以复用、易检索的标准化信息集合，该集合描述了一个产品的特性。通俗点讲，属性值、特性相同的商品就可以称为一个spu。例如手机行业，iphone8就是一个spu，spu与商家，与颜色、款式、套餐都无关。以本技术实施例所涉及的车辆为例，则车辆spu是第一服务端对不同属性、规格但又同属同一系（如同一车型和电池）的车辆进行统一管理的编码。
33.（3）信息摘要算法（message-digest algorithm 5，简称md5）md5算法的作用是让大容量信息在用数字签名软件签署私人密匙前被"压缩"成一种保密的格式（就是把一个任意长度的字节串变换成一定长的大整数）。不管是md2、md4还是md5，它们都需要获得一个随机长度的信息并产生一个128位的信息摘要。
34.下面对本技术的技术方案进行介绍：发明人研究发现，随着互联网的发展，网络购车逐渐成为很多人喜欢的购物方式，这也大大方便了用户的生活。例如，用户可通过购车app或者购车小程序等渠道进行车辆选购。
35.在用户使用购车app或者购车小程序等渠道进行选购车辆的过程中，对于同一车型，提供给用户选择的车辆属性很多，例如包括版本、电池、外观、内饰、轮毂、选装等等，每种车辆属性的属性值也不少，比如，以车辆属性包括外观为例，则属性值可包括白色、黑色和蓝色等；以车辆属性包括版本为例，则属性值可包括单电机版、双电机版等。
36.然而目前的车辆选购过程中，虽然可以通过用户端的购车app等渠道选购车辆，但是在选购车辆时只能选择商家预先配置好的有限的几种属性组合的车辆，由于选择有限，因此无法按照用户需求定制不同属性，从而造成用户购车体验差的问题。不仅如此，目前的车辆选购过程，在用户端所展示的车辆属性的属性名称只能是汽车生产商默认的属性名称，无法根据需求在用户端上设定车辆属性对应的属性名称，进一步地造成用户购车体验差的问题。具体而言，目前的购车流程需要服务端预先对用户端（购车app或者购车小程序等所在的用户设备）进行数据配置，具体包括配置用户端所展示的信息（包括车辆属性以及车辆属性对应的属性名称，如版本（如单电机版）以及版本对应版本名称（如常规版）等），并且服务端需要对这些车辆属性以及车辆属性对应的属性名称进行统一管理和运营，使得用户端不能够根据需求修改所展示的“属性名称
”ꢀ
（例如，不能够根据节日、时间等采取不同的措施进行个性化定义展示的“属性名称”），造成用户车辆选购体验差的问题。
37.针对上述现存方案中无法按照用户需求定制车辆不同属性的问题，发明人经过研究发现，通过在用户端展示不同车辆属性对应的选项，以供用户根据需求选择，能够解决无
法按照用户需求定制车辆不同属性的问题。
38.基于上述过程，发明人提出了一种车辆订单管理方法，应用于第一服务端，该方法通过获取用户端发送的下单请求，下单请求中携带所选的第一下单信息，其中，第一下单信息中包括所选的多个车辆属性、多个车辆属性对应的属性值； 将第一下单信息以及下单请求发送至第二服务端，以使第二服务端根据第一下单信息以及下单请求执行下单操作，能够实现按照用户需求定制车辆的不同属性的功能，从而提升了用户的车辆选购体验。
39.针对上述现存方案中无法根据需求在用户端上设定车辆属性对应的属性名称的问题，发明人经过研究发现，个性化的属性名称相较于统一配置的属性名称能够有利于提升用户的车辆选购体验。例如，以服务端统一配置的车辆属性中的版本为例，版本对应的属性值可包括单电机版和双电机版，其对应的属性名称也可以默认为单电机版和双电机版，然而对于不熟悉车辆属性的用户而言，并不能够从“单电机版”、“双电机版”直观感受到车辆版本，而倘若将“单电机版”在用户端展示为“常规版”，将“双电机版”在用户端展示为“豪华版”则更能够使用户更直观感受到两个版本的区别。再例如，以服务端统一配置的车辆属性中的外观为例，其对应的属性值包括黑色、白色、粉色等其对应的属性名称也可以默认为黑色、白色、粉色等（如车辆属性：外观，属性值：粉，属性名称：粉色），而倘若将“粉色”在用户端展示为“女神粉”（即车辆属性：外观，属性值：粉色，属性名称：女神粉），通过使用吸引大众字眼，有效提高用户网上购车浏览体验。
40.经过发明人实验论证发现，设置至少一个车辆属性的属性值在第二服务端存储的属性名称与在用户端存储的属性名称不同，能够有效提升用户的车辆选购体验。
41.但发明人考虑到，若在用户端中增加个性化设定属性名称的功能，而不做其他处理的话，会因为用户端与服务端之间属性名称不统一的原因，使得用户在通过用户端进行下单后，服务端需要核对用户端的属性名称在服务端对应的属性名称，再执行下单操作，如此以来容易造成下单速度慢的问题。
42.基于上述情况，发明人进一步研究发现，在设置至少一个车辆属性的属性值在第二服务端存储的属性名称与在用户端存储的属性名称不同之后，还可以根据用户下单时所选车辆属性生成对应的车辆字符串（如车辆md5值），再根据车辆字符串匹配对应第二下单信息（即车辆sku）进行下单，能够避免上述问题。这是考虑到即使修改后了属性名称，其本质不变（以车辆属性包括外观，属性值包括粉为例，若将该属性值的属性名称设置为“女神粉”并展示该属性名称供用户选择，实际上该属性名称并不影响用户实际所选择的属性值），并不会影响车辆字符串，因此通过车辆字符串所匹配的车辆sku进行下单操作，避免了服务端需要核对用户端的属性名称在服务端对应的属性名称造成下单速度慢的问题，提升了下单速度，以及用户的购车体验。
43.基于上述过程，发明人提出了一种车辆订单管理方法，该方法获取用户端发送的下单请求，下单请求中携带所选的第一下单信息，其中，第一下单信息中包括所选的多个车辆属性、多个车辆属性对应的属性值； 根据第一下单信息中所包含的多个车辆属性，确定对应的车辆字符串；根据车辆字符串匹配对应的第二下单信息，第二下单信息包括第一下单信息对应的车辆sku；将第二下单信息以及下单请求发送至第二服务器，以使第二服务端根据第二下单信息以及下单请求执行下单操作，能够进一步提升用户的车辆选购体验。
44.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完
整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
45.图1为本技术实施例提供的车辆订单管理系统的架构图，如图1所示，该系统包括：第一服务端1、用户端2以及第二服务端3。
46.其中，第一服务端1可以为服务器设备，其可以实现为单个服务器，也可以实现为由多个服务器组成的服务器集群，服务器可以是分布式系统的服务器或者是结合区块链的服务器，服务器也可以是云服务器，或者是带人工智能技术的智能云计算服务器或智能云主机等。
47.本技术实施例中，第一服务端1用于获取用户端2发送的下单请求，下单请求中携带所选的第一下单信息，第一下单信息中包括所选的多个车辆属性、多个车辆属性对应的属性值；将第一下单信息以及下单请求发送至第二服务端3。
48.用户端2可以为浏览器、app（application，应用程序）、或网页应用如h5（hypertext 至少一arkup language5，超文本标记语言第5版）应用、或轻应用（也被称为小程序，一种轻量级应用程序）或云应用等，客户端可以部署在电子设备中，需要依赖设备运行或者设备中的某些app而运行等。电子设备例如可以具有显示屏并支持信息浏览等，如可以是个人移动终端如手机、平板电脑、个人计算机、电视机等。
49.本技术实施例中，用户端2包括显示装置，其中显示装置用于显示第一车辆属性中多个车辆属性对应的多媒体资源，多媒体资源包括但不限于：图片、音频、视频等。
50.用户端2还包括处理器，其中处理器用于根据用户对第一车辆属性中多个车辆属性的选择操作，生成下单请求，下单请求中携带根据选择操作所生成的第一下单信息，第一下单信息中包括多个车辆属性、多个车辆属性对应的属性值；将下单请求发送至第一服务端1。
51.其中，第一车辆属性包括前台类目属性、spu属性、商品属性、销售属性。
52.需要说明的是，目前的购车方案中并没有对车辆属性进行划分，而本技术将多个车辆属性划分为以下五层结构，具体如图2所示，在图2中，多个车辆属性可包括前台类目属性、后台类目属性、spu属性、商品属性、销售属性这五层结构。可选地，前台类目属性可包括车型以及版本。通常情况下，前台类目属性由用户端2维护，用户端2可根据需求设定该版本中属性值所对应的属性名称。
53.后台类目属性可包括车型以及版本。通常情况下，后台类目属性由第二服务端3维护，第二服务端3可根据需求选择是否设定该版本中属性值所对应的属性名称。
54.车辆spu可包括车型以及电池。
55.商品属性可包括车辆、电池、外观、内饰、选装包等车辆属性。
56.销售属性是指车辆sku，其中，车辆sku可包括由车辆、电池、外观、内饰、选装包等车辆属性通过笛卡尔积组合生成的sku。
57.第二服务端3同样可以为服务器设备，其可以实现为单个服务器，也可以实现为由多个服务器组成的服务器集群，服务器可以是分布式系统的服务器或者是结合区块链的服务器，服务器也可以是云服务器，或者是带人工智能技术的智能云计算服务器或智能云主机等。
58.具体地，第二服务端3可包括商家所使用的服务端。
59.本技术实施例中，第二服务端3用于接收第一服务端1发送的下单请求以及第一下单信息，第一下单信息中包括所选的多个车辆属性、多个车辆属性对应的属性值；根据第一下单信息执行下单操作；其中，至少一个车辆属性的属性值在第二服务端存储的属性名称与在用户端存储的属性名称不同。
60.以下将对本技术的车辆订单管理方法进行详细阐述。
61.图3为本技术实施例提供的一种车辆订单管理方法的流程图，该方法应用于第一服务器1，如图3所示，该方法可以包括以下步骤：301、获取用户端发送的下单请求，下单请求中携带所选的第一下单信息。
62.在该步骤中，第一下单信息中包括所选的多个车辆属性、多个车辆属性对应的属性值。在实际应用中，多个车辆属性包括但不限于：版本、电池、外观等。而本技术实施例中，将多个车辆属性划分为前台类目属性、后台类目属性、spu属性、商品属性、销售属性。以车辆属性包括版本为例，版本对应的属性值可包括单电机版或者双电机版。
63.本技术实施例中，用户端的显示界面显示有多个车辆属性对应的选项（属性值）以可供用户选择，当用户选择完毕并提交后，用户端根据用户所选生成第一下单信息，并向第一服务器1发送下单请求，下单请求中携带该第一下单信息。
64.需要说明的是，本技术实施例中，所获取的第一下单信息中的车辆属性对应的属性值中，有至少一个车辆属性的属性值在第二服务端存储的属性名称与在用户端存储的属性名称不同。例如，针对车辆属性为版本而言，其对应的属性值可包括单电机版和双电机版，其属性值对应的属性名称包括单电机版和双电机版。当然也可以根据需求，设定其对应的属性值包括0和1，其中，0对应的属性名称为单电机版，1对应的属性名称为双电机版。而在本技术实施例中，用户端所存储的版本其对应的属性值包括0和1，其中，0对应的属性名称为常规版，1对应的属性名称为豪华版，而在第二服务端中存储的版本其对应的属性值包括0和1，其中，0对应的属性名称为单电机版，1对应的属性名称为双电机版，即两端针对于版本属性值（0和1）所存储的属性名称不同。
65.通过设置至少一个车辆属性的属性值在第二服务端存储的属性名称与在用户端存储的属性名称不同，能够根据需求在用户端上设定车辆属性对应的属性名称，以便于用户能够更为直观的了解到车辆属性，从而提高用户的购车体验。
66.例如，第一服务端在用户端配置外观这一车辆属性的三个属性值（黑色、白色、粉色）对应的属性名称分别为：时尚黑、典雅白、女神粉，而在第二服务端中采用默认属性名称，即在第二服务端中外观这一车辆属性的三个属性值（黑色、白色、粉色）对应的属性名称分别为：黑色、白色、粉色。通过使用吸引大众字眼，有效提高用户网上购车浏览体验。
67.作为一种可能实现的方案，在步骤301之后，还包括：302、将第一下单信息以及下单请求发送至第二服务端，以使第二服务端根据第一下单信息以及下单请求执行下单操作。
68.本技术实施例中，第二服务端可根据第一下单信息中所包含的车辆属性和车辆属性对应的属性值进行下单操作，具体地，可将第一下单信息中所包含的车辆属性和车辆属性对应的属性值转化为生产代码，通过该生产代码进行现车匹配或者向车辆生产车间发送生产该生产代码所对应车辆的请求。
69.作为另一种可能实现的方案，在步骤301之后，还包括：302’、根据第一下单信息中所包含的多个车辆属性，确定对应的车辆字符串；根据车辆字符串匹配对应的第二下单信息，第二下单信息包括第一下单信息对应的车辆sku；将第二下单信息以及下单请求发送至第二服务器，以使第二服务端根据第二下单信息以及下单请求执行下单操作。
70.该步骤中，每个车辆属性所形成的车辆字符串具有唯一性。第二下单信息包括第一下单信息对应的车辆sku，以下将第二下单信息简称为车辆sku。
71.本技术实施例中，该方案与上述方案区别在于本技术考虑到个性化的属性名称可能会造成下单速度慢的问题，因此针对这一问题，可先将第一下单信息转化为第二下单信息，再通过第二下单信息执行上述的下单操作。
72.可选地，车辆字符串可以是md5值，具体地，第一服务端可根据md5算法，对第一下单信息中所包含的多个车辆属性进行计算，得到其对应的md5值。
73.在上述过程中，可根据md5算法，将第一下单信息中所包含的多个车辆属性转化为明文字符串后，再转换为128位的哈希值，该128位哈希值即为多个车辆属性对应的md5值。
74.本技术实施例中，作为一种可能实现的方案，步骤302’中的“根据车辆字符串匹配对应的车辆sku”的过程可通过确定匹配库中每个第二下单信息对应的车辆字符串；利用车辆字符串与匹配库中每个第二下单信息对应的车辆字符串进行比较，以确定车辆字符串对应的第二下单信息。
75.需要说明的是，在确定匹配库中每个车辆sku对应的车辆字符串之前，还需要预先建立匹配库，且匹配库中包括多个车辆sku及其每个车辆sku对应的车辆字符串之间的映射关系。
76.可选地，多个车辆属性包括必选属性以及非必选属性，建立匹配库的过程可包括：根据至少一个必选属性，或者根据至少一个必选属性以及至少一个非必选属性，生成对应的车辆sku，并存储多个车辆sku至匹配库。此外，还需要确定每个车辆sku对应的车辆字符串，并建立多个车辆sku及其每个车辆sku对应的车辆字符串之间的映射关系，其中，确定方式可参照上述根据多个车辆属性确定对应的车辆字符串的过程，此处不再累述。
77.在上述过程中，若车辆sku包含必选属性以及非必选属性，从预先配置好的资源库中查询出所包含的必选属性对应的多媒体资源，并配置获取非必选属性所对应的多媒体资源，以生成车辆下单信息第二下单信息对应的多媒体资源。
78.其中，必选属性对应的多媒体资源用于展示必选属性，非必选属性所对应的多媒体资源用于展示非必选属性，资源列表资源库中包括至少一个必选属性所对应的多媒体资源。
79.需要说明的是，本技术实施例通过划分必选属性以及非必选属性的目的在于：根据至少一个必选属性，生成对应的第二下单信息或者根据至少一个必选属性以及至少一个非必选属性，生成对应的第二下单信息，有利于后续第二下单信息的多媒体资源配置，以减少第二下单信息的多媒体资源配置工作量，提高第二下单信息的多媒体资源配置效率。也就是说，必选属性对应的多媒体资源为预先配置好，并存储于资源库中，而非必选属性对应的多媒体资源未预先配置，而是根据用户所选的非必选属性再进行多媒体资源的配置以及价格的实时计算。
80.需要说明的是，现存方案并不划分必选属性以及非必选属性，而是任一车辆属性及其任意组合都需要逐条配置多媒体资源。例如，以多个车辆属性包括车型、版本、外观为例，其中，车型的属性值包括车型a；版本包括版本a；外观包括外观a，选装包包括选装包a、选装包b、选装包c等，则现存方案需要对车型a、版本a、外观a、车型a-版本a、车型a-版本a-外观a、车型a-版本a-外观a-选装包a、车型a-版本a-外观a-选装包b等多种方案生成对应的第二下单信息，并分别配置每个第二下单信息对应的多媒体资源，造成配置工作量较大的问题。
81.而本技术通过上述方案，划分了必选属性以及非必选属性之后，有利于后续车辆sku的多媒体资源配置，以减少车辆sku的多媒体资源配置工作量，提高车辆sku的多媒体资源配置效率。例如，将车型、版本、设置为购车必选属性，选装包设置为购车非必选属性，在同样生成车辆sku后，只需要从资源库中查询出预先配置好的必选属性对应的多媒体资源，再对非必选属性进行多媒体资源的配置，以生成车辆sku对应的多媒体资源，再计算车辆sku对应的车辆价格。以车型的属性值包括车型a；版本包括版本a；外观包括外观a，选装包包括选装包a、选装包b、选装包c等为例，则只需要配置对车型a、版本a、外观a、车型a-版本a、车型a-版本a-外观a这几个车辆sku对应的多媒体资源即可，而关于其他包含选装包的车辆sku无需预先配置多媒体资源，只需要在确定车辆sku包含选装包后，先从资源列表中确定所包含的购车必选车辆属性对应的多媒体资源，并获取购车非必选车辆属性所对应的多媒体资源，以生成车辆sku对应的多媒体资源。例如，某一车辆sku为“车型a-版本a-外观a-选装包a”，只需要从资源列表中继承“车型a-版本a-外观a”这一车辆sku对应的多媒体，再获取“选装包a”这一车辆sku对应的多媒体，再进行组合，得到“车型a-版本a-外观a-选装包a”这一车辆sku对应的多媒体资源。相较于现存方案，本技术实施例的方案减少了对“选装包a、选装包b、车型a-版本a-外观a-选装包a、车型a-版本a-外观a-选装包b等多种方案”对应的车辆sku对应的多媒体资源配置，从而节省了人工成本，减少了配置工作量，提高了多媒体资源配置效率。
82.在步骤302’之后，该方法还包括：步骤303’、校对第二下单信息所对应的多个车辆属性与所选的第一下单信息中所包含的多个车辆属性是否一致；若是，则匹配成功；若否，则重新匹配。
83.本技术实施例中，在根据车辆字符串匹配对应的第二下单信息之后，进一步通过校对第二下单信息所对应的多个车辆属性与所选的第一下单信息中所包含的多个车辆属性是否一致，能够提高所匹配第二下单信息的准确性。
84.图4为本技术实施例提供的另一种车辆订单管理方法的流程图，该方法应用于用户端，如图4所示，该方法可以包括以下步骤：401、接收第一服务端发送的第一车辆属性并存储。
85.在该步骤中，第一车辆属性包括前台类目属性、spu属性、商品属性、销售属性，前台类目属性用于在用户端存储。
86.本技术实施例中，第一服务端还用于向用户端发送第一车辆属性，以供用户端获取第一车辆属性中多个车辆属性对应的多媒体资源并显示。
87.402、根据当前展示页面以及当前订单类型，确定所要展示的车辆属性，并依据对应的资源搜索路径，获取所要展示的车辆属性对应的多媒体资源。
88.在该步骤中，当前展示页面为至少两个不同的展示页面之一，当前订单类型为至少两种不同的订单类型之一。
89.本技术实施例中，作为一种可能实现的方案，用户端可根据预先建立的规则，确定所要展示的车辆属性对应的资源搜索路径，规则中包含不同展示页面与不同订单类型的组合下，所要展示的车辆属性对应的资源搜索路径，资源搜索路径为从资源库中搜索多媒体资源的路径。
90.可选地，两个不同的展示页面包括首页、详情页，两种不同的订单类型包括盲订、大订/小订，不同展示页面与不同订单类型的组合包括：展示页面为首页以及订单类型为盲订的组合、展示页面为首页以及订单类型为大订/小订的组合、展示页面为详情页以及订单类型为盲订的组合、展示页面为详情页以及订单类型为大订/小订的组合，其中，盲订可以理解为车辆生产商目前只公开了车辆外观，但是未公开具体车辆结构以及其他的车辆属性等。小订可以理解为车辆生产商目前只公开了车辆外观和部分车辆结构（如车辆包括四个轮毂、单电机等）大订可以理解为车辆生产商目前公开了车辆外观、车辆结构以及车辆属性。“/”表示或的意思。
91.作为一种示例，若当前展示页面为首页、当前订单类型为盲订时，确定所要展示的车辆属性包括作为前台类目属性以及作为后台类目属性，并将前台类目属性以及后台类目属性对应的多媒体资源的存储路径作为资源搜索路径。
92.作为另一种示例，当当前展示页面为首页，当前订单类型为大订或者小订时，确定所要展示的车辆属性包括前台类目属性以及后台类目属性，并将前台类目属性以及后台类目属性对应的多媒体资源的存储路径作为资源搜索路径。
93.作为另一种示例，当当前展示页面为详情页，当前订单类型为盲订时，确定所要展示的车辆属性包括前台类目属性，并将前台类目属性对应的多媒体资源的存储路径作为资源搜索路径。
94.作为另一种示例，当当前展示页面为详情页，当前订单类型为大订或者小订时，确定所要展示的车辆属性包括后台类目属性，并将后台类目属性对应的多媒体资源的存储路径作为资源搜索路径。
95.本技术实施例中，具体可根据需求设定不同展示页面所处位置以及不同订单类型所要展示的多媒体资源。例如，可设定当展示页面所处位置为首页、订单类型包括盲订时，所要展示的车辆属性包括“外观”这一车辆属性，通过判断“外观”这一车辆属性是否为前台类目属性或者后台类型属性，从而确定出这一车辆属性对应多媒体资源的资源搜索路径。
96.在实际应用中，预先建立的规则可以是一种四象限规则，如图5所示，在图5中，第一象限为“当前展示页面为首页、当前订单类型为盲订时，确定所要展示的车辆属性包括作为非叶子的前台类目属性以及作为非叶子的后台类目属性，并将作为非叶子的前台类目属性以及作为非叶子的后台类目属性对应的多媒体资源的存储路径作为资源搜索路径，即资源搜索路径为：非叶子前台类目属性-》非叶子后台类目属性-》多媒体资源”。
97.其中，确定前台类目属性、后台类目属性是否属于叶子还是非叶子可根据需求设定。例如，本技术实施例中，如图6所示，以某一轿车为例，前台类目属性中包括车型a和版本a、版本b，其中，车型a则为非叶子前台类目属性，版本a和版本b为叶子前台类型属性。
98.第二象限为“当当前展示页面为首页，当前订单类型为大订或者小订时，确定所要
展示的车辆属性包括前台类目属性以及后台类目属性，并将前台类目属性以及后台类目属性对应的多媒体资源的存储路径作为资源搜索路径，即资源搜索路径为：非叶子前台类目属性-》非叶子后台类目属性-》多媒体资源”；第三象限为“当当前展示页面为详情页，当前订单类型为盲订时，确定所要展示的车辆属性包括前台类目属性，并将前台类目属性对应的多媒体资源的存储路径作为资源搜索路径，即资源搜索路径为：叶子前台类目属性
ꢀ‑
》多媒体资源”；第四象限为“当当前展示页面为详情页，当前订单类型为大订或者小订时，确定所要展示的车辆属性包括后台类目属性，并将后台类目属性对应的多媒体资源的存储路径作为资源搜索路径，即资源搜索路径为：叶子后台类目属性-》多媒体资源”。
99.403、显示第一车辆属性中多个车辆属性对应的多媒体资源；本技术实施例中，用户端的显示装置显示第一车辆属性中多个车辆属性对应的多媒体资源的方式有多种：作为一种可能实现的方案，用户端的显示界面显示有多个车辆属性对应的多媒体资源。可选地，界面显示有全部车辆属性可供用户选择，当用户选择任一车辆属性中的任一选项（属性值）后，可显示对应选项的多媒体资源。例如，用户选择了外观这一车辆属性中的“红色”这一属性值，则在显示界面中展示有外观为红色的车辆模型。
100.作为另一种可能实现的方案，用户端的界面显示有部分车辆属性可供用户选择，当用户选择任一车辆属性后，展开与这一车辆属性相关联的其他车辆属性以供用户选择。例如，用户选择选装包这一车辆属性后，展示与“选装包”相关联的其他车辆属性（如座椅材质、座椅加热功能、座椅按摩功能等），以供用户选择。
101.404、根据用户对第一车辆属性中多个车辆属性的选择操作，生成下单请求，下单请求中携带根据选择操作所生成的第一下单信息，第一下单信息中包括多个车辆属性、多个车辆属性对应的属性值。
102.本技术实施例中，其中，第一服务端用以根据第一下单信息中所包含的多个车辆属性，确定对应的车辆字符串；根据车辆字符串匹配对应的第二下单信息，并将第二下单信息发送至第二服务端，以使第二服务端器根据第二下单信息执行下单操作。
103.405、将下单请求发送至第一服务端。
104.进一步地，该方法还包括：修改至少一个车辆属性中属性值对应的属性名称。
105.本技术实施例中，用户端还用于在接收第一服务端发送的第一车辆属性之后，对任一车辆属性中属性值对应的属性名称进行修改，以实现多个车辆属性中的至少一个车辆属性的属性值在用户端存储的属性名称与在第二服务端存储的属性名称不同。
106.当然，也可以是第一服务端所发送的第一车辆属性，该第一车辆属性中至少一个车辆属性的属性值在用户端存储的属性名称与在第二服务端存储的属性名称不同，用户端在接受该第一车辆属性后，再根据需求进行二次修改属性名称，本技术对此不作限定。
107.通过修改至少一个车辆属性中属性值对应的属性名称，能够解决现存技术中无法根据需求在用户端上设定车辆属性对应的属性名称的问题，有效提高用户网上购车浏览体验。
108.图7为本技术实施例提供的另一种车辆订单管理方法的流程图，如图7所示，该方法应用于第二服务端，该方法可以包括以下步骤：
501、接收第一服务端发送的下单请求以及第一下单信息，第一下单信息中包括所选的多个车辆属性、多个车辆属性对应的属性值；在该步骤中，第二下单信息由第一服务端获取用户端发送的下单请求，下单请求中携带所选的第一下单信息，第一下单信息中包括所选的多个车辆属性、多个车辆属性对应的属性值。
109.502、根据第一下单信息执行下单操作。
110.其中，至少一个车辆属性的属性值在第二服务端存储的属性名称与在用户端存储的属性名称不同。
111.当然除了上述步骤501-502的下单方式之外，第二服务端还可以接收第一服务端发送的第二下单信息，根据第二下单信息执行下单操作，其中，第二下单信息是根据第一下单信息中所包含的多个车辆属性，确定对应的车辆字符串，再根据车辆字符串匹配进行匹配所得到的下单信息。
112.两种下单方式的区别在于：本技术考虑到由于车辆属性对应的属性名称在用户端和第二服务端不同步的问题，可能会导致第一服务端或者第二服务端在进行下单操作时需要人工或者其他方式进行确定不同的属性名称是否属于同一属性值的问题，从而造成下单速度慢的问题，因此通过使用第二下单信息执行下单操作的方案（由于第二下单信息是通过将第一下单信息转换为字符串进行匹配所得到的车辆sku，因此即使属性名称不同，其所对应的字符串不变），能够有利于提升下单速度，进一步提升用户的购车体验。
113.本技术实施例中，作为一种可能实现的方案，步骤402可包括：将第一下单信息转化为生产代码以及选装包的密码值，以根据生产代码以及选装包的密码值进行现车匹配或者向车辆生产车间发送生产该生产代码以及选装包的密码值所对应车辆的请求。
114.具体地，将第一下单信息转化为生产代码以及选装包的密码值，以根据生产代码以及选装包的密码值进行现车匹配或者向车辆生产车间发送生产该生产代码以及选装包的密码值所对应车辆的请求。
115.进一步地，该方法还包括：接收第一服务端发送的第二车辆属性并存储，第二车辆属性包括后台类目属性、spu属性、商品属性、销售属性。
116.该方法还包括：修改至少一个车辆属性中属性值对应的属性名称。
117.如图8所示，为本技术提供的一种车辆订单管理装置的结构示意图，该装置可以包括以下模块：第一获取模块81，用于获取用户端发送的下单请求，所述下单请求中携带所选的第一下单信息，其中，所述第一下单信息中包括所选的多个车辆属性、多个车辆属性对应的属性值；第一发送模块82，用于将所述第一下单信息以及所述下单请求发送至第二服务端，以使所述第二服务端根据所述第一下单信息以及所述下单请求执行下单操作；其中，至少一个车辆属性的属性值在所述第二服务端存储的属性名称与在所述用户端存储的属性名称不同。
118.可选地，该装置还包括：第一确定模块83和第一匹配模块84；第一确定模块83，用于根据所述第一下单信息中所包含的多个车辆属性，确定对应的车辆字符串；
第一匹配模块84，用于根据所述车辆字符串匹配对应的第二下单信息，所述第二下单信息包括第一下单信息对应的车辆sku；第一发送模块82还用于将所述第二下单信息以及所述下单请求发送至第二服务器，以使所述第二服务端根据所述第二下单信息以及所述下单请求执行下单操作。
119.可选地，该装置的第一发送模块82还用于向所述用户端发送第一车辆属性，所述第一车辆属性包括前台类目属性、spu属性、商品属性、销售属性，所述前台类目属性用于在所述用户端存储；第一发送模块82还用于向所述第二服务端发送第二车辆属性，所述第二车辆属性包括后台类目属性、spu属性、商品属性、销售属性，所述后台类目属性用于在所述第二服务端存储。
120.可选地，所述多个车辆属性包括必选属性以及非必选属性；该装置还包括：第一处理模块85；第一处理模块85用于根据至少一个所述必选属性，或者根据至少一个所述必选属性以及至少一个所述非必选属性，生成对应的第二下单信息；存储多个所述第二下单信息至匹配库；第一匹配模块84具体用于确定匹配库中每个第二下单信息对应的车辆字符串；利用所述车辆字符串与匹配库中每个第二下单信息对应的车辆字符串进行比较，以确定所述车辆字符串对应的第二下单信息。
121.可选地，该装置的第一处理模块85还用于若所述第二下单信息包含所述必选属性以及所述非必选属性，从预先配置好的资源库中查询出所包含的必选属性对应的多媒体资源，并配置非必选属性所对应的多媒体资源，生成所述第二下单信息对应的多媒体资源，其中，所述必选属性对应的多媒体资源用于展示所述必选属性，所述非必选属性所对应的多媒体资源用于展示所述非必选属性，所述资源库中包括至少一个所述必选属性所对应的多媒体资源。
122.可选地，该装置的第一处理模块85还用于实时计算所述第二下单信息对应的车辆价格。
123.可选地，该装置还包括校对模块86；校对模块86用于校对所述第二下单信息所对应的多个车辆属性与所选的第一下单信息中所包含的多个车辆属性是否一致；若是，则匹配成功；若否，则重新匹配。
124.图8所述的车辆订单管理装置可以执行图3所示实施例所述的车辆订单管理方法，其实现原理和技术效果不再赘述。对于上述实施例中的车辆订单管理装置其中各个模块、单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
125.如图9所示，为本技术提供的一种车辆订单管理装置的结构示意图，该装置可以包括以下模块：第二显示模块91，用于显示第一车辆属性中多个车辆属性对应的多媒体资源；第二生成模块92，用于根据用户对所述第一车辆属性中多个车辆属性的选择操作，生成下单请求，所述下单请求中携带根据选择操作所生成的第一下单信息，所述第一下单信息中包括多个车辆属性、多个车辆属性对应的属性值；
第二发送模块93，用于将所述下单请求发送至第一服务端，其中，所述多个车辆属性中的至少一个车辆属性的属性值在所述用户端存储的属性名称与在第二服务端存储的属性名称不同。
126.可选地，该装置还包括第二接收模块94；第一接收模块94，用于接收所述第一服务端发送的第一车辆属性并存储，所述第一车辆属性包括前台类目属性、spu属性、商品属性、销售属性。
127.可选地，该装置还包括第二确定模块95；第二确定模块95，用于根据当前展示页面以及当前订单类型，确定所要展示的车辆属性，并依据对应的资源搜索路径，获取所要展示的车辆属性对应的多媒体资源。
128.可选地，所述当前展示页面为至少两个不同的展示页面之一，所述当前订单类型为至少两种不同的订单类型之一；该装置的第二确定模块95具体用于根据预先建立的规则，确定所要展示的车辆属性对应的资源搜索路径，所述规则中包含不同展示页面与不同订单类型的组合下，所要展示的车辆属性对应的资源搜索路径，所述资源搜索路径为从资源库中搜索多媒体资源的路径。
129.可选地，两个不同的展示页面包括首页、详情页，两种不同的订单类型包括盲订、大订/小订，不同展示页面与不同订单类型的组合包括：展示页面为首页以及订单类型为盲订的组合、展示页面为首页以及订单类型为大订/小订的组合、展示页面为详情页以及订单类型为盲订的组合、展示页面为详情页以及订单类型为大订/小订的组合；该装置的第二确定模块95具体用于若当前展示页面为首页、当前订单类型为盲订时，确定所要展示的车辆属性包括作为前台类目属性以及作为后台类目属性，并将前台类目属性以及后台类目属性对应的多媒体资源的存储路径作为资源搜索路径；或者，当当前展示页面为首页，当前订单类型为大订或者小订时，确定所要展示的车辆属性包括前台类目属性以及后台类目属性，并将前台类目属性以及后台类目属性对应的多媒体资源的存储路径作为资源搜索路径；或者，当当前展示页面为详情页，当前订单类型为盲订时，确定所要展示的车辆属性包括前台类目属性，并将前台类目属性对应的多媒体资源的存储路径作为资源搜索路径；或者，当当前展示页面为详情页，当前订单类型为大订或者小订时，确定所要展示的车辆属性包括后台类目属性，并将后台类目属性对应的多媒体资源的存储路径作为资源搜索路径。
130.可选地，该装置还包括：第二处理模块96；第二处理模块96用于修改至少一个车辆属性中属性值对应的属性名称。
131.图9所述的车辆订单管理装置可以执行图4所示实施例所述的车辆订单管理方法，其实现原理和技术效果不再赘述。对于上述实施例中的车辆订单管理装置其中各个模块、单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
132.如图10所示，为本技术提供的一种车辆订单管理装置的结构示意图，该装置可以包括以下模块：第三接收模块101，用于接收第一服务端发送的下单请求以及第一下单信息，所述第一下单信息中包括所选的多个车辆属性、多个车辆属性对应的属性值；
第三下单模块102，用于根据所述第一下单信息执行下单操作；其中，至少一个车辆属性的属性值在所述第二服务端存储的属性名称与在所述用户端存储的属性名称不同。
133.可选地，该装置的第三下单模块102具体用于将所述第一下单信息转化为生产代码以及选装包的密码值，以根据所述生产代码以及选装包的密码值进行现车匹配或者向车辆生产车间发送生产所述生产代码以及选装包的密码值所对应车辆的请求。
134.可选地，该装置的第三接收模块101还用于接收第一服务端发送的第二车辆属性并存储，所述第二车辆属性包括后台类目属性、spu属性、商品属性、销售属性；可选地，该装置还包括：第三处理模块103；第三处理模块103，用于修改至少一个车辆属性中属性值对应的属性名称。
135.图10所述的车辆订单管理装置可以执行图7所示实施例所述的车辆订单管理方法，其实现原理和技术效果不再赘述。对于上述实施例中的车辆订单管理装置其中各个模块、单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。
136.本技术实施例还提供了一种电子设备，如图11所示，该设备可以包括存储组件111及处理组件112；该存储组件111存储一条或多条计算机程序指令，其中，一条或多条计算机程序指令供处理组件112调用执行，以实现图3所示的车辆订单管理方法，或者图4所述的车辆订单管理方法，或者图7所述的车辆订单管理方法。
137.实际应用中，该计算设备可以实现为如图1所示系统架构中的第一服务端1。
138.当然，上述计算设备必然还可以包括其他部件，例如输入/输出接口、通信组件等。
139.输入/输出接口为处理组件和外围接口模块之间提供接口，上述外围接口模块可以是输出设备、输入设备等。通信组件被配置为便于计算设备和其他设备之间有线或无线方式的通信等。
140.本技术实施例还提供了一种计算机程序产品，存储有计算机程序或者计算机存储介质，该计算机程序或者计算机存储介质被计算机执行时可以实现图3所示的车辆订单管理方法，或者图4所述的车辆订单管理方法，或者图7所述的车辆订单管理方法。该计算机可读介质可以是上述实施例中描述的计算设备中所包含的；也可以是单独存在，而未装配入该计算设备中。
141.在这样的实施例中，计算机程序可以是从网络上被下载和安装，和/或从可拆卸介质被安装。在该计算机程序被处理器执行时，执行本技术的系统中限定的各种功能。
142.需要说明的是，上述计算设备可以为物理设备或者云计算平台提供的弹性计算主机等。其可以实现成多个服务器或终端设备组成的分布式集群，也可以实现成单个服务器或单个终端设备。
143.前文相应实施例中涉及的处理组件可以包括一个或多个处理器来执行计算机指令，以完成上述的方法中的全部或部分步骤。当然处理组件也可以为一个或多个应用专用集成电路（asic）、数字信号处理器（dsp）、数字信号处理设备（dspd）、可编程逻辑器件（pld）、现场可编程门阵列（fpga）、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。
144.存储组件被配置为存储各种类型的数据以支持在终端的操作。存储组件可以由任
何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器（sra至少一），电可擦除可编程只读存储器（eepro至少一），可擦除可编程只读存储器（epro至少一），可编程只读存储器（pro至少一），只读存储器（ro至少一），磁存储器，快闪存储器，磁盘或光盘。
145.计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合等。
146.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
147.以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
148.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ro至少一/ra至少一、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行各个实施例或者实施例的某些部分所述的方法。
149.最后应说明的是：以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围。