CN112804362B - 分散数据微服务自动化运维体系 - Google Patents

Abstract

本发明提供了分散数据微服务自动化运维体系，包括自动运维系统及边缘网关，所述自动运维系统与kubernetes贴合使用，能够控制pod伸缩贴合微服务，实时对kubernetes做出资源调配动作，多个所述微服务通过所述边缘网关与外部连网，所述边缘网关为统一管理处理微服务的路由网关。本发明既能解决Pod动态伸缩提高资源利用率的问题，也能解决微服务本身高并发在更换部署环境后所面临的问题，同时也要简化运维配置，提高工作效率。

Description

分散数据微服务自动化运维体系

技术领域

本发明涉及微服务资源配置技术领域，特别涉及基于kubernetes（一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效，Kubernetes提供了应用部署，规划，更新，维护的一种机制）的分散数据微服务自动化运维体系。

背景技术

在当今社会，各行各业的应用“互联网+”的规模越来越大，很多行业应用产生的数据已经远远超出传统企业的数据处理能力，传统的单体架构无法承受大量用户的访问使用，微服务应运而生。微服务作为一套新的架构风格，将单个应用程序开发划为一组细粒的服务，每个服务运行在自己的进程中，服务间有着约定的轻量级通信机制进行交互，一般是HTTP（超文本传输协议，HyperText Transfer Protocol）资源API（应用程序接口，Application Programming Interface）作为通信机制，围绕业务功能构建服务并且独立部署，从而组成一个完整的系统平台为用户提供服务。微服务有着业务粒度小、职责单一、隔离性强、去中心化管理、易管理等特点，但在构建、部署和运维上出现不少难题，就部署而言，微服务的单一应用实例数量过多，相应的部署配置和监控的体量也就更大，并且一个应用的修改会引起与之关联的其他应用的改动，从而造成部署复杂的情况。

从现有研究可以看出，针对kubernetes现有的问题很多学者提出了各自不同的解决方案，但总的来说，在有效的控制Pod（是一种简单而易用的标记型语言）伸缩、应对实际应用中遇到的多样化数据以及针对高并发的分散数据微服务容器化部署kubernetes进行容器编排这样业务需求等方面还可以有更大的改动空间。

当前kubernetes认为Pod是无状态的，即同一Pod的副本完全一样，这是实现Pod跨节点调度及Pod副本自动伸缩的前提。但是分散数据微服务破坏了这一前提，其Pod副本并不完全一致，以kubernetes设计理念推论，同一业务数据不同将被视为不同应用，那么维护Pod工作量取决于业务数据量，当需要修改业务部署配置时，要对相应的多个Pod进行修改，即存在脚本同步更新问题，也需要大量的YAML（一种直观的能够被电脑识别的数据序列化格式，是一个可读性高并且容易被人类阅读，容易和脚本语言交互，用来表达资料序列的编程语言）配置文件和指令操作，因此运维过程复杂、效率低下。

HPA（HorizontalPodAutoscaling，水平自动伸缩）的方式是在kubernetes内部运行，外部无法对其监测控制，所以对运维人员来说是不可控的，这使得以后的运维工作增加了难度，从而运维人员不能更好地合理化利用资源。另外，当微服务应用部署在kubernetes时，kubernetes通过设置Ingress[一组路由规则的集合，Ingress是kubernetes API的标准资源类型之一，它其实就是一组基于DNS名称（host）或URL路径把请求转发至指定的Service资源的规则，用于将集群外部的请求流量转发至集群内部完成服务发布]资源清单来暴露内部的应用服务，按照这种方式进行暴露，每个微服务的应用都需要对外暴露，没有统一的网关处理，就会导致所有接口向外开放，对系统的安全性能产生极大的威胁。

Kubernetes定义Pod为无状态，所以分散数据架构的微服务在Kubernetes中的Pod副本数据并不完全一致，同一业务数据不同被视为不同应用，就存在运维过程复杂、效率低、不可控、不能更好地资源合理化利用、应用安全性低等问题。

发明内容

本发明提供了分散数据微服务自动化运维体系，其目的是为了解决背景技术中运维过程复杂、效率低、不可控、不能更好地资源合理化利用、应用安全性低的技术问题。

为了达到上述目的，本发明提供的分散数据微服务自动化运维体系，所述分散数据微服务包括多个微服务及多个数据库，多个所述数据库与多个所述微服务一一对应独立设置，多个所述微服务及多个所述数据库采用kubernetes作为微服务部署主体；

本发明提供的分散数据微服务自动化运维体系包括自动运维系统及边缘网关，所述自动运维系统与kubernetes贴合使用，能够控制pod伸缩贴合微服务，实时对kubernetes做出资源调配动作，多个所述微服务通过所述边缘网关与外部连网，所述边缘网关为统一管理处理微服务的路由网关。

优选地，所述自动运维系统以嵌入插件的方式分别与所述kubernetes及所述边缘网关闭环式连接，嵌入插件之间的通信方式采用轻量级机制技术通信。

优选地，所述自动运维系统包括性能采集组件、调度组件、配置中心及同步组件；

所述性能采集组件采集性能指标数据，并传达给所述调度组件；

所述调度组件处理所述性能采集组件采集的性能指标数据，并根据数据类型修改资源配置，将调整后的配置文件传输给所述配置中心；

所述配置中心提取配置文件内容，对kubernetes和边缘网关进行操作资源配置，同时进行包括管理资源配置内容、资源配置修改日志、配置文件版本控制、配置回滚的工作，并将同步配置内容传输给同步组件；

所述同步组件结合所述配置中心最新的配置内容同步操作kubernetes和边缘网关路由资源配置。

优选地，所述同步组件在设置边缘网关路由配置时，根据配置中心的应用比例因子做出相对的配置，当边缘网关拿到比例因子rf之后，根据表达式算出idx；

idx = (mid - (mid % rf))/rf

idx表示微服务进行分散数据的单体应用的标识，根据idx给相应的应用配置路由规则，mid表示用户机器码，用户机器码唯一，同一用户机器码的请求会被路由到指定的应用上处理业务逻辑请求，从而实现分散数据的方式完成微服务的高并发。

优选地，所述边缘网关结合kubernetes中的微服务对流量进行统一入口管理和控制路由，选取Netflix Zuul，或Spring Cloud Gateway，或OpenResty作为边缘网关路由；所述配置中心选取Nacos，或Eureka，或自己编写的服务作为配置中心。

优选地，所述性能采集组件采用prometheus进行数据采集工作，通过选取prometheus的不同的性能指标来进行性能数据采集，以应对微服务应用相关业务多样化数据特征。

优选地，所述prometheus进行数据采集工作包括如下步骤：

步骤S11、prometheus根据其配置文件中的具体报警规则，系统将告警信息推送至prometheus的alermanager模块，根据不同的集群和告警名称，匹配不同的路由进行告警信息的处理；

步骤S12、在alermanager模块收到告警信息之后，alermanager模块根据其配置内容对告警信息处理，发送告警信息，将性能指标数据发送给所述调度组件。

优选地，所述调度组件接收所述性能采集组件的告警内容，判断性能指标数据的类型，并根据性能指标数据的类型对配置中心进行调整，修改配置中心的配置文件。

优选地，所述配置中心中，所述管理资源配置内容、资源配置修改日志、配置文件版本控制、配置回滚的工作采用人工操作的方式进行资源配置修改。

本发明能够取得下列有益效果：

本发明提出的一种分组件的处理策略，该策略可以达到自动化运维的目的，形成一个自动调控的闭环自动化管理运维系统，此外，同步组件在同步配置时也同时修改了相应的网关设置，边缘网关自动配置对应kubernetes内部的微服务应用的路由，实现内部接口端点对外界透明化。这样极大地简化了操作，也减少了运维和开发人员的工作量和操作过程中的失误率，为其带来便捷，让其把精力专注于业务逻辑实现上，提高项目开发效率，减低开发时间成本、预算成本，对资源可以充分地利用。

附图说明

图1为本发明的分散数据微服务自动化运维体系的分散数据微服务一较佳实施例的结构示意图；

图2(a)为本发明的分散数据微服务自动化运维体系的一较佳实施例的示意图；

图2(b)为本发明的分散数据微服务自动化运维体系的自动运维系统一较佳实施例的技术方案框架图；

图3为本发明的分散数据微服务自动化运维体系的自动运维系统一较佳实施例的示意图；

图4为本发明的分散数据微服务自动化运维体系的一较佳实施例的对比实验的部署时间对比图；

图5为本发明的完整的待使用的分散数据微服务自动化运维体系的一较佳实施例的对比实验的启停时间对比图；

图6为本发明的完整的待使用的分散数据微服务自动化运维体系的一较佳实施例的对比实验的扩展时间对比图；

图7为本发明的完整的待使用的分散数据微服务自动化运维体系的一较佳实施例的检测实验的服务器每分钟吞吐量图；

图8为本发明的完整的待使用的分散数据微服务自动化运维体系的一较佳实施例的检测实验的中值对比图；

图9为本发明的完整的待使用的分散数据微服务自动化运维体系的一较佳实施例的检测实验的偏离差异图。

具体实施方式

为使本发明要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。

本发明针对现有的问题，提供了分散数据微服务自动化运维体系，如图1所示，所述分散数据微服务包括多个微服务及多个数据库，多个所述数据库与多个所述微服务一一对应独立设置，多个所述微服务及多个所述数据库采用kubernetes作为微服务部署主体。分散数据微服务为按微服务业务应用进行构建单独的数据库，保证把域数据封装在独立服务中，增强隔离性，保证服务与服务、数据与数据之间独立存在，互不干扰。

本发明的分散数据微服务自动化运维体系是在kubernetes环境部署分散数据微服务应用的场景下，根据各个微服务应用已获得资源情况、应用健壮性和繁忙度等数据，合理调整微服务应用的资源分配和置于集群外部的网络边缘网关的配置情况。

如图2(a)所示，本发明提供的分散数据微服务自动化运维体系包括自动运维系统及边缘网关，所述自动运维系统与kubernetes贴合使用，能够控制pod伸缩贴合微服务，根据微服务容器化部署后产生的多样化问题和保证高并发性能，实时对kubernetes做出资源调配动作，多个所述微服务通过所述边缘网关与外部连网，所述边缘网关为统一管理处理微服务的路由网关。所述自动运维系统以嵌入插件的方式分别与所述kubernetes及所述边缘网关闭环式连接，嵌入插件之间的通信方式采用轻量级机制技术通信。

kubernetes作为部署微服务主体，该自动化运维策略（指本发明的分散数据微服务自动化运维体系）是以嵌入插件的方式接入到系统中，形成一个闭环系统，该主要插件部分分为两个部分，首先与kubernetes贴合使用能够控制Pod合理伸缩贴合微服务的自动化运维系统，另一部分则是根据kubernetes环境和微服务特性在集群外部设置的边缘网关，这样的方式与微服务本身的设计原理类似，在不改动kubernetes的情况下进行解耦联动开发，保证各个部分的强隔离性，在插件之间的通信方式采用轻量级机制技术进行通信，如HTTP资源请求，以保证相互及时通信、相互协调，减少故障率。通过此策略在保证微服务应用高并发能力的前提下，简化运维过程，提高运维效率，保证运维人员实时可控系统，从而更好地合理化利用资源，与此同时保证微服务应用的安全可靠。

该方案是在上述策略的指导下，结合微服务自身特点以及现有技术环境的现状作出的合理技术选型和框架搭建，如图2(b)所示。该方案是分组件式开发，就开发而言，有效的拆分，使得业务分层、解耦、让代码变得更易维护，各业务功能拆分、抽离能保证业务的隔离性和功能的复用性，从而为以后的扩展升级预留空间。

如图3所示，所述自动运维系统根据组件的功能划分，包括性能采集组件、调度组件、配置中心及同步组件；各个组件各司其职，相互协作，串联互通，也能够起到解耦的作用，方便迭代更新重用组件，提高效率。

所述性能采集组件采集性能指标数据，并传达给所述调度组件；

所述调度组件处理所述性能采集组件采集的性能指标数据，并根据数据类型修改资源配置，将调整后的配置文件传输给所述配置中心；

所述配置中心提取配置文件内容，对kubernetes和边缘网关进行操作资源配置，同时进行包括管理资源配置内容、资源配置修改日志、配置文件版本控制、配置回滚的工作，并将同步配置内容传输给同步组件；所述配置中心中，所述管理资源配置内容、资源配置修改日志、配置文件版本控制、配置回滚的工作采用人工操作的方式进行资源配置修改。

所述同步组件结合所述配置中心最新的配置内容同步操作kubernetes和边缘网关路由资源配置。

具体地，所述性能采集组件采用prometheus（一个开源的监控和警报系统）进行数据采集工作，通过选取prometheus的不同的性能指标来进行性能数据采集，以应对微服务应用相关业务多样化数据特征。

prometheus的指标设计提供了丰富多样的采集指标供选择，主要分为四种指标类型，分别为计数器（Counter）、仪表盘（Guage）、直方图（Histogram）、摘要（Summary）。计数器（Counter）代表一种样本数据单调递增的指标，即正常情况下只增不减；仪表盘（Guage）代表一种样本数据可以任意变化的指标，即可增可减；直方图（Histogram）在一段时间范围内对数据进行采样，例如请求持续时间或响应大小，并将其存入配置的存储桶中，后续可通过指定区间筛选样本，也可统计样本总数，最后将数据展示为直方图；摘要（Summary）表示在一段时间内的数据采样结果，直接存储客户端计算统计之后展示出来的分位数。通过选取不同的性能指标来进行性能数据采集以应对微服务应用相关业务多样化数据特征。

所述prometheus进行数据采集工作包括如下步骤：

步骤S11、prometheus根据其配置文件中的具体报警规则，例如通过PromQL（prometheus 内置的数据查询语言,其提供对时间序列数据丰富的查询,聚合以及逻辑运算能力的支持）表达式验证监控CPU（中央处理器，Central Processing Unit)的使用率，如果超过了设定阈值，系统将告警信息推送至prometheus的alermanager（通过命令行flag和一个配置文件进行配置的组件）模块，根据不同的集群和告警名称匹配不同的路由进行告警信息的处理。

步骤S12、在alermanager模块收到告警信息之后，alermanager模块根据其配置内容对告警信息处理，发送告警信息，将性能指标数据发送给所述调度组件。本实验采用web.hook（反向应用程序接口 ，被广泛应用于微服务，即客户端提供一个接口而不主动请求，当服务端的数据发生变化时，主动推送给客户端）的方式处理的告警信息，告警信息会经过分组为alertname（警告名称）的route（路径）向web.hook接收者传递，并向web.hook配置的网络接口http://IP:Port发送告警信息。

所述调度组件接收所述性能采集组件的告警内容，判断性能指标数据的类型，并根据性能指标数据的类型对配置中心进行调整，修改配置中心的配置文件。

所述调度组件主要是对prometheus采集过来的数据进行格式转化，随后针对各个指标问题进行分析，根据设定的规则对目标Pod的进行伸缩扩容操作的相关配置，待配置文件调整完成之后将配置文件传输给配置中心组件，待后续组件进行相关工作处理，该组件是贴合微服务的自动化运维系统的核心组件之一，也是调整微服务在kubernetes中的资源分配以及网络边缘网关的关键核心控制单元。该组件同时要保留往来历史性能指标数据，根据现有设定的规则在累积数据当中挖掘出合适的资源配置内容，以提高资源利用率。

调度组件（SchedulingConfig）是自定义的程序，接收json（一种轻量级的数据交换格式。它基于ECMAScript的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据）告警内容，对内容进行处理，根据json.alerts[i].labels.alertname来判断具体性能指标的类型，根据 json.commonLabels.alername来判断是出问题的主机，根据指标类型来对配置中心进行调整，例如告警内容性能指标是CPU，出问题的主机是IP:9100，表示IP:9100的CPU使用率过高。调度服务根据解析出来的告警内容来修改配置中心的配置文件，对该主机所承载的业务应用进行扩容。

所述配置中心作为核心组件之一，上游组件将数据转化分析处理等操作后生成配置文件上传至配置中心，而后续的同步组件则需要从配置中心提取配置文件内容对kubernetes和网络边缘网关进行操作配置，同时管理资源配置内容、资源配置修改日志、资源配置文件版本控制、配置回滚等。配置中心的作用是配置信息的中转存储，这样做的目的是既能够完成kubernetes里的微服务合理资源调度，又可以在运维过程中进行人为的自定义配置信息。

所述配置中心可选取Nacos（ 一种构建以“服务”为中心的现代应用架构的服务基础设施），或Eureka（ Netflix 出品的用于实现服务注册和发现的工具），或自己编写的服务作为配置中心。配置中心的角色不限定于特定的一个服务，可以是现有的Nacos，也可以是Eureka，更可以是自己编写的服务。

配置中心的选取基于该实验的目的性和目前现有开源技术的先进性以及其开发文档的完整性，本实验采用Nacos服务注册中心作为配置中心。可以通过API接口调用对Nacos进行配置文件的修改。Nacos作为配置中心，本身自带控制面板，可以通过控制面板对配置文件的修改来人工干涉kubernetes的扩缩容，也有利于提高运维效率，此外，Nacos时刻接受同步组件的监听。

所述同步组件结合配置中心的配置文件内容来同步操作看kubernetes和网络边缘网关路由配置，进而简化运维人员的操作，更好地提高效率。所述同步组件在设置边缘网关路由配置时，根据配置中心的应用比例因子做出相对的配置，当边缘网关拿到比例因子rf之后，根据表达式算出idx；

idx = (mid - (mid % rf))/rf

idx表示微服务进行分散数据的单体应用的标识，根据idx给相应的应用配置路由规则，mid表示用户机器码，用户机器码唯一，同一用户机器码的请求会被路由到指定的应用上处理业务逻辑请求，从而实现分散数据的方式完成微服务的高并发。

同步组件是自定义的程序，时刻监听着配置中心的配置文件的变化，当配置文件因人工修改或者调度服务修改而发生变化时，该组件会第一时间将更修改后的配置文件拉取下来进行解析，并根据对kubernetes的微服务业务应用进行编排和网关路由配置进行修改，以保证修改后的配置文件与kubernetes和网关保持一致性。

所述边缘网关结合kubernetes中的微服务对流量进行统一入口管理和控制路由，选取Netflix Zuul（Zuul是从设备和网站到Netflix流应用的后端的所有请求的前门），或Spring Cloud Gateway（Spring Cloud 生态系统中的网关，目标是替代 Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能），或OpenResty[一个高性能网页平台，其内部集成了大量精良的Lua（一个简洁、轻量、可扩展的程序设计语言）库、第三方模块以及大多数的依赖项，用于方便地搭建能够处理超高并发、扩展性极高的动态网页应用、网页服务和动态网关]作为边缘网关路由；

基于OpenResty底层是Nginx（一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP服务器），可以把Nginx的各种功能进行自由拼接，能够满足微服务应用的多样化数据需求，并且体量轻巧，所以本文实验选取的是OpenResty作为边缘服务器，控制微服务路由网关。

本发明提出一种分组件处理策略以实现自动化运维，使用prometheus对Kubernetes以Pod为单位进行资源监控数据采集，调度组件对数据进行分析，调整Kubernetes资源分配和网络边缘网关路由配置，采用配置中心统一管理配置内容，简化配置管理，同步组件根据最新配置信息进行更新动作，达到自动化运维目的。

以下将基于本发明进行实验设置，并对实验结果进行分析。

实验设置：

本实验主要分为两个阶段，第一个阶段需要测试自动化运维系统的三个方面，第一方面是测试自动化运维系统的开发效率，第二方面是对其功能性进行验证，第三方面是测试自动化运维统方式在实际运行环境中的运行响应效果，主要分为手动操作自动化运维系统进行扩展和自动化运维系统自动响应扩展两种方式。本实验中基于虚拟机方式部署、基于Docker的YAML文件部署、基于自动化系统方式部署实验内容主要是针对于第一阶段而设置的。

实验的第二个阶段是要测试基于上述策略的技术解决方案在高并发环境下的性能表现。本实验的高并发实验是针对于第二阶段而设置的。

为了实验的对比，采用自己编写的带有登录功能的微服务应用作为本实验的单体应用，名为user_service，主要通过虚拟机方式、基于Docker（一个开源的应用容器引擎）的YAML文件方式和自动化系统方式这三种方式进行部署该单体应用来作第一阶段的实验对比，此外第二阶段的实验是通过Jmeter（Apache组织开发的基于Java的压力测试工具，用于对软件做压力测试）模拟高并发场景向部署在原kubernetes的环境的微服务和部署在增加了贴合微服务的自动化运维系统和网关的kubernetes环境中的微服务分别发起请求进行测试，根据Jmeter报告参数数据作对比。

1.基于虚拟机方式部署

由于user_service（会员服务）单体应用是用go语言（一种编程语言）编写而成，因此在虚拟机（Linux系统）中部署user_service单体应用很容易，只需将user_service文件和相关配置文件上传至linux（一种自由和开放源码的类UNIX操作系统）目录下，输入”./user_service”指令之后回车即可。但这仅仅只是启动一个应用，作为微服务，要承受高并发访问量，那么就要搭建user_service应用的应用集群，就需要多台机器，不仅浪费了资源，还对集群的搭建增加难度，耗时更长。

2.基于Docker的YAML文件部署

通过Dockerfile文件定义镜像，通过使用Docker的镜像打包命令docker build生成user_service镜像，编写kubernetes的资源清单配置YAML文件，在demo-namespace的命名空间里生成Deployment（部署）资源和对应的Service（服务）资源以及Ingress资源。

3.基于自动化系统方式部署

首先在Nacos的中创建命名空间svc_namespace，在svc_namespace里创建配置文件svc.json，文件中的各个字段数值和解释如表1所示：

表1

手动扩展方式

针对微服务的手动扩展就是修改Nacos中的svc.json文件内容，修改相应字段内容，检验kubernetes集群和OpenResty网关是否相应作出动作，并记录从发布修改后的svc.json文件开始到所有的应用调整完毕后所需要的时间。

自动响应扩展方式

而自动相应扩展方式则是不在人工的操作下，针对不同的用户访问量和集群各个资源处理情况作出对svc.json的内容自动调整，并且集群和网关能够及时作出调整动作，记录从增大访问量到集群和网关调整微服务数量完成所需要的时间以及从减少访问量后集群和网关调整微服务数量完成所需要的时间。

4.高并发实验

高并发实验主要是通过测试原kubernetes的环境（以下简称原环境）部署的微服务的性能与测试添加了贴合微服务的自动化运维系统作为插件嵌入kubernetes的环境（以下简称新环境）部署的微服务的性能进行对比，也就是通过使用JMeter进行性能测试，分别设置100、5000、10000个用户分别并发请求访问，将低、中、高三种情况的测试报告作对比。测试报告中有偏离、吞吐量、中值三个评测标准，偏离表示服务器响应时间变化、离散程度测量值的大小，也就是数据的分布；吞吐量表示服务器每分钟处理的请求数；中值表示时间的数字,有一半的服务器响应时间低于该值而另一半高于该值。

两个环境中部署的微服务是同一个docker镜像，使用的机器设备为同一个，两个环境分别部署在同一物理机，不同虚拟机但CentOs（社区企业操作系统，CentOS 是一个可自由使用源代码的企业级Linux发行版本）镜像相同、虚拟机参数配置相同的环境中。

实验结果与分析：

第一阶段实验结果

本实验对上述实验第一阶段的三种实验的设置分别进行实验测试，并记录其消耗的时间，比较这三种实验方式下的服务性能指标。性能指标参数如表2所示。通过该表可以看出不同实验的部署过程复杂度是不同的。

表2

图4是通过实验得到的服务部署效率对比图，实验主要根据消耗时间长短来作对比。从图4可以看出，自动化系统部署方式在微服务的构建部署比传统虚拟机的构建方式快了很多，极大地提高微服务开发效率。

图5是启停实验的效率对比图，主要依据还是以时间长短来衡量。从图5中可以看出对已经部署好的微服务集群的启停时间在容器+YAML方式和自动化系统部署方式都表现的很好，比虚拟机快很多。

图6是针对三种部署方式的四种扩展方式进行实验的结果对比图，主要依据还是时间长短。从图6中可以看出在扩展微服务时自动化系统部署的两种扩展方式的效果都远优于传统的虚拟机和容器+YAML的效果。

综合3种不同的部署方式部署集群过程所花费的时间的测试分析得出结论：基于kubernetes的分散数据微服务自动化运维系统在部署和运维过程中的效率都比传统虚拟机下提高好几个时间级别，简化开发和运维过程，也保证微服务应用的安全性。

第二阶段实验结果

图7表示服务器每分钟吞吐量图的测试报告图，在原环境和新环境下分别进行100、5000、10000不同程度的并发测试，从该图可以看出，两种环境下的吞吐量处理数量随着并发量的增大而增加，但新环境的处理数量与原环境的相差无几。

图8是两个环境的中值测试数据报告，报告显示随着并发量的增加两个环境的中值数据在5000以前都为增加，在5000之后呈下降趋势。表示着两个环境的一半服务响应时间低于测试值而另一半高于该值的情况变化不大。

图9表示两个环境的偏离差异测试数据报告，从该图可看出随着并发量的增加两个环境下的偏离量都在增加，只是新环境的增长率高于原环境，但总体差异都不是很大，这也表示新环境对高并发的请求处理较分散，去中心化。

综上所述，针对提出的处理策略的性能分两阶段进行评估，第一阶段实验证明该策略效率高、功能性验证和运行效果；第二阶段证明在不损耗并发性能的同时能应对分散数据微服务多样化功能需求和解决运维等问题。

总体来看，新环境下的应用承受并发能力与原环境下的承受能力总体相当，表明在不损耗并发性能的前提之下，该策略解决方案也能应对分散数据微服务多样化功能需求和解决运维、合理化利用资源和安全等问题，能够实现微服务模块的统一管理、实时监控、数据采集、性能分析、自动调度等运维任务，最大程序地减少运维人员的工作量，提高运维效率，同时也能够保证系统的稳定运行，使得业务可持续性和资源的充分利用。

本发明能够取得下列有益效果：

本发明提出的分散数据微服务自动化运维体系，通过一种分组件的处理策略（该策略可以达到自动化运维的目的），形成一个自动调控的闭环自动化管理运维系统，此外，同步组件在同步配置时也同时修改了相应的网关设置，边缘网关OpenResty自动配置对应kubernetes内部的微服务应用的路由，实现内部接口端点对外界透明化。这样极大地简化了操作，也减少了运维和开发人员的工作量和操作过程中的失误率，为其带来便捷，让其把精力专注于业务逻辑实现上，提高项目开发效率，减低开发时间成本、预算成本，对资源可以充分地利用。在不损耗并发性能的同时，最终可以实现以最低成本代价使得系统稳定地高并发，横向扩展，进而获取系统的最高利益。

以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明所述原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (8)

1.分散数据微服务自动化运维体系，所述分散数据微服务包括多个微服务及多个数据库，多个所述数据库与多个所述微服务一一对应独立设置，多个所述微服务及多个所述数据库采用kubernetes作为微服务部署主体，其特征在于，包括自动运维系统及边缘网关，所述自动运维系统与kubernetes贴合使用，能够控制pod伸缩贴合微服务，实时对kubernetes做出资源调配动作，多个所述微服务通过所述边缘网关与外部连网，所述边缘网关为统一管理处理微服务的路由网关；

所述自动运维系统包括性能采集组件、调度组件、配置中心及同步组件；

所述性能采集组件采集性能指标数据，并传达给所述调度组件；

所述调度组件处理所述性能采集组件采集的性能指标数据，并根据数据类型修改资源配置，将调整后的配置文件传输给所述配置中心；

所述配置中心提取配置文件内容，对kubernetes和边缘网关进行操作资源配置，同时进行包括管理资源配置内容、资源配置修改日志、配置文件版本控制、配置回滚的工作，并将同步配置内容传输给同步组件；

所述同步组件结合所述配置中心最新的配置内容同步操作kubernetes和边缘网关路由资源配置。

2.根据权利要求1所述的分散数据微服务自动化运维体系，其特征在于，所述自动运维系统以嵌入插件的方式分别与所述kubernetes及所述边缘网关闭环式连接，嵌入插件之间的通信方式采用轻量级机制技术通信。

3.根据权利要求1所述的分散数据微服务自动化运维体系，其特征在于，所述同步组件在设置边缘网关路由配置时，根据配置中心的应用比例因子做出相对的配置，当边缘网关拿到比例因子rf之后，根据表达式算出idx；

idx = (mid - (mid % rf))/rf

idx表示微服务进行分散数据的单体应用的标识，根据idx给相应的应用配置路由规则，mid表示用户机器码，用户机器码唯一，同一用户机器码的请求会被路由到指定的应用上处理业务逻辑请求，从而实现分散数据的方式完成微服务的高并发。

4.根据权利要求1所述的分散数据微服务自动化运维体系，其特征在于，所述边缘网关结合kubernetes中的微服务对流量进行统一入口管理和控制路由，选取Netflix Zuul，或Spring Cloud Gateway，或OpenResty作为边缘网关路由；所述配置中心选取Nacos，或Eureka，或自己编写的服务作为配置中心。

5.根据权利要求1所述的分散数据微服务自动化运维体系，其特征在于，所述性能采集组件采用prometheus进行数据采集工作，通过选取prometheus的不同的性能指标来进行性能数据采集，以应对微服务应用相关业务多样化数据特征。

6.根据权利要求5所述的分散数据微服务自动化运维体系，其特征在于，所述prometheus进行数据采集工作包括如下步骤：

步骤S11、prometheus根据其配置文件中的具体报警规则，系统将告警信息推送至prometheus的alermanager模块，根据不同的集群和告警名称，匹配不同的路由进行告警信息的处理；

步骤S12、在alermanager模块收到告警信息之后，alermanager模块根据其配置内容对告警信息处理，发送告警信息，将性能指标数据发送给所述调度组件。

7.根据权利要求1所述的分散数据微服务自动化运维体系，其特征在于，所述调度组件接收所述性能采集组件的告警内容，判断性能指标数据的类型，并根据性能指标数据的类型对配置中心进行调整，修改配置中心的配置文件。

8.根据权利要求1所述的分散数据微服务自动化运维体系，其特征在于，所述配置中心中，所述管理资源配置内容、资源配置修改日志、配置文件版本控制、配置回滚的工作采用人工操作的方式进行资源配置修改。

Images