本申请涉及云服务部署技术领域，特别涉及一种云环境下服务的部署方法、系统、装置及计算机可读存储介质。
背景技术：
随着大数据、云计算概念的兴起，越来越多的企业或个人用户开始使用云服务，按照性能的不同，大体可划分为共有云和私有云两种，其中共有云的使用成本较低，但由于多个租户共用缺乏各租户数据间的物理隔离，响应也相对较慢；各私有云则为租户私有，可控性和安全性较高，但相对成本较高，因此逐渐出现了同时兼具公有云和私有云两者优势的解决方案。
结合后的方案将云划分为共享区和专享区，并有针对性的在不同区域设置不同的业务，例如，将互联网外部应用部署在共享区，而将企业内容应用部署在专享区；将弹性和潮汐应用部署在共享区，而将固定业务部署在专享区。因此为适应各式场景，云服务提供商需要能够灵活的设置IaaS服务和PaaS服务在不同的区域。
现有的解决方案可参见图1，上层由控制系统和服务集群构成的PaaS服务系统，并使用单独的物理资源集群部署，以同时为下层分属不同区域的租户提供统一的PaaS服务，而IaaS服务则根据需求可以部署在共享区或专享区。但该解决方案仍存在一些问题：由于所有租户共用一套PaaS服务，因此只能采用安全性能较差的隔离方式；当唯一的PaaS服务出现异常时所有的租户都会受到影响；无法实现灵活部署PaaS服务在目标区域的目的，且由于两种服务分别部署在不同的物理资源上，会存在较大的业务访问延迟。由于现有解决方案存在上述问题，其实际使用效果有待提升。
因此，如何克服现有的服务部署机制存在的各项技术缺陷，提供一种能够灵活部署两种服务在同一目标区域，业务访问延迟更低、安全性更高、异常出现时影响更小的服务部署机制是本领域技术人员亟待解决的问题。
技术实现要素：
本申请的目的是提供一种云环境下服务的部署方法，从租户的服务创建请求中获取待创建服务的相关信息，并在剩余资源量满足创建所需资源量的基础上，同时将包括Paas服务和IaaS服务在内的两层服务都创建在目标创建资源区当中，为每位租户都提供了独享的PaaS服务和IaaS服务，由于每位租户都拥有自己的PaaS服务，且与IaaS服务使用同一物理资源，因此可显著降低两者之间的业务访问延迟，同时此种方式下各租户间隔离会更加彻底，安全性能更佳。
本申请的另一目的在于提供了一种云环境下服务的部署系统、装置及计算机可读存储介质。
为实现上述目的，本申请提供一种云环境下服务的部署方法，该方法包括：
当接收到租户的服务创建请求时，根据所述服务创建请求确定待创建服务的目标创建资源区和创建所需资源量，并查询所述租户在所述目标创建资源区中的剩余资源量；其中，所述待创建服务包括PaaS服务和IaaS服务；
判断所述剩余资源量是否大于所述创建所需资源量；
若所述剩余资源量大于所述创建所需资源量，则在所述目标创建资源区中创建所述待创建服务，并通过第一预设路径返回服务创建成功信号；
若所述剩余资源量不大于所述创建所需资源量，则通过第二预设路径返回剩余资源量小于创建所需资源量的失败信号。
可选的，根据所述服务创建请求确定待创建服务的目标创建资源区和创建所需资源量，并查询所述租户在所述目标创建资源区中的剩余资源量，包括：
提取所述服务创建请求中包含的待创建服务特征信息和租户身份信息；
提取所述待创建服务特征信息中包含的目标创建资源区信息和创建所需资源量信息；
根据所述目标创建资源区信息和所述创建所需资源量信息确定对应的目标创建资源区和创建所需资源量；
根据所述租户身份信息和所述目标创建资源区信息确定所述租户在所述目标创建资源区中的剩余资源量。
可选的，该部署方法还包括：
当所述租户被隶属的二级服务商管理、且所述剩余资源量小于所述创建所需资源量时，向隶属的二级服务商发送第一扩容请求；
当所述租户隶属的二级服务商接收到并同意所述第一扩容请求时，增加所述租户在所述目标创建资源区中的剩余资源量。
可选的，该部署方法还包括：
当所述租户隶属的二级服务商所拥有的未分配资源量小于阈值时，向所述二级服务商隶属的一级云服务提供商发送第二扩容请求；
当所述二级服务商隶属的一级云服务提供商接收到并同意所述第二扩容请求时，增加所述二级服务商拥有的未分配资源量。
可选的，在所述目标创建资源区中创建所述待创建服务之前，还包括：
判断所述目标创建资源区是否满足创建所述待创建服务的限制条件；
当不满足所述限制条件时，通过第三预设路径返回不满足创建限制条件的失败信号。
为实现上述目的，本申请还提供了一种云环境下服务的部署系统，该部署系统包括：
信息确定及查询单元，用于当接收到租户的服务创建请求时，根据所述服务创建请求确定待创建服务的目标创建资源区和创建所需资源量，并查询所述租户在所述目标创建资源区中的剩余资源量；其中，所述待创建服务包括PaaS服务和IaaS服务；
容量判断单元，用于判断所述剩余资源量是否大于所述创建所需资源量；
服务创建及成功反馈单元，用于当所述剩余资源量大于所述创建所需资源量时，在所述目标创建资源区中创建所述待创建服务，并通过第一预设路径返回服务创建成功信号；
一型失败信号反馈单元，用于当所述剩余资源量不大于所述创建所需资源量时，通过第二预设路径返回剩余资源量小于创建所需资源量的失败信号。
可选的，所述信息确定及查询单元包括：
第一信息提取子单元，用于提取所述服务创建请求中包含的待创建服务特征信息和租户身份信息；
第二信息提取子单元，用于提取所述待创建服务特征信息中包含的目标创建资源区信息和创建所需资源量信息；
信息确定子单元，用于根据所述目标创建资源区信息和所述创建所需资源量信息确定对应的目标创建资源区和创建所需资源量；
查询子单元，用于根据所述租户身份信息和所述目标创建资源区信息确定所述租户在所述目标创建资源区中的剩余资源量。
可选的，该部署系统还包括：
第一扩容请求发送单元，用于当所述租户被隶属的二级服务商管理、且所述剩余资源量小于所述创建所需资源量时，向隶属的二级服务商发送第一扩容请求；
租户剩余资源量增加单元，用于当所述租户隶属的二级服务商接收到并同意所述第一扩容请求时，增加所述租户在所述目标创建资源区中拥有的剩余资源量。
可选的，该部署系统还包括：
第二扩容请求发送单元，用于当所述租户隶属的二级服务商所拥有的未分配资源量小于阈值时，向所述二级服务商隶属的一级云服务提供商发送第二扩容请求；
二级服务商未分配资源量增加单元，用于当所述二级服务商隶属的一级云服务提供商接收到并同意所述第二扩容请求时，增加所述二级服务商拥有的未分配资源量。
可选的，该部署系统还包括：
目标创建资源区状态判断单元，用于判断所述目标创建资源区是否满足创建所述待创建服务的限制条件；
二型失败信号反馈单元，用于当不满足所述限制条件时，按第三预设路径返回不满足创建限制条件的失败信号。
为实现上述目的，本申请还提供了一种云环境下服务的部署装置，该部署装置包括：
存储器，用于存储计算机程序；
处理器，用于执行所述计算机程序时实现如上述内容所描述的部署方法的步骤。
为实现上述目的，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述内容所描述的部署方法的步骤。
显然，本申请所提供的一种云环境下服务的部署方法，从租户的服务创建请求中获取待创建服务的相关信息，并在剩余资源量满足创建所需资源量的基础上，同时将包括Paas服务和IaaS服务在内的两层服务都创建在目标创建资源区当中，为每位租户都提供了独享的PaaS服务和IaaS服务，由于每位租户都拥有自己的PaaS服务，且与IaaS服务使用同一物理资源，因此可显著降低两者之间的业务访问延迟，同时此种方式下各租户间隔离会更加彻底，安全性能更佳。本申请同时还提供了一种云环境下服务的部署系统、装置及计算机可读存储介质，具有上述有益效果，在此不再赘述。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为现有部署PaaS服务和IaaS服务方式的示意图；
图2为本申请实施例所提供的一种云环境下服务的部署方法的流程图；
图3为本申请实施例所提供的云环境下服务的部署方法中一种从服务创建请求中提取相关信息的方法的流程图；
图4为本申请实施例所提供的云环境下服务的部署方法中一种当租户的剩余资源量不足以创建待创建服务时解决方法的流程图；
图5为本申请实施例所提供的一种云环境下服务的部署系统的结构框图；
图6为本申请实施例所提供的一种当IaaS服务部署到专享区或共享区时具体操作步骤的时序图；
图7为本申请实施例所提供的一种当PaaS服务部署到专享区或共享区时具体操作步骤的时序图；
图8为本申请实施例所提供的一种部署PaaS服务和IaaS服务的示意图。
具体实施方式
本申请的核心是提供一种云环境下服务的部署方法、系统、装置及计算机可读存储介质，从租户的服务创建请求中获取待创建服务的相关信息，并在剩余资源量满足创建所需资源量的基础上，同时将包括Paas服务和IaaS服务在内的两层服务都创建在目标创建资源区当中，为每位租户都提供了独享的PaaS服务和IaaS服务，由于每位租户都拥有自己的PaaS服务，且与IaaS服务使用同一物理资源，因此可显著降低两者之间的业务访问延迟，同时此种方式下各租户间隔离会更加彻底，安全性能更佳。
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
以下结合图2，图2为本申请实施例所提供的一种云环境下服务的部署方法的流程图。
其具体包括以下步骤：
S101：当接收到租户的服务创建请求时，根据服务创建请求确定待创建服务的目标创建资源区和创建所需资源量，并查询租户在目标创建资源区中的剩余资源量；
本步骤旨在确定租户想要创建哪些服务以及创建这些服务的目标创建资源区和创建所需资源量，并根据该租户在目标创建资源区中的剩余资源量判断是否满足该创建所需资源量。通常情况下，能够从租户向控制台发送的服务创建请求中得到这些信息，当然除创建服务所必要的信息外还可能包含其它信息，可以视实际情况选择的提取出来和使用，此处并不做具体限定。
需要说明的是，本申请所提及的待创建服务包括PaaS服务和IaaS服务，IaaS服务(Infrastructure as a Service，基础设施即服务)，是指消费者通过Internet可以从完善的计算机基础设施获得的服务，这类服务称为基础设施即服务，基于Internet的服务(如存储和数据库)是IaaS的一部分。Internet上其他类型的服务还包括PaaS服务(Platform as a Service，平台即服务)SaaS服务(Software as a Service，软件即服务)。其中，PaaS提供了用户可以访问的完整或部分的应用程序开发，SaaS则提供了完整的可直接使用的应用程序，比如通过Internet管理企业资源。
简单来说，PaaS服务在云架构中位于中间层，其上层是SaaS服务，其下层是IaaS服务。具体来说，仅提供IaaS服务就相当于提供场外服务器、存储和网络硬件等，需要使用者自己去做环境配备、应用程序的开发及应用等工作；提供PaaS服务(建立在IaaS服务基础上)就相当于在提供基础设施的基础上，还能够提供应用程序的开发环境及部分应用，还需要用户自行开发部分或全部的应用程序；提供SaaS服务(建立在PaaS服务基础上)则相当于直接为用户提供了完整且可直接使用的应用程序，只需要用户登录流浪器即可。
本申请的目的在于，区别于现有技术，需要打破PaaS服务固定设定的缺陷，使得PaaS服务与配套的底层IaaS服务一并可以灵活设置，以解决高业务访问延迟、安全性较差的问题。
S102：判断剩余资源量是否大于创建所需资源量；
在S101的基础上，本步骤旨在判断该租户在目标创建资源区中的剩余资源量是否满足(大于)待创建服务的创建所需资源量。通常情况下剩余资源量是需要大于该创建所需资源量的，最小也需要与创建所需资源量等同，出于一些安全、冗余方面的考虑，还可以设定剩余资源量具体需要大于该创建所需资源量的大小，比如，设定只有该剩余资源量是该创建所需资源量的1.3倍时才认为满足创建条件等等，可根据实际情况灵活设定，此处并不做具体限定。
S103：在目标创建资源区中创建待创建服务，并通过第一预设路径返回服务创建成功信号；
本步骤建立在S102的判断结果为该剩余资源量大于创建所需资源量的基础上，因此满足在该目标资源区内创建该待创建服务的资源量要求，即可以在目标创建资源区内创建该待创建服务，并在创建完成后按第一预设路径返回服务创建成功信号，以用于告知租户服务已创建成功。
进一步的，即使经过S102的判断得到剩余资源量大于创建所需资源量的结果，仍有可能出现由于目标资源区存在的一些限制条件，导致无法创建待创建服务，因此还可以对是否满足限制条件进行判断，例如：
判断目标创建资源区是否满足创建待创建服务的限制条件；当不满足限制条件时，按第三预设路径返回不满足创建限制条件的失败信号。
S104：通过第二预设路径返回剩余资源量小于创建所需资源量的失败信号。
本步骤建立在S102的判断结果为该剩余资源量小于创建所需资源量的基础上，因此不满足在该目标资源区内创建该待创建服务的资源量要求，即需要通过第二预设路径返回剩余资源量小于创建所需资源量的失败信号，以用于告知租户服务由于剩余资源量较少导致创建失败。
进一步的，当由于租户在目标创建资源区内的剩余资源量较少因此不满足创建待创建服务所需资源量的要求时，还可以在该租户隶属于某二级服务商的基础上，向隶属的二级服务商发送扩容请求，以增加自己在目标创建资源区内的剩余资源量，进而完成待创建服务的创建目的。
更进一步的，还可以在当某二级服务商自身拥有的从一级云服务提供商划分出的资源量较少时，再由该二级服务商向隶属的一级云服务提供商请求扩容等操作，目的很明显，旨在通过一层层请求的方式满足租户的各种实际需求。
上述各步骤中出现的第一预设路径、第二预设路径以及第三预设路径旨在用于区别反馈的不同作用的信号，实际使用中可以为存在区别的三种路径，也可以是采用一条路径却发送不同信息的方式实现，此处并不做具体限定。
基于上述技术方案，本申请实施例提供的一种云环境下服务的部署方法，从租户的服务创建请求中获取待创建服务的相关信息，并在剩余资源量满足创建所需资源量的基础上，同时将包括Paas服务和IaaS服务在内的两层服务都创建在目标创建资源区当中，为每位租户都提供了独享的PaaS服务和IaaS服务，由于每位租户都拥有自己的PaaS服务，且与IaaS服务使用同一物理资源，因此可显著降低两者之间的业务访问延迟，同时此种方式下各租户间隔离会更加彻底，安全性能更佳。
以下结合图3，图3为本申请实施例所提供的云环境下服务的部署方法中一种从服务创建请求中提取相关信息的方法的流程图。
本实施例旨在提供一种从服务创建请求中提取相关信息的方法，具体包括以下步骤：
S201：提取服务创建请求中包含的待创建服务特征信息和租户身份信息；
S202：提取待创建服务特征信息中包含的目标创建资源区信息和创建所需资源量信息；
S203：根据目标创建资源区信息和创建所需资源量信息确定对应的目标创建资源区和创建所需资源量；
S204：根据租户身份信息和目标创建资源区信息确定租户在目标创建资源区中的剩余资源量。
当然，本实施例只是给出一种作为参考的实现步骤，可根据实际情况中硬件的不同、请求中包含信息的不同以及存在的特殊要求进行灵活改变，只要能够实现得到相关信息的目的即可。
以下结合图4，图4为本申请实施例所提供的云环境下服务的部署方法中一种当租户的剩余资源量不足以创建待创建服务时的解决方法的流程图。
S301：当租户被隶属的二级服务商管理、且剩余资源量小于创建所需资源量时，向隶属的二级服务商发送第一扩容请求；
S302：当租户隶属的二级服务商接收到并同意第一扩容请求时，增加租户在目标创建资源区中的剩余资源量。
本实施例给出了一种向隶属的二级服务商发送扩容请求的具体步骤，在此基础上，还可以在满足相关条件下，提供一种向一级云服务提供商请求扩容的具体步骤：
当租户隶属的二级服务商所拥有的未分配资源量小于阈值时，向二级服务商隶属的一级云服务提供商发送第二扩容请求；当二级服务商隶属的一级云服务提供商接收到并同意第二扩容请求时，增加二级服务商拥有的未分配资源量。
基于上述技术方案，本申请实施例提供的一种云环境下服务的部署方法，从租户的服务创建请求中获取待创建服务的相关信息，并在剩余资源量满足创建所需资源量的基础上，同时将包括Paas服务和IaaS服务在内的两层服务都创建在目标创建资源区当中，为每位租户都提供了独享的PaaS服务和IaaS服务，由于每位租户都拥有自己的PaaS服务，且与IaaS服务使用同一物理资源，因此可显著降低两者之间的业务访问延迟，同时此种方式下各租户间隔离会更加彻底，安全性能更佳。
因为情况复杂，无法一一列举进行阐述，本领域技术人员应能意识到根据本申请提供的基本方法原理结合实际情况可以存在很多的例子，在不付出足够的创造性劳动下，应均在本申请的保护范围内。
下面请参见图5，图5为本申请实施例所提供的一种云环境下服务的部署系统的结构框图。
该部署系统可以包括：
信息确定及查询单元100，用于当接收到租户的服务创建请求时，根据服务创建请求确定待创建服务的目标创建资源区和创建所需资源量，并查询租户在目标创建资源区中的剩余资源量；其中，待创建服务包括PaaS服务和IaaS服务；
容量判断单元200，用于判断剩余资源量是否大于创建所需资源量；
服务创建及成功反馈单元300，用于当剩余资源量大于创建所需资源量时，在目标创建资源区中创建待创建服务，并通过第一预设路径返回服务创建成功信号；
一型失败信号反馈单元400，用于当剩余资源量不大于创建所需资源量时，通过第二预设路径返回剩余资源量小于创建所需资源量的失败信号。
其中，信息确定及查询单元100包括：
第一信息提取子单元，用于提取服务创建请求中包含的待创建服务特征信息和租户身份信息；
第二信息提取子单元，用于提取待创建服务特征信息中包含的目标创建资源区信息和创建所需资源量信息；
信息确定子单元，用于根据目标创建资源区信息和创建所需资源量信息确定对应的目标创建资源区和创建所需资源量；
查询子单元，用于根据租户身份信息和目标创建资源区信息确定租户在目标创建资源区中的剩余资源量。
进一步的，该部署系统还可以包括：
第一扩容请求发送单元，用于当租户被隶属的二级服务商管理、且剩余资源量小于创建所需资源量时，向隶属的二级服务商发送第一扩容请求；
租户剩余资源量增加单元，用于当租户隶属的二级服务商接收到并同意第一扩容请求时，增加租户在目标创建资源区中拥有的剩余资源量；
第二扩容请求发送单元，用于当租户隶属的二级服务商所拥有的未分配资源量小于阈值时，向二级服务商隶属的一级云服务提供商发送第二扩容请求；
二级服务商未分配资源量增加单元，用于当二级服务商隶属的一级云服务提供商接收到并同意第二扩容请求时，增加二级服务商拥有的未分配资源量。
更进一步的，该部署系统还可以包括：
目标创建资源区状态判断单元，用于判断目标创建资源区是否满足创建待创建服务的限制条件；
二型失败信号反馈单元，用于当不满足限制条件时，按第三预设路径返回不满足创建限制条件的失败信号。
在此，给出一种具体如何在目标创建资源区内创建PaaS服务和IaaS服务的操作步骤，可参见如图6和图7所示的时序图：
1、当IaaS服务部署到专享区或共享区时(如图6所示)：
租户控制台通过RESTful API(符合REST架构设计的API，而REST是所有Web应用都应该遵守的架构设计指导原则，API则是Application Programming Interface，应用程序编程接口)向认证系统获取认证信息，返回对应的认证信息，并调用API创建服务。控制系统API收到服务配置请求后，通知控制系统数据库，并初始化新建实例的数据库记录；控制系统数据库收到请求后，写入服务配置信息到数据库，包含索引ID(id)、租户ID(tenant_id)、资源区(region)(专享区、共享区)、实例ID(instance_id)、运行状态(status)；控制系统调度进程侦听消息队列，获取控制系统API请求，通过调度算法计算符合实例创建需要的资源；符合要求，更新数据库中实例对应的物理主机信息；控制系统调度向实例管理系统发送对应的创建实例请求的消息；实例管理系统收到消息后，获取服务实例镜像信息(URL)、获得实例网络信息、获取存储信息，调用配置的虚拟化驱动来创建实例，服务实例返回启动消息；服务实例创建完成后，更新服务状态。
2、当PaaS服务部署到专享区或共享区时(如图6所示)：
租户控制平台通过RESTful API向认证系统获取认证信息，返回对应的认证信息；服务控制系统收到服务配置请求后，调用API创建服务；服务控制系统在数据库中写入服务配置信息，包含索引ID(id)、租户ID(tenant_id)、资源区(region)(专享区、共享区)、实例ID(instance_id)、运行状态(status)、配置级别(level)；控制系统API收到服务配置请求后，通知控制系统数据库，并初始化新建实例的数据库记录；控制系统调度进程侦听消息队列，获取控制系统API请求，通过调度算法计算符合实例创建需要的资源；符合要求，更新数据库中实例对应的物理主机信息；控制系统调度向实例管理系统发送对应的创建实例请求的消息；实例管理系统收到消息后，获取服务实例镜像信息(URL)、获得实例网络信息、获取存储信息，调用配置的虚拟化驱动来创建实例，服务实例返回启动消息；服务Agent向服务控制系统发送获取服务信息(RPC)，并返回服务信息(RPC)后保存；服务Agent根据监控列表信息向服务实例定时监控；服务Agent根据获取的服务信息下方配置给服务实例，并返回处理结果；服务Agent向服务控制系统更新服务为配置完成，服务控制系统向控制台返回配置完成。
图中出现的RPC是指Remote Procedure Call，远程方法调用，是一种用来实现跨进程(或者跨机器)的通信机制。项目内部服务之间则通过RPC请求的方式进行通信。客户端发起RPC请求，服务器端接收RPC请求调用本地的程序执行，并将执行结果返回客户端。
经过如上的服务创建操作，可得到如图8所示的本申请实施例所提供的一种部署PaaS服务和IaaS服务的示意图。
基于上述实施例，本申请还提供了一种云环境下服务的部署装置，该部署装置可以包括存储器和处理器，其中，该存储器中存有计算机程序，该处理器调用该存储器中的计算机程序时，可以实现上述实施例所提供的步骤。当然，该部署装置还可以包括各种必要的网络接口、电源以及其它零部件等。
本申请还提供了一种计算机可读存储介质，其上存有计算机程序，该计算机程序被执行终端或处理器执行时可以实现上述实施例所提供的步骤。该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。
还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。