分散数据微服务自动化运维体系转让专利
申请号 : CN202110365528.9
文献号 : CN112804362B
文献日 : 2021-06-22
发明人 : 张锦 , 唐杰 , 黄逸奇 , 李希 , 徐大宏
申请人 : 湖南师范大学
摘要 :
权利要求 :
1.分散数据微服务自动化运维体系,所述分散数据微服务包括多个微服务及多个数据库,多个所述数据库与多个所述微服务一一对应独立设置,多个所述微服务及多个所述数据库采用kubernetes作为微服务部署主体,其特征在于,包括自动运维系统及边缘网关,所述自动运维系统与kubernetes贴合使用,能够控制pod伸缩贴合微服务,实时对kubernetes做出资源调配动作,多个所述微服务通过所述边缘网关与外部连网,所述边缘网关为统一管理处理微服务的路由网关;
所述自动运维系统包括性能采集组件、调度组件、配置中心及同步组件;
所述性能采集组件采集性能指标数据,并传达给所述调度组件;
所述调度组件处理所述性能采集组件采集的性能指标数据,并根据数据类型修改资源配置,将调整后的配置文件传输给所述配置中心;
所述配置中心提取配置文件内容,对kubernetes和边缘网关进行操作资源配置,同时进行包括管理资源配置内容、资源配置修改日志、配置文件版本控制、配置回滚的工作,并将同步配置内容传输给同步组件;
所述同步组件结合所述配置中心最新的配置内容同步操作kubernetes和边缘网关路由资源配置。
2.根据权利要求1所述的分散数据微服务自动化运维体系,其特征在于,所述自动运维系统以嵌入插件的方式分别与所述kubernetes及所述边缘网关闭环式连接,嵌入插件之间的通信方式采用轻量级机制技术通信。
3.根据权利要求1所述的分散数据微服务自动化运维体系,其特征在于,所述同步组件在设置边缘网关路由配置时,根据配置中心的应用比例因子做出相对的配置,当边缘网关拿到比例因子rf之后,根据表达式算出idx;
idx = (mid ‑ (mid % rf))/rfidx表示微服务进行分散数据的单体应用的标识,根据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所述的分散数据微服务自动化运维体系,其特征在于,所述配置中心中,所述管理资源配置内容、资源配置修改日志、配置文件版本控制、配置回滚的工作采用人工操作的方式进行资源配置修改。
说明书 :
分散数据微服务自动化运维体系
技术领域
单并且高效,Kubernetes提供了应用部署,规划,更新,维护的一种机制)的分散数据微服务
自动化运维体系。
背景技术
用,微服务应运而生。微服务作为一套新的架构风格,将单个应用程序开发划为一组细粒的
服务,每个服务运行在自己的进程中,服务间有着约定的轻量级通信机制进行交互,一般是
HTTP(超文本传输协议,HyperText Transfer Protocol)资源API(应用程序接口,
Application Programming Interface)作为通信机制,围绕业务功能构建服务并且独立部
署,从而组成一个完整的系统平台为用户提供服务。微服务有着业务粒度小、职责单一、隔
离性强、去中心化管理、易管理等特点,但在构建、部署和运维上出现不少难题,就部署而
言,微服务的单一应用实例数量过多,相应的部署配置和监控的体量也就更大,并且一个应
用的修改会引起与之关联的其他应用的改动,从而造成部署复杂的情况。
应用中遇到的多样化数据以及针对高并发的分散数据微服务容器化部署kubernetes进行
容器编排这样业务需求等方面还可以有更大的改动空间。
不完全一致,以kubernetes设计理念推论,同一业务数据不同将被视为不同应用,那么维护
Pod工作量取决于业务数据量,当需要修改业务部署配置时,要对相应的多个Pod进行修改,
即存在脚本同步更新问题,也需要大量的YAML(一种直观的能够被电脑识别的数据序列化
格式,是一个可读性高并且容易被人类阅读,容易和脚本语言交互,用来表达资料序列的编
程语言)配置文件和指令操作,因此运维过程复杂、效率低下。
了难度,从而运维人员不能更好地合理化利用资源。另外,当微服务应用部署在kubernetes
时,kubernetes通过设置Ingress[一组路由规则的集合,Ingress是kubernetes API的标准
资源类型之一,它其实就是一组基于DNS名称(host)或URL路径把请求转发至指定的
Service资源的规则,用于将集群外部的请求流量转发至集群内部完成服务发布]资源清单
来暴露内部的应用服务,按照这种方式进行暴露,每个微服务的应用都需要对外暴露,没有
统一的网关处理,就会导致所有接口向外开放,对系统的安全性能产生极大的威胁。
低、不可控、不能更好地资源合理化利用、应用安全性低等问题。
发明内容
设置,多个所述微服务及多个所述数据库采用kubernetes作为微服务部署主体;
做出资源调配动作,多个所述微服务通过所述边缘网关与外部连网,所述边缘网关为统一
管理处理微服务的路由网关。
作,并将同步配置内容传输给同步组件;
用上处理业务逻辑请求,从而实现分散数据的方式完成微服务的高并发。
述配置中心选取Nacos,或Eureka,或自己编写的服务作为配置中心。
据特征。
息的处理;
应的网关设置,边缘网关自动配置对应kubernetes内部的微服务应用的路由,实现内部接
口端点对外界透明化。这样极大地简化了操作,也减少了运维和开发人员的工作量和操作
过程中的失误率,为其带来便捷,让其把精力专注于业务逻辑实现上,提高项目开发效率,
减低开发时间成本、预算成本,对资源可以充分地利用。
附图说明
具体实施方式
对应独立设置,多个所述微服务及多个所述数据库采用kubernetes作为微服务部署主体。
分散数据微服务为按微服务业务应用进行构建单独的数据库,保证把域数据封装在独立服
务中,增强隔离性,保证服务与服务、数据与数据之间独立存在,互不干扰。
理调整微服务应用的资源分配和置于集群外部的网络边缘网关的配置情况。
据微服务容器化部署后产生的多样化问题和保证高并发性能,实时对kubernetes做出资源
调配动作,多个所述微服务通过所述边缘网关与外部连网,所述边缘网关为统一管理处理
微服务的路由网关。所述自动运维系统以嵌入插件的方式分别与所述kubernetes及所述边
缘网关闭环式连接,嵌入插件之间的通信方式采用轻量级机制技术通信。
分分为两个部分,首先与kubernetes贴合使用能够控制Pod合理伸缩贴合微服务的自动化
运维系统,另一部分则是根据kubernetes环境和微服务特性在集群外部设置的边缘网关,
这样的方式与微服务本身的设计原理类似,在不改动kubernetes的情况下进行解耦联动开
发,保证各个部分的强隔离性,在插件之间的通信方式采用轻量级机制技术进行通信,如
HTTP资源请求,以保证相互及时通信、相互协调,减少故障率。通过此策略在保证微服务应
用高并发能力的前提下,简化运维过程,提高运维效率,保证运维人员实时可控系统,从而
更好地合理化利用资源,与此同时保证微服务应用的安全可靠。
的拆分,使得业务分层、解耦、让代码变得更易维护,各业务功能拆分、抽离能保证业务的隔
离性和功能的复用性,从而为以后的扩展升级预留空间。
用,方便迭代更新重用组件,提高效率。
作,并将同步配置内容传输给同步组件;所述配置中心中,所述管理资源配置内容、资源配
置修改日志、配置文件版本控制、配置回滚的工作采用人工操作的方式进行资源配置修改。
应用相关业务多样化数据特征。
(Counter)代表一种样本数据单调递增的指标,即正常情况下只增不减;仪表盘(Guage)代
表一种样本数据可以任意变化的指标,即可增可减;直方图(Histogram)在一段时间范围内
对数据进行采样,例如请求持续时间或响应大小,并将其存入配置的存储桶中,后续可通过
指定区间筛选样本,也可统计样本总数,最后将数据展示为直方图;摘要(Summary)表示在
一段时间内的数据采样结果,直接存储客户端计算统计之后展示出来的分位数。通过选取
不同的性能指标来进行性能数据采集以应对微服务应用相关业务多样化数据特征。
算能力的支持)表达式验证监控CPU(中央处理器,Central Processing Unit)的使用率,如
果超过了设定阈值,系统将告警信息推送至prometheus的alermanager(通过命令行flag和
一个配置文件进行配置的组件)模块,根据不同的集群和告警名称匹配不同的路由进行告
警信息的处理。
web.hook(反向应用程序接口 ,被广泛应用于微服务,即客户端提供一个接口而不主动请
求,当服务端的数据发生变化时,主动推送给客户端)的方式处理的告警信息,告警信息会
经过分组为alertname(警告名称)的route(路径)向web.hook接收者传递,并向web.hook配
置的网络接口http://IP:Port发送告警信息。
件调整完成之后将配置文件传输给配置中心组件,待后续组件进行相关工作处理,该组件
是贴合微服务的自动化运维系统的核心组件之一,也是调整微服务在kubernetes中的资源
分配以及网络边缘网关的关键核心控制单元。该组件同时要保留往来历史性能指标数据,
根据现有设定的规则在累积数据当中挖掘出合适的资源配置内容,以提高资源利用率。
示数据)告警内容,对内容进行处理,根据json.alerts[i].labels.alertname来判断具体
性能指标的类型,根据 json.commonLabels.alername来判断是出问题的主机,根据指标类
型来对配置中心进行调整,例如告警内容性能指标是CPU,出问题的主机是IP:9100,表示
IP:9100的CPU使用率过高。调度服务根据解析出来的告警内容来修改配置中心的配置文
件,对该主机所承载的业务应用进行扩容。
kubernetes和网络边缘网关进行操作配置,同时管理资源配置内容、资源配置修改日志、资
源配置文件版本控制、配置回滚等。配置中心的作用是配置信息的中转存储,这样做的目的
是既能够完成kubernetes里的微服务合理资源调度,又可以在运维过程中进行人为的自定
义配置信息。
务作为配置中心。配置中心的角色不限定于特定的一个服务,可以是现有的Nacos,也可以
是Eureka,更可以是自己编写的服务。
Nacos进行配置文件的修改。Nacos作为配置中心,本身自带控制面板,可以通过控制面板对
配置文件的修改来人工干涉kubernetes的扩缩容,也有利于提高运维效率,此外,Nacos时
刻接受同步组件的监听。
关路由配置时,根据配置中心的应用比例因子做出相对的配置,当边缘网关拿到比例因子
rf之后,根据表达式算出idx;
用上处理业务逻辑请求,从而实现分散数据的方式完成微服务的高并发。
取下来进行解析,并根据对kubernetes的微服务业务应用进行编排和网关路由配置进行修
改,以保证修改后的配置文件与kubernetes和网关保持一致性。
Spring Cloud Gateway(Spring Cloud 生态系统中的网关,目标是替代 Netflix Zuul,其
不仅提供统一的路由方式,并且基于 Filter 链的方式提供了网关基本的功能),或
OpenResty[一个高性能网页平台,其内部集成了大量精良的Lua(一个简洁、轻量、可扩展的
程序设计语言)库、第三方模块以及大多数的依赖项,用于方便地搭建能够处理超高并发、
扩展性极高的动态网页应用、网页服务和动态网关]作为边缘网关路由;
多样化数据需求,并且体量轻巧,所以本文实验选取的是OpenResty作为边缘服务器,控制
微服务路由网关。
Kubernetes资源分配和网络边缘网关路由配置,采用配置中心统一管理配置内容,简化配
置管理,同步组件根据最新配置信息进行更新动作,达到自动化运维目的。
测试自动化运维统方式在实际运行环境中的运行响应效果,主要分为手动操作自动化运维
系统进行扩展和自动化运维系统自动响应扩展两种方式。本实验中基于虚拟机方式部署、
基于Docker的YAML文件部署、基于自动化系统方式部署实验内容主要是针对于第一阶段而
设置的。
YAML文件方式和自动化系统方式这三种方式进行部署该单体应用来作第一阶段的实验对
比,此外第二阶段的实验是通过Jmeter(Apache组织开发的基于Java的压力测试工具,用于
对软件做压力测试)模拟高并发场景向部署在原kubernetes的环境的微服务和部署在增加
了贴合微服务的自动化运维系统和网关的kubernetes环境中的微服务分别发起请求进行
测试,根据Jmeter报告参数数据作对比。
和相关配置文件上传至linux(一种自由和开放源码的类UNIX操作系统)目录下,输入”./
user_service”指令之后回车即可。但这仅仅只是启动一个应用,作为微服务,要承受高并
发访问量,那么就要搭建user_service应用的应用集群,就需要多台机器,不仅浪费了资
源,还对集群的搭建增加难度,耗时更长。
名空间里生成Deployment(部署)资源和对应的Service(服务)资源以及Ingress资源。
svc.json文件开始到所有的应用调整完毕后所需要的时间。
记录从增大访问量到集群和网关调整微服务数量完成所需要的时间以及从减少访问量后
集群和网关调整微服务数量完成所需要的时间。
下简称新环境)部署的微服务的性能进行对比,也就是通过使用JMeter进行性能测试,分别
设置100、5000、10000个用户分别并发请求访问,将低、中、高三种情况的测试报告作对比。
测试报告中有偏离、吞吐量、中值三个评测标准,偏离表示服务器响应时间变化、离散程度
测量值的大小,也就是数据的分布;吞吐量表示服务器每分钟处理的请求数;中值表示时间
的数字,有一半的服务器响应时间低于该值而另一半高于该值。
自由使用源代码的企业级Linux发行版本)镜像相同、虚拟机参数配置相同的环境中。
看出不同实验的部署过程复杂度是不同的。
了很多,极大地提高微服务开发效率。
的很好,比虚拟机快很多。
优于传统的虚拟机和容器+YAML的效果。
机下提高好几个时间级别,简化开发和运维过程,也保证微服务应用的安全性。
着并发量的增大而增加,但新环境的处理数量与原环境的相差无几。
间低于测试值而另一半高于该值的情况变化不大。
也表示新环境对高并发的请求处理较分散,去中心化。
数据微服务多样化功能需求和解决运维等问题。
和解决运维、合理化利用资源和安全等问题,能够实现微服务模块的统一管理、实时监控、
数据采集、性能分析、自动调度等运维任务,最大程序地减少运维人员的工作量,提高运维
效率,同时也能够保证系统的稳定运行,使得业务可持续性和资源的充分利用。
同步组件在同步配置时也同时修改了相应的网关设置,边缘网关OpenResty自动配置对应
kubernetes内部的微服务应用的路由,实现内部接口端点对外界透明化。这样极大地简化
了操作,也减少了运维和开发人员的工作量和操作过程中的失误率,为其带来便捷,让其把
精力专注于业务逻辑实现上,提高项目开发效率,减低开发时间成本、预算成本,对资源可
以充分地利用。在不损耗并发性能的同时,最终可以实现以最低成本代价使得系统稳定地
高并发,横向扩展,进而获取系统的最高利益。
应视为本发明的保护范围。