服务稳定性的测量方法及装置与流程

本发明涉及计算机应用技术领域，尤其涉及服务稳定性的测量方法及装置。

背景技术：

服务稳定性是指服务在实际运行时可用同时不出现故障。服务稳定性测试是概率性的测试。目前，主要通过服务在上线之前进行服务稳定性测试，根据业务的实际使用场景的用户操作，构建测试模型，模拟实际的场景运行，并观察服务在有负载的情况下看业务运行是否正常，是否有存在内存泄露，系统崩溃和异常重启等，在线下稳定性测试通过的基础上将服务进行上线，但是即使稳定性测试通过，也不能保证上线后的服务在实际运行的时候不出现故障。因此，通常需要确定上线后的服务接口的服务稳定性。

目前，主要通过手动记录上线后服务接口在时间段内的故障情况，从而确定出服务接口的服务稳定性。

但是，上述方式确定服务稳定性可能不能准确的反映出服务接口的实际情况，可能不能及时对服务接口进行维护，导致用户体验较差。

技术实现要素：

本发明提供了一种服务稳定性的测量方法、装置、计算机可读存储介质及电子设备，得到的服务稳定性综合考虑了运行信息以及故障信息，可较为准确的反映出服务接口的服务稳定情况，从而确保服务接口的正常运行以及及时维护，进而改善用户体验。

第一方面，本发明提供了一种服务稳定性的测量方法，包括：

获取服务接口对应的至少一个接口事件以及获取所述接口事件对应的多个运行日志；

根据各个所述接口事件分别对应的多个运行日志，确定故障信息以及运行信息，其中，所述故障信息包括故障次数；

根据所述故障信息以及运行信息，确定所述服务接口对应的服务稳定性。

可选地，所述获取所述接口事件对应的多个运行日志，包括：

接收所述服务接口对应的服务执行所述接口事件发送的返回值；

根据所述返回值，获取所述接口事件对应的运行日志。

可选地，所述根据所述返回值，获取所述接口事件对应的运行日志，包括：

当所述返回值满足预设运行正常条件时，确定事件运行结果为运行正常关键词，否则，确定事件运行结果为运行故障关键词；

根据所述事件运行结果，确定所述接口事件对应的运行日志。

可选地，所述运行日志还包括事件标识、事件名称和事件运行时间。

可选地，所述根据各个所述接口事件分别对应的多个运行日志，确定故障信息，包括：

获取至少一个异常故障对应的至少一个异常时段；

根据各个所述接口事件分别对应的多个运行日志，确定总故障次数以及各个所述异常时段内的异常故障次数；

根据所述总故障次数和异常故障次数，确定故障信息。

可选地，所述至少一个异常故障包括服务升级、服务上线、服务重启、网络异常中的任意一项或多项。

可选地，所述根据所述总故障次数和异常故障次数，确定故障信息，包括：

将所述总故障次数和所述异常故障次数之差作为故障信息。

第二方面，本发明提供了一种服务稳定性的测量装置，包括：

获取模块，用于获取服务接口对应的至少一个接口事件以及获取所述接口事件对应的多个运行日志；

信息确定模块，用于根据各个所述接口事件分别对应的多个运行日志，确定故障信息以及运行信息，其中，所述故障信息包括故障次数；

稳定性确定模块，用于根据所述故障信息以及运行信息，确定所述服务接口对应的服务稳定性。

第三方面，本发明提供了一种计算机可读存储介质，包括执行指令，当电子设备的处理器执行所述执行指令时，所述处理器执行如第一方面中任一所述的方法。

第四方面，本发明提供了一种电子设备，包括处理器以及存储有执行指令的存储器，当所述处理器执行所述存储器存储的所述执行指令时，所述处理器执行如第一方面中任一所述的方法。

本发明提供了一种服务稳定性的测量方法、装置、计算机可读存储介质及电子设备，该方法通过获取服务接口对应的若干个接口事件以及接口事件对应的多个运行日志，然后，根据若干个接口事件分别对应的多个运行日志，确定故障信息以及运行信息，之后，根据故障信息以及运行信息，获取服务接口对应的服务稳定性，得到的服务稳定性综合考虑了服务接口的运行信息以及故障信息，可较为准确的反映出服务接口的服务稳定情况，从而确保服务接口的正常运行以及及时维护，进而改善用户体验。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

为了更清楚地说明本发明实施例或现有的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明一实施例提供的一种服务稳定性的测量方法的流程示意图；

图2为本发明一实施例提供的另一种服务稳定性的测量方法的流程示意图；

图3为本发明一实施例提供的一种服务稳定性的测量装置的结构示意图；

图4为本发明一实施例提供的一种电子设备的结构示意图。

具体实施方式

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

前述已知，主要通过手工记录上线后服务接口在时间段内的故障情况，从而确定出服务接口的服务稳定情况。但是时间段内的故障情况可能不能准确的反映出实际的服务稳定情况，同时，人工记录不仅耗时耗力，同时容易出现记录错误及遗漏等的情况。本发明则试图基于服务接口的若干个接口事件以及接口事件的运行日志，确定出服务接口的故障信息以及运行信息，并利用故障信息以及运行信息，确定服务接口对应的服务稳定性。所以相对于传统方法，本发明实施例能够较为准确的确定出服务接口的服务稳定情况，同时可避免人工记录过程中出现的数据错误。

参照图1所示，为本发明所述服务稳定性的测量方法的一个具体实施例。本实施例中所述方法包括以下步骤：

步骤101，获取服务接口对应的至少一个接口事件以及获取所述接口事件对应的运行日志。

具体而言，服务接口可以理解为应用程序接口，应用程序接口是操作系统留给应用程序的一个调用接口，应用程序通过调用操作系统的服务接口而使操作系统去执行应用程序的命令。接口事件具体指的是可以被窗体或控件识别的操作，接口事件包括但不限于数据地址、数据访问方法以及访问返回的数据的验证方法，作为一个示例，接口事件包括统一资源定位符(uniformresourcelocator，简称url)，统一资源定位符是对可以从互联网上得到的资源的位置和访问方法的一种简洁的表示，是互联网上标准资源的地址，互联网上的每个文件都有一个唯一的统一资源定位符，它包含的信息指出文件的位置以及浏览器应该怎么处理它。接口事件对应的运行日志具体指的是执行接口事件时所产生的事件记录，运行日志主要用于记录接口事件的执行过程和执行结果。

具体地，服务接口对应多个接口事件，多个接口事件预先存储在数据库中，当需要执行接口事件时，从数据库中调用即可，可选的，接口事件可以由工作人员结合实际场景进行配置，在一个示例中，假设需要完成一个浏览器搜索，此时工作人员可以通过前端页面配置请求信息，后端基于请求信息生成对应的接口事件后存储到数据库中，当执行接口事件时，从数据库中调用该接口事件，从而完成浏览器搜索，这里，通过前端页面配置后端生成接口事件的方法，相对于直接编写接口事件代码而言，能够重复多次利用前端页面框架，从而能够更为快速的得到大量的接口事件，降低后端代码的工作难度，提高接口事件的配置效率。

具体而言，通过执行该接口事件，从而得到执行该接口事件的运行日志。需要说明的是，这里，一个接口事件对应的多个运行日志，每个运行日志代表一条运行记录，即一个接口事件重复多次执行，每次执行均得到一个运行日志。

步骤102，根据各个所述接口事件分别对应的多个运行日志，确定故障信息以及运行信息，其中，所述故障信息包括故障次数。

这里，各个接口事件分别对应的多个运行日志能够反映出服务接口的整体运行情况，通过对这些运行日志进行统计分析，能够得到服务接口的故障信息以及服务接口的运行信息。其中，故障信息具体指的是执行接口事件的故障情况，可选的，异常情况包括但不限于故障次数、故障原因、故障时间段等。运行信息具体指的是执行各个接口事件的运行情况，可选的，运行情况包括但不限于运行次数、运行正常次数、运行时间段等，运行次数包括运行正常次数以及故障次数，是各个接口事件总的运行次数。

具体地，获取一定时段内的各个接口事件分别对应的多个运行日志，从而使得故障信息以及运行信息能够反映出服务接口在一定时段内的整体故障和运行情况。

步骤103，根据所述故障信息以及运行信息，确定所述服务接口对应的服务稳定性。

具体地，服务稳定性因综合考虑了服务接口的故障信息以及运行信息，从而确保其具有相对较高的准确性。这里，服务稳定性用于指示服务接口的稳定性，从而在服务接口的出现问题时及时通知工作人员，以便工作人员将出现的问题及时反馈给相关技术人员，以提高解决服务接口问题的效率，且可避免由于服务接口的稳定性问题而导致无法正常提供服务，进而提升服务对应的线上业务的稳定性，大大提升用户体验。

需要说明的是，当需要确定某一服务的稳定性时，具体地，确定服务对应的若干个服务接口，针对每个服务接口，获取该服务接口对应的若干个接口事件以及每个接口事件分别对应的多个运行日志，基于各个服务接口分别对应的多个运行日志，确定服务的故障信息以及运行信息，基于故障信息以及运行信息，确定服务对应的服务稳定性。举例来说，服务可以是搜索业务，搜索业务对应的服务接口可以是搜索列表的接口、搜索内容的接口、统计信息的接口，确定搜索列表的接口、搜索内容的接口、统计信息的接口分别对应的多个运行日志，基于搜索列表的接口、搜索内容的接口、统计信息的接口分别对应的多个运行日志，确定搜索业务的故障信息及运行信息，进而确定出搜索业务的服务稳定性。这里，搜索列表的接口用于获取用户在搜索框输入时下方的推荐内容，包括若干个条排列的内容，比如，在浏览器的搜索框内输入用药频率时，搜索框下方可能会出现若干条用药频率的相关推送信息；搜索内容的接口用于获取用户输入的关键词对应的内容；统计信息的接口用于对用户输入的关键词对应的内容进行统计分析。

通过以上技术方案可知，本实施例所述方法具备的有益效果是：通过获取服务接口对应的若干个接口事件，从而了解服务接口的服务情况，然后，获取了接口事件对应的多个运行日志，从而了解接口事件的运行情况，基于各个接口事件分别对应的多个运行日志，确定服务接口的故障信息以及运行信息，之后，综合考虑故障信息以及运行信息，确定服务接口对应的服务稳定性，该服务稳定性可较为准确的反映出服务接口的服务稳定情况，从而确保服务接口的正常运行，进而改善用户体验，同时，可基于服务稳定性及时的对服务接口进行维护，提高用户体验。

图1所示仅为本发明所述方法的基础实施例，在其基础上进行一定的优化和拓展，还能够得到所述方法的其他可选实施例。

如图2所示，为本发明所述服务稳定性的测量方法的另一个具体实施例。本实施例在前述实施例的基础上，对于确定服务稳定性的过程进行了更具体的描述和一定程度的优化。本实施例所述方法的目的在于结合服务接口对应的若干个接口事件分别对应的多个运行日志，确定服务接口的服务稳定性。

本实施例中所述方法包括以下步骤：

步骤201，获取服务接口对应的至少一个接口事件。

服务接口为目标应用系统的接口，例如，假设目标应用系统为浏览器，服务接口可以是搜索内容的接口。需要说明的是，浏览器只是举例说明，并不对本发明实施例进行任何限定。以下以搜索内容的接口为例进行详细阐述。

具体地，接口事件包括但不限于请求信息以及返回值验证方法，当接口事件为搜索内容时，请求信息包括但不限于接口名称、统一资源定位符、请求类型、请求参数。其中，接口名称用于说明服务接口的名称，统一资源定位符用于说明数据位置，请求类型用于说明请求方法，可选的，包括但不限于get(完整请求一个资源)、post(提交表单)、put(上传文件)、delete(删除)、patch、head(仅请求响应首部)、options(返回请求的资源所支持的方法)、trace(追求一个资源请求中间所经过的代理)，请求参数用于说明请求的数据，返回值验证方法用于验证请求后的返回值是否正常。

步骤202，接收所述服务接口对应的服务执行所述接口事件发送的返回值。

具体地，接收服务接口对应的服务以预设时间间隔执行接口事件发送的返回值。返回值可以理解为执行接口事件的结果，这里，预设时间间隔具体需要结合实际场景确定，过长可能会导致运行日志的参考价值较小，过短可能会导致运行日志的数量过多，无用数据过多，降低数据质量以及数据处理效率，可选的，预设时间间隔可以是10分钟。其中，服务是一种在后台运行的程序所提供的某种功能。

举例来说，获取搜索内容的接口对应的统一资源定位符，将统一资源定位符发送至对应的浏览器，接收浏览器根据统一资源定位符获得的返回值，该返回值为搜索内容。

步骤203，当所述返回值满足预设运行正常条件时，确定事件运行结果为运行正常关键词，否则，确定事件运行结果为运行故障关键词；根据所述事件运行结果，确定所述接口事件对应的运行日志。

具体地，返回值满足预设运行正常条件，则说明事件运行结果正常，事件运行结果为运行正常关键词，运行正常关键词用于说明事件运行结果是正确的，比如，可以是通过、正常等词语。返回值不满足预设运行正常条件，则说明事件运行结果异常，事件运行结果为运行故障关键词，运行故障关键词用于说明事件运行结果是异常的，比如，可以是故障、异常等词语。之后，根据事件运行结果，确定接口事件对应的运行日志，从而记录接口事件的运行情况。

需要说明的是，预设运行正常条件是基于执行接口事件的结果确定的，比如，接口事件是搜索列表，则预设正常运行条件可以是搜索列表的内容的条数大于0。

需要说明的是，接口事件对应的运行日志包括但不限于事件标识、事件名称、事件运行时间以及事件运行结果。其中，事件标识用于区分不同的接口事件；事件名称用于说明接口事件的类型；事件运行时间用于说明请求信息发送时间，或者执行接口事件的起始时间点；事件运行结果用于说明接口事件是否发生异常，显然，如果是运行正常关键词，则说明接口事件正常，如果是运行故障关键词，则说明接口事件异常。

可选的，在数据库中存储服务接口对应的若干个接口事件，建立监控平台和目标应用系统之间的服务接口，使得监控平台能够调用接口事件，并将接口事件发送至目标应用系统，使得目标应用系统执行接口事件，并将返回值发送给监控平台检验，从而得到事件运行结果，进而得到运行日志。举例来说，接口事件为搜索内容的统一资源定位符，目标应用系统为浏览器，当执行接口事件时，监控平台调用接口事件，从而获取统一资源定位符，通过监控平台和浏览器之间的服务接口将统一资源定位符发送至浏览器，并通过监控平台和浏览器之间的服务接口接收浏览器发送的返回值，对返回值进行检验，得到事件运行结果，基于事件运行结果、发送统一资源定位符的时间、事件名称、事件标识，确定出接口事件的运行日志，这里，可以每隔10分钟执行一次接口事件，从而得到该接口事件对应的多个运行日志。

步骤204，获取异常故障对应的至少一个异常时段；根据各个所述接口事件分别对应的多个运行日志，确定总故障次数以及各个所述异常时段内的异常故障次数；将所述总故障次数和异常故障次数之差作为故障信息。

需要说明的是，考虑到异常故障可能会导致服务接口运行异常，但是该服务接口运行异常并不是由于服务接口本身导致的，因此，需要排除因异常故障导致的服务接口运行异常的情况，从而确保故障信息的准确性。

具体地，若干个异常故障包括但不限于服务升级、服务上线、服务重启、网络异常等任意一项或多项，本发明实施例对此不做具体限定。需要说明的是，服务升级、服务上限、服务重启、网络异常在实际场景可能对应有不同或者同一应用软件进行统一管理，通过建立和该应用软件的服务接口，从而获取若干个异常故障对应的若干个异常时段。

具体地，针对每个异常故障，获取异常故障对应的若干个异常时段，每个异常时段包括异常开始时间点以及异常结束时间点，从所有的运行日志中确定出每个异常时段内的运行日志，确定每个异常时段内的运行日志中的运行故障关键词的出现次数；将每个异常故障对应的运行故障关键词的出现次数之和作为异常故障次数。然后，确定所有运行日志中的运行故障关键词的出现次数为总故障次数，之后，基于总故障次数和异常故障次数，确定出故障信息，得到的故障信息综合考虑了总故障次数以及异常故障次数而具有相对较高的准确性。这里，故障信息为故障次数，故障次数为总故障次数和异常故障次数的差值。

为方便说明，这里以一个异常故障为例进行说明，假设异常故障存在n个异常时段，第i个异常时段的异常开始时间点为is，异常结束时间点为ie，针对第i个异常时段，筛选出事件运行时间在is到ie这一时段内的若干个运行日志，并确定筛选出的若干个运行日志中的运行故障关键词的出现次数，并将其作为第i个异常时段的异常次数ei，将e1+e2+…+ei+…+en作为异常故障次数，即异常故障次数为n个异常时段分别对应的异常次数之和。

步骤205，根据各个所述接口事件分别对应的多个运行日志，确定运行信息。

在一种可行的实现方式中，运行信息为运行日志的数量，即运行次数。举例来说，假设运行日志共有m条，则运行次数为m。

在另一种可行的实现方式中，运行信息为运行正常次数，运行正常次数为运行正常关键词出现的次数与异常故障次数之和，假设运行日志共有m条，运行正常关键词出现的数量为m1，异常故障次数为m2，则运行正常次数为m1+m2。

步骤206，根据所述故障信息以及运行信息，确定所述服务接口对应的服务稳定性。

可行的，确定运行次数和故障次数的差值，并将该差值和运行次数的比值的百分比作为服务稳定性，实现对服务稳定性的量化。举例来说，假设运行次数为m，故障次数为x，那么，服务稳定性为

可行的，确定运行正常次数和故障次数的差值，并将该差值和运行正常次数的比值的百分比作为服务稳定性，实现对服务稳定性的量化。举例来说，假设运行次数为m，故障次数为x，那么，服务稳定性为

在一种可能的场景中，当服务升级时，可根据上述步骤确定服务升级前的服务稳定性，以及服务升级后的服务稳定性，从而实现对服务升级前后的服务稳定性的比对。

需要说明的是，运行信息和故障信息是基于一定时段内的服务接口的多个运行日志确定的，因此，运行信息和故障信息能够反映出服务接口在一定时段内的整体故障情况和运行情况。这里，一定时段可以是周、月等，具体需要结合实际情况确定，可以计算每周和/或每月的服务稳定性。

通过以上技术方案可知，本实施例所述方法存在的有益效果是：获取服务接口对应的若干个接口事件，通过执行接口事件并对执行接口事件的执行结果进行验证，从而获取接口事件对应的多个运行日志，并基于多个运行日志获取总故障次数以及运行次数，基于异常故障的若干个异常时段对总故障次数进行校正，将不是由于服务接口本身故障导致的运行故障排除，从而得到更为准确的故障次数，基于故障次数以及运行次数，确定服务接口的服务稳定性，得到的服务稳定性综合考虑了运行信息以及故障信息，可较为准确的反映出服务接口的服务稳定情况，从而确保服务接口的正常运行以及及时维护，进而改善用户体验。同时，当服务升级时，能够用于评价服务升级前后服务接口的稳定性变化，实现对服务稳定性这一指标的量化。

基于与本发明方法实施例相同的构思，请参考图3，本发明实施例还提供了一种服务稳定性的测量装置，包括：

获取模块301，用于获取服务接口对应的至少一个接口事件以及获取所述接口事件对应的多个运行日志；

信息确定模块302，用于根据各个所述接口事件分别对应的多个运行日志，确定故障信息以及运行信息，其中，所述故障信息包括故障次数；

稳定性确定模块303，用于根据所述故障信息以及运行信息，确定所述服务接口对应的服务稳定性。

本发明一个实施例中，所述获取模块301，包括：执行单元以及日志确定单元；其中，

所述执行单元，用于接收所述服务接口对应的服务执行所述接口事件发送的返回值；

所述日志确定单元，用于根据所述返回值，获取所述接口事件对应的运行日志。

本发明一个实施例中，所述日志确定单元，具体用于执行如下步骤：

当所述返回值满足预设运行正常条件时，确定事件运行结果为运行正常关键词，否则，确定事件运行结果为运行故障关键词；

根据所述事件运行结果，确定所述接口事件对应的运行日志。

本发明一个实施例中，所述运行日志还包括事件标识、事件名称和事件运行时间。

本发明一个实施例中，所述信息确定模块302，包括：时段确定单元、次数确定单元以及故障确定单元；其中，

所述时段确定单元，用于获取至少一个异常故障对应的至少一个异常时段；

所述次数确定单元，用于根据各个所述接口事件分别对应的多个运行日志，确定总故障次数以及各个所述异常时段内的异常故障次数；

所述故障确定单元，用于根据所述总故障次数和异常故障次数，确定故障信息。

本发明一个实施例中，所述至少一个异常故障包括服务升级、服务上线、服务重启、网络异常中的任意一项或多项。

本发明一个实施例中，所述根据所述总故障次数和异常故障次数，确定故障信息，包括：

将所述总故障次数和所述异常故障次数之差作为故障信息。

图4是本发明实施例提供的一种电子设备的结构示意图。在硬件层面，该电子设备包括处理器401以及存储有执行指令的存储器402，可选地还包括内部总线403及网络接口404。其中，存储器402可能包含内存4021，例如高速随机存取存储器(random-accessmemory，ram)，也可能还包括非易失性存储器4022(non-volatilememory)，例如至少1个磁盘存储器等；处理器401、网络接口404和存储器402可以通过内部总线403相互连接，该内部总线403可以是isa(industrystandardarchitecture，工业标准体系结构)总线、pci(peripheralcomponentinterconnect，外设部件互连标准)总线或eisa(extendedindustrystandardarchitecture，扩展工业标准结构)总线等；内部总线403可以分为地址总线、数据总线、控制总线等，为便于表示，图4中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。当然，该电子设备还可能包括其他业务所需要的硬件。当处理器401执行存储器402存储的执行指令时，处理器401执行本发明任意一个实施例中的方法，并至少用于执行如图1或图2所示的方法。

在一种可能实现的方式中，处理器从非易失性存储器中读取对应的执行指令到内存中然后运行，也可从其它设备上获取相应的执行指令，以在逻辑层面上形成一种服务稳定性的测量装置。处理器执行存储器所存放的执行指令，以通过执行的执行指令实现本发明任一实施例中提供的一种服务稳定性的测量方法。

处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(centralprocessingunit，cpu)、网络处理器(networkprocessor，np)等；还可以是数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现场可编程门阵列(field－programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本发明实施例还提供了一种计算机可读存储介质，包括执行指令，当电子设备的处理器执行执行指令时，所述处理器执行本发明任意一个实施例中提供的方法。该电子设备具体可以是如图4所示的电子设备；执行指令是一种服务稳定性的测量装置所对应计算机程序。

本领域内的技术人员应明白，本发明的实施例可提供为方法或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例，或软件和硬件相结合的形式。

本发明中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者锅炉不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者锅炉所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者锅炉中还存在另外的相同要素。

以上所述仅为本发明的实施例而已，并不用于限制本发明。对于本领域技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的权利要求范围之内。