CN113206884A - 一种基于组合验证机制的微服务选择方法 - Google Patents

Abstract

本发明公开了一种基于组合验证机制的微服务选择方法，包括以下步骤：(1)获得具有某个功能的微服务集合，加入系统得到备选集合；(2)将备选集合中的微服务依次放入在现有的架构中，分别计算出服务自身分数F、上游契合度分数G和下游契合度分数H；(3)将得到的三个分数做几何平均数计算，得到标准值，再将标准值用于计算得到服务最终得分Sc；(4)根据服务最终得分Sc，选择分数最高的作为质量最高且最符合当前架构的微服务。利用本发明，可以让使用者可以根据自己的需求，快速找到最合适、最理想的服务。

Description

一种基于组合验证机制的微服务选择方法

技术领域

本发明属于微服务组合领域，尤其是涉及一种基于组合验证机制的微服务选择方法。

背景技术

在当前的网站开发中，微服务已经越来越受开发者的重视，越来越多的应用开始往微服务方向发展。

如公开号为CN111124430A的中国专利文献公开了一种混合架构的微服务部署方法和装置，公开号为CN109947547A的中国专利文献公开了一种基于云计算的微服务构架方法。

现有的单体架构存在一些问题，例如：

1)项目过于复杂之后。动一发而牵全身，修改十分困难。

2)开发缓慢。某块之间相互制约，导致同步开发受到约束。

3)技术栈不易扩展。项目开始的时候一旦选择了某一种技术栈来开发项目，那么以后就很难在技术栈上做切换。有时候因为某一个功能需要改新的技术去做，那么这是很难去重新改造这个模块的。

基于微服务开发的应用存在以下的优点：

1)易于开发和维护。微服务相对很小，容易理解。

2)独立部署。一个微服务的部署和修改不会影响其他服务。

3)伸缩性强。每个微服务都可以水平、横向扩展，而且对于资源的需求都是独立，因此扩容或者缩容都十分方便。

4)与组织相匹配。微服务架构可以更好将架构和组织相匹配；每个团队独立负责某些服务，获得更高的生产力。

现有的服务组合都是依靠人工选定的，架构师经过评估后去选择某一个应用需要使用哪种微服务提供支持，但是由于人工知识的受限，可能无法在众多的微服务中找到最符合自身需求的。

发明内容

本发明提供了一种基于组合验证机制的微服务选择方法，让使用者可以根据自己的需求，快速找到最合适、最理想的服务。

一种基于组合验证机制的微服务选择方法，包括以下步骤：

(1)获得具有某个功能的微服务集合，加入系统得到备选集合；

(2)将备选集合中的微服务依次放入在现有的架构中，分别计算出服务自身分数F、上游契合度分数G和下游契合度分数H；

(3)将得到的三个分数做几何平均数计算，得到标准值，再将标准值用于计算得到服务最终得分Sc；

(4)根据服务最终得分Sc，选择分数最高的作为质量最高且最符合当前架构的微服务。

进一步地，步骤(2)中，所述服务自身分数F的公式为：

式中，n表示微服务自身评价因素的个数，α_i表示第i个自身评价因素的权重因子，x_i表示微服务第i个自身评价因素的系统分数。

所述的自身评价因素包括但不限于社区活跃性、使用量、可靠稳定性和可扩展性。

进一步地，步骤(2)中，所述上游契合度分数G的公式为：

式中，m表示上游微服务调用当前微服务的上游契合因素个数，β_j表示第j个上游契合因素的权重因子，y_j表示第j个上游契合因素的系统分数。

所述的上游契合因素包括但不限于响应时间、并发承受量、熔断超时处理和对上游的接口封装。

进一步地，步骤(2)中，所述下游契合度分数H的公式为：

式中，l表示当前微服务调用下游微服务时的下游契合因素个数，γ_k表示第k个下游契合因素的权重因子，z_k表示第k个下游契合因素的系统分数。

所述的下游契合因素包括但不限于下游支持性、处理机制和处理能力。

进一步地，步骤(3)中，所述服务最终得分Sc的公式为：

Sc＝oF′+pG′+qH′

式中，F′、G′、H′分别表示服务自身分数F、上游契合度分数G和下游契合度分数H进几何平均数计算后的标准值，o,p,q表示权重因子。

与现有技术相比，本发明具有以下有益效果：

本发明的方法综合考虑了服务自身质量以及服务和已有架构的契合度，可以在众多同类型的微服务中，挑选出最符合开发者要求且最契合已有架构的微服务。并且在开发者对某个领域所对应的微服务不太了解的情况下，也可以精准的做出选择。

附图说明

图1位本发明实施例一种基于组合验证机制的微服务选择方法的流程示意图；

图2为本发明方法在客户端作用时机以及作用点；

图3为服务质量验证阶段；

图4为具体数据库微服务计算服务最终得分流程图。

具体实施方式

下面结合附图和实施例对本发明做进一步详细描述，需要指出的是，以下所述实施例旨在便于对本发明的理解，而对其不起任何限定作用。

在一个web系统中，通常需要很多的基础应用微服务作为支撑，而同一个应用会存在很多不同的类型供用户进行选择。例如最常见的数据库服务，市面上就有Mysql、Oracle、SQL Server等；消息中间件服务，会有RabbitMQ、RocketMQ、Kafka、ActiveMQ等。这些不同服务供应商提供的服务，往往存在很多的区别，虽然主要功能都相近，但是会各有所长，应用场景也会千差万别。因此对于这些可供选择的服务，如何从中选择一个合适的服务与目前已有的web架构进行组合搭配，这就产生了问题。

本发明方法的目的，就是解决用户上述的烦恼，通过把用户自定义的需求作为参数，在众多微服务中，找到最符合要求的微服务。

如图1所示，一种基于组合验证机制的微服务选择方法，主要包括服务准备阶段、服务质量验证阶段和服务调用阶段。

假设某个web系统已经有了确定的部分服务集合S，而我们还需要服务A。我们的目标就是从SA中选择出具体的服务A，组合进已有的服务集合S中，使得整个web系统符合预期并能够良好的运行。图2展示了该算法在客户端的作用时机。整体步骤如下：

步骤一：用户首先将自己已知的微服务加入已有备选服务集合中，形成完整的备选集合SA，并设置需求参数。

假设用户需要的服务A为数据库服务。用户如果有自己的备选，例如Mysql服务Oracle服务，那么就可以将这些服务加入系统已有的服务集中(假设系统已有的服务为Mongodb，Sql server和Mysql)。用户的选择服务如果系统中已有，则不添加进系统，如果系统中没有，则添加进系统。因此最终完整的备选集合SA就是：Mysql，Oracle，Mongodb和Sqlserver四个服务。同时系统会不断的进行更新，将用户新增的服务放入库中，从而不断提高系统的完善性。

步骤二：计算服务自身质量，得到服务自身分数F。

我们首先考虑SA中各个具体微服务的自身的因素，当然自身因素中也会出现主要因素和次要因素。例如主要因素可能是服务的稳定性，可靠性等；次要因素可能是服务调用的复杂性，服务后续的开发维护等(因为对于大部分公司而言，web服务通常都是选择第三方的软件，那么就会出现学习成本，后续的运维成本。而可靠性，稳定性是提供商保证的)。

本发明定义服务自身的因素分数设为F，各个因素的分数设为x，那么

其中，α作为各个因素的权重因子,即每个因素对于选择者而言，权重都是不同的。因为各个公司的需求不同，这就导致有些公司可能需要稳定性高的，那么就可以将稳定性因素对应的权重增大，而有些公司可能存在运维能力差的问题，因此想要容易维护的，那么可以将维护的权重增大，权重因子α是用户可以自己调配的。如果用户不做设置，那么默认权重全部为

那么首先考虑这四个数据库服务的自身因素例如有社区活跃性，使用量，可靠稳定性和可扩展性等(下述分数均为百分制)。根据计算得出四个服务的社区活跃性、使用量、可靠稳定性和可扩展性如下表1所示：

表1

这里假设用户对自身服务的质量，在可扩展性上有一定要求，因此用户将可扩展性因子的权重调高到了70％，剩下的三个因子就各占10％。那么通过公式就可以分别计算出这四个数据库的服务自身分数F如下表2所示：

表2

Mysql	Oracle	Mongodb	Sql server
				87.08	51.85	57.57	60.14

服务自身分数F的值越高，说明当前服务的自身质量越好，越能符合用户需求以及架构的需求。

在步骤三之前，需要先说明一个概念，上下游契合度。

上下游契合度指的是某个具体的服务能否良好的嵌入到已有的服务集合中去。假设服务A的上游使用者是M，下游使用者是N。那么当服务A嵌入到服务集合S中之后，整个系统的调用链就完善了，那么就会出现服务A和上游M，下游N的关系问题，定义为上下游契合度。

步骤三：计算上游契合度分数G

上游服务是指调用服务A的服务集，由于上游服务需要服务A的支持，因此我们需要考虑的因素就有服务A的响应时间，服务A的并发承受量，服务A的熔断超时处理机制，以及一些其他的属性(例如是否有良好的接口封装支持上游服务的调用)。

将上游契合度的分数定义为G，将服务A的每个因素定义为y，那么

其中，β是各个因素的权重因子，不同用户对于因素的衡量都是不同的，因此也可以让用户去自定义。如果用户不做设置，那么默认权重全部为

在该示例中，假设上游服务是一个Java语言编写的调用服务，上游服务通过http、https或者rpc的方式调用当前的数据库接口。虽然Java语言对这四个数据库服务都有良好的性能支持，但是在支持性上，Mysql和Oracle都会比Mongodb和Sql server好一点。同时还需要看上游Java服务所需要的接口形式，如果上游服务需要的是大量Json格式作为信息存储的格式，那么Mongodb的优势就体现出来。

通过系统测试计算，可以得到这四个数据库服务分别在响应时间、并发承受量、熔断超时处理以及对上游的接口封装性上的分数(百分制)，具体如下表3所示：

表3

这里假设用户对数据的存储没有特殊要求，但是用户对支持性的要求较高，因此在上述步骤一中的参数设置中，将对上游的接口封装性的权重设置为55％，剩下三个因子的就各占15％。通过计算可以分别求得这四个数据库服务的上游契合度分数如下表4所示：

表4

Mysql	Oracle	Mongodb	Sql server
				86.24	82.67	75.20	76.24

上游契合度分数G的值越高，说明当前服务对上游的支持越高，同时也越能符合用户的需求。

步骤四：计算下游契合度分数H

下游服务是被服务A调用的，那么就需要下游服务对于服务A的支持，即服务A能否良好的契合下游服务。例如对于下游的数据结构，服务A能否很好的接受处理；下游如果崩溃无法使用，服务A的处理机制等。

将下游契合度的分数定义为H，将服务A的每个因素定义为z，那么

其中，γ是各个因素的权重因子，也可供用户自定义。如果用户不做设置，那么默认权重全部为

本示例中，假设下游还有服务为数据库做支持，那么就需要考虑的因素就有数据库服务对下游的支持性，下游崩溃情况下的处理机制以及如何确保下游正确接受并处理消息的能力等。

通过系统测试计算，可以得到四个数据库服务分别在下游支持性，处理机制以及处理能力的分数(百分制)如下表5所示：

表5

这里假设用户对下游的服务没有要求，因此因子的权重默认都是

通过计算可以分别求得这四个数据库服务的下游契合度分数如下表6所示：

表6

Mysql	Oracle	Mongodb	Sql server
				83.0	82.7	76.4	76.2

下游契合度分数H的值越高，说明当前服务对下游的支持越高，同时也越能符合用户的需求。

步骤五：重复步骤二、三、四，多次求取并做几何平均数处理

由于步骤二、三、四中的x，y，z都是系统给出的分数，因此为了确保正确性，可以进行多次求值，并对多次求得的分数做几何平均数计算减少误差(因为几何平均数受极端数据的影响要小于算术平均数)。

几何平均数的公式为：

因此，将上述多次的值带入公式中，即可分别求得几何平均分数F′，G′，H′。

示例中，假设重复步骤二、三、四操作5次，得到数据如表7所示。

表7

根据表7的数据，分别计算几何平均分数F′，G′，H′如下表8所示：

表8

步骤六：计算服务最终得分Sc

根据几何平均数以及归一化处理之后，就可以得到服务服务A的三个基本分数。最后服务A对于整个系统的分数，可以定义为

Sc＝oF′+pG′+qH′

其中，o,p,q也是权重因子，可由用户自定义。如果用户不做定义，那么默认因子为0.2:0.4:0.4，即上下游的契合度相较与服务自身而言，更为重要。

假设用户对权重不做设定，将步骤五中求得几何平均数带入Sc计算公式中，可以求得四个数据库服务的服务最终得分，分别为下表9所示：

表9

Mysql	Oracle	Mongodb	Sql server
				84.44	77.586	71.432	73.65

步骤七：调用服务最终得分最高的服务

最终通过上述步骤，服务最终得分最高的服务，就是服务质量最高，最符合用户预期的服务。整个服务质量验证过程如图3所示。上述四个数据库服务中，得分最高的是Mysql服务，因此在当前的web架构下，我们选取Mysql服务作为服务A放入已有集合S中。对于数据库选择的案例，整个流程如图4所示。

以上所述的实施例对本发明的技术方案和有益效果进行了详细说明，应理解的是以上所述仅为本发明的具体实施例，并不用于限制本发明，凡在本发明的原则范围内所做的任何修改、补充和等同替换，均应包含在本发明的保护范围之内。

Claims (8)

1.一种基于组合验证机制的微服务选择方法，其特征在于，包括以下步骤：

(1)获得具有某个功能的微服务集合，加入系统得到备选集合；

(2)将备选集合中的微服务依次放入在现有的架构中，分别计算出服务自身分数F、上游契合度分数G和下游契合度分数H；

(3)将得到的三个分数做几何平均数计算，得到标准值，再将标准值用于计算得到服务最终得分Sc；

(4)根据服务最终得分Sc，选择分数最高的作为质量最高且最符合当前架构的微服务。

2.根据权利要求1所述的基于组合验证机制的微服务选择方法，其特征在于，步骤(2)中，所述服务自身分数F的公式为：

式中，n表示微服务自身评价因素的个数，α_i表示第i个自身评价因素的权重因子，x_i表示微服务第i个自身评价因素的系统分数。

3.根据权利要求2所述的基于组合验证机制的微服务选择方法，其特征在于，所述的自身评价因素包括但不限于社区活跃性、使用量、可靠稳定性和可扩展性。

4.根据权利要求1所述的基于组合验证机制的微服务选择方法，其特征在于，步骤(2)中，所述上游契合度分数G的公式为：

式中，m表示上游微服务调用当前微服务的上游契合因素个数，β_j表示第j个上游契合因素的权重因子，y_j表示第j个上游契合因素的系统分数。

5.根据权利要求4所述的基于组合验证机制的微服务选择方法，其特征在于，所述的上游契合因素包括但不限于响应时间、并发承受量、熔断超时处理和对上游的接口封装。

6.根据权利要求1所述的基于组合验证机制的微服务选择方法，其特征在于，步骤(2)中，所述下游契合度分数H的公式为：

式中，l表示当前微服务调用下游微服务时的下游契合因素个数，γ_k表示第k个下游契合因素的权重因子，z_k表示第k个下游契合因素的系统分数。

7.根据权利要求6所述的基于组合验证机制的微服务选择方法，其特征在于，所述的下游契合因素包括但不限于下游支持性、处理机制和处理能力。

8.根据权利要求1所述的基于组合验证机制的微服务选择方法，其特征在于，步骤(3)中，所述服务最终得分Sc的公式为：

Sc＝oF′+pG′+qH′

式中，F′、G′、H′分别表示服务自身分数F、上游契合度分数G和下游契合度分数H进几何平均数计算后的标准值，o,p,q表示权重因子。

Images