一种负载均衡中健康检查的方法、装置以及系统

技术领域

本申请涉及负载均衡领域，具体而言本申请实施例涉及一种负载均衡中健康检查的方法、装置以及系统。

背景技术

随着互联网用户的飞速发展，单一服务器无法应对大量用户的业务压力。客户可以通过部署负载均衡系统将用户的业务请求均衡的分担到不同的服务器上去，为用户提供更好的服务。健康检查功能是负载均衡系统中核心功能之一。健康检查负责监测服务器能否正常的提供服务，使流量转发到能正常提供服务的服务器上，从而保证负载均衡系统能够提供稳定的业务。

当前健康检查的方式为周期性的主动向服务器进行探测(主动发送探测报文)，检查能否正常提供服务，负载均衡系统根据服务器的健康检查结果决定是否向该服务器进行流量转发。

中国公开号为“CN104394224A”，名称为“一种负载均衡系统”的专利提出了一种健康检查方法，该健康检查在指定主动探测方式、检查周期、服务器地址、正常阈值和异常阈值之后就会进行服务器状态的健康检查。当服务器状态为正常，负载均衡设备上的健康检查会周期性向服务器发送探测报文，检查服务器状态。如果服务器异常的次数超过异常阈值时，则健康检查会认定该服务器状态为异常，此时负载均衡系统就不会向该服务器进行流量转发。当服务器状态为异常，负载均衡设备上的健康检查会周期性向服务器发送探测报文，检查服务器状态。如果服务器正常的次数超过正常阈值时，则健康检查会认定该服务器状态恢复为正常，此时负载均衡系统可以向该服务器转发流量。

相关技术的技术方案的健康检查周期越长，负载均衡系统对于服务器的健康检查延时性越高，转向异常服务器的流量越多，越影响正常业务。健康检查周期越短，健康检查延时性越低，但是负载均衡系统对于服务器的健康检查越频繁，对于服务器的压力越大。在业务申请繁忙时，为了能够尽量减少流量向异常服务器的转发，降低对于正常业务的影响，因此需要健康检查具有更低的延时性，能够更快的检测出异常服务器，因此需要将健康检查周期设置短一些。在这种场景下，原本服务器需要处理大量的业务请求，这样处理无疑会加大服务器的压力。周期性的健康检查无法解决这种互联网业务繁忙时对健康检查具有低延时性和不增加服务器压力的矛盾。

因此如何提升健康检查的策略成了亟待解决的技术问题。

发明内容

本申请实施例的目的在于提供一种负载均衡中健康检查的方法、装置以及系统，通过本申请的实施例可以解决在互联网环境下，当业务繁忙时，周期性主动健康检查无法更及时的检查出异常服务器，导致大量正常业务流量向异常服务器转发，业务受到影响较大的问题，在业务减少时，不会增加服务器的压力，造成资源的浪费。也就是说，本申请的实施例可以解决周期性主动健康检查无法适应互联网流量的问题。

第一方面，本申请的一些实施例提供一种负载均衡中健康检查的方法，所述方法包括：获取设定时间段内稳定因素参量的值，其中，所述稳定因素参量是通过预先统计处于稳定工作状态的服务器的报文特征获得的，所述稳定因素参量的值是通过统计向所述服务器转发的报文或者来自于所述服务器的报文确定的；根据所述稳定因素参量的值与设定阈值确定所述服务器的工作状态；根据所述工作状态确定是否继续向所述服务器转发流量报文。

本申请的一些实施例通过监控预先确定的稳定因素参量对应的具体取值，来确定对应的服务器是否故障，进而可以确定是否能够继续向该服务器提供流量报文，与相关技术需要周期性向被检测服务器主动发送探测报文以获取故障与否的技术方案相比，本申请的实施例通过检测转发的报文即可能够检查出服务器是否异常，不会由于健康检查给正常服务器造成额外的压力。

在一些实施例中，所述稳定因素参量包括：目标报文比值、零窗口占比或者HTTP中设定URI的状态码占比。

本申请的一些实施例提供了多种正常流量下比值相对稳定的稳定因素参量，提升了方案的通用性。

在一些实施例中，所述服务器的传输层采用TCP协议，其中，所述目标报文比值包括：在所述设定时间段内接收的RST报文的数量与接收的FIN报文的数量之间的比值，或者在所述设定时间段内接收的RST报文的数量与接收的SYN报文和ACK报文数量之和之间的比值。

本申请的一些实施例利用TCP网络上的某些种类的报文数量的比值相对稳定的特征，来监控某类报文的数量突然增加比率是否出现严重失衡确定服务器的工作状态，相对于周期性主动健康检查在大流量下严重影响服务器工作的问题，本申请的实施例能够在不增加服务器压力的前提下更及时的探测异常服务器，减少对于业务的影响，保证业务的稳定。

在一些实施例中，在所述根据所述稳定因素参量的值与设定阈值确定所述服务器的工作状态之前，所述方法还包括：通过监控处于稳定状态的所述服务器获取所述设定阈值。

本申请的一些实施例的用户可以通过正常检查中展示的正常比值，配置被动健康检查的设定阈值。配置完毕之后，对于状态为正常的服务器，持续监测目标报文比值是否超过正常值，如果超过则会状态设置为异常，对于状态为异常的服务器，状态恢复进行主动探测，检查服务是否恢复正常。

在一些实施例中，所述通过监控处于稳定状态的网络获取所述设定阈值，还包括：根据平均方差确定所述网络处于稳定状态，其中，所述平均方差为目标报文比值的方差。

本申请的一些实施例通过平均方差来确定网络的稳定状况，进而提升被动健康检查得到的检查结果的准确性。

在本申请的一些实施例中，所述设定阈值包括：目标报文比值阈值、零窗口占比阈值或者HTTP中设定URI的状态码占比阈值。

本申请的一些实施例提供与稳定因素参量的类型分别匹配的阈值类型，扩展方案的通用性。

在一些实施例中，所述稳定因素参量的值包括：当前时刻统计得到的所述设定时间段内的RST报文的数目与FIN报文的数目的第一实际比值，或者所述设定时间段内的RST报文的数目与SYN报文和ACK报文的数目和的第二实际比值；所述通过监控处于稳定状态的所述服务器获取所述设定阈值，包括：通过监控处于稳定状态的TCP网络获取RST报文与FIN报文的第一参考比值，或者通过监控处于稳定状态的所述TCP网络获取RST报文与SYN报文和ACK报文和的第二参考比值；所述根据所述稳定因素参量的值与设定阈值确定所述服务器的工作状态，包括：确认所述第一实际比值大于所述第一参考比值，或者确认所述第二实际比值大于所述第二参考比值，则确定所述服务器处于异常状态；所根据所述工作状态确定是否继续向所述服务器转发流量报文，包括：停止向所述服务器转发报文。

本申请的一些实施例通过比较监控得到的稳定因素参量的值与对应设定阈值的大小来确定是否向相应服务器转发报文。

在一些实施例中，所述停止向所述服务器转发报文之后，所述方法还包括：向所述服务器发送探测报文以确认所述服务器是否恢复正常。

本申请的一些实施例对于处于异常工作状态的服务器采用主动探测的方式来确定其是否恢复正常，可以提升这些服务器的工作效率。

在一些实施例中，在所述获取设定时间段内稳定因素参量的值之前，所述方法还包括：对前一个设定时段内统计的目标报文数目、零窗口数目以及HTTP中设定URI的状态码数目进行清零操作。

为了更准确的反应近期网络状况，本申请实施例的被动健康检查会定时的将各类报文的报文统计重置为零，重新开始计数。

第二方面，本申请的一些实施例提供一种负载均衡中健康检查的装置，所述装置包括：确定因素参量值获取模块，被配置为获取设定时间段内稳定因素参量的值，其中，所述稳定因素参量是通过预先统计处于稳定工作状态的服务器的报文特征获得的，所述稳定因素参量的值是通过统计向所述服务器转发的报文或者来自于所述服务器的报文确定的；工作状态确定模块，被配置为根据所述稳定因素参量的值与设定阈值确定所述服务器的工作状态；决策模块，被配置为根据所述工作状态确定是否继续向所述服务器转发流量报文。

第三方面，本申请的一些实施例提供一种负载均衡中健康检查的系统，所述系统包括：正常检测模块，被配置为通过监控处于稳定状态的服务器获取与稳定因素参量对应的设定阈值；实时检查模块，被配置为获取设定时间段内所述稳定因素参量的值，其中，所述稳定因素参量是通过预先统计处于稳定工作状态的服务器的报文特征获得的；根据所述稳定因素参量的值与所述设定阈值确定所述服务器的工作状态；根据所述工作状态确定是否继续向所述服务器转发流量报文；状态恢复模块，被配置为在确认所述服务器异常时，向所述服务器发送探测报文以确认所述服务器是否恢复正常；定时重置模块，被配置为经过所述设定时间段后对统计的目标报文数目、零窗口数目以及HTTP中设定URI的状态码数目进行清零操作。

第四方面，本申请的一些实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时可实现上述第一方面所述的方法。

第五方面，本申请的一些实施例提供一种电子设备，包括存储器、处理器以及存储在所述存储器上并可在所述处理器上运行的计算机程序，其中，所述处理器执行所述程序时可实现上述第一方面所述的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的集群服务系统的组成框图；

图2为本申请实施例提供的负载均衡中健康检查的方法的流程图；

图3为本申请实施例提供的负载均衡中健康检查的装置的组成框图；

图4为本申请实施例提供的负载均衡中健康检查的系统的组成框图；

图5为本申请实施例提供的电子设备的组成框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

相关技术方案的周期性的健康检查的检查周期为固定值，而互联网流量具有较大的波动性和突发性。因此，理想的技术方案应该在业务请求繁忙时，为了减少健康检查的延时性，健康检查周期需要变小；而在业务请求减少时，不需要减少健康检查的延时性，健康检查周期不需要减少，避免对于服务器造成不必要的压力。显然，周期性的健康检查无法适应互联网流量的特性。可以理解的是，互联网业务请求具有较大的波动性和突发性。在一段时间内，业务请求可能会繁忙。这就要求健康检查具有较高的实时性，在业务请求繁忙时能够及时的检测服务器健康检查状态，减少对于业务的影响。

本申请的实施例通过检测转发的报文即可能够检查出服务器是否异常，不会由于健康检查给正常服务器造成额外的压力。在大流量下，转发报文量多，若服务器异常，则报文比值会快速持续增大很多，若服务器正常，则报文比值维持在一定范围内，因而本申请实施例能够更及时的检查出异常的服务器，对业务影响更小，在小流量下，本申请的实施例通过检测转发报文比值，也能够检查出服务器异常，因此能够适应互联网流量具有波动性的特点。

请参看图1，图1为本申实施例的集群服务系统的组成框图，图1的集群服务系统包括用户端100，作为一个示例，用户端100包括门户网站、搜索网站或者电子商务相关的网站等；图1的集群服务系统还包括负载均衡器200，用于制定负载均衡策略以将来自于用户端的报文发送至能够提供服务的目标服务器；图1的集群服务系统还包括服务器集群300，作为一个示例，服务器集群300包括第一服务器、第二服务器以及第三服务器；其中，负载均衡器200会探测服务器集群300中的服务器的工作状态以将来自于用户端100的报文发送至正常工作的服务器，实现负载均衡。

下面示例性阐述在负载均衡器200上执行的健康检查的方法。

如图2所示，本申请的一些实施例提供一种负载均衡中健康检查的方法，所述方法包括：S201，获取设定时间段内稳定因素参量的值，其中，所述稳定因素参量是通过预先统计处于稳定工作状态的服务器的报文特征获得的，所述稳定因素参量的值是通过统计向所述服务器转发的报文或者来自于所述服务器的报文确定的；S202，根据所述稳定因素参量的值与设定阈值确定所述服务器的工作状态；S203，根据所述工作状态确定是否继续向所述服务器转发流量报文。

需要说明的是，所述稳定因素参量包括：目标报文比值、零窗口占比或者HTTP中设定URI的状态码占比。例如，所述服务器的传输层采用TCP协议，目标报文类型包括RST报文、FIN报文、SYN报文和ACK的报文，对应的目标报文比值包括：在所述设定时间段内接收的RST报文的数量与接收的FIN报文的数量之间的比值，或者在所述设定时间段内接收的RST报文的数量与接收的SYN报文和ACK报文数量之和之间的比值。

为了获取设定阈值，在本申请的一些实施例中，在执行S202之前，所述方法还包括：通过监控处于稳定状态的所述服务器获取所述设定阈值。本申请的一些实施例的用户可以通过正常检查中展示的正常比值，将该正常比值配置为被动健康检查的设定阈值。配置完毕之后，对于状态为正常的服务器持续监测报文比值是否超过正常值，如果超过则会状态设置为异常，对于状态为异常的服务器，状态恢复进行主动探测，检查服务是否恢复正常。

为了提升被动健康检查结果的准确性，在本申请的一些实施例中，所述通过监控处于稳定状态的网络获取所述设定阈值，还包括：根据平均方差确定所述网络处于稳定状态，其中，所述平均方差为目标报文比值的方差。本申请的一些实施例通过平均方差来确定网络的稳定状况，进而提升被动健康检查得到的检查结果的准确性。

可以理解的是，本申请的实施例为各种稳定因素参量类型对应设置相关的设定阈值。具体地，在本申请的一些实施例中，所述设定阈值包括：目标报文比值阈值、零窗口占比阈值或者HTTP中设定URI的状态码占比阈值。需要说明的是，当S201获取的稳定因素参量的值为目标报文比值时，则S202根据目标报文比值和目标报文比值阈值进行比较确定相应服务器的工作状态；当S201获取的稳定因素参量的值是零窗口占比时，则S202根据零窗口占比和零窗口占比阈值进行比较确定相应服务器的工作状态；当S201获取的稳定因素参量的值是HTTP中设定URI的状态码占比时，则S202根据HTTP中设定URI的状态码占比和HTTP中设定URI的状态码占比阈值进行比较确定相应服务器的工作状态。

下面以目标报文比值作为稳定因素参量和TCP协议为例，示例性阐述负载均衡中健康检查的方法的步骤。

作为本申请的一个示例，负载均衡方法包括的通过监控处于稳定状态的所述服务器获取所述设定阈值的步骤包括：通过监控处于稳定状态的TCP网络获取RST报文与FIN报文的第一参考比值，或者通过监控处于稳定状态的所述TCP网络获取RST报文与SYN报文和ACK报文和的第二参考比值；S201获取稳定因素参量的值包括：获取当前时刻统计得到的所述设定时间段内的RST报文的数目与FIN报文的数目的第一实际比值，或者所述设定时间段内的RST报文的数目与SYN报文和ACK报文的数目和的第二实际比值；S202包括：确认所述第一实际比值大于所述第一参考比值，或者确认所述第二实际比值大于所述第二参考比值，则确定所述服务器处于异常状态；S203包括：停止向所述服务器转发报文。本申请的一些实施例通过比较监控得到的稳定因素参量的值与对应设定阈值的大小来确定是否向相应服务器转发报文。

为了保证服务器的工作效率，在本申请的一些实施例中，停止向故障服务器转发报文之后，所述负载均衡的方法还包括：向所述服务器发送探测报文以确认所述服务器是否恢复正常。

可以理解的是，在本申请的一些实施例中，在所述获取设定时间段内稳定因素参量的值之前，所述负载均衡的方法还包括：对前一个设定时段内统计的目标报文数目、零窗口数目以及HTTP中设定URI的状态码数目进行清零操作。

请参考图3，图3示出了本申请实施例提供的负载均衡中健康检查的装置，应理解，该装置与上述图2方法实施例对应，能够执行上述方法实施例涉及的各个步骤，该装置的具体功能可以参见上文中的描述，为避免重复，此处适当省略详细描述。装置包括至少一个能以软件或固件的形式存储于存储器中或固化在装置的操作系统中的软件功能模块，该负载均衡装置包括：确定因素参量值获取模块301，被配置为获取设定时间段内稳定因素参量的值，其中，所述稳定因素参量是通过预先统计处于稳定工作状态的服务器的报文特征获得的，所述稳定因素参量的值是通过统计向所述服务器转发的报文或者来自于所述服务器的报文确定的；工作状态确定模块302，被配置为根据所述稳定因素参量的值与设定阈值确定所述服务器的工作状态；决策模块303，被配置为根据所述工作状态确定是否继续向所述服务器转发流量报文。

在一些实施例中，负载均衡装置还包括：正常检测模块(图3未示出)，被配置为通过监控处于稳定状态的服务器获取与稳定因素参量对应的设定阈值。

在一些实施例中，负载均衡装置还包括：状态恢复模块(图3未示出)，被配置为在确认所述服务器异常时，向所述服务器发送探测报文以确认所述服务器是否恢复正常。

在一些实施例中，负载均衡装置还包括：定时重置模块(图3未示出)，被配置为经过所述设定时间段后对统计的目标报文数目、零窗口数目以及HTTP中设定URI的状态码数目进行清零操作。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置的具体工作过程，可以参考前述负载均衡方法中的对应过程，在此不再过多赘述。

如图4所示，本申请的一些实施例提供一种负载均衡中健康检查的系统(对应于图1的负载均衡器)，所述系统包括：正常检测模块401，被配置为通过监控处于稳定状态的服务器获取与稳定因素参量对应的设定阈值；实时检查模块402，被配置为获取设定时间段内所述稳定因素参量的值，其中，所述稳定因素参量是通过预先统计处于稳定工作状态的服务器的报文特征获得的；根据所述稳定因素参量的值与所述设定阈值确定所述服务器的工作状态；根据所述工作状态确定是否继续向所述服务器转发流量报文；状态恢复模块403，被配置为在确认所述服务器异常时，向所述服务器发送探测报文以确认所述服务器是否恢复正常；定时重置模块404，被配置为经过所述设定时间段后对统计的目标报文数目、零窗口数目以及HTTP中设定URI的状态码数目进行清零操作。

下面分别阐述相应模块的功能。

本申请一些实施例的技术方案的原理为：在一般情况下，互联网上的各类目标报文数量的比值是相对稳定的，而当某类报文的数量突然增加比率出现严重失衡时，就表示网络出现了异常情况。例如，在TCP网络环境下，存在RST(即TCP首部中的复位标志ReSeT)、FIN(即TCP首部中的结束标志FINish)、SYN(即TCP首部中的同步序号标志SYNchronous，)和ACK(即TCP首部中的确认标志ACKnowledgment)等报文。在TCP异常时，通过发送RST报文异常关闭连接。在一般情况下，RST报文和FIN报文的比值，或者RST报文与“SYN+ACK”报文的比值是稳定的。因此，RST报文和FIN报文的比值，或者RST报文与“SYN+ACK”报文的比值远超正常值时，则表示对应服务器的网络状态出现异常。

本申请一些实施例的负载均衡中健康检查的系统包括：实时检查模块、定时重置模块、状态恢复模块和正常检测模块。用户可以通过正常检查模块中展示的正常比值(对应于设定阈值)，配置被动健康检查各类报文正常比值。配置完毕之后，对于状态为正常的服务器，定时重置模块会定时的重置统计数据，实时检查模块会在定时重置模块重置统计数据后持续监测报文比值是否超过正常值，如果超过则会状态设置为异常，对于状态为异常的服务器，状态恢复进行主动探测，检查服务是否恢复正常。

例如，正常检测模块在负载均衡系统中用于监控网络状况，给出客户网络状态上RST报文和FIN报文的正常比值范围，或者RST报文与SYN报文和ACK报文的和的正常比值范围和两个正常比值的平均方差。在平均方差不大时(一般小于10)，表示当前网络状况稳定，用户可以根据被动健康检查的建议，设置被动健康检查的监控周期以及被动健康检查的RST报文和FIN报文的正常比值取值(对应于上述第一参考比值)，或者RST报文与SYN报文和ACK报文的和的正常比值取值(对应于上述第二参考比值)。在平均方差较大时，表示此时网络状况可能有问题，被动健康检查会建议用户确认网络正常后再进行探测。

实时检查模块用于实时统计稳定因素参量的值，例如，被动健康检查持续监控负载均衡系统中向服务器转发流量的RST报文和FIN报文、SYN报文和ACK报文，并获取上述第一实际比值或者第二实际比值。若在监控周期内实际比值超过参考比值，则判定对应服务器为异常状态，不再向该服务器转发流量。

为了更准确的反应近期网络状况，定时重置模块查会定时的将各类报文的报文统计重置为零，重新开始计数。

为了及时探测故障服务器是否恢复正常工作状态，被动健康检查会采用状态恢复模块向状态为异常的服务器主动进行探测服务是否恢复正常，以便能够继续提供服务。

需要说明的是，本申请的实施例提供的负载均衡中健康检查的系统除了监控RST报文和FIN报文的比值、RST报文与SYN报文与ACK报文和的比值外，还可以监控零窗口占比、HTTP特定URI的状态码占比等正常流量下比值相对稳定的因素，可以达到类似的效果。

本申请的一些实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时可实现上述所述的负载均衡方法。

如图5所示，本申请的一些实施例提供一种电子设备500，包括存储器510、处理器520以及存储在所述存储器510上并可在所述处理器520上运行的计算机程序，其中，所述处理器520通过总线530从内存读取程序并执行所述程序时可实现上述所述的负载均衡方法。

处理器520可以处理数字信号，可以包括各种计算结构。例如复杂指令集计算机结构、结构精简指令集计算机结构或者一种实行多种指令集组合的结构。在一些示例中，处理器520可以是微处理器。

存储器510可以用于存储由处理器520执行的指令或指令执行过程中相关的数据。这些指令和/或数据可以包括代码，用于实现本申请实施例描述的一个或多个模块的一些功能或者全部功能。本公开实施例的处理器520可以用于执行存储器510中的指令以实现图2中所示的方法。存储器510包括动态随机存取存储器、静态随机存取存储器、闪存、光存储器或其它本领域技术人员所熟知的存储器。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

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

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。