CN111585840B - 服务资源监测方法、装置和设备 - Google Patents

Abstract

本申请实施例提供一种服务资源监测方法、装置和设备，该方法包括获取私有云环境下的服务资源池的服务可用性参数、服务性能参数、服务关联参数，所述服务资源池中包括多个微服务；基于所述服务可用性参数、所述服务性能参数、所述服务关联参数，构建所述服务资源池的多层级服务资源全局监测模型，所述多层级服务资源全局监测模型用于反映所述服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征；基于所述多层级服务资源全局监测模型，生成所述服务资源池的评估结果，所述评估结果包括评估分数或评估等级。以此可以改善现有技术中未能对私有云环境下的服务资源池进行整体监测的问题。

Description

服务资源监测方法、装置和设备

技术领域

本申请涉及微服务资源监测领域，具体而言，涉及一种服务资源监测方法、装置和设备。

背景技术

在微服务(microservices)架构下，单一的应用程序被拆分为多个具有高内聚、低耦合的多个微服务，每个微服务运行在独立的进程中，服务之间相互协调和配合，以向用户提供应用程序(或系统)的多项功能，各项大的功能之间组合起来可以形成项目模块，项目模块组合起来可以形成向用户提供各种业务的网站。

在采用微服务架构向用户提供服务功能时，服务故障经常是突然爆发甚至呈产生雪崩效应，所以需要对服务资源进行监测。服务资源监测是服务治理系统的关键部分，服务资源监测的复杂度与应用系统的复杂度呈显著正相关。在一些具有大量微服务个体的大规模在线实时信息系统中，服务资源监测逐步成为影响应用系统运行及拓展的瓶颈。

私有云环境下的服务资源构成了一个有机整体，服务资源不仅独立提供服务，而且各服务资源之间存在相互组合及嵌套关系。但是现有技术中的服务资源监测技术侧重于对单个服务资源的监测，而个体性的监测指标并不能反映私有云环境下的服务资源池的整体情况。

发明内容

本申请的目的在于提供一种服务资源监测方法、装置和设备，能够改善现有技术中未能对私有云环境下的服务资源池进行整体监测的问题。

第一方面，本申请实施例提供一种服务资源监测方法，所述方法包括：

获取私有云环境下的服务资源池的服务可用性参数、服务性能参数、服务关联参数，所述服务资源池中包括多个微服务；

基于所述服务可用性参数、所述服务性能参数、所述服务关联参数，构建所述服务资源池的多层级服务资源全局监测模型，所述多层级服务资源全局监测模型用于反映所述服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征；

基于所述多层级服务资源全局监测模型，生成所述服务资源池的评估结果，所述评估结果包括评估分数或评估等级。

在上述方法中，通过以私有云环境下的服务资源池作为监测对象，综合提取服务资源池的服务可用性参数、服务性能参数、服务关联参数，并基于这些参数构建用于反映所述服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征的多层级服务资源全局监测模型，还为整个服务资源池生成以分数或等级形式体现的评估结果，不仅有利于用户从宏观上得知整个服务资源池的运行情况，还有利于根据构建出的多层级服务资源全局监测模型及时对服务资源进行前瞻性地调整，从而可以降低故障发生的风险。

在可选的实施方式中，所述基于所述多层级服务资源全局监测模型，生成所述服务资源池的评估结果，包括：

基于所述多层级服务资源全局监测模型，生成所述服务资源池在多个维度下的子评估结果，所述多个维度下的子评估结果包括供给评估结果、网络性能评估结果、调用评估结果；根据所述多个维度下的子评估结果以及设定的多维指标加权系数，计算得到所述服务资源池的全局评估分数或全局评估等级。

通过上述实现方式可以对服务资源池进行综合评估和细化评估。

在可选的实施方式中，所述网络性能评估结果的计算过程包括：对于所述服务资源池中的每个微服务，根据设定的性能加权系数对单个服务的多种服务性能参数进行加权计算，得到单个服务的性能评估分数；对所述服务资源池中的所有服务的性能评估分数求平均，得到所述服务资源池的性能评估分数，作为所述网络性能评估结果。

在上述实现方式中，不仅提供了一种对单个服务的多种参数进行计算以得到单个服务的综合评估结果的方式，还可以统计得到整个服务资源池中所有服务在复杂属性上的综合评估结果，以此原理得到整个服务资源池网络性能评估结果。

在可选的实施方式中，所述服务资源池的评估结果包括全局评估等级，所述方法还包括：在监测到所述全局评估等级低于设定的等级阈值时，发出预警提示信息；响应对于所述预警提示信息的检查操作，根据所述检查操作中的每个检查项目分别输出所述服务资源池在各个检查项目下的子评估等级。以此可以及时根据服务资源池的全局评估等级进行预警提示，并根据接收到的检查操作输出多个检查项目下的子评估等级，有利于让用户先从宏观上得知整个服务资源池的综合运行情况有多严重，再根据各个检查项目下的各个子评估等级进行处理，有利于为用户的后续运维操作提供数据参考，在一定程度上可以避免用户因面临的异常点过多而无法快速确定先处理哪方面问题的情况。

在可选的实施方式中，所述方法还包括：对于所述服务资源池中的目标服务，以所述目标服务的唯一服务标识码作为基础标识，基于所述目标服务的服务提供者所在地以及所述基础标识，为所述目标服务生成带有地理空间特征的应用资源本体标识，所述目标服务是所述服务资源池中的任一个微服务。

通过上述实现方式，有利于快速确定出异常服务的地理空间位置，便于进行故障排查。

在可选的实施方式中，所述方法还包括：基于所述服务资源池中的各个微服务的应用资源本体标识，确定所述服务资源池中的异常服务的实体区域，或，统计得到异常服务的频发区域。

通过上述实现方式，有利于运维人员缩小对于异常服务的排查区域，提升故障排查效率，通过统计异常服务的频发区域有利于用户为制定资源调整策略提供数据参考依据。

在可选的实施方式中，所述方法还包括：基于所述多层级服务资源全局监测模型，在显示界面上以预设的至少一种展示模式显示所述服务资源池的多层级监测结果，所述多层级监测结果包括所述服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征。

通过上述实现方式，可以将服务资源池的多层级监测结果进行可视化，有利于用户更为直观地得知服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征，便于运维人员从宏观以及微观角度对服务资源进行处理。

在可选的实施方式中，获取所述服务资源池的服务可用性参数的过程，包括：以所述服务资源池中的各个微服务的服务标识码作为索引，对服务注册中心的注册资源池进行状态监测，得到所述服务资源池的服务注册量，作为所述服务资源池的服务可用性参数；获取所述服务资源池的服务性能参数的过程，包括：对所述服务资源池的各个微服务进行日志分析，得到每个服务的服务并发数、服务吞吐量、服务延迟量中的至少一种，将所有服务的服务并发数、服务吞吐量、服务延迟量中的至少一种作为所述服务资源池的服务性能参数；获取所述服务资源池的服务关联参数的过程，包括：调用分布式链路追踪组件对所述服务资源池中的各个微服务之间的调用关系进行监测，得到所述服务资源池的分布式服务追踪关联链路数量，作为所述服务资源池的服务关联参数。

通过上述实现方式给出了一种用于在服务资源监测过程中表征服务可用性的全局监测指标、一种用于在服务资源监测过程中表征服务质量的服务级监测指标、一种用于在服务资源监测过程中表征服务调用关系的服务间监测指标。

第二方面，本申请实施例提供一种服务资源监测装置，所述装置包括：

监测模块，用于获取私有云环境下的服务资源池的服务可用性参数、服务性能参数、服务关联参数，所述服务资源池中包括多个微服务；

生成模块，用于基于所述服务可用性参数、所述服务性能参数、所述服务关联参数，构建所述服务资源池的多层级服务资源全局监测模型，所述多层级服务资源全局监测模型用于反映所述服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征；

所述生成模块，还用于基于所述多层级服务资源全局监测模型，生成所述服务资源池的评估结果，所述评估结果包括评估分数或评估等级。

通过上述装置可以执行前述第一方面提供的方法，不仅有利于用户从宏观上得知整个服务资源池的运行情况，还有利于根据构建出的多层级服务资源全局监测模型及时对服务资源进行前瞻性地调整，从而可以降低故障发生的风险。

第三方面，本申请实施例提供一种服务资源监测设备，包括：

存储器；

处理器；

所述存储器中存储有所述处理器可执行的计算机程序，所述计算机程序被所述处理器执行时执行前述第一方面所述的方法。

第四方面，本申请实施例提供一种存储介质，该存储介质上存储有处理器可执行的计算机程序，所述计算机程序被所述处理器执行时执行前述第一方面提供的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种服务资源监测设备的示意图。

图2为本申请实施例提供的一种服务资源监测方法的流程图。

图3为本申请实施例提供的另一种服务资源监测方法的流程图。

图4为本申请实施例提供的再一种服务资源监测方法的流程图。

图5为本申请实施例提供的一种服务资源监测装置的功能模块框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

为了进行服务资源监测，现有技术中提出了一些服务监测方案，例如，阿里云的应用实时监控服务ARMS(Application Real-Time Monitoring Service)、美国流媒体公司Netflix的开源服务监控平台Mantis、Spring Cloud的链路跟踪组件Sleuth、Twitter发布的Zipkin服务链路追踪系统、CNCF(Cloud Native Computing Foundation，云原生计算基金会)发布的分布式服务跟踪标准Open Tracing、淘宝的“鹰眼”、京东的“Hydra”、大众点评的“CAT”、新浪的“Watchman”、唯品会的“Microscope”、窝窝网的“Tracing”等。

发明人经过研究发现，这些服务监测方案都是侧重于单一服务资源监测或服务调用链的监测，对于若将这些方案直接应用到私有云环境下的服务监测，会欠缺全局性的综合质量考虑，使得在智能办公等对安全性要求高的服务监测条件下，缺乏对整个云环境的服务资源池综合监测能力，而个体性监测指标并不能反映私有云服务资源池的综合性质量。

因此，本申请实施例提供以下方案针对性地对私有云环境下的服务资源池进行监测，且进行多层级监测，既考虑到了全局情况，又不丢弃个体性监测。这将有利于运维人员及时得知私有云环境下的服务资源池的整体运行情况，且在发生服务故障时，可以根据构建的多层级服务资源全局监测模型及时进行故障处理。

请参阅图1，图1为本申请实施例提供的一种服务资源监测设备的示意图。该服务资源监测设备可以是服务器，该服务资源监测设备可作为对私有云环境下的服务资源池进行监测的监测节点。

该服务资源监测设备可以与服务注册中心进行数据交互，还可以与私有云环境下的应用系统进行数据交互，服务资源池中的各个微服务配合以实现该应用系统中的各个功能。

为了使得该服务资源监测设备可以执行本申请实施例提供的服务资源监测方法，该服务资源监测设备包括存储器110、处理器120、通信组件130，存储器110、处理器120、通信组件130之间直接或间接连接，以实现数据交互。

存储器110可以包括至少一个具有存储能力的组件，存储器110可以是随机存取存储器(Random Access Memory，RAM)、只读存储器(Read Only Memory，ROM)、可编程只读存储器(Programmable Read-Only Memory，PROM)、电可擦除只读存储器(Electric ErasableProgrammable Read-Only Memory，EEPROM)等能够存储计算机程序的存储介质。存储器110上存储有处理器120可以执行的计算机程序，当计算机程序被处理器120执行时执行本申请实施例提供的服务资源监测方法。存储器110还可以是数据库，可以用于存储服务资源监测方法中的一些监测参数、监测结果或评估结果。

处理器120具有运算处理能力，可以是但不限于：中央处理器(CentralProcessing Unit，简称CPU)、网络处理器(Network Processor，简称NP)、专用集成电路、现场可编程门阵列或者其他分立组件搭建的专用处理器。处理器120可以执行存储器110中存储的计算机程序，从而实现本申请实施例提供的服务资源监测方法。

通信组件130为服务资源监测设备提供有线或无线通信能力，可以包括通讯总线、无线通信芯片、通信接口等。通过通讯总线可实现该服务资源监测设备的内部组件之间的直接或间接连接，通过无线通信芯片/通信接口可以实现该服务资源监测设备与其他外部设备(服务器、数据库等)之间的无线/有线通信，从而实现设备与设备之间的数据交互。

其中，图1所示结构仅作为示意，服务资源监测设备还可以有比图1所示结构更多的组件，或具有与图1所示结构所不同的配置，例如服务资源监测设备还可以包括显示器，用以显示一些监测参数、监测结果、故障提示等，也可以用于向用户提供监测操作界面。

请参阅图2，图2为本申请实施例提供的一种服务资源监测方法的流程图，该方法可以应用于服务资源监测系统中的监测节点。在本文的描述中，微服务可简称服务。

如图2所示，该方法包括：步骤S21-S23。

S21：获取私有云环境下的服务资源池的服务可用性参数、服务性能参数、服务关联参数，服务资源池中包括多个微服务。

私有云(Private Clouds)的安全性要求较高，对于私有云环境下的服务资源池，服务资源池中的各个微服务部署在多个服务设备上，在实际应用中，该多个服务设备可能位于同一位置，也可能位于不同位置(例如提供微服务的设备在北京、上海等)。各个微服务可以具有各自的数据库，也可以共用数据库。

作为一种实现方式，可以基于服务本体唯一性思想，以微服务的唯一服务标识码作为监测ID(Identifier，标识符)，通过多个子监测计算后台(例如开发Java服务后台)对所需的各种参数进行实时计算并定期回传给监测节点，或，将微服务的服务提供者主动传输的各种参数定期存入数据库，以便随时读取这些参数。开发Java服务后台本身也可以作为执行本申请实施例提供的方法的监测节点。

S22：基于服务可用性参数、服务性能参数、服务关联参数，构建服务资源池的多层级服务资源全局监测模型，多层级服务资源全局监测模型用于反映服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征。

其中，可以对多层级服务资源全局监测模型进行对象化和定量化，构建服务资源在多个维度的监测指标集，在多维监测指标集中，可以将服务注册状态作为服务可用性表征指标，以服务并发数、吞吐量、延迟量作为服务质量表征指标，以分布式服务追踪链路作为服务关联指标等，以此进行指标量化与开发。

该多层级服务资源全局监测模型可以表示为：Q＝{∑U，∑P，∑C}。

其中，Q表示全局性服务质量参数，U表示服务可用性参数，P表示服务性能参数；C表示服务关联参数。

作为一种实现方式，多层级服务资源全局监测模型中的所有参数可以写入数据表(或数据库)中进行存储，根据监测到的服务可用性参数、服务性能参数、或服务关联参数，可以定期或即时更新数据表中的内容。理想情况下可以实现实时监测与更新。

多层级服务资源全局监测模型的具体数据结构可以包括但不限于数组、矩阵、数据表等元素集合形式。本领域技术人员可以根据多层级服务资源全局监测模型的数据内容，输出二维或三维图像。

S23：基于多层级服务资源全局监测模型，生成服务资源池的评估结果。

评估结果包括评估分数或评估等级，通过以分数、等级等展现形式更容易让用户直观得知服务运行情况。其中，通过S23生成的评估结果可以包括全局评估结果以及多个维度下的子评估结果，全局评估结果可以通过在各个子评估结果之间以加权计算的方式得到。

在具体应用时，可以通过一个总分/等级以综合评估服务资源池的整体情况，还可以通过多个维度的分数/等级分别对服务资源池在可用性、性能质量、调用关系等维度下进行评估，从而分别在多个维度下对服务资源池的综合运行情况进行监测评估。本领域技术人员可以根据实际需要设置评估结果的展现形式，可以是计算出的评估分数，也可以是基于评估分数所在的分数区间确定的评估等级。

在上述S21-S23中，是基于Web服务可用性评价、Web服务可信度评价、Web服务本体及服务链等理论，提出私有云环境下的服务资源整体性、全局性监测框架，即，以私有云环境下的服务资源池为监测对象，综合提取服务资源池的多维度指标(服务可用性、服务性能、服务间的关联)，将服务资源池视为一个整体监测对象，将服务资源池中的各个微服务视为局部监测对象，构建一种描述“可用-性能-关系”的多层级服务资源全局监测模型，从而建立应用资源的全局关联监测机制。

在上述方法中，通过以私有云环境下的服务资源池作为监测对象，综合提取服务资源池的多种参数并构建用于反映服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征的多层级服务资源全局监测模型，不仅有利于用户从宏观上得知整个服务资源池的运行情况，还有利于根据构建出的多层级服务资源全局监测模型及时对服务资源进行前瞻性地调整，从而可以降低故障发生的风险。

可选地，请参阅图3，在上述S22之后可以执行步骤S24。

S24：基于多层级服务资源全局监测模型，在显示界面上以预设的至少一种展示模式显示服务资源池的多层级监测结果，多层级监测结果包括服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征。

其中，可以对构建多层级服务资源全局监测模型的服务可用性参数、服务性能参数、服务关联参数进行统一记录，并将统计的参数以预设的至少一种展示模式进行可视化显示，且可视化的内容可根据参数或模型的更新而进行刷新显示，从而直观展现私有云环境下的服务资源监测状况。

本申请实施例中的“多层级监测”是指：对整个服务资源池的全局监测、微服务间监测以及微服务级监测这三个层级的监测。

全局性资源特征可以是服务资源池的当前可用服务数量，例如从服务注册中心检索到的服务注册量，微服务间资源特征可以是用于反映微服务之间相互调用关系的分布式服务追踪链路，微服务级资源特征可以是服务并发数、吞吐量、延迟量等。

预设的至少一种展示模式包括但不限于：折线图、饼图、柱状图、散点图、气泡图、雷达图等。这些展示模式可以组合使用。

作为一种实施方式，可以将全局性资源特征、微服务间资源特征以及微服务级资源特征分别以各自预设的展示模式进行可视化显示，以便于用户能够直观得知特征参数的变化。例如，可以将统计得到的服务可用性参数以柱状图、折线图、饼图等形式进行展示，以体现出服务资源池中的可用服务数量，可以将服务性能参数中的各组子参数(一个微服务可以对应一组子参数)分别以不同的折线图进行显示，以体现出各个微服务的服务性能变化，可以将服务关联参数以折线图、柱状图、气泡图(数值越大，气泡形状越大)等形式进行显示，以体现出分布式服务追踪链路数量变化。再例如，整个服务资源池中的各个微服务可以作为气泡图中的气泡、散点图中的散点，当需要查看对于选中的部分微服务的相关监测结果时，可以将被选中的部分微服务的相关参数以折线图、饼图、柱状图、雷达图等形式进行展示，从而展示多维度的监测结果。

在一个应用场景下，可以基于微服务的服务标识码以及统计得到的服务可用性参数、服务性能参数、服务关联参数，以各种参数分别对应的预设阈值进行比较，从而对服务资源池中的各个微服务进行分类或分级。以此有利于筛选出哪些是近期或临近节假日需要重点关注的微服务，哪些是使用频率较少的微服务，哪些是故障频发的微服务，从而便于运维人员根据多层级监测结果快速确定需要关注或处理的微服务。

在另一个应用场景下，可以在接收到数据筛选操作时，根据数据筛选操作中的阈值对服务资源池中的各个微服务进行筛选，从而将筛选出的微服务的监测结果以预设的展示模式进行展示。

通过上述实现方式，可以将服务资源池的多层级监测结果进行可视化，有利于用户更为直观地得知服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征，便于运维人员从宏观以及微观角度对服务资源进行处理。其中，上述S24可以与S23组合使用，以对S23生成的服务资源池的评估结果进行可视化展示。

作为一种实现方式，上述S23可以包括：S231-S232。

S231：基于多层级服务资源全局监测模型，生成服务资源池在多个维度下的子评估结果。

其中，该多个维度下的子评估结果可包括供给评估结果、网络性能评估结果、调用评估结果。

例如，可以通过统计服务资源池的服务注册量，根据服务注册量的变化、可用服务在整个服务资源池中的比例等，计算供给评估结果。而针对评估指标较为复杂、需要通过多种类型的参数评价同一类属性的场景，可以通过加权计算的方式得到评估结果。例如，在需要通过并发量、吞吐量、延迟量等参数综合评价单个服务的综合网络性能时，可以预先对并发量、吞吐量、延迟量等指标分别设定每个指标的性能加权系数，从而得到单个服务的网络性能评估分数。以此原理可以对服务资源池中的每个微服务，根据设定的性能加权系数对单个服务的多种服务性能参数进行加权计算，得到单个服务的性能评估分数，通过对服务资源池中的所有服务的性能评估分数求平均，可以得到服务资源池的性能评估分数，作为整个服务资源池的网络性能评估结果。

通过对服务资源池中的各个服务之间的调用关系进行监测，统计出每个服务自身所调用的服务以及被调用的服务，可以筛选出一段时间内调用次数或被调用次数达到设定次数的服务，还可以通过计算单个服务的调用次数和被调用次数之比得到单个服务的调用性能评估结果，以此有利于预估哪些服务适合在什么时候进行迁移或更新，从而尽可能降低因服务暂时不可用而带来的不良影响。

S232：根据多个维度下的子评估结果以及设定的多维指标加权系数，计算得到服务资源池的全局评估分数或全局评估等级。

其中，一个子评估结果对应一个指标加权系数，通过将每个维度下的子评估结果分别乘以相应维度的指标加权系数后求和，可以得到服务资源池的全局评估分数。基于计算出的全局评估分数所在的分数区间可以确定全局评估等级。

通过上述S231-S232的实现方式，先为服务资源池生成多个维度下的子评估结果，再根据多个维度下的子评估结果和设定的多维指标加权系数进行加权计算，从而得到整个服务资源池的全局评估分数或全局评估等级作为评估结果，以此可以对服务资源池进行综合评估和细化评估。

作为S231-S232的一种应用场景，服务资源池的评估结果包括全局评估等级，在监测到全局评估等级低于设定的等级阈值时，可以发出预警提示信息；响应用户对于预警提示信息的检查操作，检查操作中可以携带用户输入或选定或默认设置的检查项目。根据检查操作中的每个检查项目可以分别输出服务资源池在各个检查项目下的子评估等级。由于等级本身可以由分数转换得到，在该应用场景中的各个评估等级的确定方式可以参考S231-S232的评估结果计算方式。

以此可以及时根据服务资源池的全局评估等级进行预警提示，并根据接收到的检查操作输出多个检查项目下的子评估等级，有利于让用户先从宏观上得知整个服务资源池的综合运行情况有多严重，再根据各个检查项目下的各个子评估等级进行处理，上述方法有利于为用户的后续运维操作提供数据参考，在一定程度上可以避免用户因面临的异常点过多而无法快速确定先处理哪方面问题的情况。

可选地，在通过本申请实施例的方法对私有云环境下的服务资源池进行监测时，还提供了一种描述微服务个体的标识方式，在本申请实施例提供的服务资源监测方法中还可以包括步骤S20。

S20：对于服务资源池中的目标服务，以目标服务的唯一服务标识码作为基础标识，基于目标服务的服务提供者所在地以及基础标识，为目标服务生成带有地理空间特征的应用资源本体标识，目标服务是服务资源池中的任一个微服务。

对于传统的微服务，基于Web服务本体理论的服务本体唯一性思想，每个微服务具有其唯一的服务标识码，例如，UUID(Universally Unique Identifier，通用唯一识别码)、GUID(Globally Unique Identifier，全局唯一标识符)、自增ID等服务标识码。其中，UUID是一个由4个连字号将32个字节长的字符串分隔后生成的字符串，总共度36个字节长，通过UUID可以无需考虑数据库建立时的名称重复问题。GUID是微软对UUID标准的一种实现。自增ID是在设计标识时将ID字段的值设为自增的形式。

而在本申请实施例中，监测对象是私有云环境下的服务资源池，在私有云环境下，服务资源池中的各个微服务可能是跨地理区域进行部署的，面向私有云环境下的跨地理区域应用资源的服务级、服务间、全局监测需求，通过上述S20可以将基于位置的地理空间唯一标识算法与传统服务唯一标识构造算法相结合，从而为服务资源池中的各个微服务构造新的服务标识码，即，带有地理空间特征的应用资源本体标识。

作为一种实施方式，应用资源本体标识的标识构造算法可以表示为：SID＝{GRID+UID}。其中，SID为应用资源本体标识；GRID为服务提供者的物理位置的地理网格标识码，例如GeoHash编码；UID为传统的唯一服务标识码，例如GUID、UUID、自增ID等。由于应用资源本体标识SID结合了服务提供者的地理空间特征以及传统的服务标识码，应用资源本体标识SID仍然具有唯一性，可称作应用资源本体唯一性标识。

通过上述S20的实现方式，在微服务的唯一服务标识码的基础上，基于微服务的服务提供者所在地生成了带有地理空间特征的应用资源本体标识，以应用资源本体标识作为微服务的新标识，以此有利于快速确定出异常服务的地理空间位置，便于进行故障排查。例如，在存在1000个微服务的情况下，有50个微服务出现了功能异常，在传统方案中需要依据出现故障的功能进行复杂的排查手段以得知是哪里的服务出现了异常，然后进行诊断处理，传统方式只能得知微服务在逻辑上的标识，难以落实到物理排查，排查效率低，而通过上述S20构造的应用资源本体标识可以直接从名称上反映出异常服务所分布的区域，可以得知微服务部署地的机房位置。在这样的情况下，结合上述S24进行可视化，可以较为直观地得知各个微服务的分布情况，例如，可以显示W市有多个服务部署区域，且该多个服务部署区域中以不同的颜色对正常、异常的服务进行区分，以此便于用户快速、直观得知异常服务的分布情况。

其中，异常服务包括但不限于：出现网络异常、供电异常、负载异常的服务。

可选地，基于上述S20为服务资源池中的各个微服务生成应用资源本体标识后，上述方法还可以包括：步骤S25。

S25：基于服务资源池中的各个微服务的应用资源本体标识，确定服务资源池中的异常服务的实体区域，或，统计得到异常服务的频发区域。

其中，可以通过分析服务日志的方式确定异常服务，并基于异常服务的应用资源本体标识确定异常服务的实体区域。异常服务的实体区域可以通过S24中预设的展示模式进行显示，例如可以通过气泡图显示出不同颜色、不同大小的气泡，通过气泡颜色、气泡大小等要素以区分正常服务与异常服务。

作为一种应用场景，可以在预先构建的服务资源池部署地图上标识出异常服务的实体区域。

根据服务资源池的历史数据，可以筛选或统计出整个服务资源池中出现一段时间内(例如半天、一天、三天、一周内)出现异常的次数超过设定次数的服务，并基于筛选或统计出的各个服务的应用资源本体标识，从应用资源本体标识中提取这些服务的地理空间特征，以此确定并显示异常服务的频发区域。

在面临大量微服务的场景时，通过上述S25的实现方式，有利于运维人员缩小对于异常服务的排查区域，提升故障排查效率，通过统计异常服务的频发区域有利于用户为制定资源调整策略提供数据参考依据。

下面结合图4将对S21中的参数获取细节进行介绍。

请参阅图4，在S21中，获取服务资源池的服务可用性参数的过程，可以包括子步骤S211。

S211：以服务资源池中的各个微服务的服务标识码作为索引，对服务注册中心的注册资源池进行状态监测，得到服务资源池的服务注册量，作为服务资源池的服务可用性参数。

其中，提供同一种服务的功能的设备节点可以有一个或多个，在实际应用中，服务的一对多模式较为常见，例如对于“提交订单”、“支付”等功能，提供“提交订单”这一功能的后台微服务个体可能有多个(例如10个、20个、50个、100个等)，且各个微服务实例的网络地址有可能是动态分配的，因此，对于在服务注册中心(Registry)注册的服务，会采用服务发现机制以确认一个服务是否可用。

对于服务注册状态，可通过开发Java服务后台对服务资源(即微服务)的注册状态进行实时计算和状态监控，并将注册状态返回给监测节点。

本申请实施例通过监测处于已注册状态下的服务注册量可以得知当前可用的服务量，从而反映出当前服务资源池的各服务所支持的功能在整体上的可用性。

作为一种实现方式，在通过S211对服务注册中心的注册资源池进行状态监测时，可以将S20构建的应用资源本体标识SID作为微服务的唯一性标识(即索引键值)，对服务注册中心(Registry)的注册资源池进行状态检索。对于监测的每个服务，如果服务的注册状态是“已注册”，则返回第一预设值(例如返回1)，如果未检索到该服务的注册状态或注册状态是“注销”，则返回第二预设值(例如返回0)。通过对所有处于已注册状态的服务进行统计，即可得到服务资源池的服务注册量，还可以对已注册的服务进行分类显示，例如，可依据服务功能显示各个功能下已注册的可用服务量。

其中，服务注册中心(Registry)是微服务架构下与服务提供者(RPC Server)、服务消费者(RPC Client)进行配合的一种角色。在微服务架构下，服务提供者可根据服务发布文件中的配置信息向服务注册中心注册自身服务，并向服务注册中心定期发送心跳，以汇报存活状态；服务消费者可根据服务引用文件中的配置信息向服务注册中心订阅服务，把服务注册中心返回的服务节点列表缓存在本地内存中，并与服务提供者建立连接。当服务提供者的设备节点发生变更时，服务注册中心会进行同步变更，在服务消费者感知到变更后，会刷新本地内存中缓存的服务节点列表。

通过S211的实现方式给出了一种用于在服务资源监测过程中表征服务可用性的全局监测指标，通过对服务注册中心的注册资源池进行状态监测，得到各个服务功能下的服务注册量，从而反映出各个服务功能的可用服务数量，可基于此统计出整个服务资源池的可用服务情况，实现全局监测。

在S21中，获取服务资源池的服务性能参数的过程，可以包括子步骤S212。

S212：对服务资源池的各个微服务进行日志分析，得到每个服务的服务并发数、服务吞吐量、服务延迟量中的至少一种，将所有服务的服务并发数、服务吞吐量、服务延迟量中的至少一种作为服务资源池的服务性能参数。

其中，可以将服务资源池中的所有服务在服务并发数、服务吞吐量、服务延迟量中的至少一种参数作为服务资源池的服务性能参数。

目标服务的平均并发用户数量C＝n*L/T。C是平均并发用户数，n是平均每天访问的用户数(login session)，L是一天内用户从登录到退出的平均时间(login session的平均时间)，T是考察时间长度(一天内多长时间有用户使用系统)。基于平均并发用户数量可以预设的峰值模拟方式模拟计算并发用户峰值，从而有利于运维人员提前对目标服务进行调整。

在一个应用场景下，开发Java服务后台对目标服务的调用并发数量进行计算，并定期更新，回传到监测节点，本领域技术人员可以根据实际需要对私有云智能办公系统进行持续监测，从而进行长周期(例如一天、两天、一周)日志分析计算，评估得到服务的平均并发用户数量，作为目标服务的服务并发数，以此原理可以得到服务资源池中的各个服务的服务并发数，监测节点可对各个服务的服务并发数进行分类、排序、显示。

服务吞吐量是单位时间内的服务请求数量，可以通过服务日志分析方法计算得到。通过开发Java服务后台对单位时间内的服务资源的请求数进行监测统计，并对结果进行定期更新、回传到监测节点，监测节点可对各个服务的吞吐量进行分类、排序、显示。

服务延迟量是目标服务对请求(业务请求或服务请求)进行响应所需要的时间，可以通过服务日志分析方法计算得到。通过开发Java服务后台持续对服务资源的响应时间进行监测，并定期更新、回传到监测节点，监测节点可对各个服务的吞吐量进行分类、排序、显示。

上述的服务并发数、服务吞吐量、服务延迟量均可作为衡量服务资源池的服务性能的参数，在监测服务并发数、服务吞吐量、服务延迟量时，可基于传统的日志分析方式收集服务并发数、吞吐量、网络延迟情况。在微服务架构中，一个业务请求会经历多个服务，每个服务可能提供给多个业务模块进行调用，通过收集端到端链路上的访问日志、服务提供者的运行日志有利于确定发生故障的原因或发生故障的位置。通过收集并分析各个服务的运行日志、访问日志可以得到服务并发数、服务吞吐量、服务延迟量等服务性能参数。

本领域技术人员可以根据实际需要选用日志分析工具对服务的运行日志或访问日志进行收集、分析挖掘处理，例如，可以选用ExceptionLess、LEK(logstash,elasticsearch,kibana)等工具进行日志处理，也可以通过轻量级的日志传输组件filebeat将记录到本地的日志进行转发，通过Kafka组件将日志接入统一的接口进行存储、分析。

通过上述S212的实现方式给出了一种用于在服务资源监测过程中表征服务质量的服务级监测指标，通过这些指标构建整个服务资源池的多层级服务资源全局监测模型，可以在进行全局监测的基础上得知各个服务的微观表现，实现多层级监测。

在S21中，获取服务资源池的服务关联参数的过程，可以包括子步骤S213。

S213：调用分布式链路追踪组件对服务资源池中的各个微服务之间的调用关系进行监测，得到服务资源池的分布式服务追踪关联链路数量，作为服务资源池的服务关联参数。

其中，在微服务架构下，微服务数量多，调用关系复杂，一个业务请求会经过多个微服务进行处理，形成一条调用关系链。通过在同一条调用关系链中传输Trace ID这一链路调用唯一标识可以对该调用关系链进行标记。一条调用关系链上存在多个微服务节点，一个微服务节点可以是一个服务器。通过对Trace ID的追踪记录，可以确定微服务架构下的各条调用关系链中涉及的业务请求过程，并可以根据确定的业务请求过程针对性的将同一条调用关系链上的日志进行关联。对于一条调用关系链上的单个节点的处理延时，可以在一个请求到达一个服务时，通过一个时间戳标记(Span ID)对该服务的开始处理时间、结束处理时间进行记录，从而得到处理延时，基于时间戳标记(Span ID)也可确定一个节点在调用关系链中所处的位置。

在本申请实施例中，服务资源池的服务关联参数可以量化为分布式服务追踪关联链路数量，可表示为分布式Trace ID数目。分布式Trace数目可通过分布式链路追踪组件计算得到。

对于分布式服务追踪关联链路数量，通过开发Java服务后台可以调用分布式链路追踪组件对服务资源的分布式Trace ID数目进行轮巡和请求，分布式链路追踪组件可对服务资源之间的调用关系进行监测，并将监测结果定期回传到开发Java服务后台或其他监测节点。

本领域技术人员可以根据实际业务选择需要的分布式链路追踪组件对各个微服务之间的调用关系进行监测，常见的分布式链路追踪工具包括：Google的Dapper，Twitter的“ZipKin”，京东商城的“Hydra”，大众点评网的“CAT”等。

通过上述S213的实现方式给出了一种用于在服务资源监测过程中表征服务调用关系的服务间监测指标，以此原理对整个服务资源池中的所有服务进行监测，获取得到整个服务资源池中的分布式服务追踪关联链路数量，基于此构建的多层级服务资源全局监测模型可以在实现全局监测的情况下，反映出服务资源池中的服务间调用关系。以此有利于为运维人员对故障的服务以及故障服务所在的链路进行快速维护提供数据参考。

请参阅图4，在具体实施时，上述S211、S212、S213可以并行执行。一旦获取到服务可用性参数、服务性能参数、服务关联参数中的任一种参数，可以对多层级服务资源全局监测模型进行更新，并基于新的多层级服务资源全局监测模型显示新的多层级监测结果或新的评估结果，即，对可视化的内容进行更新。

可选地，可以在下一次获取到服务资源池的服务可用性参数、服务性能参数、服务关联参数中的任一种参数时，对多层级服务资源全局监测模型进行更新，以此有利于对私有云环境下的服务资源池进行多层级实时监测。

通过上述方法，在传统服务个体及服务调用监测基础上，对私有云环境下的服务资源池进行多层级的全局监测，以带有地理空间特征的应用资源本体标识对服务资源进行标识，以服务注册状况、服务并发数、服务吞吐量、服务延迟量、关联链路等多种类型的参数构建多维度的监测指标集，并基于此构建多层级服务资源全局监测模型，同时实现对于私有云环境下整个服务资源池的全局性、服务间、服务级三个层次的监测方法，改善了服务资源的全局综合性监测问题，有利于运维人员快速定位出异常服务、及时发现异常源、异常调用链并进行维护，有利于提升私有云服务系统的安全性、稳定性。

在未有其他说明的情况下，本领域技术人员可以根据实际需要任意设置本申请实施例中的设定值(例如设定的系数、次数、阈值等)。

基于同一发明构思，请参阅图5，本申请实施例还提供一种服务资源监测装置300，该装置可用于执行前述的服务资源监测方法。

如图5所示，该装置包括：监测模块301、生成模块302。

监测模块301，用于获取私有云环境下的服务资源池的服务可用性参数、服务性能参数、服务关联参数，服务资源池中包括多个微服务。

生成模块302，用于基于服务可用性参数、服务性能参数、服务关联参数，构建服务资源池的多层级服务资源全局监测模型，多层级服务资源全局监测模型用于反映服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征。

生成模块302，还用于基于多层级服务资源全局监测模型，生成服务资源池的评估结果，评估结果包括评估分数或评估等级。

通过上述装置可以执行前述的服务资源监测方法，不仅有利于用户从宏观上得知整个服务资源池的运行情况，还有利于根据构建出的多层级服务资源全局监测模型及时对服务资源进行前瞻性地调整，从而可以降低故障发生的风险。

可选地，该生成模块302还可用于：基于多层级服务资源全局监测模型，生成服务资源池在多个维度下的子评估结果，多个维度下的子评估结果包括供给评估结果、网络性能评估结果、调用评估结果；根据多个维度下的子评估结果以及设定的多维指标加权系数，计算得到服务资源池的全局评估分数或全局评估等级。

可选地，该生成模块302还可用于：对于服务资源池中的每个微服务，根据设定的性能加权系数对单个服务的多种服务性能参数进行加权计算，得到单个服务的性能评估分数；对服务资源池中的所有服务的性能评估分数求平均，得到服务资源池的性能评估分数，作为网络性能评估结果。

可选地，该装置还可以包括监测响应模块，监测响应模块可用于：在监测到全局评估等级低于设定的等级阈值时，发出预警提示信息；响应对于预警提示信息的检查操作，根据检查操作中的每个检查项目分别输出服务资源池在各个检查项目下的子评估等级。

可选地，该装置还可以包括显示模块，用于基于多层级服务资源全局监测模型，在显示界面上以预设的至少一种展示模式显示服务资源池的多层级监测结果，多层级监测结果包括服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征。

可选地，该装置还可以包括标识构造模块，用于对于服务资源池中的目标服务，以目标服务的唯一服务标识码作为基础标识，基于目标服务的服务提供者所在地以及基础标识，为目标服务生成带有地理空间特征的应用资源本体标识，目标服务是服务资源池中的任一个微服务。

可选地，该装置还可以包括分析模块，用于基于服务资源池中的各个微服务的应用资源本体标识，确定服务资源池中的异常服务的实体区域，或，统计得到异常服务的频发区域。

可选地，该监测模块301还可用于：以服务资源池中的各个微服务的服务标识码作为索引，对服务注册中心的注册资源池进行状态监测，得到服务资源池的服务注册量，作为服务资源池的服务可用性参数；对服务资源池的各个微服务进行日志分析，得到每个服务的服务并发数、服务吞吐量、服务延迟量中的至少一种，所有服务的服务并发数、服务吞吐量、服务延迟量中的至少一种作为服务资源池的服务性能参数；调用分布式链路追踪组件对服务资源池中的各个微服务之间的调用关系进行监测，得到服务资源池的分布式服务追踪关联链路数量，作为服务资源池的服务关联参数。

可选地，该生成模块302还可用于：在下一次获取到服务资源池的服务可用性参数、服务性能参数、服务关联参数中的任一种参数时，对多层级服务资源全局监测模型进行更新。

关于服务资源监测装置300的其他细节，请参考前述服务资源监测方法中的相关描述，在此不再赘述。

除了上述实施例以外，本申请实施例还提供一种存储介质，该存储介质上存储有处理器可执行的计算机程序，计算机程序被处理器执行时执行前述的方法。存储介质可包括：硬盘、存储器等各种可以存储计算机程序的介质。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。又例如，多个单元或组件可以结合或者可以集成到另一个系统作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。另一点，所讨论的相互之间的连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。另外，可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

需要说明的是，功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以用软件产品的形式体现出来。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

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

Claims (9)

1.一种服务资源监测方法，其特征在于，所述方法包括：

获取私有云环境下的服务资源池的服务可用性参数、服务性能参数、服务关联参数，所述服务资源池中包括多个微服务；

其中，获取所述服务资源池的服务可用性参数的过程，包括：以所述服务资源池中的各个微服务的服务标识码作为索引，对服务注册中心的注册资源池进行状态监测，得到所述服务资源池的服务注册量，作为所述服务资源池的服务可用性参数；

获取所述服务资源池的服务性能参数的过程，包括：对所述服务资源池的各个微服务进行日志分析，得到每个服务的服务并发数、服务吞吐量、服务延迟量中的至少一种，将所有服务的服务并发数、服务吞吐量、服务延迟量中的至少一种作为所述服务资源池的服务性能参数；

获取所述服务资源池的服务关联参数的过程，包括：调用分布式链路追踪组件对所述服务资源池中的各个微服务之间的调用关系进行监测，得到所述服务资源池的分布式服务追踪关联链路数量，作为所述服务资源池的服务关联参数；

基于所述服务可用性参数、所述服务性能参数、所述服务关联参数，构建所述服务资源池的多层级服务资源全局监测模型，所述多层级服务资源全局监测模型用于反映所述服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征；

基于所述多层级服务资源全局监测模型，生成所述服务资源池的评估结果，所述评估结果包括评估分数或评估等级。

2.根据权利要求1所述的方法，其特征在于，所述基于所述多层级服务资源全局监测模型，生成所述服务资源池的评估结果，包括：

基于所述多层级服务资源全局监测模型，生成所述服务资源池在多个维度下的子评估结果，所述多个维度下的子评估结果包括供给评估结果、网络性能评估结果、调用评估结果；

根据所述多个维度下的子评估结果以及设定的多维指标加权系数，计算得到所述服务资源池的全局评估分数或全局评估等级。

3.根据权利要求2所述的方法，其特征在于，所述网络性能评估结果的计算过程包括：

对于所述服务资源池中的每个微服务，根据设定的性能加权系数对单个服务的多种服务性能参数进行加权计算，得到单个服务的性能评估分数；

对所述服务资源池中的所有服务的性能评估分数求平均，得到所述服务资源池的性能评估分数，作为所述网络性能评估结果。

4.根据权利要求1所述的方法，其特征在于，所述服务资源池的评估结果包括全局评估等级，所述方法还包括：

在监测到所述全局评估等级低于设定的等级阈值时，发出预警提示信息；

响应对于所述预警提示信息的检查操作，根据所述检查操作中的每个检查项目分别输出所述服务资源池在各个检查项目下的子评估等级。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

对于所述服务资源池中的目标服务，以所述目标服务的唯一服务标识码作为基础标识，基于所述目标服务的服务提供者所在地以及所述基础标识，为所述目标服务生成带有地理空间特征的应用资源本体标识，所述目标服务是所述服务资源池中的任一个微服务。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

基于所述服务资源池中的各个微服务的应用资源本体标识，确定所述服务资源池中的异常服务的实体区域，或，统计得到异常服务的频发区域。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在显示界面上以预设的至少一种展示模式显示所述服务资源池的多层级监测结果，所述多层级监测结果包括所述服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征。

8.一种服务资源监测装置，其特征在于，所述装置包括：

监测模块，用于获取私有云环境下的服务资源池的服务可用性参数、服务性能参数、服务关联参数，所述服务资源池中包括多个微服务；

所述监测模块，还用于以服务资源池中的各个微服务的服务标识码作为索引，对服务注册中心的注册资源池进行状态监测，得到服务资源池的服务注册量，作为服务资源池的服务可用性参数；对服务资源池的各个微服务进行日志分析，得到每个服务的服务并发数、服务吞吐量、服务延迟量中的至少一种，所有服务的服务并发数、服务吞吐量、服务延迟量中的至少一种作为服务资源池的服务性能参数；调用分布式链路追踪组件对服务资源池中的各个微服务之间的调用关系进行监测，得到服务资源池的分布式服务追踪关联链路数量，作为服务资源池的服务关联参数；

生成模块，用于基于所述服务可用性参数、所述服务性能参数、所述服务关联参数，构建所述服务资源池的多层级服务资源全局监测模型，所述多层级服务资源全局监测模型用于反映所述服务资源池的全局性资源特征、微服务间资源特征以及微服务级资源特征；

所述生成模块，还用于基于所述多层级服务资源全局监测模型，生成所述服务资源池的评估结果，所述评估结果包括评估分数或评估等级。

9.一种服务资源监测设备，其特征在于，包括：

存储器；

处理器；

所述存储器中存储有所述处理器可执行的计算机程序，所述计算机程序被所述处理器执行时执行权利要求1-7任一项所述的方法。

Images