CN114840226A

CN114840226A - Sa-based management system and method for upgrading version of micro-service

Info

Publication number: CN114840226A
Application number: CN202210454410.8A
Authority: CN
Inventors: 邵林坚; 宋杨; 秦钢
Original assignee: Hangzhou Diji Intelligent Technology Co ltd
Current assignee: Hangzhou Diji Intelligent Technology Co ltd
Priority date: 2022-04-27
Filing date: 2022-04-27
Publication date: 2022-08-02

Abstract

The invention relates to the technical field of Internet of things, in particular to a management system and a method for performing micro-service upgrade versions based on sa, which comprises the following steps: entering a packaging program, and constructing a rear-end docker image file, a front-end docker image file, a helm Chart package file and an offline installation package file to further form an SA package; uploading the SA packet, decompressing on an OS (operating system), and acquiring the content of a manifest file and system information of an installation environment; loading the mirror image, and registering relevant information of the application in a registry service of an instruction set operating system; and cleaning the jobs created by the old version, executing the installation command, updating the pod after executing the SQL, and successfully installing the health check interface after the health check interface normally responds. The invention effectively solves the problem that the whole application upgrading fails after a certain service upgrades the wrong version under the condition of upgrading a plurality of services. The simplicity of service upgrading is ensured, and the change cost brought by service upgrading is reduced.

Description

Sa-based management system and method for upgrading version of micro-service

Technical Field

The invention relates to the technical field of Internet of things, in particular to a management system and method for performing micro-service upgrade versions based on sa.

Background

A set of system environment is deployed for a user P1 in the existing operating system of the Internet of things; the customer needs to upgrade the commonly used function 1 and function n.

However, technicians usually directly operate the micro-services and upgrade the images of the related micro-services. Since the technical capabilities of the clients are not uniform and it is unknown which micro-services provide the functions, the scheme for directly upgrading the function 1 and the function n by updating the micro-services has high operation difficulty and is prone to errors, and thus a management system and a method for upgrading versions of the micro-services based on sa are provided.

Disclosure of Invention

Aiming at the defects of the prior art, the invention discloses a management system and a management method for upgrading versions of micro-services based on sa, which are used for solving the problems that the technical capability of customers is not uniform, the functions are not known to be provided by which micro-services, and the scheme for directly upgrading the function 1 and the function n by updating the micro-services is difficult to operate and easy to make mistakes.

The invention is realized by the following technical scheme:

in a first aspect, the present invention provides a management method for updating versions of microservice based on sa, including the following steps:

s1, initializing and entering a packaging program, and constructing a back-end docker image file, a front-end docker image file, a helm Chart package file and an offline installation package file to further form an SA package;

s2 uploads the SA package constructed in S1, and carries out decompression on the OS to obtain the system information of the manifest file content and the installation environment;

s3 loading mirror image, and registering relevant information of application in the register center service of the instruction set operating system;

s4 clears the jobs created by the old version, executes the installation command, updates the pod after executing the SQL, and successfully installs the health check interface after the health check interface normally responds.

Furthermore, in the method, when the Helm Chart package is constructed, various parameters in the file are replaced, and the Chart.yaml file and the values.yaml file are modified.

Furthermore, the method comprises the following steps when the offline installation integration package is constructed:

preparing an integration package working directory;

preparing a Docker mirror image file;

preparing a HelmChart package file;

preparing an application icon file;

preparing a manifest file;

json file is modified;

and constructing an integration package.

Further, in the method, the uploading of the SA packet supports fragment uploading, which specifically includes:

analyzing the MD5 value of the acquired file at the browser end, sending the MD5 value after the file analysis to the back end to judge whether the file is uploaded before,

the request server side judges whether the file is uploaded, and if the file is uploaded, the file address is directly returned;

if the last uploaded fragment index is returned after the previous uploading, the last uploading is continued from the index, a single fragment is uploaded each time, a fragment merging request is initiated to the back end after all the fragments are uploaded, and the file storage address is returned to the front end after all the fragments are successfully merged.

Furthermore, in the method, the obtaining of the manifest file content and the system information of the installation environment includes the following steps:

whether an application code identical to the application code of the upgrade package exists in the system or not is judged, if yes, the next judgment is carried out, and if not, the upgrade process is interrupted;

comparing the compatible version field of the installation package with the version number of the installed application in the system, entering next judgment when the version number of the installed application is contained in the compatible version number, and interrupting the upgrading process if the version number of the installed application is not contained in the compatible version number;

and acquiring the version numbers of all services in the system, comparing the dependent services of the upgrade package with the existing services in the system, entering next judgment when the service version numbers are consistent, and interrupting the upgrade process if the service version numbers are inconsistent.

Furthermore, in the method, in the registry service of the instruction set operating system, the relevant information of the registered application includes the appcode and the version number.

Furthermore, in the method, whether the service is normally started is monitored through the health check interface, and if the health check interface normally responds, the installation is successful.

Further, the method may include monitoring for a service time of less than 10 minutes via the health check interface.

In a second aspect, the present invention provides a management system for performing a microservice upgrade based on sa, including a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, where the memory is coupled to the processor, and the processor executes the computer program to implement the steps of the management method for performing a microservice upgrade based on sa according to the first aspect.

The invention has the beneficial effects that:

the invention takes a plurality of micro-services as an independent unit 'SA' to carry out unified development and management, and cooperates with an SA version control mechanism to clarify the external services depending on the SA version, thereby effectively solving the problem that the application cannot normally run due to lack of assemblies or depending services after the micro-services are upgraded and improving the reliability of the services.

The invention effectively solves the problem that the whole application upgrading fails after a certain service upgrades the wrong version under the condition of upgrading a plurality of services. The simplicity of service upgrading is ensured, and the change cost brought by service upgrading is reduced.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a schematic step diagram of a method for managing an upgrade version of a microservice based on sa.

Detailed Description

In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

Example 1

The embodiment provides a management method for updating versions of micro-services based on sa, which comprises the following steps:

When a plurality of micro services are upgraded, the micro services are packaged into one application, and in an environment to be upgraded, an installation package is freely selected according to customer requirements to replace a mirror image of the micro services.

In this embodiment, a plurality of related services are packaged, the SA includes a service image, SQL, and a description file, and the system determines whether to adapt to other SAs according to the description file. If the service is matched with the service, the service can be updated corresponding to the mirror image and the database of the service; if not, the update cannot be performed. The SAs are typically aggregated in a business capability dimension.

The application package of the embodiment contains microservices, SQL and configuration information. When a plurality of environments are managed, the efficiency and the usability of service upgrading are greatly improved, and the individuation of the client environment is kept.

Example 2

In a specific implementation level, this embodiment provides a packing method, including the following steps:

the preparation before the construction is carried out in the embodiment, the jar file compiled at the back end is put into the root directory of the revops folder. And (4) putting the static file compiled at the front end into the ui directory under the vops.

Entering the profiles folder, executing the command mkdir-p release & & rm-rf release, creating and clearing the release directory.

The embodiment constructs a back-end mirror image, and all commands below are executed under the savops root directory

Back end packed commands

$ REPO _ NAME is replaced with your own warehouse address, or a default address harbor.

$ SERVICE _ NAME is replaced with your application NAME.

$ SERVICE _ VERSION is replaced with your application VERSION.

$ JAR _ FILE is replaced with your JAR package name.

After the packaging is completed, the successfully constructed image file needs to be saved under a release directory, and the command is executed:

also, the parameters are all replaced according to the content of the first step.

The embodiment constructs a front-end mirror image, and all commands below are executed under a devops root directory;

because of the front-end resource folder, the name must be html. Therefore, you need to rename the static folder that you build successfully to html.

For example, if your folder name is dist, then the command mv ui/dist ui/html can be executed to rename the folder.

The new html folder is then wrapped with the commands tar-zcvf ui/html.

The front end of this embodiment packs the command:

docker build\

-t${REPO_NAME}/${SERVICE_NAME}:${SERVICE_VERSION}\

--build-arg PORT＝${SERVICE_PORT}\

--build-arg JAR_FILE＝"${JAR_FILE}"\

.

1

2

3

4

5

docker save\

-o release/${SERVICE_NAME}-${SERVICE_VERSION}.tar\

${REPO_NAME}/${SERVICE_NAME}:${SERVICE_VERSION}

1

2

3

docker build -t harbor.isyscore.com/application/demo3:v1.0.0--build-arg PORT＝9080.

docker save -o release/demo3-v1.0.0.tar harbor.isyscore.com/application/demo3:v1.0.0

1

$ 2$ { REPO _ NAME } is replaced with your own warehouse address, or the default address harbor.

$ SERVICE _ NAME is replaced with your application NAME.

$ SERVICE _ VERSION is replaced with your application VERSION.

In this embodiment, a hell Chart packet is constructed:

replacing the parameters in the file:

all template files of Helm Chart are located in the Chart _ temp folder. You can copy the template folder for a plurality of times.

Windows and Mac OS X or Linux desktop version users can use the text editor, Linux desktop-less users can use sed or vim

The command(s) is (are) sent,

edit the Chart. yaml and values. yaml files under the Chart _ temp folder.

Modify chart. yaml file:

replace $ { chart _ name } with your application name.

Replace both $ { version } and $ { app _ version } with your application version number.

Replace $ { app _ icon } with icon for your application, if not, with a null character.

Modify values. yaml file:

docker build\

-t${REPO_NAME}/${SERVICE_NAME}-ui:${SERVICE_VERSION}\

--build-arg UI_FILE＝./ui/html.tar\

-f./ui/Dockerfile\

.

1

2

3

4

5

docker save\

-o release/${SERVICE_NAME}-${SERVICE_VERSION}-ui.tar\

${REPO_NAME}/${SERVICE_NAME}-ui:${SERVICE_VERSION}

1

2

3

docker build -t harbor.isyscore.com/application/demo3-ui:v1.0.0-f./ui/Dockerfile.

docker save -o release/demo3-v1.0.0-ui.tar harbor.isyscore.com/application/demo3-ui:v1.0.0

1

2 replace $ { repo _ name } with your warehouse address, or use the default address harbor.

Replace $ { host } with a null character.

Replace $ project _ name, $ { image _ name } with the name of your application.

Replace $ project _ dbname with the data name of your application.

Replace $ project _ dbusername with the data username of your application.

Replace $ project _ dbpasscode with the database password of your application.

Replace $ { port }, $ { service _ port } with the service port number of your application.

Replace $ { uiimage _ name } with the name of your application plus-ui suffix.

Replace $ { image _ tag }, $ { uiimage _ tag } with the version number of your application.

If your application needs to inject a start parameter, such as-dsspring.

Replace $ { env _ javaops } with the parameter you need to inject, and if not, replace with an empty string.

This implementation packing file

Saving the replaced file, and then executing the command:

$ SERVICE _ NAME is replaced with your application NAME.

$ SERVICE _ VERSION is replaced with your application VERSION.

The outgoing Chart package can be moved under the release folder using the following commands:

helm package--app-version${SERVICE_VERSION}--version${SERVICE_VERSION}chart_temp

1 likewise, the parameters are all replaced according to the content of the first step.

Example 3

In a specific implementation level, this embodiment provides a method for constructing an offline installation integration package, including the following steps:

preparing a working catalog of integration packages

Executing the command, creating a working directory:

$ SERVICE _ NAME is replaced with your application NAME.

$ SERVICE _ VERSION is replaced with your application VERSION.

Preparing a Docker image file

Executing a command, creating an integrated Docker image:

$ SERVICE _ NAME is replaced with your application NAME.

$ SERVICE _ VERSION is replaced with your application VERSION.

Then, a command mv allInOne. tar release/$ { WORK _ DIR } is executed, and the successfully constructed file is moved to the working directory.

$ WORK _ DIR is replaced with your working directory, such as demo 3-v1.0.0-installer.

Preparing a HelmChart package file

In the step of building the Helm Chart package, the Helm Chart package is successfully built, and in the step, the file needs to be copied to a working directory.

You can execute the following command to complete the operation:

mv${SERVICE_NAME}-${SERVICE_VERSION}.tgz release/

1

helm package --app-version v1.0.0 --version v1.0.0 chart_temp

mv demo3-v1.0.0.tgz release/

1

2

mkdir -p release/${SERVICE_NAME}-${SERVICE_VERSION}-installer

1

mkdir -p release/demo3-v1.0.0-installer

1

docker save\

-o allInOne.tar\

"${REPO_NAME}/${SERVICE_NAME}:${SERVICE_VERSION}"\

"${REPO_NAME}/${SERVICE_NAME}-ui:${SERVICE_VERSION}"

1

2

3

4

docker save\

-o allInOne.tar\

"harbor.isyscore.com/application/demo3:v1.0.0"\

"harbor.isyscore.com/application/demo3-ui:v1.0.0}"

1

2

3

4

mv allInOne.tar release/demo3-v1.0.0-installer

replace 1$ { SERVICE _ NAME } with your application NAME.

$ SERVICE _ VERSION is replaced with your application VERSION.

Preparing an application icon file

If you are building, you have used the-i parameter or have entered the application's icon connection URL, this step can be omitted.

If you do not enter the parameters, you can put your application icon file under the work directory and rename to $ { SERVICE _ CODE }. And packaging the icon file into the integration package during construction.

This embodiment preferably performs, for example, your icon file is icon. png, your SERVICE _ CODE is demo3-a380, and your working directory is demo 3-v1.0.0-installer. Then you need to copy the file icon. png under folder demo3-v1.0.0-installer, and then rename the file icon. png to demo3-a380. png.

Preparing manifest file

Json, a template file in a manifest folder, can be copied into your work directory.

Command, edit a manifest.

Json file is modified

Replace $ app _ Code with your application Code, such as demo3-a380.

Replace $ app _ name with your application name, such as demo 3.

Replace $ { app _ version } with your application version, such as v1.0.0.

Replace $ Chart _ name with your Helm Chart package name, such as demo3-v1.0.0. tgz.

Replace $ repo _ name with your warehouse name, or use the default address harbor.

Replace $ { port } with your application port number, e.g., 8080.

Replace $ icon with your application icon name or URL, such as demo3-a380. png.

Constructing a unified bag

The integration package may be constructed using the following commands:

cp release/"${SERVICE_NAME}-${SERVICE_VERSION}".tgz release/${WORK_DIR}

1

cp release/demo3-v1.0.0.tgz release/demo3-v1.0.0-installer

$ 1 { WORK _ DIR } is your working directory, e.g., demo 3-v1.0.0-installer.

Then, the constructed integration package is moved to the release folder.

By this point, the entire dehaps operation is complete. And viewing the release folder to obtain the final front-end mirror image file, the final rear-end mirror image file, the Helm Chart file and the offline installation package file.

Example 4

In a specific implementation aspect, this embodiment provides an installation step, which specifically includes:

the present embodiment installs the SA package on the OS. Uploading an SA package, supporting fragment uploading, and comprising the following steps:

analyzing and acquiring an MD5 value (as a unique key value of the file) of the file at a browser end, sending the MD5 value after the file is analyzed to a back end, and judging whether the file is uploaded before;

The embodiment decompresses the SA packet and acquires the manifest file content and the system information of the installation environment, and the method comprises the following steps:

and if the application code identical to the application code of the upgrade package exists in the system, entering next judgment, and if the application code does not exist, interrupting the upgrade process.

Comparing the compatible version field of the installation package with the version number of the installed application in the system, entering next judgment when the version number of the installed application is contained in the compatible version number, and interrupting the upgrading process if the version number of the installed application is not contained in the compatible version number

And (4) after all the judgment results pass, executing the step 4.

In the embodiment, the mirror image is loaded, and the relevant information of the application, such as appcode, version number and the like, is registered in the registry service of the instruction set operating system.

The embodiment cleans the jobcreated by the old version; and executing the installation command, and updating the pod after the SQL is executed.

In this embodiment, whether the service is normally started is monitored through the health check interface, the time is limited to 10 minutes, and if the health check interface normally responds, the installation is successful.

Example 5

The embodiment provides a management system for performing a microservice upgrade version based on sa, which includes a processor, a memory and a computer program stored in the memory and configured to be executed by the processor, wherein the memory is coupled to the processor, and when the processor executes the computer program, the steps of the management method for performing a microservice upgrade version based on sa are implemented.

In summary, the invention takes a plurality of micro-services as an independent unit "SA" to perform unified development and management, and cooperates with the SA version control mechanism to clarify the external services on which the SA version depends, thereby effectively solving the problem that the application cannot normally operate due to lack of components or dependent services after the micro-services are upgraded, and increasing the reliability of the services.

The above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.

Claims

1. A management method for updating versions of micro-services based on sa is characterized by comprising the following steps:

2. The management method for the sa-based version of the microservice upgrade, as claimed in claim 1, wherein in the method, when constructing the hell Chart package, parameters in the file are replaced, and the Chart.

3. The method for managing the sa-based microservice upgrade version, according to claim 1, wherein the method comprises the following steps when constructing the offline installation integration package:

preparing an integration package working directory;

preparing a Docker mirror image file;

preparing a HelmChart package file;

preparing an application icon file;

preparing a manifest file;

json file is modified;

and constructing an integration package.

4. The method according to claim 1, wherein in the method, the SA package is uploaded and fragment uploading is supported, specifically as follows:

5. The method for managing the sa-based microservice upgrade version according to claim 1, wherein the method for obtaining the manifest file content and the system information of the installation environment comprises the following steps:

6. The method of claim 1, wherein the information related to the registered application in the registry service of the instruction set operating system comprises an appcode and a version number.

7. The sa-based management method for upgrade versions of microservice, as claimed in claim 1, wherein said method monitors whether the service is started normally through the health check interface, and if the health check interface responds normally, the installation is successful.

8. The sa-based version of microservice upgrade management method as claimed in claim 7, wherein the method is characterized in that the service time is monitored through the health check interface for less than 10 minutes.

9. A sa-based microservice upgrade version management system comprising a processor, a memory and a computer program stored in the memory and configured to be executed by the processor, the memory being coupled to the processor and the processor implementing the method steps of the sa-based microservice upgrade version management method according to any of claims 1 to 8 when executing the computer program.