CN116647434A - 运维服务部署方法、装置及运维系统 - Google Patents

Abstract

本发明提供了一种运维服务部署方法、装置及运维系统，应用于包含运维服务端和运维客户端的运维系统中；其中，运维服务端设置有主服务器；运维客户端设置有从服务器；从服务器为基于主服务器部署的服务器；该方案在运维服务部署过程中能够简单高效的将服务部署组件部署至运维服务端，并可对部署过程进行实时监控，从而解决了现有运维服务中存在的部署复杂，自动化程度低的问题。

Description

运维服务部署方法、装置及运维系统

技术领域

本发明涉及运维服务部署领域，尤其是涉及一种运维服务部署方法、装置及运维系统。

背景技术

项目在部署运维阶段时，项目包的形式不同，其部署运维的方式也不尽相同。运维部署依赖于开发提供的运维部署手册，手册的质量以及现场实施人员对手册的理解是运维部署执行效果的关键。但实际场景中存在以下问题：

项目部署往往过于复杂，运维的脚本过多，不利于现场实施人员部署，各组件之间依赖配置繁复需要逐一比对，容易出错且不好排查；

过度依赖运维部署手册，手册的质量以及现场实施人员对手册的理解成为对部署运维的制约因素，且过多的部署文档难以对其进行有效的管理；

服务在升级的时候可能会涉及到多个组件，导致项目升级容易出现问题。

综上所述，现有的运维服务还存在着部署复杂，自动化程度低的问题。

发明内容

有鉴于此，本发明的目的在于提供一种运维服务部署方法、装置及运维系统，该方案在运维服务部署过程中能够简单高效的将服务部署组件部署至运维服务端，并可对部署过程进行实时监控，从而解决了现有运维服务中存在的部署复杂，自动化程度低的问题。

第一方面，本发明实施例提供了一种运维服务部署方法，该方法应用于包含运维服务端和运维客户端的运维系统中；其中，运维服务端设置有主服务器；运维客户端设置有从服务器；从服务器为基于主服务器部署的服务器；

该运维服务部署方法包括：

在从服务器中获取目标服务器，并利用目标服务器对应的上传参数将服务部署组件发送至运维服务端的主服务器中；

根据服务部署组件对应的组件属性数据生成通知指令，并控制运维服务端将通知指令发送至运维客户端；

运维客户端响应通知指令后，控制运维客户端与运维服务端建立长连接，并将服务部署组件从主服务器发送至从服务器中；

控制运维客户端将服务部署组件安装至从服务器中，实时获取服务部署组件的运行状态数据，并将运行状态数据发送至运维服务端。

在一些实施方式中，在从服务器中获取目标服务器，并利用目标服务器对应的上传参数将服务部署组件发送至运维服务端的主服务器中的步骤之前，方法还包括；

利用主服务器建立从服务器。

在一些实施方式中，利用主服务器建立从服务器的步骤，包括：

控制运维服务端接收从服务器配置参数，并对从服务器配置参数进行校验；

根据校验结果生成运维服务端与运维客户端之间的连接指令，利用连接指令控制运维服务端与运维客户端进行连接；

当运维服务端与运维客户端完成连接后，控制运维服务端将服务安装组件发送至运维客户端中；

控制运维客户端对服务安装组件进行部署，建立从服务器。

在一些实施方式中，控制运维客户端对服务安装组件进行部署，建立从服务器的步骤，包括：

控制运维客户端对服务安装组件进行部署，实时获取从服务器的部署状态数据，并将部署状态数据实时发送至运维服务端；

从服务器完成建立后，实时获取从服务器的运行状态数据，并将运行状态数据实时发送至运维服务端。

在一些实施方式中，在从服务器中获取目标服务器，并利用目标服务器对应的上传参数将服务部署组件发送至运维服务端的主服务器中的步骤，包括：

获取目标服务器后，根据目标服务器的配置数据生成对应的执行脚本及其配置文件，并将执行脚本和配置文件保存至运维服务端的预设目录中；

利用目标服务器对应的上传参数将服务部署组件上传至目录中，并获取服务部署组件依赖的中间件；

将服务部署组件以及中间件保存至运维服务端的主服务器中。

在一些实施方式中，根据服务部署组件对应的组件属性数据生成通知指令，并控制运维服务端将通知指令发送至运维客户端的步骤，包括：

根据服务部署组件以及中间件对应的组件属性数据确定通知指令；

控制运维服务端将配置文件、执行脚本以及通知指令发送至运维客户端。

在一些实施方式中，运维客户端响应通知指令后，控制运维客户端与运维服务端建立长连接，并将服务部署组件从主服务器发送至从服务器中的步骤，包括：

客户端接收通知指令后，通过SSH与运维服务端建立长连接，并将长连接的状态参数发送至运维服务端；

利用状态参数控制运维服务端将服务部署组件以及执行脚本发送至从服务器中。

在一些实施方式中，控制运维客户端将服务部署组件安装至从服务器中，实时获取服务部署组件的运行状态数据，并将运行状态数据发送至运维服务端的步骤，包括：

获取运维客户端接收的配置文件和执行脚本；

根据服务部署组件对应的中间件，并利用配置文件执行对应的执行脚本，控制服务部署组件安装至从服务器中；

实时获取服务部署组件的运行状态数据，并按照预设时间间隔将运行状态数据发送至运维服务端。

第二方面，本发明实施例提供了一种运维服务部署装置，该装置应用于包含运维服务端和运维客户端的运维系统中；其中，运维服务端设置有主服务器；运维客户端设置有从服务器；从服务器为基于主服务器部署的服务器；

该运维服务部署装置包括：

第一部署单元，用于在从服务器中获取目标服务器，并利用目标服务器对应的上传参数将服务部署组件发送至运维服务端的主服务器中；

第二部署单元，用于根据服务部署组件对应的组件属性数据生成通知指令，并控制运维服务端将通知指令发送至运维客户端；

第三部署单元，用于运维客户端响应通知指令后，控制运维客户端与运维服务端建立长连接，并将服务部署组件从主服务器发送至从服务器中；

第四部署单元，用于控制运维客户端将服务部署组件安装至从服务器中，实时获取服务部署组件的运行状态数据，并将运行状态数据发送至运维服务端。

第三方面，发明实施例还提供一种运维系统，该运维系统包括运维服务端和运维客户端；其中，运维服务端设置有主服务器；运维客户端设置有从服务器；从服务器为基于主服务器部署的服务器；

该运维系统中还包括：处理器和存储装置；存储装置上存储有计算机程序，计算机程序在被处理器运行时实现上述第一方面提到的运维服务部署方法的步骤。

第四方面，本发明实施例还提供一种可读存储介质，该可读存储介质上存储有计算机程序，其中，计算机程序被处理器运行时实现上述第一方面提到的运维服务部署方法的步骤。

本发明实施例带来了至少以下有益效果：

本发明提供了一种运维服务部署方法、装置及运维系统，应用于包含运维服务端和运维客户端的运维系统中；其中，运维服务端设置有主服务器；运维客户端设置有从服务器；从服务器为基于主服务器部署的服务器。在进行运维服务部署的过程中，首先在从服务器中获取目标服务器，并利用目标服务器对应的上传参数将服务部署组件发送至运维服务端的主服务器中；再根据服务部署组件对应的组件属性数据生成通知指令，并控制运维服务端将通知指令发送至运维客户端；在运维客户端响应通知指令后，控制运维客户端与运维服务端建立长连接，并将服务部署组件从主服务器发送至从服务器中；最后控制运维客户端将服务部署组件安装至从服务器中，实时获取服务部署组件的运行状态数据，并将运行状态数据发送至运维服务端。该方案在运维服务部署过程中能够简单高效的将服务部署组件部署至运维服务端，并可对部署过程进行实时监控，从而解决了现有运维服务中存在的部署复杂，自动化程度低的问题。

本发明的其他特征和优点将在随后的说明书中阐述，或者，部分特征和优点可以从说明书推知或毫无疑义的确定，或者通过实施本发明的上述技术即可得知。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施方式，并配合所附附图，作详细说明如下。

附图说明

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

图1为本发明实施例提供的一种运维服务部署方法的流程图；

图2为本发明实施例提供的一种运维服务部署方法中利用主服务器建立从服务器的流程图；

图3为本发明实施例提供的一种运维服务部署方法中步骤S204的流程图；

图4为本发明实施例提供的一种运维服务部署方法中步骤S101的流程图；

图5为本发明实施例提供的一种运维服务部署方法中步骤S102的流程图；

图6为本发明实施例提供的一种运维服务部署方法中步骤S103的流程图；

图7为本发明实施例提供的一种运维服务部署方法中步骤S104的流程图；

图8为本发明实施例提供的一种运维系统的框架图；

图9为本发明实施例提供的一种运维服务部署方法中从服务器添加的工作原理图；

图10为本发明实施例提供的一种运维服务部署方法中运维系统的工作原理图；

图11为本发明实施例提供的一种运维服务部署方法中运维管理的流程图；

图12为本发明实施例提供的一种运维服务部署方法中服务器添加的流程图；

图13为本发明实施例提供的一种运维服务部署方法中组件安装流程图；

图14为本发明实施例提供的一种运维服务部署装置的结构示意图；

图15为本发明实施例提供的一种电子设备的结构示意图。

图标：

1410-第一部署单元；1420-第二部署单元；1430-第三部署单元；1440-第四部署单元；

101-处理器；102-存储器；103-总线；104-通信接口。

具体实施方式

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

项目在部署运维阶段时，项目包的形式不同，其部署运维的方式也不尽相同。运维部署依赖于开发提供的运维部署手册，手册的质量以及现场实施人员对手册的理解是运维部署执行效果的关键。具体的说，目前存在的服务包存在以下集中情况：第一种是war包，该项目包需要部署在tomcat这类web服务器中启动；第二种是jar包，在linux服务器中通过执行运行命令启动；第三种是镜像包，通过docker容器部署。同时服务包的部署脚本、执行命令也不尽相同。因此实际场景中存在以下问题：

项目部署往往过于复杂，运维的脚本过多，不利于现场实施人员部署，各组件之间依赖配置繁复需要逐一比对，容易出错且不好排查；

过度依赖运维部署手册，手册的质量以及现场实施人员对手册的理解成为对部署运维的制约因素，且过多的部署文档难以对其进行有效的管理；

服务在升级的时候可能会涉及到多个组件，导致项目升级容易出现问题。

综上所述，现有的运维服务还存在着部署复杂，自动化程度低的问题。基于此，本发明实施例提供的一种运维服务部署方法、装置及运维系统，该方案在运维服务部署过程中能够简单高效的将服务部署组件部署至运维服务端，并可对部署过程进行实时监控，从而解决了现有运维服务中存在的部署复杂，自动化程度低的问题。

为便于对本实施例进行理解，首先对本发明实施例所公开的一种运维服务部署方法进行详细介绍。该方法应用于包含运维服务端和运维客户端的运维系统中；其中，运维服务端设置有主服务器；运维客户端设置有从服务器；从服务器为基于主服务器部署的服务器。在此基础上，该运维服务部署方法如图1所示，包括：

步骤S101，在从服务器中获取目标服务器，并利用目标服务器对应的上传参数将服务部署组件发送至运维服务端的主服务器中。

从用户层面上看，运维人员基于使用需求首先获取相应的目标服务器，根据目标服务器对应的上传参数将服务部署组件进行上传。

步骤S102，根据服务部署组件对应的组件属性数据生成通知指令，并控制运维服务端将通知指令发送至运维客户端。

运维服务端接收服务部署组件后，获取其相应的组件属性数据，并利用该组组件属性数据生成相应的通知指令，然后将通知指令发送至运维客户端，通知运维客户端对服务部署组件进行拉取。

步骤S103，运维客户端响应通知指令后，控制运维客户端与运维服务端建立长连接，并将服务部署组件从主服务器发送至从服务器中。

运维客户端接收到通知指令后对其进行响应，然后与运维服务端建立长连接，并向运维服务端进行数据请求，将服务部署组件从主服务器拉取至从服务器中。

步骤S104，控制运维客户端将服务部署组件安装至从服务器中，实时获取服务部署组件的运行状态数据，并将运行状态数据发送至运维服务端。

运维客户端将服务部署组件从主服务器拉取完成后，对服务部署组件进行解析部署，将服务部署组件安装至从服务器中。然后对从服务器中服务部署组件的运行状态进行实时分析，获取其运行状态数据，并将该数据发送至运维服务端，进而再传递至用户中。

在进行运维服务部署之前，需要对从服务器进行添加。因此在从服务器中获取目标服务器，并利用目标服务器对应的上传参数将服务部署组件发送至运维服务端的主服务器中的步骤之前，该方法还包括；利用主服务器建立从服务器。

具体在实施过程中，利用主服务器建立从服务器的过程，如图2所示，包括：

步骤S201，控制运维服务端接收从服务器配置参数，并对从服务器配置参数进行校验。

首先根据配置需要获取从服务器的相关配置参数，并将服务器配置参数发送至运维服务端，然后对运维服务端中的服务器配置参数进行校验。

步骤S202，根据校验结果生成运维服务端与运维客户端之间的连接指令，利用连接指令控制运维服务端与运维客户端进行连接。

校验结果决定后续的流程，如果校验结果为异常，则停止后续步骤；如果校验正常，则尝试运维服务端与运维客户端进行连接。这个过程通过连接指令来实现，连接指令通过校验结果以及从服务器配置参数确定的。

步骤S203，当运维服务端与运维客户端完成连接后，控制运维服务端将服务安装组件发送至运维客户端中。

如果运维服务端与运维客户端连接失败，则进行提示并停止后续步骤；如果运维服务端与运维客户端连接成功，则控制运维服务端将服务安装组件发送至运维客户端中。这个过程需要控制运维服务端向运维客户端建立长连接，然后将服务安装组件通过长连接的方式发送至运维客户端中。

步骤S204，控制运维客户端对服务安装组件进行部署，建立从服务器。

当服务安装组件全部推送完毕后，控制运维客户端执行安装部署，从而建立服务器。具体场景中，如图3所示，包括：

步骤S31，控制运维客户端对服务安装组件进行部署，实时获取从服务器的部署状态数据，并将部署状态数据实时发送至运维服务端；

步骤S32，从服务器完成建立后，实时获取从服务器的运行状态数据，并将运行状态数据实时发送至运维服务端。

在控制运维客户端进行安装部署的过程中，实施获取部署状态数据，然后将该数据发送至运维服务端中，从而对安装过程进行实时监控。当从服务器完成建立后，实施获取从服务器的运行状态数据，并将运行状态数据发送至运维服务端，从而对运行过程进行实时监控。

在一些实施方式中，在从服务器中获取目标服务器，并利用目标服务器对应的上传参数将服务部署组件发送至运维服务端的主服务器中的步骤S101，如图4所示，包括：

步骤S401，获取目标服务器后，根据目标服务器的配置数据生成对应的执行脚本及其配置文件，并将执行脚本和配置文件保存至运维服务端的预设目录中。

步骤S402，利用目标服务器对应的上传参数将服务部署组件上传至目录中，并获取服务部署组件依赖的中间件。

步骤S403，将服务部署组件以及中间件保存至运维服务端的主服务器中。

在将服务部署组件发送至运维服务器的过程中，可将服务部署组件以及相应的配置文件、执行脚本一起创建在指定目录中。具体可通过相应的插件，将服务部署组件、配置文件以及执行脚本进行打包，得到对应的组件包，并将组件包发送至运维服务端的主服务器中。

在一些实施方式中，根据服务部署组件对应的组件属性数据生成通知指令，并控制运维服务端将通知指令发送至运维客户端的步骤S102，如图5所示，包括：

步骤S501，根据服务部署组件以及中间件对应的组件属性数据确定通知指令；

步骤S502，控制运维服务端将配置文件、执行脚本以及通知指令发送至运维客户端。

根据选择的服务部署组件以及中间件，记录组件包关联的中间件信息。特别说明的是，不同中间件的参数均进行了特殊内部约定。

服务部署组件以及中间件获取后，根据其对应的组件属性数据确定与运维客户端之间的通知指令，并将配置文件、执行脚本以及通知指令均发送至运维客户端。通知指令用于告知运维客户端需要拉取组件包，因此向运维客户端发送通知指令后需要对其响应数据进行实时获取。

在一些实施方式中，运维客户端响应通知指令后，控制运维客户端与运维服务端建立长连接，并将服务部署组件从主服务器发送至从服务器中的步骤S103，如图6所示，包括：

步骤S601，客户端接收通知指令后，通过SSH与运维服务端建立长连接，并将长连接的状态参数发送至运维服务端；

步骤S602，利用状态参数控制运维服务端将服务部署组件以及执行脚本发送至从服务器中。

客户端接收到该通知指令后，通过SSH建立与运维服务端之间的远程长连接。长连接建立后需要获取其对应的状态参数，并将该状态参数发送至运维服务端。而运维服务端利用状态参数了解到长连接已完成建立后，将组件包发送给至从服务器中。发送过程可通过发送组件包的形式来实现，具体的，运维服务端下发指令到运维客户端，运维客户端执行该指令将组件包复制到相应的从服务器中。

在一些实施方式中，控制运维客户端将服务部署组件安装至从服务器中，实时获取服务部署组件的运行状态数据，并将运行状态数据发送至运维服务端的步骤S104，如图7所示，包括：

步骤S701，获取运维客户端接收的配置文件和执行脚本；

步骤S702，根据服务部署组件对应的中间件，并利用配置文件执行对应执行脚本，控制服务部署组件安装至从服务器中；

步骤S703，实时获取服务部署组件的运行状态数据，并按照预设时间间隔将运行状态数据发送至运维服务端。

运维客户端解析该组件包，得到运维客户端接收的配置文件和执行脚本，并根据服务部署组件对应的中间件，利用配置文件执行对应执行脚本，控制服务部署组件安装至从服务器中。这个过程中，运维客户端实时获取服务部署组件的额运行状态数据，并按照预设的时间间隔定时推送组件运行状态数据至运维服务端。运维服务端同步监控信息，并将该信息发送至用户。

上述实施例中的运维系统是一个比较宽泛的描述，如图8所示的运维系统框架图可知，该运维系统包含了运维服务端和运维客户端，运维服务端对应了业务展现层和业务处理层；运维客户端对应了数据采集层和被管理对象。具体的，业务展现层统一运维门户、用户账号、权限管理等功能，通过大屏展示、运维服务门户、服务器资源管理以及容器运维管理来实现业务展现。业务处理层，主要对各种业务数据进行处理，这些业务数据包括：资源配置信息、资源监控指标、日志信息、流程引擎、实时数据处理、统计分析引擎等方面。数据采集层实现对运维系统及业务应用进行实时监控，具体通过相应的容器探针来对被管理对象中涉及的数据库、中间件、服务器以及相关业务系统进行数据监听。

具体的说，运维系统由被管理对象、数据采集层、业务处理层、业务展现层组成，数据采集层通过探针监听被管理对象信息并将数据推送到业务处理层，处理过后的数据最终在业务展现层展现。被管理对象与数据采集层作为运维客户端，业务处理成与业务展现层作业运维服务端。

其从服务器添加的工作原理图如图9所示，核心步骤为：

实现服务器配置步骤：

步骤一：配置服务器IP、用户名、密码等信息，并且验证其正确性，并配置免密登录；

步骤二：运维平台通过ssh推送运维客户端组件包到从服务器，运维平台下发命令到从服务器执行安装部署；

步骤三：客户端安装成功后，通过tcp通知运维平台；

步骤四：从服务器通过客户端推送从服务器运行信息到运维平台，进行服务器监控。

图10为一种运维系统的工作原理图，其主要描述项目部署的过程。其核心步骤为：

步骤一：通过assembly构建组件包，将配置文件与项目运行脚本构建在指定目录中；

步骤二：上传组件包到运维服务端服务器指定目录；

步骤三：选择组件部署服务器以及组件涉及中间件，并记录组件包关联中间件信息；

步骤四：运维服务端下发指令到运维客户端，客户端执行命令将组件包复制到所在服务器；

步骤五：客户端解析组件包并读取关联中间件信息，替换组件原有相关配置，并执行运行脚本；

步骤五：客户端读取组件运行状态，并通过tcp回传给服务端；

步骤六：服务端接收客户端传递消息并展示；

步骤七：服务端查看组件运行信息，通过下发指令到客户端，客户端通过执行命令返回日志信息。

图11为运维管理的流程图可知，在进行运维管理的过程中，首先登录运维系统，然后上传组件包，然后选择服务器，再选择中间件，再提交运维，然后查询运维状态。

具体场景中，可监听容器运行状态，根据设置阈值进行容器扩容，自动寻找空闲可用机器，自动扩容，容器自动回收。

中间件部署过程如下：

以中间件mysql为例，通过运维平台上传mysql组件包到运维主服务器，所有组件存储在指定位置；

点击组件部署，这时可以选择运维平台绑定的从服务器进行部署mysql,选择好从服务器后将mysql组件包传输到选定从服务器的相应目录；

运维平台接收上传完毕状态后，会下发执行部署命令到相应从服务器，进行运维部署，同时从服务器的容器探针会监听容器运行状态回传到运维平台进行监控，同时如果组件配有参数的话会一并回传，例如mysql的连接信息；

运维平台可以组件进行扩容策略配置，以mysql为例：需要设置容器属性（容器运行需要占用的服务器资源），配置策略脚本，配置阈值等：例如cpu,内存状态等，阈值分为回收阈值与扩容阈值，当容器触发相应阈值时，执行相应策略；

容器扩容：根据容器属性，通过轮询策略寻找合适的从服务器进行容器部署，通过策略脚本完成容器部署，mysql主从搭建等；

容器回收：一般用于服务应用，例如当权限服务三分之二的容器实例触发了回收阈值，那么服务会从触发回收阈值的容器实例中随机选择一个进行回收。

应用服务：以nacos为例，通过运维平台上传mysql组件包到运维主服务器，所有组件存储在指定位置；

点击组件部署，这时可以选择运维平台绑定的从服务器进行部署nacos,选择好从服务器后，需要确认选择是否依赖中间件，如果服务依赖其他中间件，则进行选择中间件，例如nacos依赖mysql中间件，选择后服务部署时会读取mysql参数信息（特别说明，不同中间件的参数均进行了特殊内部约定）进行nacos部署。

运维平台接收上传完毕状态后，会下发执行部署命令到相应从服务器，进行运维部署，同时从服务器的容器探针会监听容器运行状态回传到运维平台进行监控，同时如果组件配有参数的话会一并回传。

运维平台可以组件进行扩容策略配置，以nacos为例：需要设置容器属性（容器运行需要占用的服务器资源），配置策略脚本，配置阈值等：例如cpu,内存状态等，阈值分为回收阈值与扩容阈值，当容器触发相应阈值时，执行相应策略；

容器扩容：根据容器属性，通过轮询策略寻找合适的从服务器进行容器部署，通过策略脚本完成容器部署，nacos集群搭建等；

容器回收：一般用于服务应用，例如当权限服务三分之二的容器实例触发了回收阈值，那么服务会从触发回收阈值的容器实例中随机选择一个进行回收。

图12为服务器添加流程图，在服务器添加过程中，首先登录运维系统，然配置相关服务信息，然后进行测试连接并判断连接是否成功。如果失败，则重新配置服务信息；如果成功，则自动配置免密，自动部署运维客户端；然后运维系统检测运维客户端运行状态，并判断运行状态是否正常。如果是，则结束；如果否，则推送异常告警信息。

免密配置是当测试连接服务器成功时自动执行脚本进行的配置。运行状态异常判定过程是运维客户端会监控服务器的cpu、内存等过程，当达到指定阈值时会触发异常告警。

图13为组件安装流程图，在组件安装过程中，首先上传组件包，然后选择相应的服务器，再选取中间件，然后运维服务端通知客户端拉去组件包，客户端获取组件后选取中间信息，运维客户端解析组件包，并更新组件配置信息，然后客户端执行组件运行脚本后，客户端监听组件运行状态并推送给运维服务端。

以nacos为例，通过运维平台上传mysql组件包到运维主服务器，所有组件存储在指定位置。

点击组件部署，这时可以选择运维平台绑定的从服务器进行部署nacos,选择好从服务器后，需要确认选择是否依赖中间件，如果服务依赖其他中间件，则进行选择中间件，例如nacos依赖mysql中间件，选择后服务部署时会读取mysql参数信息（特别说明，不同中间件的参数均进行了特殊内部约定）进行nacos部署。

运维平台接收上传完毕状态后，会下发执行部署命令到相应从服务器，进行运维部署，同时从服务器的容器探针会监听容器运行状态回传到运维平台进行监控，同时如果组件配有参数的话会一并回传。

从和服务器解析nacos组件包，通过读取nacos组件包中的配置文件来获取依赖mysql中间件信息，nacos服务的配置信息，运行脚本的位置，执行脚本的命令等信息，通过运行执行脚本命令来部署服务。

运维平台可以组件进行扩容策略配置，以nacos为例：需要设置容器属性（容器运行需要占用的服务器资源），配置策略脚本，配置阈值等：例如cpu,内存状态等，阈值分为回收阈值与扩容阈值，当容器触发相应阈值时，执行相应策略。

容器扩容：根据容器属性，通过轮询策略寻找合适的从服务器进行容器部署，通过策略脚本完成容器部署，nacos集群搭建等。

容器回收：一般用于服务应用，例如当权限服务三分之二的容器实例触发了回收阈值，那么服务会从触发回收阈值的容器实例中随机选择一个进行回收。

由此可见，该运维系统中采用运维服务部署方法，可采用ssh建立各个服务器之间连接，主服务器部署运维服务端，在用户配置服务器时，通过ssh建立通讯，并下发运维客户端服务包到配置服务器进行安装部署，客户端用于接收与服务端指令、监听组件服务的运行状态、推送组件祖运行信息等。同时对于组件包采用assembly进行构建，并且将配置信息与运行脚本封装到指定目录。

从上述实施例中提到的运维服务部署方法可知，该方法在运维服务部署过程中能够简单高效的将服务部署组件部署至运维服务端，并可对部署过程进行实时监控，从而解决了现有运维服务中存在的部署复杂，自动化程度低的问题。

对应于上述方法实施例，本发明实施例提供了一种运维服务部署装置，该装置应用于包含运维服务端和运维客户端的运维系统中；其中，运维服务端设置有主服务器；运维客户端设置有从服务器；从服务器为基于主服务器部署的服务器。

如图14所示，该运维服务部署装置包括：

第一部署单元1410，用于在从服务器中获取目标服务器，并利用目标服务器对应的上传参数将服务部署组件发送至运维服务端的主服务器中；

第二部署单元1420，用于根据服务部署组件对应的组件属性数据生成通知指令，并控制运维服务端将通知指令发送至运维客户端；

第三部署单元1430，用于运维客户端响应通知指令后，控制运维客户端与运维服务端建立长连接，并将服务部署组件从主服务器发送至从服务器中；

第四部署单元1440，用于控制运维客户端将服务部署组件安装至从服务器中，实时获取服务部署组件的运行状态数据，并将运行状态数据发送至运维服务端。

通过上述实施例中提到的运维服务部署装置可知，该装置在运维服务部署过程中能够简单高效的将服务部署组件部署至运维服务端，并可对部署过程进行实时监控，从而解决了现有运维服务中存在的部署复杂，自动化程度低的问题。

本实施例提供的运维服务部署装置，与上述实施例提供的运维服务部署方法具有相同的技术特征，所以也能解决相同的技术问题，达到相同的技术效果。为简要描述，实施例部分未提及之处，可参考前述运维服务部署方法实施例中相应内容。

本实施例还提供一种运维系统，该运维系统包括运维服务端和运维客户端；其中，运维服务端设置有主服务器；运维客户端设置有从服务器；从服务器为基于主服务器部署的服务器。如图15所示，该运维系统包括处理器101和存储器102；其中，存储器102用于存储一条或多条计算机指令，一条或多条计算机指令被处理器执行，以实现上述运维服务部署方法的步骤。

图15所示的电子设备还包括总线103和通信接口104，处理器101、通信接口104和存储器102通过总线103连接。

其中，存储器102可能包含高速随机存取存储器（RAM，Random Access Memory），也可能还包括非不稳定的存储器（non-volatile memory），例如至少一个磁盘存储器。总线103可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图15中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

通信接口104用于通过网络接口与至少一个用户终端及其它网络单元连接，将封装好的IPv4报文或IPv4报文通过网络接口发送至用户终端。

处理器101可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器101中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器101可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DigitalSignal Processor，简称DSP)、专用集成电路(Application Specific IntegratedCircuit，简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本公开实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本公开实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器102，处理器101读取存储器102中的信息，结合其硬件完成前述实施例的方法的步骤。

本发明实施例还提供了一种可读存储介质，该可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行前述实施例的运维服务部署方法的步骤。

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

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

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种运维服务部署方法，其特征在于，所述方法应用于包含运维服务端和运维客户端的运维系统中；其中，所述运维服务端设置有主服务器；所述运维客户端设置有从服务器；所述从服务器为基于所述主服务器部署的服务器；

所述运维服务部署方法包括：

在所述从服务器中获取目标服务器，并利用所述目标服务器对应的上传参数将服务部署组件发送至所述运维服务端的所述主服务器中；

根据所述服务部署组件对应的组件属性数据生成通知指令，并控制所述运维服务端将所述通知指令发送至所述运维客户端；

所述运维客户端响应所述通知指令后，控制所述运维客户端与所述运维服务端建立长连接，并将所述服务部署组件从所述主服务器发送至所述从服务器中；

控制所述运维客户端将所述服务部署组件安装至所述从服务器中，实时获取所述服务部署组件的运行状态数据，并将所述运行状态数据发送至所述运维服务端。

2.根据权利要求1所述的运维服务部署方法，其特征在于，所述在所述从服务器中获取目标服务器，并利用所述目标服务器对应的上传参数将服务部署组件发送至所述运维服务端的所述主服务器中的步骤之前，所述方法还包括；

利用所述主服务器建立所述从服务器。

3.根据权利要求1所述的运维服务部署方法，其特征在于，所述利用所述主服务器建立所述从服务器的步骤，包括：

控制所述运维服务端接收从服务器配置参数，并对所述从服务器配置参数进行校验；

根据校验结果生成所述运维服务端与所述运维客户端之间的连接指令，利用所述连接指令控制所述运维服务端与所述运维客户端进行连接；

当所述运维服务端与所述运维客户端完成连接后，控制所述运维服务端将服务安装组件发送至所述运维客户端中；

控制所述运维客户端对所述服务安装组件进行部署，建立所述从服务器。

4.根据权利要求3所述的运维服务部署方法，其特征在于，所述控制所述运维客户端对所述服务安装组件进行部署，建立所述从服务器的步骤，包括：

控制所述运维客户端对所述服务安装组件进行部署，实时获取所述从服务器的部署状态数据，并将所述部署状态数据实时发送至所述运维服务端；

所述从服务器完成建立后，实时获取所述从服务器的运行状态数据，并将所述运行状态数据实时发送至所述运维服务端。

5.根据权利要求1所述的运维服务部署方法，其特征在于，在所述从服务器中获取目标服务器，并利用所述目标服务器对应的上传参数将服务部署组件发送至所述运维服务端的所述主服务器中的步骤，包括：

获取所述目标服务器后，根据所述目标服务器的配置数据生成对应的执行脚本及其配置文件，并将所述执行脚本和所述配置文件保存至所述运维服务端的预设目录中；

利用所述目标服务器对应的上传参数将所述服务部署组件上传至所述目录中，并获取所述服务部署组件依赖的中间件；

将所述服务部署组件以及所述中间件保存至所述运维服务端的所述主服务器中。

6.根据权利要求5所述的运维服务部署方法，其特征在于，根据所述服务部署组件对应的组件属性数据生成通知指令，并控制所述运维服务端将所述通知指令发送至所述运维客户端的步骤，包括：

根据所述服务部署组件以及所述中间件对应的组件属性数据确定所述通知指令；

控制所述运维服务端将所述配置文件、所述执行脚本以及所述通知指令发送至所述运维客户端。

7.根据权利要求6所述的运维服务部署方法，其特征在于，所述运维客户端响应所述通知指令后，控制所述运维客户端与所述运维服务端建立长连接，并将所述服务部署组件从所述主服务器发送至所述从服务器中的步骤，包括：

所述客户端接收所述通知指令后，通过SSH与所述运维服务端建立长连接，并将所述长连接的状态参数发送至所述运维服务端；

利用所述状态参数控制所述运维服务端将所述服务部署组件以及所述执行脚本发送至所述从服务器中。

8.根据权利要求7所述的运维服务部署方法，其特征在于，控制所述运维客户端将所述服务部署组件安装至所述从服务器中，实时获取所述服务部署组件的运行状态数据，并将所述运行状态数据发送至所述运维服务端的步骤，包括：

获取所述运维客户端接收的所述配置文件和所述执行脚本；

根据所述服务部署组件对应的所述中间件，并利用所述配置文件执行对应的所述执行脚本，控制所述服务部署组件安装至所述从服务器中；

实时获取所述服务部署组件的运行状态数据，并按照预设时间间隔将所述运行状态数据发送至所述运维服务端。

9.一种运维服务部署装置，其特征在于，所述装置应用于包含运维服务端和运维客户端的运维系统中；其中，所述运维服务端设置有主服务器；所述运维客户端设置有从服务器；所述从服务器为基于所述主服务器部署的服务器；

所述运维服务部署装置包括：

第一部署单元，用于在所述从服务器中获取目标服务器，并利用所述目标服务器对应的上传参数将服务部署组件发送至所述运维服务端的所述主服务器中；

第二部署单元，用于根据所述服务部署组件对应的组件属性数据生成通知指令，并控制所述运维服务端将所述通知指令发送至所述运维客户端；

第三部署单元，用于所述运维客户端响应所述通知指令后，控制所述运维客户端与所述运维服务端建立长连接，并将所述服务部署组件从所述主服务器发送至所述从服务器中；

第四部署单元，用于控制所述运维客户端将所述服务部署组件安装至所述从服务器中，实时获取所述服务部署组件的运行状态数据，并将所述运行状态数据发送至所述运维服务端。

10.一种运维系统，其特征在于，所述运维系统包括运维服务端和运维客户端；其中，所述运维服务端设置有主服务器；所述运维客户端设置有从服务器；所述从服务器为基于所述主服务器部署的服务器；

所述运维系统中还包括：处理器和存储装置；所述存储装置上存储有计算机程序，所述计算机程序在被所述处理器运行时实现上述权利要求1至8任一项所述的运维服务部署方法的步骤。