一种面向可维护性的微服务粒度评估方法及工具与流程

1.本发明属于软件开发技术领域，具体设计一种面向可维护性的微服务粒度评估方法及工具。


背景技术：

2.随着互联网技术的迅速发展以及市场需求的复杂化，软件架构朝着灵活变化、快速迭代的方向演进。传统的单体架构将所有的功能集中在一个独立的单元中进行开发和部署，导致开发效率低，灵活性差，无法满足快速迭代的需求。微服务架构将一个独立的应用程序拆分成多个协同工作的小而自治的微服务，每个微服务通常只完成某个特定的功能，能够由不同的技术栈进行单独开发和部署，以满足业务流程个性化需求，相较于单体架构更具扩展性和灵活性。
3.微服务粒度决定了微服务的规模和微服务公开的功能范围，影响着微服务系统的性能、可维护性、存储以及计算资源的使用和消耗。合适的粒度对于微服务系统至关重要。微服务粒度划分贯穿于软件系统的整个生命周期，在开发和演进过程中对微服务粒度进行全面的评估和追踪，有助于开发者更好地维护微服务系统。
4.微服务粒度评估应重点关注粒度划分在整个软件生命周期对软件质量属性的影响。微服务粒度划分的好坏直接影响着微服务系统的可维护性的高低。而可维护性作为重要的软件质量属性之一，对软件商业价值有着重要影响。一方面，微服务粒度过大，可能使得单个微服务维护成本变高。另一方面，微服务粒度过小，可能使得微服务之间的通信成本变高，从而使整个系统的可维护性降低。因此，站在系统可维护性角度来评估微服务粒度具有实际意义。
5.现有的微服务粒度评估方法仍存在许多不足。一方面，大多数方法仅关注了系统设计时的结构数据以及系统实际运行时的表现，而没有关注系统迭代时产生的演进数据，未能从整个软件生命周期的角度对微服务粒度设计及其所产生影响进行持续追踪与评估。另一方面，这些方法大多仅突出显示应在粒度评估中考虑的指标，没有给出聚合型度量，无法直观地评估当前微服务粒度质量。


技术实现要素：

6.本发明的目的在于：针对现有方法的不足，本发明的目的是提供一种面向可维护性的微服务粒度评估方法及工具，能够站在可维护性角度从多个维度全面地评估微服务粒度，并提供聚合性度量来直观反映微服务粒度在系统演进中的变化，便于开发者根据评估结果进行微服务粒度的调整。
7.为实现上述目的，本发明的技术方案是：提供一种面向可维护性的微服务粒度评估方法，包括以下步骤：
8.s1：基于用户提供的仓库地址以及项目版本信息，自动化地获取每个项目版本的源代码和历史提交信息，并对源代码进行自动编译，生成对应的class文件；
9.s2：基于步骤s1中项目每个版本的class文件，提取出评估所需项目各个版本的微服务接口数据和微服务间依赖数据；
10.s3：基于步骤s1获取的项目历史提交信息和步骤s2中所提取的各类评估所需输入数据，按照不同的规则对各类数据进行清洗。
11.s4：若所要评估的项目不是基于springcloud框架开发的微服务项目，用户可直接将处理好的项目数据进行导入。
12.s5：基于步骤s3所清洗得到的数据或基于步骤s4所导入的处理好的项目数据，计算9个与可维护性相关的微服务粒度评估指标，根据权重计算粒度评估最终得分。
13.优选地，进行步骤s1前对微服务项目中的源代码文件进行预处理工作，记录项目编号projectno、项目名称projectname、每个微服务项目的版本编号versionno和版本标识versionname，生成版本标识列表commitlist，用于按版本获取源代码进行数据提取。
14.优选地，在进行步骤s1时需要对版本标识进行合法性检查，自动切换并拉取版本代码，使用maven命令对代码进行编译，生成class文件存储在目标路径中。同时记录下不合法的版本标识和编译错误的信息，以便人工排查。
15.优选地，在进行步骤s1中的提取历史提交信息时，需要使用git命令git log
–
pretty＝format:“％h#％an#％ad#％s
”–
name-only获取所有历史提交信息。
16.微服务项目历史提交信息包括：所属项目编号projectno、所属版本编号versionno、提交标识符commitid、提交者committer、提交时间committime、提交描述commitcontent、提交文件名称commitfile。
17.优选地，进行步骤s2中提取评估所需项目各个版本的微服务接口数据时，需要扫描配置文件获取当前微服务名称，同时扫描出每个微服务中所有含有controller相关注解的文件，从文件中找到所有存在restful相关注解的方法，存储对应微服务的方法名称、参数信息和返回值。
18.生成的微服务接口数据具体包括：所属项目编号projectno、所属版本编号versionno、微服务名称service、接口详细信息interface、参数parameter、返回值returnvalue，其中接口详细信息interface包含完整的包名称、接口名称和参数。
19.优选地，在进行步骤s2中提取评估所需项目各个版本的微服务间依赖数据时，需要扫描配置文件获取当前微服务currentservice为起点微服务，同时扫描出所有含有@feignclient的文件，读取@feignclient注解中value或name中不为空的值为终点微服务targetservice，如果起点微服务中有方法存在restful注解并被其他文件调用，则生成一条currentservice-》targetservice的依赖关系。
20.生成的微服务间依赖数据具体包括：所属项目编号projectno、所属版本编号versionno、调用关系边的起点微服务名称invokingservice、调用关系边起点微服务的调用方法信息invokingmethod、调用关系边的终点微服务名称invokedservice、调用关系边的终点微服务被调用的方法信息invokedmethod，其中方法信息包含完整的包名称、接口名称和参数。
21.优选地，进行步骤s3清洗评估输入数据时，需要检查各类评估输入数据的有效性。对于接口数据来说，需要过滤非逻辑微服务的相关数据，从而保证模型评估的是真正逻辑微服务的粒度设计。对于依赖数据来说，同样需要过滤调用关系中主动调用与被动调用的
微服务是非逻辑微服务的依赖数据。除此之外，还需要过滤微服务调用自身的不规范的依赖数据。对于历史提交数据来说，需要过滤非代码文件的提交数据。
22.优选地，若所要评估的项目不是基于springcloud框架开发的微服务项目，用户可进行步骤s4直接将处理好的项目数据进行导入。
23.优选地，进行步骤s5中的微服务粒度评估时，所使用的所有微服务粒度评估指标如下：
24.(1)消息级别内聚(cohesionatmessagelevel，chm)
25.消息级别内聚指标chm衡量一个微服务发布的接口在消息级别的内聚性。该指标值越大，对应微服务的功能凝聚力就越大，系统的可维护性越高，公式如下：
[0026][0027]
其中，oprk,oprm∈oj是接口ij上的操作，并且k≠m。f
msg
计算两个操作在消息级别的相似度，表示输入参数和返回值相似度的平均值，公式如下：
[0028][0029]
其中，parm,retm,park,retk分别是oprm和oprk的一系列输入参数和返回值。微服务系统的平均消息级别内聚使用chm表示，公式如下：
[0030][0031]
其中，n为微服务数量。
[0032]
(2)向心耦合(centripetal coupling，cpc)
[0033]
向心耦合指在微服务系统中两个微服务同时依赖第三个微服务。对于微服务系统中的向心耦合关系而言，如果被依赖的微服务改变，依赖它的各个微服务可能会发生改变。向心耦合关系越多，微服务系统的耦合度越高，可维护性越低。系统中所有向心耦合关系组成的集合使用r
cpc
表示，公式如下：
[0034]rcpc
＝{(ms,(os,sd))|ms,os,sd∈ms∧sd∈d
ms
∧sd∈d
os
}
[0035]
其中，ms为系统中所有微服务组成的集合。d
ms
和d
os
分别为微服务ms和os的直接依赖项集合，公式如下：
[0036]dms
＝{cd|r∈r∧r＝(ms,cd)}
[0037]
其中，cd为微服务ms直接依赖的另一个微服务，r为二者之间的依赖关系，r为系统中的微服务依赖关系集合。微服务系统的向心耦合使用cpc表示，公式如下：
[0038]
cpc＝|r
cpc
|
[0039]
(3)离心耦合(centrifugal coupling，cfc)
[0040]
离心耦合指在微服务系统中一个微服务同时依赖其他两个微服务。该关系的出现可能是由于微服务系统粒度划分得过小，微服务之间耦合变多。离心耦合越多，微服务系统的耦合度越高，可维护性越低。系统中所有离心耦合关系组成的集合使用r
cfc
表示，公式如
下：
[0041]rcfc
＝{(ms,(ds,od))|ms,ds,od∈ms∧ds∈d
ms
∧od∈d
ms
}
[0042]
其中，ms为系统中所有微服务组成的集合。d
ms
为微服务ms的直接依赖项集合，与向心耦合中定义一致。微服务系统的离心耦合使用cfc表示，公式如下：
[0043]
cfc＝|r
cfc
|
[0044]
(4)强耦合占可能依赖项比率(ratio of strong coupling to possible dependencies，rscpd)
[0045]
强耦合特指微服务系统中的向心耦合关系和离心耦合关系，它们相对于微服务系统中两个微服务之间单独的依赖关系能更好地体现微服务系统的耦合程度。强耦合占可能依赖项比率越高，微服务系统的耦合度越高，可维护性越低。rscpd为强耦合占可能依赖项的比率，公式如下：
[0046][0047]
其中，nec为微服务系统的可能依赖项数量，即系统中的所有微服务数量。
[0048]
(5)接口数量(interface number，ifn)
[0049]
接口数量指标ifn衡量一个微服务对外提供的接口数量。指标值越小，微服务承担单一职责的可能性就越大，系统的可维护性越高。公式如下：
[0050]
ifnj＝|ij|
[0051]
其中，ij为微服务msj对外提供的所有功能接口。微服务系统的平均微服务接口数量用ifn表示，公式如下：
[0052][0053]
其中，n为系统中微服务数量。
[0054]
(6)依赖微服务参数种类(dependent microservice parameter types，dmpt)
[0055]
依赖微服务参数种类指标dmpt衡量一个微服务本身在依赖、通信和数据处理时的复杂度。它计算了一个微服务调用的其他所有微服务方法的参数种类。该指标值越大，说明该微服务的依赖复杂度越高，对应的可维护性越低。公式如下：
[0056][0057]
其中，n为系统中微服务数量。
[0058]
(7)内部共同更改频率(internal co-change frequency，icf)
[0059]
内部共同更改频率指标icf衡量历史提交记录中一个微服务内部所有实体共同更改的频率。该指标值越大，意味着这个微服务内部的所有实体共同演化的可能性更高，系统的可维护性越高。公式如下：
[0060]
[0061]
其中，em和en均为微服务msj的实体集中的实体,即em,f
cmt
(em,en)是实体em和en共同更改的commit数量。当m＝n时，f
cmt
(em,en)＝0。微服务系统的平均内部共同更改频率用icf表示，公式如下：
[0062][0063]
其中，n为系统中微服务数量。
[0064]
(8)外部共同更改频率(external co-change frequency，ecf)
[0065]
外部共同更改频率指标ecf衡量历史提交记录中不同微服务的实体共同更改的频率。该指标值越大，意味着属于不同微服务中的实体共同演化的可能性越高，系统的可维护性越低。公式如下：
[0066][0067]
其中，ecfj计算了微服务msj的实体集和除微服务msj外的微服务实体集中共同更改的频率。是外部实体集，满足f
cmt
(em,en)是实体em和en共同更改的commit数量。如果ecfj＝1。微服务系统的平均外部共同更改频率用ecf表示，公式如下：
[0068][0069]
其中，n为系统中微服务数量。
[0070]
(9)外部共同更改与内部共同更改比率(ratio of ecf and icf，rei)
[0071]
外部共同更改与内部共同更改比率指标rei衡量微服务间的实体共同更改频率与位于微服务内部的实体共同更改频率的比率，即微服务独立演化的能力。该指标值越小，跨微服务发生共同更改的可能性就越小，微服务往往会独立演化，可维护性越高。rei公式如下：
[0072]
rei＝ecf/icf
[0073]
优选地，步骤s5中的9个微服务粒度评估指标分为内聚、耦合、规模、复杂度和独立自主五个微服务粒度评估因素，其中消息级别内聚指标chm属于内聚，向心耦合cpc、离心耦合cfc和强耦合占可能依赖项比率rscpd属于耦合，接口数量ifn属于规模，依赖微服务参数种类dmpt属于复杂度，内部共同更改频率icf、外部共同更改频率ecf和外部共同更改占内部共同更改比率rei属于独立自主。在耦合方面，强耦合占可能依赖项比率rscpd为组合指标。在独立自主方面，外部共同更改占内部共同更改比率rei为组合指标。
[0074]
优选地，步骤s5中五个微服务粒度评估因素各由一个能够完整代表该维度的指标进行表示，其中内聚由消息级别内聚chm表示，耦合由强耦合占可能依赖项比率rscpd表示，规模由接口数量ifn表示，复杂度由依赖微服务参数种类dmpt表示，独立自主由外部用同更
改与内部共同更改比率rei表示。5个指标在评估方法中所占权重代表该指标在评估方法中的比重，数值如下：
[0075][0076]
本发明还提供一种面向可维护性的微服务粒度评估工具，所述工具包含源数据获取模块、数据提取模块、数据清洗模块、数据导入模块、微服务粒度评估模块，实现了如权利要求2-15中任意所述的面向可维护性的微服务粒度评估方法。
[0077]
本发明的有益效果为：通过获取微服务项目版本信息、历史提交信息和微服务项目源代码，进一步自动提取微服务项目不同版本的微服务接口数据和微服务间依赖数据，对各类评估所需数据进行清洗从而确保其有效性，最后基于各类评估所需数据计算9个微服务粒度评估指标，并将5个分别代表内聚、耦合、规模、复杂度和独立自主的组合指标按照各自权重聚合成最终的微服务粒度评估得分。该方法在可维护性角度辅助开发者全面地从各个因素来度量微服务粒度，并提供直观的面向可维护性的粒度评估结果，从而记录并追踪微服务系统软件生命周期各个阶段中微服务粒度在可维护性方面的变化，支持开发者在软件生命周期的各个阶段对微服务粒度进行评估和调整。
附图说明
[0078]
图1本发明中的一种面向可维护性的微服务粒度评估方法的流程图。
[0079]
图2本发明中的一种面向可维护性的微服务粒度评估方法中源数据获取的流程图。
[0080]
图3本发明中的一种面向可维护性的微服务粒度评估方法中数据提取的流程图。
[0081]
图4本发明中的一种面向可维护性的微服务粒度评估方法中数据清洗的流程图。
[0082]
图5本发明中的一种面向可维护性的微服务粒度评估方法中粒度评估的流程图。
[0083]
图6本发明中的一种面向可维护性的微服务粒度评估方法所含指标的结构图。
[0084]
图7本发明中的一种面向可维护性的微服务粒度评估方法所含向心耦合指标示意图。
[0085]
图8本发明中的一种面向可维护性的微服务粒度评估方法所含离心耦合指标示意图。
[0086]
图9本发明中的一种面向可维护性的微服务粒度评估工具的用户使用流程图。
[0087]
图10本发明中的一种面向可维护性的微服务粒度评估工具的系统架构图。
[0088]
图11、图12为经历过粒度调整的微服务项目粒度评估结果展示图。
具体实施方式
[0089]
下面结合附图和实施例对本发明作进一步的详细说明。
[0090]
本文使用的术语“源数据”是指微服务项目所有版本的源代码文件以及历史提交数据。
[0091]
本文使用的术语“消息级别”是指不同接口在通信时传递消息的过程。
[0092]
本文使用的术语“向心耦合”是指微服务系统中两个微服务共同依赖于一个微服务的共享依赖关系。
[0093]
本文使用的术语“离心耦合”是指微服务系统中一个微服务同时依赖于其他两个微服务的同时依赖关系。
[0094]
本文使用的术语“强耦合”是指微服务系统中向心耦合和离心耦合的集合。
[0095]
本文使用的术语“可能依赖项”是指微服务系统中微服务的数量。
[0096]
本文使用的术语“内聚”是对软件设计中模块内各元素间关联强度的度量。内聚作为一个微服务中各个部分的凝聚程度，具体表现为每个部分对该微服务功能的贡献程度。一般来说，微服务系统的内聚力越高，可维护性越高。
[0097]
本文使用的术语“耦合”是软件模块之间相互依赖的方式和程度。每个微服务都包含一个独特的业务流程，并与其他微服务高度解耦和隔离。较高的耦合度通常对可维护性有负面影响。
[0098]
本文使用的术语“规模”是指每个微服务包含的接口数量。每个微服务的规模应该尽可能的小，较小的规模使得微服务易于维护，其对可维护性有正面影响。小规模的微服务应该遵循单一职责原则，即微服务应该只有一个改变的理由，遵循该原则的软件设计应该将出于相同原因而更改的软件元素聚集在一起。
[0099]
本文使用的术语“复杂度”是指分析、维护、测试、设计和修改软件的难易程度。高复杂度使得软件维护起来更加困难，因此对可维护性有负面影响。微服务的复杂度体现在依赖、通信和数据处理方面。就微服务粒度而言，如果单个微服务的粒度过大，则微服务本身具备的职责增加，其功能复杂度也较高；反之，如果单个微服务粒度过小，则微服务系统中存在数量多且规模小的微服务，微服务之间的交互程度增加，通信复杂度提高。
[0100]
本文使用的术语“独立自主”是指每个微服务具有独立的生命周期。为此，微服务之间应该高度解耦，保证每个微服务独立部署与演化，从而达到独立自主。一般来说，微服务系统的独立自主的程度越高，对其进行功能添加、更改或错误修复所需的时间就越短，系统可维护性也越高。
[0101]
实施例1：本发明提供了一种面向可维护性的微服务粒度评估方法，包括以下步骤：
[0102]
步骤s1：基于用户提供的仓库地址以及项目版本信息，自动化地获取每个项目版本的源代码和历史提交信息，并对源代码进行自动编译，生成对应的class文件。
[0103]
步骤s2：基于步骤s1中项目每个版本的class文件，提取出评估所需项目各个版本
的微服务接口数据和微服务间依赖数据。
[0104]
步骤s3：基于步骤s1获取的项目历史提交信息和步骤s2中所提取的各类评估所需输入数据，按照不同的规则对各类数据进行清洗。
[0105]
步骤s4：若所要评估的项目不是基于springcloud框架开发的微服务项目，用户可直接将处理好的项目数据进行导入。
[0106]
步骤s5：基于步骤s3所清洗得到的数据或基于步骤s4所导入的处理好的项目数据，计算9个与可维护性相关的微服务粒度评估指标，根据权重计算粒度评估最终得分。
[0107]
本发明提供了一种面向可维护性的微服务粒度评估工具，所述包括：源数据获取模块、数据提取模块、数据清洗模块、数据导入模块、微服务粒度评估模块，用于将上述评估方法实例化，即自动化地实现微服务系统的粒度评估。
[0108]
下面结合具体的实施例对本发明的技术方案进行详细说明。
[0109]
实施例一
[0110]
图1本发明中的一种面向可维护性的微服务粒度评估方法的流程图。具体包括如下的步骤：
[0111]
步骤s100：自动化地获取项目源数据；
[0112]
步骤s200：提取评估所需要的各类输入数据；
[0113]
步骤s300：清洗评估所诉需要的各类输入数据；
[0114]
步骤s400：如果所要评估的项目不是基于springcloud框架实现的微服务系统，需要用户自行导入准备好的评估所需输入数据；
[0115]
步骤s500：进行微服务粒度评估
[0116]
在所述步骤s100中包括以下步骤：
[0117]
步骤s101：使用git命令获取项目历史提交数据；
[0118]
步骤s102：根据项目开发周期，生成版本信息列表，用于获取项目每个版本源代码；
[0119]
步骤s103：检查每个版本标识的合法性，记录不合法的版本标识；
[0120]
步骤s104：根据版本标识从仓库中获取对应版本代码，并进行编译，记录编译失败的版本，便于后续调试；
[0121]
以上所述总体流程如图2所示。
[0122]
在所述步骤s200中包括以下步骤：
[0123]
步骤s201：扫描配置文件获取当前微服务名称；
[0124]
步骤s202：扫描出每个微服务中所有含有controller相关注解的文件，从文件中找到所有存在restful相关注解的方法信息并存储；
[0125]
步骤s203：扫描所有含有@feignclient注解并调用当前服务方法的文件，生成并存储一条微服务依赖关系；
[0126]
以上所述总体流程如图3所示。
[0127]
在所述步骤s300中包括以下步骤：
[0128]
步骤s301：针对评估所需微服务接口数据，需要过滤非逻辑微服务相关信息；
[0129]
步骤s302：针对评估所需微服务间依赖数据，需要过滤起点或终点包含非逻辑微服务的依赖关系；
[0130]
步骤s303：针对评估所需的微服务演进数据，需要过滤非代码文件的演进信息；
[0131]
以上所述总体流程如图4所示。
[0132]
在所述步骤s500中包括以下步骤：
[0133]
步骤s501：根据上述所述的评估所需输入数据，计算5个评估因素中9个微服务粒度评估指标，分别为消息级别内聚、向心耦合、离心耦合、强耦合占可能依赖项比率、接口数量、依赖微服务参数种类、内部共同更改频率、外部共同更改频率、外部共同更改与内部共同更改比率；
[0134]
步骤s502：根据每个计算得到的综合指标及其权重，生成最终的微服务粒度评估得分；
[0135]
以上所述总体流程如图5所示，该评估方法所含指标结构图如图6所示。
[0136]
图7为向心耦合示意图，其中ms和os为微服务系统中两个不同的微服务，sd为ms和os共同依赖的微服务。ms、os和sd构成一个元组(ms,(os,sd))来表示一个向心耦合关系。
[0137]
图8为向心耦合示意图，其中ms为微服务系统的一个微服务，ds和od为ms所依赖的两个不同的微服务，ms、ds和od构成一个元组(ms,(ds,od))来表示一个离心耦合关系。
[0138]
实施例2：
[0139]
基于上述各实施例的基础上，所述工具包含源数据获取模块、数据提取模块、数据清洗模块、数据导入模块、微服务粒度评估模块。所述源数据提取模块用于供用户自动化地从代码仓库获取所要分析的基于springcloud框架开发的微服务项目的源代码及历史提交数据。所述数据提取模块用于供用户自动化地提取评估所需的微服务接口数据和微服务间依赖数据。所述数据清洗模块用于供用户对所提取出的评估所需各类数据按照一定的规则进行清洗，从而过滤无效数据。所述数据导入模块用于除基于springcloud框架开发的其他微服务项目的评估数据导入。所述微服务评估模块用于供用户自动化地计算微服务粒度评估指标，并根据指标权重计算微服务粒度评估得分。
[0140]
图9为所述工具使用流程图。当用户开始使用该工具对微服务系统进行粒度评估时，可以自己向工具导入各类输入数据，或者使用本工具对各类输入数据进行自动抽取。当使用本工具对模型各类输入数据进行自动抽取时，首先要利用工具采集项目源数据，接着从源数据中提取各类所需输入数据，然后对提取的数据进行清洗，最后将所有数据进行存储。将各类输入数据准备好后，便可以使用工具对微服务粒度进行评估，并将评估结果进行存储。后续还可以使用工具查看和导出模型的计算结果。
[0141]
图10为所述工具架构图，分为数据层、持久层、业务层和表现层。分别负责输入及评估数据的存储、所有数据的访问、工具业务逻辑功能实现以及评估结果展示。
[0142]
图11和图12为一个经历过粒度调整的微服务项目粒度评估结果展示图。所述方法的所有指标能够合理地度量出该项目粒度调整所带来的变化，指标的变化同时说明该项目粒度调整的合理性。在不同的软件开发阶段，该方法有着不同的应用场景。在微服务系统开发初期，各个微服务规模、微服务之间的关系变化明显，开发者可以重点关注方法中的微服务内聚、耦合、规模、复杂度指标的变化，即chm、cpc、cfc、rscpd、ifn、dmpt指标的变化，来着重分析微服务系统规模、依赖复杂度、总体内聚性以及微服务复杂依赖关系的合理性。当微服务系统结构相对稳定时，开发者可以重点关注微服务独立演化相关指标的变化，即icf、ecf、rei的变化，来着重分析系统中微服务内部与微服务之间实体共同演进的能力，从而验
证系统微服务粒度的合理性。当对微服务系统进行重构时，开发者可以使用工具度量重构前后微服务粒度各个因素对应的指标，通过对比所有评估指标变化以及评估得分来验证重构操作在可维护性角度的合理性。在软件开发的各个阶段，开发者可以通过评估得分从而更加直观的监测微服务系统的可维护性变化情况。
[0143]
注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。