业务服务的更新方法及装置、电子设备和存储介质与流程

1.本技术涉及数据处理技术领域，特别是涉及一种业务服务的更新方法及装置、电子设备和存储介质。


背景技术：

2.随着互联网开发技术不断发展，虚拟化、容器化越来越成熟，后台服务上线也有了更稳定上线部署方案，虚拟化的方案是将硬件虚拟化后安装操作系统，在虚拟硬件上安装的操作系统能更方便的进行维护，从而使得部署在其上的服务也相比于安装在物理机上的系统更容易维护，当物理机故障时，将虚拟化系统的数据文件到另一台物理机上启动，即可恢复服务。容器化技术出现后，虚拟化系统的数据文件大小进一步减小，启动速度进一步提升，在重启容器的资源消耗中，操作系统的损耗几乎可以忽略不计。
3.微服务技术在容器化的基础上进一步平台化，形成了统一管理服务器资源的微服务平台，业务服务在微服务平台上注册后，上传自身容器镜像，指定需要部署的服务数量、每服务需要的cpu、内存数量，部署和上线的操作步骤都可以由微服务平台来完成，极大的简化了开发和运维工作。
4.当业务服务需要上线新版本时，由上线操作人员上传新版本容器镜像到线上环境中，然后在微服务平台点击更新应用。微服务平台则按既定策略，进行更新服务的更新动作。目前的既定策略有两种，一种是先逐步杀死一定比率的旧服务容器，再启动新镜像，直到所有容器都得到更新；另一种是先逐一申请一定比率的新容器资源，申请过程可能会发生排队等待，申请容器资源成功后启动新镜像，新镜像启动成功后杀死相应的旧服务容器，直到所有容器都得到更新。上述的升级过程，每一步的新容器的启动都会消耗1～3分钟时间，这个时间包含了镜像系统的启动、容器内服务启动、依赖资源包加载、配置加载解析、服务健康检查，若发生新容器资源的申请排队情况时间可能会超过5分钟。若业务服务的容器数量较大，如对50个容器服务进行更新，整体的更新时间需要10～30分钟，更新100个容器则需要更长的时间。可见，现有技术中由于线上环境中的容器启动消耗时间较长，导致上线业务服务的新版本所消耗的也较长。


技术实现要素：

5.本技术实施例的目的在于提供一种业务服务的更新方法及装置、电子设备和存储介质，以实现将线上环境中待更新的业务服务的流量切换到灰度环境中，从而无需基于线上环境边升级容器边进行版本的更新，缩短了版本更新的时间以及提升了版本更新的效率。具体技术方案如下：
6.在本技术实施例的第一方面，提供了一种业务服务的更新方法，包括：配置服务器在预配置的灰度环境中部署新版本容器，其中，所述新版本容器由灰度环境中的旧版本容器升级得到；所述配置服务器基于线上环境中旧版本容器的数量对所述新版本容器进行扩容，其中，扩容后的所述新版本容器的数量与所述线上环境中旧版本容器的数量匹配；所述
灰度环境和所述线上环境相互独立；所述配置服务器向业务服务器发送流量切换指令；所述业务服务器响应于流量切换指令，断开与所述线上环境的通信连接，并与所述灰度环境建立通信连接；所述业务服务器响应于业务服务请求，将所述业务服务请求转发至所述灰度环境，以获取所述灰度环境反馈的业务服务的更新数据。
7.在本技术实施例的第二方面，还提供了一种业务服务的更新装置，包括：部署模块，用于在预配置的灰度环境中部署新版本容器，其中，所述新版本容器由灰度环境中的旧版本容器升级得到；扩容模块，用于基于线上环境中旧版本容器的数量对所述新版本容器进行扩容，其中，扩容后的所述新版本容器的数量与所述线上环境中旧版本容器的数量匹配；所述灰度环境和所述线上环境相互独立；发送模块，用于向业务服务器发送流量切换指令；处理模块，用于响应于流量切换指令，断开与所述线上环境的通信连接，并与所述灰度环境建立通信连接；更新模块，用于响应于业务服务请求，将所述业务服务请求转发至所述灰度环境，以获取所述灰度环境反馈的业务服务的更新数据。
8.在本技术实施例的第三方面，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述任一所述的业务服务的更新方法。
9.在本技术实施例的第四方面，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述任一所述的业务服务的更新方法。
10.在本技术实施例中，在业务服务更新的过程中涉及到相互独立的灰度环境和线上环境，配置服务器先将灰度环境中的旧版本容器更新为新版本容器，并对灰度环境中的新版本容器进行扩容，然后业务服务器基于流量切换指令建议与灰度环境的通信连接，进而基于业务服务请求获取灰度环境反馈的业务服务的更新数据，以对业务服务进行更新，即可以先对与线上环境相互独立的灰度环境中的容器版本进行更新，然后将线上环境中待更新的业务服务的流量切换到灰度环境中，从而无需基于线上环境边升级容器边进行版本的更新，缩短了版本更新的时间以及提升了版本更新的效率，从而解决了现有技术中由于线上环境中的容器启动消耗时间较长，导致上线业务服务的新版本所消耗的也较长的问题。
附图说明
11.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。
12.图1为本技术实施例中业务服务的更新方法的流程图；
13.图2为本技术实施例中调用运维操作进行流量切换的示意图；
14.图3为本技术实施例中基于流量切换的微服务快速上线的示意图；
15.图4为本技术实施例中业务服务的更新装置的结构示意图；
16.图5为本技术实施例中电子设备的结构示意图。
具体实施方式
17.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行描述。
18.本技术实施例提供了一种业务服务的更新方法，如图1所示，该方法的步骤包括：
19.步骤102，配置服务器在预配置的灰度环境中部署新版本容器，其中，新版本容器
由灰度环境中的旧版本容器升级得到；
20.步骤104，配置服务器基于线上环境中旧版本容器的数量对新版本容器进行扩容，其中，扩容后的新版本容器的数量与线上环境中旧版本容器的数量匹配；灰度环境和线上环境相互独立；
21.其中，需要说明的是，本技术实施例中的灰度环境和线上环境可以是一个容器平台上的两个相互独立的环境。
22.步骤106，配置服务器向业务服务器发送流量切换指令；
23.步骤108，业务服务器响应于流量切换指令，断开与线上环境的通信连接，并与灰度环境建立通信连接；
24.步骤110，业务服务器响应于业务服务请求，将业务服务请求转发至灰度环境，以获取灰度环境反馈的业务服务的更新数据。
25.通过上述步骤102至步骤110可知，在业务服务更新的过程中涉及到相互独立的灰度环境和线上环境，配置服务器先将灰度环境中的旧版本容器更新为新版本容器，并对灰度环境中的新版本容器进行扩容，然后业务服务器基于流量切换指令建议与灰度环境的通信连接，进而基于业务服务请求获取灰度环境反馈的业务服务的更新数据，以对业务服务进行更新，即可以先对与线上环境相互独立的灰度环境中的容器版本进行更新，然后将线上环境中待更新的业务服务的流量切换到灰度环境中，从而无需基于线上环境边升级容器边进行版本的更新，缩短了版本更新的时间以及提升了版本更新的效率，从而解决了现有技术中由于线上环境中的容器启动消耗时间较长，导致上线业务服务的新版本所消耗的也较长的问题。
26.需要说明的是，本技术实施例中的业务服务可以是播放器业务、首页业务、用户中心业务、活动业务等。
27.在本技术实施例的可选实施方式中，在步骤102中涉及到的将预配置的灰度环境中的旧版本容器更新为新版本容器的方式之前，本技术实施例的方法还可以进一步包括：
28.步骤11，配置服务器获取线上环境中旧版本容器的容器配置；
29.步骤12，配置服务器基于线上环境中旧版本容器的容器配置建立灰度环境，其中，灰度环境中包括旧版本容器。
30.可见，是基于线上环境中旧版本容器的容器配置建立灰度环境，因此，在初始状态下(容器更新之前)灰度环境与线上环境中均是旧版本容器。另外，本技术实施例中的灰度环境和线上环境可以是一个容器平台上的两个相互独立的环境，基于此，可以基于该容器平台中的剩余配额，即未被利用的资源建立该灰度环境，也就是说可以在充分利用资源且不增加资源的情况下，建立该灰度环境，也就是说，在后续利用灰度环境进行版本更新提升更新效率的同时，也未增加系统资源。
31.在本技术实施例的再一个可选实施方式中，对于上述步骤104中涉及到的配置服务器基于线上环境中旧版本容器的数量对新版本容器进行扩容的方式，进一步可以包括：配置服务器基于线上环境中旧版本容器的数量配置灰度环境中新版本容器的数量，其中，灰度环境中新版本容器的数量与线上环境中旧版本容器的数量之间的差值的绝对值小于预设阈值。
32.在本技术实施例的具体实施方式中，该预设阈值可以根据实际情况进行相应的取
值，可以是0,1,2等，也就是说，该灰度环境中新版本容器的数量可以大于、小于或等于线上环境中旧版本容器的数量，但两者的数量尽量接近，因为这样可以保证从线上环境切换过来的流量能够及时访问到灰度环境中的新版本容器实现版本更新。
33.在本技术实施例的再一个可选实施方式中，对于上述步骤108中涉及到的业务服务器响应于流量切换指令，断开与线上环境的通信连接，并与灰度环境建立通信连接的方式，进一步可以包括：
34.步骤21，业务服务器响应于流量切换指令，将线上环境中业务服务的主机名修改为灰度环境中业务服务的主机名；
35.步骤22，业务服务器将线上环境中业务服务的业务服务池修改为灰度环境中业务服务的业务服务池；
36.步骤23，业务服务器基于业务服务的业务分组名、灰度环境中业务服务的主机名和灰度环境中业务服务的业务服务池，将业务服务的流量切换到灰度环境中。
37.对于上述步骤21至步骤23，以业务服务为player(播放器)业务，且业务服务器为nginx服务器为例，则业务分组名为“player”。此外，在所有前置nginx服务器上配置好灰度环境和线上环境的两组host(主机名)，分别使用grayhost(灰度主机)和prodhost(线上主机)来标记，以及在所有前置nginx服务器上配置好灰度环境和线上环境的两组upstream(业务服务器池)，分别使用grayupstream(灰度业务服务池)和produpstream(线上业务服务池)来标记。
38.基于此，将线上环境中业务服务的主机名修改为灰度环境中业务服务的主机名是指将prodhost修改为grayhost，将线上环境中业务服务的业务服务池修改为灰度环境中业务服务的业务服务池是指将produpstream修改为grayupstream。而对于基于业务服务的业务分组名、灰度环境中业务服务的主机名和灰度环境中业务服务的业务服务池，将业务服务的流量切换到灰度环境中的方式，在具体应用场景可以是基于switch的方式进行流量的切换，如图2所示，具体可以是/switch？group＝player&env＝gray进行流量的切换，中switch为接口名，group为业务分组名，env为要切换到的目标环境名。在图2中可见，nginx服务调用switch则可以将流量切换到灰度环境中，如果是没有调用switch则依然是将流量切换到线上环境。
39.在本技术实施例的再一个可选实施方式中，对于步骤110中涉及到的业务服务器响应于业务服务请求，将业务服务请求转发至灰度环境，以获取灰度环境反馈的业务服务的更新数据的方式，进一步可以包括：
40.步骤31，在预设时长内未出现异常的情况下，业务服务器将灰度环境中业务服务的主机名修改为线上环境中业务服务的主机名；
41.步骤32，业务服务器将灰度环境中业务服务的业务服务池修改为线上环境中业务服务的业务服务池；
42.步骤33，业务服务器基于线上环境中业务服务的主机名和线上环境中业务服务的业务服务池重新建立与线上环境的通信连接，将线上环境中的旧版本容器更新为新版本容器。
43.步骤34，在预设时长内出现异常的情况下，业务服务器基于线上环境中业务服务的主机名和线上环境中业务服务的业务服务池重新建立与线上环境的通信连接，以使新版
本容器回滚至旧版本容器
44.可见，通过上述步骤31至步骤34，如果在灰度环境中进行版本更新完成且无异常，则可以将线上环境中的旧版本容器更新为新版本容器，以将灰度环境中更新后的业务服务的流量切回到线上环境，也就是说，在基于灰度环境完成版本更新后，再对线上环境中的旧版本容器进行更新，即在不影响业务服务版本更新的情况下，也能对线上环境进行容器更新。此外，回滚是指上述步骤21至步骤23的逆向操作，即在具体应用场景中可以是：前置nginx服务器可以动态调整host(主机名)和upstream(业务服务器池)指向线上环境，完成到旧版本的业务回滚，其回滚与流量切换所消耗的时间也是类似的，也即在本技术实施例中，如果出现更新异常也可以能够较快的完成业务回滚。
45.在本技术实施例的再一个可选实施方式中，本技术实施例的方法步骤还可以包括：
46.步骤110，在新版本容器回滚至旧版本容器之后，业务服务器将灰度环境的容器数量缩容至扩容前的数量。
47.可见，在将线上环境的容器版本更新且将业务服务流量切回到线上环境之后，对灰度环境进行缩容，从而可以释放灰度环境所占用的资源，以备下一次业务服务的更新。
48.下面结合本技术实施例的具体实施方式对本技术进行举例说明，该具体实施方式提供了一种基于流量切换的微服务快速上线的方法，图3是基于流量切换的微服务快速上线的示意图，基于图3，该具体实施方式的方法步骤包括：
49.步骤301，在容器平台新建独立的灰度环境，其中，灰度环境和线上环境共用资源配额；
50.步骤302，调用微服务平台接口，获取业务服务在线上环境的容器配置；
51.其中，容器配置可以包括：cpu、内存、磁盘、其他环境变量等；
52.步骤303，调用微服务平台接口，在灰度环境部署新版本的镜像，使用步骤302的容器配置进行部署；
53.步骤304，调用微服务平台接口，获取业务服务在线上环境的容器数量；
54.步骤305，调用微服务平台接口，在灰度环境上对新版本的容器进行扩容，扩容至步骤304所获取的容器数量；
55.步骤306，在前置nginx服务器上动态修改host(主机名)的值为灰度环境提供的host(主机名)，动态修改upstream(业务服务器池)为灰度环境的upstream(业务服务器池)。此步骤需要在前置nginx服务器上完成动态修改host(主机名)和upstream(业务服务器池)的能力实现；
56.其中，该步骤306具体可以通过以下步骤实现：
57.步骤31，在所有前置nginx服务器上配置好灰度环境的线上环境的两组host(主机名)，分别使用grayhost(灰度主机)和prodhost(线上主机)来标记。
58.步骤32，在所有前置nginx服务器上配置好灰度环境的线上环境的两组upstream(业务服务器池)，分别使用grayupstream(灰度业务服务池)和produpstream(线上业务服务池)来标记。
59.步骤33，将前置nginx服务器上代理的业务接口按upstream(业务服务池)来分组管理，如player(播放器)业务，以下将以player业务作为示例进行展开。预告定义好player
业务的playerhost(播放器主机)和playerupstream(播放器业务服务池)两个变量，且将playerhost(播放器主机)的默认值设置为player业务的prodhost(线上主机)，将playerupstream(播放器业务服务池)的默认值设置为player业务的produpstream(线上业务服务池)。
60.步骤34，在player业务的所有location(关键字，nginx的业务接口标记)中，先获取最新host(主机名)，并设置到请求的包头的host字段中；若未获取到最新的host，则将prodhost(线上主机)作为最新的host设置到管理对象中，并返回。如下所示：
[0061][0062][0063]
步骤35，继续处理upstream(业务服务器池)。先获取最新upstream(业务服务器池)，并设置为请求的访问目标；若未获取到最新的upstream(业务服务器池)，则将produpstream(业务服务器池)作为最新的upstream设置到管理对象中，并返回。如下所示：
[0064][0065]
步骤36，在前置nginx服务器中实现切换链路/switch？group＝player&env＝gray
接口。其中switch为接口名，group为业务分组名，env为要切换到的目标环境名。如下所示：
[0066][0067][0068]
步骤37，调用所有前置nginx服务器的/switch？group＝player&env＝gray方法，即可完成了流量从线上旧版本服务切换到灰度环境的新版本服务上；
[0069]
其中，在具体应用场景中，所有用户请求都访问到了新版本服务，整体升级耗时小于1分钟。
[0070]
步骤38，若新版本服务上线后出现异常情况，未按预期返回结果时，调用所有前置nginx服务器的/switch？group＝player&env＝prod方法进行回滚；
[0071]
其中，通过该回滚可完成了流量从灰度环境新版本服务切换到线上环境的旧版本服务上，整体回滚耗时较短。
[0072]
步骤307，基于拨测、自动化测试用例、人工回测、持续观察指标健康度预设时长(例如2小时)，以便形成新服务上线可靠的结论；
[0073]
步骤308，在上线可靠的结论下，调用微服务平台接口，使用新版本镜像更新线上环境；
[0074]
步骤309，调用所有前置nginx服务器的/switch？group＝player&env＝prod方法，将所有流量切回到线上环境；
[0075]
步骤310，调用微服务平台接口，对灰度环境进行缩容，缩减容器数量至扩容前的数量，释放冗余资源。
[0076]
通过上述步骤301至步骤310可知，在具体实施方式中将部署过程前置，在上线新
版本前，从旧版本服务上读取容器资源配置和数量，将新版本镜像和容器配置更新到一个独立的灰度环境中，在部署完成后，通过在前置nginx服务器上动态调整host(主机名)和upstream(业务服务器池)指向灰度环境。在实际过程中，单一的前置nginx服务器切换链路到灰度环境的时间开销小于300毫秒，60台前置nginx服务器进行切换，完成整体流量切换小于1分钟。此外，该具体实施方式还限定了灰度环境部署的资源需要持续观察一定的时间，在该时间内，灰度环境会占用剩余的业务服务器资源配额。若检测并观察到新版本的业务服务存在故障，则通过在前置nginx服务上动态调整host(主机名)和upstream(业务服务器池)指向线上环境，完成到旧版本的业务回滚。若检测并观察到新版本的业务服务稳定有效，则使用新版本的镜像更新线上环境，线上环境更新完成后，通过在前置nginx服务上动态调整host(主机名)和upstream(业务服务器池)将流量切回线上环境，同时对灰度环境进行缩容，回退资源到初始状态。
[0077]
可见，通过该具体实施方式，在新版本服务上线前进行双环境部署，以使能够在一段时间内同时保留新旧两个版本的线上服务，有效利用了配额内的备用资源。另外，现有技术的方案中是一边部署一边替换一边升级的漫长过程，这种方式只能进行单向运维等待至升级结束或中止升级，其回滚是一个逆向的过程，也有同样的低效的问题，而通过该具体实施的方式，相比于现有技术有了更大的灵活性或可靠性。
[0078]
对应于上述业务服务的方法，本技术实施例还提供了一种业务服务的更新装置，如图4所示该装置包括：
[0079]
部署模块42，用于在预配置的灰度环境中部署新版本容器，其中，新版本容器由灰度环境中的旧版本容器升级得到；
[0080]
扩容模块44，用于基于线上环境中旧版本容器的数量对新版本容器进行扩容，其中，扩容后的新版本容器的数量与线上环境中旧版本容器的数量匹配；灰度环境和线上环境相互独立；
[0081]
发送模块46，用于向业务服务器发送流量切换指令；
[0082]
处理模块48，用于响应于流量切换指令，断开与线上环境的通信连接，并与灰度环境建立通信连接；
[0083]
更新模块50，用于响应于业务服务请求，将业务服务请求转发至灰度环境，以获取灰度环境反馈的业务服务的更新数据。
[0084]
通过本技术实施例的装置，在业务服务更新的过程中涉及到相互独立的灰度环境和线上环境，配置服务器先将灰度环境中的旧版本容器更新为新版本容器，并对灰度环境中的新版本容器进行扩容，然后业务服务器基于流量切换指令建议与灰度环境的通信连接，进而基于业务服务请求获取灰度环境反馈的业务服务的更新数据，以对业务服务进行更新，即可以先对与线上环境相互独立的灰度环境中的容器版本进行更新，然后将线上环境中待更新的业务服务的流量切换到灰度环境中，从而无需基于线上环境边升级容器边进行版本的更新，缩短了版本更新的时间以及提升了版本更新的效率，从而解决了现有技术中由于线上环境中的容器启动消耗时间较长，导致上线业务服务的新版本所消耗的也较长的问题。
[0085]
可选地，本技术实施例中的处理模块48进一步可以包括：第一修改单元，用于响应于流量切换指令，将线上环境中业务服务的主机名修改为灰度环境中业务服务的主机名；
第二修改单元，用于将线上环境中业务服务的业务服务池修改为灰度环境中业务服务的业务服务池；切换单元，用于基于灰度环境中业务服务的主机名和灰度环境中业务服务的业务服务池，与灰度环境建立通信连接。
[0086]
可选地，本技术实施例中的扩容模块44进一步可以包括：配置单元，用于基于线上环境中旧版本容器的数量配置灰度环境中新版本容器的数量，其中，灰度环境中新版本容器的数量与线上环境中旧版本容器的数量之间的差值的绝对值小于预设阈值。
[0087]
可选地，本技术实施例中的装置进一步还可以包括：获取模块，用于在将预配置的灰度环境中的旧版本容器更新为新版本容器之前，获取线上环境中旧版本容器的容器配置；配置模块，用于基于线上环境中旧版本容器的容器配置建立灰度环境，其中，灰度环境中包括旧版本容器。
[0088]
可选地，本技术实施例中的更新模块进一步可以包括：第三修改单元，用于在预设时长内未出现异常的情况下，将灰度环境中业务服务的主机名修改为线上环境中业务服务的主机名；第四修改单元，用于将灰度环境中业务服务的业务服务池修改为线上环境中业务服务的业务服务池；更新单元，用于基于线上环境中业务服务的主机名和线上环境中业务服务的业务服务池重新建立与线上环境的通信连接，将线上环境中的旧版本容器更新为新版本容器。
[0089]
可选地，本技术实施例中的装置进一步还可以包括：回滚模块，用于在预设时长内出现异常的情况下，业务服务器基于线上环境中业务服务的主机名和线上环境中业务服务的业务服务池重新建立与线上环境的通信连接，以使新版本容器回滚至旧版本容器；缩容模块，用于在新版本容器回滚至旧版本容器之后，业务服务器将灰度环境的容器数量缩容至扩容前的数量。
[0090]
本技术实施例还提供了一种电子设备，如图5所示，包括处理器501、通信接口502、存储器503和通信总线504，其中，处理器501，通信接口502，存储器503通过通信总线504完成相互间的通信；
[0091]
存储器503，用于存放计算机程序；
[0092]
处理器501，用于执行存储器503上所存放的程序时，实现上述图1中的方法步骤，在此不再赘述。
[0093]
此外，该处理器501基于程序实现上述图1中的业务服务的更新方法所起到的作用也是相当的，在此不再赘述。
[0094]
上述终端提到的通信总线可以是外设部件互连标准(peripheral component interconnect，简称pci)总线或扩展工业标准结构(extended industry standard architecture，简称eisa)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
[0095]
通信接口用于上述终端与其他设备之间的通信。
[0096]
存储器可以包括随机存取存储器(random access memory，简称ram)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。
[0097]
上述的处理器可以是通用处理器，包括中央处理器(central processing unit，简称cpu)、网络处理器(network processor，简称np)等；还可以是数字信号处理器
(digital signal processing，简称dsp)、专用集成电路(application specific integrated circuit，简称asic)、现场可编程门阵列(field－programmable gate array，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
[0098]
在本技术提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的业务服务的更新方法。
[0099]
在本技术提供的又一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的业务服务的更新方法。
[0100]
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本技术实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solid state disk(ssd))等。
[0101]
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0102]
本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0103]
以上所述仅为本技术的较佳实施例而已，并非用于限定本技术的保护范围。凡在本技术的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本技术的保护范围内。