一种分布式系统部署方法、系统、电子设备及存储介质

摘要

本申请公开了一种分布式系统部署方法，区别于现有使用编排文件加额外功能组件完成分布式系统部署的方法，本申请将额外安装或部署的功能组件进行抽象化处理，作为与原编排文件中的各编排命令同等地位的存在，并与其它编排命令就统一的依赖关系进行完整的命令排布，以防止因依赖关系不满足导致的不可用问题，同时也由于将额外功能组件的安装或部署过程整合进编排文件，使得目标分布式系统的部署仅基于单一的编排文件即可完成，集成度和自动化程度更高，真正实现了一键式部署，而更少的部署操作步骤，也提升了用户的使用体验。本申请还同时公开了一种分布式系统部署系统、电子设备及计算机可读存储介质，具有上述有益效果。

说明书

技术领域

本申请涉及分布式系统技术领域，特别涉及一种分布式系统部署方法、系统、电子设备及计算机可读存储介质。

背景技术

在部署一个分布式系统时，不仅涉及多个功能组件，且注意事项较多、步骤极其繁琐，尤其在一些框架的搭建过程中，涉及的各组件间还存在有依赖关系，一步出错，可能将需要重新部署，因此快速、准确、步骤简单的完成一个分布式系统的部署是十分具有研究价值的。

现有存在通过编排文件来实现分布式系统部署的方式，编排文件的作用相当于功能程序的配置文件或者部署指导，但现阶段编排文件内仅包含的要素较少，而一些在部署分布式系统过程中需要的重要功能，例如运行测试功能、监控报警功能以及数据库的初始化操作，却是通过独立于编排文件之外的功能组件来实现，编排文件存在的目的在于期望实现自动化的部署，而除编排文件中涉及的要素，额外功能组件往往还需要手动进行安装或部署，不仅与编排文件的目的相违背，且后续安装的功能组件还存在因依赖关系不满足导致出现的不可用现象。在分开进行的同时，还增加了完成部署需要操作的步骤和多个对象，无法真正实现一键式部署，用户使用体验有待改进。

因此，如何克服现有部署分布式系统方式中存在的各技术缺陷，提供一种要素构成更丰富、无需手动安装或部署功能组件、集成度和自动化更高的分布式系统部署机制，是本领域技术人员亟待解决的问题。

发明内容

本申请的目的是提供一种分布式系统部署方法，区别于现有使用编排文件加额外功能组件完成分布式系统部署的方法，本申请将额外安装或部署的功能组件进行抽象化处理，作为与原编排文件中的各编排命令同等地位的存在，并与其它编排命令就统一的依赖关系进行完整的命令排布，以防止因依赖关系不满足导致的不可用问题，同时也由于将额外功能组件的安装或部署过程整合进编排文件，使得目标分布式系统的部署仅基于单一的编排文件即可完成，集成度和自动化程度更高，真正实现了一键式部署，而更少的部署操作步骤，也提升了用户的使用体验。

本申请的另一目的在于提供了一种分布式系统部署系统、电子设备及计算机可读存储介质。

为实现上述目的，本申请提供一种分布式系统部署方法，该方法包括：

根据系统部署要求选取构成目标分布式系统的各要素；其中，所述要素包括应用、属性信息、配置信息、存储、数据接口、监控报警规则、冒烟测试规则、数据初始化规则中的至少一项；

将各所述要素按照统一的格式抽象为各编排命令，并按照各所述要素间的依赖关系排布对应的各编排命令，得到编排文件；

利用解析器依次解析所述编排文件中各编排命令，并按各所述编排命令将对应的容器化应用部署至目标节点，以完成所述目标分布式系统的部署。

可选的，在完成所述目标分布式系统的部署之前，还包括：

利用由所述数据初始化规则抽象得到的初始化编排命令对安装完成的数据库进行数据初始化操作。

可选的，在完成所述目标分布式系统的部署之后，还包括：

利用由所述监控报警规则抽象得到的监控报警编排命令对运行的目标分布式系统进行监控；

当所述目标分布式系统任意组成部分或功能部分存在异常时，通过预设路径反馈携带有异常信息的异常警报信息。

可选的，在按各所述编排命令将对应的容器化应用部署至目标节点之前，还包括：

利用容器化技术封装各目标应用，得到各所述容器化应用；

利用Kubernetes的service自动发现并区分不同的服务。

可选的，在完成所述目标分布式系统的部署之后，还包括：

利用由所述冒烟测试规则抽象得到的冒烟测试编排命令调用预先定义的冒烟测试用例进行冒烟测试，并反馈得到的测试结果。

可选的，该分布式系统部署方法还包括：

当需要迁移所述目标分布式系统时，将所述编排文件导出至目标设备；

在所述目标设备上根据所述编排文件完成所述目标分布式系统的迁移。

可选的，该分布式系统部署方法还包括：

接收所述目标分布式系统部署完成后返回的部署完成信号，并根据所述部署完成信号中包含的信息更新所述目标分布式系统的部署状态。

为实现上述目的，本申请还提供了一种分布式系统部署系统，包括：

构成要素确定单元，用于根据系统部署要求选取构成目标分布式系统的各要素；其中，所述要素包括应用、属性信息、配置信息、存储、数据接口、监控报警规则、冒烟测试规则、数据初始化规则中的至少一项；

要素抽象及按序编排单元，用于将各所述要素按照统一的格式抽象为各编排命令，并按照各所述要素间的依赖关系排布对应的各编排命令，得到编排文件；

分布式系统部署单元，用于利用解析器依次解析所述编排文件中各编排命令，并按各所述编排命令将对应的容器化应用部署至目标节点，以完成所述目标分布式系统的部署。

可选的，该分布式系统部署系统还包括：

数据初始化单元，用于在完成所述目标分布式系统的部署之前，利用由所述数据初始化规则抽象得到的初始化编排命令对安装完成的数据库进行数据初始化操作。

可选的，该分布式系统部署系统还包括：

监控单元，用于在完成所述目标分布式系统的部署之后，利用由所述监控报警规则抽象得到的监控报警编排命令对运行的目标分布式系统进行监控；

警报单元，用于当所述目标分布式系统任意组成部分或功能部分存在异常时，通过预设路径反馈携带有异常信息的异常警报信息。

可选的，该分布式系统部署系统还包括：

容器化封装单元，用于在按各所述编排命令将对应的容器化应用部署至目标节点之前，利用容器化技术封装各目标应用，得到各所述容器化应用；

服务自动发现单元，用于利用Kubernetes的service自动发现并区分不同的服务。

可选的，该分布式系统部署系统还包括：

冒烟测试单元，用于在完成所述目标分布式系统的部署之后，利用由所述冒烟测试规则抽象得到的冒烟测试编排命令调用预先定义的冒烟测试用例进行冒烟测试，并反馈得到的测试结果。

可选的，该分布式系统部署系统还包括：

迁移导出单元，用于当需要迁移所述目标分布式系统时，将所述编排文件导出至目标设备；

迁移还原单元，用于在所述目标设备上根据所述编排文件完成所述目标分布式系统的迁移。

可选的，该分布式系统部署系统还包括：

完成信号接收及处理单元，用于接收所述目标分布式系统部署完成后返回的部署完成信号，并根据所述部署完成信号中包含的信息更新所述目标分布式系统的部署状态。

为实现上述目的，本申请还提供了一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上述内容所描述的分布式系统部署方法的步骤。

为实现上述目的，本申请还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述内容所描述的分布式系统部署方法的步骤。

显然，本申请所提供的一种分布式系统部署方法，区别于现有使用编排文件加额外功能组件完成分布式系统部署的方法，本申请将额外安装或部署的功能组件进行抽象化处理，作为与原编排文件中的各编排命令同等地位的存在，并与其它编排命令就统一的依赖关系进行完整的命令排布，以防止因依赖关系不满足导致的不可用问题，同时也由于将额外功能组件的安装或部署过程整合进编排文件，使得目标分布式系统的部署仅基于单一的编排文件即可完成，集成度和自动化程度更高，真正实现了一键式部署，而更少的部署操作步骤，也提升了用户的使用体验。本申请同时还提供了一种分布式系统部署系统、电子设备及计算机可读存储介质，具有上述有益效果，在此不再赘述。

附图说明

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

图1为本申请实施例提供的一种分布式系统部署方法的流程图；

图2为在实施例一的基础上提供的一种全功能分布式系统的部署方法的流程图；

图3为本申请实施例提供的一种分布式系统部署系统的结构框图；

图4为本申请实施例提供的一种分布式系统要实现编排发布涉及的要素和编排的典型使用场景的逻辑结构示意图；

图5为本申请实施例提供的一个编写完成的编排文件。

具体实施方式

本申请的核心是提供一种分布式系统部署方法、系统、电子设备及计算机可读存储介质，区别于现有使用编排文件加额外功能组件完成分布式系统部署的方法，本申请将额外安装或部署的功能组件进行抽象化处理，作为与原编排文件中的各编排命令同等地位的存在，并与其它编排命令就统一的依赖关系进行完整的命令排布，以防止因依赖关系不满足导致的不可用问题，同时也由于将额外功能组件的安装或部署过程整合进编排文件，使得目标分布式系统的部署仅基于单一的编排文件即可完成，集成度和自动化程度更高，真正实现了一键式部署，而更少的部署操作步骤，也提升了用户的使用体验。

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

实施例一

以下结合图1，图1为本申请实施例提供的一种分布式系统部署方法的流程图，其具体包括以下步骤：

S101：根据系统部署要求选取构成目标分布式系统的各要素；

本步骤旨在根据系统部署要求选取构成目标分布式系统的各要素，其中，在构建每个目标分布式系统之初，还需要先构思好待部署的目标分布式系统的作用和目的，例如，需要构建一个能够存储海量数据、且具有较佳的拓展性和数据冗余度的分布式系统，那么就需要根据该系统部署要求来选取构成该分布式存储系统的各具体的要求。

其中，要素包括应用、属性信息、配置信息、存储、数据接口、监控报警规则、冒烟测试规则、数据初始化规则中的至少一项，需要说明的是，此处所描述的要素所处的层面较高，而具体以用于构建一个满足上述要求的分布式存储系统中的应用要素为例时，还需要针对性的选取用于实现数据分布式存储的应用，包括但不限于数据收集应用、数据分发应用、数据分片应用、特征值/摘要信息及匹配应用等等，并以此类推至其它要素，即首选需要确定需要哪些大类的要素，并在完成大类要素的确定后，完成每项大类要素下的具体内容。

S102：将各要素按照统一的格式抽象为各编排命令，并按照各要素间的依赖关系排布对应的各编排命令，得到编排文件；

在S101的基础上，本步骤旨在将确定好的各要素按照统一的格式抽象为各编排命令，并按照各要素间的依赖关系排布对应的各编排命令，得到编排文件。其中，由于各要素的种类不一，具体如何将其能够抽象为统一格式的编排命令，可能需要通过不同的抽象手段，需要说明的是，抽象为各编排命令的步骤实际上是将具体应用如何安装、部署使其能够起到其应具有的作用的配置参数抽取出来的过程，以使的在该编排命令的指导下能够将对应的应用以合适的方式安装在预定位置，并使用合适的配置使其具有相应的作用。

区别于现有技术中仅包含很少要素种类的编排文件，本申请还将原先不置入编排文件的数据初始化规则、监控报警规则以及冒烟参数规则，均与其它普通要素一样，作为本申请后续编写编排文件所需要素的一部分。当然，为了使这些原先作为额外功能组件的规则能够作为编排文件的一部分写入编排文件，还需要对这些额外功能组件进行抽象化处理，将这些额外功能组件的使用步骤和安装部署步骤抽象为各编排命令，以便与其它要素抽象得到的编排命令等同地位的依照整体的依赖关系完成命令排布，最终得到一个能够完成上述所有要素部署的编排文件，并在后续与相应的容器化应用和容器化平台下成功的将各要素对应的具体内容部署至各个节点中，完成目标分布式系统的部署。

现有技术中之所以将本申请着重提出的三种在实际构建和后续运行十分重要的规则独立于编排文件，作为额外的功能组件，其原先是因为在现有技术中将这些内容不作为部署一个分布式系统的基本组成部分，其更在意的一些底层的内容，像是更基础的操作系统、节点间连接、数据分发等，其更加认为这部分内容属于拓展内容，殊不知这部分作为客户在分布式系统后续运维过程中(以及一个分布式系统的全生命)接触最多的内容，其是否可随分布式系统部署过程中自动完成、是否还需要额外的等待时间、是否便于操作都是客户较关心的内容，因为分布式系统的使用群体更多的还是普通人，而非技术人员，因此看似不重要的内容其实更加应用客户的使用体验。另一原因是，在未出现采用编排文件来实现分布式系统的部署时，监控报警、冒烟测试和数据库数据初始化常作用为一个独立的系统组件被单独安装的目标系统中，这种安装和部署方法已被长期广泛的使用，因此成熟度较高，门槛较低，尤其是涉及一些组件的特殊依赖环境，如何实现统筹协调也是一个十分关键的问题。

而本申请通过将这些部分与基础要素均通过抽象步骤，得到编排命令，并在整体的依赖关系下完成各编排命令的排布，将原先分离的两部分合并成了一个部分，意味着在仅存的编排文件的指导下，可实现全面版分布式系统的自动部署，无需由特定的安装人员就额外组件的安装进行繁琐的人工操作，大大增加了集成度和自动化程度，在经过短时间的部署方式培训后，客户可在硬件因素准备完成后，自行完整分布式系统的部署，而无需专门的技术人员，真正实现了一键部署，客户使用体验更佳。

S103：利用解析器依次解析编排文件中各编排命令，并按各编排命令将对应的容器化应用部署至目标节点，以完成目标分布式系统的部署。

在S102的基础上，本步骤旨在利用解析器依次解析编排文件中各编排命令，并按各编排命令将对应的容器化应用部署至目标节点，以完成目标分布式系统的部署。需要说明的是，本步骤中提及的解析器，是一种专门用来将编排文件中书写的各编排命令解析为计算机可理解并进行执行的指令集的配套应用，其解析过程与编排文件中编排命令的编写过程属于相反的两个过程。另外，有了指导如何安装、部署分布式系统的编排文件，有了配套的解析器，还需要真正用于部署的各功能应用，具体的，这些应用通常经过容器化处理，表现为一个个容器化应用，以借助封装有依赖关系的容器化应用实现便捷的交付。在具备这些软件层面的内容后，只需要在合适的硬件设备上开始具体的部署操作，即可在编排文件的指导下按照一条条编排命令的顺序依次将相应的应用经合适的配置安装、部署在合适的硬件节点中，并最终在完成数据库数据初始化操作、监控报警功能部署、冒烟测试功能均执行完成后，完成全面版的目标分布式系统的部署工作，至此，该目标分布式系统应处于一个待交付和待使用的阶段。

进一步的，在因实际情景下各因素的制约下出现的分布式系统迁移要求时，还可以直接从原分布式系统中导出其编排文件，并在其它内容准备齐全的前提下，在新的硬件设备中直接依据导出的编排文件实现分布式系统的迁移，十分方便快捷。

更进一步的，还可以在目标分布式系统部署完成后，向上层返回一个通知反馈信号(例如部署完成信号)，以便能够根据该通知反馈信号及时确认目标分布式系统的部署进度和状态。

基于上述技术方案，本申请实施例提供的一种分布式系统部署方法，区别于现有使用编排文件加额外功能组件完成分布式系统部署的方法，本申请将额外安装或部署的功能组件进行抽象化处理，作为与原编排文件中的各编排命令同等地位的存在，并与其它编排命令就统一的依赖关系进行完整的命令排布，以防止因依赖关系不满足导致的不可用问题，同时也由于将额外功能组件的安装或部署过程整合进编排文件，使得目标分布式系统的部署仅基于单一的编排文件即可完成，集成度和自动化程度更高，真正实现了一键式部署，而更少的部署操作步骤，也提升了用户的使用体验。

实施例二

以下结合图2，图2为在实施例一的基础上提供的一种全功能分布式系统的部署方法的流程图，本实施例在实施例一的基础上，提供了一种在何阶段、如何具体完成原额外功能组件的部署方法，以期完成全功能版的分布式系统部署目的，具体实施步骤如下：

S201：利用容器化技术封装各目标应用，得到各容器化应用；

S202：利用Kubernetes的service自动发现并区分不同的服务；

现有技术一般使用IP+端口区分不同的服务，但由于不同环境上服务分配的IP很难保证一致，所以需要采用一些服务自动发现的机制，比如dubbo使用ZooKeeper，SpringCloud使用Eureka作为服务发现，本实施例使用Kubernetes的service作为服务发现机制，其本质上一种基于DNS的服务发现机制。

其中，dubbo是一种服务框架，ZooKeeper则是服务该dubbo的一种分布式应用程序协调服务；Spring Cloud是一系列框架的有序集合，它利用Spring Boot(一种全新框架，用来简化新Spring应用的初始搭建以及开发过程，该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置)的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署，Eureka本身是一个基于REST(一种设计风格)的服务，主要用于定位运行在AWS域(云计算)中的中间层服务，以达到负载均衡和中间层服务故障转移的目的。SpringCloud将它集成在其子项目spring-cloud-netflix中，以实现SpringCloud的服务发现功能。

此处对Eureka如何实现自动发现进行说明：

Eureka包含两个组件：Eureka Server和Eureka Client，其中，Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到；Eureka Client是一个java(一种程序语言)客户端，用于简化与Eureka Server的交互，客户端同时也就别一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，Eureka Client将会向Eureka Server发送心跳包，默认周期为30秒，如果EurekaServer在多个心跳周期内没有接收到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。Eureka Server之间通过复制的方式完成数据的同步，Eureka还提供了客户端缓存机制，即使所有的Eureka Server都挂掉，客户端依然可以利用缓存中的信息消费其他服务的API(Application Programming Interface，应用程序编程接口)。综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。

Kubernetes是一种自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展，本文中还将使用到的容器技术(Docker)通常被视为Kubernetes内部使用的低级别组件。Service是定义一系列Pod以及访问这些Pod的策略的一层抽象。Service通过Label(对应表)找到Pod组(包含一组容器和卷的节点被称为Pod)。因为Service是抽象的，所以在图表里通常看不到它们的存在，现在，假定有2个后台Pod，并且定义后台Service的名称为‘backend-service’，lable选择器为(tier＝backend,app＝myapp)。backend-service的Service会通过如下的方式实现自动发现：

为Service创建一个本地集群的DNS入口，因此前端Pod只需要DNS查找主机名为‘backend-service’，就能够解析出前端应用程序可用的IP地址。

S203：利用解析器依次解析编排文件中各编排命令；

S204：按各编排命令将对应的容器化应用部署至目标节点；

S205：利用由数据初始化规则抽象得到的初始化编排命令对安装完成的数据库进行数据初始化操作；

可以看出，S205对数据库的数据初始化操作被放在应用刚被部署至目标节点之后、基本应用部署完成之前，也就是说在数据库构建完成后，就紧接着对其进行数据初始化操作，已在初始化完成后就得以待工作状态。

S206：在数据库的数据初始化操作完成后，判定分布式系统基本应用部署完成；

S207：利用由监控报警规则抽象得到的监控报警编排命令对运行的目标分布式系统进行监控；

S208：当目标分布式系统任意组成部分或功能部分存在异常时，通过预设路径反馈携带有异常信息的异常警报信息；

S209：利用由冒烟测试规则抽象得到的冒烟测试编排命令调用预先定义的冒烟测试用例进行冒烟测试，并反馈得到的测试结果。

根据图2所示，S207、S208进行的监控报警功能部署和S209进行的冒烟测试，通常两者之间不存在明显的依赖关系，因此可同时并行进行执行，若在特殊环境下存在一些依赖关系，也可以进行适当的调整。

冒烟测试，这一术语源自硬件行业，对一个硬件或硬件组件进行更改或修复后，直接给设备加电，如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。

结合冒烟测试的作用，则不确定部署过程中各部分是否为对其它部分存在影响时，也可以穿插在各功能应用的部署过程中进行，但通常情况下在安装、部署过程中不会存在此问题，冒烟测试更多的在被用于试运行和更新内容更新测试。

实施例三

下面请参见图3，图3为本申请实施例提供的一种分布式系统部署系统的结构框图，该分布式系统部署系统可以包括：

构成要素确定单元100，用于根据系统部署要求选取构成目标分布式系统的各要素；其中，要素包括应用、属性信息、配置信息、存储、数据接口、监控报警规则、冒烟测试规则、数据初始化规则中的至少一项；

要素抽象及按序编排单元200，用于将各要素按照统一的格式抽象为各编排命令，并按照各要素间的依赖关系排布对应的各编排命令，得到编排文件；

分布式系统部署单元300，用于利用解析器依次解析编排文件中各编排命令，并按各编排命令将对应的容器化应用部署至目标节点，以完成目标分布式系统的部署。

其中，该分布式系统部署系统还可以包括：

数据初始化单元，用于在完成目标分布式系统的部署之前，利用由数据初始化规则抽象得到的初始化编排命令对安装完成的数据库进行数据初始化操作；

监控单元，用于在完成目标分布式系统的部署之后，利用由监控报警规则抽象得到的监控报警编排命令对运行的目标分布式系统进行监控；

警报单元，用于当目标分布式系统任意组成部分或功能部分存在异常时，通过预设路径反馈携带有异常信息的异常警报信息；

容器化封装单元，用于在按各编排命令将对应的容器化应用部署至目标节点之前，利用容器化技术封装各目标应用，得到各容器化应用；

服务自动发现单元，用于利用Kubernetes的service自动发现并区分不同的服务；

冒烟测试单元，用于在完成目标分布式系统的部署之后，利用由冒烟测试规则抽象得到的冒烟测试编排命令调用预先定义的冒烟测试用例进行冒烟测试，并反馈得到的测试结果。

进一步的，该分布式系统部署系统还可以包括：

迁移导出单元，用于当需要迁移目标分布式系统时，将编排文件导出至目标设备；

迁移还原单元，用于在目标设备上根据编排文件完成目标分布式系统的迁移；

完成信号接收及处理单元，用于接收目标分布式系统部署完成后返回的部署完成信号，并根据部署完成信号中包含的信息更新目标分布式系统的部署状态。

因为情况复杂，无法一一列举进行阐述，本领域技术人员应能意识到根据本申请提供的基本方法原理结合实际情况可以存在很多的例子，在不付出足够的创造性劳动下，应均在本申请的保护范围内。

实施例四

随着云计算和容器技术的发展，在互联网+应用的领域，采用微服务架构(微服务不需要像普通服务那样成为一种独立的功能或者独立的资源，服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台，使部署、管理和服务功能交付变得更加简单)来构建大规模分布式系统已经成为主流。相比于传统单体架构，微服务系统服务化后，系统规模和复杂度成倍增长，交付件和部署服务器数量可能达到成百上千的规模。同时，微服务系统一般采用敏捷开发的思想来构建持续交付流水线。

如何实现大规模分布式系统的部署和迁移将是一个很大的挑战：

1、一个完整持续交付流水线往往会有多套环境的需求。比如开发环境，测试环境，演示环境和生产环境，这么多环境的部署实施和验证会耗费大量的人力；

2、在产品生命周期内，不可避免的要面临机房搬迁、扩容等环境迁移的操作，如何平稳无误的实现有序迁移；

3、虽然微服务系统往往是无状态的，但不可避免会有彼此依赖，特别是对中间件的依赖，所以各交付件启动需要保顺；

4、微服务系统往往实施了自动化监控，应用的监控规则本身也是系统不可分割的一部分。

因此，需要一个描述整个分布式系统是如何构建的编排文件及实施方案，在编排文件里描述包含整个系统所有应用的配置信息，环境变量，版本信息，域名，资源配额等，并将分布式系统全生命周期中需要注意的内容纳入考虑范围，真正实现一键发布整个分布式系统以及快速迁移。

目前，微服务常常使用容器技术来发布，并通过Kubernetes、Mesos等容器编排工具来进行部署和运行管理，Kubernetes本身支持yaml/json格式的编排文件，用于构建分布式系统，但无法很好的解决应用配置、外部依赖(域名、数据、监控等)以及启动顺序的约束，另外也无法对应用监控报警规则、自动化测试进行编排，系统在编排创建的时候，往往需要重复配置监控和自动化测试，因此，为了真正实现一键发布和迁移整个分布式系统，还需要标识出所有与整个系统运行密切相关的依赖，同时采用一定的技术方案来实现编排描述及编排恢复。

本实施例提供的分布式系统的部署方法包括如下内容，请同时参见图4：

1、编排文件中要描述该分布式系统所有的运行依赖，包括应用版本、资源需求、配置、初始数据、监控报警规则、域名配置、存储依赖以及应用启动顺序；

2、应用采用容器化发布，交付件为Docker镜像，解决应用运行环境的一致性问题，同时可以约束应用标准化交付，这也是微服务最常用的发布机制；

3、数据能够自动初始化，一个系统往往有初始数据，在系统第一次运行时，需要自动初始化，本申请是将初始化操作也作为一个应用来编排；

4、应用和配置分离，同一个交付件不需要重新发布就可以跑在不同的环境下，在启动时加载不通的配置，同时保证了配置也可以通过编排文件描述，这可以通过配置中心来实现；

5、去除固定IP地址的配置方式，要求所有服务支持自动发现机制，比如Kubernetes的DNS机制；

6、存储卷的依赖，容器化后有些需要持久卷的支持，也必须在编排文件中进行描述；

7、域名配置，对于环境的迁移，需要支持域名解析的自动设置；

8、监控对应分布式系统是非常重要的，监控/报警规则也作为编排的内容；

9、应用启动顺序控制，虽然微服务讲究无状态，理论上与启动顺序无关，但现实的系统常常有依赖，需要控制启动顺序；

10、定义冒烟测试用例，在系统运行起来后自动进行冒烟测试。

因此，在分布式系统需要发布时，只需要维护该编排文件，同时将应用镜像发布到镜像仓库，部署新环境时通过该编排文件即可实现一键部署，实现了大规模分布式系统规范化发布和快速迁移，大大简化了部署和验证的工作，提高分布式系统的交付效率，同时促使了系统的标准化发布。

一种根据本实施例思想编写得到的编排文件示例可参见图5，受限于篇幅，图5中并未包含本实施例所描述的所有要素，但其基本思想一致。

基于上述实施例，本申请还提供了一种用于实现分布式系统部署的电子设备，该电子设备可以包括存储器和处理器，其中，该存储器中存有计算机程序，该处理器调用该存储器中的计算机程序时，可以实现上述实施例所提供的步骤。当然，该电子设备还可以包括各种必要的网络接口、电源以及其它零部件等。

本申请还提供了一种计算机可读存储介质，其上存有计算机程序，该计算机程序被执行终端或处理器执行时可以实现上述实施例所提供的步骤。该存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random AccessMemory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本文中应用了具体个例对本申请的原理及实施方式进行了阐述，且各个实施例间为递进关系，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，可参见对应的方法部分说明。以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。

还需要说明的是，在本说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。