CN110688277A - 用于微服务框架的数据监控方法及装置 - Google Patents

Abstract

本申请公开了一种用于微服务框架的数据监控方法及装置，用于对模块调用数据的存储结果进行监控。该方法包括：监控微服务框架中的业务模块调用接口是否能正常使用；如果所述微服务框架中的业务模块调用接口不能正常使用，则采用链路数据追踪方法查询所述业务模块调用接口对应的模调链路统计数据；采用链路数据分析方法，根据所述模调链路统计数据分析确定出不能正常使用的所述业务模块调用接口对应的业务模块。本申请解决了相关技术中用于微服务框架的数据监控方法监控难度较高的技术问题。通过本申请，达到了精准快速定位链路故障的目的，从而实现了降低微服务框架的数据监控难度的技术效果。

Description

用于微服务框架的数据监控方法及装置

技术领域

本申请涉及微服务技术领域，具体而言，涉及一种用于微服务框架的数据监控方法及装置。

背景技术

在微服务技术领域，很多复杂的业务功能通常需要很多个服务协同才能完成，如果链路上的任何一个服务出现问题，都会导致功能接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。日志作为记录链路信息的必备手段，它具有写多读少、每条数据都有日期属性、且需要海量存储等特性，很适合使用时序数据库进行数据存储，Influxdb和Cassandra都是不错的选择。但是，Influxdb集群版是闭源式的，在遇到海量数据分布式存储的时候，开源的Cassandra明显更加容易把控一些。

发明人发现，尽管相关技术中出现了Zipkin、Skywalking等优秀的APM(应用性能管理)开源组件，也有收费的OneAPM，比较流行的ELK也增加了APM功能模块，但没有一款是为PHP(超文本预处理器)量身打造的。由于公司主要业务都是使用基于PHP的swoole扩展的RPC微服务架构，特定的通信协议和系统架构很难适用上述的APM组件，导致微服务架构下数据监控的难度加大。

针对相关技术中的用于微服务框架的数据监控方法监控难度较高的问题，目前尚未提出有效的解决方案。

发明内容

本申请的主要目的在于提供一种用于微服务框架的数据监控方法及装置，以解决相关技术中的用于微服务框架的数据监控方法监控难度较高的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种用于微服务框架的数据监控方法，用于对模块调用数据的存储结果进行监控。

根据本申请的用于微服务框架的数据监控方法包括：监控微服务框架中的业务模块调用接口是否能正常使用；如果所述微服务框架中的业务模块调用接口不能正常使用，则采用链路数据追踪方法查询所述业务模块调用接口对应的模调链路统计数据；采用链路数据分析方法，根据所述模调链路统计数据分析确定出不能正常使用的所述业务模块调用接口对应的业务模块。

进一步地，所述监控微服务框架中的业务模块调用接口是否能正常使用之前包括：获取业务模块调用接口ID信息；基于所述业务模块调用接口ID信息确定业务模块调用接口调用的业务模块ID信息；基于所述业务模块调用接口ID信息和所述业务模块ID信息，按照预设规则构建链路数据拓扑图，用以追踪链路数据。

进一步地，所述监控微服务框架中的业务模块调用接口是否能正常使用包括：获取业务模块ID信息；基于所述业务模块ID信息，对所述业务模块的调用成功率进行统计；根据统计结果判断是否调整所述业务模块的调用次数。

进一步地，所述监控微服务框架中的业务模块调用接口是否能正常使用之后包括：获取不能正常使用的业务模块调用接口ID信息；根据不能正常使用的所述业务模块调用接口ID信息，向客户端发送告警信息。

进一步地，所述监控微服务框架中的业务模块调用接口是否能正常使用之后包括：确定无法正常使用的业务模块调用接口ID信息和/或业务模块ID信息；基于所述业务模块调用接口ID信息和/或所述业务模块ID信息发送告警请求；基于所述告警请求判断告警请求的次数是否达到预设阈值；根据判断结果确定是否向客户端发送告警信息。

为了实现上述目的，根据本申请的另一方面，提供了一种用于微服务框架的数据监控装置，用于对模块调用数据的存储结果进行监控。

根据本申请的用于微服务框架的数据监控装置包括：监控模块，用于监控微服务框架中的业务模块调用接口是否能正常使用；查询模块，用于如果所述微服务框架中的业务模块调用接口不能正常使用，则采用链路数据追踪方法查询所述业务模块调用接口对应的模调链路统计数据；分析模块，用于采用链路数据分析方法，根据所述模调链路统计数据分析确定出不能正常使用的所述业务模块调用接口对应的业务模块。

进一步地，所述装置还包括：第一获取模块，用于获取业务模块调用接口ID信息；第一确定模块，用于基于所述业务模块调用接口ID信息确定业务模块调用接口调用的业务模块ID信息；构建模块，用于基于所述业务模块调用接口ID信息和所述业务模块ID信息，按照预设规则构建链路数据拓扑图，用以追踪链路数据。

进一步地，所述监控模块包括：获取单元，用于获取业务模块ID信息；统计单元，用于基于所述业务模块ID信息，对所述业务模块的调用成功率进行统计；判断单元，用于根据统计结果判断是否调整所述业务模块的调用次数。

进一步地，所述装置还包括：第二获取模块，用于获取不能正常使用的业务模块调用接口ID信息；第一发送模块，用于根据不能正常使用的所述业务模块调用接口ID信息，向客户端发送告警信息。

进一步地，所述装置还包括：第二确定模块，用于确定无法正常使用的业务模块调用接口ID信息和/或业务模块ID信息；第二发送模块，用于基于所述业务模块调用接口ID信息和/或所述业务模块ID信息发送告警请求；判断模块，用于基于所述告警请求判断告警请求的次数是否达到预设阈值；第三确定模块，用于根据判断结果确定是否向客户端发送告警信息。

在本申请实施例中，采用监控微服务框架中的业务模块调用接口是否能正常使用的方式，如果所述微服务框架中的业务模块调用接口不能正常使用，则采用链路数据追踪方法查询所述业务模块调用接口对应的模调链路统计数据；采用链路数据分析方法，根据所述模调链路统计数据分析确定出不能正常使用的所述业务模块调用接口对应的业务模块，达到了精准快速定位链路故障的目的，从而实现了提高微服务框架的数据监控效率的技术效果，进而解决了用于微服务框架的数据监控方法监控难度较高的技术问题。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请第一实施例的用于微服务框架的数据监控方法的流程示意图；

图2是根据本申请第二实施例的用于微服务框架的数据监控方法的流程示意图；

图3是根据本申请第三实施例的用于微服务框架的数据监控方法的流程示意图；

图4是根据本申请第四实施例的用于微服务框架的数据监控方法的流程示意图；

图5是根据本申请第五实施例的用于微服务框架的数据监控方法的流程示意图；

图6是根据本申请第一实施例的用于微服务框架的数据监控装置的组成结构示意图；

图7是根据本申请第二实施例的用于微服务框架的数据监控装置的组成结构示意图；

图8是根据本申请第三实施例的用于微服务框架的数据监控装置的组成结构示意图；

图9是根据本申请第四实施例的用于微服务框架的数据监控装置的组成结构示意图；以及

图10是根据本申请第五实施例的用于微服务框架的数据监控装置的组成结构示意图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

根据本发明实施例，提供了一种用于微服务框架的数据监控方法，用于对模块调用数据的存储结果进行监控，如图1所示，该方法包括如下的步骤S101至步骤S103：

步骤S101，监控微服务框架中的业务模块调用接口是否能正常使用。

具体实施时，传统的web应用程序中，最容易出现性能问题的一般都是各种IO操作，比如连接数据库、访问外部缓存、读写磁盘、对外发送HTTP请求等。因此首先需要监控业务模块调用接口的使用状态是否正常，以及时定位故障，保证业务模块的正常调用。

步骤S102，如果所述微服务框架中的业务模块调用接口不能正常使用，则采用链路数据追踪方法查询所述业务模块调用接口对应的模调链路统计数据。

具体实施时，如果监控到微服务框架中的一个或多个业务模块调用接口无法正常使用，可以采用链路数据追踪的方法获取无法正常使用的业务模块调用接口对应的模调链路统计数据。上述链路数据追踪方法主要包括以下步骤：采集模块调用数据的日志数据，其中包含“接口ID”信息，该信息代表了同一个外部接口调用的会话标识。根据该接口ID信息，可以查询出该接口会话一共调用了哪些功能模块；然后，通过日志数据中的“模块ID”和“父模块ID”等信息，可以统计出模块之间的调用先后顺序和依赖关系；然后，通过日志数据中的“模调执行时长”可以统计出整个会话中最耗时的一些功能模块。通过这些分析出来的数据，就可以为每一次接口会话绘制出一个完整的链路拓扑图出来，从而直观的看出一个接口会话链路中存在的性能问题。

步骤S103，采用链路数据分析方法，根据所述模调链路统计数据分析确定出不能正常使用的所述业务模块调用接口对应的业务模块。

具体实施时，在基于链路数据追踪方法得到无法正常使用的业务模块调用接口对应的模调链路统计数据后，进一步通过链路数据分析方法对上述数据进行分析，以确定出不能正常使用的所述业务模块调用接口对应的业务模块。即一旦监控到线上某个调用接口不可用，可以根据该接口对应的“接口ID”，使用链路数据追踪方法快速查询该接口对应的模调链路统计数据，通过链路数据分析方法，对比找出该接口出现问题的链路，进而精确定位到出现问题的某个业务模块。

优选地，上述链路数据分析方法，通过将链路调用的日志数据存储起来以后，可以从多个维度进行数据统计分析。以业务模块ID为基础，按天聚合数据。按天聚合的最小统计时间单位为分钟，也就是说一个业务模块一天会统计出1440条数据。每条数据包括的信息有：总调用次数、调用成功次数、调用失败次数、最大响应时间、最小响应时间、平均响应时间、主调用IP分布、被调用IP分布等信息。并在模调中心的web界面上提供多日期数据曲线对比功能，可以直观看出每天业务模块调用量的分布情况，以及通过对比看出某一天的某个时段的数据是否存在异常。

作为本申请实施例的一种优选实施方式，如图2所示，所述监控微服务框架中的业务模块调用接口是否能正常使用之前包括如下的步骤S201至步骤S203：

步骤S201，获取业务模块调用接口ID信息。

具体实施时，在监控微服务框架中的业务模块调用接口是否能正常使用之前，需要构建链路数据追踪方法以追踪链路数据，及时定位故障节点，首先需要获取业务模块调用接口ID信息。

步骤S202，基于所述业务模块调用接口ID信息确定业务模块调用接口调用的业务模块ID信息。

具体实施时，上述接口ID信息代表了同一个外部接口调用的会话标识，根据该接口ID信息，可以查询出该接口会话一共调用了哪些功能模块，进而可以确定该接口ID信息对应的业务模块ID信息。

步骤S203，基于所述业务模块调用接口ID信息和所述业务模块ID信息，按照预设规则构建链路数据拓扑图，用以追踪链路数据。

具体实施时，通过日志数据中的“模块ID”和“父模块ID”等信息，可以统计出模块之间的调用先后顺序和依赖关系；然后，通过日志数据中的“模调执行时长”可以统计出整个会话中最耗时的一些功能模块，通过这些分析出来的数据，就可以为每一次接口会话构建出一个完整的链路拓扑图出来，从而直观的看出一个接口会话链路中存在的性能问题。此外，由于单次接口会话可能并不具备代表性，可以按接口ID做聚合，把同一个接口多次会话的数据取平均值，然后绘制一个链路拓扑图，以此作为接口性能分析的依据。优选地，可以使用图形绘制的js库mxGraph进行调用链路拓扑图的绘制，然后在html页面上进行展示。

作为本申请实施例的一种优选实施方式，如图3所示，所述监控微服务框架中的业务模块调用接口是否能正常使用包括如下的步骤S301至步骤S303：

步骤S301，获取业务模块ID信息。

具体实施时，需要对各个业务模块的服务能力进行评估，以提高业务模块调用的效率，提高用户的体验，因此首先需要获取各个业务模块的ID信息，作为分析每个业务模块服务能力的基本单位。

步骤S302，基于所述业务模块ID信息，对所述业务模块的调用成功率进行统计。

具体实施时，基于上述业务模块ID信息，对接口会话的各个模块的调用成功率进行统计，同时结合服务端设置的高可用等级的要求，评估每个业务模块的服务能力。

步骤S303，根据统计结果判断是否调整所述业务模块的调用次数。

具体实施时，如果统计出某个业务模块的调用成功率未达到预设阈值，则可以通过调整该业务模块的调用次数以使其调用成功率达到要求，比如，服务端要求每个功能模块的调用成功率必须在99.99％以上，而业务模块A的调用成功率仅为90％，这样就可以通过不断调整该业务模块A的调用次数N，以达到调用成功率在99.99％以上的标准。上述预设阈值N就可以作为评估某个业务模块服务能力的容量值。

作为本申请实施例的一种优选实施方式，如图4所示，所述监控微服务框架中的业务模块调用接口是否能正常使用之后包括如下的步骤S401至步骤S402：

步骤S401，获取不能正常使用的业务模块调用接口ID信息。

具体实施时，当监控到微服务框架中存在无法正常使用的业务模块调用接口后，需要进一步获取该无法正常使用的业务模块调用接口的ID信息。

步骤S402，根据不能正常使用的所述业务模块调用接口ID信息，向客户端发送告警信息。

具体实施时，基于不能正常使用的业务模块调用接口ID信息向客户端发送告警信息，以使客户端及时采取措施对不能正常使用的业务模块调用接口进行处理。

作为本申请实施例的一种优选实施方式，如图5所示，所述监控微服务框架中的业务模块调用接口是否能正常使用之后包括如下的步骤S501至步骤S504：

步骤S501，确定无法正常使用的业务模块调用接口ID信息和/或业务模块ID信息。

具体实施时，当监控到微服务框架中存在无法正常使用的业务模块调用接口后，需要进一步确定无法正常使用的业务模块调用接口的ID信息或业务模块ID信息。

步骤S502，基于所述业务模块调用接口ID信息和/或所述业务模块ID信息发送告警请求。

具体实施时，基于不能正常使用的业务模块调用接口ID信息或业务模块ID信息发起告警请求。

步骤S503，基于所述告警请求判断告警请求的次数是否达到预设阈值。

具体实施时，使用者可以在监控设置页面配置告警通知的最大次数，以及告警频率，并提供告警反馈接口。使用者一旦收到告警通知，并及时准备处理时，可以通过操作告警反馈接口通知监控程序立即停止告警。也即在模调中心的监控设置页面，可以为每一个业务模块和接口设置告警阈值，同时设置需要通知的客户端，通过判断告警请求的次数是否达到告警阈值，以避免警告通知对客户端的频繁骚扰。

步骤S504，根据判断结果确定是否向客户端发送告警信息。

具体实施时，可以启动一个常驻进程，对模调日志数据进行准实时的离线分析，如果发现某个业务模块触发了它的告警阈值，就可以立即通过企业微信、短信、或者APP推送消息等方式，第一时间通知到相应的客户端。如果某个业务模块的告警请求次数未达到告警阈值，则向客户端正常发送告警信息，以使客户端及时处理发送故障的接口或业务模块。

从以上的描述中，可以看出，本发明实现了如下技术效果：1)故障定位更快速：很多线上环境问题的触发条件较为隐蔽，结合本申请实施例中的链路监控和故障分析定位方法，可以快速定位故障节点。2)服务能力评估更精准：本申请实施例中的服务能力评估方法，可以有效评估业务系统服务的可用性，并可以将评估结果作为相应的服务扩容的参考。3)链路追踪更全面：使用本申请实施例的链路追踪方法，可以精确追踪每一个接口会话的功能节点的调用情况，并可以使用直观的图形方式进行链路展示。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

根据本发明实施例，还提供了一种用于实施上述用于微服务框架的数据监控方法的装置，，用于对模块调用数据的存储结果进行监控，如图6所示，该装置包括：监控模块1、查询模块2及分析模块3。

本申请实施例的监控模块1，用于监控微服务框架中的业务模块调用接口是否能正常使用。

具体实施时，传统的web应用程序中，最容易出现性能问题的一般都是各种IO操作，比如连接数据库、访问外部缓存、读写磁盘、对外发送HTTP请求等。因此首先监控模块需要监控业务模块调用接口的使用状态是否正常，以及时定位故障，保证业务模块的正常调用。

本申请实施例的查询模块2，用于如果所述微服务框架中的业务模块调用接口不能正常使用，则采用链路数据追踪方法查询所述业务模块调用接口对应的模调链路统计数据。

具体实施时，如果监控到微服务框架中的一个或多个业务模块调用接口无法正常使用，可以采用链路数据追踪的方法通过查询模块获取无法正常使用的业务模块调用接口对应的模调链路统计数据。

本申请实施例的分析模块3，用于采用链路数据分析方法，根据所述模调链路统计数据分析确定出不能正常使用的所述业务模块调用接口对应的业务模块。

具体实施时，在基于链路数据追踪方法得到无法正常使用的业务模块调用接口对应的模调链路统计数据后，分析模块通过链路数据分析方法对上述数据进行分析，以确定出不能正常使用的所述业务模块调用接口对应的业务模块。即一旦监控到线上某个调用接口不可用，可以根据该接口对应的“接口ID”，使用链路数据追踪方法快速查询该接口对应的模调链路统计数据，通过链路数据分析方法，对比找出该接口出现问题的链路，进而精确定位到出现问题的某个业务模块。

作为本申请实施例的一种优选实施方式，如图7所示，所述装置还包括：第一获取模块4、第一确定模块5及构建模块6。

本申请实施例的第一获取模块4，用于获取业务模块调用接口ID信息。

具体实施时，在监控微服务框架中的业务模块调用接口是否能正常使用之前，需要构建链路数据追踪方法以追踪链路数据，及时定位故障节点，首先需要通过第一获取模块获取业务模块调用接口ID信息。

本申请实施例的第一确定模块5，用于基于所述业务模块调用接口ID信息确定业务模块调用接口调用的业务模块ID信息。

具体实施时，上述接口ID信息代表了同一个外部接口调用的会话标识，根据该接口ID信息，可以通过第一确定模块查询出该接口会话一共调用了哪些功能模块，进而可以确定该接口ID信息对应的业务模块ID信息。

本申请实施例的构建模块6，用于基于所述业务模块调用接口ID信息和所述业务模块ID信息，按照预设规则构建链路数据拓扑图，用以追踪链路数据。

具体实施时，构建模块通过日志数据中的“模块ID”和“父模块ID”等信息，可以统计出模块之间的调用先后顺序和依赖关系；然后，通过日志数据中的“模调执行时长”可以统计出整个会话中最耗时的一些功能模块，通过这些分析出来的数据，就可以为每一次接口会话构建出一个完整的链路拓扑图出来，从而直观的看出一个接口会话链路中存在的性能问题。此外，由于单次接口会话可能并不具备代表性，可以按接口ID做聚合，把同一个接口多次会话的数据取平均值，然后绘制一个链路拓扑图，以此作为接口性能分析的依据。优选地，可以使用图形绘制的js库mxGraph进行调用链路拓扑图的绘制，然后在html页面上进行展示。

作为本申请实施例的一种优选实施方式，如图8所示，所述监控模块1包括：获取单元11、统计单元12及判断单元13。

本申请实施例的获取单元11，用于获取业务模块ID信息。

具体实施时，需要对各个业务模块的服务能力进行评估，以提高业务模块调用的效率，提高用户的体验，因此首先需要通过获取单元获取各个业务模块的ID信息。

本申请实施例的统计单元12，用于基于所述业务模块ID信息，对所述业务模块的调用成功率进行统计。

具体实施时，基于上述业务模块ID信息，通过统计单元对接口会话的各个模块的调用成功率进行统计，同时结合服务端设置的高可用等级的要求，评估某个业务模块的服务能力。

本申请实施例的判断单元13，用于根据统计结果判断是否调整所述业务模块的调用次数。

具体实施时，如果统计出某个业务模块的调用成功率未达到预设阈值，则判断单元可以通过调整该业务模块的调用次数以使其调用成功率达到要求，比如，服务端要求每个功能模块的调用成功率必须在99.99％以上，而业务模块A的调用成功率仅为90％，这样就可以通过不断调整该业务模块A的调用次数N，以达到调用成功率在99.99％以上的标准。上述预设阈值N就可以作为评估某个业务模块服务能力的容量值。

作为本申请实施例的一种优选实施方式，如图9所示，所述装置还包括：第二获取模块7及发送模块8。

本申请实施例的第二获取模块7，用于获取不能正常使用的业务模块调用接口ID信息。

具体实施时，当监控到微服务框架中存在无法正常使用的业务模块调用接口后，需要进一步通过第二获取模块获取该无法正常使用的业务模块调用接口的ID信息。

本申请实施例的发送模块8，用于根据不能正常使用的所述业务模块调用接口ID信息，向客户端发送告警信息。

具体实施时，基于不能正常使用的业务模块调用接口ID信息通过发送模块向客户端发送告警信息，以使客户端及时采取措施对不能正常使用的业务模块调用接口进行处理。

作为本申请实施例的一种优选实施方式，如图10所示，所述装置还包括：第二确定模块9、第二发送模块10、判断模块11及第三确定模块12。

本申请实施例的第二确定模块9，用于确定无法正常使用的业务模块调用接口ID信息和/或业务模块ID信息。

具体实施时，当监控到微服务框架中存在无法正常使用的业务模块调用接口后，需要通过第二确定模块进一步确定无法正常使用的业务模块调用接口的ID信息或业务模块ID信息。

本申请实施例的第二发送模块10，用于基于所述业务模块调用接口ID信息和/或所述业务模块ID信息发送告警请求。

具体实施时，第二发送模块基于不能正常使用的业务模块调用接口ID信息或业务模块ID信息发起告警请求。

本申请实施例的判断模块11，用于基于所述告警请求判断告警请求的次数是否达到预设阈值。

具体实施时，使用者可以在监控设置页面配置告警通知的最大次数，以及告警频率，并提供告警反馈接口。使用者一旦收到告警通知，并及时准备处理时，可以通过操作告警反馈接口通知监控程序立即停止告警。也即在模调中心的监控设置页面，可以为每一个业务模块和接口设置告警阈值，同时设置需要通知的客户端，判断模块通过判断告警请求的次数是否达到告警阈值，以避免警告通知对客户端的频繁骚扰。

本申请实施例的第三确定模块12，用于根据判断结果确定是否向客户端发送告警信息。

具体实施时，可以启动一个常驻进程，对模调日志数据进行准实时的离线分析，第三确定模块如果发现某个业务模块触发了它的告警阈值，就可以立即通过企业微信、短信、或者APP推送消息等方式，第一时间通知到相应的客户端。如果某个业务模块的告警请求次数未达到告警阈值，则向客户端正常发送告警信息，以使客户端及时处理发送故障的接口或业务模块。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种用于微服务框架的数据监控方法，其特征在于，用于对模块调用数据的存储结果进行监控，所述方法包括：

监控微服务框架中的业务模块调用接口是否能正常使用；

如果所述微服务框架中的业务模块调用接口不能正常使用，则采用链路数据追踪方法查询所述业务模块调用接口对应的模调链路统计数据；

采用链路数据分析方法，根据所述模调链路统计数据分析确定出不能正常使用的所述业务模块调用接口对应的业务模块。

2.根据权利要求1所述的用于微服务框架的数据监控方法，其特征在于，所述监控微服务框架中的业务模块调用接口是否能正常使用之前包括：

获取业务模块调用接口ID信息；

基于所述业务模块调用接口ID信息确定业务模块调用接口调用的业务模块ID信息；

基于所述业务模块调用接口ID信息和所述业务模块ID信息，按照预设规则构建链路数据拓扑图，用以追踪链路数据。

3.根据权利要求1所述的用于微服务框架的数据监控方法，其特征在于，所述监控微服务框架中的业务模块调用接口是否能正常使用包括：

获取业务模块ID信息；

基于所述业务模块ID信息，对所述业务模块的调用成功率进行统计；

根据统计结果判断是否调整所述业务模块的调用次数。

4.根据权利要求1所述的用于微服务框架的数据监控方法，其特征在于，所述监控微服务框架中的业务模块调用接口是否能正常使用之后包括：

获取不能正常使用的业务模块调用接口ID信息；

根据不能正常使用的所述业务模块调用接口ID信息，向客户端发送告警信息。

5.根据权利要求1所述的用于微服务框架的数据监控方法，其特征在于，所述监控微服务框架中的业务模块调用接口是否能正常使用之后包括：

确定无法正常使用的业务模块调用接口ID信息和/或业务模块ID信息；

基于所述业务模块调用接口ID信息和/或所述业务模块ID信息发送告警请求；

基于所述告警请求判断告警请求的次数是否达到预设阈值；

根据判断结果确定是否向客户端发送告警信息。

6.一种用于微服务框架的数据监控装置，其特征在于，用于对模块调用数据的存储结果进行监控，所述装置包括：

监控模块，用于监控微服务框架中的业务模块调用接口是否能正常使用；

查询模块，用于如果所述微服务框架中的业务模块调用接口不能正常使用，则采用链路数据追踪方法查询所述业务模块调用接口对应的模调链路统计数据；

分析模块，用于采用链路数据分析方法，根据所述模调链路统计数据分析确定出不能正常使用的所述业务模块调用接口对应的业务模块。

7.根据权利要求6所述的用于微服务框架的数据监控装置，其特征在于，还包括：

第一获取模块，用于获取业务模块调用接口ID信息；

第一确定模块，用于基于所述业务模块调用接口ID信息确定业务模块调用接口调用的业务模块ID信息；

构建模块，用于基于所述业务模块调用接口ID信息和所述业务模块ID信息，按照预设规则构建链路数据拓扑图，用以追踪链路数据。

8.根据权利要求6所述的用于微服务框架的数据监控装置，其特征在于，所述监控模块包括：

获取单元，用于获取业务模块ID信息；

统计单元，用于基于所述业务模块ID信息，对所述业务模块的调用成功率进行统计；

判断单元，用于根据统计结果判断是否调整所述业务模块的调用次数。

9.根据权利要求6所述的用于微服务框架的数据监控装置，其特征在于，还包括：

第二获取模块，用于获取不能正常使用的业务模块调用接口ID信息；

第一发送模块，用于根据不能正常使用的所述业务模块调用接口ID信息，向客户端发送告警信息。

10.根据权利要求6所述的用于微服务框架的数据监控装置，其特征在于，还包括：

第二确定模块，用于确定无法正常使用的业务模块调用接口ID信息和/或业务模块ID信息；

第二发送模块，用于基于所述业务模块调用接口ID信息和/或所述业务模块ID信息发送告警请求；

判断模块，用于基于所述告警请求判断告警请求的次数是否达到预设阈值；

第三确定模块，用于根据判断结果确定是否向客户端发送告警信息。

Images