CN112463587B - 一种基于QOS的Ice服务监控方法 - Google Patents

Abstract

一种基于QOS的Ice服务监控方法，包括以下步骤：1)、监控请求发起；2)、监控数据分析功：监控数据分析从逻辑上实现了监控消息接收与分配、监控数据处理和分析结果存储三个主要的功能；3)、监控数据展示，监控数据展示从逻辑上实现了报表读取、报表可视化展示、报告导出和数据输出地址修改；4)、Ice服务替换，从逻辑上实现了工作流获取、服务测试调用、服务推荐模块调用和服务替换。本发明不仅是获取服务的QoS信息，更重要的一点是根据获取到的ice服务数据实现对ice服务的替换，进而提高整个系统架构的可用性。

Description

一种基于QOS的Ice服务监控方法

技术领域

本发明是微服务架构领域中的服务监控，尤其是针对通过Ice框架开发的服务，我们通过发起对Ice服务的监控请求，获取Ice服务的QoS信息，从而对Ice 服务的质量有一个评定，进而能够迅速定位运行异常的服务和获取其原因，然后可以发起服务替换等操作，提升微服务架构的可用性。

背景技术

在互联网飞速发展的时代，系统架构不断优化更新，日益复杂的互联网应用构建在不同的软件模块上，这些软件模块可能由不同的团队开发、使用不同的编程语言、横跨了多个数据中心和数台服务器；系统运维人员很难定位某一个服务运行异常的具体原因，这将给企业甚至国家造成巨大的损失。因此，分布式集群需要一个用于帮助理解系统行为、分析系统性能和快速定位异常的工具。所以，服务监控系统成为了分布式系统架构中的基本组件之一，发挥着极其重要的作用。

目前国内外很多大型互联网公司都开发了自己的服务监控系统，用于支持不同业务场景下的服务监控需求。对于企业来说，传统运维方式中，运维人员疲于处理各种故障、效率低下，即使加班加点地调试、部署、维护，也经常因设备故障而导致业务中断，严重影响业务的正常运转，甚至带来不可预计的损失；因此，部署一套高效可靠的监控系统，实时监控服务器与应用服务的运行状态，提供便捷、及时的通知机制让运维人员快速定位并解决故障尤为重要。

以美团点评的CAT监控系统为例，目前美团点评的业务服务器数量超过7000 台，拥有15台以上的物理服务器集群，每日能产生50TB的数据。在2011年以前，美团点评使用了一些简单的监控工具例如Zabbix，这些单独工具的功能在一定程度上满足了美团点评的服务监控需求，但是整体服务化水平参差不齐、扩展性弱并且不同工具之间不能连通，使得定位异常需要切换多个不同的系统，费时费力且低效。于是从2011年美团点评开始研发属于自己的第一代服务监控系统 CAT，为美团各业务线提供系统的性能指标、健康状况、监控告警等，并且将随着技术的更新不断优化。

发明内容

为了克服已有技术的不足,本发明提供了一种基于QOS的Ice服务监控方法，不仅是获取服务的QoS信息，更重要的一点是根据获取到的ice服务数据实现对 ice服务的替换，进而提高整个系统架构的可用性。

本发明解决其技术问题所采用的技术方案是：

一种基于QOS的Ice服务监控方法，包括以下步骤：

1)、监控请求发起，运行流程如下：

1.1)发起监控请求；

监控系统客户端在初始化后处于等待状态，等待埋点在业务代码中的API被调用后激活，然后开始执行监控的流程，所以这个过程可以抽象为Ice服务向监控系统发起了一个监控的请求；

1.2)收集监控数据；

当监控请求已经发起，那么处于等待状态的监控线程组开始创建负责数据收集、系统状态监控和数据发送的线程实例，随着创建事务Transaction的API代码被调用，这三个线程实例开始发挥作用；

1.3)监控数据发送；

只有业务代码执行到监控API时，监控系统才会在这个时间点上采集数据作为一条独立的消息存入消息树结构中；而整个业务执行时间的统计依赖于事务Transaction，在业务执行结束时会自动将Transaction的状态设置为SUCCESS并调用complete()告知监控系统这个Transaction已经结束了；

1.4)数据的收集就是服务业务流程执行过程中不断调用监控API主动触发数据采集事件的流程，当Transaction结束后整个数据收集过程也随之结束。在监控系统中，Transaction扮演了一个“容器”的角色，它将同属于一个服务流程中所有监控API被调用产生的消息聚合在一起，与其他的Transaction有着很明显的界限；

2)、监控数据分析功：监控数据分析从逻辑上实现了监控消息接收与分配、监控数据处理和分析结果存储三个主要的功能，包括以下步骤：

2.1)在Netty接收端使用自定义解码器时引入了MessageHandler类的对象，当消息树被解码还原后调用handle()方法将消息树交给消费线程；消费线程可以通过findDistributor()方法直接找到正在运行的分配线程，然后将消息树交给分配线程；

2.2)消息树在Netty接收端解码时生成了不同类型消息的List，此时分配线程只需要将这些List分配至不同的分析器即可，不需要对消息树进行拆分；

2.3)监控数据的处理依赖于分析器实例，分析器从其等待队列中取出消息，利用外部导入的报表模型将消息处理成报表存入缓存，等待一个周期结束后将缓存中的内容写入本地文件和数据库中；

3)、监控数据展示，监控数据展示从逻辑上实现了报表读取、报表可视化展示、报告导出和数据输出地址修改；

4)、Ice服务替换，从逻辑上实现了工作流获取、服务测试调用、服务推荐模块调用和服务替换。

进一步，所述步骤3)的过程如下：

3.1)报表读取虽然在后端将全部的报表数据放入了缓存中，但是数据展现在界面上需要经过二次读取和二次处理，而二次读取的数据依赖于用户在界面上选择的索引转化为的读取参数；报表读取类ReportLoader能够传递的数据包括以天为单位和以时间段为单位的两个索引、索引文件、某类型的全部报表和某个时间段的指定类型报表。在读取报表的过程中为了线程安全，采用了ReentrantLock 可重入锁对文件和数据库进行限制，保证数据准确性；

3.2)报表的可视化展示使用JFreeChart工具在页面上生成表格和多种统计图，在用户切换索引时后端将读取新的数据转化为表格和统计图能够解析的数据集，在页面上重新生成表格或统计图组件覆盖原有的部分，完成页面的刷新；

3.3)报告导出可生成具有指定格式的PDF报告文件，报告的标题和正文字体统一设置，报告正文以服务名作为一级标题进行区分，在计算不同指标的加权平均值后借助JFreeChart工具生成统计图写入文件，每个服务名一级标题下的正文结构完全相同；

3.4)数据输出地址的主要功能是修改配置文件中的数据输出地址，这个地址用于存储报表文件、原始数据、系统日志和其他一些必要的临时文件。

再进一步，所述步骤4)的过程如下：

4.1)工作流的获取实现了从流程编排引擎获取的原始数据到可调用服务列表的转换，得到一个Map<String,Boolean>类型的HashMap与Ice服务信息表相匹配；

4.2)服务测试调用对HashMap里的服务名进行遍历调用测试，如果某个服务调用失败则将HashMap里对应条目的Value改为true，代表需要进行替换；该部分需要经过测试远程服务是否可访问和测试调用两部分，为防止不可访问的服务拖延程序运行时间，在测试调用的部分设置了超时计时器，测试超时将直接设置该服务为状态异常；

4.3)服务推荐模块获得Value为true的Ice服务的同类服务，修改原有的工作流服务列表，将这个新的列表返回给流程编排引擎，完成服务替换。

本发明的有益效果主要表现在：不仅是获取服务的QoS信息，更重要的一点是根据获取到的ice服务数据实现对ice服务的替换，进而提高整个系统架构的可用性。

附图说明

图1为本发明所具有的功能模块图；

图2为监控请求发起流程图；

图3为监控消息接收与分配流程图；

图4为Ice服务替换流程图。

具体实施方式

下面结合附图对本发明作进一步描述。

参照图1～图4，一种基于QOS的Ice服务监控方法，包括以下步骤：

1)、监控请求发起，运行流程如下：

1.1)发起监控请求；

监控系统客户端在初始化后处于等待状态，等待埋点在业务代码中的API被调用后激活，然后开始执行监控的流程，所以这个过程可以抽象为Ice服务向监控系统发起了一个监控的请求；

1.2)收集监控数据；

当监控请求已经发起，那么处于等待状态的监控线程组开始创建负责数据收集、系统状态监控和数据发送的线程实例，随着创建事务Transaction的API代码被调用，这三个线程实例开始发挥作用；

1.3)监控数据发送；

只有业务代码执行到监控API时，监控系统才会在这个时间点上采集数据作为一条独立的消息存入消息树结构中；而整个业务执行时间的统计依赖于事务 Transaction，在业务执行结束时会自动将Transaction的状态设置为SUCCESS并调用complete()告知监控系统这个Transaction已经结束了；

1.4)数据的收集就是服务业务流程执行过程中不断调用监控API主动触发数据采集事件的流程，当Transaction结束后整个数据收集过程也随之结束。在监控系统中，Transaction扮演了一个“容器”的角色，它将同属于一个服务流程中所有监控API被调用产生的消息聚合在一起，与其他的Transaction有着很明显的界限；

2)、监控数据分析功：监控数据分析从逻辑上实现了监控消息接收与分配、监控数据处理和分析结果存储三个主要的功能，包括以下步骤：

2.1)在Netty接收端使用自定义解码器时引入了MessageHandler类的对象，当消息树被解码还原后调用handle()方法将消息树交给消费线程；消费线程可以通过findDistributor()方法直接找到正在运行的分配线程，然后将消息树交给分配线程；

2.2)消息树在Netty接收端解码时生成了不同类型消息的List，此时分配线程只需要将这些List分配至不同的分析器即可，不需要对消息树进行拆分；

2.3)监控数据的处理依赖于分析器实例，分析器从其等待队列中取出消息，利用外部导入的报表模型将消息处理成报表存入缓存，等待一个周期结束后将缓存中的内容写入本地文件和数据库中；

3)、监控数据展示，监控数据展示从逻辑上实现了报表读取、报表可视化展示、报告导出和数据输出地址修改；

4)、Ice服务替换，从逻辑上实现了工作流获取、服务测试调用、服务推荐模块调用和服务替换。

进一步，所述步骤3)的过程如下：

3.1)报表读取虽然在后端将全部的报表数据放入了缓存中，但是数据展现在界面上需要经过二次读取和二次处理，而二次读取的数据依赖于用户在界面上选择的索引转化为的读取参数；报表读取类ReportLoader能够传递的数据包括以天为单位和以时间段为单位的两个索引、索引文件、某类型的全部报表和某个时间段的指定类型报表。在读取报表的过程中为了线程安全，采用了ReentrantLock 可重入锁对文件和数据库进行限制，保证数据准确性；

3.2)报表的可视化展示使用JFreeChart工具在页面上生成表格和多种统计图，在用户切换索引时后端将读取新的数据转化为表格和统计图能够解析的数据集，在页面上重新生成表格或统计图组件覆盖原有的部分，完成页面的刷新；

3.3)报告导出可生成具有指定格式的PDF报告文件，报告的标题和正文字体统一设置，报告正文以服务名作为一级标题进行区分，在计算不同指标的加权平均值后借助JFreeChart工具生成统计图写入文件，每个服务名一级标题下的正文结构完全相同；

3.4)数据输出地址的主要功能是修改配置文件中的数据输出地址，这个地址用于存储报表文件、原始数据、系统日志和其他一些必要的临时文件。

再进一步，所述步骤4)的过程如下：

4.1)工作流的获取实现了从流程编排引擎获取的原始数据到可调用服务列表的转换，得到一个Map<String,Boolean>类型的HashMap与Ice服务信息表相匹配；

4.2)服务测试调用对HashMap里的服务名进行遍历调用测试，如果某个服务调用失败则将HashMap里对应条目的Value改为true，代表需要进行替换；该部分需要经过测试远程服务是否可访问和测试调用两部分，为防止不可访问的服务拖延程序运行时间，在测试调用的部分设置了超时计时器，测试超时将直接设置该服务为状态异常；

4.3)服务推荐模块获得Value为true的Ice服务的同类服务，修改原有的工作流服务列表，将这个新的列表返回给流程编排引擎，完成服务替换。

本实施例中，本发明中，监控请求发起模块从逻辑上实现了监控请求发起、监控数据收集和监控数据发送三个主要的功能。监控系统客户端在初始化后处于等待状态，等待埋点在业务代码中的API被调用后激活，然后开始执行监控的流程，所以这个过程可以抽象为Ice服务向监控系统发起了一个监控的请求。监控请求已经发起，那么处于等待状态的监控线程组开始创建负责数据收集、系统状态监控和数据发送的线程实例，随着创建事务Transaction的API代码被调用，这三个线程实例开始发挥作用。

监控数据分析从逻辑上实现了监控消息接收与分配、监控数据处理和分析结果存储三个主要的功能。监控消息接收与分配主要指客户端发送的消息树从被服务端接收到交给分析器的这个过程，消息经过了Netty接收端、消费与分配线程和分析线程三个部分。

监控数据展示从逻辑上实现了报表读取、报表可视化展示、报告导出和数据输出地址修改四个主要功能。报表读取虽然在后端将全部的报表数据放入了缓存中，但是数据展现在界面上需要经过二次读取和二次处理，而二次读取的数据依赖于用户在界面上选择的索引转化为的读取参数。报表读取类ReportLoader能够传递的数据包括以天为单位和以时间段为单位的两个索引、索引文件、某类型的全部报表和某个时间段的指定类型报表。在读取报表的过程中为了线程安全，采用了ReentrantLock可重入锁对文件和数据库进行限制，保证数据准确性。

Ice服务替换从逻辑上实现了工作流获取、服务测试调用、服务推荐模块调用和服务替换四个主要的功能。工作流的获取实现了从流程编排引擎获取的原始数据到可调用服务列表的转换，得到一个Map<String,Boolean>类型的HashMap与 Ice服务信息表相匹配。服务测试调用对HashMap里的服务名进行遍历调用测试，如果某个服务调用失败则将HashMap里对应条目的Value改为true，代表需要进行替换。最后调用服务推荐模块获得Value为true的Ice服务的同类服务，修改原有的工作流服务列表，将这个新的列表返回给流程编排引擎，完成服务替换。

如图1所示，基于QOS的Ice服务监控系统由四大功能模块组成，每一模块相互协作实现对Ice服务的监控工作。

发起监控请求，如图2所示流程；

1.1)首先需要创建监控线程实例，一个监控线程实例对应一个Ice服务；

1.2)设置服务名与ip等配置信息，然后创建Transaction实例，等待该实例被调用

1.3)当该Api被调用后，收集Ice服务的QoS数据，该数据包括时延性、吞吐量、准确度，这三个数据是对该服务的评判标准

1.4)获取到的数据可发送到收集端，进行统一分析

针对所获数据信息，对其进行接收与分配，流程如图3所示：

2.1)在Netty接收端使用自定义解码器时引入了MessageHandler类的对象，当消息树被解码还原后调用handle()方法将消息树交给消费线程；

2.2)消息树在Netty接收端解码时生成了不同类型消息的List，此时分配线程只需要将这些List分配至不同的分析器即可，不需要对消息树进行拆分；

3.3)监控数据的处理依赖于分析器实例，分析器从其等待队列中取出消息，利用外部导入的报表模型将消息处理成报表存入缓存，等待一个周期结束后将缓存中的内容写入本地文件和数据库中。

当数据被处理完毕，即可对数据进行展示：本发明对处理完毕的数据进行一个报表展示，同时用户还可根据时间对其进行报表导出。

本发明不仅是获取服务的QoS信息，更重要的一点是根据获取到的ice服务数据实现对ice服务的替换，进而提高整个系统架构的可用性：

工作流的获取实现了从流程编排引擎获取的原始数据到可调用服务列表的转换，得到一个Map<String,Boolean>类型的HashMap与Ice服务信息表相匹配。

服务测试调用对HashMap里的服务名进行遍历调用测试，如果某个服务调用失败则将HashMap里对应条目的Value改为true，代表需要进行替换；该部分需要经过测试远程服务是否可访问和测试调用两部分，为防止不可访问的服务拖延程序运行时间，在测试调用的部分设置了超时计时器，测试超时将直接设置该服务为状态异常。

服务推荐模块获得Value为true的Ice服务的同类服务，修改原有的工作流服务列表，将这个新的列表返回给流程编排引擎，完成服务替换。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明权利要求所限定的范围。

Claims (3)

1.一种基于QOS的Ice服务监控方法，其特征在于，所述方法包括以下步骤：

1)、监控请求发起，运行流程如下：

1.1)发起监控请求；

监控系统客户端在初始化后处于等待状态，等待埋点在业务代码中的API被调用后激活，然后开始执行监控的流程，所以这个过程抽象为Ice服务向监控系统发起了一个监控的请求；

1.2)收集监控数据；

当监控请求已经发起，那么处于等待状态的监控线程组开始创建负责数据收集、系统状态监控和数据发送的线程实例，随着创建事务Transaction的API代码被调用，这三个线程实例开始发挥作用；

1.3)监控数据发送；

只有业务代码执行到监控API时，监控系统才会在这个时间点上采集数据作为一条独立的消息存入消息树结构中；而整个业务执行时间的统计依赖于事务Transaction，在业务执行结束时会自动将Transaction的状态设置为SUCCESS并调用complete()告知监控系统这个Transaction已经结束了；

1.4)数据的收集就是服务业务流程执行过程中不断调用监控API主动触发数据采集事件的流程，当Transaction结束后整个数据收集过程也随之结束，在监控系统中，Transaction扮演了一个“容器”的角色，它将同属于一个服务流程中所有监控API被调用产生的消息聚合在一起，与其他的Transaction有着很明显的界限；

2)、监控数据分析功：监控数据分析从逻辑上实现了监控消息接收与分配、监控数据处理和分析结果存储三个主要的功能，包括以下步骤：

2.1)在Netty接收端使用自定义解码器时引入了MessageHandler类的对象，当消息树被解码还原后调用handle()方法将消息树交给消费线程；消费线程通过findDistributor()方法直接找到正在运行的分配线程，然后将消息树交给分配线程；

2.2)消息树在Netty接收端解码时生成了不同类型消息的List，此时分配线程只需要将这些List分配至不同的分析器即可，不需要对消息树进行拆分；

2.3)监控数据的处理依赖于分析器实例，分析器从其等待队列中取出消息，利用外部导入的报表模型将消息处理成报表存入缓存，等待一个周期结束后将缓存中的内容写入本地文件和数据库中；

3)、监控数据展示，监控数据展示从逻辑上实现了报表读取、报表可视化展示、报告导出和数据输出地址修改；

4)、Ice服务替换，从逻辑上实现了工作流获取、服务测试调用、服务推荐模块调用和服务替换。

2.如权利要求1所述的一种基于QOS的Ice服务监控方法，其特征在于，所述步骤3)的过程如下：

3.1)报表读取虽然在后端将全部的报表数据放入了缓存中，但是数据展现在界面上需要经过二次读取和二次处理，而二次读取的数据依赖于用户在界面上选择的索引转化为的读取参数；报表读取类ReportLoader能够传递的数据包括以天为单位和以时间段为单位的两个索引、索引文件、某类型的全部报表和某个时间段的指定类型报表；在读取报表的过程中为了线程安全，采用了ReentrantLock可重入锁对文件和数据库进行限制，保证数据准确性；

3.2)报表的可视化展示使用JFreeChart工具在页面上生成表格和多种统计图，在用户切换索引时后端将读取新的数据转化为表格和统计图能够解析的数据集，在页面上重新生成表格或统计图组件覆盖原有的部分，完成页面的刷新；

3.3)报告导出可生成具有指定格式的PDF报告文件，报告的标题和正文字体统一设置，报告正文以服务名作为一级标题进行区分，在计算不同指标的加权平均值后借助JFreeChart工具生成统计图写入文件，每个服务名一级标题下的正文结构完全相同；

3.4)数据输出地址的主要功能是修改配置文件中的数据输出地址，这个地址用于存储报表文件、原始数据、系统日志和其他一些临时文件。

3.如权利要求1或2所述的一种基于QOS的Ice服务监控方法，其特征在于，所述步骤4)的过程如下：

4.1)工作流的获取实现了从流程编排引擎获取的原始数据到可调用服务列表的转换，得到一个Map<String,Boolean>类型的HashMap与Ice服务信息表相匹配；

4.2)服务测试调用对HashMap里的服务名进行遍历调用测试，如果某个服务调用失败则将HashMap里对应条目的Value改为true，代表需要进行替换；该部分需要经过测试远程服务是否可访问和测试调用两部分，为防止不可访问的服务拖延程序运行时间，在测试调用的部分设置了超时计时器，测试超时将直接设置该服务为状态异常；

4.3)服务推荐模块获得Value为true的Ice服务的同类服务，修改原有的工作流服务列表，将这个新的列表返回给流程编排引擎，完成服务替换。