CN117555747A - 一种服务总线监控方法及*** - Google Patents

Abstract

本发明提供了计算机技术领域的一种服务总线监控方法及***，方法包括：步骤S10、创建一MQ队列，通过所述MQ队列接收管理***分发的服务总线调用的消息；步骤S20、对所述MQ队列消费的消息进行监听，基于所述消息记录服务调用日志、校验调用状态以及统计服务调用结果，并通过可视化界面展示所述服务调用日志；步骤S30、将所述服务调用日志实时存储至Elasticsearch中，将所述服务调用结果实时存储至MySQL中；步骤S40、基于所述调用状态对消息进行补偿推送；步骤S50、通过所述Elasticsearch以及MySQL进行问题定位。本发明的优点在于：极大的提升了服务总线服务调用的可靠性以及运维的便捷性。

Description

一种服务总线监控方法及***

技术领域

本发明涉及计算机技术领域，特别指一种服务总线监控方法及***。

背景技术

服务总线是一种通过屏蔽实现数据交换所需的底层通信技术，是一种实现应用请求信息和响应结果信息的传输工具，广泛应用于各种管理***(集成平台)中，例如应用于医院管理***中。各管理***在应用服务总线时，存在对服务总线的服务调用进行可视化的监控管理的需求；例如在服务的调用流程中，对请求入栈、报文转换处理、请求出栈、调用失败后补偿调用、调用结果统计分析等进行监控管理。

然而，传统服务总线在应用时，无法清晰展示服务调用过程以及各节点的出入栈信息，失败的调用请求无法进行补偿调用(无法对失败消息进行补偿推送)，即无法对整个服务调用流程进行监控管理，无法充分的暴露问题，也无法通过解决问题来精准的提升管理***的管理水平。

因此，如何提供一种服务总线监控方法及***，实现提升服务总线服务调用的可靠性以及运维的便捷性，成为一个亟待解决的技术问题。

发明内容

本发明要解决的技术问题，在于提供一种服务总线监控方法及***，实现提升服务总线服务调用的可靠性以及运维的便捷性。

第一方面，本发明提供了一种服务总线监控方法，包括如下步骤：

步骤S10、创建一MQ队列，通过所述MQ队列接收管理***分发的服务总线调用的消息；

步骤S20、对所述MQ队列消费的消息进行监听，基于所述消息记录服务调用日志、校验调用状态以及统计服务调用结果，并通过可视化界面展示所述服务调用日志；

步骤S30、将所述服务调用日志实时存储至Elasticsearch中，将所述服务调用结果实时存储至MySQL中；

步骤S40、基于所述调用状态对消息进行补偿推送；

步骤S50、通过所述Elasticsearch以及MySQL进行问题定位。

进一步的，所述步骤S10具体为：

基于服务总线的扩展接口创建一MQ队列，通过所述MQ队列异步接收管理***分发的服务总线调用的消息。

进一步的，所述步骤S20中，所述服务调用日志至少包括整个服务的入栈报文和出栈报文、发往下游各端点的入栈报文和出栈报文、请求消息在服务总线内部的介质流程走向；所述介质流程走向至少包括请求消息在存储介质的存储状态、在各存储介质中的流向、存储到各存储介质所花费的时间；

所述调用状态为调用成功或者调用失败；

所述服务调用结果至少包括服务调用成功次数、服务调用失败次数、接口调用成功次数、接口调用失败次数、响应时间、服务调用时间以及接口调用时间。

进一步的，所述步骤S40具体为：

基于所述调用状态获取调用失败的消息，基于接收的筛选条件对需要补偿的所述消息进行筛选后，通过自动补偿、手动单个补偿或者手动批量补偿的补偿方式，对筛选的所述消息进行补偿推送，并通过可视化界面实时展示补偿结果、补偿时间、补偿时间段以及补偿进度。

进一步的，所述步骤S50具体为：

通过所述Elasticsearch检索设定时间段的服务调用日志，通过SQL语句从MySQL中按需查询服务调用结果，基于所述服务调用日志以及服务调用结果进行问题定位。

第二方面，本发明提供了一种服务总线监控***，包括如下模块：

MQ队列创建模块，用于创建一MQ队列，通过所述MQ队列接收管理***分发的服务总线调用的消息；

MQ队列监听模块，用于对所述MQ队列消费的消息进行监听，基于所述消息记录服务调用日志、校验调用状态以及统计服务调用结果，并通过可视化界面展示所述服务调用日志；

调用日志及结果存储模块，用于将所述服务调用日志实时存储至Elasticsearch中，将所述服务调用结果实时存储至MySQL中；

消息补偿模块，用于基于所述调用状态对消息进行补偿推送；

问题定位模块，用于通过所述Elasticsearch以及MySQL进行问题定位。

进一步的，所述MQ队列创建模块具体用于：

基于服务总线的扩展接口创建一MQ队列，通过所述MQ队列异步接收管理***分发的服务总线调用的消息。

进一步的，所述MQ队列监听模块中，所述服务调用日志至少包括整个服务的入栈报文和出栈报文、发往下游各端点的入栈报文和出栈报文、请求消息在服务总线内部的介质流程走向；所述介质流程走向至少包括请求消息在存储介质的存储状态、在各存储介质中的流向、存储到各存储介质所花费的时间；

所述调用状态为调用成功或者调用失败；

所述服务调用结果至少包括服务调用成功次数、服务调用失败次数、接口调用成功次数、接口调用失败次数、响应时间、服务调用时间以及接口调用时间。

进一步的，所述消息补偿模块具体用于：

基于所述调用状态获取调用失败的消息，基于接收的筛选条件对需要补偿的所述消息进行筛选后，通过自动补偿、手动单个补偿或者手动批量补偿的补偿方式，对筛选的所述消息进行补偿推送，并通过可视化界面实时展示补偿结果、补偿时间、补偿时间段以及补偿进度。

进一步的，所述问题定位模块具体用于：

通过所述Elasticsearch检索设定时间段的服务调用日志，通过SQL语句从MySQL中按需查询服务调用结果，基于所述服务调用日志以及服务调用结果进行问题定位。

本发明的优点在于：

通过创建的MQ队列接收管理***分发的服务总线调用的消息，并对MQ队列消费的消息进行监听，基于消息记录服务调用日志、校验调用状态以及统计服务调用结果，通过可视化界面展示服务调用日志，将服务调用日志实时存储至Elasticsearch中，将服务调用结果实时存储至MySQL中，基于调用状态对消息进行补偿推送，并通过Elasticsearch以及MySQL进行问题定位；即通过监听MQ队列消费的消息以记录服务调用日志，并通过可视化界面展示服务调用日志，可直观的知晓服务调用过程以及各节点的出入栈信息；而通过校验消息的调用状态，当消息调用失败时，通过自动补偿、手动单个补偿或者手动批量补偿的补偿方式对消息进行补偿推送，不仅保障消息推送的可靠性，还无需对业务***进行改造；通过将服务调用日志存储至Elasticsearch，不仅能快速检索定位消息，还能通过调用栈查看日志调用花费时间、错误节点与出入栈报文，帮助快速定位发送失败问题，将服务调用结果存储至MySQL，后续通过MySQL查询服务调用结果的统计情况即可快速发送问题并优化问题，最终极大的提升了服务总线服务调用的可靠性以及运维的便捷性。

附图说明

下面参照附图结合实施例对本发明作进一步的说明。

图1是本发明一种服务总线监控方法的流程图。

图2是本发明一种服务总线监控***的结构示意图。

图3是本发明的流程示意图。

具体实施方式

本申请实施例中的技术方案，总体思路如下：通过监听MQ队列消费的消息以记录服务调用日志，并通过可视化界面展示服务调用日志，可直观的知晓服务调用过程以及各节点的出入栈信息；通过校验消息的调用状态，当消息调用失败时，通过自动补偿、手动单个补偿或者手动批量补偿的补偿方式对消息进行补偿推送，以保障消息推送的可靠性，进而提升服务总线服务调用的可靠性；通过将服务调用日志存储至Elasticsearch，不仅能快速检索定位消息，还能通过调用栈查看日志调用花费时间、错误节点与出入栈报文，帮助快速定位发送失败问题，将服务调用结果存储至MySQL，后续通过MySQL查询服务调用结果的统计情况即可快速发送问题并优化问题，进而提升运维的便捷性。

请参照图1至图3所示，本发明一种服务总线监控方法的较佳实施例，包括如下步骤：

步骤S10、创建一MQ队列，通过所述MQ队列接收管理***分发的服务总线调用的消息；

步骤S20、对所述MQ队列消费的消息进行监听，基于所述消息记录服务调用日志、校验调用状态以及统计服务调用结果，并通过可视化界面展示所述服务调用日志；

由于不同服务对应的请求消息处理配置不同，会有不同的请求消息出入栈及请求消息流程走向，所以有必要展示所述服务调用日志；

步骤S30、将所述服务调用日志实时存储至Elasticsearch中，将所述服务调用结果实时存储至MySQL中；

在对所述服务调用日志和服务调用结果进行分析和统计后，需要对其进行落地存储，由于每天交互量颇大，且需要存储至少一年的数据(服务调用日志和服务调用结果)，为了保证数据检索的速度和准确性，分为两种方式存储(Elasticsearch和MySQL)；所述服务调用日志以月为单位存储到Elasticsearch的不同索引中，以便快速检索，而所述服务调用结果则存入MySQL中，能通过SQL语句展示不同需求的内容。

步骤S40、基于所述调用状态对消息进行补偿推送；

步骤S50、通过所述Elasticsearch以及MySQL进行问题定位。

本发明在对业务***零改造的基础上，能够助力于管理***进行失败消息的补偿推送，由于服务总线本身并无此功能所以进行了拓展，使其无需通过业务***就可重新推送消息；由于原先服务总线并无展示服务调用日志的功能，本发明引入Elasticsearch，不仅能快速检索定位消息，还能通过调用栈查看日志调用花费时间，错误节点与出入栈报文，帮助快速定位发送失败问题；通过统计服务调用结果，能一目了然的快速发现多次响应异常的服务和端点，比如调用时间过长，调用失败次数过多的服务，进行发现问题和优化，从而提升运维的便捷性。

所述步骤S10具体为：

基于服务总线的扩展接口创建一MQ队列，通过所述MQ队列异步接收管理***分发的服务总线调用的消息。即以服务总线为基础，扩展服务总线的扩展接口，来实现服务总线的监控管理。

所述步骤S20中，所述服务调用日志至少包括整个服务的入栈报文和出栈报文、发往下游各端点的入栈报文和出栈报文、请求消息在服务总线内部的介质流程走向；所述介质流程走向至少包括请求消息在存储介质的存储状态、在各存储介质中的流向、存储到各存储介质所花费的时间；

所述调用状态为调用成功或者调用失败；

所述服务调用结果至少包括服务调用成功次数、服务调用失败次数、接口调用成功次数、接口调用失败次数、响应时间、服务调用时间以及接口调用时间。

所述步骤S40具体为：

基于所述调用状态获取调用失败的消息，基于接收的筛选条件对需要补偿的所述消息进行筛选后，通过自动补偿、手动单个补偿或者手动批量补偿的补偿方式，对筛选的所述消息进行补偿推送，并通过可视化界面实时展示补偿结果、补偿时间、补偿时间段以及补偿进度。

由于服务总线从MQ队列消费消息后，会对当前消息的执行结果进行查看，而服务消息调用时可能存在当下游端点异常或者网络不通，会出现服务调用异常，针对该情况进行消息补偿；对消息进行筛选时，可以通过时间、调用***、成功失败，接收端点等进行。

所述步骤S50具体为：

通过所述Elasticsearch检索设定时间段的服务调用日志，通过SQL语句从MySQL中按需查询服务调用结果，基于所述服务调用日志以及服务调用结果进行问题定位。

本发明一种服务总线监控***的较佳实施例，包括如下模块：

MQ队列创建模块，用于创建一MQ队列，通过所述MQ队列接收管理***分发的服务总线调用的消息；

MQ队列监听模块，用于对所述MQ队列消费的消息进行监听，基于所述消息记录服务调用日志、校验调用状态以及统计服务调用结果，并通过可视化界面展示所述服务调用日志；

由于不同服务对应的请求消息处理配置不同，会有不同的请求消息出入栈及请求消息流程走向，所以有必要展示所述服务调用日志；

调用日志及结果存储模块，用于将所述服务调用日志实时存储至Elasticsearch中，将所述服务调用结果实时存储至MySQL中；

在对所述服务调用日志和服务调用结果进行分析和统计后，需要对其进行落地存储，由于每天交互量颇大，且需要存储至少一年的数据(服务调用日志和服务调用结果)，为了保证数据检索的速度和准确性，分为两种方式存储(Elasticsearch和MySQL)；所述服务调用日志以月为单位存储到Elasticsearch的不同索引中，以便快速检索，而所述服务调用结果则存入MySQL中，能通过SQL语句展示不同需求的内容。

消息补偿模块，用于基于所述调用状态对消息进行补偿推送；

问题定位模块，用于通过所述Elasticsearch以及MySQL进行问题定位。

本发明在对业务***零改造的基础上，能够助力于管理***进行失败消息的补偿推送，由于服务总线本身并无此功能所以进行了拓展，使其无需通过业务***就可重新推送消息；由于原先服务总线并无展示服务调用日志的功能，本发明引入Elasticsearch，不仅能快速检索定位消息，还能通过调用栈查看日志调用花费时间，错误节点与出入栈报文，帮助快速定位发送失败问题；通过统计服务调用结果，能一目了然的快速发现多次响应异常的服务和端点，比如调用时间过长，调用失败次数过多的服务，进行发现问题和优化，从而提升运维的便捷性。

所述MQ队列创建模块具体用于：

基于服务总线的扩展接口创建一MQ队列，通过所述MQ队列异步接收管理***分发的服务总线调用的消息。即以服务总线为基础，扩展服务总线的扩展接口，来实现服务总线的监控管理。

所述MQ队列监听模块中，所述服务调用日志至少包括整个服务的入栈报文和出栈报文、发往下游各端点的入栈报文和出栈报文、请求消息在服务总线内部的介质流程走向；所述介质流程走向至少包括请求消息在存储介质的存储状态、在各存储介质中的流向、存储到各存储介质所花费的时间；

所述调用状态为调用成功或者调用失败；

所述服务调用结果至少包括服务调用成功次数、服务调用失败次数、接口调用成功次数、接口调用失败次数、响应时间、服务调用时间以及接口调用时间。

所述消息补偿模块具体用于：

基于所述调用状态获取调用失败的消息，基于接收的筛选条件对需要补偿的所述消息进行筛选后，通过自动补偿、手动单个补偿或者手动批量补偿的补偿方式，对筛选的所述消息进行补偿推送，并通过可视化界面实时展示补偿结果、补偿时间、补偿时间段以及补偿进度。

由于服务总线从MQ队列消费消息后，会对当前消息的执行结果进行查看，而服务消息调用时可能存在当下游端点异常或者网络不通，会出现服务调用异常，针对该情况进行消息补偿；对消息进行筛选时，可以通过时间、调用***、成功失败，接收端点等进行。

所述问题定位模块具体用于：

通过所述Elasticsearch检索设定时间段的服务调用日志，通过SQL语句从MySQL中按需查询服务调用结果，基于所述服务调用日志以及服务调用结果进行问题定位。

综上所述，本发明的优点在于：

通过创建的MQ队列接收管理***分发的服务总线调用的消息，并对MQ队列消费的消息进行监听，基于消息记录服务调用日志、校验调用状态以及统计服务调用结果，通过可视化界面展示服务调用日志，将服务调用日志实时存储至Elasticsearch中，将服务调用结果实时存储至MySQL中，基于调用状态对消息进行补偿推送，并通过Elasticsearch以及MySQL进行问题定位；即通过监听MQ队列消费的消息以记录服务调用日志，并通过可视化界面展示服务调用日志，可直观的知晓服务调用过程以及各节点的出入栈信息；而通过校验消息的调用状态，当消息调用失败时，通过自动补偿、手动单个补偿或者手动批量补偿的补偿方式对消息进行补偿推送，不仅保障消息推送的可靠性，还无需对业务***进行改造；通过将服务调用日志存储至Elasticsearch，不仅能快速检索定位消息，还能通过调用栈查看日志调用花费时间、错误节点与出入栈报文，帮助快速定位发送失败问题，将服务调用结果存储至MySQL，后续通过MySQL查询服务调用结果的统计情况即可快速发送问题并优化问题，最终极大的提升了服务总线服务调用的可靠性以及运维的便捷性。

虽然以上描述了本发明的具体实施方式，但是熟悉本技术领域的技术人员应当理解，我们所描述的具体的实施例只是说明性的，而不是用于对本发明的范围的限定，熟悉本领域的技术人员在依照本发明的精神所作的等效的修饰以及变化，都应当涵盖在本发明的权利要求所保护的范围内。

Claims (10)

1.一种服务总线监控方法，其特征在于：包括如下步骤：

步骤S10、创建一MQ队列，通过所述MQ队列接收管理***分发的服务总线调用的消息；

步骤S20、对所述MQ队列消费的消息进行监听，基于所述消息记录服务调用日志、校验调用状态以及统计服务调用结果，并通过可视化界面展示所述服务调用日志；

步骤S30、将所述服务调用日志实时存储至Elasticsearch中，将所述服务调用结果实时存储至MySQL中；

步骤S40、基于所述调用状态对消息进行补偿推送；

步骤S50、通过所述Elasticsearch以及MySQL进行问题定位。

2.如权利要求1所述的一种服务总线监控方法，其特征在于：所述步骤S10具体为：

基于服务总线的扩展接口创建一MQ队列，通过所述MQ队列异步接收管理***分发的服务总线调用的消息。

3.如权利要求1所述的一种服务总线监控方法，其特征在于：所述步骤S20中，所述服务调用日志至少包括整个服务的入栈报文和出栈报文、发往下游各端点的入栈报文和出栈报文、请求消息在服务总线内部的介质流程走向；所述介质流程走向至少包括请求消息在存储介质的存储状态、在各存储介质中的流向、存储到各存储介质所花费的时间；

所述调用状态为调用成功或者调用失败；

所述服务调用结果至少包括服务调用成功次数、服务调用失败次数、接口调用成功次数、接口调用失败次数、响应时间、服务调用时间以及接口调用时间。

4.如权利要求1所述的一种服务总线监控方法，其特征在于：所述步骤S40具体为：

基于所述调用状态获取调用失败的消息，基于接收的筛选条件对需要补偿的所述消息进行筛选后，通过自动补偿、手动单个补偿或者手动批量补偿的补偿方式，对筛选的所述消息进行补偿推送，并通过可视化界面实时展示补偿结果、补偿时间、补偿时间段以及补偿进度。

5.如权利要求1所述的一种服务总线监控方法，其特征在于：所述步骤S50具体为：

通过所述Elasticsearch检索设定时间段的服务调用日志，通过SQL语句从MySQL中按需查询服务调用结果，基于所述服务调用日志以及服务调用结果进行问题定位。

6.一种服务总线监控***，其特征在于：包括如下模块：

MQ队列创建模块，用于创建一MQ队列，通过所述MQ队列接收管理***分发的服务总线调用的消息；

MQ队列监听模块，用于对所述MQ队列消费的消息进行监听，基于所述消息记录服务调用日志、校验调用状态以及统计服务调用结果，并通过可视化界面展示所述服务调用日志；

调用日志及结果存储模块，用于将所述服务调用日志实时存储至Elasticsearch中，将所述服务调用结果实时存储至MySQL中；

消息补偿模块，用于基于所述调用状态对消息进行补偿推送；

问题定位模块，用于通过所述Elasticsearch以及MySQL进行问题定位。

7.如权利要求6所述的一种服务总线监控***，其特征在于：所述MQ队列创建模块具体用于：

基于服务总线的扩展接口创建一MQ队列，通过所述MQ队列异步接收管理***分发的服务总线调用的消息。

8.如权利要求6所述的一种服务总线监控***，其特征在于：所述MQ队列监听模块中，所述服务调用日志至少包括整个服务的入栈报文和出栈报文、发往下游各端点的入栈报文和出栈报文、请求消息在服务总线内部的介质流程走向；所述介质流程走向至少包括请求消息在存储介质的存储状态、在各存储介质中的流向、存储到各存储介质所花费的时间；

所述调用状态为调用成功或者调用失败；

所述服务调用结果至少包括服务调用成功次数、服务调用失败次数、接口调用成功次数、接口调用失败次数、响应时间、服务调用时间以及接口调用时间。

9.如权利要求6所述的一种服务总线监控***，其特征在于：所述消息补偿模块具体用于：

基于所述调用状态获取调用失败的消息，基于接收的筛选条件对需要补偿的所述消息进行筛选后，通过自动补偿、手动单个补偿或者手动批量补偿的补偿方式，对筛选的所述消息进行补偿推送，并通过可视化界面实时展示补偿结果、补偿时间、补偿时间段以及补偿进度。

10.如权利要求6所述的一种服务总线监控***，其特征在于：所述问题定位模块具体用于：

通过所述Elasticsearch检索设定时间段的服务调用日志，通过SQL语句从MySQL中按需查询服务调用结果，基于所述服务调用日志以及服务调用结果进行问题定位。