一种面向微服务调用过程跟踪的监控系统及方法

摘要

本发明公开了一种面向微服务调用过程跟踪的监控系统及方法，系统主要包括数据采集、数据传输和数据存储模块。数据采集模块采用动态AOP技术向通用组件中织入监控逻辑代码，无需修改业务代码，保证了监控功能对应用系统的透明性。数据传输模块采取基于消息队列的异步方式，使用消息中间件实现监控数据的接入和传输，缓和数据发送和数据处理两者速度不同步的问题，同时也降低了数据采集模块和数据存储模块之间的耦合性。数据存储以用户事务请求为单位，针对一次事务请求记录包含多次服务调用的情况，监控系统使用列式模型数据库来进行数据存储。

权利要求

1.一种面向微服务调用过程跟踪的监控方法，采用面向微服务调用过程跟踪的监控系统，其特征在于：所述系统包括数据采集模块、数据传输模块、数据存储模块；

所述数据采集模块，用于使用基于字节码的动态AOP技术采集微服务节点上的服务性能数据和描述服务调用关系的数据；

所述数据传输模块，用于监控数据的异步传输；

所述数据存储模块，用于对采集到的服务性能数据以及描述服务调用关系的数据进行统一管理存储，并提供以用户事务请求为单位的查询接口；

所述方法包括以下步骤：

步骤1：数据采集模块从各个微服务节点中采集服务运行时的性能数据，同时添加描述服务调用的标识数据，并将数据封装为消息发送至数据传输模块；

步骤1的具体实现包括以下子步骤：

步骤1.1：数据采集模块对应用服务器组件、通信组件和数据库访问组件的相关类方法添加监控逻辑代码，增强组件功能；

步骤1.2：增强后的组件在服务运行期间采集和记录性能数据和标识数据；

步骤1.3：数据采集模块将采集的数据封装为消息发送给数据传输模块；

步骤2：数据传输模块接收各服务节点发送而来的消息数据，采用消息中间件作缓冲，实现数据接入和传输；

步骤2的具体实现包括以下子步骤：

步骤2.1：数据采集模块创建消息队列和异步线程，将数据推送到消息队列；

步骤2.2：异步线程将消息发送至消息中间件；

步骤3：数据存储模块从消息中间件中获取消息数据，并将数据存储到数据库中；

步骤3的具体实现包括以下子步骤：

步骤3.1：数据存储模块从消息中间件中接收数据；

步骤3.2：数据存储模块对数据进行解析和过滤；

步骤3.3：数据存储模块将合法的数据存入数据库；

步骤4：数据展示模块从数据库中读取监控数据，依据描述服务调用关系的标识数据构建用户请求的服务调用树；

步骤4的具体实现包括以下子步骤：

步骤4.1：数据展示模块依据查询接口从数据库中读取用户事务请求数据；

步骤4.2：数据展示模块处理数据，计算服务响应时间，并构建服务调用拓扑关系；

步骤4.3：数据展示模块可视化呈现用户事务请求的执行过程以及各环节的性能信息。

2.根据权利要求1所述的方法，其特征在于：所述数据采集模块若干，作为监控代理部署于各微服务节点处，在应用系统响应用户请求时，采集各服务的服务地址信息、时间戳信息以及服务运行过程中的数据库访问信息、异常信息。

3.根据权利要求1所述的方法，其特征在于：所述数据传输模块采用基于消息队列的异步传输方式，对系统从各分散的服务节点采集而来的数据进行接入和传输。

4.根据权利要求1所述的方法，其特征在于：所述数据存储模块用于存储采集的数据，接收数据传输模块传输的监控数据，采用列式模型的数据库进行存储，并提供以用户事务请求为单位的事务信息查询接口。

5.根据权利要求1-4任意一项所述的方法，其特征在于：所述监控系统还包括数据展示模块，用于从数据库中读取监控数据，提供查询接口；并对数据进行处理分析，以图表的形式在Web页面中呈现监控结果。

说明书

一种面向微服务调用过程跟踪的监控系统及方法

技术领域

[0001] 本发明属于服务监控技术领域，具体涉及一种针对微服务应用环境下服务性能进行监控以及服务调用过程跟踪的系统及方法。

背景技术

[0002] 微服务(Microservice Architecture)是一种新兴的软件架构风格，现在已经受到越来越多企业应用开发者的关注。关于这一软件架构风格较为完整的描述最早是在2014年Martin Fowler和James Lewis的一篇博客文章中。文章中提到微服务架构风格作为一种软件开发方法，是通过开发一些微小服务的方式来开发一个独立完整的应用系统。每个微服务围绕业务功能进行构建，并且能够通过自动的部署机制进行独立部署，运行在自己的进程中。微服务可以使用不同的语言来编写，使用不同的数据存储技术，服务之间采用轻量级的通信方式(如REST)和消息格式(如JSON)来传输数据。

[0003] 微服务架构区别于以往Web开发常用的三层架构，将整个应用拆分成多个独立的模块，每个模块实现特定的业务功能，模块以服务组件的形式存在，开发应用软件不再是开发库而是编写微服务。微服务架构是以松散的服务方式，构建可独立化部署的模块化应用。

[0004] 通常每个微服务都部署在不同的服务器节点上，这些节点可以是从物理机虚拟出来的虚拟机，也可以是通过容器(比如Docker)技术实例化的容器。微服务关联着一定的业务，一般情况下用于存储业务数据的数据库也会和服务运行在同一个节点之上。微服务的这种部署方式能够隔离运行环境，使得服务与服务之间高度解耦，保证了服务运行的独立性和维护的方便性。

[0005] 微服务架构可作为构造应用系统架构的替代性方案，它将应用中复杂的业务功能以微服务的形式组件化，使得整个应用被分解为粒度更细、更为独立的服务组件，进而也让系统开发具有更高的敏捷性和可伸缩性。在微服务架构下，业务功能的划分伴随着团队的划分，每一个团队只用负责开发和维护自己的服务模块，开发人员能够更加密切地关注应用业务逻辑的实现，而不必关心整个系统的结构。这种开发方式的组合有效地提升了软件开发的效率，有助于应用系统获得全新的弹性和较高的容错能力。

[0006] 在微服务架构的应用系统中，当业务需求增加时，服务个数增多，运行节点的数量也随之增多。另一方面，为了应对大量用户发起的高并发量请求，同一个服务也会有多个实例，并且也会被部署和运行在单独的节点上，处于不同的硬件、软件和网络环境中。服务节点数量的增多以及服务运行环境的复杂性使得用户请求在系统中的执行路径也复杂多变，系统行为难以捕捉。在用户请求出现严重耗时或者错误时，这种情况下如果采取登录单个节点查看日志、分析日志的方法来定位性能问题将会耗费巨大的时间和成本。当微服务应用出现性能问题时，需要能够快速定位引起性能瓶颈的服务，这种时候采取运行时监控的手段可以有效地解决问题。

[0007] 传统的针对服务的监控工具主要是对服务个体的性能进行监控，并没有考虑服务之间的依赖关系，因此缺少对应用系统的整体行为认知，为服务性能问题排查和调优带来的帮助有限。在微服务架构下，由于业务功能细化，服务之间的调用行为更加普遍，除了对单个服务进行性能监控以外，监控系统也需要能够对用户请求涉及的微服务调用过程进行监控和跟踪，获取到用户请求触发的服务调用路径以及调用路径上各个环节的耗时，进而帮助开发及维护人员定位应用系统的性能瓶颈。另一方面，由于微服务架构下服务运行环境复杂，跟踪用户请求可以生成运行情况下的服务依赖拓扑关系，反映整体应用的结构，为服务部署优化和系统架构完善提供基础。

发明内容

[0008] 为了解决上述技术问题，本发明提供了一种面向微服务调用过程跟踪的监控系统及方法。

[0009] 本发明的系统所采用的技术方案是：一种面向微服务调用过程跟踪的监控系统，其特征在于：包括数据采集模块、数据传输模块、数据存储模块；

[0010] 所述数据采集模块，用于使用基于字节码的动态AOP技术采集微服务节点上的服务性能数据和描述服务调用关系的数据；

[0011] 所述数据传输模块，用于监控数据的异步传输；

[0012] 所述数据存储模块，用于对采集到的服务性能数据以及描述服务调用关系的数据进行统一管理存储，并提供以用户事务请求为单位的查询接口。

[0013] 作为优选，所述数据采集模块若干，作为监控代理部署于各微服务节点处，在应用系统响应用户请求时，采集各服务的服务地址信息、时间戳信息以及服务运行过程中的数据库访问信息、异常信息。

[0014] 作为优选，所述数据传输模块采用基于消息队列的异步传输方式，对系统从各分散的服务节点采集而来的数据进行接入和传输。

[0015] 作为优选，所述数据存储模块用于存储采集的数据，接收数据传输模块传输的监控数据，采用列式模型的数据库进行存储，并提供以用户事务请求为单位的事务信息查询接口。

[0016] 作为优选，所述监控系统还包括数据展示模块，用于从数据库中读取监控数据，提供查询接口；并对数据进行处理分析，以图表的形式在Web页面中呈现监控结果。

[0017] 本发明的方法所采用的技术方案是：一种面向微服务调用过程跟踪的监控方法，其特征在于，包括以下步骤：

[0018] 步骤1：数据采集模块从各个微服务节点中采集服务运行时的性能数据，同时添加描述服务调用的标识数据，并将数据封装为消息发送至数据传输模块；

[0019] 步骤2：数据传输模块接收各服务节点发送而来的消息数据，采用消息中间件作缓冲，实现数据接入和传输；

[0020] 步骤3：数据存储模块从消息中间件中获取消息数据，并将数据存储到数据库中；

[0021] 步骤4：从数据库中读取监控数据，依据描述服务调用关系的标识数据构建用户请求的服务调用树。

[0022] 作为优选，步骤1的具体实现包括以下子步骤：

[0023] 步骤1.1：数据采集模块对应用服务器组件、通信组件和数据库访问组件的相关类方法添加监控逻辑代码，增强组件功能；

[0024] 步骤1.2：增强后的组件在服务运行期间采集和记录性能数据和标识数据；

[0025] 步骤1.3：数据采集模块将采集的数据封装为消息发送给数据传输模块。

[0026] 作为优选，步骤2的具体实现包括以下子步骤：

[0027] 步骤2.1：数据采集模块创建消息队列和异步线程，将数据推送到消息队列；

[0028] 步骤2.2：异步线程将消息发送至消息中间件。

[0029] 作为优选，步骤3的具体实现包括以下子步骤：

[0030] 步骤3.1：数据存储模块从消息中间件中接收数据；

[0031] 步骤3.2：数数据存储模块对数据进行解析和过滤；

[0032] 步骤3.3：数据存储模块将合法的数据存入数据库。

[0033] 作为优选，步骤4的具体实现包括以下子步骤：

[0034] 步骤4.1：数据展示模块依据查询接口从数据库中读取用户事务请求数据；

[0035] 步骤4.2：数据展示模块处理数据，计算服务响应时间，并构建服务调用拓扑关系；

[0036] 步骤4.3：数据展示模块可视化呈现用户事务请求的执行过程以及各环节的性能信息。

[0037] 相对于现有技术，本发明的有益效果是：

[0038] (1)本发明设计和实现了一个面向微服务调用的监控系统，通过监控和跟踪请求执行时的微服务调用过程，记录各个环节的性能数据，以此来支持微服务应用性能瓶颈的定位。

[0039] (2)本发明通过对监控系统的架构进行了设计，监控系统涵盖了从数据采集、数据传输、数据存储到数据展示的整个过程，并依据监控数据模型也给出了数据传输和存储的方案。

[0040] (3)本发明设计的监控系统能完整地呈现了事务请求执行过程，并且能够有效地定位耗时瓶颈和异常。

附图说明

[0041] 图1是本发明实施例的数据采集原理图；

[0042] 图2是本发明实施例的服务调用跟踪过程图；

[0043] 图3是本发明实施例的监控数据模型图；

[0044] 图4是本发明实施例的数据传输过程图；

[0045] 图5是本发明实施例的数据存储过程图。

[0046] 图6是本发明实施例的监控系统架构示意图。

具体实施方式

[0047] 为了便于本领域普通技术人员理解和实施本发明，下面结合附图及实施例对本发明作进一步的详细描述，应当理解，此处所描述的实施示例仅用于说明和解释本发明，并不用于限定本发明。

[0048] 请见图6，本发明提供的一种面向微服务调用过程跟踪的监控系统，包括数据采集模块、数据传输模块、数据存储模块；数据采集模块，用于使用基于字节码的动态AOP技术采集微服务节点上的服务性能数据和描述服务调用关系的数据；数据传输模块，用于监控数据的异步传输；数据存储模块，用于对采集到的服务性能数据以及描述服务调用关系的数据进行统一管理存储，并提供以用户事务请求为单位的查询接口。

[0049] 数据采集模块是整个监控系统的核心模块，负责监控数据的采集和发送，由监控代理完成，监控代理通过对与业务不相关的通用组件进行监控来获取服务调用和数据库访问等信息。监控系统考虑的监控对象包括应用服务器、通信组件和数据库访问组件。监控代理不直接侵入应用系统或通用组件的源代码，而采取AOP技术，在通用组件类加载时动态织入监控逻辑，增强通用组件的功能。如图1所示，监控代理通过向应用服务器、通信组件和数据库访问组件织入监控逻辑，分别用来拦截服务器请求、服务调用和数据库访问等行为，采集并发送数据。

[0050] 监控代理通过为全局的用户请求以及每次服务调用分配标识数据来跟踪用户请求下的服务调用过程。如图2所示，将处于同一请求下的服务调用关联起来的方法是让它们共享一个统一的标识ID，可以定义一个事务ID来实现。具体做法是在用户的事务请求首次到达应用服务器时监控系统为该请求分配一个事务ID，该ID需保证全局唯一，用来标识整个事务请求过程。同时为了描述该请求下多次服务调用的父子关系，需要为每次服务调用设置一个调用ID和父调用ID，调用ID标识本次服务调用过程，父调用ID标识引起本次服务调用的上一次服务调用，请求首次到达应用服务器时的服务称为入口服务，对于入口服务则设置父调用ID为-1。依据事务ID、调用ID和父调用ID能够构建事务请求的服务调用拓扑关系。

[0051] 图3显示了一次用户事务请求的过程，包含了多次服务调用，服务在执行过程中会发起远程服务调用或者数据库访问，为了准确跟踪到这些行为信息，定义了事务、调用和事件三个数据模型。

[0052] 事务(Transaction)表示用户发起的业务请求，是一个全局的概念。事务包含了请求过程中的一系列服务调用，每一个事务都具有一个ID，即事务ID。同一事务下的不同服务调用过程通过事务ID关联起来，事务ID需保证全局唯一，用以区分不同的事务请求，通常使用和主机名关联的生成策略。

[0053] 调用(Span)表示一次服务的执行过程，即用户或其他服务发起的请求到达应用服务器，应用服务器对此作出响应，通常是调用服务中的某个方法。监控系统通过对应用服务器组件实施监控，记录描述一次服务调用的相关信息，包括服务器类型、服务信息、时间戳信息、异常信息等，其中服务器类型用来标识系统拓扑结构图节点。另外，为了支持服务调用跟踪，还需添加跟踪上下文标识和采样标识等标识数据。描述一次服务调用的数据如表1。

[0054] 表1描述服务调用的字段信息

[0055]

[0056] 在服务执行过程中与其他组件交互的过程统称为事件(Event)，主要包括远程服务调用和数据库访问。一次服务执行过程中可能包含许多事件，因此对于每一个事件都需要有事件编号用来标识发生顺序，对于两种不同类别的事件还要有事件类型作为区分。对于远程服务调用事件，其属性字段包括被调用服务的地址和参数；对于数据库访问事件，则主要记录数据库的类型、数据库连接地址和SQL语句。描述事件的数据如表2所示。

[0057] 表2描述事件的字段信息

[0058]

[0059]

[0060] 如图4所示，对于监控数据的传输过程，监控代理启动时创建一个本地队列和数据传输线程，数据传输线程以守护线程的方式创建，持续监听本地队列中的数据的产生，以守护线程方式运行也减少对服务线程资源的占用。监控代理通过拦截服务线程将采集到的一次服务调用的数据封装在调用对象中，记录完成后首先将数据推送到本地队列中，然后由数据传输线程从队列中获取数据然后发送出去。

[0061] 数据存储模块采用列式模型的HBase数据库，服务调用数据存储过程如图5所示。将同一事务下的多次服务调用数据存储在HBase表的同一行下，以事务ID作为行键，不同事务请求引发的服务调用次数可能不一样，由于HBase的列支持动态增加，因此可以将Span数据按列存放。数据收集模块每次从消息队列服务器中取出一个Span数据后根据其包含的事务ID字段将数据插入到HBase表中的一行。

[0062] 应当理解的是，本说明书未详细阐述的部分均属于现有技术。

[0063] 应当理解的是，上述针对较佳实施例的描述较为详细，并不能因此而认为是对本发明专利保护范围的限制，本领域的普通技术人员在本发明的启示下，在不脱离本发明权利要求所保护的范围情况下，还可以做出替换或变形，均落入本发明的保护范围之内，本发明的请求保护范围应以所附权利要求为准。