Service module deployment method and apparatus, electronic device, and computer readable medium

Abstract

The application discloses a service module deployment method and device, electronic equipment and a computer readable medium, and relates to the technical field of computers. The method comprises the following steps: receiving a service module deployment request, and obtaining a corresponding module package; analyzing the module package to obtain a deployment configuration file; in response to detecting that the deployment configuration file comprises a target file, determining a list of to-be-deployed service modules based on the target file, and determining the dependency relationship between each to-be-deployed service module in the list of to-be-deployed service modules; according to the dependency relationship, sorting each to-be-deployed service module to obtain a to-be-deployed service module sequence; and calling a corresponding program set based on the to-be-deployed service module sequence to deploy each to-be-deployed service module. The method can automatically analyze and install all dependencies of the module, thereby reducing the operation difficulty, and an operation and maintenance personnel only needs to perform an installation task once, without the need to install each module individually, thereby saving time and effort. The module deployment process is complete, low-risk and efficient.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud computing, and particularly relates to a service module deployment method and device, electronic equipment and a computer readable medium. BACKGROUND

[0002] Micro-service architecture is the mainstream of current IT development, and enterprise-level applications are often split into multiple services and deployed on different virtual machines. As the deployment architecture becomes more complex and the system scale expands, the dependencies between various modules become diversified, and often several or even dozens of sub-modules and middleware are needed when deploying an application. Manually completing the distributed deployment of multiple modules of enterprise-level applications is not only time-consuming and labor-intensive, but also inefficient and has a high risk of operation.

[0003] In the process of implementing the present application, the inventors have found that at least the following problems exist in the prior art:

[0004] Manually completing the distributed deployment of multiple service modules of enterprise-level applications is time-consuming and labor-intensive, inefficient, and has a high risk of operation. SUMMARY

[0005] Therefore, the embodiments of the present application provide a service module deployment method and device, electronic equipment and a computer readable medium, which can solve the problem that the prior art manually completing the distributed deployment of multiple service modules of enterprise-level applications is not only time-consuming and labor-intensive, but also inefficient and has a high risk of operation.

[0006] To achieve the above object, according to an aspect of the embodiments of the present application, a service module deployment method is provided, comprising:

[0007] receiving a service module deployment request and obtaining a corresponding module package;

[0008] parsing the module package to obtain a deployment configuration file, and in response to detecting that the deployment configuration file includes a target file, determining a list of service modules to be deployed based on the target file and determining the dependencies between each service module to be deployed in the list of service modules to be deployed;

[0009] According to the dependencies, each service module to be deployed is sorted to obtain a sequence of service modules to be deployed;

[0010] Based on the sequence of service modules to be deployed, a corresponding program set is called to deploy each service module to be deployed.

[0011] Optionally, determining the list of service modules to be deployed based on the target file comprises:

[0012] determining the middleware and micro-service modules to be deployed according to the target file;

[0013] obtaining state identifiers corresponding to the middleware and microservice modules to be deployed;

[0014] generating a list of service modules to be deployed according to the middleware, microservice modules to be deployed, and the state identifiers.

[0015] Optionally, a corresponding program set is called based on the sequence of service modules to be deployed to deploy each service module to be deployed, including:

[0016] extracting, from the target file, running environment requirement information corresponding to each microservice module in the sequence of service modules to be deployed;

[0017] determining whether the target deployment machine meets the installation requirement according to the running environment requirement information, and ending the deployment process if not;

[0018] if yes, determining the arrangement order of each microservice module based on the sequence of service modules to be deployed;

[0019] deploying each microservice module in the sequence of service modules to be deployed to the target deployment machine corresponding to the microservice module in turn based on the reverse sorting of the arrangement order.

[0020] Optionally, the list of service modules to be deployed is generated according to the middleware, microservice modules to be deployed, and the state identifiers, including:

[0021] determining the middleware and microservice modules to be deployed corresponding to the state identifiers as not installed;

[0022] generating the list of service modules to be deployed according to the middleware and microservice modules to be deployed corresponding to the state identifiers as not installed.

[0023] Optionally, a corresponding program set is called based on the sequence of service modules to be deployed to deploy each service module to be deployed, including:

[0024] determining the service module identifier in the sequence of service modules to be deployed;

[0025] determining the target deployment machine of the service module to be deployed corresponding to the service module identifier according to the service module identifier;

[0026] in response to triggering a deployment event corresponding to the service module identifier, calling a corresponding program set to deploy the service module to be deployed corresponding to the service module identifier to the target deployment machine.

[0027] Optionally, the dependency relationship between each service module to be deployed in the list of service modules to be deployed is determined, including:

[0028] determine, based on the target file, dependencies of each to-be-deployed service module in the list of to-be-deployed service modules;

[0029] determine, according to each dependency, a dependency type;

[0030] determine, according to each to-be-deployed service module, the dependencies of each to-be-deployed service module, and the dependency type, a dependency relationship between each to-be-deployed service module.

[0031] Optionally, the determining, according to each dependency, of the dependency type comprises:

[0032] in response to the dependency being a direct dependency module, determining that the dependency type is direct dependency;

[0033] in response to the dependency being an indirect dependency module, determining that the dependency type is indirect dependency.

[0034] In addition, the present application also provides a service module deployment apparatus, comprising:

[0035] a receiving unit configured to receive a service module deployment request and acquire a corresponding module package;

[0036] a parsing unit configured to parse the module package to obtain a deployment configuration file, and in response to detecting that the deployment configuration file comprises a target file, determine a list of to-be-deployed service modules based on the target file and determine a dependency relationship between each to-be-deployed service module in the list of to-be-deployed service modules;

[0037] a sorting unit configured to sort each to-be-deployed service module according to the dependency relationship to obtain a sequence of to-be-deployed service modules;

[0038] a module deployment unit configured to call a corresponding program set based on the sequence of to-be-deployed service modules to deploy each to-be-deployed service module.

[0039] Specifically, the parsing unit is further configured to:

[0040] determine, based on the target file, a to-be-deployed middleware and a to-be-deployed microservice module;

[0041] acquire a state identifier corresponding to the to-be-deployed middleware and the to-be-deployed microservice module;

[0042] generate the list of to-be-deployed service modules according to the to-be-deployed middleware, the to-be-deployed microservice module, and the state identifier.

[0043] Specifically, the module deployment unit is further configured to:

[0044] extract, from the target file, running environment requirement information corresponding to each to-be-deployed microservice module in the sequence of to-be-deployed service modules;

[0045] According to the running environment requirement information, it is determined whether the target deployment machine meets the installation requirement, and if not, the deployment process is ended.

[0046] If yes, based on the sequence of the to-be-deployed service modules, the arrangement order of each microservice module is determined.

[0047] Based on the reverse sorting of the arrangement order, each microservice module in the sequence of the to-be-deployed service modules is deployed to the target deployment machine corresponding to the microservice module in turn.

[0048] Specifically, the parsing unit is further configured to:

[0049] determine the to-be-deployed middleware and the microservice module corresponding to the state identifier as the to-be-deployed middleware and the microservice module not installed;

[0050] According to the to-be-deployed middleware and the microservice module corresponding to the state identifier as the to-be-deployed middleware and the microservice module not installed, a to-be-deployed service module list is generated.

[0051] Specifically, the module deployment unit is further configured to:

[0052] determine the to-be-deployed service module identifier in the sequence of the to-be-deployed service modules;

[0053] According to the to-be-deployed service module identifier, the target deployment machine of the to-be-deployed service module corresponding to the to-be-deployed service module identifier is determined;

[0054] In response to triggering the deployment event corresponding to the to-be-deployed service module identifier, the corresponding program set is called to deploy the to-be-deployed service module corresponding to the to-be-deployed service module identifier to the target deployment machine.

[0055] Specifically, the parsing unit is further configured to:

[0056] determine the dependent service of each to-be-deployed service module in the to-be-deployed service module list based on the target file;

[0057] According to each dependent service, the dependency type is determined;

[0058] According to each to-be-deployed service module, the dependent service and the dependency type of each to-be-deployed service module, the dependency relationship between each to-be-deployed service module is determined.

[0059] Specifically, the parsing unit is further configured to:

[0060] In response to the dependent service belonging to a direct dependent module, the dependency type is determined as direct dependency;

[0061] In response to the dependent service belonging to an indirect dependent module, the dependency type is determined as indirect dependency.

[0062] In addition, the application further provides a service module deployment electronic device, comprising one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement the service module deployment method as described above.

[0063] In addition, the application further provides a computer readable medium, which stores a computer program, when the program is executed by a processor, the service module deployment method as described above is implemented.

[0064] To achieve the above object, according to another aspect of the embodiments of the application, a computer program product is provided.

[0065] The computer program product of the embodiments of the application comprises a computer program, when the program is executed by a processor, the service module deployment method provided by the embodiments of the application is implemented.

[0066] The above-mentioned embodiment of the application has the following advantages or beneficial effects: the application receives a service module deployment request, obtains a corresponding module package, parses the module package to obtain a deployment configuration file, in response to detecting that the deployment configuration file includes a target file, determines a list of service modules to be deployed based on the target file and determines the dependency relationship between each service module to be deployed in the list of service modules to be deployed; according to the dependency relationship, each service module to be deployed is sorted to obtain a sequence of service modules to be deployed; based on the sequence of service modules to be deployed, a corresponding program set is called to deploy each service module to be deployed. The whole dependency of the module can be automatically parsed and installed, the operation difficulty is reduced, the operation and maintenance personnel only needs to perform an installation task once, does not need to install one by one, saves time and effort, and the module deployment process is complete, low risk and efficient.

[0067] The further effects of the above-mentioned non-conventional optional mode will be described in the following combined with the specific embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0068] The accompanying drawings serve to better understand the application and do not constitute an improper limitation on the application. Among them:

[0069] Figure 1 is a schematic diagram of the main process of the service module deployment method according to an embodiment of the application;

[0070] Figure 2 is a schematic diagram of the main process of the service module deployment method according to an embodiment of the application;

[0071] Figure 3 is a schematic diagram of the main process of the service module deployment method according to an embodiment of the application;

[0072] Figure 4 is a multi-module microservice deployment dependency diagram of a service module deployment method according to an embodiment of the present application;

[0073] Figure 5 is an interaction diagram between successfully deployed modules according to an embodiment of the present application;

[0074] Figure 6 is a schematic diagram of main units of a service module deployment apparatus according to an embodiment of the present application;

[0075] Figure 7 is an exemplary system architecture diagram to which embodiments of the present application can be applied;

[0076] Figure 8 is a structural schematic diagram of a computer system of a terminal device or a server suitable for being used to implement embodiments of the present application. DETAILED DESCRIPTION

[0077] Exemplary embodiments of the present application are described below with reference to the accompanying drawings, which include various details of the embodiments of the present application to assist in understanding, and should be considered as merely exemplary. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Also, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. The acquisition, storage, use, processing, etc. of data in the technical solutions of the present application all comply with relevant provisions of national laws and regulations.

[0078] Figure 1 is a schematic diagram of the main process of a service module deployment method according to an embodiment of the present application, as shown in Figure 1 the service module deployment method includes:

[0079] Step S101, receiving a service module deployment request and obtaining a corresponding module package.

[0080] In this embodiment, the execution subject of the service module deployment method (for example, it can be a server) can receive a service module deployment request through wired connection or wireless connection. Specifically, the service module to be deployed can include middleware and microservice modules. The middleware is a type of computer software that provides connection between system software and application software and facilitates communication between software components, and it provides services for software application programs in addition to the operating system. In the microservice architecture, the system can be divided into independent service units according to business, and each service only focuses on completing one task.

[0081] Upon receiving a service module deployment request, the executing entity can obtain the corresponding module package. The module package can be a compressed file. It may contain information about the middleware to be deployed or the microservices to be deployed. The middleware information may include the name of the middleware, dependencies between middleware components, and dependencies between the middleware and the microservices. The microservice information may include the name of the microservice and dependencies between it.

[0082] Step S102: Parse the module package to obtain the deployment configuration file. In response to the detection that the deployment configuration file includes a target file, determine the list of service modules to be deployed based on the target file and determine the dependencies between each service module to be deployed in the list.

[0083] After obtaining the module package, the executing entity can parse it, specifically by decompressing the package to obtain deployment configuration files for the middleware and microservice modules. When the executing entity detects that the deployment configuration file includes a target file, for example, a module.yml file, it can determine a list of service modules to be deployed based on the detected target file. This list of service modules to be deployed may include middleware and microservice modules to be deployed. This embodiment does not specifically limit the content included in the list of service modules to be deployed. Specifically, the executing entity can extract the dependencies of each service module to be deployed (including middleware and microservice modules) from the target file, where dependencies include direct dependencies and indirect dependencies.

[0084] Example, Figure 4 This diagram illustrates the dependencies in a multi-module microservice deployment. (Example:) Figure 4As shown, when the application of "application release" is to be deployed, the application contains a front-end module and a back-end service module; wherein the front-end module needs to be published to users for interactive use through the nginx service; the back-end service is developed by java, needs to install jdk and run in the environment provided by it to provide interface for the front-end, and also needs to use mysql and other middleware for data storage. In the embodiment of the application, in order to meet the design of the micro-service framework, some basic businesses relied on by the application release are separated into separate micro-service modules, such as user center service, timing task service, automation service, etc. Among them, automation depends on the service provided by the management and control platform, and the management and control platform depends on the saltstack middleware to execute scripts. In this scenario, in addition to the two target modules (application release front-end module and application release service module), the operation and maintenance personnel also need to install 7 middleware (nginx middleware, jdk middleware, mysql middleware, redis middleware, mongoDB middleware, nacos middleware and saltstack middleware), 6 lower modules (user center service module, automation service module, timing task service module, file service module, unified event service module and management and control platform service module). The embodiment of the application regards the middleware as a module equal to the micro-service module, and includes the module dependency management together; under this premise, the middleware needs to provide the corresponding installation package, configuration file and installation script as the application micro-service module. In this way, during deployment, the middleware and the micro-service module can be used as the to-be-deployed service module to perform automatic deployment in the same mode. The execution subject can implant a yml file in each to-be-deployed service module, and configure other modules relied on by the module in the yml file. The developer only needs to configure the modules directly relied on by the module responsible for (for example, in the case shown in the figure, the application release front-end only needs to configure two dependencies of nginx and back-end service, and the automation service module only needs to configure the dependency of the management and control platform service). In this way, the execution subject can find all the middleware and micro-service modules that need to be installed from top to bottom. In the embodiment of the application, the operation and maintenance personnel only need to install the topmost module during deployment, and the lower micro-service modules and middleware relied on by the topmost module will be automatically installed.

[0085] Specifically, the dependency relationship between each to-be-deployed service module in the to-be-deployed service module list is determined, including:

[0086] The dependent service of each to-be-deployed service module in the to-be-deployed service module list is determined based on the target file. For example, the dependent service of the to-be-deployed service module A (which can be an application release front-end module or an application release service module, and the to-be-deployed service module A is not limited in the embodiment of the application) is the automation service.

[0087] According to each dependent service, a dependency type is determined. For example, when the dependent service is an automation service, the corresponding dependency type is direct dependency. When the dependent service is a management platform service, the corresponding dependency type is indirect dependency.

[0088] According to each to-be-deployed service module, the dependent service and the dependency type of each to-be-deployed service module, a dependency relationship between each to-be-deployed service module is determined.

[0089] Each to-be-deployed service module includes a module corresponding to a dependent service. Each to-be-deployed service module includes middleware and a microservice module. For example, each to-be-deployed service module can include an application publishing front-end module, an application publishing service module, middleware dependent on the application publishing front-end module, an automation service module dependent on the application publishing service module, a management platform service module dependent on the automation service module, and a saltstack middleware dependent on the management platform service module. For example, the dependency relationship between the application publishing service module and the dependent automation service module is a direct dependency relationship, the dependency relationship between the automation service module and the management platform service module is an indirect dependency relationship, and the dependency relationship between the management platform service module and the saltstack middleware is an indirect dependency relationship. Figure 4

[0090] Specifically, according to each dependent service, a dependency type is determined, including: in response to the dependent service belonging to a direct dependency module, that is, the dependent service is a service that can be implemented under the direct dependency module (for example, a user center service, an automation service, a timing task service, a file service, a unified event service, etc.), it is determined that the dependency type is direct dependency; in response to the dependent service belonging to an indirect dependency module, that is, the dependent service is a service that can be implemented under the indirect dependency module (for example, a management platform service, etc.), it is determined that the dependency type is indirect dependency.

[0091] In step S103, according to the dependency relationship, each to-be-deployed service module is sorted to obtain a to-be-deployed service module sequence.

[0092] The execution subject places the to-be-deployed service module corresponding to the direct dependency relationship at the head of the module deployment list, and places the to-be-deployed service module corresponding to the indirect dependency relationship at the tail of the module deployment list, that is, the order of the module deployment list is the target module, the direct dependency module, and the indirect dependency module in turn, thereby obtaining a to-be-deployed service module sequence with a determined module deployment order.

[0093] ​The target module is a module included in the application to be deployed and not relied on. The direct dependency module is a module directly relied on by the target module. The indirect dependency module is a module indirectly relied on by the target module, that is, a module not directly relied on by the target module. For example, the target module can be an application publishing service module as shown in Figure 4 The direct dependency module can be an automation service module as shown in Figure 4 The indirect dependency module can be a management and control platform service module as shown in Figure 4

[0094] In step S104, the corresponding program set is called based on the sequence of service modules to be deployed to deploy each service module to be deployed.

[0095] The program set includes a script set and a command set. The script set can be a set of installation scripts, and the command set can be a set of service start commands.

[0096] Specifically, the corresponding program set is called based on the sequence of service modules to be deployed to deploy each service module to be deployed, including:

[0097] The service module to be deployed in the sequence of service modules to be deployed is determined. The target deployment machine of the service module to be deployed corresponding to the service module to be deployed is determined according to the service module to be deployed.

[0098] Specifically, the target deployment machine can be specified by the user, and specifically can be that the user inputs the machine identifier (for example, a) associated with the service module to be deployed identifier (for example, A). After the execution subject receives the machine identifier (for example, a) input by the user, the corresponding machine, that is, the target deployment machine, can be found according to the machine identifier.

[0099] In response to triggering the deployment event corresponding to the service module to be deployed identifier, the corresponding program set is called to deploy the service module to be deployed corresponding to the service module to be deployed identifier to the target deployment machine.

[0100] When the execution subject detects that the deployment event corresponding to the service module to be deployed identifier in the sequence of service modules to be deployed is triggered, it indicates that each service module to be deployed in the sequence of service modules to be deployed needs to be deployed. The module deployment process is started, and then the corresponding script set and command set are called in sequence according to the order of each service module to be deployed in the sequence of service modules to be deployed (that is, the order of the indirect dependency module, the direct dependency module, and the target module) to issue the installation script and issue the service start command, so as to deploy the corresponding module to the corresponding target deployment machine.

[0101] ​The embodiment receives a service module deployment request, obtains a corresponding module package, parses the module package to obtain a deployment configuration file, determines a list of to-be-deployed service modules based on a target file in response to detecting that the deployment configuration file includes the target file, and determines a dependency relationship between each to-be-deployed service module in the list of to-be-deployed service modules. The to-be-deployed service modules are sorted according to the dependency relationship to obtain a sequence of to-be-deployed service modules. The corresponding program set is called based on the sequence of to-be-deployed service modules to deploy each to-be-deployed service module. The entire dependency of the module can be automatically parsed and installed, the operation difficulty is reduced, the operation personnel only needs to perform an installation task once, does not need to install each module individually, time and labor are saved, and the module deployment process is complete, low-risk, and efficient.

[0102] Figure 2 FIG. 1 is a schematic diagram of a main process of a service module deployment method according to an embodiment of the present application. As shown in FIG. 1, the service module deployment method includes the following steps. Figure 2

[0103] In step S201, a service module deployment request is received, and a corresponding module package is obtained.

[0104] In step S202, the module package is parsed to obtain a deployment configuration file. In response to detecting that the deployment configuration file includes a target file, a middleware and a microservice module to be deployed are determined according to the target file. Whether it is middleware or other microservice modules, they are installed in the same way. The target file includes middleware information to be deployed and other microservice information to be deployed. The middleware information to be deployed can include a middleware name to be deployed and a deployment position. The other microservice information to be deployed can include a name of the other microservice module to be deployed and a deployment position. The deployment position can include whether to be installed on the same machine as the target module. The target module is a module that is not dependent on the application to be deployed.

[0105] In step S203, a state identifier corresponding to the middleware and the microservice module to be deployed is obtained.

[0106] The state identifier is used to represent whether the middleware and the microservice module have been deployed (i.e., whether they have been installed). For example, the state identifier can be Y, representing that the deployment has been performed, and the state identifier can be N, representing that the deployment has not been performed. By obtaining the state identifier of the middleware and the microservice module to be deployed, the deployment situation of the middleware and the microservice module to be deployed can be known, repeated deployment and waste of deployment resources can be avoided, and the module deployment efficiency and accuracy can be improved.

[0107] In step S204, a list of to-be-deployed service modules is generated according to the middleware, the microservice module to be deployed, and the state identifier.

[0108] ​Step S205, determine the dependency relationship between each to-be-deployed service module in the to-be-deployed service module list.

[0109] Step S206, sort each to-be-deployed service module according to the dependency relationship to obtain a to-be-deployed service module sequence.

[0110] The execution subject can filter out the middleware and microservice modules that have not been deployed by obtaining the state identifiers of the to-be-deployed middleware and microservice modules, thereby obtaining a to-be-deployed service module list, and further sorting the middleware and microservice modules that have not been deployed in the to-be-deployed service module list according to the dependency relationship to generate a to-be-deployed service module sequence. In the to-be-deployed service module sequence, the to-be-deployed service modules that are not dependent are placed at the head of the sequence, the to-be-deployed service modules that are directly dependent are placed in the middle of the sequence, and the to-be-deployed service modules that are indirectly dependent are placed at the tail of the sequence.

[0111] Step S207, call the corresponding program set based on the to-be-deployed service module sequence to deploy each to-be-deployed service module.

[0112] The to-be-deployed service modules are traversed from the tail of the to-be-deployed service module sequence, and the program set (including the script set and the command set) corresponding to the currently traversed to-be-deployed service module is called to deploy (i.e., install) the corresponding to-be-deployed service module.

[0113] Specifically, calling the corresponding program set based on the to-be-deployed service module sequence to deploy each to-be-deployed service module includes: extracting the running environment requirement information corresponding to each microservice module in the to-be-deployed service module sequence from the target file; determining whether the target deployment machine meets the installation requirements according to the running environment requirement information, and ending the deployment process if not; if so, determining the arrangement order of each microservice module (the arrangement order is, for example, the order of target module, directly dependent module, and indirectly dependent module) based on the to-be-deployed service module sequence; and deploying each microservice module in the to-be-deployed service module sequence to the target deployment machine corresponding to each microservice module in turn based on the reverse order of the arrangement order (the reverse order is, for example, the order of indirectly dependent module, directly dependent module, and target module).

[0114] Specifically, generating the to-be-deployed service module list according to the to-be-deployed middleware, microservice modules, and state identifiers includes: determining the to-be-deployed middleware and microservice modules corresponding to the state identifiers as to-be-deployed middleware and microservice modules that have not been installed; and generating the to-be-deployed service module list according to the to-be-deployed middleware and microservice modules corresponding to the state identifiers as to-be-deployed middleware and microservice modules that have not been installed. That is, all the service modules in the to-be-deployed service module list have not been deployed. Thus, repeated deployment is avoided, deployment resources are saved, and deployment efficiency is improved.

[0115] Figure 3 Figure 1 is a schematic diagram of the main flow of the service module deployment method according to an embodiment of the present application. The service module deployment method of the embodiments of the present application is applied to a scenario in which the dependencies among various modules to be deployed are diversified. The service module deployment method includes a module analysis flow and a module deployment flow.

[0116] For example, the module analysis flow is as shown in Figure 2. Figure 3

[0117] Step 1.1: The developer packs the middleware or application module according to the standard process and uploads it to the system.

[0118] Step 1.2: The system performs tar decompression on the uploaded module package.

[0119] Step 1.3: The module.yml file is searched for in the decompressed file. If it exists, the process continues; if it does not exist, the module package is illegal and needs to be uploaded again by the user.

[0120] Step 1.4: The basic information of the module package, such as the module name and version number, is extracted from the module.yml.

[0121] Step 1.5: The direct dependency relationship of the module is extracted from the module.yml. For example, the following are the dependency configurations of the application publishing backend module.

[0122] Each dependency relationship includes three elements: the module name, the module version, and whether it is installed on the same machine as the current module. Through the combination of the module name and the version, a dependent module can be accurately determined. From the example in the above figure, the dependency chain of the service module can be sorted out as “application publishing backend – automation service – management service”.

[0123] Step 1.6: The system built-in commands supported by the module (generally used for starting, stopping, and restarting the module service) are extracted from the module.yml.

[0124] Step 1.7: The installation script of the module is extracted from the module.yml.

[0125] Step 1.8: The environment requirements of the module are extracted from the module.yml. This step is not necessary. If no environment requirements are set, all machines can install the module by default.

[0126] Step 1.9: The parsed results are saved to the database for subsequent installation of the module.

[0127] The module deployment flow is as shown in Figure 3. Figure 3 ​​

[0128] Step 2.1: Check if the target machine meets the deployment requirements of the module (obtained from step 1.8, i.e., the running requirements). If not, end the deployment. If yes, proceed to the next step.

[0129] Step 2.2: Find the lower-level modules (middleware, other service modules, etc.) that the module depends on. If there is no dependency, go directly to step 2.6. If there is a lower-level module dependency, go to step 2.3. The dependency relationship of the module is obtained from step 1.5.

[0130] Step 2.3: Determine if the lower-level module needs to be deployed on the same machine as the upper-level module. For example, the middleware jdk as the local runtime environment of the backend module must be deployed on the same machine as the target module, while the middleware mysql as a public module is deployed separately and provides support for multiple service modules, and does not need to be deployed with the target module.

[0131] Step 2.4: According to the requirements of 2.3, find the lower-level module on the local machine or any machine.

[0132] Step 2.5: Determine if the lower-level module has already been deployed. If it has been deployed, go to step 2.6 to handle the upper-level module. If it has not been deployed, the lower-level module needs to be deployed, and at this time, the process of 2.2 to 2.5 needs to be repeated to further find the lower-level modules that the lower-level module depends on.

[0133] Through the recursive search of steps 2.2 to 2.5, all modules that need to be deployed can be found.

[0134] Step 2.6: Add the modules that need to be deployed to the sequence of service modules to be deployed. The sequence can be in the order of target module, direct dependency module, and indirect dependency module.

[0135] Step 2.7: Start deploying from the end of the sequence of service modules to be deployed, i.e., deploy the indirect dependency module first, then the direct dependency module, and finally the target module.

[0136] Step 2.8: Generate module deployment commands according to the deployment script information of the service modules to be deployed (obtained from step 1.7), and send them to the agent end for execution.

[0137] Step 2.9: Generate module startup commands according to the support command information of the service modules to be deployed (obtained from step 1.6), and send them to the agent end for execution.

[0138] Step 2.10: The agent end feeds back the command execution results. If the module deployment is completed, determine if there is still a next service module to be deployed. If there is, repeat the above deployment steps.

[0139] Step 2.11: After all the service modules to be deployed are deployed, the deployment process is ended.

[0140] The embodiment of the application can parse the middleware and lower-level modules relied on by the application module, and automatically install according to the dependency order. The module packaging process is formulated through the module.yml file, so that all middleware and business modules can be installed by using general steps, and the deployment process is standardized and normalized. At the same time, all dependencies of the module can be automatically parsed and installed, which reduces the operation difficulty, and the operation and maintenance personnel only need to perform an installation task, without the need to install one by one, and the deployment process is complete and low-risk.

[0141] Figure 5 is a schematic diagram of the interaction between the successfully deployed modules according to an embodiment of the application. In the embodiment of the application, a service: usually a single application constitutes an independent unit, and provides a specific function externally. A module: in the embodiment of the application, it refers to the code, configuration, jar package, etc. of a certain service, which is obtained after being compiled and packaged, and can be understood as an entity of a service, which is one-to-one corresponding to the service. As shown in Figure 5 The execution subject for executing the service module deployment can include a deployment resource management, a module warehouse, and an execution agent, as shown in the figure. The deployment resource management mainly maintains virtual machine (virtual machine: refers to a complete computer system that is simulated by software and has complete hardware system functions, and runs in a completely isolated environment, which is referred to as a virtual machine) resources and agent client management (including agent installation, agent log management, etc.) on the virtual machine. The module warehouse is the core module of the product, and includes product management, module uploading and module management, module parsing, module installation, etc. Among them, the module parsing and the module installation are the core contents protected by the service module deployment method of the application, the module parsing includes basic information parsing of the module, dependency parsing of the module, configuration parsing of the module, and command parsing of the module, etc., and the module installation includes running environment detection of the module, dependency detection of the module, module installation state query, and installation log collection and storage, etc. The execution agent module includes an agent server and a plurality of agent clients installed on the virtual machine. The agent server is responsible for receiving various commands sent by the deployment resource management module and the module warehouse, such as log finding commands, agent installation commands, hardware detection commands, process finding commands, script execution commands, etc., and sends them to the target deployment machine for execution by the agent client. Thus, it is ensured that the deployed service module can normally provide business capability, and the business handling efficiency is improved.

[0142] Figure 6 is a schematic diagram of the main unit of the service module deployment device according to the embodiment of the application. As Figure 6As shown, the service module deployment apparatus 600 comprises a receiving unit 601, an analyzing unit 602, an ordering unit 603 and a module deployment unit 604.

[0143] The receiving unit 601 is configured to receive a service module deployment request and acquire a corresponding module package.

[0144] The analyzing unit 602 is configured to analyze the module package to obtain a deployment configuration file, determine a list of to-be-deployed service modules and determine the dependency relationship between each to-be-deployed service module in the list of to-be-deployed service modules based on the target file in response to detecting that the deployment configuration file comprises the target file.

[0145] The ordering unit 603 is configured to order each to-be-deployed service module according to the dependency relationship to obtain a sequence of to-be-deployed service modules.

[0146] The module deployment unit 604 is configured to call a corresponding program set based on the sequence of to-be-deployed service modules to deploy each to-be-deployed service module.

[0147] In some embodiments, the analyzing unit 602 is further configured to determine to-be-deployed middleware and microservice modules according to the target file, acquire state identifiers corresponding to the to-be-deployed middleware and microservice modules, and generate the list of to-be-deployed service modules according to the to-be-deployed middleware, microservice modules and state identifiers.

[0148] In some embodiments, the module deployment unit 604 is further configured to extract running environment requirement information corresponding to each microservice module in the sequence of to-be-deployed service modules from the target file, determine whether the target deployment machine meets the installation requirement according to the running environment requirement information, end the deployment process if not, determine the arrangement order of each microservice module based on the sequence of to-be-deployed service modules if yes, and deploy each microservice module in the sequence of to-be-deployed service modules to the target deployment machine corresponding to the microservice module in turn based on the reverse ordering of the arrangement order.

[0149] In some embodiments, the analyzing unit 602 is further configured to determine to-be-deployed middleware and microservice modules corresponding to the state identifiers as to-be-installed, and generate the list of to-be-deployed service modules according to the to-be-deployed middleware and microservice modules corresponding to the state identifiers as to-be-installed.

[0150] In some embodiments, the module deployment unit 604 is further configured to: determine the identifier of the service module to be deployed in the sequence of service modules to be deployed; determine the target deployment machine of the service module to be deployed corresponding to the identifier of the service module to be deployed based on the identifier of the service module to be deployed; and in response to triggering a deployment event corresponding to the identifier of the service module to be deployed, invoke the corresponding program set to deploy the service module to be deployed corresponding to the identifier of the service module to be deployed to the target deployment machine.

[0151] In some embodiments, the parsing unit 602 is further configured to: determine the dependent services of each service module to be deployed in the list of service modules to be deployed based on the target file; determine the dependency type according to each dependent service; and determine the dependency relationship between each service module to be deployed based on each service module to be deployed, the dependent services of each service module to be deployed, and the dependency type.

[0152] In some embodiments, the parsing unit 602 is further configured to: determine the dependency type as a direct dependency in response to the dependent service belonging to a directly dependent module; and determine the dependency type as an indirect dependency in response to the dependent service belonging to an indirectly dependent module.

[0153] It should be noted that the service module deployment method and service module deployment device in this application are related in terms of specific implementation content, so repeated content will not be described again.

[0154] Figure 7 An exemplary system architecture 700 is shown that can be applied to the service module deployment method or service module deployment apparatus of the embodiments of this application.

[0155] like Figure 7 As shown, system architecture 700 may include terminal devices 701, 702, and 703, a network 704, and a server 705. Network 704 serves as the medium for providing communication links between terminal devices 701, 702, and 703 and server 705. Network 704 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0156] Users can use terminal devices 701, 702, and 703 to interact with server 705 via network 704 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 701, 702, and 703, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0157] Terminal devices 701, 702, and 703 can be various electronic devices with service module deployment processing screens and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0158] The server 705 can be a server providing various services, for example, a background management server providing support for a service module deployment request submitted by a user using a terminal device 701, 702, 703 (only as an example). The background management server can receive a service module deployment request, obtain a corresponding module package; parse the module package to obtain a deployment configuration file, in response to detecting that the deployment configuration file includes a target file, determine a list of to-be-deployed service modules based on the target file and determine the dependency relationship between each to-be-deployed service module in the list of to-be-deployed service modules; according to the dependency relationship, sort each to-be-deployed service module to obtain a sequence of to-be-deployed service modules; and call a corresponding program set based on the sequence of to-be-deployed service modules to deploy each to-be-deployed service module. The entire dependency of the module can be automatically parsed and installed, which reduces the operation difficulty, and the operation and maintenance personnel only need to perform an installation task once, without the need to install each module individually, saving time and effort, and the module deployment process is complete, low-risk, and efficient.

[0159] It should be noted that the service module deployment method provided by the embodiments of the present application is generally executed by the server 705, and correspondingly, the service module deployment apparatus is generally arranged in the server 705.

[0160] It should be understood that Figure 7 The number of terminal devices, networks, and servers in the above embodiments is only illustrative. According to the implementation needs, there can be any number of terminal devices, networks, and servers.

[0161] Reference is made to Figure 8 which shows a structural schematic diagram of a computer system 800 of a terminal device suitable for implementing the embodiments of the present application. Figure 8 The terminal device shown is only an example and should not impose any limitation on the functions and use range of the embodiments of the present application.

[0162] As shown in Figure 8 , the computer system 800 includes a central processing unit (CPU) 801, which can perform various appropriate actions and processes according to programs stored in a read-only memory (ROM) 802 or programs loaded from a storage portion 808 to a random access memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the computer system 800 are also stored. The CPU 801, the ROM 802, and the RAM 803 are connected to each other through a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0163] The following components are connected to the I / O interface 805: an input part 806 including a keyboard, a mouse, etc.; an output part 807 including a display such as a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage part 808 including a hard disk, etc.; and a communication part 809 including a network interface card such as a LAN card, a modem, etc. The communication part 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the I / O interface 805 as necessary. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is attached to the drive 810 as necessary, so that a computer program read out therefrom is installed in the storage part 808 as necessary.

[0164] In particular, according to embodiments of the present application, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, embodiments of the present application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for executing the methods illustrated by the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network by the communication part 809, and / or installed from the removable medium 811. When the computer program is executed by the central processing unit (CPU) 801, the above-described functions defined in the system of the present application are executed.

[0165] Note that the computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium or a combination thereof. The computer-readable storage medium can include, for example, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer-readable storage medium can include, but are not limited to, an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, the computer-readable storage medium can be any tangible medium that contains or stores a program used by an instruction execution system, apparatus, or device to function according to the program. In the present application, the computer-readable signal medium can include a computer-readable storage medium or any computer-readable medium that transmits, propagates, or transfers programs used by an instruction execution system, apparatus, or device to function according to the programs. The program code contained in the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wireline, optical fiber, RF, etc., or any suitable combination of the foregoing.

[0166] The flow diagrams and block diagrams in the accompanying drawings illustrate possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a segment, or a portion of code, which comprises one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flow diagrams, and combinations thereof, can be implemented by special purpose hardware-based systems that perform the specified functions or operations, or combinations of special purpose hardware and computer instructions.

[0167] The units described in the embodiments of the present application can be implemented in the form of software, or can be implemented in the form of hardware. The described units can also be arranged in a processor, for example, can be described as: a processor includes a receiving unit, an analysis unit, an ordering unit and a module deployment unit. In some cases, the names of these units do not constitute a limitation on the units themselves.

[0168] As another aspect, the present application also provides a computer readable medium, which can be included in the device described in the above embodiments, or can exist independently without being assembled into the device. The computer readable medium carries one or more programs, when the one or more programs are executed by the device, the device receives a service module deployment request, obtains a corresponding module package; parses the module package to obtain a deployment configuration file, in response to detecting that the deployment configuration file includes a target file, determines a list of to-be-deployed service modules based on the target file and determines the dependency relationship between each to-be-deployed service module in the list of to-be-deployed service modules; according to the dependency relationship, sorts each to-be-deployed service module to obtain a sequence of to-be-deployed service modules; and based on the sequence of to-be-deployed service modules, calls a corresponding program set to deploy each to-be-deployed service module.

[0169] The computer program product of the present application includes a computer program, which, when executed by a processor, implements the service module deployment method in the embodiments of the present application.

[0170] According to the technical solutions of the embodiments of the present application, the automatic parsing and installation of all dependencies of the module can be realized, the operation difficulty is reduced, the operation and maintenance personnel only need to perform an installation task once, do not need to install one by one, save time and effort, the module deployment process is complete, low risk and high efficiency.

[0171] The above specific embodiments do not constitute a limitation on the protection scope of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and substitutions can be made depending on design requirements and other factors. Any modification, equivalent replacement and improvement made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. A service module deployment method, characterized by, The application comprises: receiving a service module deployment request, obtaining a corresponding module package; wherein the module package includes middleware information to be deployed or microservice information to be deployed; parsing the module package to obtain a deployment configuration file, in response to detecting that the deployment configuration file includes a target file, determining a list of service modules to be deployed based on the target file, including: determining the middleware and microservice modules to be deployed according to the target file; obtaining the state identifiers corresponding to the middleware and microservice modules to be deployed; generating a list of service modules to be deployed according to the middleware, microservice modules to be deployed and the state identifiers; and determining the dependency relationship between each service module to be deployed in the list of service modules to be deployed, including: determining the dependent services of each service module to be deployed in the list of service modules to be deployed based on the target file; determining the dependency type according to each dependent service; determining the dependency relationship between each service module to be deployed according to each service module to be deployed, the dependent services of each service module to be deployed and the dependency type; According to the dependency relationship, the each service module to be deployed is sorted to obtain a service module sequence to be deployed; based on the service module sequence to be deployed, calling a corresponding program set to deploy the each service module to be deployed; Further comprising: by deploying nginx front-end middleware, the microservice modules of the application publishing front-end module and the application publishing service module can be published to users; deploying microservice modules having a direct dependency relationship with the application publishing service module: user center service module, file service module, automation service module, timing task service module, unified event service module, and configuring backend middleware for the microservice modules having the direct dependency relationship: jdk middleware, mysql middleware, redis middleware, mongoDB middleware and nacos middleware; deploying microservice modules having an indirect dependency relationship with the automation service module: management and control platform service module, and configuring indirect dependency middleware for the microservice modules having the indirect dependency relationship: saltstack middleware; implanting a yml file in each microservice module to be deployed, the yml file configuring other microservice modules dependent on the microservice module; and installing middleware and microservice modules from top to bottom according to the yml file.

2. The method of claim 1, wherein, The above method comprises: extracting the running environment requirement information of each microservice module in the service module sequence to be deployed from the target file; determining whether the target deployment machine meets the installation requirements according to the running environment requirement information, if not, ending the deployment process; if yes, determining the arrangement order of the each microservice module based on the service module sequence to be deployed; based on the reverse sorting of the arrangement order, deploying each microservice module in the service module sequence to be deployed to the target deployment machine corresponding to the each microservice module.

3. The method of claim 1, wherein, The generating a to-be-deployed service module list according to the to-be-deployed middleware, the microservice module, and the state identifier includes: determining that the to-be-deployed middleware and the microservice module corresponding to the state identifier are to-be-deployed middleware and microservice modules that are not installed; generating a to-be-deployed service module list according to the to-be-deployed middleware and the microservice module corresponding to the state identifier that are not installed.

4. The method of claim 1, wherein, The calling a corresponding program set based on the to-be-deployed service module sequence to deploy the to-be-deployed service modules includes: determining a to-be-deployed service module identifier in the to-be-deployed service module sequence; determining a target deployment machine of a to-be-deployed service module corresponding to the to-be-deployed service module identifier according to the to-be-deployed service module identifier; in response to triggering a deployment event corresponding to the to-be-deployed service module identifier, calling a corresponding program set to deploy the to-be-deployed service module corresponding to the to-be-deployed service module identifier to the target deployment machine.

5. The method of claim 1, wherein, The determining a dependency type according to each of the dependent services includes: in response to the dependent service belonging to a directly dependent module, determining the dependency type as direct dependency; in response to the dependent service belonging to an indirectly dependent module, determining the dependency type as indirect dependency.

6. A service module deployment apparatus characterized by comprising: The method includes: a receiving unit configured to receive a service module deployment request, and acquire a corresponding module package; the module package includes to-be-deployed middleware information or to-be-deployed microservice information; a parsing unit configured to parse the module package, obtain a deployment configuration file, and in response to detecting that the deployment configuration file includes a target file, determine a to-be-deployed service module list based on the target file, including: determining to-be-deployed middleware and microservice modules according to the target file; acquiring state identifiers corresponding to the to-be-deployed middleware and microservice modules; generating a to-be-deployed service module list according to the to-be-deployed middleware, the microservice module, and the state identifier; and determining dependency relationships between each to-be-deployed service module in the to-be-deployed service module list, including: determining dependent services of each to-be-deployed service module in the to-be-deployed service module list based on the target file; determining a dependency type according to each of the dependent services; and determining dependency relationships between each to-be-deployed service module according to each of the to-be-deployed service modules, the dependent services of each of the to-be-deployed service modules, and the dependency type; a sorting unit configured to sort each of the to-be-deployed service modules according to the dependency relationships to obtain a to-be-deployed service module sequence; a module deployment unit configured to call a corresponding program set based on the to-be-deployed service module sequence to deploy each of the to-be-deployed service modules. The module deployment unit is further configured to: publish the microservice modules of the application publishing front-end module and the application publishing service module to the user by deploying the nginx front-end middleware; deploy the microservice modules having a direct dependency relationship with the application publishing service module, i.e., the user center service module, the file service module, the automation service module, the timing task service module, and the unified event service module, and configure the back-end middleware for the microservice modules having the direct dependency relationship, i.e., the jdk middleware, the mysql middleware, the redis middleware, the mongoDB middleware, and the nacos middleware; deploy the microservice module having an indirect dependency relationship with the automation service module, i.e., the management and control platform service module, and configure the indirect dependency middleware for the microservice module having the indirect dependency relationship, i.e., the saltstack middleware; implant a yml file in each microservice module to be deployed, the yml file configuring other microservice modules dependent on the microservice module; and install the middleware and the microservice modules from top to bottom according to the yml file.

7. The apparatus of claim 6, wherein, The module deployment unit is further configured to: extract the running environment requirement information corresponding to each microservice module in the sequence of the service modules to be deployed from the target file; determine whether the target deployment machine meets the installation requirement according to the running environment requirement information, and end the deployment process if not; if yes, determine the arrangement order of the microservice modules based on the sequence of the service modules to be deployed; deploy each microservice module in the sequence of the service modules to be deployed to the target deployment machine corresponding to the microservice module in turn based on the reverse order of the arrangement order.

8. The apparatus of claim 6, wherein, The analysis unit is further configured to: determine the microservice modules and the middleware to be deployed corresponding to the state identifier as not installed; generate a list of the service modules to be deployed according to the microservice modules and the middleware to be deployed corresponding to the state identifier as not installed.

9. The apparatus of claim 6, wherein, The module deployment unit is further configured to: determine the service module identifier in the sequence of the service modules to be deployed; determine the target deployment machine of the service module corresponding to the service module identifier according to the service module identifier; in response to triggering the deployment event corresponding to the service module identifier, call the corresponding program set to deploy the service module corresponding to the service module identifier to the target deployment machine.

10. A service module deployment electronic device, comprising: comprise: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement the method of any one of claims 1-5.

11. A computer readable medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method of any one of claims 1-5.

12. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the method of any one of claims 1-5.

Images