一种信息处理方法及装置、设备、存储介质与流程

1.本技术涉及信息处理技术领域，涉及但不限于一种信息处理方法及装置、设备、存储介质。


背景技术：

2.随着互联网行业的不断发展，基于微服务架构的应用越来越多。在开发微服务应用时，遵循持续集成(continuous integration，ci)和持续交付(continuous delivery，cd)的实践原则，需要频繁地将每个微服务的分别部署到各种环境中，由于每个微服务可以独立部署，有单独的代码仓库，可以独立运行和扩展；所以，一般通过给微服务搭建部署流水线的方式来实现微服务的部署。
3.其中，在搭建微服务的部署流水线时，需要针对每个微服务分别完成拉取代码、代码编译，打包镜像文件和环境部署等步骤。
4.目前主要通过詹金斯(jenkins)软件搭建微服务的部署流水线。具体的，针对每个微服务，人工查找该微服务的程序代码的存储位置、确定该微服务的编译环境、确定该微服务的待部署的环境，然后人工采用jenkins软件编写对应的脚本，运行脚本，根据该微服务的程序代码存储的位置拉取程序代码、根据该微服务的编译环境进行编译，并将编译后的文件打包为镜像文件后存储，以及根据该微服务的待部署的环境进行环境部署。
5.这样，当需要对多个微服务进行部署时，由于多个微服务对应的技术栈可能不同；即，多个微服务的程序语言可能不同、程序代码的存储位置可能不同、编译环境可能不同、待部署的环境也可能不同；所以，在搭建微服务部署流水线时的拉取代码、代码编译、打包和环境部署等步骤均不同。因此，需要针对每个微服务搭建一个专用的部署流水线；从而导致实现复杂、管理与维护成本高。


技术实现要素：

6.本技术提供一种信息处理方法及装置、设备、存储介质，从而通过适用于多个微服务的配置文件和通用的部署流水线，完成微服务的部署；实现简单、管理与维护成本低。
7.本技术实施例的技术方案是这样实现的：
8.本技术实施例提供了一种信息处理方法，包括：
9.获取配置文件的参数项，所述配置文件复用于至少两个微服务；
10.基于所述配置文件的参数项，配置目标微服务的参数项信息，得到所述目标微服务对应的目标配置文件；
11.基于所述目标配置文件和所述目标微服务的程序代码运行部署流水线，以部署所述目标微服务。
12.本技术实施例提供了一种信息处理装置，所述装置包括：
13.获取模块，用于获取配置文件的参数项，所述配置文件复用于至少两个微服务；
14.配置模块，用于基于所述配置文件的参数项，配置目标微服务的参数项信息，得到
所述目标微服务对应的目标配置文件；
15.部署模块，用于基于所述目标配置文件和所述目标微服务的程序代码运行部署流水线，以部署所述目标微服务。
16.本技术实施例还提供了一种电子设备，包括：存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述信息处理方法。
17.本技术实施例还提供了一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述信息处理方法。
18.本技术实施例所提供的信息处理方法、装置、设备及存储介质，获取配置文件的参数项，所述配置文件复用于至少两个微服务；基于所述配置文件的参数项，配置目标微服务的参数项信息，得到所述目标微服务对应的目标配置文件；基于所述目标配置文件、所述目标微服务的程序代码文件以及部署流水线，部署所述目标微服务。在本技术的方案中，用户预先设置了可以用于多个微服务的配置文件，该配置文件中规定了微服务部署时的相关参数项；在部署一个微服务时，在该配置文件中配置该微服务的相关信息，得到目标配置文件，基于目标配置文件和目标微服务的程序代码运行该部署流水线，自动完成该微服务的部署。这样，一方面，该方案可以自动完成微服务的部署，实现简单；另一方面，该部署过程不受微服务的技术栈的限定，即对于每个微服务均可以通用，管理与维护成本低。
附图说明
19.图1为本技术实施例提供的信息处理系统的一种可选的结构示意图；
20.图2为本技术实施例提供的信息处理方法的一种可选的流程示意图；
21.图3为本技术实施例提供的信息处理方法中部分步骤的一种可选的流程示意图；
22.图4为本技术实施例提供的电子设备的一种可选的结构示意图；
23.图5为本技术实施例提供的信息处理方法一种可选的流程示意图；
24.图6为本技术实施例提供的信息处理装置的一种可选的结构示意图；
25.图7为本技术实施例提供的电子设备的一种可选的结构示意图。
具体实施方式
26.为使本技术的目的、技术方案和优点更加清楚，下面将结合本技术中的附图，对申请的具体技术方案做进一步详细描述。以下实施例用于说明本技术，但不用来限制本技术的范围。
27.本技术可提供信息处理方法及装置、设备和存储介质。实际应用中，信息处理方法可由信息处理装置实现，信息处理装置中的各功能实体可以由电子设备(如终端设备)的硬件资源，如处理器等计算资源、通信资源(如用于支持实现光缆、蜂窝等各种方式通信)协同实现。
28.为了便于理解，先对本技术中涉及到的技术术语进行解释。
29.1)、微服务，具有一定功能，且可以独立部署和构建的服务程序。例如，一个应用程序可以作为一个微服务。再例如，一个应用程序中的一个功能模块也可以作为一个微服务。
30.2)、部署流水线，用于微服务的部署，规定了微服务部署过程中需要满足的参数，以及部署的步骤。其中，可以根据一个部署流水线，自动完成一个微服务的部署。
31.3)、配置文件，可以指包括完成微服务的部署所需参数文件。具体的，配置文件可以包括下述参数中的一项或者多项：环境参数、辅助参数和构建参数。
32.本技术实施例提供的信息处理方法应用于信息处理系统，信息处理系统包括客户端以及一个或至少一个服务器。
33.图1示意了一种信息处理系统的结构，信息处理系统10包括：客户端101和至少一个服务器102。其中，客户端101和服务器102之间可以通过网络103进行通信。
34.其中，客户端101可以接收和存储用户编写微服务的程序代码，并将一个或者多个微服务的相关信息(例如，微服务的程序、微服务的环境信息等)存储于客户端101或者服务器102。
35.若需要部署一个微服务，以该信息处理系统为例，在一示例中，可以将一个微服务部署于客户端101；在另一示例中，也可以将该一个微服务部署于服务器102。
36.在另一示例中，信息处理系统可以包括多个服务器102，多个服务器102共同组成一个集群。在该示例中，可以将该一个微服务部署于信息处理系统包括的任一个服务器；或者，也可以将该一个微服务部署于信息处理系统包括的多个服务器。
37.这里，客户端101，存储了一个或至少一个微服务的相关信息。服务器102可以接收客户端101发送的，或者其他服务器发送的微服务的程序代码以及微服务的部署参数，基于部署流水线、程序代码以及微服务的部署参数，来部署微服务。
38.示例性的，基于图1所示的客户端101，客户端101基于用户的第一操作，响应于第一操作，客户端101向服务器102发送第一指令，服务器102在部署流水线中获取配置文件的参数项，基于所述配置文件的参数项，配置目标微服务的参数项信息，得到所述目标微服务对应的目标配置文件；基于所述目标配置文件和所述目标微服务的程序代码运行部署流水线，以部署所述目标微服务。
39.下面，结合图1所示的信息处理系统的示意图，对本技术实施例提供的信息处理方法及装置、设备和存储介质的各实施例进行说明。
40.本实施例提供一种信息处理方法，该方法应用于信息处理装置，其中，信息处理装置可部署于电子设备上。该方法所实现的功能可以通过电子设备中的处理器调用程序代码来实现，当然程序代码可以保存在计算机存储介质中，可见，该电子设备至少包括处理器和存储介质。
41.电子设备可以是任何具有信息处理能力的设备，在一种实施例中，电子设备可以是移动终端设备；例如，电子设备可以是笔记本、平板电脑、手机等等。在另一种实施例中，电子设备还可以是不便移动的具有计算功能的终端设备，比如服务器、台式计算机、桌面电脑等。
42.当然，本技术实施例不局限于提供的方法和硬件，还可有多种实现方式，例如提供为存储介质(存储有用于执行本技术实施例提供的信息处理方法的指令)。
43.图2为本技术实施例的一种信息处理方法的流程示意图，用于部署多个微服务，现以一个微服务(目标微服务)为例，对通过部署流水线实现微服务的部署的过程进行详细说明。
44.其中，执行本技术的信息处理方法的执行主体为电子设备，电子设备可以为上述信息处理系统中的服务器。
45.如图2所示，该方法包括以下步骤：
46.s201、电子设备获取配置文件的参数项。
47.其中，配置文件复用于至少两个微服务。
48.配置文件是在部署流水线的研发阶段设计好的，即，在执行本技术的信息处理方法时，配置文件已经存储在电子设备上。其中，在部署流水线的研发阶段，可以根据实际需求设计配置文件的具体内容，本技术实施例对此不予唯一限定。
49.配置文件可以包括至少一个参数项，用于表征部署微服务所需要的参数。其中，参数项可以包括以下至少之一：环境参数项、辅助参数项和构建参数项。其中，环境参数项所包括的内容用于表征微服务的待部署的环境，辅助参数项对应的内容用于指向微服务对应的目标镜像文件的位置，构建信息项用于根据目标微服务的代码生成目标镜像文件。本技术实施例对配置文件中的参数项不进行限定。
50.s201可以实施为：电子设备接收第一指令，响应于该第一指令，获取在部署流水线的研制阶段设置的配置文件，并在配置文件中获取其包括的至少一个参数项。
51.第一指令可以是客户端发送的用于指示进行微服务部署的指令。
52.s202、电子设备基于所述配置文件的参数项，配置目标微服务的参数项信息，得到所述目标微服务对应的目标配置文件。
53.目标微服务也就是待部署的微服务。
54.具体的，电子设备配置文件的参数项中，分别针对每个参数项，配置目标微服务对应的参数项信息，将配置好的参数项作为目标微服务的目标配置文件。
55.例如，配置文件的参数项包括a参数项和b参数项，则s202可以实施为：电子设备在配置文件的a参数项中配置a参数项的参数，得到配置好的a参数，电子设备在配置文件的b参数项中配置b参数项的参数，得到配置好的b参数，目标微服务的目标配置文件为配置好的a参数和配置好的b参数所属的配置文件。
56.本技术实施例中，目标微服务的参数项(也可以称为待配置的参数项)可以包括配置文件中的部分或者全部参数项。例如，配置文件的参数项包括a参数项、b参数项和c参数项；待配置的参数项可以包括a参数项和b参数项；或者待配置的参数项可以包括a参数项、b参数项和c参数项。
57.s203、电子设备基于所述目标配置文件和所述目标微服务的程序代码运行部署流水线，以部署所述目标微服务。
58.其中，在信息处理系统中，每个微服务分别对应一个代码仓库。
59.在一示例中，s203可以实施为：电子设备根据目标配置文件、目标微服务的程序代码和部署流水线创建至少一个任务；运行至少一个任务，以部署目标微服务。
60.示例性的，电子设备调用部署流水线，获取部署目标微服务所需的步骤，对于每一个步骤，创建一个与该步骤对应的任务，根据步骤执行顺序运行所有创建的任务，完成目标微服务的自动部署。其中，可以将目标配置文件所描述的参数作为创建任务时所依据的参数，并将目标微服务的程序代码作为任务的处理对象。
61.例如，该至少一个任务可以包括：拉取代码、生成镜像文件和环境部署。
62.当部署流水线基于泰克顿tekton软件开发，则电子设备根据目标配置文件、目标微服务的程序代码和部署流水线创建至少一个任务。例如，电子设备将目标配置文件和目
标微服务的程序代码提交至目标代码仓库；通过采集器根据目标代码仓库生成目标事件；通过tekton软件为目标事件创建流水线运行对象pipelinerun；通过tekton根据pipelinerun和通用的部署流水线创建部署微服务所需的至少一个任务。
63.在另一示例中，s203可以实施为：电子设备通过管理部署流水线的软件，基于目标微服务的部署参数和目标微服务的程序代码，运行部署流水线，自动部署该目标微服务。
64.可以根据实际需求选择管理部署流水线的软件，本技术实施例对此不做唯一限定，例如，管理部署流水线的软件可以为库伯内特斯(kubernetes，k8s)软件。
65.当需要配置另一个微服务时，也是先得到另一个配置文件，然后根据另一个配置文件和另一个微服务的程序代码文件以及部署流水线，部署另一个微服务。
66.本技术实施例提供的信息处理方法，获取配置文件的参数项，所述配置文件复用于至少两个微服务；基于所述配置文件的参数项，配置目标微服务的参数项信息，得到所述目标微服务对应的目标配置文件；基于所述目标配置文件和所述目标微服务的程序代码运行部署流水线，以部署所述目标微服务。在本技术的方案中，用户预先设置了一个配置文件，该配置文件中规定了微服务部署时的相关参数项；在部署一个微服务时，在该配置文件中配置该微服务的相关信息，基于目标配置文件和目标微服务的程序代码运行部署流水线，即可自动完成该微服务的部署。这样，一方面，该方案可以自动完成微服务的部署，实现简单；另一方面，该部署过程不受微服务的技术栈的限定，即对于每个微服务均可以通用，管理与维护成本低。
67.配置文件可以包括不同的参数项，具体的，配置文件可以包括但不限于下述实施例a至实施例d。
68.实施例a，配置文件的参数项包括环境参数项。
69.其中，环境参数项所包括的内容用于表征微服务的待部署的环境。待部署的环境可以包括但不限于下述一个或多个环境：开发环境、运行环境以及测试环境。
70.可以根据实际需求设置目标环境参数的具体内容。例如，目标环境参数可以包括测试环境。
71.在实施例a中，s201的实施可以包括：电子设备打开部署流水线，接收用户的第一操作，响应于该第一操作，获取在部署流水线的研制阶段设置的配置文件，并在配置文件中获取其包括的环境参数项。
72.对应的，s202的实施可以包括：电子设备在s201中获取的配置文件的环境参数项中，写入目标微服务的环境参数，得到目标环境参数，将目标环境参数作为目标配置文件。
73.示例性的，假设目标微服务的环境参数包括测试环境，s202可以实施为：电子设备在s201中获取的配置文件的环境参数项中，写入目标微服务在测试环境下的库文件，得到目标环境参数，作为目标微服务的配置文件。
74.对应的，如图3所示，电子设备运行至少一个任务，自动部署目标微服务的过程可以包括但不限于下述s2031至s2033。
75.在s2031至s2033中，每个步骤可以对应一个任务。其中，第一个步骤为获取目标微服务的程序代码；第一个步骤对应的任务为第一任务；第二个步骤为根据目标微服务的程序代码文件生成目标镜像文件，第二个步骤对应的任务为第二任务；第三个步骤为将目标镜像文件部署到目标环境参数所执行的目标环境中，第三个步骤对应的任务为第三任务。
76.s2031、电子设备获取所述目标微服务的程序代码。
77.在一示例中，存储目标微服务的程序代码的名称是已知的，则电子设备可以运行至少一个任务中的第一任务，根据目标微服务的程序代码的名称，获取具有该名称的文件，打开该文件，得到目标微服务的程序代码。
78.在另一示例中，存储目标微服务的程序代码的位置是已知的，则电子设备可以运行至少一个任务中的第一任务，根据存储该目标微服务的程序代码的位置，获取存储目标微服务的程序代码的文件，打开该文件，得到目标微服务的程序代码。
79.s2032、电子设备根据所述目标微服务的程序代码文件生成目标镜像文件。
80.在一示例中，若微服务的程序代码为编译性语言，例如c语言等，则s2032可以实施为：电子设备运行至少一个任务中的第二任务，将s2031中得到的目标微服务的程序码编译为二进制，将该二进制代码所属的文件通过镜像软件生成目标镜像文件。
81.在一示例中，若微服务的程序代码为解释性语言，例如python语言等，则s2032可以实施为：电子设备运行至少一个任务中的第二任务，将s2031中得到的目标微服务的程序码所属的文件通过镜像软件生成目标镜像文件。
82.可以根据实际需求配置镜像软件，本技术对此不予唯一限定。例如，镜像软件可以为docker软件。
83.s2033、电子设备将所述目标镜像文件部署到所述目标环境参数所执行的目标环境中。
84.在一示例中，电子设备运行至少一个任务中的第三任务，将s2033中得到的目标镜像文件作为目标镜像文件，将目标环境参数与目标镜像文件关联，以使运行该为服务时，可以找到该目标环境参数中的文件。
85.可以根据实际需求配置具体的关联方式。例如，可以将目标环境参数中的库文件的路径与镜像文件的名称关联。
86.实施例b，配置文件的参数项包括环境参数项和辅助参数项。
87.其中，辅助参数项对应的内容用于指向微服务对应的目标镜像文件的位置。换而言之，辅助参数用于指向微服务的部署位置；或者存储微服务的对应的目标镜像文件的位置。
88.可以根据实际需求设置辅助参数的具体形式。
89.例如，辅助参数可以是一个路径，通过该一个路径指向微服务对应的镜像文件的位置。
90.再例如，辅助参数也可以是一个路径加一个文件佳名称，通过该一个路径下的具有该名称的文件夹指向微服务对应的镜像文件的位置。
91.在实施例b中，s201的实施可以包括：电子设备打开部署流水线，接收第一指令，响应于该第一指令，获取在部署流水线的研制阶段设置的配置文件，并在配置文件中获取其包括的环境参数项和辅助参数项。
92.对应的，s202的实现可以包括：电子设备在s201中获取的配置文件的环境参数项中写入目标微服务的环境参数，得到目标环境参数，在s201中获取的配置文件的辅助参数项中写入目标微服务的辅助参数，得到目标辅助参数，将目标环境参数和目标辅助参数作为目标配置文件。
93.对应的，如图3所示，在执行s2033之前，电子设备还可以执行下述s2033a。
94.s2033a、电子设备将所述目标镜像文件存储于所述目标辅助参数指向的位置。
95.电子设备运行第四任务，读取目标辅助参数，将s2032中得到的镜像文件存储到目标辅助参数指向的位置。
96.在一示例中，目标辅助参数为一个路径值时，将目标镜像文件存储到该路径下。
97.目标服务参数可以为宿主机(可以称为目标服务器)下的一个路径。
98.在一示例中，目标辅助参数为一个路径值和一个文件夹名称时，将目标镜像文件存储到该路径下具有该名称的文件夹中。
99.实施例c，配置文件的参数项包括环境参数项和构建参数项。
100.其中，构建信息项用于根据目标微服务的代码生成目标镜像文件。
101.可以根据实际需求设置构建参数的具体内容。例如，构建信息包括微服务的编译软件版本，容器封装软件名称，镜像软件名称，以及相关执行步骤(编译、封装以及镜像)的限定等等。
102.在实施例c中，s201、s202和s203的具体实现可以参考实施例a中s201、s202、s203的实现过程，此处不在赘述。
103.不同的是，在实施例c中，若微服务的程序代码为编译性语言，例如c语言等，s2032可以实施为：电子设备根据目标构建信息，将s2031获取的目标微服务的程序代码后编译成二进制代码，然后采用容器软件进行容器封装，再采用镜像软件将封装后的代码文件生成目标镜像文件。
104.或者，在实施例c中，若微服务的程序代码为解释性语言，例如python语言等，s2032可以实施为：电子设备根据目标构建信息，将s2031获取的目标微服务的程序代码，然后采用容器软件进行容器封装，再采用镜像软件将封装后的代码文件生成目标镜像文件。
105.实施例d、配置文件的参数项包括环境参数项、辅助参数项和构建参数项。
106.具体的，实施例d的实现过程可以参考上述实施例a至实施例c中的具体实施，此处不再一一赘述。
107.需要说明的是，配置文件包括的参数项还可以是上述多种参数的组合，或者，配置文件还可以包括其他参数，或者还可以包括其他参数与上述参数的组合；具体的实施可以参考上述参数中对应的描述，不再一一赘述。
108.可选的，本技术的实施例该可以包括下述过程。
109.电子设备获取目标微服务的度量信息，并记录目标微服务的度量信息。
110.其中，度量信息可以包括：部署时间、待部署的环境。
111.其中，待部署的环境下述至少一项：开发环境、测试环境及生产环境。
112.具体的，在微服务架构的日志文件中获取目标微服务的部署时间和待部署的环境。将获取的微服务的部署时间、待部署的环境存储在预设位置。
113.可以理解的，还可以对微服务的其他信息进行记录。
114.可选的，在本技术的实施例中，也可以预先设置一个目录架构，该目录架构用于规定部署微服务时需要调用的文件的名称，以及各文件之间的存储位置关系，使用目录架构可以快速将微服务的程序代码文件等导入到部署流水线规定的位置。
115.例如，该目录架构可以规定部署微服务时需要调用的文件可以包括微服务的程序
代码文件的名称为main.go、构建参数所属文件的名称为dockerfile、环境参数和辅助参数所属的文件的名称为deploy-config、main.go、dockerfile和deploy-config均存储在根目录下。
116.本技术实施例对于目录架构的具体内容与形式不做限定，可以根据实际需求进行配置。
117.下面，通过具体的应用场景对本技术实施例提供的信息处理方法进行进一步说明。
118.越来越多的应用是基于微服务架构的，这些服务具有拆分粒度细，有单独的代码仓库，独立部署、独立运行和扩展的特点。在开发微服务应用时，遵循ci/cd的实践原则，将每个微服务的代码频繁地部署到各种环境中。由于每个微服务模块都是需要独立部署的，微服务化后的部署单元增多，一般采用自动化的方式去做微服务的部署。
119.相关技术中，部署微服务的技术方案是使用ci工具搭建部署流水线，以减少人工重复性操作。其中，一般采用jenkins软件为微服务模块搭建任务，主要包括编写脚本以完成拉取代码、代码编译、打包镜像和环境部署等步骤。由于各个微服务模块的开发栈可能不同，即，多个微服务的程序语言可能不同、程序代码的存储位置可能不同、编译环境可能不同、待部署的环境也可能不同，所以，在搭建微服务部署流水线时的拉取代码、代码编译、打包和环境部署等步骤均不同。因此，需要针对每个微服务搭建一个专用的部署流水线；从而导致实现复杂、管理与维护成本高。
120.如上所述，使用jenkins作为ci工具部署微服务，存在如下问题：
121.成本高：不同的微服务对应的技术栈不同，构建方式不同，需要专人学习jenkins相关知识，且需要配置专业的管理人员去维护各微服务的部署流水线，从而导致管理部署流水线的成本较高。
122.占用系统资源高：jenkins做ci工具依赖大量的插件，且由于其是基于java语言开发的，所以启动时占用的系统资源较高。
123.可以看出：使用jenkins软件做微服务的自动化部署时，存在管理成本高、占用系统资源高和环境管理困难的问题。
124.本技术提出一种信息处理方法，可以针对多个微服务，通过一个部署流水线，完成多个微服务的部署；且实现简单、管理与维护成本低。
125.具体来说，本技术的技术方案，用户预先在部署流水线中设置了一个配置文件，该配置文件中规定了微服务部署时的相关参数项；在部署一个微服务时，在该配置文件中配置该微服务的相关信息，基于该微服务的相关信息、微服务的程序文件和部署流水线，自动完成该微服务的部署。这样，一方面，该方案可以自动完成微服务的部署，实现简单；另一方面，该部署过程不受微服务的技术栈的限定，即对于每个微服务均可以通用，管理与维护成本低。
126.假设采用tecton软件作为ci工具部署微服务，且预先设置了一个目录架构，配置文件中包括环境参数项、辅助参数项和构建参数项，则本技术的方案可以包括：
127.其中，目录结构的具体示例如下：
[0128][0129][0130]
其中，构建文件(dockerfile)用于存储构建参数。
[0131]
程序文件(main.go)用于存储目标微服务的程序代码。
[0132]
参数文件(deploy-config)用于存储配置文件包括的目标环境参数和辅助参数。
[0133]
部署文件(deploy)用于存储微服务在各个阶段的环境文件。
[0134]
具体的，部署文件包括开发文件(develop)、生产文件(production)和测试文件(staging)。
[0135]
其中，开发文件(develop)用于存储在开发阶段，即开发环境下的环境文件，开发环境下的环境文件可以包括待部署的环境文件(config)和软件环境文件(kubeconfig)，待部署的环境文件(config)各yaml文件(《service》-configmap.yaml、《service》-deployment.yaml和《service》-serviceyaml)用于存储目标微服务在开发环境下对应的资
源对象等，软件环境文件(kubeconfig)用于存储kubernetes软件的环境配置信息。
[0136]
生产文件(production)用于存储在生产阶段，即生产环境下的环境文件，生产环境下的环境文件可以包括待部署的环境文件(config)和软件环境文件(kubeconfig)，待部署的环境文件(config)各yaml文件(《service》-configmap.yaml、《service》-deployment.yaml和《service》-serviceyaml)用于存储目标微服务在生产环境下对应的资源对象等，软件环境文件(kubeconfig)用于存储kubernetes软件的环境配置信息。
[0137]
测试文件(production)用于存储在测试阶段，即测试环境下的环境文件，测试环境下的环境文件可以包括待部署的环境文件(config)和软件环境文件(kubeconfig)，待部署的环境文件(config)各yaml文件(《service》-configmap.yaml、《service》-deployment.yaml和《service》-serviceyaml)用于存储目标微服务在测试环境下对应的资源对象等，软件环境文件(kubeconfig)用于存储kubernetes软件的环境配置信息。
[0138]
例如，开发文件、生产文件和测试文件中的《service》-configmap.yaml可以用于存储微服务(应用)的配置信息，用来描述应用的配置文件，其是k8s中一种规范的资源对象文件。例如，调用k8s的接口创建《service》-configmap.yaml中描述的应用配置对象，就会在k8s中为应用创建一个配置文件，供应用使用。
[0139]
开发文件、生产文件和测试文件中的《service》-deployment.yaml用于描述微服务在k8s中部署如何部署，比如使用的镜像文件，应用的实例，应用的启动命令启动参数，其是k8s的一种规范的资源对象文件。例如，调用k8s的接口创建该文件描述的应用部署对象，就会在k8s中创建出指定数量的应用实例。
[0140]
开发文件、生产文件和测试文件中的《service》-serviceyaml用于描述访问应用入口等，其是k8s的一种规范的资源对象文件。例如，调用k8s的接口，即可任意创建这个文件中描述的服务对象。
[0141]
配置文件(pkg)用于存储用户自定义的代码文件。
[0142]
其他文件(xxxx.go)用于存储微服务部署过程中的其他文件。
[0143]
其中，配置文件存放在微服务的代码仓库中，与代码一起做版本控制。
[0144]
辅助参数和环境参数的格式示例如下：
[0145][0146][0147]
其中，##为程序代码的解释符号，##后面的内容为所在行代码的解释。
[0148]
可以在构建文件(dockerfile)中编写代码编译的步骤，从而实现在容器中使用docker的多阶构建特性标准化代码的编译步骤，从而屏蔽各微服务编译时所依赖的环境。
[0149]
在制作镜像文件时，第一阶段编译代码，编译后的文件用于第二阶段制作镜像文件。其中，使用docker镜像作为交付产物，应用容器标准化了应用的交付物。
[0150]
现以泰克顿(tekton)作为ci工具为例，对通过部署流水线完成微服务的部署过程予以介绍。
[0151]
其中，在tekton定义了多个kubernetes资源对象，包括：
[0152]
作业(task)：用于定义微服务部署所需每一个步骤。其中，一个步骤对应一个task。例如，task1定义了拉取代码的步骤，task2定义了制作镜像文件的步骤，task3定义了环境部署的步骤。
[0153]
作业运行(taskrun)：用于描述在微服务部署的各个阶段，运行哪个task。
[0154]
流水线(pipeline)：用于定义微服务部署所需的所有task，以及各task之间的运行逻辑关系。例如，一个流水线可以包括上述task1、task2和task3，在执行完task1后，执行
task2，在执行完task2之后执行task3。
[0155]
流水线运行(pipelinerun)：用于定义指示tekton去运行流水线包括的任务。
[0156]
流水线资源(pipelineresource)：定义任务的输入和输出，以及代码、要部署的kubernetes(也可以称为k8s)环境信息等。例如，在多人合作开发时会为代码库创建至少一个分支，每个分支对应的是不同的环境，比如开发分支对应的是开发环境，测试分支对应的是测试或者预生产环境，生产分支对应的是生产环境，根据不同分支将应用部署到不同的环境中。
[0157]
图4示意了一种电子设备的内部数据流向图。
[0158]
如图4所示，电子设备接收用户提交的微服务的代码，将代码文件提交至代码仓库401(gerrit)的暂存分支，待评审通过后在网络端(web端)合并到库分支后产生事件(event)，电子设备通过事件采集器402(gerrit-event)(也可以称为事件采集软件)采集、解析事件后，将解析的结果传递给流水线监听器403(pipeline-listener)，电子设备通过pipeline-listener403解析event中的代码仓库的信息，为该微服务部署创建pipelinerun对象，电子设备通过tekton404根据该piplinerun启动任务405(pod)，然后在pod内执行拉取代码、代码的编译、制作镜像文件、应用部署和代码度量统计的操作，并将制作完成的镜像文件统一存储到镜像仓库406(harbor)中的指定位置。在部署流水线的部署环节会根据代码中的配置文件包括的参数项将镜像文件部署到对应的开发或者是集成测试环境中，将微服务的度量统计信息统一收集并存储到分析引擎407(elasticsearch)集群中，并通过图表展示度量信息。
[0159]
具体的，如图5所示，该过程可以描述为以下步骤：
[0160]
s501、电子设备编写微服务的程序代码，将程序代码存储于程序代码文件，并编写构建文件。
[0161]
电子设备在本地编写微服务的程序代码，在代码目录中按照目录结构的规定，将微服务的程序代码放置于程序代码文件，并根据需求编写构建文件dockerfile。
[0162]
s502、电子设备放置各环境文件。
[0163]
电子设备在代码目录中按照目录结构的规定，在deploy目录下放置各环境的kubernetes中的kubeconfig文件和应用yaml文件。
[0164]
s503、电子设备配置辅助参数和环境参数，并按照目录结构的规定放置于配置文件。
[0165]
在电子设备在代码目录中按照目录结构的规定，定义好镜像文件的存储路径，镜像文件的名称，以及要部署的环境和yaml文件；并放置于deploy-config文件中。
[0166]
s504、电子设备提交代码。
[0167]
电子设备将微服务的代码提交至代码仓库的暂存分支，待代码合并后，通过事件采集器采集到代码合并的事件，并将该事件传递给触发器。
[0168]
s505、电子设备创建流水线运行对象。
[0169]
电子设备通过触发器根据事件内容采用tekton软件创建流水线运行对象pipelinerun的对象任务的描述。
[0170]
其中，该描述包括代码仓库的标识等等。
[0171]
s506、电子设备根据流水线运行对象和部署流水线创建微服务的任务。
[0172]
电子设备通过tekton根据pipelinerun和通用的部署流水线创建该微服务的pod。
[0173]
s507、电子设备运行微服务的任务。
[0174]
通过微服务的任务的运行，电子设备实现拉取代码，编译代码、制作镜像文件，并制作完成的镜像推送到镜像仓库中的指定位置。
[0175]
s508、电子设备将镜像文件部署到目标环境中。
[0176]
电子设调用deploy目录下存放的kubeconfig和yaml中存放的微服务的环境信息，并将镜像文件与该环境信息关联。
[0177]
s509、电子设备统计微服务的度量信息。
[0178]
电子设备统计微服务的度量信息，度量信息可以包括：部署时间、待部署的环境。电子设备将微服务的度量信息存储到elasticsearch中，以使用户可以通过表格查看研发度量信息。
[0179]
综上所述，与jenkins方案相比，tekton方案有以下优势：
[0180]
第一、占用系统资源少。
[0181]
在占用系统资源方面，jenkins是基于java语言开发的，体积庞大，jenkins在部署kubernetes微服务时，依赖外部插件，运行时占用系统资源高。tekton是基于go语言开发的，是一款轻量级的ci/cd框架，且基于kuberentes的自定义资源类型(custom resource definition，crd)，专注于kuberentes应用的部署，组件少，概念少，运行时占用系统资源少。
[0182]
第二、数据高可用。
[0183]
在数据高可用方面，jenkins的数据都是存储在主(master)节点上，而master节点是单节点，所以存在数据丢失的风险。tekton的数据是以kubernetes的crd方式存储在集群中，保证了数据的高可用。
[0184]
第三、管理与维护简单。
[0185]
在管理与维护多个微服务对应的技术栈不同，jenkins要根据不同的微服务所使用的语言和构建环境，编写不同的构建脚本，搭建不同的部署流水线。本方案中使用了docker镜像的多阶构建，使用docker镜像作为交付物和基于kuberentes部署应用，屏蔽了不同技术栈的微服务单元在编译、打包和部署方面的差异，实现了通过一个部署流水线实现多个微服务的部署，简化了管理和使用。
[0186]
图6为本技术实施例的一种信息处理装置的结构示意图，如图6所示，信息处理装置600可以包括获取模块601、配置模块602和部署模块603。其中：
[0187]
获取模块601，用于获取配置文件的参数项，所述配置文件复用于至少两个微服务。
[0188]
配置模块602，用于基于所述配置文件的参数项，配置目标微服务的参数项信息，得到所述目标微服务对应的目标配置文件。
[0189]
部署模块603，用于基于所述目标配置文件和所述目标微服务的程序代码运行部署流水线，以部署所述目标微服务。
[0190]
在一些实施例中，所述部署模块603具体用于：
[0191]
根据所述目标配置文件、所述目标微服务的程序代码和所述部署流水线创建至少一个任务；
[0192]
运行所述至少一个任务，以部署所述目标微服务。
[0193]
在一些实施例中，所述配置文件的参数项包括：环境参数项；配置模块602，用于：
[0194]
在所述配置文件的所述环境参数项中，配置所述目标微服务的环境参数，得到所述目标配置文件包括的目标环境参数，所述目标环境参数用于表征所述目标微服务的待部署的环境。
[0195]
在一些实施例中，部署模块603，具体用于：
[0196]
获取所述目标微服务的程序代码文件；
[0197]
根据所述目标微服务的程序代码文件生成目标镜像文件；
[0198]
将所述目标镜像文件部署到所述目标环境参数所执行的目标环境中。
[0199]
在一些实施例中，所述配置文件的参数项还包括辅助参数项，配置模块602还用于：
[0200]
在所述配置文件的所述辅助参数项中，配置所述目标微服务的辅助参数，得到所述目标配置文件包括的目标辅助参数；所述目标辅助参数用于指向所述目标微服务对应的目标镜像文件的位置；
[0201]
所述运行所述至少一个任务，以部署所述目标微服务，还包括：
[0202]
将所述目标镜像文件存储于所述目标辅助参数指向的位置。
[0203]
在一些实施例中，所述配置文件的参数项还包括构建参数项，配置模块602还用于：
[0204]
在所述配置文件的所述构建参数项中，配置所述目标微服务的构建参数，得到所述目标配置文件包括的目标构建参数；所述目标构建参数用于根据所述目标微服务的代码生成所述目标镜像文件；
[0205]
部署模块603在执行，所述根据所述目标微服务的程序代码生成目标镜像文件，包括：
[0206]
根据所述目标构建信息，将所述目标微服务的程序代码进行编译；
[0207]
将编译后的代码进行容器封装；
[0208]
根据封装后的代码文件生成所述目标镜像文件。
[0209]
在一些实施例中，所述配置文件的参数项还包括构建参数项，配置模块602还用于：
[0210]
在所述配置文件的所述构建参数项中，配置所述目标微服务的构建参数，得到所述目标配置文件包括的目标构建参数；所述目标构建参数用于根据所述目标微服务的代码生成所述目标镜像文件；
[0211]
部署模块603在执行，所述根据所述目标微服务的程序代码生成目标镜像文件，包括：
[0212]
根据所述目标构建信息，将所述目标微服务的程序代码进行容器封装，
[0213]
根据封装后的代码文件生成所述目标镜像文件。
[0214]
需要说明的是，本技术实施例提供的信息处理装置包括所包括的各单元，可以通过电子设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(cpu，central processing unit)、微处理器(mpu，micro processor unit)、数字信号处理器(dsp，digital signal processor)或现场可编程门阵列(fpga，
field-programmable gate array)等。
[0215]
以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本技术装置实施例中未披露的技术细节，请参照本技术方法实施例的描述而理解。
[0216]
需要说明的是，本技术实施例中，如果以软件功能模块的形式实现上述的信息处理方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本技术各个实施例所述方法的全部或部分。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read only memory，rom)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本技术实施例不限制于任何特定的硬件和软件结合。
[0217]
对应地，本技术实施例提供一种电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述实施例中提供的信息处理方法中的步骤。
[0218]
对应地，本技术实施例提供一种存储介质，也就是计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中提供的信息处理方法中的步骤。
[0219]
这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本技术存储介质和设备实施例中未披露的技术细节，请参照本技术方法实施例的描述而理解。
[0220]
需要说明的是，图7为本技术实施例电子设备的一种硬件实体示意图，如图7所示，所述电子设备700包括：一个处理器701、至少一个通信总线702、用户接口703、至少一个外部通信接口704和存储器705。其中，通信总线702配置为实现这些组件之间的连接通信。其中，用户接口703可以包括显示屏，外部通信接口704可以包括标准的有线接口和无线接口。
[0221]
存储器705配置为存储由处理器701可执行的指令和应用，还可以缓存待处理器701以及电子设备中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(flash)或随机访问存储器(random access memory，ram)实现。
[0222]
应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本技术的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一些实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本技术的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
[0223]
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有
的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
[0224]
在本技术所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
[0225]
上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
[0226]
另外，在本技术各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
[0227]
本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(read only memory，rom)、磁碟或者光盘等各种可以存储程序代码的介质。
[0228]
或者，本技术上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本技术各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、rom、磁碟或者光盘等各种可以存储程序代码的介质。
[0229]
以上所述，仅为本技术的实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。