CN111782231B - 服务部署方法和装置 - Google Patents

Abstract

本申请实施例公开了服务部署方法和装置。该方法的一具体实施方式包括：获取用户配置的服务安装相关数据；根据用户配置的地址集合，将服务安装相关数据发送到用于安装服务的服务器集群中的目标服务器；在目标服务器上生成安装目录，并基于地址集合，将安装目录分发到服务器集群中的每个服务器；控制服务器集群根据服务安装相关数据安装服务，并在服务器集群上启动服务。该实施方式实现了远程自动化地部署、操作服务，降低了服务运维操作的难度。

Description

服务部署方法和装置

技术领域

本申请实施例涉及计算机技术领域，具体涉及服务部署方法和装置。

背景技术

随着大数据时代的到来，不断增长的软件复杂度和部署软件所面临的风险，迫使人们开始关注组件部署。组件部署是一个复杂过程，包括从开发商发放产品，到应用者在他们的计算机上实际安装并维护应用的所有活动。这些活动包括组件打包，企业及用户对组件的安装、配置、测试、集成和更新等。

组件部署存在着风险，这是由于以下原因造成的：组件越来越复杂，包括许多构件、版本和变种；组件发展很快，相继两个版本的间隔很短(可能只有几个月)；环境的不确定性；构件的来源多样性等。

组件部署及操作过程的主要特征有：过程覆盖度、过程可变更性、过程间协调和模型抽象。

组件部署过程中需要关注的问题有：安装和系统运行的变更管理、构件之间的相依、协调、内容发放、部署过程的可变更性和安全性。

传统的组件安装及操作过程是将组件安装包下载好或者对组件源码包编译好之后，通过命令行的操作，对安装包进行解压；解压完成之后再修改对应的配置文件，创建对应的数据目录，初始化关联集群，然后才能对组件进行启动。但是，当面临大批量主机系统安装时，传统的安装方法会存在下列问题：

一是需要现场操作，会耗费不必要的人力、物力；

二是难以批量操作，容错性低，效率低；

三是难以维护，当安装出现问题时，操作繁琐，追寻原因困难；

四是组件启动困难，尤其是需要关联的组件，必须要启动它的依赖组件之后才能启动服务组件，这就造成了启动的困扰。同时启动组件之后还需要手动去验证服务进程是否启动成功。

发明内容

本申请实施例的目的在于提出了一种改进的服务部署方法和装置，来解决以上背景技术部分提到的技术问题。

第一方面，本申请实施例提供了一种服务部署方法，该方法包括：获取用户配置的服务安装相关数据；根据用户配置的地址集合，将服务安装相关数据发送到用于安装服务的服务器集群中的目标服务器；在目标服务器上生成安装目录，并基于地址集合，将安装目录分发到服务器集群中的每个服务器；控制服务器集群根据服务安装相关数据安装服务，并在服务器集群上启动服务。

在一些实施例中，在获取用户配置的服务安装相关数据之前，该方法还包括：基于用户在可视化界面的操作，选择待部署的服务的服务安装包及相关脚本；选择待部署的服务对应的服务器集群对应的地址集合；确定待部署的服务的基本信息；基于服务安装包、相关脚本、地址集合和基本信息，生成服务安装相关数据。

在一些实施例中，基本信息包括以下至少一种：服务版本、组件名称、服务名称、数据目录、日志目录。

在一些实施例中，在获取用户配置的服务安装相关数据之后，该方法还包括：确定服务安装相关数据对应的服务是否具有依赖服务；如果有，获取依赖服务的相关数据，并选择服务对应的服务器集群的地址集合。

在一些实施例中，控制服务器集群根据服务安装相关数据安装服务，包括：确定服务器集群中的服务器上是否存在服务安装目录；如果不存在，安装服务安装相关数据，并接收服务器发送的表征服务安装成功的信息。

在一些实施例中，在服务器集群上启动服务，包括：将用于启动服务的启动服务脚本上传到服务器集群；控制启动服务脚本在服务器集群中的服务器上启动；在服务器集群包括的服务器上确定服务的运行情况；基于运行情况，确定服务是否启动成功。

在一些实施例中，在服务器集群中的服务器上运行的服务包括至少一个角色；以及基于运行情况，确定服务是否启动成功，包括：对于至少一个角色中的每个角色，从服务器集群中确定运行该角色的服务器的数量，如果数量等于预先配置该角色的服务器的总数，确定该角色启动成功；响应于确定各个角色均启动成功，确定服务启动成功。

在一些实施例中，控制启动服务脚本在服务器集群中的服务器上启动，包括：确定服务是否具有依赖服务；如果有，控制依赖服务在服务器集群中的服务器上启动。

第二方面，本申请实施例提供了一种服务部署装置，该装置包括：第一获取模块，用于获取用户配置的服务安装相关数据；发送模块，用于根据用户配置的地址集合，将服务安装相关数据发送到用于安装服务的服务器集群中的目标服务器；第一生成模块，用于在目标服务器上生成安装目录，并基于地址集合，将安装目录分发到服务器集群中的每个服务器；安装模块，用于控制服务器集群根据服务安装相关数据安装服务，并在服务器集群上启动服务。

第三方面，本申请实施例提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当一个或多个程序被一个或多个处理器执行，使得一个或多个处理器实现如第一方面中任一实现方式描述的方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如第一方面中任一实现方式描述的方法。

本申请实施例提供的服务部署方法和装置，通过根据用户配置的地址集合，将服务安装相关数据发送到用于安装服务的服务器集群中的目标服务器，在目标服务器上生成安装目录，并基于地址集合，将安装目录分发到服务器集群中的每个服务器，控制服务器集群根据服务安装相关数据安装服务，并在服务器集群上启动服务，从而实现了远程自动化地部署、操作服务，降低了服务运维操作的难度。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1是本申请可以应用于其中的示例性系统架构图；

图2是根据本申请的服务部署方法的一个实施例的流程图；

图3是根据本申请的服务部署方法的又一个实施例的流程图；

图4是根据本申请的服务部署装置的一个实施例的结构示意图；

图5是适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

图1示出了可以应用本申请实施例的服务部署方法的示例性系统架构100。

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

用户可以使用终端设备101通过网络102与服务器集群103交互，以接收或发送消息等。终端设备101上可以安装有各种通讯客户端应用，例如可视化服务操作应用、数据处理应用、搜索类应用、网页浏览器应用、购物类应用、即时通信工具等。

终端设备101可以是各种电子设备，包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。

服务器集群103可以是提供各种服务的服务器，例如对终端设备101上传的服务安装相关数据进行部署的服务器。服务器可以根据用户在终端设备101对服务进行的配置，安装、运行各种服务。

需要说明的是，终端设备101可以远程对服务器集群103进行操作，即在服务器上执行的操作可以由终端设备101控制。服务器集群103中的某台服务器可以远程对其他服务器进行操作。因此，本申请实施例所提供的服务部署方法可以由终端设备101执行，也可以由服务器集群103中的任一服务器执行，相应地，服务部署装置可以设置于终端设备101中，也可以设置于服务器集群103中的任一服务器中。

应该理解，图1中的终端设备、网络、服务器集群以及服务器集群包括的服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

继续参考图2，其示出了根据本申请的应服务部署方法的一个实施例的流程200。该方法包括以下步骤：

步骤201，获取用户配置的服务安装相关数据。

在本实施例中，服务部署方法的执行主体(例如图1所示的终端设备或服务器)可以获取用户配置的服务安装相关数据。其中，服务安装相关数据可以是为了使服务器实现某种功能所需要的各种数据。例如，为了在服务器上部署组件(例如MySQL、HDFS、HBase、MongoDB等大数据组件)，并且基于组件运行某些实例(即服务)，需要在服务器集群上安装组件，及对组件进行配置以执行服务。安装及配置服务所需的数据(例如组件安装包、配置文件、配置服务的服务器的地址等)即服务安装相关数据。

步骤202，根据用户配置的地址集合，将服务安装相关数据发送到用于安装服务的服务器集群中的目标服务器。

在本实施例中，上述执行主体可以根据用户配置的地址集合，将服务安装相关数据发送到用于安装服务的服务器集群中的目标服务器。其中，地址集合可以是用户在上述执行主体上选择的、组成服务器集群的每个服务器的地址(例如IP地址)的集合。目标服务器为用于在服务器集群中的各个服务器上部署服务所选定的服务器，例如，目标服务器可以是用户任意选择的服务器，也可以是由上述执行主体随机选择的服务器。

步骤203，在目标服务器上生成安装目录，并基于地址集合，将安装目录分发到服务器集群中的每个服务器。

在本实施例中，上述执行主体可以通过远程控制目标服务器，在目标服务器上生成安装目录，并基于地址集合，将安装目录分发到服务器集群中的每个服务器。其中，安装目录为用于部署服务的各种数据的集合。例如，安装目录可以包括组件的源码包、修改之后的配置文件、用于控制服务启动停止的脚本等。

步骤204，控制服务器集群根据服务安装相关数据安装服务，并在服务器集群上启动服务。

在本实施例中，上述执行主体可以控制服务器集群根据服务安装相关数据安装服务，并在服务器集群上启动服务。

具体地，上述执行主体可以上传服务安装脚本和服务启动服务脚本至各个服务器，并在各个服务器上运行服务安装脚本以安装服务，然后运行服务启动服务脚本以启动服务。

本申请的上述实施例提供的方法，通过根据用户配置的地址集合，将服务安装相关数据发送到用于安装服务的服务器集群中的目标服务器，在目标服务器上生成安装目录，并基于地址集合，将安装目录分发到服务器集群中的每个服务器，控制服务器集群根据服务安装相关数据安装服务，并在服务器集群上启动服务，从而实现了远程自动化地部署、操作服务，降低了服务运维操作的难度。

在本实施例的一些可选的实现方式中，如图3所示，在步骤201之前，上述执行主体还可以执行如下步骤：

步骤301，基于用户在可视化界面的操作，选择待部署的服务的服务安装包及相关脚本。

其中，可视化界面是用户用来配置服务所使用的界面，通常，可视化界面设置在如图1所示的终端设备上。用户利用可视化界面可以对服务进行各种操作。上述相关脚本可以包括服务安装脚本，用于利用服务安装包进行服务安装。

步骤302，选择待部署的服务对应的服务器集群对应的地址集合。

具体地，用户可以利用上述可视化界面，选择待部署的服务的服务器组成的服务器集群，上述地址集合中的每个地址对应于一个服务器。

步骤303，确定待部署的服务的基本信息。

其中，基本信息可以是用户利用上述可视化界面手动输入或选择的信息。基本信息包括各种信息。可选的，基本信息可以包括但不限于以下至少一种：服务版本、组件名称、服务名称、数据目录、日志目录。通过设置基本信息，可以使用户只聚焦于其关心的信息，便于用户操作，并且可以避免其他操作对部署服务造成的影响。

步骤304，基于服务安装包、相关脚本、地址集合和基本信息，生成服务安装相关数据。

作为示例，可以将服务安装包、相关脚本、地址集合和基本信息打包成一个压缩文件作为服务安装相关数据。

图3所示实施例提供的方法，通过设置可视化界面，在用户的操作下生成服务安装相关数据，从而可以使用户方便地对服务进行部署，用户只需关心部署服务所必要的信息，有助于简化服务部署的步骤，提供服务部署的效率，使服务部署更加灵活易用。

在本实施例的一些可选的实现方式中，在上述步骤201之后，上述执行主体还可以执行如下步骤：

首先，确定服务安装相关数据对应的服务是否具有依赖服务。

其中，依赖的服务是对上述待部署的服务提供支持的服务。作为示例，HBase需要依赖HDFS做底层数据的存储，此时若要启动HBase，就必须先要启动HDFS，HDFS即为HBase的依赖服务。

然后，如果确定具有依赖服务，获取依赖服务的相关数据，并选择服务对应的服务器集群的地址集合。

其中，依赖服务的相关数据可以包括服务安装包、启动脚本等数据，用于自动安装依赖服务。上述执行主体可以在用户的操作下，进一步选择上述服务器集群对应的地址集合。

本实现方式通过确定某个服务是否有依赖服务，并自动获取依赖服务，可以在部署服务时，同时部署依赖服务，从而可以无需手动选择依赖服务，提高部署服务的效率。

在本实施例的一些可选的实现方式中，在步骤204中，上述执行主体可以按照如下步骤控制服务器集群根据服务安装相关数据安装服务：

首先，确定服务器集群中的服务器上是否存在服务安装目录。

其中，服务安装目录是指某台待安装的服务器的组件目录。例如，待安装的组件为大数据组件ZK，服务安装目录可以是/usr/local/zk。此目录下存放的是ZK的源码文件、可执行文件、配置文件和人工编写的脚本(配置配置文件的脚本、启动停止的脚本等)。

然后，如果不存在，安装服务安装相关数据，并接收服务器发送的表征服务安装成功的信息。

具体地，如果某台服务器上不存在上述服务安装目录，表示此服务器上没有部署组件服务。此时，可以通过服务安装脚本运行该服务的安装过程。安装成功后，服务器可以向上述执行主体发送表征服务安装成功的信息。例如数字0表示安装成功。

相应的，如果服务器上存在上述服务安装目录，表示该服务器上已经安装了此组件服务，就不会继续安装，此时服务器返回数字1，表示服务部署失败。

本实现方式通过判断服务器上是否存在服务安装目录，可以快速、准确地确定服务器上是否成功部署服务，提高服务部署的效率，

在本实施例的一些可选的实现方式中，在步骤204中，上述执行主体可以根据如下步骤在服务器集群上启动服务：

步骤一，将用于启动服务的启动服务脚本上传到服务器集群。

其中，启动服务脚本用于在服务器上启动安装好的服务。需要说明的是，启动服务脚本可以在部署服务成功之后上传到服务器集群，也可以在部署服务的同时上传到服务器集群，本申请实施例对上传启动服务器脚本的时机不做限定。

步骤二，控制启动服务脚本在服务器集群中的服务器上启动。

具体地，启动服务脚本在启动后，可以在服务器上创建一个日志文件，用于记录上述服务的运行情况。例如，在一台服务器上运行的服务可以包括至少一个角色，日志文件可以用于记录不同角色的运行情况作为服务的运行情况。

步骤三，在服务器集群包括的服务器上确定服务的运行情况。

作为示例，上述执行主体可以循环地远程登录到各个服务器上，确定执行启动服务脚本的进程是否存在，如果存在，将服务器上的上述日志文件内容输出到上述执行主体中预先建立的txt文件中，每秒循环一次，上述执行主体根据该txt文件，可以确定各个服务器的运行情况。

步骤四，基于运行情况，确定服务是否启动成功。

具体地，如果运行情况表示各个服务器上的服务均正常启动，则服务器启动成功。

本实现方式通过确定各个服务器上的服务的运行情况，可以准确地判断服务是否启动成功，从而可以更灵活地对服务进行监控，提高部署服务的效率。

在本实施例的一些可选的实现方式中，在服务器集群中的服务器上运行的服务包括至少一个角色。其中，角色为组件中执行特定功能的模块。例如，HBase的角色有：HMaster(管理元数据和动态分配region)、regionservice(响应用户IO请求、读取和存储数据)。

基于此，上述步骤四可以包括如下子步骤：

首先，对于至少一个角色中的每个角色，从服务器集群中确定运行该角色的服务器的数量，如果数量等于预先配置该角色的服务器的总数，确定该角色启动成功。

具体地，各个角色的启动状态可以记录在服务器上的日志文件中，启动状态可以包括但不限于以下至少一种：角色名称、角色总数、已启动的角色数量等。同一角色位于不同的服务器上时，上述执行主体会循环地根据各个服务器上的日志文件的内容，判断该角色对应的进程是否存在，如果存在，表示角色已启动，如果已启动的角色数量等于预先配置该角色的服务器的总数，则表示该角色启动成功。启动成功的角色的状态信息可以为1，如果启动失败，角色的状态信息可以为2。

然后，响应于确定各个角色均启动成功，确定服务启动成功。

本实现方式通过累计各个角色的数量，确定各个角色是否启动成功，从而准确地判断服务是否正常启动，有助于精确地对部署的服务的启动情况进行监控，提高对服务进行部署的效率。

在本实施例的一些可选的实现方式中，上述步骤二可以包括如下子步骤：

首先，确定服务是否具有依赖服务。

然后，如果有依赖服务，控制依赖服务在服务器集群中的服务器上启动。依赖服务可以预先部署到各个服务器上，服务器可以在运行启动服务脚本时，启动依赖服务。相应的，如果没有依赖服务，可以直接启动上述服务。

本实现方式通过自动启动依赖服务，可以实现无需手动启动依赖服务，降低操作服务启动的复杂性，提高服务运行的效率。

进一步参考图4，作为对上述各图所示方法的实现，本申请提供了一种服务部署装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图4所示，本实施例的服务部署装置400包括：第一获取模块401，用于获取用户配置的服务安装相关数据；发送模块402，用于根据用户配置的地址集合，将服务安装相关数据发送到用于安装服务的服务器集群中的目标服务器；第一生成模块403，用于在目标服务器上生成安装目录，并基于地址集合，将安装目录分发到服务器集群中的每个服务器；安装模块404，用于控制服务器集群根据服务安装相关数据安装服务，并在服务器集群上启动服务。

在本实施例中，第一获取模块401可以获取用户配置的服务安装相关数据。其中，服务安装相关数据可以是为了使服务器实现某种功能所需要的各种数据。例如，为了在服务器上部署组件(例如MySQL、HDFS、HBase、MongoDB等大数据组件)，并且基于组件运行某些实例(即服务)，需要在服务器集群上安装组件，及对组件进行配置以执行服务。安装及配置服务所需的数据(例如组件安装包、配置文件、配置服务的服务器的地址等)即服务安装相关数据。

在本实施例中，发送模块402可以根据用户配置的地址集合，将服务安装相关数据发送到用于安装服务的服务器集群中的目标服务器。其中，地址集合可以是用户在上述装置400上选择的、组成服务器集群的每个服务器的地址(例如IP地址)的集合。目标服务器为用于在服务器集群中的各个服务器上部署服务所选定的服务器，例如，目标服务器可以是用户任意选择的服务器，也可以是由上述装置400随机选择的服务器。

在本实施例中，第一生成模块403可以通过远程控制目标服务器，在目标服务器上生成安装目录，并基于地址集合，将安装目录分发到服务器集群中的每个服务器。其中，安装目录为用于部署服务的各种数据的集合。例如，安装目录可以包括组件的源码包、修改之后的配置文件、用于控制服务启动停止的脚本等。

在本实施例中，安装模块404可以控制服务器集群根据服务安装相关数据安装服务，并在服务器集群上启动服务。

具体地，上述安装模块404可以上传服务安装脚本和服务启动服务脚本至各个服务器，并在各个服务器上运行服务安装脚本以安装服务，然后运行服务启动服务脚本以启动服务。

在本实施例的一些可选的实现方式中，上述装置400还可以包括：第一选择模块(图中未示出)，用于基于用户在可视化界面的操作，选择待部署的服务的服务安装包及相关脚本；第二选择模块(图中未示出)，用于选择待部署的服务对应的服务器集群对应的地址集合；第一确定模块(图中未示出)，用于确定待部署的服务的基本信息；第二生成模块(图中未示出)，用于基于服务安装包、相关脚本、地址集合和基本信息，生成服务安装相关数据。

在本实施例的一些可选的实现方式中，基本信息包括以下至少一种：服务版本、组件名称、服务名称、数据目录、日志目录。

在本实施例的一些可选的实现方式中，装置400还可以包括：第二确定模块(图中未示出)，用于确定服务安装相关数据对应的服务是否具有依赖服务；第二获取模块(图中未示出)，用于如果有，获取依赖服务的相关数据，并选择服务对应的服务器集群的地址集合。

在本实施例的一些可选的实现方式中，安装模块404可以包括：第一确定单元(图中未示出)，用于确定服务器集群中的服务器上是否存在服务安装目录；安装单元(图中未示出)，用于如果不存在，安装服务安装相关数据，并接收服务器发送的表征服务安装成功的信息。

在本实施例的一些可选的实现方式中，安装模块404可以包括：上传单元(图中未示出)，用于将用于启动服务的启动服务脚本上传到服务器集群；启动单元(图中未示出)，用于控制启动服务脚本在服务器集群中的服务器上启动；第二确定单元(图中未示出)，用于在服务器集群包括的服务器上确定服务的运行情况；第三确定单元(图中未示出)，用于基于运行情况，确定服务是否启动成功。

在本实施例的一些可选的实现方式中，在服务器集群中的服务器上运行的服务包括至少一个角色；以及第三确定单元可以包括：第一确定子单元(图中未示出)，用于对于至少一个角色中的每个角色，从服务器集群中确定运行该角色的服务器的数量，如果数量等于预先配置该角色的服务器的总数，确定该角色启动成功；第二确定子单元(图中未示出)，用于响应于确定各个角色均启动成功，确定服务启动成功。

在本实施例的一些可选的实现方式中，启动单元可以包括：第三确定子单元(图中未示出)，用于确定服务是否具有依赖服务；启动子单元(图中未示出)，用于如果有，控制依赖服务在服务器集群中的服务器上启动。

本申请的上述实施例提供的装置，通过根据用户配置的地址集合，将服务安装相关数据发送到用于安装服务的服务器集群中的目标服务器，在目标服务器上生成安装目录，并基于地址集合，将安装目录分发到服务器集群中的每个服务器，控制服务器集群根据服务安装相关数据安装服务，并在服务器集群上启动服务，从而实现了远程自动化地部署、操作服务，降低了服务运维操作的难度。

下面参考图5，其示出了适于用来实现本申请实施例的电子设备的计算机系统500的结构示意图。图5示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图5所示，计算机系统500包括中央处理单元(CPU)501，其可以根据存储在只读存储器(ROM)502中的程序或者从存储部分508加载到随机访问存储器(RAM)503中的程序而执行各种适当的动作和处理。在RAM 503中，还存储有系统500操作所需的各种程序和数据。CPU501、ROM 502以及RAM 503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。

以下部件连接至I/O接口505：包括键盘、鼠标等的输入部分506；包括诸如液晶显示器(LCD)等以及扬声器等的输出部分507；包括硬盘等的存储部分508；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分509。通信部分509经由诸如因特网的网络执行通信处理。驱动器510也根据需要连接至I/O接口505。可拆卸介质511，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器510上，以便于从其上读出的计算机程序根据需要被安装入存储部分508。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分509从网络上被下载和安装，和/或从可拆卸介质511被安装。在该计算机程序被中央处理单元(CPU)501执行时，执行本申请的方法中限定的上述功能。

需要说明的是，本申请所述的计算机可读存储介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读存储介质，该计算机可读存储介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读存储介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括第一获取模块、发送模块、第一生成模块、安装模块。其中，这些模块的名称在某种情况下并不构成对该单元本身的限定，例如，第一获取模块还可以被描述为“用于获取用户配置的服务安装相关数据的模块”。

作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被该电子设备执行时，使得该电子设备：获取用户配置的服务安装相关数据；根据用户配置的地址集合，将服务安装相关数据发送到用于安装服务的服务器集群中的目标服务器；在目标服务器上生成安装目录，并基于地址集合，将安装目录分发到服务器集群中的每个服务器；控制服务器集群根据服务安装相关数据安装服务，并在服务器集群上启动服务。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (5)

1.一种服务部署方法，其特征在于，所述方法包括：

获取用户配置的服务安装相关数据，包括：

基于所述用户在可视化界面的操作，选择待部署的服务的服务安装包及相关脚本；

选择所述待部署的服务对应的服务器集群对应的地址集合；

确定所述待部署的服务的基本信息；

基于所述服务安装包、所述相关脚本、所述地址集合和所述基本信息，生成所述服务安装相关数据；

确定所述服务安装相关数据对应的服务是否具有依赖服务；

如果有，获取所述依赖服务的相关数据，并选择所述服务对应的服务器集群的地址集合；

根据所述用户配置的地址集合，将所述服务安装相关数据发送到用于安装服务的服务器集群中的目标服务器；

在所述目标服务器上生成安装目录，并基于所述地址集合，将所述安装目录分发到所述服务器集群中的每个服务器；

控制所述服务器集群根据所述服务安装相关数据安装所述服务，并在所述服务器集群上启动所述服务；

其中，所述控制所述服务器集群根据所述服务安装相关数据安装所述服务，包括：

确定所述服务器集群中的服务器上是否存在服务安装目录；

如果不存在，安装所述服务安装相关数据，并接收所述服务器发送的表征服务安装成功的信息；

如果存在，则不安装；

所述在所述服务器集群上启动所述服务，包括：

在部署所述服务时，同时将用于启动所述服务的启动服务脚本上传到所述服务器集群；

控制所述启动服务脚本在所述服务器集群中的服务器上启动；

在所述服务器集群包括的服务器上确定所述服务的运行情况；

基于所述运行情况，确定所述服务是否启动成功；

其中，在所述服务器集群中的服务器上运行的服务包括至少一个角色，所述基于所述运行情况，确定所述服务是否启动成功，包括：

对于所述至少一个角色中的每个角色，从所述服务器集群中确定运行该角色的服务器的数量，如果所述数量等于预先配置该角色的服务器的总数，确定该角色启动成功；

响应于确定各个角色均启动成功，确定所述服务启动成功；

所述控制所述启动服务脚本在所述服务器集群中的服务器上启动，包括：

确定所述服务是否具有依赖服务；

如果有，控制所述依赖服务在所述服务器集群中的服务器上启动。

2.根据权利要求1所述的方法，其特征在于，所述基本信息包括以下至少一种：服务版本、组件名称、服务名称、数据目录、日志目录。

3.一种服务部署装置，其特征在于，所述装置包括：

第一获取模块，用于获取用户配置的服务安装相关数据，包括：基于所述用户在可视化界面的操作，选择待部署的服务的服务安装包及相关脚本；选择所述待部署的服务对应的服务器集群对应的地址集合；确定所述待部署的服务的基本信息；基于所述服务安装包、所述相关脚本、所述地址集合和所述基本信息，生成所述服务安装相关数据；

发送模块，用于确定所述服务安装相关数据对应的服务是否具有依赖服务；如果有，获取所述依赖服务的相关数据，并选择所述服务对应的服务器集群的地址集合，根据所述用户配置的地址集合，将所述服务安装相关数据发送到用于安装服务的服务器集群中的目标服务器；

第一生成模块，用于在所述目标服务器上生成安装目录，并基于所述地址集合，将所述安装目录分发到所述服务器集群中的每个服务器；

安装模块，用于控制所述服务器集群根据所述服务安装相关数据安装所述服务，并在所述服务器集群上启动所述服务，其中，所述控制所述服务器集群根据所述服务安装相关数据安装所述服务，包括：确定所述服务器集群中的服务器上是否存在服务安装目录；如果不存在，安装所述服务安装相关数据，并接收所述服务器发送的表征服务安装成功的信息；如果存在，则不安装；所述在所述服务器集群上启动所述服务，包括：在部署所述服务时，同时将用于启动所述服务的启动服务脚本上传到所述服务器集群；控制所述启动服务脚本在所述服务器集群中的服务器上启动；在所述服务器集群包括的服务器上确定所述服务的运行情况；基于所述运行情况，确定所述服务是否启动成功；其中，在所述服务器集群中的服务器上运行的服务包括至少一个角色，所述基于所述运行情况，确定所述服务是否启动成功，包括：对于所述至少一个角色中的每个角色，从所述服务器集群中确定运行该角色的服务器的数量，如果所述数量等于预先配置该角色的服务器的总数，确定该角色启动成功；响应于确定各个角色均启动成功，确定所述服务启动成功；所述控制所述启动服务脚本在所述服务器集群中的服务器上启动，包括：确定所述服务是否具有依赖服务；如果有，控制所述依赖服务在所述服务器集群中的服务器上启动。

4.一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-2中任一所述的方法。

5.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-2中任一所述的方法。

Images