探测基于Kubernetes部署的微服务的可用性的方法、系统及介质与流程

本发明涉及计算机应用技术领域，具体地，涉及一种探测基于kubernetes部署的微服务的可用性的方法、系统及介质。

背景技术：

随着技术的发展，有人提出了一套围绕应用和微服务的云平台，支持私有化部署，具有高可用、统一管控、行业合规的特点，为客户提供数据化转型所需的自主可控、弹性伸缩的全栈服务能力。该平台采用开源kubernetes容器编排引擎，提供业务容器化管理，支持应用自动化部署、弹性伸缩等功能。业务以微服务的方式运行，如何保证业务正常运行，需进行微服务可用性探测。

传统的可用性探测主要用于传统x86(泛指一系列基于intel8086且向后兼容的中央处理器指令集架构)系统，针对微服务的可用性拨测的功能还未成熟，不能进行业务的有效监控。

在现在的运维工作中，运维人员需在生产环境上主动发起针对各产品的带有参数的http(超文本传输协议)请求调用接口，针对得到的返回结果，进行人工比对，从而判断出探测结果正常与否。现有的技术条件下，该方法稳健性差，探测正确性取决于输入的多个参数的正确性；效率较低，需人工手动在指定时间发起请求，人力成本较高，且耗时较长；结果判断较复杂，当接口返回参数较多时，人工一一比对判，需过滤无效信息，针对关键字段判断业务可用性，该过程较复杂，断错误率较高，耗时也较长；安全性较低，在生产环境每日定时进行人为操作，操作风险较高，易对生产数据及环境产生影响。人工运维的操作存在业务探测低效、运维风险高、安全性低的情况，故无法满足微服务业务可用性拨测的需求。

技术实现要素：

鉴于现有技术存在的上述缺陷，本发明实施方式提供了一种探测基于kubernetes部署的微服务的可用性的方法、系统及介质。

在对本发明实施方式的发明内容进行具体说明之前，对本发明实施方式涉及的部分术语进行解释，如下：

kubernetes：一个开源的，用于管理云平台中多个主机上的容器化的应用；

restful：一种软件架构风格、设计风格，提供了一组设计原则和约束条件；

devops：developmentandoperations，一组过程、方法与系统的统称，促进开发、运营和质量保障的整合；

cronjob：cronjob管理基于时间的job，在给定时间点只运行一次，在给定时间点周期性地运行。

一方面，本发明实施方式提供了一种探测基于kubernetes部署的微服务的可用性的方法，包括：

通过前端页面获取用户配置的待探测的微服务的参数信息，所述参数信息被实时存入数据库进行持久化保存，所述参数信息包括data结构体和result结构体，其中，data结构体是发起restfulapi请求时配置的微服务巡检信息，result结构体是期待探测返回的预期结果；

通过后台程序发起restfulapi请求以执行对所述微服务的业务探测，得到业务状态结果；

根据所述预期结果和得到的业务状态结果判断所述微服务的可用性。

在本发明的一些实施方式中，根据所述预期结果和得到的业务状态结果判断所述微服务的可用性包括：

从数据库获取所述预期结果；

将所述预期结果与所述业务状态结果进行对比；

根据所述对比的结果输出所述微服务的可用性的最终判断结果。

在本发明的一些实施方式中，所述方法还包括：将最终判断结果存入数据库进行持久化保存。

在本发明的一些实施方式中，所述方法还包括：通过短信、微信的方式向外部发送最终判断结果。

在本发明的一些实施方式中，所述data结构体包括：请求的域名或者ip地址、请求所带的参数及信息、请求的方式、请求的请求头信息；所述result结构体包括：返回的状态码以及返回的信息。

另一方面，本发明实施方式提供了一种探测基于kubernetes部署的微服务的可用性的系统，包括：

集成工具组件，其提供基础公共服务，所述基础公共服务包括http访问服务、日志服务、数据库服务和缓存服务；

前端展现组件，用于提供用户配置参数用的前端页面和展现探测结果的结果展示页面；

运营运维组件，用于执行下述操作：通过所述http访问服务从所述前端页面获取用户配置的待探测的微服务的参数信息，通过所述数据库服务将所述参数信息实时存入数据库进行持久化保存，所述参数信息包括data结构体和result结构体，其中，data结构体是发起restfulapi请求时配置的微服务巡检信息，result结构体是期待探测返回的预期结果；

通过后台程序发起restfulapi请求以执行对所述微服务的业务探测，得到业务状态结果；

根据所述预期结果和得到的业务状态结果判断所述微服务的可用性，并通过所述结果展示页面呈现判断结果。

在本发明的一些实施方式中，所述系统还包括：

定时任务组件，用于定时调用所述运营运维组件进行业务探测。

在本发明的一些实施方式中，所述系统还包括：

api组件，其包括所述运营运维组件使用的restfulapi接口。

再一方面，本发明实施方式提供了一种探测基于kubernetes部署的微服务的可用性的系统，包括：

存储器，其上存储有计算机可读指令和数据；

处理器，其用于执行所述计算机可读指令并读取所述数据以实现上述探测方法。

又一方面，本发明实施方式提供了一种存储介质，其上存储有计算机可读指令，所述计算机可读指令被处理器执行以实现上述探测方法。

采用本发明各种实施方式，可以实现以下有益效果：

用户可以访问前端页面进行参数配置，使得业务的配置信息修改可动态自适应生效，采用微服务的思想，实现业务实例在可视化界面的弹性伸缩等，无需登录主机修改，用户可自主完成运维工作，无需开发人员支持，是devops的良好实践。

每日定时自动探测业务情况，通过拨测及时探测业务可用性。

计算工作在后端实现(包括数据的结果对比、分析)，减少前端负载，对客户端友好。

探测结果通过web界面可实时展示，供用户查询产品可用性情况。

结果比对、分析工作尽量在后端完成，对客户端友好。

附图说明

图1是根据本发明实施方式的探测微服务可用性的系统的架构层次；

图2是根据本发明实施方式的产品巡检的流程示意图；

图3是根据本发明一种实施方式的一种探测基于kubernetes部署的微服务的可用性的方法的流程图；

图4是根据本发明另一种实施方式的一种探测基于kubernetes部署的微服务的可用性的方法的流程图；

图5是根据本发明又一种实施方式的一种探测基于kubernetes部署的微服务的可用性的方法的流程图；

图6是根据本发明一种实施方式的一种探测基于kubernetes部署的微服务的可用性的系统的框图；

图7是根据本发明另一种实施方式的一种探测基于kubernetes部署的微服务的可用性的系统的框图；

图8是根据本发明又一种实施方式的一种探测基于kubernetes部署的微服务的可用性的系统的框图。

具体实施方式

为了便于理解本发明技术方案的各个方面、特征以及优点，下面结合附图对本发明进行具体描述。应当理解，下述的各种实施方式只用于举例说明，而非用于限制本发明的保护范围。

根据本发明实施方式，通过构建微服务可用性探测系统，能够动态自适应添加微服务拨测任务，配置信息动态生效，负载分布在集群计算节点，结果实时展示，实现基于微服务restful接口的拨测，完成微服务可用性的探测目标。如图1所示，从系统架构层次角度而言，本发明实施方式的探测微服务可用性的系统主要包括集成工具层、运营运维层、api层、前端展现层以及定时任务层，下面对各层进行具体说明。

集成工具层

集成工具层主要提供基础公共服务，主要包括http访问服务、日志服务、数据库服务和缓存服务，这些服务供上层组件调用。

1)http访问服务基于request包提供restfulapi调用，为客户端提供web服务，调用云产品和支撑组件接口，得到产品及组件数据和业务可用性情况，实现前后端分离，其中，产品是以微服务的方式实现其功能。

2)日志服务提供产品拨测的访问请求、网络情况和产品返回结果的日志记录。日志服务通过封装日志接口，供其他模块调用。日志服务功能具备如下特点：

a)日志定期归档：可设置日志保留时间，默认保留近7天的日志，防止历史日志量过多占用磁盘空间大。

b)日志规范命名：生成的日志会以模块拼接当日时间戳命名，命名规范，便于查找，定位问题。

c)日志内容清晰：日志输出内容满足系统标准日志输出格式，带有info、debug、error分级。

3)数据库服务提供数据持久化落库服务。所有业务的配置信息和接口信息会动态导入mysql数据库，保证数据的一致性。数据库供缓存数据库获取频繁访问的数据。

4)缓存服务提供前端调用后端数据库时缓存数据的功能。该功能通过开源组件redis实现，实现前端可以快速读取常用数据，减轻数据库读数据负担。

运营运维层

运营端集成了公有云主要产品的数据，包括cbs、cvm、ckv、clb、hdfs以及日常运维所需的产品巡检模块。

各产品自动化运维模块通过调用各产品接口获取所需数据，在前端通过图形化的形式展现，便于客户时刻关注产品具体的信息。

产品巡检模块通过restfulapi实现动态产品拨测，得到各产品业务状态，返回给客户，在前端页面展示。

其中，如图2所示，产品巡检模块流程如下：

步骤1：客户访问devops前端页面

步骤2：客户可以在前端页面进行产品巡检的参数配置，可动态添加和删除，具体信息包括data结构体和result结构体两部分。data结构体是发起restfulapi请求时配置的产品(即微服务)巡检信息，包括请求的域名或者ip地址(url字段)、请求所带的参数及信息(data字段)、请求的方式(method字段)、请求的请求头信息(headers字段)。result结构体是期待产品拨测(即对实现产品功能的微服务的探测)返回的结果需要比对的关键字段，包括返回的状态码(code字段)以及返回的信息(data字段)。

步骤3：配置好的产品参数会实时动态落数据库，进行持久化保存。

步骤4：devops后台程序有两种情况会执行，一种是用户前端进行产品巡检的页面访问时会调用，另一种情况是每日的定时巡检任务会调用。两种情况的业务执行流程在步骤4到步骤7都是一样的，不同点在于当定时巡检任务触发时，在进行步骤9的同时，会异步进行步骤8，进行短信的自动发送，将巡检结果定时同事客户。

步骤5：从数据库中获取各产品拨测的预期结果(result信息)。

步骤6：devops后台程序拨测输出产品业务状态结果(response信息)，即微服务的可用性状态。

步骤7：拨测的预期结果与devops后台程序拨测输出产品业务状态结果两者对比，程序根据对比结果做出实现每个产品的微服务的可用性状态的最终判断，输出为final_result(最终判断结果)。

步骤8：final_result会异步通过短信通知的方式，通过配置短信接收人，发送到相关产品负责人或关联人。

步骤9：final_result会异步存入数据库，进行永久化落库。

步骤10：缓存数据库会根据前端请求项读取数据库内容，便于前端快速访问。

步骤11：前端页面请求数据会先从缓存数据库中读取，若数据存在，则直接返回信息。

api层

api层封装了运营运维层的restfulapi接口，以及可以调用定时任务的两个模块。api接口供前端页面调用访问。

定时任务层

定时任务层集成了kubernetes的cronjob模块，其中包括定时巡检和容量采集。定时巡检模块会调用产品可用性拨测模块，在固定时间进行巡检，并发送巡检结果给相关用户；容量采集定时采集各个产品的容量。两个模块的可由api层直接调用。

前端展现层

前端展现层调用api接口，将接口的返回结果进行前端的逻辑判断后展现。可展示每个产品的业务名、产品名、以及产品状态，例如，可以用颜色表示产品状态，绿色表示“正常”，红色表示“错误”。

基于上述系统架构，如图3所示，本发明实施方式提供的一种探测基于kubernetes部署的微服务的可用性的方法可以包括下述处理：

s010:通过前端页面获取用户配置的待探测的微服务的参数信息，所述参数信息被实时存入数据库进行持久化保存，所述参数信息包括data结构体和result结构体，其中，data结构体是发起restfulapi请求时配置的微服务巡检信息，result结构体是期待探测返回的预期结果。具体而言，所述data结构体包括：请求的域名或者ip地址、请求所带的参数及信息、请求的方式、请求的请求头信息；所述result结构体包括：返回的状态码以及返回的信息。

s020:通过后台程序发起restfulapi请求以执行对所述微服务的业务探测(即拨测)，得到业务状态结果。

s030：根据所述预期结果和得到的业务状态结果判断所述微服务的可用性。

在本发明的一些实施方式中，处理s030可以包括：

从数据库获取所述预期结果；

将所述预期结果与所述业务状态结果进行对比；

根据所述对比的结果输出所述微服务的可用性的最终判断结果。

如图4所示，在本发明的另一种实施方式中，所述微服务的可用性的探测方法可以包括：

s010:通过前端页面获取用户配置的待探测的微服务的参数信息，所述参数信息被实时存入数据库进行持久化保存，所述参数信息包括data结构体和result结构体，其中，data结构体是发起restfulapi请求时配置的微服务巡检信息，result结构体是期待探测返回的预期结果。具体而言，所述data结构体包括：请求的域名或者ip地址、请求所带的参数及信息、请求的方式、请求的请求头信息；所述result结构体包括：返回的状态码以及返回的信息。

s020:通过后台程序发起restfulapi请求以执行对所述微服务的业务探测(即拨测)，得到业务状态结果。

s030：根据所述预期结果和得到的业务状态结果判断所述微服务的可用性。

s040:将最终判断结果存入数据库进行持久化保存。

如图5所示，在本发明的另一种实施方式中，所述微服务的可用性的探测方法可以包括：

s010:通过前端页面获取用户配置的待探测的微服务的参数信息，所述参数信息被实时存入数据库进行持久化保存，所述参数信息包括data结构体和result结构体，其中，data结构体是发起restfulapi请求时配置的微服务巡检信息，result结构体是期待探测返回的预期结果。具体而言，所述data结构体包括：请求的域名或者ip地址、请求所带的参数及信息、请求的方式、请求的请求头信息；所述result结构体包括：返回的状态码以及返回的信息。

s020:通过后台程序发起restfulapi请求以执行对所述微服务的业务探测(即拨测)，得到业务状态结果。

s030：根据所述预期结果和得到的业务状态结果判断所述微服务的可用性。

s040:将最终判断结果存入数据库进行持久化保存。

s050：通过短信、微信的方式向外部发送最终判断结果。

此外，在本发明的一些可选实施方式中，可以省略图5中的处理s040，即将最终判断结构直接向外部发送给相关人员。

基于上述系统架构和方法，本发明实施方式还提出了一种探测基于kubernetes部署的微服务的可用性的系统，本文亦称为“微服务可用性探测系统”。

如图6所示，在本发明的一种实施方式中，所述微服务可用性探测系统可包括：

集成工具组件100，其提供基础公共服务，所述基础公共服务包括http访问服务、日志服务、数据库服务和缓存服务；

前端展现组件200，用于提供用户配置参数用的前端页面和展现探测结果的结果展示页面；

运营运维组件300，用于执行下述操作：

通过所述http访问服务从所述前端页面获取用户配置的待探测的微服务的参数信息，通过所述数据库服务将所述参数信息实时存入数据库进行持久化保存，所述参数信息包括data结构体和result结构体，其中，data结构体是发起restfulapi请求时配置的微服务巡检信息，result结构体是期待探测返回的预期结果；

通过后台程序发起restfulapi请求以执行对所述微服务的业务探测，得到业务状态结果；

根据所述预期结果和得到的业务状态结果判断所述微服务的可用性，并通过所述结果展示页面呈现判断结果。

如图7所示，在本发明的另一种实施方式中，所述微服务可用性探测系统可进一步包括：

定时任务组件400，用于定时调用所述运营运维组件300进行业务探测。

如图8所示，在本发明的又一种实施方式中，所述微服务可用性探测系统可进一步包括：

api组件500，其包括所述运营运维组件300使用的restfulapi接口。

在本发明的其他实施方式中，一种探测基于kubernetes部署的微服务的可用性的系统可包括：

存储器，其上存储有计算机可读指令和数据；

处理器，其用于执行所述计算机可读指令并读取所述数据以实现上述各实施方式所进行的探测或拨测方法。

此外，本发明实施方式提供了一种存储介质，其上存储有计算机可读指令，所述计算机可读指令被处理器执行以实现上述各实施方式所进行的探测或拨测方法。例如，所述存储介质可以包括软盘、磁带、磁盘、光盘、闪存、硬盘等。

以上具体描述了本发明的各种不同的实施方式，下面以另一种形式描述本发明实施方式的技术方案的其他方面或特征，并且不限于下述一系列段落，为了清楚和有效起见，可给这些段落中的一些或所有段落指定字母数字。这些段落中的每一段可以以任何合适的方式与一个或多于一个其他段落组合的内容组。在不限定合适的组合中的一些的实例的条件下，下文中的一些段落特别引用其他段落并且进一步限定其他段落。

1、一种动态自适应的微服务可用性拨测方法，其包括以下步骤：a、采用微服务思想，配置信息修改可动态自适应生效；b、基于cronjob自动定时探测业务的可用性；c、服务可用性拨测结果展示，基于restful与后端动态交互。

2、如段落1所述的微服务可用性拨测方法，其中，处理a可以包括：

a1、客户在前端页面进行产品巡检的参数配置，可动态添加和删除，具体信息包括data结构体和result结构体两部分。data结构体是发起restfulapi请求时配置的产品巡检信息，包括请求的域名或者ip地址(url字段)、请求所带的参数及信息(data字段)、请求的方式(method字段)，请求的请求头信息(headers字段)。result结构体是期待产品拨测返回的结果需要比对的关键字段，包括返回的状态码(code字段)以及返回的信息(data字段)；

a2、配置好的产品参数会实时动态落数据库，进行持久化保存；

a3、devops后台程序在用户前端进行产品巡检的页面访问时会调用，另一种情况是每日的定时巡检任务会调用。每次调用时，后台程序读取数据库信息，配置动态生效；

a4、计算工作在服务器端实现，对客户端友好。

3、如段落2所述的微服务可用性拨测方法，其中，处理b可以包括：

b1、定时任务层集成了kubernetes的cronjob模块，其中包括定时巡检和容量采集；

b2、定时巡检模块会调用产品可用性拨测模块，在固定时间进行巡检，并发送巡检结果给相关用户；

b3、容量采集定时采集各个产品的容量。两个模块的可由api层直接调用。

综上所述，根据本发明实施方式提出的微服务可用性探测方案，用户可以访问前端页面进行参数配置，使得业务的配置信息修改可动态自适应生效，采用微服务的思想，实现业务实例在可视化界面的弹性伸缩等，无需登录主机修改，用户可自主完成运维工作，无需开发人员支持，是devops的良好实践。每日定时自动探测业务情况，通过拨测及时探测业务可用性。计算工作在后端实现(包括数据的结果对比、分析)，减少前端负载，对客户端友好。拨测结果通过web界面可实时展示，供用户查询产品可用性情况。结果比对、分析工作尽量在后端完成，对客户端友好。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件结合硬件平台的方式来实现。基于这样的理解，本发明的技术方案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

本领技术人员应当理解，以上所公开的仅为本发明的实施方式而已，当然不能以此来限定本发明之权利范围，依本发明实施方式所作的等同变化，仍属本发明权利要求所涵盖的范围。