Micro-service publishing method and device, equipment, storage medium and program product

Abstract

The invention discloses a micro-service publishing method and device, equipment, a storage medium and a computer program product, and relates to the technical field of computers, and the method comprises the steps: obtaining a micro-service code of a to-be-published micro-service, and carrying out the compiling and packaging of the micro-service code, and obtaining a compiled code; determining a target server node of a target server cluster from the server clusters, and obtaining preset production environment configuration information corresponding to the target server node; adjusting configuration information in the compiled code based on the production environment configuration information to obtain a target code; the method comprises the steps that a target server node receives a target code, mirror image packaging is carried out on the target code to obtain a micro-service mirror image, the micro-service mirror image is released to a Docker private server, the target server node pulls the micro-service mirror image from the Docker private server, a current container instance is started based on the micro-service mirror image, and micro-service provided by the micro-service mirror image is operated in the current container instance. According to the invention, the difficulty of micro-service release management is reduced, and the efficiency of micro-service release configuration management is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a microservice publishing method, apparatus, device, storage medium, and computer program product. Background Art

[0002] With the rapid development of mobile Internet technology, App (Application) has become an indispensable part of people's daily life. App release, that is, the process of deploying the developed application to the server or application store for users to download and use, is a key link in the software development cycle. Under the microservice architecture, App is usually composed of multiple independent services, each of which can be independently developed, deployed and expanded. This architectural model greatly improves the flexibility and scalability of the system. At present, App release mainly relies on automated deployment tools and continuous integration / continuous deployment (CI / CD) pipelines. Automated deployment tools such as Jenkins and Ansible can automatically perform a series of operations such as code pulling, compiling and packaging, and deploying to the server, which significantly improves the release efficiency. At the same time, the CI / CD pipeline connects the code submission, construction, testing, deployment and other links in series, realizing a seamless connection from code to production environment.

[0003] However, in the process of large-scale cluster release of microservices, each service requires independent configuration information. As the number of services increases, the management and synchronization of configuration information becomes increasingly complex, configuration management is difficult, and configuration management efficiency is low.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0005] The main purpose of this application is to provide a microservice publishing method, device, equipment, storage medium and computer program product, aiming to solve the technical problems of high configuration management difficulty and low configuration management efficiency in the microservice publishing process.

[0006] To achieve the above objectives, the present application proposes a microservice publishing method, the method comprising:

[0007] Obtain the microservice code of the microservice to be released, and compile and package the microservice code to obtain compiled code;

[0008] Determine a target server node of a target server cluster from each server cluster, and obtain preset production environment configuration information corresponding to the target server node;

[0009] Adjusting the configuration information in the compiled code based on the production environment configuration information to obtain a target code;

[0010] The target code is image-packaged to obtain a microservice image, and the microservice image is published to a Docker private server, wherein the target server node pulls the microservice image from the Docker private server, starts a current container instance based on the microservice image, and runs the microservice provided by the microservice image in the current container instance.

[0011] In one embodiment, after the step of packaging the target code into a microservice image and publishing the microservice image to a Docker private server, the step further includes:

[0012] Perform health checks on the microservices running on the target server node;

[0013] When the microservice running on the target server node passes the health check, it is determined that the microservice release is completed.

[0014] In one embodiment, the step of performing health detection on the microservice running on the target server node includes:

[0015] Sending a heartbeat detection signal to the target server node according to a preset period;

[0016] If no response information from the target server node is received within the preset time length of sending the heartbeat detection, it is determined that the microservice running on the target server node has failed the health detection;

[0017] If the response information is received within the preset time period, it is determined that the microservice running on the target server node passes the health check.

[0018] In one embodiment, after the step of performing health detection on the microservice running on the target server node, the step further includes:

[0019] When the microservice running on the target server node fails the health check, obtaining node information of the target server node;

[0020] An abnormality alarm is generated based on the node information, and the abnormality alarm information is output through a preset communication channel.

[0021] In one embodiment, after the step of packaging the target code into a microservice image and publishing the microservice image to a Docker private server, the step further includes:

[0022] If an exception occurs to the microservice image, determine the historical image corresponding to the microservice image from the Docker private server;

[0023] The current container instance is deleted in the target server node, wherein the target server node pulls the historical image from the Docker private server, starts a historical container instance based on the historical image, and runs a microservice provided by the historical image in the historical container instance.

[0024] In one embodiment, the step of obtaining the microservice code of the microservice to be released, and compiling and packaging the microservice code to obtain the compiled code includes:

[0025] Obtain the microservice code of the microservice to be released, and determine the dependencies of the microservice to be released;

[0026] Dependencies are added to the microservice code to obtain target code, and the target code is compiled and packaged to obtain compiled code.

[0027] In addition, to achieve the above purpose, the present application also proposes a microservice publishing device, the microservice publishing device comprising:

[0028] An acquisition module is used to acquire the microservice code of the microservice to be released, and compile and package the microservice code to obtain a compiled code;

[0029] A configuration module, used to determine a target server node of a target server cluster from each server cluster, and obtain preset production environment configuration information corresponding to the target server node;

[0030] A determination module, configured to adjust the configuration information in the compiled code based on the production environment configuration information to obtain a target code;

[0031] A publishing module is used to image-package the target code to obtain a microservice image, and publish the microservice image to a Docker private server, wherein the target server node obtains the microservice image from the Docker private server, uses the microservice image to start a Docker container, and runs the microservice image.

[0032] In addition, to achieve the above-mentioned purpose, the present application also proposes a microservice publishing device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the microservice publishing method described above.

[0033] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the microservice publishing method described above are implemented.

[0034] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the microservice publishing method described above are implemented.

[0035] In the present application, the microservice code of the microservice to be released is obtained, and the microservice code is compiled and packaged to obtain the compiled code; the target server node of the target server cluster is determined from each server cluster, and the preset production environment configuration information corresponding to the target server node is obtained; the configuration information in the compiled code is adjusted based on the production environment configuration information to obtain the target code; the target code is image-packaged to obtain a microservice image, and the microservice image is published to a Docker private server, wherein the target server node pulls the microservice image from the Docker private server, starts the current container instance based on the microservice image, and runs the microservice provided by the microservice image in the current container instance.

[0036] This application centrally manages the production environment configuration information and injects the configuration information during the packaging stage, avoiding the tedious process of manually configuring or synchronizing configuration information on multiple server nodes. It handles the configuration information management issues of microservices during the release process in an automated and centralized manner, thereby improving the accuracy and efficiency of configuration management. In addition, this application handles the acquisition, injection, and image packaging of configuration information in an automated manner, reducing the risk of human error, thereby improving the accuracy of configuration management. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0038] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0039] Figure 1 A flowchart of the first embodiment of the microservice publishing method of this application is provided;

[0040] Figure 2 A flow chart of the second embodiment of the microservice publishing method of this application;

[0041] Figure 3 A brief flowchart of a microservice publishing method provided in one embodiment of the present application;

[0042] Figure 4 This is a schematic diagram of the module structure of the microservice publishing device in an embodiment of the present application;

[0043] Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the microservice publishing method in the embodiment of the present application.

[0044] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0045] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0046] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0047] The main solution of the embodiment of the present application is: obtain the microservice code of the microservice to be released, and compile and package the microservice code to obtain the compiled code; determine the target server node of the target server cluster from each server cluster, and obtain the preset production environment configuration information corresponding to the target server node; adjust the configuration information in the compiled code based on the production environment configuration information to obtain the target code; image-package the target code to obtain a microservice image, and publish the microservice image to the Docker private server, wherein the target server node pulls the microservice image from the Docker private server, starts the current container instance based on the microservice image, and runs the microservice provided by the microservice image in the current container instance.

[0048] In this embodiment, for ease of description, the following description is made with the microservice publishing device as the execution entity.

[0049] With the rapid development of mobile Internet technology, Apps have become an indispensable part of people's daily lives. App release, that is, the process of deploying the developed application to the server or application store for users to download and use, is a key link in the software development cycle. Under the microservice architecture, Apps are usually composed of multiple independent services, each of which can be independently developed, deployed and expanded. This architectural model greatly improves the flexibility and scalability of the system. At present, App release mainly relies on automated deployment tools and continuous integration / continuous deployment (CI / CD) pipelines. Automated deployment tools such as Jenkins and Ansible can automatically perform a series of operations such as code pulling, compiling and packaging, and deploying to the server, which significantly improves the release efficiency. At the same time, the CI / CD pipeline connects the code submission, building, testing, and deployment links in series, achieving seamless connection from code to production environment. However, in the process of large-scale cluster release of microservices, each service requires independent configuration information. As the number of services increases, the management and synchronization of configuration information becomes increasingly complex, and the configuration management is difficult and inefficient.

[0050] This application centrally manages the production environment configuration information and injects the configuration information during the packaging stage, avoiding the tedious process of manually configuring or synchronizing configuration information on multiple server nodes. It handles the configuration information management issues of microservices during the release process in an automated and centralized manner, thereby improving the accuracy and efficiency of configuration management. In addition, this application handles the acquisition, injection, and image packaging of configuration information in an automated manner, reducing the risk of human error, thereby improving the accuracy of configuration management.

[0051] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a server, etc., or an electronic device capable of realizing the above functions, a microservice publishing device, etc. The following takes the microservice publishing device as an example to illustrate this embodiment and the following embodiments.

[0052] Based on this, the present application embodiment provides a microservice publishing method, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the microservice publishing method of the present application.

[0053] In this embodiment, the microservice publishing method includes steps S10 to S40:

[0054] Step S10, obtaining the microservice code of the microservice to be released, and compiling and packaging the microservice code to obtain compiled code;

[0055] Get the latest microservice code from the version control system, such as Git, compile and package the code so that it can be deployed to the production environment. It should be noted that compilation is the process of converting source code into executable code, and packaging is the process of packaging the compiled code and its dependencies into a separate package for easy distribution and deployment. It is understandable that by automating the compilation and packaging process, efficiency can be improved and human errors can be reduced.

[0056] Step S20, determining a target server node of a target server cluster from each server cluster, and obtaining preset production environment configuration information corresponding to the target server node;

[0057] In a microservice architecture, services are usually deployed in multiple server clusters. When publishing microservices, you need to determine the target server cluster and the target server nodes in it. Each server node has its own specific production environment configuration information, such as database connection information, API keys, etc. By obtaining production configuration information, you can ensure that the microservice is correctly loaded when it starts, avoiding service unavailability caused by configuration errors.

[0058] Step S30, adjusting the configuration information in the compiled code based on the production environment configuration information to obtain a target code;

[0059] After the compiled code is packaged, the configuration information is replaced with the configuration information of the production environment, which may include modifying configuration files, environment variables, etc., which are not limited here. By adjusting the configuration information, you can ensure that the microservice uses the correct configuration information when it starts, so that the microservice can run normally in the production environment.

[0060] Step S40, image-package the target code to obtain a microservice image, and publish the microservice image to a Docker private server, wherein the target server node pulls the microservice image from the Docker private server, starts the current container instance based on the microservice image, and runs the microservice provided by the microservice image in the current container instance.

[0061] After obtaining the target code, it is packaged into a microservice image, which is an independent executable package that contains the microservice and its dependencies and can be run in any environment that supports Docker. After publishing the microservice image to a Docker private server (such as Docker Registry), the target server node can pull the image from the private server and start a container instance based on the image to run the microservice. It can be understood that through the containerized deployment of microservices, the deployment efficiency and flexibility can be improved, and the scalability and maintainability of microservices can be improved.

[0062] In one feasible implementation, the step S10: obtaining the microservice code of the microservice to be released, and compiling and packaging the microservice code to obtain the compiled code, includes:

[0063] Step S101, obtaining the microservice code of the microservice to be released, and determining the dependencies of the microservice to be released;

[0064] Get the microservice code to be released from the version control system (such as Git) or other storage location, and determine all the dependencies required by the microservice by analyzing the microservice code (such as viewing dependency configuration files such as pom.xml, build.gradle, requirements.txt, etc.). The dependencies may include third-party libraries, frameworks, database drivers, etc., which are not limited here.

[0065] It is understandable that microservice code is the implementation carrier of microservice functions, while dependencies are external resources necessary for the normal operation of microservices. Clarifying the dependencies required by microservices can correctly add and configure these dependencies in subsequent steps to avoid problems caused by missing dependencies or mismatched dependency versions.

[0066] Step S102, adding dependencies to the microservice code to obtain target code, and compiling and packaging the target code to obtain compiled code.

[0067] After determining the dependencies of the microservice, add dependency references to the microservice code (such as by modifying the dependency configuration file), use build tools (such as Maven, Gradle, Python's pip, etc.) to compile and package the microservice code containing the dependency references, and generate compiled code that can run in the target environment (such as JAR files, WAR files, the base layer of Docker images, etc.). It can be understood that adding dependency references provides a basis for the build tool to download and reference external resources.

[0068] This application centrally manages the production environment configuration information and injects the configuration information during the packaging stage, avoiding the tedious process of manually configuring or synchronizing configuration information on multiple server nodes. It handles the configuration information management issues of microservices during the release process in an automated and centralized manner, thereby improving the accuracy and efficiency of configuration management. In addition, this application handles the acquisition, injection, and image packaging of configuration information in an automated manner, reducing the risk of human error, thereby improving the accuracy of configuration management.

[0069] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 2In one embodiment, after the step S30 of packaging the target code into a microservice image and publishing the microservice image to a Docker private server, the step further includes:

[0070] Step S50, performing health detection on the microservice running on the target server node;

[0071] After the microservice is successfully deployed to the target server node and started, a health check is required to ensure that the microservice can provide services normally. Health checks usually include but are not limited to checking the running status of the microservice, port monitoring status, response time, error rate and other key indicators. The specific health check can be performed through specific health check interfaces (such as HTTP / HTTPS endpoints), log analysis, monitoring systems, etc., which are not limited here.

[0072] It is understandable that through regular or real-time health checks, anomalies in the operation of microservices, such as service crashes, response timeouts, etc., can be discovered in a timely manner, so that measures can be taken quickly to repair them, so that microservices are always available and business losses caused by service unavailability can be reduced.

[0073] Step S60, when the microservice running on the target server node passes the health check, it is determined that the microservice release is completed.

[0074] If the microservice passes the test, that is, all key indicators meet the requirements, it is determined that the microservice has been successfully released and can provide services normally. At this time, the corresponding notification mechanism (such as email, SMS, message queue, etc.) can be triggered to notify relevant personnel that the microservice release has been completed. It can be understood that confirming the completion of the microservice release through health testing can ensure that the microservice can run normally in the production environment and reduce the business impact caused by release quality issues.

[0075] In one feasible implementation, the step S50: the step of performing health detection on the microservice running on the target server node includes:

[0076] Step S501, sending a heartbeat detection signal to the target server node according to a preset period;

[0077] In this embodiment, the health check of the microservice is performed by heartbeat detection. Specifically, a heartbeat detection signal is sent to the target server node according to a preset time period (such as every second, every minute, etc.). The heartbeat detection signal includes but is not limited to signals such as network requests. The online status and response capability of the target server node can be verified by the heartbeat detection signal. If the target server node can normally receive and respond to these signals, then it can be considered that the microservice is in a healthy state.

[0078] It is understandable that by regularly sending heartbeat detection signals, the operating status of the target server node can be monitored in real time, potential problems can be discovered in time, and the stability and accuracy of microservice operation and maintenance can be improved.

[0079] Step S502: If no response information of the target server node is received within the preset time length of sending the heartbeat detection, it is determined that the microservice running on the target server node has failed the health detection;

[0080] After sending the heartbeat detection signal, wait for a preset time to receive the response information of the target server node. If there is no response within the preset time, it indicates that the microservice on the target server node may have a fault or anomaly, resulting in failure to respond to the heartbeat detection signal normally. The preset time can be reasonably set according to the actual application scenario and network conditions, and is not limited here.

[0081] It is understandable that by setting a preset duration for microservice responses, problems can be discovered quickly when microservices fail, reducing the duration of business interruptions and ensuring that microservices can be discovered and handled in a timely manner when anomalies occur, thereby improving the reliability of microservice operations.

[0082] Step S503: If the response information is received within the preset time period, it is determined that the microservice running on the target server node passes the health check.

[0083] If the response information of the target server node is successfully received within the preset time, it indicates that the microservice on the target server node is in a normal state and can respond to the heartbeat detection signal normally. The microservice passes the health detection and can continue to provide services.

[0084] In a feasible implementation manner, after the step S50: performing health detection on the microservice running on the target server node, the step further includes:

[0085] Step S70, when the microservice running on the target server node fails the health check, obtaining the node information of the target server node;

[0086] When the microservice health check fails, the node information of the target server node is obtained. The node information is used to characterize the operating status of the target server node, including but not limited to the operating load, configuration details, etc., which are not limited here. It can be understood that the node information provides a detailed snapshot of the microservice operating environment. The operation and maintenance personnel can formulate fault handling strategies based on the node information, reduce misjudgment and blind operation, reduce manual intervention, and improve the efficiency of operation and maintenance work.

[0087] Step S80: Generate an abnormality alarm based on the node information, and output the abnormality alarm information through a preset communication channel.

[0088] After the problem node is determined, an abnormal alarm is generated based on the node information, and the abnormal alarm information is output through a preset communication channel, which can be through various communication channels such as email, text messages, instant messaging tools, etc., which are not limited here.

[0089] In a feasible implementation manner, after the step S40: image packaging the target code to obtain a microservice image, and publishing the microservice image to a Docker private server, the step further includes:

[0090] Step A10: if the microservice image is abnormal, determine the historical image corresponding to the microservice image from the Docker private server;

[0091] During the operation of microservices, if the current microservice image has an exception, such as startup failure, unstable operation, etc., the previously stable running microservice image version (that is, historical image) can be retrieved from the Docker private server to roll back based on the historical image.

[0092] Step A20, deleting the current container instance in the target server node, wherein the target server node pulls the historical image from the Docker private server, starts the historical container instance based on the historical image, and runs the microservice provided by the historical image in the historical container instance.

[0093] Delete the currently running abnormal container instance, and pull the historical image from the Docker private server to start a new container instance, so that the microservice can be re-run based on the historical image. It is understandable that the efficiency and reliability of microservice operation and maintenance can be improved by ensuring the stability and availability of microservices through the rollback mechanism.

[0094] This application centrally manages the production environment configuration information and injects the configuration information during the packaging stage, avoiding the tedious process of manually configuring or synchronizing configuration information on multiple server nodes. It handles the configuration information management issues of microservices during the release process in an automated and centralized manner, thereby improving the accuracy and efficiency of configuration management. In addition, this application handles the acquisition, injection, and image packaging of configuration information in an automated manner, reducing the risk of human error, thereby improving the accuracy of configuration management.

[0095] For example, to help understand the implementation process of the microservice publishing method obtained by combining the above-mentioned embodiment 1 and embodiment 2, please refer to Figure 3 , Figure 3A brief flow chart of a microservice publishing method is provided, specifically:

[0096] Step 1: Pull the code from the code base (gitlab) (that is, obtain the microservice code of the microservice to be released);

[0097] Step 2: compile and package (that is, compile and package the microservice code to obtain compiled code);

[0098] Step 3, selecting a server (one or more) in the target cluster (ie, determining a target server node of the target server cluster from each server cluster);

[0099] Step 4: Pull the production environment configuration information (placed on git, the production configuration administrator has the authority to read it), and allow the node's own variable replacement (that is, obtain the preset production environment configuration information corresponding to the target server node);

[0100] Step 5, overwriting the configuration in the code project (i.e., adjusting the configuration information in the compiled code based on the production environment configuration information to obtain the target code);

[0101] Step 6: Pack the Docker image and push it to the production Docker private server (that is, pack the target code into a microservice image and publish the microservice image to the Docker private server);

[0102] Step 7: In the target cluster, multiple nodes of the service can obtain the image version and pull the production image (that is, image package the target code to obtain a microservice image, and publish the microservice image to the Docker private server);

[0103] Step 8: The cluster node starts the container of this version (that is, the target code is image packaged to obtain a microservice image, and the microservice image is published to the Docker private server);

[0104] Step 9, perform health detection, send heartbeat detection to check whether the corresponding service is started normally, and if no heartbeat is detected within 3 minutes, it is regarded as startup failure (that is, send a heartbeat detection signal to the target server node according to a preset period; if no response information of the target server node is received within the preset time of sending the heartbeat detection, it is determined that the microservice running on the target server node has not passed the health detection; if the response information is received within the preset time, it is determined that the microservice running on the target server node has passed the health detection);

[0105] Step 10: If there is a failure, the message is automatically pushed to the discussion group of the production release through the instant messaging tool, so that the problem can be handled in time (that is, if the microservice running on the target server node fails the health check, the node information of the target server node is obtained; an abnormal alarm is generated based on the node information, and the abnormal alarm information is output through the preset communication channel);

[0106] Step 11: If the health check of all nodes in the cluster passes, the entire publishing process is completed (that is, if the microservice running on the target server node passes the health check, it is determined that the microservice publishing is completed).

[0107] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the microservice publishing method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0108] This application also provides a microservice publishing device, please refer to Figure 4 , the microservice publishing device includes:

[0109] The acquisition module 10 is used to acquire the microservice code of the microservice to be released, and compile and package the microservice code to obtain the compiled code;

[0110] The configuration module 20 is used to determine the target server node of the target server cluster from each server cluster, and obtain the preset production environment configuration information corresponding to the target server node;

[0111] A determination module 30, configured to adjust the configuration information in the compiled code based on the production environment configuration information to obtain a target code;

[0112] The publishing module 40 is used to image-package the target code to obtain a microservice image, and publish the microservice image to a Docker private server, wherein the target server node obtains the microservice image from the Docker private server, uses the microservice image to start a Docker container, and runs the microservice image.

[0113] Optionally, the device further comprises a detection module, configured to:

[0114] Perform health checks on the microservices running on the target server node;

[0115] When the microservice running on the target server node passes the health check, it is determined that the microservice release is completed.

[0116] Optionally, the detection module is further used for:

[0117] Sending a heartbeat detection signal to the target server node according to a preset period;

[0118] If no response information from the target server node is received within the preset time length of sending the heartbeat detection, it is determined that the microservice running on the target server node has failed the health detection;

[0119] If the response information is received within the preset time period, it is determined that the microservice running on the target server node passes the health check.

[0120] Optionally, the detection module is further used for:

[0121] When the microservice running on the target server node fails the health check, obtaining node information of the target server node;

[0122] An abnormality alarm is generated based on the node information, and the abnormality alarm information is output through a preset communication channel.

[0123] Optionally, the device further includes a rollback module, configured to:

[0124] If an exception occurs to the microservice image, determine the historical image corresponding to the microservice image from the Docker private server;

[0125] The current container instance is deleted in the target server node, wherein the target server node pulls the historical image from the Docker private server, starts a historical container instance based on the historical image, and runs a microservice provided by the historical image in the historical container instance.

[0126] Optionally, the acquisition module 10 is further used for:

[0127] Obtain the microservice code of the microservice to be released, and determine the dependencies of the microservice to be released;

[0128] Dependencies are added to the microservice code to obtain target code, and the target code is compiled and packaged to obtain compiled code.

[0129] The microservice publishing device provided by the present application adopts the microservice publishing method in the above embodiment, which can solve the technical problems of high configuration management difficulty and low configuration management efficiency in the microservice publishing process. Compared with the prior art, the beneficial effects of the microservice publishing device provided by the present application are the same as the beneficial effects of the microservice publishing method provided by the above embodiment, and other technical features in the microservice publishing device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0130] The present application provides a microservice publishing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the microservice publishing method in the above-mentioned embodiment 1.

[0131] Reference below Figure 5 , which shows a schematic diagram of the structure of a microservice publishing device suitable for implementing an embodiment of the present application, Figure 5 The microservice publishing device shown is merely an example and should not impose any limitations on the functions and scope of use of the embodiments of the present application.

[0132] like Figure 5 As shown, the microservice publishing device may include a processing device 1001 (such as a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the microservice publishing device are also stored. The processing device 1001, ROM1002 and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the microservice publishing device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a microservice publishing device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or provided instead.

[0133] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0134] The microservice publishing device provided by the present application adopts the microservice publishing method in the above embodiment, which can solve the technical problems of high configuration management difficulty and low configuration management efficiency in the microservice publishing process. Compared with the prior art, the beneficial effects of the microservice publishing device provided by the present application are the same as the beneficial effects of the microservice publishing method provided by the above embodiment, and other technical features in the microservice publishing device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0135] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0136] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0137] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the microservice publishing method in the above-mentioned embodiment.

[0138] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

[0139] The computer-readable storage medium may be included in the microservice publishing device; or may exist independently without being assembled into the microservice publishing device.

[0140] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by a microservice publishing device, the microservice publishing device: obtains the microservice code of the microservice to be published, and compiles and packages the microservice code to obtain a compiled code; determines a target server node of a target server cluster from each server cluster, and obtains preset production environment configuration information corresponding to the target server node; adjusts the configuration information in the compiled code based on the production environment configuration information to obtain a target code; performs image packaging on the target code to obtain a microservice image, and publishes the microservice image to a Docker private server, wherein the target server node pulls the microservice image from the Docker private server, starts a current container instance based on the microservice image, and runs the microservice provided by the microservice image in the current container instance.

[0141] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0142] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0143] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0144] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned microservice publishing method, and can solve the technical problems of high configuration management difficulty and low configuration management efficiency during the microservice publishing process. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the microservice publishing method provided by the above-mentioned embodiment, and will not be repeated here.

[0145] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned microservice publishing method when executed by a processor.

[0146] The computer program product provided by this application can solve the technical problems of high configuration management difficulty and low configuration management efficiency in the microservice publishing process. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the microservice publishing method provided in the above embodiment, which will not be repeated here.

[0147] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A microservice publishing method, characterized in that: The microservice publishing method includes: Obtain the microservice code of the microservice to be released, and compile and package the microservice code to obtain compiled code; Determine a target server node of a target server cluster from each server cluster, and obtain preset production environment configuration information corresponding to the target server node; Adjusting the configuration information in the compiled code based on the production environment configuration information to obtain a target code; The target code is image-packaged to obtain a microservice image, and the microservice image is published to a Docker private server, wherein the target server node pulls the microservice image from the Docker private server, starts a current container instance based on the microservice image, and runs the microservice provided by the microservice image in the current container instance.

2. The microservice publishing method according to claim 1, characterized in that: After the step of packaging the target code into a mirror image to obtain a microservice image and publishing the microservice image to a Docker private server, the method further includes: Perform health checks on the microservices running on the target server node; When the microservice running on the target server node passes the health check, it is determined that the microservice release is completed.

3. The microservice publishing method according to claim 2, characterized in that: The step of performing health detection on the microservice running on the target server node includes: Sending a heartbeat detection signal to the target server node according to a preset period; If no response information from the target server node is received within the preset time length of sending the heartbeat detection, it is determined that the microservice running on the target server node has failed the health detection; If the response information is received within the preset time period, it is determined that the microservice running on the target server node passes the health check.

4. The microservice publishing method according to claim 2, characterized in that: After the step of performing health detection on the microservice running on the target server node, the method further includes: When the microservice running on the target server node fails the health check, obtaining node information of the target server node; An abnormality alarm is generated based on the node information, and the abnormality alarm information is output through a preset communication channel.

5. The microservice publishing method according to claim 1, characterized in that: After the step of packaging the target code into a mirror image to obtain a microservice image and publishing the microservice image to a Docker private server, the method further includes: If an exception occurs to the microservice image, determine the historical image corresponding to the microservice image from the Docker private server; The current container instance is deleted in the target server node, wherein the target server node pulls the historical image from the Docker private server, starts a historical container instance based on the historical image, and runs a microservice provided by the historical image in the historical container instance.

6. The microservice publishing method according to any one of claims 1 to 5, characterized in that: The step of obtaining the microservice code of the microservice to be released, and compiling and packaging the microservice code to obtain the compiled code includes: Obtain the microservice code of the microservice to be released, and determine the dependencies of the microservice to be released; Dependencies are added to the microservice code to obtain target code, and the target code is compiled and packaged to obtain compiled code.

7. A microservice publishing device, characterized in that: The microservice publishing device comprises: An acquisition module is used to acquire the microservice code of the microservice to be released, and compile and package the microservice code to obtain a compiled code; A configuration module, used to determine a target server node of a target server cluster from each server cluster, and obtain preset production environment configuration information corresponding to the target server node; A determination module, configured to adjust the configuration information in the compiled code based on the production environment configuration information to obtain a target code; A publishing module is used to image-package the target code to obtain a microservice image, and publish the microservice image to a Docker private server, wherein the target server node obtains the microservice image from the Docker private server, uses the microservice image to start a Docker container, and runs the microservice image.

8. A microservice publishing device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the microservice publishing method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the microservice publishing method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the microservice publishing method according to any one of claims 1 to 6 are implemented.

Images