CN117370134A - 微服务性能的评价方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开涉及一种微服务性能的评价方法、装置、电子设备及存储介质，上述评价方法包括：对微服务***的运行过程进行监测，得到感知拓扑信息；上述感知拓扑信息涵盖上述微服务***中微服务的资源调度和服务调用至少一种拓扑关系；根据上述感知拓扑信息，构建故障模拟信息；根据上述故障模拟信息，在上述微服务***中进行故障场景模拟；对预设监测指标在故障场景模拟前、模拟中和模拟后的实时表现数据进行分析，得到上述微服务***的稳定性评价结果。上述方案实现自动化模拟故障场景并自动化评价微服务***的稳定性，评价结果更加准确。

Description

微服务性能的评价方法、装置、电子设备及存储介质

技术领域

本公开涉及微服务技术领域，尤其涉及一种微服务性能的评价方法、装置、电子设备及存储介质。

背景技术

微服务***是多个微服务的集合，是一种能够灵活进行组织和升级迭代的软件架构形式。一个复杂的应用软件的功能可以通过拆分的多个微服务来实现，每个微服务可以独立部署、运行和升级且能够采用不同开发语言进行独立开发，具有扩展灵活和维护方便的优点。在微服务***实现所需功能的过程中，如果某一个或多个微服务发生故障可能会导致整个微服务***的不可用或功能受影响，因此进行微服务***的稳定性测试和评估十分必要。

在实现本公开构思的过程中，发明人发现相关技术中至少存在如下技术问题：相关技术中，大多是需要技术人员手动设置测试规则并手动进行微服务***的稳定性测试，而编写测试规则的前提是需要技术人员熟练掌握微服务***的相关知识，并能够设计出合适的测试用例，这对于技术人员要求较高、耗费时间和人力成本，预设测试规则和测试用例的方式也会导致测试和评价不全面，而且无法做到根据实际运行场景适配化测试，评估准确度有待于提升。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开的实施例提供了一种微服务性能的评价方法、装置、电子设备及存储介质。

第一方面，本公开的实施例提供一种微服务性能的评价方法。上述评价方法包括：对微服务***的运行过程进行监测，得到感知拓扑信息；上述感知拓扑信息涵盖上述微服务***中微服务的资源调度和服务调用至少一种拓扑关系；根据上述感知拓扑信息，构建故障模拟信息；根据上述故障模拟信息，在上述微服务***中进行故障场景模拟；对预设监测指标在故障场景模拟前、模拟中和模拟后的实时表现数据进行分析，得到上述微服务***的稳定性评价结果。

根据本公开的实施例，根据上述感知拓扑信息，构建故障模拟信息，包括：根据上述感知拓扑信息和预设故障类型，确定需要进行故障模拟的目标对象；针对上述目标对象，构建与上述预设故障类型对应的故障模拟内容；其中，上述故障模拟信息包含上述目标对象和上述故障模拟内容。

根据本公开的实施例，上述预设故障类型包括以下故障类型中的至少一种：实例宕机、CPU满载、内存满载、磁盘占满、网络丢包、网络延时、进程阻塞、依赖服务不可用、依赖服务延时。

根据本公开的实施例，上述感知拓扑信息包含：具有调用依赖关系的第一微服务节点的节点信息，各第一微服务节点之间的调用依赖关系。其中，根据上述感知拓扑信息和预设故障类型，确定需要进行故障模拟的目标对象，包括：在上述预设故障类型为第一故障类型的情况下，根据上述调用依赖关系和上述第一微服务节点的节点信息，确定进行故障模拟的第一目标微服务节点；上述第一故障类型包含以下至少一种：依赖服务不可用、依赖服务延时；针对上述目标对象，构建与上述预设故障类型对应的故障模拟内容，包括：针对上述第一目标微服务节点，构建上述第一故障类型对应的故障模拟内容。

根据本公开的实施例，上述感知拓扑信息包含：上述感知拓扑信息包含：上述微服务***中部署的第二微服务节点的节点信息，第二微服务节点进行资源调度的分配拓扑关系和优先级信息。其中，根据上述感知拓扑信息和预设故障类型，确定需要进行故障模拟的目标对象，包括：在上述预设故障类型为第二故障类型的情况下，根据上述第二微服务节点的节点信息和上述优先级信息，确定进行故障模拟的第二目标微服务节点；或者，根据上述第二微服务节点的节点信息、上述优先级信息和上述分配拓扑关系，确定进行故障模拟的第二目标微服务节点。其中上述第二故障类型包含以下至少一种：实例宕机、CPU满载、内存满载、磁盘占满、网络丢包、网络延时、进程阻塞。针对上述目标对象，构建与上述预设故障类型对应的故障模拟内容，包括：针对上述第二目标微服务节点，构建上述第二故障类型对应的故障模拟内容。

根据本公开的实施例，对预设监测指标在故障场景模拟前、模拟中和模拟后的实时表现数据进行分析，得到上述微服务***的稳定性评价结果，包括：对上述实时表现数据的变化规律进行分析，得到在故障场景模拟中和模拟后各故障场景对微服务***运行稳态的实时破坏程度信息；根据各故障场景的预设分配分值和上述实时破坏程度信息，确定每个故障场景下的稳定性评分；根据上述稳定性评分和各个故障场景预先分配的权重，生成上述微服务***的稳定性综合评分，上述稳定性综合评分作为上述稳定性评价结果。

根据本公开的实施例，上述评价方法还包括：获取上述微服务***中的各个微服务处于运行稳态下的第一历史状态数据和发生异常对应的第二历史状态数据；根据上述第一历史状态数据和上述第二历史状态数据，确定用于表示微服务运行情况的候选监测指标；上述候选监测指标用于作为指标配置界面中各微服务对应的指标选项；接收用户在上述指标配置界面中针对指标选项的选择信息和自定义指标信息；根据上述选择信息和上述自定义指标信息，生成各微服务对应的预设监测指标。

第二方面，本公开的实施例提供一种微服务性能的评价装置。上述评价装置包括：监测模块、构建模块、故障模拟模块和评价模块。上述监测模块用于对微服务***的运行过程进行监测，得到感知拓扑信息；上述感知拓扑信息涵盖上述微服务***中微服务的资源调度和服务调用至少一种拓扑关系。上述构建模块用于根据上述感知拓扑信息，构建故障模拟信息。上述故障模拟模块用于根据上述故障模拟信息，在上述微服务***中进行故障场景模拟。上述评价模块用于对预设监测指标在故障场景模拟前、模拟中和模拟后的实时表现数据进行分析，得到上述微服务***的稳定性评价结果。

第三方面，本公开的实施例提供了一种电子设备。上述电子设备包括处理器、通信接口、存储器和通信总线，其中，处理器、通信接口和存储器通过通信总线完成相互间的通信；存储器，用于存放计算机程序；处理器，用于执行存储器上所存放的程序时，实现如上所述的微服务性能的评价方法。

第四方面，本公开的实施例提供了一种计算机可读存储介质。上述计算机可读存储介质上存储有计算机程序，上述计算机程序被处理器执行时实现如上所述的微服务性能的评价方法。

本公开实施例提供的上述技术方案至少具有如下优点的部分或全部：

通过对微服务***的运行过程进行监测，得到感知拓扑信息，由于上述感知拓扑信息涵盖上述微服务***中微服务的资源调度和服务调用至少一种拓扑关系，能够自动感测出多个微服务在进行资源调度过程中的分配拓扑关系和相对优先级、微服务进行服务调用过程中的网络拓扑关系至少一种；那么根据上述感知拓扑信息构建得到的故障模拟信息进行故障场景模拟可以更加准确地模拟出微服务***在运行过程中可能出现的各种故障场景，对预设监测指标在故障场景模拟前、模拟中和模拟后的实时表现数据进行分析，得到的上述微服务***的稳定性评价结果也是更加准确和完善。上述方案实现自动化模拟故障场景并自动化评价微服务***的稳定性，评价结果更加准确，相较于采用人工手动设置测试规则和测试用例并手动进行微服务***的稳定性测试的方案而言，降低了对测试人员的技术门槛并提升了测试的自动化程度和测试结果的准确度。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

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

图1示意性地示出了适用于本公开实施例的微服务性能的评价方法的***架构；

图2示意性地示出了根据本公开一实施例的微服务性能的评价方法的流程图；

图3示意性地示出了根据本公开一实施例的步骤S220的详细实施流程图；

图4A示意性地示出了根据本公开一实施例的步骤S310和S320的实施过程示意图；

图4B示意性地示出了根据本公开另一实施例的步骤S310和S320的实施过程示意图；

图5示意性地示出了根据本公开另一实施例的微服务性能的评价方法的流程图；

图6示意性地示出了根据本公开一实施例的微服务性能的评价装置的结构框图；

图7示意性地示出了本公开实施例提供的电子设备的结构框图。

具体实施方式

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

本公开的第一个示例性实施例提供一种微服务性能的评价方法。

图1示意性地示出了适用于本公开实施例的微服务性能的评价方法的***架构。

本公开的实施例中，将应用软件实现一个或多个功能(例如为某个业务功能)所需的多个微服务的集合描述为微服务***。参照图1所示，适用于本公开实施例的微服务性能的评价方法的***架构100包含：微服务***110和性能评价应用120，其中微服务***110可以基于各种方式进行部署，例如包含但不限于是以下部署方式：单机多进程部署方式、多机器多进程部署方式、基于容器的部署方式、基于容器编排器(例如基于k8s进行部署)的部署方式、基于云函数(例如为API函数)的部署方式。

上述单机多进程部署方式是将多个微服务作为单个服务器中的多个进程。

多机器多进程部署方式是单机多进程部署的升级版本，通过提供多个服务器实现高可用性和可扩展性。

基于容器的部署方式是将微服务打包于容器中进行部署，具有高并发性，能够运行容器镜像里面的多个实例而不会引发冲突。

基于容器编排器的部署方式是基于容器编排器进行容器的部署和资源调度，例如以k8s(kubernetes的简称)容器编排器作为示例，将最小运行单位pod(pod是kubernetes中最小的资源管理组件，也是最小化运行容器化应用的资源对象)调度到工作节点上，在一个pod中可以包含一个或多个容器，每个容器用于运行一个微服务，pod作为在集群中运行的进程。

基于云函数的部署方式是将每个微服务构建为一个云函数接口，在需要调用微服务的情况下基于对应的接口进行服务调用即可。本公开实施例不限定具体微服务***的部署方式。

上述性能评价应用120用于执行本公开实施例提供的微服务性能的评价方法，能够实现自动化模拟故障场景并自动化评价微服务***的稳定性。上述性能评价应用120可以安装于微服务***所对应的服务端，该服务端作为微服务性能的评价装置的一种示例。上述性能评价应用120所安装的服务端具体可以是但不限于：主机(对应于单机多进程部署方式)、服务集群的主节点(多机器多进程部署方式)、运行容器的服务节点、具有容器编排器并进行资源调度管控的主节点、或者云服务器的管控装置等。

上述微服务包含但不限于是各种类型的服务，能够适配于业务类应用、运营类应用、开发类应用、测试类应用、运维类应用等的需求，诸如：登录服务、人脸识别服务、身份认证服务、权限分配服务、AI算法类服务、订单服务、物流服务、支付服务等。

图2示意性地示出了根据本公开一实施例的微服务性能的评价方法的流程图。

参照图2所示，本公开实施例提供的微服务性能的评价方法，包括以下步骤：S210～S240。

在步骤S210，对微服务***的运行过程进行监测，得到感知拓扑信息；上述感知拓扑信息涵盖上述微服务***中微服务的资源调度和服务调用至少一种拓扑关系。

在一些实施例中，可以通过对微服务***运行期间进行资源调用和服务调用至少一种运行过程进行监测，得到上述感知拓扑信息。

上述微服务***110包含多个微服务，例如图1中示例的微服务1、微服务2和微服务3等。在实现应用软件的一个或多个功能时，会存在微服务调用其他服务的过程。在一些实施例中，可以适配于微服务***的部署方式，在主机、服务集群的主节点、运行容器的服务节点、具有容器编排器并进行资源调度管控的主节点或云服务器的管控装置等服务端上安装第一感知模块，该第一感知模块用于进行服务调用的感测，在某个微服务发生服务调用的情况下进行网络调用链路的构建(例如登录微服务在执行过程中要调用人脸识别服务和验证码服务、订单微服务在订单结算环节要调用支付服务)，以及进行多个网络调用链路的整合，得到微服务***在服务调用过程中的网络拓扑关系。例如，在登录微服务执行过程中要调用验证码服务和人脸识别服务，则在监测到服务调用的时候对应会构建登录微服务与验证码服务、和登录微服务与人脸识别服务之间的网络调用链路。订单微服务在订单结算环节要调用支付服务，则在监测到服务调用的时候对应会构建订单微服务与支付服务之间的网络调用链路。

在实现应用软件的一个或多个功能时，还会存在资源调度的情形，多个微服务作为进程(对应于单机多进程部署方式、多机器多进程部署方式)、容器微服务(对应于基于容器的部署方式、基于容器编排器的部署方式)、云函数接口(对应于基于云函数的部署方式)等进行运行或被调用的过程中，会存在对CPU、内存、输入输出(IO)、网络、磁盘等资源的调度。在一些实施例中，可以适配于微服务***的部署方式，在主机、服务集群的主节点、运行容器的服务节点、具有容器编排器并进行资源调度管控的主节点或云服务器的管控装置等服务端上安装第二感知模块，该第二感知模块用于进行资源调度的感测，在将资源调度给某个微服务的情况下进行分配拓扑关系的构建，以及根据监测的资源调度逻辑确定各个微服务在进行资源分配过程中的相对优先级。例如在微服务1～微服务3都申请内核资源的情况下，将双核操作***中的CPU1的T1～T2(例如为左闭右开区间，不包含右端点值)时段分配给微服务1，将CPU2的T1～T3时段分配给微服务2，期间微服务3处于调度等待状态，等到微服务1释放了内核资源，将CPU1的T2～T4时段分配给微服务3；根据资源调度情况可以构建分配拓扑关系，同时按照高优先级的资源分配逻辑可以确定微服务1的优先级高于微服务3的优先级。

在步骤S220，根据上述感知拓扑信息，构建故障模拟信息。

由于上述感知拓扑信息涵盖上述微服务***中微服务的资源调度和服务调用至少一种拓扑关系，能够自动感测出多个微服务在进行资源调度过程中的分配拓扑关系和相对优先级、微服务进行服务调用过程中的网络拓扑关系至少一种，那么根据上述感知拓扑信息构建得到的故障模拟信息进行故障场景模拟可以更加准确地模拟出微服务***在运行过程中可能出现的各种故障场景。

在步骤S230，根据上述故障模拟信息，在上述微服务***中进行故障场景模拟。

故障模拟也可以称为故障演练，是遵循混沌工程原理的实践，通过以软件形式编排各种类型的故障来模拟生产***中可能发生的各种异常状态，基于对异常状态的分析和应对，进一步对微服务架构、资源调度或处理逻辑等进行优化，帮助提升微服务***的容错能力，避免真正的突发事件带来的灾难性后果。

在一些实施例中，上述故障模拟信息包含：需要进行故障模拟的目标对象和故障模拟内容。上述故障模拟内容可以对应于以下故障类型：实例宕机、CPU满载、内存满载、磁盘占满、网络丢包、网络延时、进程阻塞、依赖服务不可用、依赖服务延时等；故障模拟内容具体包括但不限于是：进行故障模拟的模拟参数、模拟时长、模拟频率、故障模拟触发条件等信息。

在一些实施例中，可以将单个故障场景逐一进行错峰模拟，检验微服务***在单故障下的应对能力和稳定性；还可以将多个故障场景联合起来进行模拟，检验微服务***在综合故障下的应对能力和稳定性。

在步骤S240，对预设监测指标在故障场景模拟前、模拟中和模拟后的实时表现数据进行分析，得到上述微服务***的稳定性评价结果。

上述预设监测指标是与微服务的功能评价具有关联的指标，例如可以是一些能够随着故障场景的发生而具有客观变化规律(可重复实现)并能够反映出微服务性能变化的指标，从而可以基于这些预设监测指标的变化来评估微服务***的稳定性。针对订单服务，对应的预设监测指标包括但不限于是：下单成功率、页面显示是否正常的状态、支付页面跳转是否正常、支付是否成功等。

在一些实施例中，基于预设的评分算法来对微服务***在故障场景模拟前、中、后的实时表现数据进行评分，各个预设监测指标对应的实时表现数据作为评分算法的输入，由评分算法输出每个故障场景模拟过程中和模拟后各个时刻下的稳定性评分。

在一些实施例中，上述评分算法主要可以根据故障重要程度、故障对业务稳态指标的破坏程度以及其他相关因素等进行评分。

上述步骤S240中，对预设监测指标在故障场景模拟前、模拟中和模拟后的实时表现数据进行分析，得到上述微服务***的稳定性评价结果，包括：对上述实时表现数据的变化规律进行分析，得到在故障场景模拟中和模拟后各故障场景对微服务***运行稳态的实时破坏程度信息；根据各故障场景的预设分配分值和上述实时破坏程度信息，确定每个故障场景下的稳定性评分；根据上述稳定性评分和各个故障场景预先分配的权重，生成上述微服务***的稳定性综合评分，上述稳定性综合评分作为上述稳定性评价结果。

微服务***运行稳态是指微服务***的业务、功能或运行处于健康和稳定的状态。随着故障场景的模拟进行，预设监测指标对应的实时表现数据的变化会呈现一定规律，例如向着变差的方向变化，考虑实时表现数据变差的情况对于微服务***的性能影响，如果影响较大，对应的实时破坏程度信息表示的破坏程度对应也较大。例如，微服务***在实现下单功能的过程中，在模拟订单微服务所依赖的支付服务功能不可用这一故障场景的过程中，对应的下单成功率、页面显示是否正常的状态、支付页面跳转是否正常、支付是否成功等指标会相应发生变化，例如支付页面跳转是否正常、支付是否成功这两个监测指标的数据会从正常跳转变化为无跳转、支付异常等状态，从而能够得到微服务***运行稳态的实时破坏程度信息。在一些实施例中，可以根据预设监测指标对稳定性的关联程度划分分值以及分值的变化趋势，关联程度越大，划分的分值越多，监测指标在故障场景发生后的变化可以是定性变化或者定量变化，针对定性变化情况，可以将分值划分为对应的等级区间；针对定量变化的情况，按照定量变化程度进行具体分值的线性调整。

在一些实施例中，相似的故障可以划分成一个大类，多个大类的故障之间可以平均分配分值，例如按照运行稳态的满分为100分，一共有4个故障大类，每个故障大类的总分为25分，表示该故障大类下微服务***稳定运行的状态；每个故障大类下面如果有多个故障，具体给每个故障划分的分值可以灵活调配，可以是平均分配或者按照不同故障的相对重要程度、实际出现频次等分配对应分值。在一些实施例中，某个故障场景的预设分配分值×(1-实时破坏程度信息(例如可以是百分比的形式))＝该故障场景下的稳定性评分。在一些实施例中，某个故障场景的预设分配分值×(1-实时破坏程度信息(例如可以是百分比的形式))×调整系数＝该故障场景下的稳定性评分；上述调整系数用于进行稳定性评分的准确度调整，可以根据模拟结果与真实发生的故障场景的表现之间的差距进行调整和优化。

在一些实施例中，根据上述稳定性评分和各个故障场景预先分配的权重，生成上述微服务***的稳定性综合评分，包括：计算各个故障场景下的稳定性评分与各自对应的权重之间的加权和，该加权和作为微服务***的稳定性综合评分。

在包含步骤S210～S240的实施例中，通过对微服务***的运行过程进行监测，得到感知拓扑信息，由于上述感知拓扑信息涵盖上述微服务***中微服务的资源调度和服务调用至少一种拓扑关系，能够自动感测出多个微服务在进行资源调度过程中的分配拓扑关系和相对优先级、微服务进行服务调用过程中的网络拓扑关系至少一种；那么根据上述感知拓扑信息构建得到的故障模拟信息进行故障场景模拟可以更加准确地模拟出微服务***在运行过程中可能出现的各种故障场景，对预设监测指标在故障场景模拟前、模拟中和模拟后的实时表现数据进行分析，得到的上述微服务***的稳定性评价结果也是更加准确和完善。上述方案实现自动化模拟故障场景并自动化评价微服务***的稳定性，评价结果更加准确，相较于采用人工手动设置测试规则和测试用例并手动进行微服务***的稳定性测试的方案而言，降低了对测试人员的技术门槛并提升了测试的自动化程度和测试结果的准确度。

图3示意性地示出了根据本公开一实施例的步骤S220的详细实施流程图。

根据本公开的实施例，参照图3所示，上述步骤S220，根据上述感知拓扑信息，构建故障模拟信息，包括以下步骤：S310和S320。

在步骤S310，根据上述感知拓扑信息和预设故障类型，确定需要进行故障模拟的目标对象。

根据本公开的实施例，上述预设故障类型包括以下故障类型中的至少一种：实例宕机、CPU满载、内存满载、磁盘占满、网络丢包、网络延时、进程阻塞、依赖服务不可用、依赖服务延时。上述预设故障类型支持配置化和定制化，用户可以通过性能评价应用的可视化界面进行故障类型的设置。

在步骤S320，针对上述目标对象，构建与上述预设故障类型对应的故障模拟内容。

针对实例宕机、CPU满载、内存满载、磁盘占满、网络丢包、网络延时、进程阻塞等故障类型，需要利用到资源调度对应的感知拓扑信息，因为需要提前确定针对哪些对象进行故障模拟和监测指标的探测。例如，在某个pod中具有一个或多个容器(每个容器用于运行一个微服务)，pod作为在集群中运行的进程，针对某个pod进行CPU故障模拟、内存故障模拟等需要用到感知到的资源调度的分配拓扑关系和相对优先级，先定位到需要模拟故障的对象，然后进行故障模拟。即，需要用到预先感知到的拓扑关系，来确定模拟故障所针对的对象(例如具体是哪个对象要进行各种故障模拟)。

针对依赖服务不可用、依赖服务延时等故障类型，需要用到服务调用对应的感知拓扑信息，因为需要提前确定针对哪些依赖服务进行服务不可用模拟或延时模拟。

在包含上述步骤S310和S320的实施例中，通过对微服务***中微服务的资源调度和服务调用至少一种拓扑关系进行感知并利用这些拓扑关系，能够相对客观且准确地定位到要进行故障模拟的目标对象，并进行对应的故障场景模拟，有效提升模拟的故障与真实故障场景的贴合程度，从而使得故障模拟中预设监测指标的实时表现数据也比较贴近真实故障场景下的反应状态，提升微服务***稳定性评价的准确度。

图4A示意性地示出了根据本公开一实施例的步骤S310和S320的实施过程示意图。

根据本公开的一种实施例，参照图4A所示，上述感知拓扑信息包含：具有调用依赖关系的第一微服务节点的节点信息，各第一微服务节点之间的调用依赖关系。第一微服务节点可以是上述微服务***中的部分微服务或全部微服务，第一微服务节点是被其他服务调用的节点、或者是调用其他服务的节点。

上述步骤S310中，根据上述感知拓扑信息和预设故障类型，确定需要进行故障模拟的目标对象，包括以下步骤S310a：在上述预设故障类型为第一故障类型的情况下，根据上述调用依赖关系和上述第一微服务节点的节点信息，确定进行故障模拟的第一目标微服务节点。上述第一故障类型包含以下至少一种：依赖服务不可用、依赖服务延时。

上述步骤S320中，针对上述目标对象，构建与上述预设故障类型对应的故障模拟内容，包括以下步骤S320a：针对上述第一目标微服务节点，构建上述第一故障类型对应的故障模拟内容。

图4B示意性地示出了根据本公开另一实施例的步骤S310和S320的实施过程示意图。

根据本公开的另一种实施例，参照图4B所示，上述感知拓扑信息包含：上述感知拓扑信息包含：上述微服务***中部署的第二微服务节点的节点信息，第二微服务节点进行资源调度的分配拓扑关系和优先级信息。第二微服务节点可以是上述微服务***中的部分微服务或全部微服务，第二微服务节点是分配了资源的运行节点，或者进行资源等待队列的节点。

上述步骤S310中，根据上述感知拓扑信息和预设故障类型，确定需要进行故障模拟的目标对象，包括以下步骤S310b-1：在上述预设故障类型为第二故障类型的情况下，根据上述第二微服务节点的节点信息和上述优先级信息，确定进行故障模拟的第二目标微服务节点；或者，包括以下步骤S310b-2：在上述预设故障类型为第二故障类型的情况下，根据上述第二微服务节点的节点信息、上述优先级信息和上述分配拓扑关系，确定进行故障模拟的第二目标微服务节点。其中上述第二故障类型包含以下至少一种：实例宕机、CPU满载、内存满载、磁盘占满、网络丢包、网络延时、进程阻塞。

上述步骤S320中，针对上述目标对象，构建与上述预设故障类型对应的故障模拟内容，包括以下步骤S320b：针对上述第二目标微服务节点，构建上述第二故障类型对应的故障模拟内容。

在一些实施场景中，微服务***中的资源调度过程是动态变化的，之前感知到的分配拓扑关系的场景(例如CPU1的T1～T2时段分配给微服务1，期间微服务3处于调度等待状态；将CPU2的T1～T3时段分配给微服务2；CPU1的T2～T4时段分配给微服务3)与当前进行故障模拟时(例如为T5时段，T5晚于T4和T3)面临的场景不同，则仅根据优先级信息作为资源调度分配的参考因素。即，根据各第二微服务节点之间进行资源调度的优先级信息和上述第二微服务节点的节点信息来确定当前进行故障模拟时的资源调度分配结果，并根据该资源调度分配结果确定进行故障模拟的第二目标微服务节点。

在另一些实施场景中，当前进行故障模拟时面临的场景就是构建的分配拓扑关系所对应的场景，则可以将上述分配拓扑关系和优先级共同作为资源调度分配的参考因素。即，根据上述分配拓扑关系、各第二微服务节点之间进行资源调度的优先级信息和上述第二微服务节点的节点信息来确定当前进行故障模拟时的资源调度分配结果，并根据该资源调度分配结果确定进行故障模拟的第二目标微服务节点。

图5示意性地示出了根据本公开另一实施例的微服务性能的评价方法的流程图。

根据本公开的实施例，上述评价方法除了包括上述步骤S210～S240之外，还包括构建预设监测指标的过程；上述构建预设监测指标包含以下步骤：S510、S520、S530和S540，为了简化示意，在图5中仅示意了步骤S510～S540。上述步骤S510～S540在步骤S240之前执行。

在步骤S510，获取上述微服务***中的各个微服务处于运行稳态下的第一历史状态数据和发生异常对应的第二历史状态数据。

上述第一历史状态数据是各个微服务真实运行过程中的状态数据，第二历史状态数据是各个微服务在应对真实故障场景发生异常对应的状态数据。

在步骤S520，根据上述第一历史状态数据和上述第二历史状态数据，确定用于表示微服务运行情况的候选监测指标。

上述候选监测指标用于作为指标配置界面中各微服务对应的指标选项。

在步骤S530，接收用户在上述指标配置界面中针对指标选项的选择信息和自定义指标信息。

在一些实施例中，为满足性能评价的个性化需求或者一些特殊测试需求，通过在指标配置界面中设置自定义指标配置功能，用户不仅能够对已经有的指标选项进行选择，还可以根据业务性能评价需求而利用自定义指标配置功能来设置自定义指标信息。

在步骤S540，根据上述选择信息和上述自定义指标信息，生成各微服务对应的预设监测指标。

在包含步骤S510～S540的实施例中，大部分的指标选项可以是由性能评价应用经过智能化分析而生成的，减少了人为设置指标所需的时间和人力成本；同时还支持用户对自定义指标的配置，提升了构建预设监测指标的智能化程度和灵活性，有助于满足各种性能测试和评价场景的需求，适用性广泛。

本公开的第二个示例性实施例提供一种微服务性能的评价装置。

图6示意性地示出了根据本公开一实施例的微服务性能的评价装置的结构框图。

参照图6所示，本公开实施例提供的微服务性能的评价装置600包括：监测模块601、构建模块602、故障模拟模块603和评价模块604。

上述监测模块601用于对微服务***的运行过程进行监测，得到感知拓扑信息；上述感知拓扑信息涵盖上述微服务***中微服务的资源调度和服务调用至少一种拓扑关系。

上述构建模块602用于根据上述感知拓扑信息，构建故障模拟信息。

上述故障模拟模块603用于根据上述故障模拟信息，在上述微服务***中进行故障场景模拟。

上述评价模块604用于对预设监测指标在故障场景模拟前、模拟中和模拟后的实时表现数据进行分析，得到上述微服务***的稳定性评价结果。

根据本公开的实施例，上述评价装置还包括：监测指标构建模块。

上述监测指标构建模块用于：获取上述微服务***中的各个微服务处于运行稳态下的第一历史状态数据和发生异常对应的第二历史状态数据；根据上述第一历史状态数据和上述第二历史状态数据，确定用于表示微服务运行情况的候选监测指标；上述候选监测指标用于作为指标配置界面中各微服务对应的指标选项；接收用户在上述指标配置界面中针对指标选项的选择信息和自定义指标信息；根据上述选择信息和上述自定义指标信息，生成各微服务对应的预设监测指标。

根据本公开的实施例，根据上述感知拓扑信息，构建故障模拟信息，包括：根据上述感知拓扑信息和预设故障类型，确定需要进行故障模拟的目标对象；针对上述目标对象，构建与上述预设故障类型对应的故障模拟内容；其中，上述故障模拟信息包含上述目标对象和上述故障模拟内容。

根据本公开的实施例，上述预设故障类型包括以下故障类型中的至少一种：实例宕机、CPU满载、内存满载、磁盘占满、网络丢包、网络延时、进程阻塞、依赖服务不可用、依赖服务延时。

根据本公开的实施例，上述感知拓扑信息包含：具有调用依赖关系的第一微服务节点的节点信息，各第一微服务节点之间的调用依赖关系。其中，根据上述感知拓扑信息和预设故障类型，确定需要进行故障模拟的目标对象，包括：在上述预设故障类型为第一故障类型的情况下，根据上述调用依赖关系和上述第一微服务节点的节点信息，确定进行故障模拟的第一目标微服务节点；上述第一故障类型包含以下至少一种：依赖服务不可用、依赖服务延时；针对上述目标对象，构建与上述预设故障类型对应的故障模拟内容，包括：针对上述第一目标微服务节点，构建上述第一故障类型对应的故障模拟内容。

根据本公开的实施例，上述感知拓扑信息包含：上述感知拓扑信息包含：上述微服务***中部署的第二微服务节点的节点信息，第二微服务节点进行资源调度的分配拓扑关系和优先级信息。其中，根据上述感知拓扑信息和预设故障类型，确定需要进行故障模拟的目标对象，包括：在上述预设故障类型为第二故障类型的情况下，根据上述第二微服务节点的节点信息和上述优先级信息，确定进行故障模拟的第二目标微服务节点；或者，根据上述第二微服务节点的节点信息、上述优先级信息和上述分配拓扑关系，确定进行故障模拟的第二目标微服务节点。其中上述第二故障类型包含以下至少一种：实例宕机、CPU满载、内存满载、磁盘占满、网络丢包、网络延时、进程阻塞。针对上述目标对象，构建与上述预设故障类型对应的故障模拟内容，包括：针对上述第二目标微服务节点，构建上述第二故障类型对应的故障模拟内容。

根据本公开的实施例，对预设监测指标在故障场景模拟前、模拟中和模拟后的实时表现数据进行分析，得到上述微服务***的稳定性评价结果，包括：对上述实时表现数据的变化规律进行分析，得到在故障场景模拟中和模拟后各故障场景对微服务***运行稳态的实时破坏程度信息；根据各故障场景的预设分配分值和上述实时破坏程度信息，确定每个故障场景下的稳定性评分；根据上述稳定性评分和各个故障场景预先分配的权重，生成上述微服务***的稳定性综合评分，上述稳定性综合评分作为上述稳定性评价结果。

本实施例更多的细节或有益效果等可以参照第一个实施例的详细描述，这里不再赘述。

上述评价装置600所包含的功能模块中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。评价装置600所包含的功能模块中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装上的***、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，评价装置600所包含的功能模块中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

本公开的第三个示例性实施例提供了一种电子设备。

图7示意性示出了本公开实施例提供的电子设备的结构框图。

参照图7所示，本公开实施例提供的电子设备700包括处理器701、通信接口702、存储器703和通信总线704，其中，处理器701、通信接口702和存储器703通过通信总线704完成相互间的通信；存储器703，用于存放计算机程序；处理器701，用于执行存储器上所存放的程序时，实现如上所述的微服务性能的评价方法。

本公开的第四个示例性实施例还提供了一种计算机可读存储介质。上述计算机可读存储介质上存储有计算机程序，上述计算机程序被处理器执行时实现如上所述的微服务性能的评价方法。

该计算机可读存储介质可以是上述实施例中描述的设备或装置中所包含的；也可以是单独存在，而未装配入该设备或装置中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。

需要说明的是，本公开实施例提供的技术方案中，所涉及的用户个人信息的采集、收集、更新、分析、处理、使用、传输、存储等方面，均符合相关法律法规的规定，被用于合法的用途，且不违背公序良俗。对用户个人信息采取必要措施，防止对用户个人信息数据的非法访问，维护用户个人信息安全、网络安全和国家安全。

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

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种微服务性能的评价方法，其特征在于，包括：

对微服务***的运行过程进行监测，得到感知拓扑信息；所述感知拓扑信息涵盖所述微服务***中微服务的资源调度和服务调用至少一种拓扑关系；

根据所述感知拓扑信息，构建故障模拟信息；

根据所述故障模拟信息，在所述微服务***中进行故障场景模拟；

对预设监测指标在故障场景模拟前、模拟中和模拟后的实时表现数据进行分析，得到所述微服务***的稳定性评价结果。

2.根据权利要求1所述的评价方法，其特征在于，根据所述感知拓扑信息，构建故障模拟信息，包括：

根据所述感知拓扑信息和预设故障类型，确定需要进行故障模拟的目标对象；

针对所述目标对象，构建与所述预设故障类型对应的故障模拟内容；

其中，所述故障模拟信息包含所述目标对象和所述故障模拟内容。

3.根据权利要求2所述的评价方法，其特征在于，所述预设故障类型包括以下故障类型中的至少一种：实例宕机、CPU满载、内存满载、磁盘占满、网络丢包、网络延时、进程阻塞、依赖服务不可用、依赖服务延时。

4.根据权利要求2所述的评价方法，其特征在于，所述感知拓扑信息包含：具有调用依赖关系的第一微服务节点的节点信息，各第一微服务节点之间的调用依赖关系；

其中，根据所述感知拓扑信息和预设故障类型，确定需要进行故障模拟的目标对象，包括：在所述预设故障类型为第一故障类型的情况下，根据所述调用依赖关系和所述第一微服务节点的节点信息，确定进行故障模拟的第一目标微服务节点；所述第一故障类型包含以下至少一种：依赖服务不可用、依赖服务延时；

针对所述目标对象，构建与所述预设故障类型对应的故障模拟内容，包括：针对所述第一目标微服务节点，构建所述第一故障类型对应的故障模拟内容。

5.根据权利要求2所述的评价方法，其特征在于，所述感知拓扑信息包含：所述微服务***中部署的第二微服务节点的节点信息，第二微服务节点进行资源调度的分配拓扑关系和优先级信息；

其中，根据所述感知拓扑信息和预设故障类型，确定需要进行故障模拟的目标对象，包括：在所述预设故障类型为第二故障类型的情况下，根据所述第二微服务节点的节点信息和所述优先级信息，确定进行故障模拟的第二目标微服务节点；或者，根据所述第二微服务节点的节点信息、所述优先级信息和所述分配拓扑关系，确定进行故障模拟的第二目标微服务节点；其中所述第二故障类型包含以下至少一种：实例宕机、CPU满载、内存满载、磁盘占满、网络丢包、网络延时、进程阻塞；

针对所述目标对象，构建与所述预设故障类型对应的故障模拟内容，包括：针对所述第二目标微服务节点，构建所述第二故障类型对应的故障模拟内容。

6.根据权利要求1所述的评价方法，其特征在于，对预设监测指标在故障场景模拟前、模拟中和模拟后的实时表现数据进行分析，得到所述微服务***的稳定性评价结果，包括：

对所述实时表现数据的变化规律进行分析，得到在故障场景模拟中和模拟后各故障场景对微服务***运行稳态的实时破坏程度信息；

根据各故障场景的预设分配分值和所述实时破坏程度信息，确定每个故障场景下的稳定性评分；

根据所述稳定性评分和各个故障场景预先分配的权重，生成所述微服务***的稳定性综合评分，所述稳定性综合评分作为所述稳定性评价结果。

7.根据权利要求1所述的评价方法，其特征在于，还包括：

获取所述微服务***中的各个微服务处于运行稳态下的第一历史状态数据和发生异常对应的第二历史状态数据；

根据所述第一历史状态数据和所述第二历史状态数据，确定用于表示微服务运行情况的候选监测指标；所述候选监测指标用于作为指标配置界面中各微服务对应的指标选项；

接收用户在所述指标配置界面中针对指标选项的选择信息和自定义指标信息；

根据所述选择信息和所述自定义指标信息，生成各微服务对应的预设监测指标。

8.一种微服务性能的评价装置，其特征在于，包括：

监测模块，用于对微服务***的运行过程进行监测，得到感知拓扑信息；所述感知拓扑信息涵盖所述微服务***中微服务的资源调度和服务调用至少一种拓扑关系；

构建模块，用于根据所述感知拓扑信息，构建故障模拟信息；

故障模拟模块，用于根据所述故障模拟信息，在所述微服务***中进行故障场景模拟；

评价模块，用于对预设监测指标在故障场景模拟前、模拟中和模拟后的实时表现数据进行分析，得到所述微服务***的稳定性评价结果。

9.一种电子设备，其特征在于，包括处理器、通信接口、存储器和通信总线，其中，处理器、通信接口和存储器通过通信总线完成相互间的通信；

存储器，用于存放计算机程序；

处理器，用于执行存储器上所存放的程序时，实现权利要求1-7中任一项所述的方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-7中任一项所述的方法。