用于监控告警系统的全链路监控方法及装置与流程

1.本发明涉及互联网运维技术领域，尤其涉及一种用于监控告警系统的全链路监控方法及装置。


背景技术：

2.监控告警是运维中最重要的一环，通过持续的信息采集、收敛、分析来发现问题，达到事前及时预警发现故障，事后提供详实的数据用于追查和定位问题的目的。监控告警系统同样会出现宕机，我们把对监控告警系统的监控，称为监控告警系统的自监控，目的是及时发现监控告警系统的故障状态，并通知给相关负责人及时处理维护。现有技术中对监控告警系统的监控方案有如下几种：
3.1、通过额外部署第三方监控组件，比如open
‑
falcon使用的自监控服务anteye，部署好之后再给anteye添加一个进程存活监控告警，这样就能实现open
‑
falcon与监控告警系统的相互监控，任何一方出现问题，都可以及时感知；
4.2、通过部署多套监控系统实现相互监控，比如至少有两个独立的prometheus实例互相做交叉监控，每台prometheus通过拉取其余所有prometheus的指标，一旦一台prometheus宕机，其他prometheus都能发现并告警。
5.可见，现有自监控方案中的自监控组件或自监控系统大多与监控告警系统部署在同一基础设施上，一旦基础设施出问题会导致其监控方案的失效，无法达到自监控的目的。另外，由于监控告警的链路较长，从指标信息的获取到告警通知到负责人手上，任意一个步骤如果出现问题，都会导致监控告警失效，而现有的自监控方案只监控系统的状态，缺少对整个链路的监控。


技术实现要素：

6.本发明的目的在于提供一种用于监控告警系统的全链路监控方法及装置，在提升监控告警系统和自监控系统可靠性的同时实现对全链路的持续监控。
7.本发明的第一方面提供一种用于监控告警系统的全链路监控方法，包括：
8.在不同环境中分别部署监控告警系统和自监控系统，使得监控告警系统和自监控系统相互监控；
9.配置监控告警系统的告警指标以及自监控系统的触发频率；
10.自监控系统按照触发频率从监控告警系统中定期获取告警指标，根据告警指标中业务告警指标产生时的时间戳和当前时间戳，判断监控告警系统的告警触发时间是否超时；
11.监控告警系统按照触发频率定期从自监控系统中拉取监控指标，将监控指标与预设阈值比较判断自监控系统的告警触发状态是否正常；
12.基于所述告警触发时间和所述告警触发状态的判断结果，向设定的接收人按照触发频率定期发送告警触发结果。
13.优选地，在不同环境中分别部署监控告警系统和自监控程序的方法包括：
14.将监控告警系统部署在目标机器上，将自监控系统部署在云服务的无服务器架构上。
15.较佳地，配置监控告警系统的告警指标以及自监控系统的触发频率的方法包括：
16.配置的监控告警系统告警指标包括硬件告警指标、业务告警指标和应用程序告警指标；
17.配置的自监控系统的触发频率是指按照触发频率定期从监控告警系统获取硬件告警指标、业务告警指标和应用程序告警指标。
18.进一步地，自监控系统按照触发频率从监控告警系统中定期获取告警指标，根据告警指标中业务告警指标产生时的时间戳和当前时间戳，判断监控告警系统的告警触发时间是否超时的方法包括：
19.自监控系统检查获取到的告警指标是否同时存在硬件告警指标、业务指标告警指标和应用程序告警指标，并在同时存在时基于业务告警指标产生时的时间戳和自监控系统获取告警指标时的当前时间戳的时间差值，
20.当时间差值未超过第一阈值时则判断监控告警系统的告警触发时间未超时，否则判断监控告警系统的告警触发时间超时。
21.进一步地，自监控系统按照触发频率从监控告警系统中定期获取告警指标，根据告警指标中业务告警指标产生时的时间戳和当前时间戳，判断监控告警系统的告警触发时间是否超时的方法还包括：
22.自监控系统检查监控告警系统的数据库中是否存在硬件告警指标、业务告警指标和应用程序告警指标的告警触发记录，同时基于数据库中业务告警指标产生时的时间戳和告警触发记录写入数据库的时间戳的时间差值；
23.当时间差值未超过第二阈值时则判断监控告警系统的告警触发时间未超时，否则判断监控告警系统的告警触发时间超时。
24.进一步地，监控告警系统按照触发频率定期从自监控系统中拉取监控指标，将监控指标与预设阈值比较判断自监控系统的告警触发状态是否正常的方法包括：
25.监控告警系统按照触发频率定期从自监控系统中拉取监控指标，所述监控指标包括自监控系统在触发频率周期内的调用总次数、调用错误次数、调用处理时间、调用内存消耗量中的一种或多种；
26.监控告警系统将拉取的监控指标与预设阈值一一对应比较判断，当任一指标超过预设阈值则认为自监控系统的告警触发状态异常，否则认为自监控系统的告警触发状态正常。
27.可选地，基于所述告警触发时间和所述告警触发状态的判断结果，向设定的接收人按照触发频率定期发送告警触发结果之后还包括：
28.自监控系统定期检查通知系统的回执记录表，判断告警触发结果是否成功发送至指定的接收人；
29.若判断结果为未成功发送至预设的接收人则向通知系统中预先配置的负责人重新发送警触发结果。
30.示例性地，所述监控告警系统包括prometheus系统，所述云服务的无服务器架构
为serverless服务。
31.与现有技术相比，本发明提供的用于监控告警系统的全链路监控方法具有以下有益效果：
32.本发明提供的用于监控告警系统的全链路监控方法中，通过在不同的环境中分别部署监控告警系统和自监控系统，其中，监控告警系统不仅能够对目标机器进行监控，还能实现监控告警系统和自监控系统的相互监控，具体来讲，预先配置监控告警系统的告警指标以及自监控系统的触发频率，然后由自监控系统按照触发频率从监控告警系统中定期获取告警指标，根据告警指标中业务告警指标产生时的时间戳和当前时间戳，判断监控告警系统的告警触发时间是否超时，同时由监控告警系统按照触发频率定期从自监控系统中拉取监控指标，将监控指标与预设阈值比较判断自监控系统的告警触发状态是否正常，最终基于告警触发时间和告警触发状态的判断结果，向设定的接收人按照触发频率定期发送告警触发结果。
33.可见，本发明由于未将监控告警系统和自监控系统部署在同一基础设施上，因此可以有效降低监控告警系统和自监控系统全部失效的风险，同时能够对接收人是否成功接收警触发结果做跟踪监控，进而实现全链路监控。
34.本发明的第二方面提供一种用于监控告警系统的全链路监控装置，应用于上述技术方案所述的用于监控告警系统的全链路监控方法中，所述装置包括：
35.部署单元，用于在不同环境中分别部署监控告警系统和自监控系统，使得监控告警系统和自监控系统相互监控；
36.配置单元，用于配置监控告警系统的告警指标以及自监控系统的触发频率；
37.第一监控单元，用于通过自监控系统按照触发频率从监控告警系统中定期获取告警指标，根据告警指标中业务告警指标产生时的时间戳和当前时间戳，判断监控告警系统的告警触发时间是否超时；
38.第二监控单元，用于通过监控告警系统按照触发频率定期从自监控系统中拉取监控指标，将监控指标与预设阈值比较判断自监控系统的告警触发状态是否正常；
39.发送检测单元，基于所述告警触发时间和所述告警触发状态的判断结果，向设定的接收人按照触发频率定期发送告警触发结果。
40.与现有技术相比，本发明提供的用于监控告警系统的全链路监控装置的有益效果与上述技术方案提供的用于监控告警系统的全链路监控方法的有益效果相同，在此不做赘述。
41.本发明的第三方面提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器运行时执行上述用于监控告警系统的全链路监控方法的步骤。
42.与现有技术相比，本发明提供的计算机可读存储介质的有益效果与上述技术方案提供的用于监控告警系统的全链路监控方法的有益效果相同，在此不做赘述。
附图说明
43.此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
44.图1为本发明实施例中用于监控告警系统的全链路监控方法的流程示意图；
45.图2为本发明实施例中自监控系统监控监控告警系统的任务流程图；
46.图3为本发明实施例中监控告警系统监控自监控系统的任务流程图。
具体实施方式
47.为使本发明的上述目的、特征和优点能够更加明显易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动的前提下所获得的所有其它实施例，均属于本发明保护的范围。
48.实施例一
49.请参阅图1，本实施例提供一种用于监控告警系统的全链路监控方法，包括：
50.在不同环境中分别部署监控告警系统和自监控系统，使得监控告警系统和自监控系统相互监控；配置监控告警系统的告警指标以及自监控系统的触发频率；自监控系统按照触发频率从监控告警系统中定期获取告警指标，根据告警指标中业务告警指标产生时的时间戳和当前时间戳，判断监控告警系统的告警触发时间是否超时；监控告警系统按照触发频率定期从自监控系统中拉取监控指标，将监控指标与预设阈值比较判断自监控系统的告警触发状态是否正常；基于告警触发时间和告警触发状态的判断结果，向设定的接收人按照触发频率定期发送告警触发结果。
51.本实施例提供的用于监控告警系统的全链路监控方法中，通过在不同的环境中分别部署监控告警系统和自监控系统，其中，监控告警系统不仅能够对目标机器进行监控，还能实现监控告警系统和自监控系统的相互监控，具体来讲，预先配置监控告警系统的告警指标以及自监控系统的触发频率，然后由自监控系统按照触发频率从监控告警系统中定期获取告警指标，根据告警指标中业务告警指标产生时的时间戳和当前时间戳，判断监控告警系统的告警触发时间是否超时，同时由监控告警系统按照触发频率定期从自监控系统中拉取监控指标，将监控指标与预设阈值比较判断自监控系统的告警触发状态是否正常，最终基于告警触发时间和告警触发状态的判断结果，向设定的接收人按照触发频率定期发送告警触发结果。
52.可见，本实施例由于未将监控告警系统和自监控系统部署在同一基础设施上，因此可以有效降低监控告警系统和自监控系统全部失效的风险，同时能够对接收人是否成功接收警触发结果做跟踪监控，进而实现全链路监控。
53.上述实施例中，在不同环境中分别部署监控告警系统和自监控程序的方法包括：
54.将监控告警系统部署在目标机器上，将自监控系统部署在云服务的无服务器架构上。
55.示例性地，监控告警系统包括prometheus系统，云服务的无服务器架构为serverless服务。
56.具体实施时，监控告警系统包括prometheus和alertmanager，prometheus和alertmanager分别部署在目标机器上并与目标机器保持信号连接，同时与目标机器共建于同一基础设施，通过监控告警系统可对目标机器进行持续的监控告警并获取告警指标。而
将自监控系统部署在云服务的无服务器架构上，也即serverless服务上，利用prometheus与自监控系统保持信号连接，使得自监控系统能够通过prometheus定期获取告警指标，实现对监控告警系统的告警触发时间进行监控，同理，监控告警系统能够从自监控系统中定期获取监控指标，实现对自监控系统的告警触发状态进行监控，从而实现监控告警系统与自监控系统的相互监控。优选地，自监控系统为自监控程序。
57.可见，本实施例将监控告警系统和自监控系统分别部署在不同的环境中，能够有效降低监控告警系统和自监控系统全部失效的风险，而将自监控系统部署在无服务器服务上，由于不依赖底层的基础设施，通知方式等都通过云服务进行，解决了因基础设施出问题后导致所有监控系统都宕机的风险，且降低了采购和运维成本。
58.上述实施例中，配置监控告警系统的告警指标以及自监控系统的触发频率的方法包括：
59.配置的监控告警系统的告警指标包括硬件告警指标、业务告警指标和应用程序告警指标；配置的自监控系统的触发频率是指按照触发频率定期从监控告警系统获取硬件告警指标、业务告警指标和应用程序告警指标。
60.具体实施时，通过监控告警系统配置三种告警类别，分别为硬件告警、tomcat应用告警和业务告警，其中，硬件告警用于监测目标机器的服务器的cpu、内存、网络流量等资源消耗情况并在大于阈值时告警，应用程序告警用于监测目标机器的jvm状态、应用健康检查接口是否正常，状态正常即告警，业务告警是tomcat应用主动上报的以当前时间戳为业务值的告警，指标大于0即告警。
61.通常来讲，当目标机器正常工作时，硬件告警指标、业务告警指标和应用程序告警指标均会大于阈值0，所以上述三种告警指标均会一直触发，自监控系统会定时检查这三类告警是否正常下发到接收人终端，下发的方式包括短信告警提醒、邮件告警提醒、通讯软件告警提醒等。
62.上述实施例中，自监控系统按照触发频率从监控告警系统中定期获取告警指标，根据告警指标中业务告警指标产生时的时间戳和当前时间戳，判断监控告警系统的告警触发时间是否超时的方法包括：
63.自监控系统检查获取到的告警指标是否同时存在硬件告警指标、业务告警指标和应用程序告警指标，并在同时存在时基于业务告警指标产生时的时间戳和自监控系统获取告警指标时的当前时间戳的时间差值；当时间差值未超过第一阈值时则判断监控告警系统的告警触发时间未超时，否则判断监控告警系统的告警触发时间超时。
64.请参阅图2，具体实施时，将自监控系统部署在serverless服务上，配置触发方式为间隔n分钟执行一次。自监控系统按监控监控告警系统的任务流程为：
65.1、检查prometheus上是否同时存在已上三种告警指标，若不同时存在则表示告警异常，若同时存在则继续检查业务告警指标的时间戳和当前时间对比求差值，当差值未超过第一阈值则表示告警触发未超时，否则表示告警触发超时；
66.2、检查监控告警系统的数据库是否存在已上三种告警的触发记录，对比插入数据库时的时间戳和业务告警指标的时间戳求差值，当差值未超过第二阈值则表示告警触发未超时，否则表示告警触发超时；
67.3、检查通知系统各渠道方式是否成功发送已上三种告警；
68.4、检查通知系统的回执记录表，对有回执渠道的通知方式(短信、电话)，检查回执记录，判断通知是否成功下发到接收人终端。
69.5、已上任意一个步骤有异常，通过云监控服务的通知方式，通知给相关负责人，进而实现对告警过程的全链路监控。
70.检测流程采用流水线模式将整个监控告警链路拆解成多个环节，轮询各个步骤的状态，从而对整个链路进行检测，不仅能确认告警通知是否触达到接收人，而且还能定位到出故障的具体步骤。
71.上述实施例中，监控告警系统按照触发频率定期从自监控系统中拉取监控指标，将监控指标与预设阈值比较判断自监控系统的告警触发状态是否正常的方法包括：
72.监控告警系统按照触发频率定期从自监控系统中拉取监控指标，监控指标包括自监控系统在触发频率周期内的调用总次数、调用错误次数、调用处理时间、调用内存消耗量中的一种或多种；监控告警系统将拉取的监控指标与预设阈值一一对应比较判断，当任一指标超过预设阈值则认为自监控系统的告警触发状态异常，否则认为自监控系统的告警触发状态正常。
73.请参阅图3，具体实施时，监控告警系统监控自监控系统的任务流程为：
74.1、prometheus拉取自监控系统的指标，包括：n分钟内调用总次数、n分钟内调用错误次数、调用处理时间(函数执行时间)、内存消耗量；
75.2、prometheus配置自监控系统告警，当出现n分钟内调用总次数为0、n分钟内调用错误次数大于0、函数执行时间大于30s、内存消耗大于500m任一种或多种情况时告警；
76.3、prometheus触发告警，通知alertmanager对告警分组去重抑制静默操作，减少用户接收告警通知的打扰率，然后调用监控告警系统；示例性地，分组是将多个数据库实例的告警汇总成一个告警，抑制是指若某台机器挂了，部署在这台机器的所有应用不告警，只告警机器挂了即可，静默是指在非工作日不告警，仅在工作日告警。
77.4、监控告警系统查找对应接收人，并根据告警等级选择不同的通知方式；
78.5、调用通知系统将告警通知采用选择的通知方式下发到接收人的终端。
79.上述实施例中，基于所述告警触发时间和所述告警触发状态的判断结果，向设定的接收人按照触发频率定期发送告警触发结果之后还包括：
80.自监控系统定期检查通知系统的回执记录表，判断告警触发结果是否成功发送至指定的接收人；若判断结果为未成功发送至预设的接收人则向通知系统中预先配置的负责人重新发送警触发结果。
81.具体实施时，接收人为用户，负责人为相关系统的责任人，当告警触发结果不能正常发送至预先配置的指定接收人手中时，及时将这一异常现象发送至责任人，以通知其对相关系统进行排查维护。
82.实施例二
83.本实施例提供一种用于监控告警系统的全链路监控装置，包括：
84.部署单元，用于在不同环境中分别部署监控告警系统和自监控系统，使得监控告警系统和自监控系统相互监控；
85.配置单元，用于配置监控告警系统的告警指标以及自监控系统的触发频率；
86.第一监控单元，用于通过自监控系统按照触发频率从监控告警系统中定期获取告
警指标，根据告警指标中业务告警指标产生时的时间戳和当前时间戳，判断监控告警系统的告警触发时间是否超时；
87.第二监控单元，用于通过监控告警系统按照触发频率定期从自监控系统中拉取监控指标，将监控指标与预设阈值比较判断自监控系统的告警触发状态是否正常；
88.发送检测单元，基于所述告警触发时间和所述告警触发状态的判断结果，向设定的接收人按照触发频率定期发送告警触发结果。
89.与现有技术相比，本发明提供的用于监控告警系统的全链路监控装置的有益效果与上述技术方案提供的用于监控告警系统的全链路监控方法的有益效果相同，在此不做赘述。
90.上述实施例中，在不同环境中分别部署监控告警系统和自监控程序的方法包括：
91.将监控告警系统部署在目标机器上，将自监控系统部署在云服务的无服务器架构上。
92.示例性地，监控告警系统包括prometheus系统，云服务的无服务器架构为serverless服务。
93.具体实施时，监控告警系统包括prometheus和alertmanager，prometheus和alertmanager分别部署在目标机器上并与目标机器保持信号连接，同时与目标机器共建于同一基础设施，通过监控告警系统可对目标机器进行持续的监控告警并获取告警指标。而将自监控系统部署在云服务的无服务器架构上，也即serverless服务上，利用prometheus与自监控系统保持信号连接，使得自监控系统能够通过prometheus定期获取告警指标，实现对监控告警系统的告警触发时间进行监控，同理，监控告警系统能够从自监控系统中定期获取监控指标，实现对自监控系统的告警触发状态进行监控，从而实现监控告警系统与自监控系统的相互监控。优选地，自监控系统为自监控程序。
94.可见，本实施例将监控告警系统和自监控系统分别部署在不同的环境中，能够有效降低监控告警系统和自监控系统全部失效的风险，而将自监控系统部署在无服务器服务上，由于不依赖底层的基础设施，通知方式等都通过云服务进行，解决了因基础设施出问题后导致所有监控系统都宕机的风险，且降低了采购和运维成本。
95.上述实施例中，配置监控告警系统的告警指标以及自监控系统的触发频率的方法包括：
96.配置的监控告警系统的告警指标包括硬件告警指标、业务告警指标和应用程序告警指标；配置的自监控系统的触发频率是指按照触发频率定期从监控告警系统获取硬件告警指标、业务告警指标和应用程序告警指标。
97.具体实施时，通过监控告警系统配置三种告警类别，分别为硬件告警、tomcat应用告警和业务告警，其中，硬件告警用于监测目标机器的服务器的cpu、内存、网络流量等资源消耗情况并在大于阈值时告警，应用程序告警用于监测目标机器的jvm状态、应用健康检查接口是否正常，状态正常即告警，业务告警是tomcat应用主动上报的以当前时间戳为业务值的告警，指标大于0即告警。
98.通常来讲，当目标机器正常工作时，硬件告警指标、业务告警指标和应用程序告警指标均会大于阈值0，所以上述三种告警指标均会一直触发，自监控系统会定时检查这三类告警是否正常下发到接收人终端，下发的方式包括短信告警提醒、邮件告警提醒、通讯软件
告警提醒等。
99.上述实施例中，自监控系统按照触发频率从监控告警系统中定期获取告警指标，根据告警指标中业务告警指标产生时的时间戳和当前时间戳，判断监控告警系统的告警触发时间是否超时的方法包括：
100.自监控系统检查获取到的告警指标是否同时存在硬件告警指标、业务告警指标和应用程序告警指标，并在同时存在时基于业务告警指标产生时的时间戳和自监控系统获取告警指标时的当前时间戳的时间差值；当时间差值未超过第一阈值时则判断监控告警系统的告警触发时间未超时，否则判断监控告警系统的告警触发时间超时。
101.具体实施时，将自监控系统部署在serverless服务上，配置触发方式为间隔n分钟执行一次。自监控系统按监控监控告警系统的任务流程为：
102.1、检查prometheus上是否同时存在已上三种告警指标，若不同时存在则表示告警异常，若同时存在则继续检查业务告警指标的时间戳和当前时间对比求差值，当差值未超过第一阈值则表示告警触发未超时，否则表示告警触发超时；
103.2、检查监控告警系统的数据库是否存在已上三种告警的触发记录，对比插入数据库时的时间戳和业务告警指标的时间戳求差值，当差值未超过第二阈值则表示告警触发未超时，否则表示告警触发超时；
104.3、检查通知系统各渠道方式是否成功发送已上三种告警；
105.4、检查通知系统的回执记录表，对有回执渠道的通知方式(短信、电话)，检查回执记录，判断通知是否成功下发到接收人终端。
106.5、已上任意一个步骤有异常，通过云监控服务的通知方式，通知给相关负责人，进而实现对告警过程的全链路监控。
107.检测流程采用流水线模式将整个监控告警链路拆解成多个环节，轮询各个步骤的状态，从而对整个链路进行检测，不仅能确认告警通知是否触达到接收人，而且还能定位到出故障的具体步骤。
108.上述实施例中，监控告警系统按照触发频率定期从自监控系统中拉取监控指标，将监控指标与预设阈值比较判断自监控系统的告警触发状态是否正常的方法包括：
109.监控告警系统按照触发频率定期从自监控系统中拉取监控指标，监控指标包括自监控系统在触发频率周期内的调用总次数、调用错误次数、调用处理时间、调用内存消耗量中的一种或多种；监控告警系统将拉取的监控指标与预设阈值一一对应比较判断，当任一指标超过预设阈值则认为自监控系统的告警触发状态异常，否则认为自监控系统的告警触发状态正常。
110.具体实施时，监控告警系统监控自监控系统的任务流程为：
111.1、prometheus拉取自监控系统的指标，包括：n分钟内调用总次数、n分钟内调用错误次数、调用处理时间(函数执行时间)、内存消耗量；
112.2、prometheus配置自监控系统告警，当出现n分钟内调用总次数为0、n分钟内调用错误次数大于0、函数执行时间大于30s、内存消耗大于500m任一种或多种情况时告警；
113.3、prometheus触发告警，通知alertmanager对告警分组去重抑制静默操作，减少用户接收告警通知的打扰率，然后调用监控告警系统；示例性地，分组是将多个数据库实例的告警汇总成一个告警，抑制是指若某台机器挂了，部署在这台机器的所有应用不告警，只
告警机器挂了即可，静默是指在非工作日不告警，仅在工作日告警。
114.4、监控告警系统查找对应接收人，并根据告警等级选择不同的通知方式；
115.5、调用通知系统将告警通知采用选择的通知方式下发到接收人的终端。
116.上述实施例中，基于所述告警触发时间和所述告警触发状态的判断结果，向设定的接收人按照触发频率定期发送告警触发结果之后还包括：
117.自监控系统定期检查通知系统的回执记录表，判断告警触发结果是否成功发送至指定的接收人；若判断结果为未成功发送至预设的接收人则向通知系统中预先配置的负责人重新发送警触发结果。
118.具体实施时，接收人为用户，负责人为相关系统的责任人，当告警触发结果不能正常发送至预先配置的指定接收人手中时，及时将这一异常现象发送至责任人，以通知其对相关系统进行排查维护。
119.实施例三
120.本实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器运行时执行上述用于监控告警系统的全链路监控方法的步骤。
121.与现有技术相比，本实施例提供的计算机可读存储介质的有益效果与上述技术方案提供的用于监控告警系统的全链路监控方法的有益效果相同，在此不做赘述。
122.本领域普通技术人员可以理解，实现上述发明方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，上述程序可以存储于计算机可读取存储介质中，该程序在执行时，包括上述实施例方法的各步骤，而的存储介质可以是：rom/ram、磁碟、光盘、存储卡等。
123.以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。