CN117827569A - 效率瓶颈检测的方法和装置、计算机可读介质 - Google Patents

Abstract

本公开提供了一种效率瓶颈检测的方法，所述方法包括：获取微服务实例的标识和效率数据，将所述标识和效率数据对应的存储在存储记录中；根据所述存储记录产生效率日志；所述效率日志包括所述微服务实例的效率数据；根据所述效率日志，检测所述微服务系统的效率瓶颈。本公开还提供了一种效率瓶颈检测的装置、计算机可读介质。

Description

效率瓶颈检测的方法和装置、计算机可读介质

技术领域

本公开涉及微服务系统技术领域，特别涉及一种效率瓶颈检测的方法和装置、计算机可读介质。

背景技术

微服务(Micro service)系统是一种在云中部署应用和服务的技术，其将系统以组件化方式分解为多个相对独立的微服务。为响应一个用户请求(任务)，会调用多个微服务实例，其中任何微服务实例出现效率瓶颈都会影响用户请求的整体响应效率。因此，准确检测(定位)出存在效率瓶颈的微服务，对微服务系统设计、开发、优化是很重要的。

但一些相关技术中，效率瓶颈检测的方式存在实用性差、通用性差、受客户限制难以部署等问题。

发明内容

本公开提供一种效率瓶颈检测的方法和装置、计算机可读介质。

第一方面，本公开实施例提供一种效率瓶颈检测的方法，所述方法包括：

获取微服务实例的标识和效率数据，将所述标识和效率数据对应的存储在存储记录中；

根据所述存储记录产生效率日志；所述效率日志包括所述微服务实例的效率数据；

根据所述效率日志，检测所述微服务系统的效率瓶颈。

在一些实施例中，所述根据所述存储记录产生效率日志包括：从所述存储记录中选出目标任务下的微服务实例的标识和效率数据，根据所述目标任务下的微服务实例的标识和效率数据产生效率日志。

在一些实施例中，每个所述目标任务下的微服务实例包括一个响应所述目标任务的主微服务实例，以及至少一个由上级微服务实例调用的次微服务实例。

在一些实施例中，所述从所述存储记录中选出目标任务下的微服务实例的标识和效率数据，根据所述目标任务下的微服务实例的标识和效率数据产生效率日志包括：

所述目标任务的主微服务实例将自身和下属的次微服务实例确定为目标微服务实例，从所述存储记录中选出所述目标微服务实例的标识和效率数据，根据所述目标微服务实例的标识和效率数据产生效率日志。

在一些实施例中，所述效率日志中，每个所述目标任务的微服务实例的效率数据表示为一个字符串。

在一些实施例中，最下层的所述微服务实例的效率数据包括处理时间、吞吐量；

非最下层的所述微服务实例的效率数据仅包括处理时间。

在一些实施例中，所述根据所述效率日志，检测所述微服务系统的效率瓶颈包括：

对所述效率日志中的所述微服务实例的效率数据进行归一化，根据归一化的所述效率数据检测所述微服务系统的效率瓶颈。

在一些实施例中，所述效率日志为用户操作日志。

第二方面，本公开实施例提供一种效率瓶颈检测的装置，所述装置包括一个或多个存储器、一个或多个处理器；所述存储器存储有能被处理器执行的计算机程序，所述计算机程序被处理器执行时实现本公开实施例的任意一种效率瓶颈检测的方法。

第三方面，本公开实施例提供一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现本公开实施例的任意一种效率瓶颈检测的方法。

本公开实施例中，对所有微服务实例的效率数据进行统一存储，并统一产生效率日志，再根据效率日志检测效率瓶颈；由此，本公开实施例在实际商用环境中进行，面对的情况多样，覆盖面广，有效性和实用性高，可发现各种深层次的隐藏问题；而且，本公开实施例的效率数据是统一产生的，其格式标准、信息全面，易于用统一的规则进行处理，通用性好；另外，本公开实施例不需要在系统中部署监控工具，不受客户是否允许的影响。

附图说明

在本公开实施例的附图中：

图1为一种微服务系统中微服务实例调用关系的示意图；

图2为本公开实施例提供的一种效率瓶颈检测的方法的流程图；

图3为本公开实施例提供的另一种效率瓶颈检测的方法的流程图；

图4为本公开实施例提供的一种效率瓶颈检测的装置的组成框图；

图5为本公开实施例提供的一种计算机可读介质的组成框图；

图6为本公开实施例提供的一种效率瓶颈检测的方法中信息流向的示意图。

具体实施方式

为使本领域的技术人员更好地理解本公开的技术方案，下面结合附图对本公开实施例提供的效率瓶颈检测的方法和装置、计算机可读介质进行详细描述。

在下文中将参考附图更充分地描述本公开，但是所示的实施例可以以不同形式来体现，且本公开不应当被解释为限于以下阐述的实施例。反之，提供这些实施例的目的在于使本公开透彻和完整，并将使本领域技术人员充分理解本公开的范围。

本公开实施例的附图用来提供对本公开实施例的进一步理解，并且构成说明书的一部分，与详细实施例一起用于解释本公开，并不构成对本公开的限制。通过参考附图对详细实施例进行描述，以上和其它特征和优点对本领域技术人员将变得更加显而易见。

本公开可借助本公开的理想示意图而参考平面图和/或截面图进行描述。因此，可根据制造技术和/或容限来修改示例图示。

在不冲突的情况下，本公开各实施例及实施例中的各特征可相互组合。

本公开所使用的术语仅用于描述特定实施例，且不意欲限制本公开。如本公开所使用的术语“和/或”包括一个或多个相关列举条目的任何和所有组合。如本公开所使用的单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。如本公开所使用的术语“包括”、“由……制成”，指定存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其它特征、整体、步骤、操作、元件、组件和/或其群组。

除非另外限定，否则本公开所用的所有术语(包括技术和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本公开的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本公开明确如此限定。

本公开不限于附图中所示的实施例，而是包括基于制造工艺而形成的配置的修改。因此，附图中例示的区具有示意性属性，并且图中所示区的形状例示了元件的区的具体形状，但并不是旨在限制性的。

微服务系统是一种在云中部署应用和服务的技术，其将原单体系统以组件化的方式分解为多个微服务，各微服务之间相对独立。

相比单体系统架构，微服务系统架构具有高内聚、松耦合、持续交付周期短、可扩展性强等优点，故已广泛用于各种业务场景的大型软件系统设计中，例如无线通信领域的网管系统中。

不同于单体系统，微服务的嵌套调用在微服务系统中非常普遍。为响应一个用户请求(任务)，经常会产生多个微服务实例的嵌套调用，故其中任何一个微服务实例出现效率瓶颈，都会影响用户请求整体的响应效率。因此，准确检测(定位)出存在效率瓶颈的微服务，对微服务系统设计、开发、优化是很重要的。

一些相关技术中，可使用以下方式进行效率瓶颈检测。

(1)在研发过程中进行测试，如基于研发环境进行大容量测试、压力测试等。但是，研发测试中的用户数、数据量、操作频率、运维习惯、应用场景等因素都相对单一，而实际商用环境中以上各种因素都是多样的，与研发环境的差异很大，故这种检测的有效性和实用性较低，一些深层次的隐藏问题不容易被发现。

(2)在实际商用环境中，提取各微服务的系统运行日志进行分析。但一方面，系统运行日志的数据量巨大且会被定期清理，故难以保证获取到完整的数据；而且，不同的微服务可能由不同的研发团队开发，其系统运行日志的格式多样，信息零散，难以用统一的规则进行处理，导致该方式的通用性差。

(3)在实际商用环境中部署监控工具，监控系统的运行状态。但由于客户对网络安全的要求，故很多客户可能不允许监控工具的部署。

第一方面，本公开实施例提供一种效率瓶颈检测的方法。

本公开实施例用于在微服务系统的运行过程中，获取其中各微服务的运行情况并进行分析，从而检测(定位)出作为效率瓶颈而影响整体响应速度的微服务，作为后续优化、改进微服务系统的基础。

参照图1，微服务系统包括多个微服务，每个微服务可拆分出一个或多个微服务实例以供调用。而每个要运行的任务(用户请求)，其需要调用某个微服务实例，该微服务实例又可能调用其它的微服务实例，被调用的微服务实例还可能继续调用其它微服务实例，从而产生微服务实例的嵌套调用。

其中，本公开实施例可用于通信网络的网管系统。

应当理解，本公开实施例也可用于其它任何的微服务系统。

参照图2，本公开实施例的方法包括：

S101、获取微服务实例的标识和效率数据，将标识和效率数据对应的存储在存储记录中。

对当前存在的微服务实例，获取其处理效率的情况(效率数据)，并将其标识和效率数据对应的存储在存储记录中，即，存储记录中记录了各微服务实例(通过标识区分)的处理效率的情况。

应当理解，获取微服务实例的标识和效率数据的具体方式是多样的。例如，可以是所有微服务实例实时将自身的效率数据上报(当然携带标识)以供存储；也可以是定期向各微服务实例发出要求其上报数据的请求。

S102、根据存储记录产生效率日志。

其中，效率日志包括微服务实例的效率数据。

从存储记录中，选择所需的微服务实例的效率数据，产生(包括新增和更新)效率日志。

应当理解，只要能表示相应的信息就可作为相应的标识、效率数据，故存储记录、效率日志等中标识、效率数据的具体格式不一定相同。

S103、根据效率日志，检测微服务系统的效率瓶颈。

对以上效率日志中的数据进行自动分析，从而根据其中记载的微服务实例的效率情况，检测(定位)出微服务系统的效率瓶颈是哪个或哪些微服务。

本公开实施例中，对所有微服务实例的效率数据进行统一存储，并统一产生效率日志，再根据效率日志检测效率瓶颈；由此，本公开实施例在实际商用环境中进行，面对的情况多样，覆盖面广，有效性和实用性高，可发现各种深层次的隐藏问题；而且，本公开实施例的效率数据是统一产生的，其格式标准、信息全面，易于用统一的规则进行处理，通用性好；另外，本公开实施例不需要在系统中部署监控工具，不受客户是否允许的影响。

在一些实施例中，效率日志为用户操作日志。

作为本公开实施例的一种方式，以上效率日志可以就是记载现网数据的用户操作日志。

由于用户操作日志是软件系统中对用户操作进行审计的必备数据，会长期保存，且支持导出到其它结构，故以其为效率日志对现有系统的改变小，能稳定、可靠、全面的从商用环境中以常规方式获取所需数据。

应当理解，本公开实施例中效率日志的形式不限于用户操作日志，例如其也可为专门新增日志。

在一些实施例中，根据存储记录产生效率日志(S102)包括：

S1021、从存储记录中选出目标任务下的微服务实例的标识和效率数据，根据目标任务下的微服务实例的标识和效率数据产生效率日志。

作为本公开实施例的一种方式，可以是针对每个任务(目标任务)，用被其直接或间接调用的全部微服务实例的效率数据产生对应该目标任务的效率日志。

在一些实施例中，每个目标任务下的微服务实例包括一个响应目标任务的主微服务实例，以及至少一个由上级微服务实例调用的次微服务实例。

参照图1，对每个任务(目标任务)，其需要直接调用一个微服务实例，该微服务实例称为主微服务实例(如图1中的微服务A实例1)；同时，该主微服务实例还可继续调用(嵌套调用)其它的微服务实例，而这些被间接调用的微服务实例称为次微服务实例(如图1中的微服务A实例a、微服务A实例b、微服务B实例1、微服务B实例2等)。

在一些实施例中，参照图3，从存储记录中选出目标任务下的微服务实例的标识和效率数据，根据目标任务下的微服务实例的标识和效率数据产生效率日志(S1021)包括：

S10211、目标任务的主微服务实例将自身和下属的次微服务实例确定为目标微服务实例，从存储记录中选出目标微服务实例的标识和效率数据，根据目标微服务实例的标识和效率数据产生效率日志。

要针对某个目标任务产生效率日志，则需要先确认其具体对应哪些微服务实例。而由于每个目标任务对应的所有微服务实例都是由其主微服务实例调用的，故主微服务实例可很容易的确定出其对应的所有微服务实例；故作为本公开实施例的一种方式，可以是目标任务的主微服务实例从存储记录中选出主微服务实例自身和所有次微服务实例(统称为目标微服务实例)的标识和效率数据，以产生效率日志。

在一些实施例中，效率日志中，每个目标任务的微服务实例的效率数据表示为一个字符串。

作为本公开实施例的一种方式，在效率日志中，每个目标任务的微服务实例(目标微服务实例)的效率数据可用一个“字符串”形式表达，作为效率日志的一条记录，从而减少效率日志的数据量。

应当理解，以上字符串的具体形式是多样的。

在一些实施例中，最下层的微服务实例的效率数据包括处理时间、吞吐量；

非最下层的微服务实例的效率数据仅包括处理时间。

作为本公开实施例的一种方式，微服务实例的效率数据具体可包括微服务实例的处理时间(本次调用的处理时间或耗时)，以及微服务实例的吞吐量(微服务实例在单位时间内的数据处理量)。

为减少效率日志的数据量，可以是对最下层的微服务实例(即不再调用任何其它微服务实例的微服务实例)，在效率日志中记录其处理时间和吞吐量作为效率数据；而对其它的非最下层的微服务实例(即至少调用一个其它微服务实例的微服务实例)，则在效率日志中只记录其处理时间，因为非最下层的微服务实例的吞吐量可根据其下属的所有微服务实例的处理时间和吞吐量计算得到。

在一些实施例中，参照图3，根据效率日志，检测微服务系统的效率瓶颈(S103)包括：

S1031、对效率日志中的微服务实例的效率数据进行归一化，根据归一化的效率数据检测微服务系统的效率瓶颈。

对相同的微服务系统(如网管系统)，当其应用在不同的具体场景下时，其具体产生的微服务实例数、数据的具体规模等都可能有很大差距；为此，可先对直接采集到的效率数据进行归一化处理，以便后续用统一的方式对其进行自动分析。

第二方面，参照图4，本公开实施例提供一种效率瓶颈检测的装置，装置包括一个或多个存储器、一个或多个处理器；存储器存储有能被处理器执行的计算机程序，计算机程序被处理器执行时实现本公开实施例的任意一种效率瓶颈检测的方法。

第三方面，参照图5，本公开实施例提供一种计算机可读介质，其上存储有计算机程序，计算机程序被处理器执行时实现本公开实施例的任意一种效率瓶颈检测的方法。

其中，处理器为具有数据处理能力的器件，其包括但不限于中央处理器(CPU)等；存储器为具有数据存储能力的器件，其包括但不限于随机存取存储器(RAM，更具体如SDRAM、DDR等)、只读存储器(ROM)、带电可擦可编程只读存储器(EEPROM)、闪存(FLASH)；I/O接口(读写接口)连接在处理器与存储器间，能实现存储器与处理器的信息交互，其包括但不限于数据总线(Bus)等。

示例性的，本公开实施例的一种效率瓶颈检测的过程可在参照图6的环境进行。

参照图6，本公开实施例用于通信网络的网管系统，网管系统可运行GUI(Graphical User Interface，图形化用户界面)界面服务，以及包括微服务A、微服务B在内的多个微服务；同时，网管系统还可运行存储服务、日志管理服务，并与外界的效率评估工具通信连接。

其中，GUI界面服务为网管系统的界面服务，用户可通过GUI界面服务进行通信网络的运维操作，如发出某个任务(用户请求),例如是任务a。

微服务A和微服务B是任务a需要调用的两个微服务(当然不同任务具体调用的微服务不同)，其中微服务A是响应任务a的主服务的，微服务B则用于向上级微服务提供接口，其中的每一个微服务都可拆分出多个微服务实例，而微服务实例还可调用其它的微服务实例。

例如，参照图1，用户通过GUI界面服务发出任务a到微服务A实例a，微服务A实例a拆分任务后，将子任务发给微服务A实例1和微服务A实例2；而微服务A实例1和微服务A实例2再分别调用微服务B实例1和微服务B实例2，微服务B的实例还可继续调用微服务B的实例。

由此，形成了参照图1的“调用树”，调用树是一个多叉树结构，其中每个微服务实例也可视为一个“节点”，如微服务A实例a为根节点，而最下层的两个微服务B实例1和微服务B实例2则为叶子节点。

上级微服务实例调用下级微服务实例时，可按照调用关系，用每层微服务实例的编号对每个微服务实例(节点)进行标识。例如，参照图1，微服务A实例a的标识为a；则下一级微服务A实例1和微服务A实例2的标识分别为a,1和a,2；再下一级的两个微服务B实例1和微服务B实例2的标识分别为a,1,1和a,2,2；而微服务B实例1下的微服务B实例1和微服务B实例2的标识分别为a,1,1,1和a,1,1,2，微服务B实例2下的微服务B实例1和微服务B实例2的标识分别为a,2,2,1和a,2,2,2。

存储服务用于存储每个微服务实例的标识和对应的效率数据，效率数据包括处理时间和吞吐量。

例如,存储服务可为Redis(Remote Dictionary Server，远程字典服务)，Redis是一个开源的日志型、高性能的Key-Value(键-值)数据库，用于存储所有微服务的处理效率数据。

日志管理服务用于实现用户操作日志(效率日志)的入库、存储、查询，以及用于将效率日志作为现网数据输出至效率评估工具。

效率评估工具位于网管系统之外，其对基准数据(研发版本测试后输出的理论数据)和效率日志的现网数据(商用环境中网管系统的实际运行数据)进行对比分析，以检测(定位)出存在效率瓶颈的微服务。

示例性的，本公开实施例的效率瓶颈检测的方法可包括：

A101、用户通过GUI界面服务发起任务a。

例如，任务a可为“批量修改小区参数”任务，故用户可通过导出和导入一个Excel文件进行批量数据修改。

A102、参照图1，响应任务a，微服务A实例a(主微服务实例)调用多个其它的微服务实例(次微服务实例)。

例如，对以上“批量修改小区参数”任务，微服务A为模板微服务，而微服务B为规划区微服务。

A103、所有微服务实例记录各自处理该任务的处理效率的相关数据，将自身的标识和效率数据上报到存储服务，由存储服务将其存储为存储记录。

示例性的，存储记录的具体形式可如下表：

其中，对最下层的微服务实例(叶子节点)a,1,1,1、a,1,1,2、a,2,2,1、a,2,2,2，记录其处理时间和吞吐量作为效率数据；而对其它微服务实例(非叶子节点)，只记录其处理时间，因为如上表，它们的吞吐量可根据其下属的所有微服务实例的处理时间和吞吐量计算得到。

例如，对以上“批量修改小区参数”任务，可以是每个微服务将自身的标识和效率数据上报到Redis。其中，吞吐量可为单位时间(1秒)内处理的MO(Managed Object，被管理对象)的个数(mo/s)，而处理时间数据的精度为0.1秒，故其以单位0.1秒记录，以避免出现小数。

A104、微服务A实例a(主微服务实例)从存储服务中读取其任务相关的存储记录的内容，汇总为一串字符串，写入日志管理服务形成效率日志。

应当理解，以上字符串的具体形式是多样的。

例如，可以是每个微服务实例的标识在前，其后为其效率数据，而不同微服务实例的数据间通过分号分开；从而微服务A实例a导出的字符串的形式可如下：

a:t(a)；1:t(a,1)；2:t(a,2)；1,1:t(a,1,1)；2,2:t(a,2,2)；1,1,1:t(a,1,1,1),Tpt1；1,1,2:t(a,1,1,2),Tpt2；2,2,1:t(a,2,2,1),Tpt3；2,2,2:t(a,2,2,2),Tpt4

例如，对以上“批量修改小区参数”任务，可以是模板微服务实例a从Redis中读取数据，将“批量修改小区参数”任务的所有效率数据进行汇总，整合为如下的字符串：

a:300；1:169；2:108；1,1:65；2,3:80；1,1,1:12,18；1,1,2:22,13；2,3,3:66,9；2,3,4:42,23。

应当理解，其它所有主微服务实例也都会以任务为粒度，汇总各自的数据。

A105、从日志管理服务中获取效率日志，导入效率评估工具。

评估工具通过解析效率日志中的字符串，可还原出本次任务的整个调用链的处理时间、吞吐量，以及每个链节点的处理时间、吞吐量，也就是得到上表中最后一列“微服务实例的处理效率的相关数据”的实际内容。

A106、效率评估工具对日志数据进行归一化处理，即，将不同管理规模、不同操作场景的处理效率数据标准化。

效率评估工具之所以要进行归一化处理的原因如下：

(1)网管系统的管理规模在不同局点不一样，如大的局点管理规模可能有10万甚至20万小区，而小的局点管理规模可能只有1万甚至5千小区。

(2)同一个场景任务的微服务的调用关系是固定的，但在不同管理规模下，同一场景任务横向拆分的微服务实例数可能相差很大；而同一个场景任务一次批量操作的对象数不同时，横向拆分的微服务实例数也可能相差很大。

例如，以“批量修改小区参数”的任务为例，在10万规模的UME网管下修改100个网元的配置数据，和在1万规模的UME网管下修改修改50个网元的配置数据，系统在处理时拆分的微服务实例数是不同的，故同样是针对“批量修改小区参数”的任务，在不同环境中产生的效率数据通常无法直接比较。

由此，通过对数据的归一化处理，则可使网管系统的管理规模、一次操作处理的网元个数等都不会影响数据的比较。

例如，归一化的方法具体可包括：

A1061、计算每个微服务实例的吞吐量。

例如，对以上“批量修改小区参数”任务，本步骤可为计算上表中每个节点的吞吐量，因除了叶子节点，其它节点的吞吐量未直接记录。

A1062、对每一层级同类型的微服务实例的吞吐量相加后求平均。

例如，对“批量修改小区参数”任务，本步骤可计算得到模板微服务实例第一层(以最上层为第一层)的平均吞吐量为：6.9mo/s；模板微服务实例第二层的平均吞吐量为：(3+14.4)/2＝8.7mo/s；规划区微服务实例第三层的平均吞吐量为：(7.7+19.5)/2＝13.6mo/s；规划区微服务实例第四层的平均吞吐量为：(21.6+28.6+59.4+96.6)/＝51.6mo/s。

应当理解，归一化的具体方式不限于此。

A107、对标准化之后的数据进行比较，定位出存在效率瓶颈的微服务。

对归一化后的数据，每一层的微服务实例就对应有一个平均吞吐量数值(现网数据)；而针对每个场景任务，比较以上得到的现网数据的平均吞吐量数值和基准数据的平均吞吐量数值，当现网数据比基准数据超出一定数值(如10％)时，就认为相应的微服务在这一层级的调用关系中出现了效率问瓶颈。

例如，对以上“批量修改小区参数”任务，其基准数据的平均吞吐量可如下：

模板微服务实例第一层：6mo/s；

模板微服务实例第二层：8mo/s；

规划区微服务实例第三层：10mo/s；

规划区微服务实例第四层：50mo/s。

由此可见，规划区微服务实例第三层的现网数据为13.6mo/s，比基准数据10超出3.6mo/s，超出比例大于10％，因此，可判定规划区微服务在被模板微服务调用时可能存在效率问题，相关的代码模块需要分析和优化。

本领域普通技术人员可以理解，上文中所公开的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。

在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。

某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器(CPU)、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其它数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于随机存取存储器(RAM，更具体如SDRAM、DDR等)、只读存储器(ROM)、带电可擦可编程只读存储器(EEPROM)、闪存(FLASH)或其它磁盘存储器；只读光盘(CD-ROM)、数字多功能盘(DVD)或其它光盘存储器；磁盒、磁带、磁盘存储或其它磁存储器；可以用于存储期望的信息并且可以被计算机访问的任何其它的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其它传输机制之类的调制数据信号中的其它数据，并且可包括任何信息递送介质。

本公开已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施例相结合描述的特征、特性和/或元素，或可与其它实施例相结合描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本公开的范围的情况下，可进行各种形式和细节上的改变。

Claims (10)

1.一种效率瓶颈检测的方法，所述方法包括：

获取微服务实例的标识和效率数据，将所述标识和效率数据对应的存储在存储记录中；

根据所述存储记录产生效率日志；所述效率日志包括所述微服务实例的效率数据；

根据所述效率日志，检测所述微服务系统的效率瓶颈。

2.根据权利要求1所述的方法，其中，

所述根据所述存储记录产生效率日志包括：从所述存储记录中选出目标任务下的微服务实例的标识和效率数据，根据所述目标任务下的微服务实例的标识和效率数据产生效率日志。

3.根据权利要求2所述的方法，其中，

每个所述目标任务下的微服务实例包括一个响应所述目标任务的主微服务实例，以及至少一个由上级微服务实例调用的次微服务实例。

4.根据权利要求3所述的方法，其中，所述从所述存储记录中选出目标任务下的微服务实例的标识和效率数据，根据所述目标任务下的微服务实例的标识和效率数据产生效率日志包括：

所述目标任务的主微服务实例将自身和下属的次微服务实例确定为目标微服务实例，从所述存储记录中选出所述目标微服务实例的标识和效率数据，根据所述目标微服务实例的标识和效率数据产生效率日志。

5.根据权利要求4所述的方法，其中，

所述效率日志中，每个所述目标任务的微服务实例的效率数据表示为一个字符串。

6.根据权利要求4所述的方法，其中，

最下层的所述微服务实例的效率数据包括处理时间、吞吐量；

非最下层的所述微服务实例的效率数据仅包括处理时间。

7.根据权利要求1所述的方法，其中，所述根据所述效率日志，检测所述微服务系统的效率瓶颈包括：

对所述效率日志中的所述微服务实例的效率数据进行归一化，根据归一化的所述效率数据检测所述微服务系统的效率瓶颈。

8.根据权利要求1所述的方法，其中，

所述效率日志为用户。

9.一种效率瓶颈检测的装置，所述装置包括一个或多个存储器、一个或多个处理器；所述存储器存储有能被处理器执行的计算机程序，所述计算机程序被处理器执行时实现权利要求1至8中任意一项所述的效率瓶颈检测的方法。

10.一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1至8中任意一项所述的效率瓶颈检测的方法。