容器化微服务自动伸缩及迁移调度的方法、系统和设备与流程

本发明涉及器化微服务技术领域，尤其涉及一种容器化微服务自动伸缩及迁移调度的方法、系统和设备。

背景技术：

在如今的互联网和企业应用开发领域，微服务和DevOps这两个思想颇为深入人心。而Docker技术的出现和其对整个容器技术及其生态圈发展的促进，解决了微服务和DevOps这两个思想实践中的很多难题，使得微服务和DevOps这两种思想大规模地实现成为了可能。而Docker给系统架构各应用的微服务容器化提供了诸多便利的同时，也对企业的服务治理带来了很大挑战。

为了充分利用IDC的物理资源、节省企业成本和保证服务的高可用性，在保证服务不中断情况下需要对服务进行弹性伸缩和迁移调度。

目前，对服务进行弹性伸缩和迁移调度主要有两种方式：

1、手工方式：

1)根据容器化微服务故障的监控预警信息，运维人员手工把不可用的服务调度到集群中其它可用节点上。

2)预估系统流量压力，运维人员提前在预测时间点手工扩容、缩减容器化微服务实例资源配额或数量。

2、基于系统性能监控的自动调度方式：

服务治理平台或监控系统监控容器的CPU、内存、网络流量，根据预先设定的规则，在CPU、内存或网络流量使用量达到阀值时自动扩容或缩减容器实例数量。

发明人在研究的过程中发现，上述两种方式存在以下缺点：

手工方式效率低：从接到告警信息到运维人员完成手工伸缩，响应时间不及时。企业运维成本高：每次伸缩都需要运维人员全程参与造成运维成本高。操作失误风险高和推广困难：如策略、规则和伸缩模式复杂，会造成运维人员学习和应用困难，推广阻力大。同时，由于根据策略和规则计算最优的伸缩模式复杂，很容易造成操作失误风险。

基于系统性能监控的自动调度方式不能达到预期效果：没有进行故障传导分析，某个容器的资源利用情况不能真实反映整个调用链的瓶颈，达到阀值容器的资源利用情况会是由于下级微服务的服务质量造成。伸缩策略受限：无法对容器实例的资源配额单独伸缩。伸缩机制受限：不能根据单个容器化微服务的特性进行重启，或单次伸缩数量、收缩时间间隔等。

技术实现要素：

为了解决上述技术问题，本发明提供了一种容器化微服务自动伸缩及迁移调度的方法、系统和设备，通过监控容器的资源(CPU、内存、IO、网络和存储)利用情况和容器化微服务的服务质量(响应时间、失败率、服务调用次数)。结合大数据综合分析结果，根据规则、策略和调度算法，提供容器化微服务无需人工干预快速的自动化伸缩和故障调度转移。达到对硬件资源的合理利用、降低运维团队成本、容器化微服务的高可用性和高性能目的。

本发明一方面提供了一种容器化微服务自动伸缩及迁移调度的方法，其特征在于，包括：

接收容器和/或微服务产生的经故障定位后的预警数据；和/或第三方平台发送的携带容器和/或微服务自动伸缩任务计划数据；

触发容器自动伸缩或故障调度转移。

进一步的，所述接收容器和/或微服务产生的经故障定位后的预警数据，包括：

实时接收资源监控和分析系统发送的容器和/或微服务产生的经故障定位后的预警数据。

进一步的，所述实时接收资源监控和分析系统发送的容器和/或微服务产生的经故障定位后的预警数据，包括：

资源监控和分析系统实时采集服务调用日志和容器资源利用信息；

判断所述采集的服务调用日志和容器资源利用信息满足系统预设预警条件后，在微服务调用链里定位原始故障点；

实时接收资源监控和分析系统发送的所述原始故障点的异常信息数据。

进一步的，所述判断所述采集的服务调用日志和容器资源利用信息满足系统预设预警条件后，在微服务调用链里定位原始故障点，包括：

基于服务器配置的预设预警条件阀值以及预设算法分析，判断采集的HTTP和TCP/UDP类型的服务调用日志和容器资源利用信息中的容器CPU、内存、存储、IO和/或网络的使用数据，以及微服务的响应时间、失败率、QPS是否满足系统预设预警条件；

若满足系统预设预警条件之一，则进行故障传导分析，在整个微服务调用链里定位原始故障点。

进一步的，所述系统预设预警条件包括但不限于高负荷、低使用率、异常波动或可用性不达标中的一种或多种。

进一步的，所述触发容器自动伸缩或故障调度转移，包括：

根据预警数据中的IP和端口或服务ID从容器集群环境中获取相关微服务属性信息；

把预警数据交给规则引擎选出需要执行动作的决策项集合，依据决策项的调度机制调用任务执行引擎生成计划任务，任务执行引擎根据任务计划数据定义准时调用容器集群的API触发容器完成自动伸缩或故障调度转移。

进一步的，所述把预警数据交给规则引擎选出需要执行动作的决策项集合，依据决策项的调度机制调用任务执行引擎生成计划任务，任务执行引擎根据任务计划数据定义准时调用容器集群的API触发容器完成自动伸缩或故障调度转移，包括：

参照RETE算法，根据预警数据的类型进行规则类型匹配，将每类中的预警数据根据属性值进行多级规则匹配，选出一个条件被优先满足的规则后，根据选定的规则从规则适配决策表中匹配决策项集合，通过匹配的决策项集合解决决策项集合中的冲突，形成可顺序执行决策项，根据决策项的调度机制调用容器集群的API完成容器伸缩或故障调度转移。

进一步的，所述接收第三方平台发送的携带容器和/或微服务自动伸缩任务计划数据，触发容器自动伸缩或故障调度转移，包括：

接收第三方平台按照接口调用协议定义的格式提交的携带容器和/或微服务自动伸缩任务计划数据；

调用任务执行引擎生成计划任务，任务执行引擎根据任务计划数据定义，准时调用容器集群的API触发容器完成自动伸缩或故障调度转移。

进一步的，所述接收第三方平台按照接口调用协议定义的格式提交的携带容器和/或微服务自动伸缩任务计划数据，包括：

接收第三方平台通过HTTP或HTTPS协议提供的接口通过同步调用或异步调用服务使用JSON格式提交的携带容器和/或微服务自动伸缩任务计划数据，并在注册成功回调地址后可实现消息推送。

进一步的，所述触发容器自动伸缩，包括：

伸缩容器的CPU、内存、存储资源中的一种或多种；

重启容器；

基于预设时间间隔将容器逐一伸缩；

基于预设时间间隔按照预设比例将容器逐步伸缩。

本发明另一方面还提供了一种容器化微服务自动伸缩及迁移调度的系统，包括：

接收模块，用于接收容器和/或微服务产生的经故障定位后的预警数据；和/或第三方平台发送的携带容器和/或微服务自动伸缩任务计划数据；

触发模块，用于触发容器自动伸缩或故障调度转移。

进一步的，所述接收模块，包括：

第一接收模块，用于实时接收资源监控和分析系统发送的容器和/或微服务产生的经故障定位后的预警数据。

进一步的，所述第一接收模块，包括：

资源监控和分析系统采集单元，用于实时采集服务调用日志和容器资源利用信息；

判断单元，用于判断所述采集的服务调用日志和容器资源利用信息满足系统预设预警条件后，在微服务调用链里定位原始故障点；

接收单元，用于实时接收资源监控和分析系统发送的所述原始故障点的异常信息数据。

进一步的，所述判断单元，包括：

判断子单元，用于基于服务器配置的预设预警条件阀值以及预设算法分析，判断采集的HTTP和TCP/UDP类型的服务调用日志和容器资源利用信息中的容器CPU、内存、存储、IO和/或网络的使用数据，以及微服务的响应时间、失败率、QPS是否满足系统预设预警条件；

定位单元，用于在判断子单元判断所述采集的服务调用日志和容器资源利用信息满足系统预设预警条件之一，则进行故障传导分析，在整个微服务调用链里定位原始故障点。

进一步的，所述系统预设预警条件包括但不限于高负荷、低使用率、异常波动或可用性不达标中的一种或多种。

进一步的，所述触发模块，包括：

获取单元，用于根据预警数据中的IP和端口或服务ID从容器集群环境中获取相关微服务属性信息；

第一触发单元，用于把预警数据交给规则引擎选出需要执行动作的决策项集合，依据决策项的调度机制调用任务执行引擎生成计划任务，任务执行引擎根据任务计划数据定义准时调用容器集群的API触发容器完成自动伸缩或故障调度转移。

进一步的，所述第一触发单元，包括：

规则匹配单元，用于参照RETE算法，根据预警数据的类型进行规则类型匹配，将每类中的预警数据根据属性值进行多级规则匹配，选出一个条件被优先满足的规则后，根据选定的规则从规则适配决策表中匹配决策项集合，通过匹配的决策项集合解决决策项集合中的冲突，形成可顺序执行决策项；

第一触发子单元，用于根据决策项的调度机制调用容器集群的API完成容器伸缩或故障调度转移。

进一步的，所述接收模块，包括：

第二接收模块，用于接收第三方平台按照接口调用协议定义的格式提交的携带容器和/或微服务自动伸缩任务计划数据。

进一步的，所述触发模块，包括：

第二触发单元，用于调用任务执行引擎生成计划任务，任务执行引擎根据任务计划数据定义，准时调用容器集群的API触发容器完成自动伸缩或故障调度转移。

进一步的，所述第二接收模块，包括：

第二接收单元，用于接收第三方平台通过HTTP或HTTPS协议提供的接口通过同步调用或异步调用服务使用JSON格式提交的携带容器和/或微服务自动伸缩任务计划数据，并在注册成功回调地址后可实现消息推送。

进一步的，所述触发模块，还包括：

第一伸缩单元，用于伸缩容器的CPU、内存、存储资源中的一种或多种；

重启单元，用于重启容器；

第二伸缩单元，用于基于预设时间间隔将容器逐一伸缩；

第三伸缩单元，用于基于预设时间间隔按照预设比例将容器逐步伸缩。

本发明另一方面还提供了一种容器化微服务自动伸缩及迁移调度的设备，包括前述任一项所述的容器化微服务自动伸缩及迁移调度的系统。

本发明通过接收容器和/或微服务产生的经故障定位后的预警数据；和/或第三方平台发送的携带容器和/或微服务自动伸缩任务计划数据，触发容器自动伸缩或故障调度转移的技术方案，一旦微服务出现异常，加快了服务伸缩的响应时间和处理时间；解放了运维人员处理的繁重工作量；有效控制了人为处理服务伸缩带来的不可控风险；降低了企业的运维成本；有效加快企业推广系统容器化微服务改造；解决了容器收缩策略的限制；扩充了容器化微服务伸缩的多样性和机制；通过对整个调用链的故障传导分析准确的定位了真实的故障点，做到了对容器化微服务的精确伸缩。

附图说明

图1为根据本发明的容器化微服务自动伸缩及迁移调度的方法的实施例一的流程图；

图2为根据本发明的JSON格式调用程序的示意图；

图3为根据本发明的数据格式程序的示意图；

图4为根据本发明的容器化微服务自动伸缩及迁移调度的系统的实施例二的示意图；

图5为根据本发明的接收模块的实施例二的示意图；

图6为根据本发明的第一接收模块的实施例二的示意图；

图7为根据本发明的判断单元的实施例二的示意图；

图8为根据本发明的触发模块的实施例二的示意图；

图9为根据本发明的第一触发单元的实施例二的示意图；

图10为根据本发明的接收模块的实施例二的另一示意图；

图11为根据本发明的触发模块的实施例二的另一示意图；

图12为根据本发明的第二接收模块的实施例二的示意图；

图13为根据本发明的触发模块的实施例二的另一示意图；

图14为根据本发明的容器化微服务自动伸缩及迁移调度的设备的实施例三的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例一

参照图1，图1示出了本发明提供的一种容器化微服务自动伸缩及迁移调度的方法的流程图。包括：步骤S110、步骤S120。

在步骤S110中，接收容器和/或微服务产生的经故障定位后的预警数据；和/或第三方平台发送的携带容器和/或微服务自动伸缩任务计划数据。

在步骤S120中，触发容器自动伸缩或故障调度转移。

进一步的，所述接收容器和/或微服务产生的经故障定位后的预警数据，包括：

实时接收资源监控和分析系统发送的容器和/或微服务产生的经故障定位后的预警数据。

进一步的，所述实时接收资源监控和分析系统发送的容器和/或微服务产生的经故障定位后的预警数据，包括：

资源监控和分析系统实时采集服务调用日志和容器资源利用信息；

判断所述采集的服务调用日志和容器资源利用信息满足系统预设预警条件后，在微服务调用链里定位原始故障点；

实时接收资源监控和分析系统发送的所述原始故障点的异常信息数据。

进一步的，所述判断所述采集的服务调用日志和容器资源利用信息满足系统预设预警条件后，在微服务调用链里定位原始故障点，包括：

基于服务器配置的预设预警条件阀值以及预设算法分析，判断采集的HTTP和TCP/UDP类型的服务调用日志和容器资源利用信息中的容器CPU、内存、存储、输入/输出IO接口或设备和/或网络的使用数据，以及微服务的响应时间、失败率、每秒查询率QPS是否满足系统预设预警条件；其中，预设预警条件阀值以及预设算法分析根据系统的硬件属性或场景所需，设置配置的阀值和策略，通过实时大数据综合分析所需的数据集。

若满足系统预设预警条件之一，则进行故障传导分析，在整个微服务调用链里定位原始故障点。在定位到故障点后，把异常信息数据按照“接口调用协议”定义的格式发送给容器化微服务自动调度系统中。

进一步的，所述系统预设预警条件包括但不限于高负荷、低使用率、异常波动或可用性不达标中的一种或多种。

进一步的，所述触发容器自动伸缩或故障调度转移，包括：

根据预警数据中的IP和端口或服务ID从容器集群环境中获取相关微服务属性信息；

把预警数据交给规则引擎选出需要执行动作的决策项集合，依据决策项的调度机制调用任务执行引擎生成计划任务，任务执行引擎根据任务计划数据定义准时调用容器集群的API触发容器完成自动伸缩或故障调度转移。

进一步的，所述把预警数据交给规则引擎选出需要执行动作的决策项集合，依据决策项的调度机制调用任务执行引擎生成计划任务，任务执行引擎根据任务计划数据定义准时调用容器集群的API触发容器完成自动伸缩或故障调度转移，包括：

参照RETE算法，根据预警数据的类型进行规则类型匹配，将每类中的预警数据根据属性值进行多级规则匹配，选出一个条件被优先满足的规则后，根据选定的规则从规则适配决策表中匹配决策项集合，通过匹配的决策项集合解决决策项集合中的冲突，形成可顺序执行决策项，根据决策项的调度机制调用容器集群的API完成容器伸缩或故障调度转移。

进一步的，所述接收第三方平台发送的携带容器和/或微服务自动伸缩任务计划数据，触发容器自动伸缩或故障调度转移，包括：

接收第三方平台按照接口调用协议定义的格式提交的携带容器和/或微服务自动伸缩任务计划数据；

调用任务执行引擎生成计划任务，任务执行引擎根据任务计划数据定义，准时调用容器集群的API触发容器完成自动伸缩或故障调度转移。

进一步的，所述接收第三方平台按照接口调用协议定义的格式提交的携带容器和/或微服务自动伸缩任务计划数据，包括：

接收第三方平台通过HTTP或HTTPS协议提供的接口通过同步调用或异步调用服务使用JSON格式提交的携带容器和/或微服务自动伸缩任务计划数据，并在注册成功回调地址后可实现消息推送。

本发明实施例中的与第三方平台的通信模式，可独立作为一个服务，以HTTP或HTTPS协议提供接口调用服务，其它业务系统或功能模块可同步调用、异步调用。并在注册成功回调地址后可实现消息推送。并可提供客户端数字证书、用户名加密码、令牌三种方式认证客户端调用的合法性。接口调用数据使用JSON格式，一应用例子，参考图2所示的调用服务。

进一步的，所述触发容器自动伸缩，包括：

伸缩容器的CPU、内存、存储资源中的一种或多种；

重启容器；

基于预设时间间隔将容器逐一伸缩；

基于预设时间间隔按照预设比例将容器逐步伸缩。

另一应用例子，通过第三方平台发送的携带容器和/或微服务自动伸缩任务计划数据；触发容器自动伸缩或故障调度转移。在互联网票务B2C业务中，由于场馆座位的限制，热点演唱会项目售票通常指定时间点进行开票售卖。在到开票售卖后瞬间会有大量的黄牛党和粉丝集中购买。首先预测演唱会抢票高峰服务的容器扩容量。

通过监控微服务的并发访问，统计出下单服务的压力最大、响应时间最慢的微服务。由于下单响应时间的瓶颈延迟会造成整个交易流程体验不好。

预测下单服务的扩容数量，根据历史监控数据，经大数据平台依据时间、城市、项目类型、项目内容四个纬度预估出需要扩容的规模和数量。

运维人员通过服务治理平台(第三方平台)，选定订单服务，并填入扩容的数量、扩容时间、扩容间隔时间、每次的扩容量。运维人员通过服务治理平台，提交订单服务扩容任务给“容器化微服务自动调度系统”。数据格式如图3所示。

“容器化微服务自动调度系统”依据接收到的数据调用任务执行引擎生成计划任务。

任务执行引擎根据任务计划数据定义，准时调用容器集群的API完成容器伸缩或故障调度转移。

本发明实施例一通过接收容器和/或微服务产生的经故障定位后的预警数据；和/或第三方平台发送的携带容器和/或微服务自动伸缩任务计划数据，触发容器自动伸缩或故障调度转移的技术方案，一旦微服务出现异常，加快了服务伸缩的响应时间和处理时间；解放了运维人员处理的繁重工作量；有效控制了人为处理服务伸缩带来的不可控风险；降低了企业的运维成本；有效加快企业推广系统容器化微服务改造；解决了容器收缩策略的限制；扩充了容器化微服务伸缩的多样性和机制；通过对整个调用链的故障传导分析准确的定位了真实的故障点，做到了对容器化微服务的精确伸缩。

实施例二

参照图4，图4示出了本发明提供的一种容器化微服务自动伸缩及迁移调度的系统200一实施例的结构图，包括：

接收模块21，用于接收容器和/或微服务产生的经故障定位后的预警数据；和/或第三方平台发送的携带容器和/或微服务自动伸缩任务计划数据。

触发模块22，用于触发容器自动伸缩或故障调度转移。

进一步的，参照图5，所述接收模块21，包括：

第一接收模块211，用于实时接收资源监控和分析系统发送的容器和/或微服务产生的经故障定位后的预警数据。

进一步的，参照图6，所述第一接收模块211，包括：

资源监控和分析系统采集单元2111，用于实时采集服务调用日志和容器资源利用信息；

判断单元2112，用于判断所述采集的服务调用日志和容器资源利用信息满足系统预设预警条件后，在微服务调用链里定位原始故障点；

接收单元2113，用于实时接收资源监控和分析系统发送的所述原始故障点的异常信息数据。

进一步的，参照图7，所述判断单元2112，包括：

判断子单元21121，用于基于服务器配置的预设预警条件阀值以及预设算法分析，判断采集的HTTP和TCP/UDP类型的服务调用日志和容器资源利用信息中的容器CPU、内存、存储、IO和/或网络的使用数据，以及微服务的响应时间、失败率、QPS是否满足系统预设预警条件；

定位单元21122，用于在判断子单元判断所述采集的服务调用日志和容器资源利用信息满足系统预设预警条件之一，则进行故障传导分析，在整个微服务调用链里定位原始故障点。

进一步的，所述系统预设预警条件包括但不限于高负荷、低使用率、异常波动或可用性不达标中的一种或多种。

进一步的，参照图8，所述触发模块22，包括：

获取单元221，用于根据预警数据中的IP和端口或服务ID从容器集群环境中获取相关微服务属性信息；

第一触发单元222，用于把预警数据交给规则引擎选出需要执行动作的决策项集合，依据决策项的调度机制调用任务执行引擎生成计划任务，任务执行引擎根据任务计划数据定义准时调用容器集群的API触发容器完成自动伸缩或故障调度转移。

进一步的，参照图9，所述第一触发单元222，包括：

规则匹配单元2221，用于参照RETE算法，根据预警数据的类型进行规则类型匹配，将每类中的预警数据根据属性值进行多级规则匹配，选出一个条件被优先满足的规则后，根据选定的规则从规则适配决策表中匹配决策项集合，通过匹配的决策项集合解决决策项集合中的冲突，形成可顺序执行决策项；

第一触发子单元2222，用于根据决策项的调度机制调用容器集群的API完成容器伸缩或故障调度转移。

进一步的，参照图10，所述接收模块21，包括：

第二接收模块212，用于接收第三方平台按照接口调用协议定义的格式提交的携带容器和/或微服务自动伸缩任务计划数据。

进一步的，参照图11，所述触发模块22，包括：

第二触发单元223，用于调用任务执行引擎生成计划任务，任务执行引擎根据任务计划数据定义，准时调用容器集群的API触发容器完成自动伸缩或故障调度转移。

进一步的，参照图12，所述第二接收模块212，包括：

第二接收单元2121，用于接收第三方平台通过HTTP或HTTPS协议提供的接口通过同步调用或异步调用服务使用JSON格式提交的携带容器和/或微服务自动伸缩任务计划数据，并在注册成功回调地址后可实现消息推送。

进一步的，参照图13，所述触发模块22，还包括：

第一伸缩单元224，用于伸缩容器的CPU、内存、存储资源中的一种或多种；

重启单元225，用于重启容器；

第二伸缩单元226，用于基于预设时间间隔将容器逐一伸缩；

第三伸缩单元227，用于基于预设时间间隔按照预设比例将容器逐步伸缩。

由于本实施例二的系统所实现的处理及功能基本相应于前述图1-3所示的方法的实施例、原理和实例，故本实施例的描述中未详尽之处，可以参见前述实施例中的相关说明，在此不做赘述。

本发明实施例二通过接收容器和/或微服务产生的经故障定位后的预警数据；和/或第三方平台发送的携带容器和/或微服务自动伸缩任务计划数据，触发容器自动伸缩或故障调度转移的技术方案，一旦微服务出现异常，加快了服务伸缩的响应时间和处理时间；解放了运维人员处理的繁重工作量；有效控制了人为处理服务伸缩带来的不可控风险；降低了企业的运维成本；有效加快企业推广系统容器化微服务改造；解决了容器收缩策略的限制；扩充了容器化微服务伸缩的多样性和机制；通过对整个调用链的故障传导分析准确的定位了真实的故障点，做到了对容器化微服务的精确伸缩。

实施例三

参照图14，图14示出了本发明提供的一种容器化微服务自动伸缩及迁移调度的设备300，包括前述实施例二中的任一项所述的容器化微服务自动伸缩及迁移调度的系统200。

本发明实施例三通过接收容器和/或微服务产生的经故障定位后的预警数据；和/或第三方平台发送的携带容器和/或微服务自动伸缩任务计划数据，触发容器自动伸缩或故障调度转移的技术方案，一旦微服务出现异常，加快了服务伸缩的响应时间和处理时间；解放了运维人员处理的繁重工作量；有效控制了人为处理服务伸缩带来的不可控风险；降低了企业的运维成本；有效加快企业推广系统容器化微服务改造；解决了容器收缩策略的限制；扩充了容器化微服务伸缩的多样性和机制；通过对整个调用链的故障传导分析准确的定位了真实的故障点，做到了对容器化微服务的精确伸缩。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

需要指出，根据实施的需要，可将本申请中描述的各个步骤/部件拆分为更多步骤/部件，也可将两个或多个步骤/部件或者步骤/部件的部分操作组合成新的步骤/部件，以实现本发明的目的。

上述根据本发明的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器可读介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当所述软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的处理方法。此外，当通用计算机访问用于实现在此示出的处理的代码时，代码的执行将通用计算机转换为用于执行在此示出的处理的专用计算机。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。