1.本技术实施例涉及容器技术，特别涉及一种业务编排部署方法、系统、网络设备和存储介质。
背景技术：
：：2.docker是一个开源的应用容器引擎，目前，许多用户采用docker系统进行业务的手工部署。3.然而，采用docker系统手工部署业务，用户需要关心基础服务部署，网络打通，网络配置参数，服务注册与发现的流程等等，难度大复杂度高，使得用户无法专注于业务容器的改造和部署策略。技术实现要素：4.本技术实施例的主要目的在于提出一种业务编排部署方法、系统、网络设备和存储介质，大大降低了业务部署的难度与复杂度，使得用户可以专注于业务容器的改造和部署策略。5.为实现上述目的，本技术实施例提供了一种业务编排部署方法，包括：获取待部署服务器的基本环境信息；当所述待部署服务器的基本环境信息符合用户需求时，获取业务配置文件并解析，将用户业务进分层处理，其中，所述用户业务至少包括两个服务，所述服务至少包括一个微服务，所述微服务之间存在依赖关系；根据所述依赖关系，生成镜像依赖树和容器依赖树；根据所述依赖关系，对所述镜像依赖树和所述容器依赖树的每一层的所有节点进行镜像构建和容器部署；启动所有容器，完成所述用户业务的编排部署。6.为实现上述目的，本技术实施例还提出了一种业务编排部署系统，包括：7.配置文件处理模块，用于获取待部署服务器的基本环境信息；判断所述待部署服务器是否符合用户需求；获取业务配置文件并解析，将用户业务进分层处理，其中，所述用户业务至少包括两个服务，所述服务至少包括一个微服务，所述微服务之间存在依赖关系；8.依赖树生成模块，用于根据所述依赖关系，生成镜像依赖树和容器依赖树；9.镜像构建模块，用于根据所述依赖关系，对所述镜像依赖树每一层的所有节点进行镜像构建；10.容器部署模块，用于根据所述依赖关系，对所述容器依赖树的每一层的所有节点进行容器部署，启动所有容器，完成所述用户业务的编排部署。11.为实现上述目的，本技术实施例还提出了一种网络设备，所述设备包括：12.至少一个处理器；以及，13.与所述至少一个处理器通信连接的存储器；其中，14.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行以上所述的业务编排部署方法。15.本技术提出的业务编排部署方法、系统、网络设备和存储介质，通过获取用户的业务配置文件和系统配置文件，业务编排部署系统就可以自动将用户业务进行分层处理，划分为各个微服务，根据微服务之间的依赖关系，生成依赖树，进行镜像构建和服务容器部署，完成用户业务编排部署，使得用户不需要关心复杂的部署流程等过程，大大降低了业务部署的难度和复杂度。附图说明16.一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定。17.图1是本技术第一实施例提供的业务编排部署方法的流程图；18.图2是本技术第二实施例提供的业务编排部署方法的流程图；19.图3是本技术第三实施例提供的业务编排部署方法的流程图；20.图4是本技术第四实施例提供的业务编排部署方法的流程图；21.图5是本技术第五实施例提供的业务编排部署系统的结构示意图；22.图6是本技术第六实施例提供的业务编排部署系统的结构示意图；23.图7是本技术第七实施例提供的网络设备的结构示意图。具体实施方式24.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合附图对本技术的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本技术各实施例中，为了使读者更好地理解本技术而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本技术所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本技术的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。25.本技术的第一实施例涉及一种业务编排部署方法，如图1所示，具体包括：26.步骤101，获取待部署服务器的基本环境信息。27.具体地说，本发明实施例的业务编排方法基于docker系统，docker是一个开源的应用容器引擎。另外，本步骤中的基本环境信息可以包括：docker系统相关参数、防火墙模块信息、网络接口配置信息、磁盘空间信息和各种启动项等。当然，此处仅为具体的举例说明，实际使用时，基本环境信息可以根据用户需求或实际业务部署需求进行获取，此处不做一一赘述。另外，本技术对待部署的服务器数量不做限定，可以部署一个服务器，也可以部署多个服务器。28.步骤102，当所述待部署服务器的基本环境信息符合用户需求时，获取业务配置文件并解析，将用户业务进分层处理，其中，用户业务至少包括两个服务，服务至少包括一个微服务，微服务之间存在依赖关系。29.具体地说，业务配置文件可以根据用户业务部署需求进行自定义配置，业务配置文件中可以包括：各服务之间的依赖关系、各容器的大小、各容器的目标路径和各服务的日志存放路径、各容器的ip地址等等，当然，此处仅为具体的举例说明，实际应用时业务配置文件还可以包含其他业务配置信息。另外，通过业务配置文件灵活配置容器网络，可以形成单容器使用多网卡组成多业务平面使用不同类型的网络基础设施的高级使用形式。有效满足了多种不同类型业务的部署需求。30.进一步地，通过业务配置文件用户可以自定义业务容器所需的volume(一种逻辑存储单元)大小和目标路径，以此实现自动在虚拟磁盘上进行源路径的分配、管理和映射，同时保证数据的高可用。31.另外，将用户业务进行分层处理，可以是将用户业务划分成网络基础服务、中间件服务、框架类服务和业务服务四个层，当然，对于每一层服务还可以根据实际业务开展需要划分为许多更细的微服务。关于具体的业务划分方法或规则，此处不做限定，可以根据业务功能、业务类型进行划分，也可以用户自定义划分方法。32.步骤103，根据依赖关系，生成镜像依赖树和容器依赖树。33.具体地说，服务之间的依赖关系，高层的服务基本都会对低层服务发生依赖，且多个高层服务可能同时依赖多个低层服务组件。这种依赖关系可以理解为，一种服务的完成必须在其他一个或多个服务完成的基础上才能进行。34.步骤104，根据依赖关系，对镜像依赖树和容器依赖树的每一层的所有节点进行镜像构建和容器部署。35.具体地说，对依赖树的每一层使用并发的方式进行镜像构建、容器构建、业务初始化启动、等待业务状态正常等部署和检查工作，本层次工作完成，开始下一层的部署安装配置，每个层次的流程相同，直到所有层的容器全部部署完成。另外，本技术所有容器的网络互通和ip地址的分配完全由业务配置文件指定和编排系统自动分配相结合的方式来完成。36.步骤105，启动所有容器，完成用户业务的编排部署。37.在本实施方式中，所有容器之间进行网络通信或者容器与服务器主机进行网络通信可以通过设立专属bridge(一种linux内置的软件桥接方式)和使用docker主机网络2种方式结合，利用linux系统的ipv4ip_forward(ip三层转发)功能、netfilter和iptables(linux内置的防火墙模块和控制系统)进行nat(网络地址转换)满足单纯的容器层网络通信和容器与服务器主机网络通信的需求，使得用户无需关注底层复杂的基础服务部署、网络打通、服务注册与发现的流程等，专注于业务容器本身的改造和部署策略。38.本实施例相对于现有技术而言，通过获取用户的业务配置文件，将用户业务进行分层处理，划分为各个微服务，根据微服务之间的依赖关系，生成依赖树，进行镜像构建和服务容器部署，使得用户不需要关心复杂的基础服务部署，网络参数配置等过程，大大降低了业务部署的难度和复杂度。39.本技术的第二实施例涉及一种业务编排部署方法，本实施例与第一实施例大致相同，区别在于，如图3所示，步骤102之前，还包括：40.步骤201，判断待部署服务器的基本环境信息是否符合用户需求。41.步骤202，若待部署服务器的基本环境信息不符合用户需求，则对待部署服务器进行基本环境的检查，并根据系统配置文件进行系统安装和配置。42.具体地说，步骤201中的系统配置文件为用户预先编辑好的系统配置文件，若待部署的服务器为一个，则用户预先编辑好单机系统配置文件，若待部署的服务器为两个，则用户预先好双机系统配置文件。43.另外，若待部署服务器的基本环境不满足用户需求，则需要根据系统配置文件对系统进行安装和配置，比如：对docker系统参数、linux系统中的防火墙模块、网络接口配置、启动项等根据用户需求进行修改重新配置。44.本实施例相对于现有技术而言，在实现第一实施例有益效果的基础上，还可以在待部署服务器的基本环境信息不符合用户需求时，根据用户自定义的系统配置文件，对服务器进行系统安装和相关参数配置，提供了一种可自定义策略的业务部署方法，大大满足了用户个性化部署需求。45.本技术的第三实施例涉及一种业务编排部署方法，本实施例与第一实施例大致相同，区别在于，如图3所示，步骤103包括：46.步骤301，遍历业务配置文件中依赖项的内容，其中，依赖项内容为微服务之间的依赖关系。47.具体地说，业务配置文件中依赖项的内容为本服务所依赖服务的服务名称。比如：a服务依赖于b服务，那么对于业务配置文件中a服务的依赖项，其内容为b，即所依赖服务的服务名称。当然，此处仅为具体的举例说明，实际使用过程中，业务配置文件中依赖项的表示方法还可以使用其他表示。此处不做赘述。48.步骤302，通过递归回溯算法生成镜像依赖树和容器依赖树。49.具体地说，生成的镜像依赖树需要满足，不被任何其他镜像依赖的组件作为根节点；而容器依赖树需要满足，不被任何其他容器依赖的组件作为根节点。另外，在进行容器部署时，由这些根节点决定部署线程的数量，以后续遍历的方式将每颗树从叶子节点开始往父节点反向部署。50.在本实施方式中，若生成镜像依赖树和容器依赖树失败，则表示业务编排部署失败，需要清理系统和配置信息，生成失败日志。51.本实施例相对于现有技术而言，在实现第一实施例有益效果的基础上，基于业务分层处理后，每个服务层内部进行相关性较小的依赖计算，大大降低了依赖树生成计算的复杂性，提高了业务部署效率。52.为了使本领域技术人员能够更清楚地理解以上本发明第一至第三实施例公开的业务编排部署方法整体流程，本发明第四实施例以业务编排部署方法应用在双服务器情况下，为例进行说明。53.如图4所示，本发明的第四实施例提供的业务编排部署方法，包括：54.步骤401，获取待部署的两个服务器的基本环境信息。55.步骤402，根据主服务器基本环境信息，判断待部署的主服务器是否符合用户需求。56.具体地，若主服务器不符合用户需求，则执行步骤403，若主服务器符合用户需求，执行步骤404。57.步骤403，对主服务器进行基本环境的检查，并根据主服务器系统配置文件进行系统安装和配置。58.其中，若系统安装和配置失败，则执行步骤411。59.步骤404，根据备服务器基本环境信息，判断待部署的备服务器是否符合用户需求。60.具体地，若备服务器不符合用户需求，则执行步骤405，若备服务器符合用户需求，则执行步骤406。61.步骤405，对备服务器进行基本环境的检查，并根据备服务器系统配置文件进行系统安装和配置。62.其中，若系统安装和配置失败，则执行步骤411。63.步骤406，对主服务器和备服务器进行双机组件安装和配置。64.具体地，双机组件安装和配置可以包括：磁盘配置、心跳网络、同步网络等等，此处仅为具体的举例说明，当然还可以根据用户需要安装其他组件和配置。65.步骤407，获取业务配置文件并解析，将用户业务进分层处理，其中，用户业务至少包括两个服务，服务至少包括一个微服务，微服务之间存在依赖关系。66.步骤408，根据依赖关系，生成镜像依赖树和容器依赖树。67.其中，若生成镜像依赖树和容器依赖树失败，则执行步骤412。68.步骤409，根据依赖关系，对镜像依赖树和容器依赖树的每一层的所有节点进行镜像构建和容器部署。69.其中，若镜像构建和容器部署失败，则执行步骤412。70.步骤410，启动所有容器，完成用户业务的编排部署。71.步骤411，清理系统和配置信息，生成失败日志。72.步骤412，清理两个服务器中的配置信息、镜像和容器，生成失败日志。73.在本实施方式中，对于双服务器进行业务部署，双机系统可以使用磁盘实时复制技术，对linux系统上的磁盘块设备进行实时复制，确保当前主机上被同步的磁盘任意数据改动均被复制到备机的对应磁盘。在实际的块设备上设置虚拟磁盘，上层业务使用磁盘时无需关心底层实际使用的磁盘设备，对业务和磁盘设备进行解耦，以起到更大的硬件兼容性，同时降低上层编码的侵入性。74.本实施例相对于现有技术而言，通过获取用户的业务配置文件，将用户业务进行分层处理，划分为各个微服务，根据微服务之间的依赖关系，生成依赖树，进行镜像构建和服务容器部署，使得用户不需要关心复杂的基础服务部署，网络参数配置等过程，大大降低了业务部署的难度和复杂度。75.此外，应当理解的是，上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。76.本发明第五实施例涉及一种业务编排部署系统，如图5所示，包括：77.配置文件处理模块501，用于获取待部署服务器的基本环境信息；判断所述待部署服务器是否符合用户需求；获取业务配置文件并解析，将用户业务进分层处理，其中，所述用户业务至少包括两个服务；78.依赖树生成模块502，用于根据所述服务之间的依赖关系，生成镜像依赖树和容器依赖树；79.镜像构建模块503，用于根据所述依赖关系，对所述镜像依赖树每一层进行镜像构建；80.容器部署模块504，用于根据所述依赖关系，对所述容器依赖树的每一层进行服务容器部署，启动所有服务容器。memory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。95.本领域的普通技术人员可以理解，上述各实施例是实现本技术的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本技术的精神和范围。当前第1页12当前第1页12
背景技术：
：：2.docker是一个开源的应用容器引擎，目前，许多用户采用docker系统进行业务的手工部署。3.然而，采用docker系统手工部署业务，用户需要关心基础服务部署，网络打通，网络配置参数，服务注册与发现的流程等等，难度大复杂度高，使得用户无法专注于业务容器的改造和部署策略。技术实现要素：4.本技术实施例的主要目的在于提出一种业务编排部署方法、系统、网络设备和存储介质，大大降低了业务部署的难度与复杂度，使得用户可以专注于业务容器的改造和部署策略。5.为实现上述目的，本技术实施例提供了一种业务编排部署方法，包括：获取待部署服务器的基本环境信息；当所述待部署服务器的基本环境信息符合用户需求时，获取业务配置文件并解析，将用户业务进分层处理，其中，所述用户业务至少包括两个服务，所述服务至少包括一个微服务，所述微服务之间存在依赖关系；根据所述依赖关系，生成镜像依赖树和容器依赖树；根据所述依赖关系，对所述镜像依赖树和所述容器依赖树的每一层的所有节点进行镜像构建和容器部署；启动所有容器，完成所述用户业务的编排部署。6.为实现上述目的，本技术实施例还提出了一种业务编排部署系统，包括：7.配置文件处理模块，用于获取待部署服务器的基本环境信息；判断所述待部署服务器是否符合用户需求；获取业务配置文件并解析，将用户业务进分层处理，其中，所述用户业务至少包括两个服务，所述服务至少包括一个微服务，所述微服务之间存在依赖关系；8.依赖树生成模块，用于根据所述依赖关系，生成镜像依赖树和容器依赖树；9.镜像构建模块，用于根据所述依赖关系，对所述镜像依赖树每一层的所有节点进行镜像构建；10.容器部署模块，用于根据所述依赖关系，对所述容器依赖树的每一层的所有节点进行容器部署，启动所有容器，完成所述用户业务的编排部署。11.为实现上述目的，本技术实施例还提出了一种网络设备，所述设备包括：12.至少一个处理器；以及，13.与所述至少一个处理器通信连接的存储器；其中，14.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行以上所述的业务编排部署方法。15.本技术提出的业务编排部署方法、系统、网络设备和存储介质，通过获取用户的业务配置文件和系统配置文件，业务编排部署系统就可以自动将用户业务进行分层处理，划分为各个微服务，根据微服务之间的依赖关系，生成依赖树，进行镜像构建和服务容器部署，完成用户业务编排部署，使得用户不需要关心复杂的部署流程等过程，大大降低了业务部署的难度和复杂度。附图说明16.一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定。17.图1是本技术第一实施例提供的业务编排部署方法的流程图；18.图2是本技术第二实施例提供的业务编排部署方法的流程图；19.图3是本技术第三实施例提供的业务编排部署方法的流程图；20.图4是本技术第四实施例提供的业务编排部署方法的流程图；21.图5是本技术第五实施例提供的业务编排部署系统的结构示意图；22.图6是本技术第六实施例提供的业务编排部署系统的结构示意图；23.图7是本技术第七实施例提供的网络设备的结构示意图。具体实施方式24.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合附图对本技术的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本技术各实施例中，为了使读者更好地理解本技术而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本技术所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本技术的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。25.本技术的第一实施例涉及一种业务编排部署方法，如图1所示，具体包括：26.步骤101，获取待部署服务器的基本环境信息。27.具体地说，本发明实施例的业务编排方法基于docker系统，docker是一个开源的应用容器引擎。另外，本步骤中的基本环境信息可以包括：docker系统相关参数、防火墙模块信息、网络接口配置信息、磁盘空间信息和各种启动项等。当然，此处仅为具体的举例说明，实际使用时，基本环境信息可以根据用户需求或实际业务部署需求进行获取，此处不做一一赘述。另外，本技术对待部署的服务器数量不做限定，可以部署一个服务器，也可以部署多个服务器。28.步骤102，当所述待部署服务器的基本环境信息符合用户需求时，获取业务配置文件并解析，将用户业务进分层处理，其中，用户业务至少包括两个服务，服务至少包括一个微服务，微服务之间存在依赖关系。29.具体地说，业务配置文件可以根据用户业务部署需求进行自定义配置，业务配置文件中可以包括：各服务之间的依赖关系、各容器的大小、各容器的目标路径和各服务的日志存放路径、各容器的ip地址等等，当然，此处仅为具体的举例说明，实际应用时业务配置文件还可以包含其他业务配置信息。另外，通过业务配置文件灵活配置容器网络，可以形成单容器使用多网卡组成多业务平面使用不同类型的网络基础设施的高级使用形式。有效满足了多种不同类型业务的部署需求。30.进一步地，通过业务配置文件用户可以自定义业务容器所需的volume(一种逻辑存储单元)大小和目标路径，以此实现自动在虚拟磁盘上进行源路径的分配、管理和映射，同时保证数据的高可用。31.另外，将用户业务进行分层处理，可以是将用户业务划分成网络基础服务、中间件服务、框架类服务和业务服务四个层，当然，对于每一层服务还可以根据实际业务开展需要划分为许多更细的微服务。关于具体的业务划分方法或规则，此处不做限定，可以根据业务功能、业务类型进行划分，也可以用户自定义划分方法。32.步骤103，根据依赖关系，生成镜像依赖树和容器依赖树。33.具体地说，服务之间的依赖关系，高层的服务基本都会对低层服务发生依赖，且多个高层服务可能同时依赖多个低层服务组件。这种依赖关系可以理解为，一种服务的完成必须在其他一个或多个服务完成的基础上才能进行。34.步骤104，根据依赖关系，对镜像依赖树和容器依赖树的每一层的所有节点进行镜像构建和容器部署。35.具体地说，对依赖树的每一层使用并发的方式进行镜像构建、容器构建、业务初始化启动、等待业务状态正常等部署和检查工作，本层次工作完成，开始下一层的部署安装配置，每个层次的流程相同，直到所有层的容器全部部署完成。另外，本技术所有容器的网络互通和ip地址的分配完全由业务配置文件指定和编排系统自动分配相结合的方式来完成。36.步骤105，启动所有容器，完成用户业务的编排部署。37.在本实施方式中，所有容器之间进行网络通信或者容器与服务器主机进行网络通信可以通过设立专属bridge(一种linux内置的软件桥接方式)和使用docker主机网络2种方式结合，利用linux系统的ipv4ip_forward(ip三层转发)功能、netfilter和iptables(linux内置的防火墙模块和控制系统)进行nat(网络地址转换)满足单纯的容器层网络通信和容器与服务器主机网络通信的需求，使得用户无需关注底层复杂的基础服务部署、网络打通、服务注册与发现的流程等，专注于业务容器本身的改造和部署策略。38.本实施例相对于现有技术而言，通过获取用户的业务配置文件，将用户业务进行分层处理，划分为各个微服务，根据微服务之间的依赖关系，生成依赖树，进行镜像构建和服务容器部署，使得用户不需要关心复杂的基础服务部署，网络参数配置等过程，大大降低了业务部署的难度和复杂度。39.本技术的第二实施例涉及一种业务编排部署方法，本实施例与第一实施例大致相同，区别在于，如图3所示，步骤102之前，还包括：40.步骤201，判断待部署服务器的基本环境信息是否符合用户需求。41.步骤202，若待部署服务器的基本环境信息不符合用户需求，则对待部署服务器进行基本环境的检查，并根据系统配置文件进行系统安装和配置。42.具体地说，步骤201中的系统配置文件为用户预先编辑好的系统配置文件，若待部署的服务器为一个，则用户预先编辑好单机系统配置文件，若待部署的服务器为两个，则用户预先好双机系统配置文件。43.另外，若待部署服务器的基本环境不满足用户需求，则需要根据系统配置文件对系统进行安装和配置，比如：对docker系统参数、linux系统中的防火墙模块、网络接口配置、启动项等根据用户需求进行修改重新配置。44.本实施例相对于现有技术而言，在实现第一实施例有益效果的基础上，还可以在待部署服务器的基本环境信息不符合用户需求时，根据用户自定义的系统配置文件，对服务器进行系统安装和相关参数配置，提供了一种可自定义策略的业务部署方法，大大满足了用户个性化部署需求。45.本技术的第三实施例涉及一种业务编排部署方法，本实施例与第一实施例大致相同，区别在于，如图3所示，步骤103包括：46.步骤301，遍历业务配置文件中依赖项的内容，其中，依赖项内容为微服务之间的依赖关系。47.具体地说，业务配置文件中依赖项的内容为本服务所依赖服务的服务名称。比如：a服务依赖于b服务，那么对于业务配置文件中a服务的依赖项，其内容为b，即所依赖服务的服务名称。当然，此处仅为具体的举例说明，实际使用过程中，业务配置文件中依赖项的表示方法还可以使用其他表示。此处不做赘述。48.步骤302，通过递归回溯算法生成镜像依赖树和容器依赖树。49.具体地说，生成的镜像依赖树需要满足，不被任何其他镜像依赖的组件作为根节点；而容器依赖树需要满足，不被任何其他容器依赖的组件作为根节点。另外，在进行容器部署时，由这些根节点决定部署线程的数量，以后续遍历的方式将每颗树从叶子节点开始往父节点反向部署。50.在本实施方式中，若生成镜像依赖树和容器依赖树失败，则表示业务编排部署失败，需要清理系统和配置信息，生成失败日志。51.本实施例相对于现有技术而言，在实现第一实施例有益效果的基础上，基于业务分层处理后，每个服务层内部进行相关性较小的依赖计算，大大降低了依赖树生成计算的复杂性，提高了业务部署效率。52.为了使本领域技术人员能够更清楚地理解以上本发明第一至第三实施例公开的业务编排部署方法整体流程，本发明第四实施例以业务编排部署方法应用在双服务器情况下，为例进行说明。53.如图4所示，本发明的第四实施例提供的业务编排部署方法，包括：54.步骤401，获取待部署的两个服务器的基本环境信息。55.步骤402，根据主服务器基本环境信息，判断待部署的主服务器是否符合用户需求。56.具体地，若主服务器不符合用户需求，则执行步骤403，若主服务器符合用户需求，执行步骤404。57.步骤403，对主服务器进行基本环境的检查，并根据主服务器系统配置文件进行系统安装和配置。58.其中，若系统安装和配置失败，则执行步骤411。59.步骤404，根据备服务器基本环境信息，判断待部署的备服务器是否符合用户需求。60.具体地，若备服务器不符合用户需求，则执行步骤405，若备服务器符合用户需求，则执行步骤406。61.步骤405，对备服务器进行基本环境的检查，并根据备服务器系统配置文件进行系统安装和配置。62.其中，若系统安装和配置失败，则执行步骤411。63.步骤406，对主服务器和备服务器进行双机组件安装和配置。64.具体地，双机组件安装和配置可以包括：磁盘配置、心跳网络、同步网络等等，此处仅为具体的举例说明，当然还可以根据用户需要安装其他组件和配置。65.步骤407，获取业务配置文件并解析，将用户业务进分层处理，其中，用户业务至少包括两个服务，服务至少包括一个微服务，微服务之间存在依赖关系。66.步骤408，根据依赖关系，生成镜像依赖树和容器依赖树。67.其中，若生成镜像依赖树和容器依赖树失败，则执行步骤412。68.步骤409，根据依赖关系，对镜像依赖树和容器依赖树的每一层的所有节点进行镜像构建和容器部署。69.其中，若镜像构建和容器部署失败，则执行步骤412。70.步骤410，启动所有容器，完成用户业务的编排部署。71.步骤411，清理系统和配置信息，生成失败日志。72.步骤412，清理两个服务器中的配置信息、镜像和容器，生成失败日志。73.在本实施方式中，对于双服务器进行业务部署，双机系统可以使用磁盘实时复制技术，对linux系统上的磁盘块设备进行实时复制，确保当前主机上被同步的磁盘任意数据改动均被复制到备机的对应磁盘。在实际的块设备上设置虚拟磁盘，上层业务使用磁盘时无需关心底层实际使用的磁盘设备，对业务和磁盘设备进行解耦，以起到更大的硬件兼容性，同时降低上层编码的侵入性。74.本实施例相对于现有技术而言，通过获取用户的业务配置文件，将用户业务进行分层处理，划分为各个微服务，根据微服务之间的依赖关系，生成依赖树，进行镜像构建和服务容器部署，使得用户不需要关心复杂的基础服务部署，网络参数配置等过程，大大降低了业务部署的难度和复杂度。75.此外，应当理解的是，上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。76.本发明第五实施例涉及一种业务编排部署系统，如图5所示，包括：77.配置文件处理模块501，用于获取待部署服务器的基本环境信息；判断所述待部署服务器是否符合用户需求；获取业务配置文件并解析，将用户业务进分层处理，其中，所述用户业务至少包括两个服务；78.依赖树生成模块502，用于根据所述服务之间的依赖关系，生成镜像依赖树和容器依赖树；79.镜像构建模块503，用于根据所述依赖关系，对所述镜像依赖树每一层进行镜像构建；80.容器部署模块504，用于根据所述依赖关系，对所述容器依赖树的每一层进行服务容器部署，启动所有服务容器。memory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。95.本领域的普通技术人员可以理解，上述各实施例是实现本技术的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本技术的精神和范围。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。