CN110995511A - 基于微服务架构的云计算运维管理方法、装置和终端设备 - Google Patents

Abstract

本申请实施例公开一种基于微服务架构的云计算运维管理方法、装置和终端设备。该方法包括：发送微服务组件至微服务组件库，根据微服务类型将微服务组件分为信息流组件、业务流组件、事件流组件或通用组件；监控微服务组件，对微服务组件进行上架处理；获取配置的接口，对上架后的微服务组件进行信息配置；根据所述微服务类型，部署微服务组件，以指示微服务组件发布微服务应用程序编程接口；调用微服务应用程序编程接口，响应微服务组件的需求。因此，本申请实施例可以使云计算环境下的运维管理达到精准细化、细颗粒度的管理水平，进而能够缩短各类业务的处置响应时间，提升应用效率。

Description

基于微服务架构的云计算运维管理方法、装置和终端设备

技术领域

本申请涉及云计算技术领域，尤其涉及一种基于微服务架构的云计算运维管理的方法、装置和终端设备。

背景技术

随着云计算的普及与信息技术的发展，基于应用虚拟化、按使用量付费、独立资源池、弹性计算计量的云服务供应模式，具有较高的可配置性、适应性和可扩展性。这种模式的应用可以给企业组织、政府部门带来诸多的便利与效率的提升。与此同时，也给云计算环境下的运维人员带来了更大的挑战，不同层次的云服务所涉及的基础资源、业务模块、服务能力、管理颗粒度、精细化程度均有所不同。

在云计算环境下的运维服务管理过程中，运维人员需要在管理虚拟化资源、物理机资源、网络设备、安全设备、域名解析及端口等基础设施资源的基础上，结合服务级别协议对部署业务、应用单位、变更管理、部署发布、资源使用情况、资源应用监控、版本控制及配置管理等内容进行有效管理，采用事件触发机制和流程管理对影响运维服务可用性、连续性和安全性的故障、问题、服务请求和访问控制进行分类管理。但在实际情况中，数据信息不透明、业务关联不精细、处置响应不及时、服务保障不连续等现象时有发生，导致应用效率难以提升。

发明内容

本申请实施例提供一种基于微服务架构的云计算运维管理方法、装置、和终端设备，以解决在云计算环境下的运维服务管理过程中，数据信息不透明、业务关联不精细、处置响应不及时、服务保障不连续的问题。

本发明采用如下技术方案：

第一方面，本申请实施例提供一种基于微服务架构的云计算运维管理方法，该方法包括：

发送微服务组件至微服务组件库，根据微服务类型将微服务组件分为信息流组件、业务流组件、事件流组件或通用组件；

监控微服务组件，对微服务组件进行上架处理；

获取配置的接口，对上架后的微服务组件进行信息配置；

根据微服务类型，部署服务组件，以指示微服务组件发布微服务应用程序编程接口；

调用微服务应用程序编程接口，响应微服务组件的需求。

第二方面，本申请实施例提供一种基于微服务架构的云计算运维管理装置，该装置包括：

发送模块，用于发送微服务组件至微服务组件库，根据微服务类型将服务组件分为息流组件、业务流组件、事件流组件或通用组件；

监控模块，用于监控微服务组件，对微服务组件进行上架处理；

获取模块，用于获取配置的接口，对上架后的微服务组件进行信息配置；

部署模块，用于根据微服务类型，部署服务组件，以指示微服务组件发布微服务应用程序编程接口；

调用模块，用于调用微服务应用程序编程接口，响应微服务组件的需求。

第三方面，本申请实施例提供一种终端设备，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现本申请实施例第一方面的基于微服务架构的云计算运维管理方法的步骤。

本申请一些实施例提供的技术方案带来的有益效果至少包括：发送微服务组件至微服务组件库，根据微服务类型将微服务组件分为信息流组件、业务流组件、事件流组件或通用组件；这样，可以监控微服务组件，对微服务组件进行上架处理，下架的微服务组件退回至微服务组件库，上架的微服务组件可以进行微服务配置；获取配置的接口，对上架后的微服务组件进行信息配置；根据微服务类型，部署微服务组件，以指示微服务组件发布微服务应用程序编程接口；调用微服务应用程序编程接口，响应微服务组件的需求。这样，以使云计算环境下的运维管理达到精准细化、细颗粒度的管理水平，进而能够缩短各类业务的处置响应时间，提升应用效率。

附图说明

为更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出可以应用于本申请实施例的一种基于微服务架构的云计算运维管理装置的示例性系统架构的示意图；

图2示出本申请实施例公开的一种基于微服务架构的云计算运维管理方法的流程图；

图3示出本申请实施例公开的一种基于微服务架构的云计算运维管理方法中的信息流实例处理流程示意图；

图4示出本申请实施例公开的一种基于微服务架构的云计算运维管理方法中的信息流的资源申请过程的流程图；

图5示出本申请实施例公开的一种基于微服务架构的云计算运维管理方法中的业务流实例处理流程示意图；

图6示出本申请实施例公开的一种基于微服务架构的云计算运维管理方法中的事件流实例处理流程示意图；

图7示出本申请实施例公开的一种基于微服务架构的云计算运维管理装置的结构示意图；

图8示出本申请实施例公开的一种终端设备的结构示意图。

具体实施方式

为使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其他步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

首先，对本申请实施例涉及到的一些名词进行解释：

微服务：又称为微服务架构，是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制进行通信，这种轻量级机制通常为HTTP(HyperText Transfer Protocol，超文本传输协议)资源的API(ApplicationProgramming Interface，应用程序编程接口)。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。

微服务架构一样会用到各种库，但这种架构会把软件给拆分成各种不同的服务来实现组件化，组件是可独立更换和升级的软件单元。这里我们定义两个重要的概念：库指的是链接到程序的组件，通过本地函数调用来使用库提供的功能；而服务是进程外的组件，通过网络服务请求或者远程函数调用之类的机制来使用里面的功能。注意这和很多面向对象程序里服务对象的机制是不同的。

图1示出可以应用于本申请实施例的一种基于微服务架构的云计算运维管理装置的示例性系统架构的示意图。

如图1所示，系统架构100可以包括终端101、102、103中的一种或多种，网络104和服务器105。网络104用以在终端101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

应该理解，图1中的终端、网络和服务器的数目仅仅是示意性的。根据现实需要，可以具有任意数目的终端、网络和服务器。比如服务器105可以是多个服务器组成的服务器集群等。

用户可以使用终端101、102、103通过网络104与服务器105交互，以接收或发送消息等。终端101、102、103可以是具有显示屏的各种电子设备，包括但不限于智能手机、平板电脑、便携式计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器。例如服务器105可以执行后面将描述的根据本申请实施例的方法，实现基于微服务构架的云计算运维管理。服务器发送微服务组件至微服务组件库，根据微服务类型将微服务组件分为信息流组件、业务流组件、事件流组件或通用组件；监控微服务组件，对微服务组件进行上架处理；获取配置的接口，对上架后的微服务组件进行信息配置；根据微服务类型，部署服务组件，以指示微服务组件发布微服务应用程序编程接口；调用微服务应用程序编程接口，响应微服务组件的需求。这样，以使云计算环境下的运维管理达到精准细化、细颗粒度的管理水平，进而能够缩短各类业务的处置响应时间，提升应用效率。

需要说明的是，本申请实施例所提供的一种基于微服务架构的云计算运维管理方法一般由服务器105执行，相应地，一种基于微服务架构的云计算运维管理装置一般设置于服务器105中，但本申请不限于此。

图2示出本申请实施例公开的一种基于微服务架构的云计算运维管理方法的流程图，图2所示的一种基于微服务架构的云计算运维管理方法可用于图1所示的环境。参考图1，该方法具体可以包括如下步骤：

S201、发送微服务组件至微服务组件库，根据微服务类型将微服务组件分为信息流组件、业务流组件、事件流组件或通用组件。

其中，微服务组件是对数据和方法的简单封装，其中的“微”指组件的粒度。

具体的，研发人员需要根据运维工具、虚拟化平台、安全设备、网络设备、DNS设备、测试工具、监听工具等资源并结合运维需求或调用它们的接口或自主研发，实现微服务构建。微服务也是部署在服务器上的应用程序。成功构建微服务后，发送微服务组件至微服务组件库。根据微服务的类型将微服务组件分为信息流组件、业务流组件、事件流组件或通用组件。

S202、监控微服务组件，对微服务组件进行上架处理。

其中，监控系统按照原理和作用大致分为日志类、调用链类和度量类三类。

具体的，日志类监控比较常见，我们的框架代码、系统环境、以及业务逻辑中都会产出一些日志，这些日志我们通常把它记录后统一收集起来，方便在需要的时候进行查询。日志类记录的信息一般是一些事件、非结构化的一些文本内容。调用链类监控主要是指记录一个请求的全部流程。一个请求从开始进入，在微服务中调用不同的服务节点后，再返回给客户端，在这个过程中通过调用链参数来追寻全链路行为。通过这个方式可以很方便的知道请求在哪个环节出现故障，系统的瓶颈在哪儿。这一类的监控一般采用CAT(CentralApplication Tracking，中央应用跟踪)具来完成，一般在大中型项目较多用到，因为搭建起来有一定的成本。度量类主要采用时序数据库的解决方案。它是以事件发生时间以及当前数值的角度来记录的监控信息，是可以聚合运算的，用于查看一些指标数据和指标趋势，这类监控主要不是用来查问题的，主要是用来看趋势的。这些监控系统可以监控微服务部署时间、发布时间、联系人、基础配置内容、调用次数、失败次数、版本、环境，目录等内容。环境比如是CPU、内存、进程等。主要监控微服务组件的调用频率和当前目标微服务类型，以对微服务组件进行上架处理。例如虚拟机分配资源是一个必须的微服务组件，就会对其进行上架处理，由运维人员在平台上点击上架处理的操作；虚机端口检测是一个非必须的组件，不一定会对其进行上架处理。

S203、获取配置的接口，对上架后的微服务组件进行信息配置。

其中，配置对程序中的一些参数进行自定义配置，方便以后更改，使得微服务具有良好的拓展性，为此可以将一些配置信息写入配置文件中。配置信息包括址配置信息、权限配置信息、环境配置信息、目录配置信息、文件配置信息、消息队列配置信息、版本配置信息、灰度发布配置信息或监听查询配置信息。配置文件是一个小型的数据库，存储这些信息，程序进行读取使用。

具体的，例如，系统上线后日志级别默认为.info，当系统出现问题，访问不正常，想查看更多的日志信息的时候，于是可以将日志输出级别动态地调整为程序调试工具级别，而无需重启应用，进行分布式配置管理。

S204、根据所述微服务类型，部署微服务组件，以指示微服务组件发布微服务应用程序编程接口。

其中，部署就是让开发出的产品能够在某一环境中运行起来。

在微服务构架中，常见的部署有蓝绿部署、滚动发布部署、灰度发布部署。其中，蓝绿部署无需停机，并且风险较小。滚动发布部署方式相对于蓝绿部署，更加节约资源，不需要运行两个集群、两倍的实例数，可以部分部署，例如每次只取出集群的20％进行升级。灰度发布部署是指在黑与白之间，能够平滑过渡的一种发布方式。ABtest就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布部署可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

具体的，部署的过程分为三步，第一步是把服务的docker容器化，把服务(应用或者是对应功能模块)在docker容器内运行。让服务有一个适合、隔离、相对安全的运行环境，这个运行环境可以理解为是基础镜像。服务运行在指定docker容器下，各个服务之间可以相互隔离，互不影响，又相互交融协同工作。如果一个服务运行出现问题，并不会影响其它服务的使用。微服务的Docker容器化部署是基于Java语言环境。服务容器化运行之后，建立各服务容器化运行之间的通信，运行于独立容器中的各个微服务之间建立依赖关系，也就是link关系。第二步是构建私有镜像仓库，最常用的git harbor来存放镜像。第三步是搭建高可用的kubernetes集群环境。

微服务有统一的集群应用环境，部署在对应的服务器上，与用户业务资源是独立的，两者之间只通过网络协议或接口进行传输。管理中心会监控微服务状态，部署成功时微服务组件发布的接口是可以访问和调用的，部署失败时无法访问或调用。

S205、调用微服务应用程序编程接口，响应微服务组件的需求。

其中，首先找到需要调用的API接口。API(Application Programming Interface，应用程序接口)是一些预先定义的函数，或指软件系统不同组成部分衔接的约定。目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问原码，或理解内部工作机制的细节。其调用API接口是基于遗传算法的网关负均衡载方法，当终端用户发出请求后，通过该负均衡载方法实现网关调度，保障快速搜索到最优的资源去响应微服务组件的需求。

调用微服务应用程序编程接口之前，需要将用户发送的微服务请求发送到微服务网关进行处理。微服务网关承载着负载均衡、请求分发、服务鉴权、容错处理，微服务架构的网关基于某种负载均衡算法，自动地帮助用户去请求，如轮询、随机等，也会根据实际情况自行定义算法。当用户请求过多时可能会被强制等待，或响应成功或超时，为防止服务崩溃还会引入容错机制。

这样，根据本申请实施例的基于微服务架构的云计算运维管理方法，通过发送微服务组件至微服务组件库，根据微服务类型将微服务组件分为信息流组件、业务流组件、事件流组件或通用组件；监控微服务组件，对微服务组件进行上架处理；获取配置的接口，对上架后的微服务组件进行信息配置；根据所述微服务类型，部署微服务组件，以指示微服务组件发布微服务应用程序编程接口；调用微服务应用程序编程接口，响应微服务组件的需求。因此，本申请实施例以使云计算环境下的运维管理达到精准细化、细颗粒度的管理水平，进而解决数据信息不透明、业务关联不精细、处置响应不及时、服务保障不连续等的现象。

上述主要从方法侧执行过程的角度对本申请实施例的方案进行介绍。可以理解的是，终端为实现上述功能，其包含执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。本申请实施例可以根据上述方法示例对终端进行功能单元的划分，例如，可以对应各个功能划分各个功能单元，也可以将两个或两个以上的功能集成在一个处理单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

为了更好的说明图2中微服务构架里信息流组件的操作过程，图3示出本申请实施例公开的一种基于微服务架构的云计算运维管理方法中的信息流实例处理流程示意图。如图3所示，该基于微服务架构的云计算运维管理方法中的信息流实例处理流程包括资源申请模块301、服务台模块302、受理中心模块303、资源池评估模块304、资源池扩建模块305、资源创建模块306、资源交付模块307和服务中心模块308。

参见图3，用户根据资源使用需求发起资源申请，传送到资源申请模块301，资源申请包括：网路资源申请、计算资源申请、存储资源申请、域名端口资源申请和安全策略申请。此时，资源申请模块301将申请信息自动提交至服务台模块302，运维人员在服务台模块302判断资源申请是否合理，如图4所示，CPU一般是4核、8核、16核、32核，资源申请模块301申请了4核或者8核是合理的，进入受理中心模块303；资源申请模块301申请了150核或者160核是不合理的，不允许进入受理中心模块303，退回至申请界面重新修改提交或者撤销。受理中心模块303受理提交的申请，并提交至资源池评估模块304。资源池评估模块304对现有资源与资源申请模块302中的资源进行评估，并作出通过或失败处理。当现有资源可以支持资源申请模块301所需资源时将通过进入资源创建模块306。当现有资源不足以支持资源申请所需资源时将失败进入资源池扩建模块305。资源创建模块306，根据资源申请模块301中所需资源进行创建，完成后自动提交至资源交付模块303。资源池扩建模块305，根据资源申请模块301所需资源进行扩建，并预留20％余量资源纳入当前资源池以备资源扩容。在资源交付模块303中，确认当前创建的资源与资源申请模块301所需要的资源一致之后，提交至服务中心模块308；若不一致，需要重新返回资源创建模块306。在服务中心模块308，将自动触发资源申请模块301反馈信息推送，将资源申请模块301反馈信息推送至用户处。

本申请实施例提供的一种基于微服务架构的云计算运维管理方法的信息流处理流程，将云计算运维管理过程中使用的基础设施资源进行数据化处理成信息流，保障各类资源的信息流数据可查询、可统计、可监控、可管理。可以使云计算环境下的运维管理达到精准细化、细颗粒度的管理水平，进而能够缩短各类业务的处置响应时间，提升应用效率。

为了更好的说明图2中微服务构架里业务流组件的操作过程，图5示出本申请实施例公开的一种基于微服务架构的云计算运维管理方法中的业务流实例处理流程示意图。如图5所示，该基于微服务架构的云计算运维管理方法中的业务流实例处理流程包括业务申请模块501、受理中心模块502、业务评估模块503、业务部署模块504、业务验证模块505、生产发布模块506和服务中心模块507。

参见图5，用户根据业务需求发起业务申请，传送到资源申请模块501。资源申请模块501包括业务部署、业务发布、业务测试、权限控制、配置管理和变更管理。业务申请模块501将申请信息自动提交到受理中心模块502，运维人员查看后提交至业务评估模块503。资源评估模块503由运维人员负责，结合自动化工具评估业务申请模块501提交的申请信息是否满足业务需求，对业务申请进行自动化测试和安全测试，避免出现应用级的安全漏洞，或者业务程序上出现SQL注入、跨站脚本等漏洞。当业务评估通过时将进入业务部署模块504。当业务评估失败时将退回至业务申请模块501。业务部署模块504将业务申请进行自动打包至应用容器内，比如应用容器为Tomcat、IIS等，实现业务部署，并对部署前的历史业务及相关配置进行备份处理，部署完成后进入业务验证模块505。在业务验证模块505中将自动触发业务验证信息推送，通知用户对部署业务进行验证。业务验证时用户验证部署业务，属于应用级的；运维人员验证基础资源层的，属于基础设施级的。根据测试报告、安全评估、用户资源余量、用户当前资源使用率等内容进行验证，防止配置的安全策略、网络带宽、访问链接、备份策略、资源阈值等内容与用户业务出现不一致或未生效。生产发布模块506中，已验证的用户业务自动同步至生产环境中予以正式发布。正式发布后的业务出现在服务中心模块507中，在服务中心模块507进行业务应用监测，监控业务访问情况、健康状况以及业务占用资源情况，主要指是安全策略、网络带宽、访问链接、备份策略、资源阈值等内容。同时将自动触发业务申请模块501反馈信息推送，将业务申请模块501的反馈信息推送至用户处。

本申请实施例提供的一种基于微服务架构的云计算运维管理方法的业务流处理流程，将云计算运维管理与服务级别协议相结合，通过精细化智能处理实现基础设施资源信息流与用户应用体验业务流的关联匹配，可以使云计算环境下的运维管理达到精准细化、细颗粒度的管理水平，通过自动化工具缩短各类业务的处置响应时间，提升应用效率。

为了更好的说明图2中微服务构架里事件流组件的操作过程，图6示出本申请实施例公开的一种基于微服务架构的云计算运维管理方法中的事件流实例处理流程示意图。如图6所示，该基于微服务架构的云计算运维管理方法中的业务流实例事件流程包括事件上报模块601、事件告警模块602、事件中心模块603、事件分析模块604、初步支持模块605、支持报告模块606、事件诊断模块607、事件恢复模块608、事件告知模块609、事件归档模块610、知识库611和事件关闭模块612。

参见图6，当用户发现业务异常时，比如无法访问、响应超时、无法链接、权限不足等情况，在个人管理中心发起事件上报流程，传送至事件上报模块601，异常信息将作为事件自动提交至事件中心模块603。当基础设施资源与用户业务监控异常时，比如资源利用率突然增高、内存溢出、服务器假死、流量异常、无法访问、异常登录等情况，将会自动触发事件告警模块602，告警信息自动提交至事件中心模块603。在事件中心模块603中，自动匹配现有知识库对事件进行定性分类，根据监控信息初步估算影响范围，并触发事件通知对运维人员进行事件告知，进入事件分析模块604。现有知识库是一种微服务组件，云计算服务方可以自主研发、或者二次开发、或者使用第三方成熟的产品，使用第三方的产品时需要进行接口微调，使之满足微服务架构。在事件分析604中，由运维人员对事件分类再次确认，详细测算事件影响范围，并结合现有知识库解决方案确定解决措施，进入初步支持模块605。在初步支持模块605中，运维人员将根据现有知识库提供的解决方案和已确定的解决措施进行初步支持，当初步支持成功时将进入支持报告模块606；当初步支持失败时将进入事件诊断模块607。在支持报告模块606中，对初步支持成功的事件形成支持报告，并将该报告自动推送至用户处进行结果告知。在事件诊断模块607中，对初步支持失败的事件进行事件诊断，结合来源于操作系统本身的服务器日志、来源于硬件设备的监控组件的网络日志和流量日志、来源于应用业务本身的异常日志等内容确认有效的事件处理方法，进入事件恢复模块608。在事件恢复模块608中将执行有效的事件处理方法，并验证事件处理结果，验证无误后对恢复过程进行事件记录，记录内容自动同步至知识库611中，进入事件告知模块609。在事件告知模块609中，将事件内容及事件处理详细过程对用户和管理人员进行告知，并自动记录告知时间、告知人与被告知人，记录内容自动同步至知识库611中，进入事件归档模块610。在事件归档模块610中，将对此次事件分析、初步支持、事件诊断、事件恢复、事件告知的整个处理流程进行自动汇总记录，形成事件归档记录报告，并将该报告自动同步至知识库611中。事件归档完成后进入事件关闭模块612，更新事件处理状态，将事件设置为关闭状态，形成闭环管理。

本申请实施例提供的一种基于微服务架构的云计算运维管理方法的事件流处理流程，将云计算运维管理融入事件触发机制和流程管理，通过自动化和知识库构建提升事件处置响应效率，保障运维服务的可用性和连续性，提升运维服务和管理的能力与水平。可以使云计算环境下的运维管理达到精准细化、细颗粒度的管理水平，进而能够缩短各类业务的处置响应时间，提升应用效率。

图7示出本申请实施例公开的一种基于微服务架构的云计算运维管理装置的结构示意图。图7所示的基于微服务架构的云计算运维管理装置可用于执行上述基于微服务架构的云计算运维管理方法。如图7所示，该基于微服务架构的云计算运维管理装置700包括发送模块701、监控模块702、获取模块703、部署模块704和调用模块705，其中：

发送模块701，用于发送微服务组件至微服务组件库，根据微服务类型将述微服务组件分为息流组件、业务流组件、事件流组件或通用组件；

监控模块702，用于监控所述微服务组件，对所述微服务组件进行上架处理；

获取模块703，用于获取配置的接口，对上架后的所述微服务组件进行信息配置；

部署模块704，用于根据所述微服务类型，部署述微服务组件，以指示所述微服务组件发布微服务应用程序编程接口。

调用模块705，用于调用所述微服务应用程序编程接口，响应所述微服务组件的需求。

根据一些实施例，还包括管理模块706，用于设置微服务网关，对所述微服务组件进行管理。

根据一些实施例，管理模块706，具体用于设置微服务网关，对微服务组件的负载均衡、请求分发、服务鉴权进行管理。

根据一些实施例，监控模块702，具体用于监控所述微服务组件的调用频率，对所述微服务组件进行上架处理。

根据一些实施例，监控模块702，具体还用于实时监控当前目标微服务类型，对所述微服务组件进行上架处理。

根据一些实施例，基于微服务架构的云计算运维管理装置700的配置信息包括地址配置信息、权限配置信息、环境配置信息、目录配置信息、文件配置信息、消息队列配置信息、版本配置信息、灰度发布配置信息或监听查询配置信息。

根据一些实施例，基于微服务架构的云计算运维管理装置700的微服务程序编程接口用于提供微服务组件列表和访问方式。

本申请实施例提供一种基于微服务架构的云计算运维管理装置，该基于微服务架构的云计算运维管理装置在通过发送微服务组件至微服务组件库，根据微服务类型将微服务组件分为信息流组件、业务流组件、事件流组件或通用组件；这样，可以监控微服务组件，对微服务组件进行上架处理，下架的微服务组件退回至微服务组件库，上架的微服务组件可以进行微服务配置；获取配置的接口，对上架后的微服务组件进行信息配置；根据微服务类型，部署微服务组件，以指示微服务组件发布微服务应用程序编程接口；调用微服务应用程序编程接口，响应微服务组件的需求。这样，以使云计算环境下的运维管理达到精准细化、细颗粒度的管理水平，进而能够缩短各类业务的处置响应时间，提升应用效率。

本申请实施例还提供一种终端设备，请参阅图8，图8示出本申请实施例公开的一种终端设备的结构示意图，如图8所示，该终端设备包括：处理器801，以及与处理器801相连接的存储器802；存储器802用于存储计算机程序，计算机程序至少用于执行本申请实施例中的基于微服务架构的云计算运维管理方法；处理器801用于调用并执行存储器中的计算机程序，上述基于微服务架构的云计算运维管理方法至少包括如下步骤：发送微服务组件至微服务组件库，根据微服务类型将微服务组件分为信息流组件、业务流组件、事件流组件或通用组件；这样，可以监控微服务组件，对微服务组件进行上架处理，下架的微服务组件退回至微服务组件库，上架的微服务组件可以进行微服务配置；获取配置的接口，对上架后的微服务组件进行信息配置；根据微服务类型，部署微服务组件，以指示微服务组件发布微服务应用程序编程接口；调用微服务应用程序编程接口，响应微服务组件的需求。

本领域的技术人员可以清楚地了解到本申请的技术方案可借助软件和/或硬件来实现。本说明书中的“单元”和“模块”是指能够独立完成或与其他部件配合完成特定功能的软件和/或硬件，其中硬件例如可以是现场可编程门阵列(Field－ProgrammaBLE GateArray，FPGA)、集成电路(Integrated Circuit，IC)等。

需要说明的是，对于前述的各方法实施例，为简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置，可通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台终端设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储器包括：U盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储器中，存储器可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(Random AccessMemory，RAM)、磁盘或光盘等。

以上所述者，仅为本公开的示例性实施例，不能以此限定本公开的范围。即但凡依本公开教导所作的等效变化与修饰，皆仍属本公开涵盖的范围内。本领域技术人员在考虑说明书及实践这里的公开后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未记载的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的范围和精神由权利要求限定。

Claims (10)

1.一种基于微服务架构的云计算运维管理方法，其特征在于，所述方法包括：

发送微服务组件至微服务组件库，根据微服务类型将所述微服务组件分为信息流组件、业务流组件、事件流组件或通用组件；

监控所述微服务组件，对所述微服务组件进行上架处理；

获取配置的接口，对上架后的所述微服务组件进行信息配置；

根据所述微服务类型，部署所述微服务组件，以指示所述微服务组件发布微服务应用程序编程接口；

调用所述微服务应用程序编程接口，响应所述微服务组件的需求。

2.根据权利要求1所述的方法，其特征在于，所述调用所述微服务应用程序编程接口，响应所述微服务组件的需求之前包括：

设置微服务网关，对所述微服务组件进行管理。

3.根据权利要求2所述的方法，其特征在于，所述设置微服务网关，对所述微服务组件进行管理包括：

设置微服务网关，对微服务组件的负载均衡、请求分发、服务鉴权进行管理。

4.根据权利要求1所述的方法，其特征在于，所述监控所述微服务组件，进行上架处理，包括：

监控所述微服务组件的调用频率，对所述微服务组件进行上架处理。

5.根据权利要求2所述的方法，其特征在于，所述监控所述微服务组件，进行上架处理，还包括：

实时监控当前目标微服务类型，对所述微服务组件进行上架处理。

6.根据权利要求1所述的方法，其特征在于，所述配置信息包括：

地址配置信息、权限配置信息、环境配置信息、目录配置信息、文件配置信息、消息队列配置信息、版本配置信息、灰度发布配置信息或监听查询配置信息。

7.根据权利要求1所述的方法，其特征在于，所述微服务程序编程接口用于提供微服务组件列表和访问方式。

8.一种基于微服务架构的云计算运维管理装置，其特征在于，所述装置包括：

发送模块，用于发送微服务组件至微服务组件库，根据微服务类型将述微服务组件分为息流组件、业务流组件、事件流组件或通用组件；

监控模块，用于监控所述微服务组件，对所述微服务组件进行上架处理；

获取模块，用于获取配置的接口，对上架后的所述微服务组件进行信息配置；

部署模块，用于根据所述微服务类型，部署述微服务组件，以指示所述微服务组件发布微服务应用程序编程接口；

调用模块，用于调用所述微服务应用程序编程接口，响应所述微服务组件的需求。

9.根据权利要求8所述的装置，其特征在于，还包括管理模块，用于在调用所述微服务应用程序编程接口，响应所述微服务组件的需求之前：设置微服务网关，对所述微服务组件进行管理。

10.一种终端设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。

Images