基于微服务的镜像生成方法、装置、电子设备及存储介质

技术领域

本公开涉及人工智能领域中的云计算领域和云应用引擎领域，尤其涉及一种基于微服务的镜像生成方法、装置、电子设备及存储介质。

背景技术

在云原生时代，微服务部署的方式由传统的服务编译产出包部署变更为镜像部署。镜像是一种特殊的文件系统，包含容器运行时所需要的程序、库、资源和配置等文件。要制造部署所需要的镜像，需要编写一定的镜像文件代码。代码的编写对用户的专业要求较高，浪费大量的人力和时间，影响镜像生成的精度和效率。

发明内容

本公开提供了一种基于微服务的镜像生成方法、装置、电子设备及存储介质。

根据本公开的第一方面，提供了一种基于微服务的镜像生成方法，包括：

响应于生成指令，获取所述生成指令所指示的微服务的程序包；其中，所述生成指令用于指示生成微服务的镜像；所述程序包中包括至少一个程序文件，所述程序文件用于表示运行微服务所需的数据；

根据所述微服务的程序包中的程序文件，确定所述微服务的服务类型；其中，所述服务类型用于表示微服务的运行环境；

根据预设的与所述微服务的服务类型对应的镜像分层规则，生成所述微服务的镜像，并将所述微服务的镜像推送到预设的镜像仓库中进行存储。

根据本公开的第二方面，提供了一种基于微服务的镜像生成装置，包括：

获取单元，用于响应于生成指令，获取所述生成指令所指示的微服务的程序包；其中，所述生成指令用于指示生成微服务的镜像；所述程序包中包括至少一个程序文件，所述程序文件用于表示运行微服务所需的数据；

类型确定单元，用于根据所述微服务的程序包中的程序文件，确定所述微服务的服务类型；其中，所述服务类型用于表示微服务的运行环境；

生成单元，用于根据预设的与所述微服务的服务类型对应的镜像分层规则，生成所述微服务的镜像，并将所述微服务的镜像推送到预设的镜像仓库中进行存储。

根据本公开的第三方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本公开第一方面所述的方法。

根据本公开的第四方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行本公开第一方面所述的方法。

根据本公开的第五方面，提供了一种计算机程序产品，所述计算机程序产品包括计算机程序，该计算机程序被处理器执行时实现本公开第一方面所述的方法。

根据本公开的技术，提高了微服务镜像的生成效率和精度。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是根据本公开实施例提供的一种基于微服务的镜像生成方法的流程示意图；

图2是根据本公开实施例提供的一种基于微服务的镜像生成方法的流程示意图；

图3是根据本公开实施例提供的一种基于微服务的镜像生成方法的流程示意图；

图4是根据本公开实施例提供的镜像层结构示意图；

图5是根据本公开实施例提供的一种基于微服务的镜像生成装置的结构框图；

图6是根据本公开实施例提供的一种基于微服务的镜像生成装置的结构框图；

图7是用来实现本公开实施例的基于微服务的镜像生成方法的电子设备的结构框图；

图8是用来实现本公开实施例的基于微服务的镜像生成方法的电子设备的结构框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

在云原生时代，微服务部署的方式由传统的服务编译产出包部署变更为Docker(应用容器引擎)镜像部署。而Docker镜像是一种特殊的文件系统，包括容器运行时所需要的程序、库、资源和配置等文件，还包括为运行时准备的一些配置参数，如匿名卷、环境变量和用户标识等。

微服务要上云就必须依赖Docker镜像，但是要制造部署所需要的Docker镜像，需要根据专业知识编写一定的代码，专业要求较高，且对于不同的微服务开发者，在制造镜像时，代码格式不统一。

云原生厂商的镜像构建一般是基于Docker构建，生成镜像时，先在项目工程增加Docker file(文件)，用户编写Docker定义的源语，描述镜像生成的流程。通过本地或服务器端读取Docker file的源语，通过Docker服务器解读运行，实现镜像的构建。使用过程中，若遇到问题还需要耗费时间和精力排查处理，浪费大量的人力和时间。

本公开提供一种基于微服务的镜像生成方法、装置、电子设备及存储介质，应用于人工智能领域中的云计算领域，尤其涉及云计算的云应用引擎领域，以提高镜像生成的效率和精度。

需要说明的是，本实施例中的数据并不是针对某一特定用户，并不能反映出某一特定用户的个人信息，且本实施例中的数据来自于公开数据集。

本公开的技术方案中，所涉及的信息或数据的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

为使读者更深刻地理解本公开的实现原理，现结合以下图1-图8所示的实施例进行进一步细化。

图1为根据本公开实施例提供的一种基于微服务的镜像生成方法的流程示意图，该方法可以由一种基于微服务的镜像生成装置执行。如图1所示，该方法包括以下步骤：

S101、响应于生成指令，获取生成指令所指示的微服务的程序包；其中，生成指令用于指示生成微服务的镜像；程序包中包括至少一个程序文件，程序文件用于表示运行微服务所需的数据。

示例性地，微服务使用平台可以获取待部署的微服务的程序包，并生成微服务的镜像，将微服务的镜像存储在平台的镜像仓库中。微服务使用平台可以是云应用平台，微服务使用平台中可以编写一个Java Server(服务)，用于生成镜像，镜像生成的环节可以使用Java线程池。不同微服务的开发者可以将所开发的微服务的程序包上传至微服务使用平台，便于进行镜像的生成。

微服务开发者可以向微服务使用平台发出微服务镜像的生成指令，指示微服务使用平台生成微服务的镜像。响应到生成指令，获取生成指令对应的微服务的程序包。可以从生成指令中获取微服务的程序包，例如，在发出生成指令时，将微服务的程序包一起发送给平台。也可以将微服务的程序包预先存储在预设的位置，并在发出生成指令时，将程序包所在的位置发给平台，在响应到生成指令后，平台从预设位置处获取程序包。或者将微服务的程序包预先存储在平台中，在响应到生成指令后，根据生成指令中的微服务的唯一标识，查找与该标识对应的程序包，作为生成指令所指示的微服务的程序包。

可以定时获取微服务的程序包，例如，可以预设生成指令的发出周期，通过定时响应生成指令，得到各个微服务的程序包。例如，每次响应到生成指令时，都从程序包的预设存储位置处查找是否存在还未部署的微服务的程序包，若不存在，则不获取程序包；若存在，则获取还未部署的微服务的程序包。也可以针对某一微服务，定时发出生成指令，即，定时获取该微服务的程序包。平台可以不接收外部的生成指令，自身定时启动程序包的获取。

程序包可以是由微服务的开发者预先编写完成的，程序包中的数据可以是微服务在运行时所需要的库、资源和配置参数等数据。程序包中可以包括一个或多个程序文件，即，程序文件可以用于表示微服务运行时所需的库、资源和配置参数等数据。本实施例中，可以获取压缩包格式的程序包。

S102、根据微服务的程序包中的程序文件，确定微服务的服务类型；其中，服务类型用于表示微服务的运行环境。

示例性地，从微服务的程序包中获取到一个或多个程序文件，程序文件中可以包括与微服务相关的数据，例如，可以包括微服务的标识、配置参数、运行环境和所需的库等。

对于不同的微服务，可以预设有不同的服务类型，服务类型也可以存在于程序文件中。例如，对于不同的服务类型，可以对应有唯一的类型标识，开发者在编写程序文件时，可以将类型标识写入程序文件中。不同的服务类型可以对应不同的运行环境，即，服务类型可以用于表示微服务的运行环境。程序文件中可以包括微服务所需的运行环境，根据程序文件中表明的运行环境，确定微服务的服务类型。

本实施例中，服务类型可以包括Spring Boot、Node.js、前端静态网页和其他类型等，其他类型可以包括以C++和Golang等语言编写程序文件的类型。其中，Spring Boot是一种开源应用框架，Node.js表示JS(JavaScript)运行环境，C++和Golang是开源编程语言。根据微服务的程序文件，确定微服务的服务类型。例如，根据程序文件的编写语言，确定微服务对应的服务类型。

本实施例中，该方法还包括：将微服务的程序包解压到磁盘的预设存储位置中，得到微服务的程序包中的程序文件。

具体的，在根据程序文件确定服务类型之前，需要从程序包中获取程序文件。程序包可以是压缩包的格式，在获取程序文件时，可以对程序包进行解压，得到程序包中的程序文件。

可以预先设定一个指定目录，将程序包解压到指定目录中。例如，预先在磁盘上设置一个存储位置，解压程序包到磁盘的预设存储位置中，使程序文件存储在磁盘上，便于后续直接从磁盘的预设存储位置中获取程序文件。

这样设置的有益效果在于，对程序包进行解压，便于获取所需格式的程序文件，将程序文件存储在设定的位置，实现对数据的有效管理，避免数据丢失，提高镜像的生成效率和精度。

S103、根据预设的与微服务的服务类型对应的镜像分层规则，生成微服务的镜像，并将微服务的镜像推送到预设的镜像仓库中进行存储。

示例性地，不同的服务类型对应有不同的镜像分层规则，在确定微服务的服务类型后，确定与该服务类型对应的镜像分层规则。根据对应的镜像分层规则，构建微服务的镜像。在平台中预先设置一个镜像仓库，镜像仓库用于存储镜像。在得到微服务的镜像后，可以将微服务的镜像存储到镜像仓库中，可以将镜像与微服务的标识进行关联存储，便于后续从镜像仓库中获取微服务的镜像。

镜像分层规则可以用于表示根据程序文件，对微服务的镜像进行构建的规则。镜像中可以包括一个或多个镜像层，通过镜像分层，可以明确镜像每一层的含义和要执行的行为，每个镜像层的数据可以不同。因此，镜像分层规则还可以用于表示根据程序文件，生成微服务的各个镜像层的数据的规则。

根据镜像分层规则，可以生成微服务镜像中各个镜像层的数据，将各个镜像层的数据进行组合，即得到微服务的镜像。例如，镜像共有三层镜像层，将第一层的镜像层数据放在镜像的最下层，第二层的镜像层在中间，将第三层的镜像层数据放在镜像的最上层，从而得到完整的镜像。本实施例中，可以采用Java代码生成最终的镜像。

本实施例中，该方法包括：响应于微服务部署指令，确定待部署微服务；从镜像仓库中获取待部署微服务的镜像，并将待部署微服务的镜像部署到预设的服务器上。

具体的，可以将微服务部署在预设的服务器上，在部署微服务时，需要部署微服务对应的镜像到服务器上。用户可以发出微服务部署指令，指示平台将微服务的镜像部署到服务器上。

微服务部署指令中可以包括微服务的标识，在响应到微服务部署指令后，确定微服务部署指令中的标识，即确定待部署的微服务。镜像仓库中可以存储有多个微服务对应的镜像，根据确定出的标识，从镜像仓库中获取与待部署微服务对应的镜像。将待部署微服务的镜像部署到服务器上，完成对待部署微服务的部署。

这样设置的有益效果在于，在生成微服务的镜像后，可以随时从镜像仓库中获取镜像，进行微服务的部署，便于对微服务镜像的管理，提高微服务的部署效率和精度。

在部署微服务时，通过Java Server进程统一镜像的构建过程并生成镜像文件，比Docker file构建更加稳定可靠。

本实施例中，待部署微服务的镜像为至少两个；从镜像仓库中获取待部署微服务的镜像，并将待部署微服务的镜像部署到预设的服务器上，包括：响应于用户对待部署微服务的镜像的选择操作，从至少两个镜像中，确定待部署微服务的目标镜像；从镜像仓库中，获取待部署微服务的目标镜像，将目标镜像部署到预设的服务器上。

具体的，在镜像仓库中，一个微服务可以对应有多个镜像，例如，微服务可能对应有不同版本的镜像。在确定待部署的微服务后，从镜像仓库中查找与待部署微服务对应的所有镜像。用户可以对这些镜像进行选择，例如，用户可以从可视化界面上看到多个镜像的镜像名称，镜像名称可以用于表示镜像版本。

用户可以通过可视化界面，对待部署微服务的镜像进行选择操作。响应到用户的选择操作，确定用户从多个镜像中所选择的镜像，作为目标镜像。即，确定部署待部署微服务所需要的镜像。从镜像仓库中获取目标镜像的数据，将目标镜像部署到服务器上，完成对待部署微服务的部署。

这样设置的有益效果在于，用户可以根据实际需求，选择需要部署的镜像，避免镜像部署错误，提高微服务部署的灵活性和精度。

本公开实施例可以获取微服务的程序包，根据程序包中的程序文件，确定微服务的服务类型。不同服务类型对应有不同的镜像分层规则，根据对应的镜像分层规则，生成微服务的镜像，并存储在镜像仓库中。使得用户可以不用关注镜像构建的代码编写过程，对于不同的服务类型，根据预设的规则，自动生成镜像，减少镜像构建的时间，有效降低对用户的专业需求，有效节约人力。通过制定镜像分层规则，实现对镜像的统一化管理，极大降低了不同开发者所编写的Docker file存在异常的情况，提高镜像的生成精度和效率。

图2为本公开实施例提供的一种基于微服务的镜像生成方法的流程示意图，该实施例是在上述实施例基础上的可选实施例。

本实施例中，响应于生成指令，获取生成指令所指示的微服务的程序包，可细化为：响应于定时发出的生成指令，确定待生成镜像的微服务，并从预设的任务数据库中确定微服务的程序包拉取方式；其中，程序包拉取方式用于表示拉取程序包时，程序包的来源；根据微服务的程序包拉取方式，获取微服务的程序包。

如图2所示，该方法包括以下步骤：

S201、响应于定时发出的生成指令，确定待生成镜像的微服务，并从预设的任务数据库中确定微服务的程序包拉取方式；其中，程序包拉取方式用于表示拉取程序包时，程序包的来源。

示例性地，生成指令可以由微服务使用平台自身进行发出和响应，即，微服务平台可以自动进行程序包的获取。可以预设生成指令的发出周期，例如，微服务使用平台可以每小时向自身发出一个生成指令，即，微服务平台每小时可以响应到一个生成指令。也可以为微服务使用平台设置程序包的获取周期，根据获取周期自动获取程序包，例如，可以每小时进行一次程序包的获取。

生成指令中可以包括待生成镜像的微服务的标识，在响应到定时的生成指令后，可以从生成指令中获取待生成镜像的微服务的标识，根据获取到的标识确定待生成镜像的微服务。微服务使用平台中预设有一个任务数据库，任务数据库可以用于存储微服务的程序包拉取方式。程序包拉取方式是指拉取程序包时，程序包的来源。例如，程序包的来源可以是HTTP(Hyper Text Transfer Protocol，超文本传输协议)地址，或者是某个数据库等。即，任务数据库中并不是直接存储程序包，而是存储程序包的拉取方式，根据拉取方式获取到程序包。任务数据库中可以存储微服务与对应的程序包的拉取方式的关联关系，例如，可以将微服务的标识与程序包拉取方式进行关联存储。在确定待生成镜像的微服务的标识后，从任务数据库中查找到对应的程序包拉取方式。若设置程序包的获取周期，则每隔一个获取周期，平台可以自动从任务数据库中获取镜像生成任务，即获取还未生成镜像的微服务所对应的程序包拉取方式。

本实施例中，该方法还包括：将与微服务对应的程序包拉取方式，预先存储在预设的任务数据库中；其中，程序包拉取方式包括从预设的拉包地址中拉取程序包，或从预设的程序包数据库中拉取程序包；拉包地址用于表示用户通过网页端输入的程序包的所在地址；程序包数据库用于表示存储程序包的数据库。

具体的，可以在需要生成镜像时，将微服务的程序包拉取方式存储在任务数据库中。也可以开发完微服务的程序包之后，需要生成镜像之前，预先将微服务的程序包拉取方式存储在任务数据库中，例如，可以由微服务开发者登录微服务使用平台，将程序包拉取方式存储在平台中的任务数据库，等待微服务使用平台从任务数据库中获取拉取方式，进而获取到程序包。

程序包拉取方式用于表示程序包的来源，程序包的来源可以是某个地址或数据库，即程序包拉取方式可以是从预设的拉包地址中拉取程序包，也可以是从预设的程序包数据库中拉取程序包。拉包地址为程序包所在的地址，可以用于表示微服务开发者通过网页端所输入的程序包所在地址。程序包数据库用于表示存储程序包的数据库，微服务开发者在完成程序包后，可以将程序包放置在程序包数据库中。

这样设置的有益效果在于，通过预先存储程序包拉取方式，可以随时从任务数据库中获取程序包，实现镜像的自动生成，提高镜像生成的效率。

本实施例中，程序包拉取方式为从预设的拉包地址中拉取程序包；根据微服务的程序包拉取方式，获取微服务的程序包，包括：获取用户通过网页端输入的超文本传输协议地址，从超文本传输协议地址中获取微服务的程序包；或者，获取用户通过网页端输入的拉包命令，从拉包命令中确定微服务的拉包地址，并从微服务的拉包地址中获取微服务的程序包；其中，拉包命令用于对程序包进行拉取。

具体的，若程序包拉取方式是从程序包数据库中获取程序包，则表明用户是预先把程序包存储在程序包数据库中，用户即为微服务开发者。例如，微服务开发者可以通过CI(Continuous Integration，持续集成)和CD(Continuous Delivery，持续交付)流程，将程序包发出到开发者一方的内部仓库，作为程序包数据库，微服务使用平台可以从数据包程序库中获取程序包。

若程序包拉取方式为从预设的拉包地址中拉取程序包，则表明用户预先将程序包存储到拉包地址中。拉包地址可以是HTTP地址，用户可以预先通过网页端输入HTTP的拉包地址，指定程序包的来源，存储到任务数据库中。在获取程序包时，从任务数据库中获取用户通过网页端输入的HTTP地址，从该HTTP地址中获取到微服务的程序包。

用户也可以在任务数据库中存储拉包命令，拉包命令中含有程序包的地址。即，程序包拉取方式可以是通过拉包命令中的拉包地址来获取程序包。拉包命令可以是Wget命令，Wget命令是一种下载文件的命令行工具。用户可以通过网页端输入Wget拉包命令，通过Wget拉包命令中的拉包地址指定程序包的来源。在获取程序包时，可以获取用户从网页端输入的Wget拉包命令，通过Wget拉包命令中的位置得到程序包。

这样设置的有益效果在于，用户可以使用多种方式指定程序包的拉取方式，便于用户操作，使平台可以通过不同的途径获取到程序包，提高程序包拉取的灵活性，进而提高镜像的生成效率。

S202、根据微服务的程序包拉取方式，获取微服务的程序包。

示例性地，在得到程序包拉取方式后，根据程序包拉取方式，得到微服务的程序包。例如，程序包拉取方式是从程序包数据库中获取程序包，则微服务使用平台可以从程序包数据库中查找与微服务对应的程序包。

若程序包拉取方式是从预设的拉包地址获取程序包，则从预设的拉包地址中获取该地址所存储的程序包，作为微服务的程序包。或者先从拉包命令中得到拉包地址，再从拉包地址中获取到微服务的程序包。本实施例中，通过拉包命令、拉包地址或程序包数据库等方式，在Java Server进程中拉取微服务对应的程序包。实现对程序包的自动拉取，提高镜像的生成效率。

S203、根据微服务的程序包中的程序文件，确定微服务的服务类型；其中，服务类型用于表示微服务的运行环境。

示例性地，本步骤可以参见上述步骤S102，不再赘述。

S204、根据预设的与微服务的服务类型对应的镜像分层规则，生成微服务的镜像，并将微服务的镜像推送到预设的镜像仓库中进行存储。

示例性地，本步骤可以参见上述步骤S103，不再赘述。

本公开实施例可以获取微服务的程序包，根据程序包中的程序文件，确定微服务的服务类型。不同服务类型对应有不同的镜像分层规则，根据对应的镜像分层规则，生成微服务的镜像，并存储在镜像仓库中。使得用户可以不用关注镜像构建的代码编写过程，对于不同的服务类型，根据预设的规则，自动生成镜像，减少镜像构建的时间，有效降低对用户的专业需求，用户无需关注镜像使用的技术和构建的过程，节约人力。通过制定镜像分层规则，实现对镜像的统一化管理，极大降低了不同开发者所编写的Docker file存在异常的情况，提高镜像的生成精度和效率。

图3为本公开实施例提供的一种基于微服务的镜像生成方法的流程示意图，该实施例是在上述实施例基础上的可选实施例。

本实施例中，根据预设的与微服务的服务类型对应的镜像分层规则，生成微服务的镜像，可细化为：根据预设的服务类型与镜像分层规则之间的关联关系，确定与微服务的服务类型对应的镜像分层规则；根据与微服务的服务类型对应的镜像分层规则，生成微服务的镜像层数据；根据微服务的镜像层数据，得到微服务的镜像。

如图3所示，该方法包括以下步骤：

S301、响应于生成指令，获取生成指令所指示的微服务的程序包；其中，生成指令用于指示生成微服务的镜像；程序包中包括至少一个程序文件，程序文件用于表示运行微服务所需的数据。

示例性地，本步骤可以参见上述步骤S101，不再赘述。

S302、根据微服务的程序包中的程序文件，确定微服务的服务类型；其中，服务类型用于表示微服务的运行环境。

示例性地，本步骤可以参见上述步骤S102，不再赘述。

S303、根据预设的服务类型与镜像分层规则之间的关联关系，确定与微服务的服务类型对应的镜像分层规则。

示例性地，预先设置服务类型与镜像分层规则之间的关联关系，不同服务类型对应的镜像分层规则不同。镜像分层规则是对镜像进行分层次来生成的规则，镜像中可以包括多个镜像层，因此，在生成镜像时，可以根据镜像分层规则来生成每一层的镜像层。

在确定微服务的服务类型之后，根据服务类型与镜像分层规则之间的关联关系，查找与微服务的服务类型对应的镜像分层规则，便于根据查找到的镜像分层规则来构建镜像。通过平台中镜像的生成服务，统一Spring Boot、Node.js、前端静态网页和Golang等类型的镜像构建过程，做到构建流程的统一化。用户无需关注镜像的构建过程，减少人力和时间，提高镜像的构建效率和精度，实现不同环境下的微服务的部署。

S304、根据与微服务的服务类型对应的镜像分层规则，生成微服务的镜像层数据。

示例性地，镜像中包括多个镜像层，各个镜像层中的数据可以不同。镜像分层规则可以用于生成每层的镜像层的数据，即，可以根据与微服务的服务类型对应的镜像分层规则，生成微服务的每层的镜像层数据。例如，微服务的镜像有三层，镜像分层规则中包括第一层镜像层数据生成方式、第二层镜像层数据生成方式和第三层镜像层数据生成方式。根据各层的镜像层数据生成方式，可以得到各层的镜像层数据。

镜像中的第一层为微服务运行所需要的基础环境，例如，基础环境可以是CentOS7(Community Enterprise Operating System，社区企业操作系统)或CentOS 8等。第二层中包括运行环境所必须的软件包，例如，Spring Boot需要openJDK(open JavaDevelopment Kit，开源Java开发工具包)，还可以包括启停脚本，例如，启动函数、停止函数和探活检查函数等。第三层是用户为微服务自由选择的软件包，一般是体积较大的软件包，实现根据需求进行选择化配置，对于不需要的软件包，可以减少最终镜像的大小。第四层和第四层之上可以是微服务的程序文件中的代码产出生成的编译文件。

本实施例中，根据与微服务的服务类型对应的镜像分层规则，生成微服务的镜像层数据，包括：根据与微服务的服务类型对应的镜像分层规则，确定微服务的镜像层的数量，以及各镜像层对应的镜像层数据生成方式；根据各镜像层对应的镜像层数据生成方式，生成微服务的各个镜像层的镜像层数据。

具体的，不同服务类型的微服务的镜像层数量可以不同，根据与微服务的服务类型对应的镜像分层规则，确定微服务的镜像层数量。本实施例中，各种服务类型对应的镜像层数量大于或等于四层。例如，对于Spring Boot类型，镜像层数量可以是七层；对于Node.js类型，镜像层数量可以是五层；对于前端静态网页的类型，镜像层数量可以是四层；对于Golang和C++等其他类型，镜像层数量可以是四层。每一层的镜像层数据不同，镜像分层规则中可以包括每一层镜像层数据的生成方式。即，可以根据镜像分层规则，确定各镜像层对应的镜像层数据生成方式。

根据各镜像层对应的镜像层数据生成方式，自动生成各层的镜像层数据。对于Spring Boot类型的微服务，本质是运行fat-jar(uber-jar，包含所有依赖的jar包)，而常规的一个fat-jar大小超过100M，若将整个fat-jar都进行构建，则每次部署都会拉取整个jar包，造成时间上的消耗。本公开实施例中，在进行镜像构建时，前三层的镜像层数据生成方式是根据预先设定的规则分别生成微服务运行所需要的基础环境的数据、运行环境所必须的软件包的数据以及用户为微服务自由选择的软件包的数据。第四层的镜像层数据生成方式是从程序文件中获取微服务依赖的第三方jar包，根据预设的编译规则，编译为第四层的镜像层数据，第四层的镜像层数据版本更迭改动较小。第五层的镜像层数据是与微服务相关的一些固定配置文件，版本更迭改动较小，镜像层数据生成方式可以是从程序文件中获取并进行编译。第六层也是根据程序文件得到的服务依赖的snapshot(快照)jar包。第七层是根据预设的规则，基于程序文件编译代码，第七层的镜像层数据的版本会经常改动，放到最上一层。

对于Node.js类型的各镜像层数据的生成方式，第一层依然是生成服务运行需要的基础环境的数据，第二层是Node环境加Node.js服务的启停脚本，第三层还是可选的软件包，第四层是文件存储较大的第三方依赖包，第五层是文件存储较小的编译生成的文件。对于前端静态网页类型的镜像构建，第二层的镜像层数据生成方式主要用于生成多版本Nginx(engine x，服务器)运行环境和Nginx服务启停文件。Golang和C++等其他类型，除centOS的运行环境外，不依赖其他环境包，所以第二层仅为启停脚本。

对于启停脚本，主要包括服务启动命令、停止命令和探活检查命令等，例如，程序包启动、停止、探活检查入口函数脚本，可以分别对应start(启动)、stop(停止)和check(检查)函数，start和stop函数会调用run.sh里面的函数，check函数会调用check.sh里面的函数。run.sh用于表示程序包启动、停止的函数脚本，check.sh用于表示程序包探活检查脚本，包括探活实现逻辑。启停脚本中还可以包括自定义环境变量脚本，用于实现用户的一些特殊定制需求，例如，自定义健康检查等。

这样设置的有益效果在于，可以对镜像的每一层镜像层数据进行生成，避免数据混乱，提高镜像的生成精度和效率，保证微服务的正常运行。对启停脚本和探活命令使用脚本等进行统一化管理，用户无需关注云原生部署的各项繁琐配置，通过平台统一化管理，极大降低了异常情况的发生。

本实施例中，镜像层为软件包配置层；软件包配置层中包括用户选择配置的软件包；根据各镜像层对应的镜像层数据生成方式，生成微服务的各个镜像层的镜像层数据，包括：响应于用户发出的软件包的自定义操作，确定用户所选择的软件包，为自定义软件包；获取自定义软件包，将自定义软件包作为镜像层数据，配置到软件包配置层中。

具体的，软件包配置层可以是镜像中的第三层，用户可以在生成镜像之前，自由选择软件包，从而满足实际的业务需求。可被选择的软件包预先存储在平台上，用户在需要生成镜像前，预先对软件包进行选择，用户的选择操作即为自定义操作。响应到用户的自定义操作，确定用户所选择的软件包，作为自定义软件包。当需要开始生成镜像时，获取用户选择的自定义软件包。根据软件包配置层的镜像层数据生成方式，将自定义软件包编译为镜像层数据，配置到软件包配置层中。

对于可选软件包，是为了将一些实际需要的、比较小众的以及体积较大的程序包，做成配置数据，提供给用户进行选择。

这样设置的有益效果在于，使镜像生成可以满足实际需求，提高镜像生成的灵活性，用户操作简单，节约人力和时间，提高镜像生成的精度和效率。

S305、根据微服务的镜像层数据，得到微服务的镜像，并将微服务的镜像推送到预设的镜像仓库中进行存储。

示例性地，将各层的镜像层数据进行拼接，得到完整的微服务的镜像。在平台中预先设置镜像仓库，将微服务的镜像存储在镜像仓库中，便于后续进行部署。对于不同的微服务，可以对应有不同的镜像层数据拼接逻辑，例如，预先设置镜像和镜像层之间的关联关系，将与镜像关联的镜像层的镜像层数据进行组合。可以将各层的镜像层数据按照镜像层的顺序进行拼接，得到最终的镜像。本实施例中，可以通过Java语言来生成镜像。也可以将各镜像层数据存储在镜像仓库中，当需要进行微服务的镜像部署时，从镜像仓库中查找与微服务的镜像关联的镜像层，将关联的镜像层的镜像数据按照层数的顺序进行拼接，得到微服务的镜像进行部署。

本实施例中，根据微服务的镜像层数据，得到微服务的镜像，包括：根据与微服务的服务类型对应的镜像分层规则，确定微服务的镜像层的排序；根据微服务的镜像层的排序，将微服务的镜像层数据构建为微服务的镜像。

具体的，镜像分层规则中可以包括各镜像层的排序，排序是指镜像层在组装成镜像时的上下排列位置。例如，第一层在最下方，层数越大，排序越靠上。从镜像分层规则中，确定微服务的各镜像层的排序，根据镜像层的排序，将镜像层数据进行组装，构建得到微服务的镜像。

例如，对于Spring Boot类型，最后一层是根据微服务的程序文件所编译的代码，该层的镜像层数据的版本会经常发生更新迭代。对于镜像而言，当镜像中的数据需要变化时，从最上层开始获取镜像层数据，越下层的数据需要变动，则需要占用越多的存储空间。因此，可以将最后一层放在最上面一层，对于改动少的镜像层可以放在下层。即，将越容易变更的镜像层放到镜像的上层，不容易变更的镜像层放到下层。

这样设置的有益效果在于，将容易变更的数据放在上层，不容易变更的数据放在下层，镜像服务器保存的时候可以做到底层文件共用，减少存储镜像的压力，即减少镜像仓库的存储空间，部署时减少拉取镜像的时间，提升部署效率。

图4为本公开实施例提供的镜像层结构示意图。第一层401可以在镜像的最下层，第二层402、第三层403和第四层404依次向上排列，在第四层404之上还可以有其他的镜像层，第四层404以及之上的镜像层可以根据微服务的应用代码进行编译得到。

本公开实施例可以获取微服务的程序包，根据程序包中的程序文件，确定微服务的服务类型。不同服务类型对应有不同的镜像分层规则，根据对应的镜像分层规则，生成微服务的镜像，并存储在镜像仓库中。使得用户可以不用关注镜像构建的代码编写过程，对于不同的服务类型，根据预设的规则，自动生成镜像，减少镜像构建的时间，有效降低对用户的专业需求，用户无需关注镜像使用的技术和构建的过程，节约人力。通过制定镜像分层规则，实现对镜像的统一化管理，极大降低了不同开发者所编写的Docker file存在异常的情况，提高镜像的生成精度和效率。

图5为本公开实施例提供的一种基于微服务的镜像生成装置的结构框图。为了便于说明，仅示出了与本公开实施例相关的部分。参照图5，基于微服务的镜像生成装置500包括：获取单元501、类型确定单元502和生成单元503。

获取单元501，用于响应于生成指令，获取所述生成指令所指示的微服务的程序包；其中，所述生成指令用于指示生成微服务的镜像；所述程序包中包括至少一个程序文件，所述程序文件用于表示运行微服务所需的数据；

类型确定单元502，用于根据所述微服务的程序包中的程序文件，确定所述微服务的服务类型；其中，所述服务类型用于表示微服务的运行环境；

生成单元503，用于根据预设的与所述微服务的服务类型对应的镜像分层规则，生成所述微服务的镜像，并将所述微服务的镜像推送到预设的镜像仓库中进行存储。

图6为本公开实施例提供的一种基于微服务的镜像生成装置的结构框图。如图6所示，基于微服务的镜像生成装置600包括获取单元601、类型确定单元602和生成单元603，其中，获取单元601包括指令响应模块6011和程序包获取模块6012。

指令响应模块6011，用于响应于定时发出的生成指令，确定待生成镜像的微服务，并从预设的任务数据库中确定所述微服务的程序包拉取方式；其中，所述程序包拉取方式用于表示拉取程序包时，程序包的来源；

程序包获取模块6012，用于根据所述微服务的程序包拉取方式，获取所述微服务的程序包。

一个示例中，该装置600，还包括：

方式存储单元，用于将与所述微服务对应的程序包拉取方式，预先存储在预设的任务数据库中；其中，所述程序包拉取方式包括从预设的拉包地址中拉取程序包，或从预设的程序包数据库中拉取程序包；所述拉包地址用于表示用户通过网页端输入的程序包的所在地址；所述程序包数据库用于表示存储程序包的数据库。

一个示例中，程序包拉取方式为从预设的拉包地址中拉取程序包；

程序包获取模块6012，包括：

第一获取子模块，用于获取用户通过网页端输入的超文本传输协议地址，从所述超文本传输协议地址中获取所述微服务的程序包；或者，

第二获取子模块，用于获取用户通过网页端输入的拉包命令，从所述拉包命令中确定所述微服务的拉包地址，并从所述微服务的拉包地址中获取所述微服务的程序包；其中，所述拉包命令用于对程序包进行拉取。

一个示例中，该装置600，还包括：

解压单元，用于将所述微服务的程序包解压到磁盘的预设存储位置中，得到所述微服务的程序包中的程序文件。

一个示例中，生成单元603，包括：

规则确定模块，用于根据预设的服务类型与镜像分层规则之间的关联关系，确定与所述微服务的服务类型对应的镜像分层规则；

镜像层生成模块，用于根据与所述微服务的服务类型对应的镜像分层规则，生成所述微服务的镜像层数据；

镜像生成模块，用于根据所述微服务的镜像层数据，得到所述微服务的镜像。

一个示例中，镜像层生成模块，包括：

镜像层确定子模块，用于根据与所述微服务的服务类型对应的镜像分层规则，确定所述微服务的镜像层的数量，以及各镜像层对应的镜像层数据生成方式；

镜像层生成子模块，用于根据各镜像层对应的镜像层数据生成方式，生成所述微服务的各个镜像层的镜像层数据。

一个示例中，镜像层为软件包配置层；所述软件包配置层中包括用户选择配置的软件包；

镜像层生成子模块，具体用于：

响应于用户发出的软件包的自定义操作，确定用户所选择的软件包，为自定义软件包；获取所述自定义软件包，将所述自定义软件包作为镜像层数据，配置到所述软件包配置层中。

一个示例中，镜像生成模块，包括：

顺序确定子模块，用于根据与所述微服务的服务类型对应的镜像分层规则，确定所述微服务的镜像层的排序；

镜像构建子模块，用于根据所述微服务的镜像层的排序，将所述微服务的镜像层数据构建为所述微服务的镜像。

一个示例中，该装置600，还包括：

部署响应单元，用于响应于微服务部署指令，确定待部署微服务；

镜像部署单元，用于从镜像仓库中获取待部署微服务的镜像，并将待部署微服务的镜像部署到预设的服务器上。

一个示例中，待部署微服务的镜像为至少两个；

镜像部署单元，包括：

目标确定模块，用于响应于用户对待部署微服务的镜像的选择操作，从至少两个镜像中，确定待部署微服务的目标镜像；

部署模块，用于从所述镜像仓库中，获取待部署微服务的目标镜像，将所述目标镜像部署到预设的服务器上。

根据本公开的实施例，本公开还提供了一种电子设备。

图7为本公开实施例提供的一种电子设备的结构框图，如图7所示，电子设备700包括：至少一个处理器702；以及与所述至少一个处理器702通信连接的存储器701；其中，存储器存储有可被所述至少一个处理器702执行的指令，所述指令被所述至少一个处理器702执行，以使所述至少一个处理器702能够执行本公开的基于微服务的镜像生成方法。

电子设备700还包括接收器703和发送器704。接收器703用于接收其他设备发送的指令和数据，发送器704用于向外部设备发送指令和数据。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

根据本公开的实施例，本公开还提供了一种计算机程序产品，计算机程序产品包括：计算机程序，计算机程序存储在可读存储介质中，电子设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得电子设备执行上述任一实施例提供的方法。

图8示出了可以用来实施本公开的实施例的示例电子设备800的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图8所示，设备800包括计算单元801，其可以根据存储在只读存储器(ROM)802中的计算机程序或者从存储单元808加载到随机访问存储器(RAM)803中的计算机程序，来执行各种适当的动作和处理。在RAM 803中，还可存储设备800操作所需的各种程序和数据。计算单元801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

设备800中的多个部件连接至I/O接口805，包括：输入单元806，例如键盘、鼠标等；输出单元807，例如各种类型的显示器、扬声器等；存储单元808，例如磁盘、光盘等；以及通信单元809，例如网卡、调制解调器、无线通信收发机等。通信单元809允许设备800通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元801可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元801的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元801执行上文所描述的各个方法和处理，例如基于微服务的镜像生成方法。例如，在一些实施例中，基于微服务的镜像生成方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元808。在一些实施例中，计算机程序的部分或者全部可以经由ROM 802和/或通信单元809而被载入和/或安装到设备800上。当计算机程序加载到RAM 803并由计算单元801执行时，可以执行上文描述的基于微服务的镜像生成方法的一个或多个步骤。备选地，在其他实施例中，计算单元801可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行基于微服务的镜像生成方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、复杂可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS服务("Virtual Private Server"，或简称"VPS")中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。