How to determine a detachable and combinable microservice architecture

Abstract

The present application relates to a method, apparatus, computer equipment, storage medium and computer program product for determining a detachable and combinable microservice architecture. The method comprises: obtaining demand information for a microservice; generating target splitting scheme information for the microservice based on the demand information; the target splitting scheme information is used to represent the combination method between modules in the microservice; determining the deployment information of each module based on the target splitting scheme information; determining the packaging method of each module based on the deployment information of each module; and determining the microservice architecture of the microservice based on the packaging method of each module. The present method can improve the accuracy of determining the microservice architecture.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for determining a detachable and combinable microservice architecture. Background Art

[0002] At present, in order to configure microservices corresponding to different needs, it is crucial to determine the microservice architecture of microservices.

[0003] In traditional technology, when determining the microservice architecture, the service splitting method is generally determined during development; however, this method is difficult to meet the needs of different types of customers, resulting in low accuracy in determining the microservice architecture of microservices. Summary of the invention

[0004] Based on this, it is necessary to provide a detachable and combinable microservice architecture determination method, apparatus, computer device, computer-readable storage medium and computer program product that can improve the accuracy of determining the microservice architecture in order to address the above technical problems.

[0005] In a first aspect, the present application provides a method for determining a detachable and combinable microservice architecture, comprising:

[0006] Obtain demand information for microservices;

[0007] Generate target splitting scheme information of the microservice according to the demand information; the target splitting scheme information is used to represent the combination mode between the modules in the microservice;

[0008] Determine the deployment information of each module according to the target splitting plan information;

[0009] Determine the packaging method of each module according to the deployment information of each module;

[0010] According to the packaging method of each module, the microservice architecture of the microservice is determined.

[0011] In one embodiment, before determining the microservice architecture of the microservice according to the packaging method of each module, the method further includes:

[0012] In a case where the deployment information of each module is preset deployment information, determining addressing information of each module;

[0013] Determining the microservice architecture of the microservice according to the packaging method of each module includes:

[0014] According to the packaging method and addressing information of each module, a microservice architecture of the microservice is determined.

[0015] In one embodiment, determining the addressing information of each module includes:

[0016] Acquire configuration information of each module, and extract addressing information of each module from the configuration information;

[0017] or,

[0018] The module name of each module is obtained, and the service name of each module is determined according to the correspondence between the module name and the service name as the addressing information of each module.

[0019] In one embodiment, the method further comprises:

[0020] Determine the module name of each module;

[0021] According to the module name of each module, the package name, interface address name and database table name of each module are determined.

[0022] In one embodiment, generating target splitting scheme information of the microservice according to the demand information includes:

[0023] Performing denoising processing on the demand information to obtain processed demand information;

[0024] Performing feature extraction processing on the processed demand information to obtain a feature vector corresponding to the processed demand information;

[0025] Input the feature vector into the trained splitting scheme information prediction model to obtain the prediction probability of the microservice under each preset splitting scheme information;

[0026] From the preset splitting scheme information, the preset splitting scheme information with the largest prediction probability is screened out as the target splitting scheme information.

[0027] In one embodiment, before generating the target splitting solution information of the microservice according to the demand information, the method further includes:

[0028] Inputting the demand information into the trained importance prediction model to obtain the importance of each demand information;

[0029] Filtering out the demand information whose importance is greater than a preset importance from each of the demand information as key demand information;

[0030] The generating target splitting scheme information of the microservice according to the demand information also includes:

[0031] According to the key requirement information, target splitting solution information of the microservice is generated.

[0032] In a second aspect, the present application also provides a detachable and combinable microservice architecture determination device, including:

[0033] Demand acquisition module, used to obtain demand information for microservices;

[0034] A solution generation module, used to generate target splitting solution information of the microservice according to the demand information; the target splitting solution information is used to represent the combination mode between the modules in the microservice;

[0035] An information determination module, used to determine the deployment information of each module according to the target splitting scheme information;

[0036] A mode determination module, used to determine the packaging mode of each module according to the deployment information of each module;

[0037] The architecture determination module is used to determine the microservice architecture of the microservice according to the packaging method of each module.

[0038] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0039] Obtain demand information for microservices;

[0040] Generate target splitting scheme information of the microservice according to the demand information; the target splitting scheme information is used to represent the combination mode between the modules in the microservice;

[0041] Determine the deployment information of each module according to the target splitting plan information;

[0042] Determine the packaging method of each module according to the deployment information of each module;

[0043] According to the packaging method of each module, the microservice architecture of the microservice is determined.

[0044] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the following steps are implemented:

[0045] Obtain demand information for microservices;

[0046] Generate target splitting scheme information of the microservice according to the demand information; the target splitting scheme information is used to represent the combination mode between the modules in the microservice;

[0047] Determine the deployment information of each module according to the target splitting plan information;

[0048] Determine the packaging method of each module according to the deployment information of each module;

[0049] According to the packaging method of each module, the microservice architecture of the microservice is determined.

[0050] In a fifth aspect, the present application further provides a computer program product, including a computer program, which implements the following steps when executed by a processor:

[0051] Obtain demand information for microservices;

[0052] Generate target splitting scheme information of the microservice according to the demand information; the target splitting scheme information is used to represent the combination mode between the modules in the microservice;

[0053] Determine the deployment information of each module according to the target splitting plan information;

[0054] Determine the packaging method of each module according to the deployment information of each module;

[0055] According to the packaging method of each module, the microservice architecture of the microservice is determined.

[0056] The above-mentioned method, apparatus, computer equipment, storage medium and computer program product for determining the detachable and combinable microservice architecture first obtains the demand information for the microservice, and then generates the combination method between the modules in the microservice based on the demand information as the target splitting plan information of the microservice. Then, based on the target splitting plan information, the deployment information of each module is determined. Then, based on the deployment information of each module, the packaging method of each module is determined. Finally, based on the packaging method of each module, the microservice architecture of the microservice is determined. In this way, in the process of determining the microservice architecture, by generating target splitting plan information that matches the demand information of the microservice, the deployment information of each module in the microservice can be accurately determined, so that the packaging method of each module in the microservice can be accurately determined, and then the microservice architecture of the microservice can be more accurately determined, which is conducive to improving the accuracy of determining the microservice architecture of the microservice; moreover, the microservice architecture involved in this solution is determined to be detachable and combinable, and can meet the needs of different types of customers, avoiding the traditional microservice architecture that determines the service splitting during development, which is difficult to meet the needs of different types of customers, resulting in the defect of low accuracy in determining the microservice architecture of the microservice, and further improving the accuracy of determining the microservice architecture of the microservice. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0058] Figure 1 A schematic diagram of a flow chart of a method for determining a detachable and combinable microservice architecture in one embodiment;

[0059] Figure 2 A schematic diagram of target splitting scheme information in one embodiment;

[0060] Figure 3 A schematic diagram of target splitting scheme information in another embodiment;

[0061] Figure 4 A schematic diagram of a packaging method in an embodiment;

[0062] Figure 5 A schematic diagram of a packaging method in another embodiment;

[0063] Figure 6 A schematic diagram of a flow chart of a method for determining a detachable and combinable microservice architecture in another embodiment;

[0064] Figure 7 A schematic diagram of a flow chart of a research and development implementation process in an embodiment;

[0065] Figure 8 A schematic diagram of a code structure in one embodiment;

[0066] Fig. 9 A structural block diagram of a detachable and combinable microservice architecture determination device in one embodiment;

[0067] Fig.10 FIG. 4 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0068] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0069] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0070] In an exemplary embodiment, Figure 1 As shown, a method for determining a detachable and combinable microservice architecture is provided. This embodiment uses the method applied to a server as an example for illustration; it is understandable that the method can also be applied to a terminal, and can also be applied to a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. Among them, the terminal can be but is not limited to various personal computers, laptops, smart phones and tablets; the server can be implemented as an independent server or a server cluster composed of multiple servers. In this embodiment, the method includes the following steps:

[0071] Step S101, obtaining demand information for microservices.

[0072] Among them, the microservice consists of several modules and a running base, which can be understood as a war (Web Application Archive) package or a docker (a containerized platform) image package.

[0073] Among them, the module is composed of several engineering projects to complete specific business functions, such as portal management, conference management, etc.

[0074] Among them, the engineering project refers to the Maven (an open source project management and build automation tool) project during IDE (Integrated Development Environment) development. A engineering project is packaged into a jar (Java Archive, a file format) package.

[0075] Among them, the running base refers to embedded middleware such as Spring Boot (a microservice development framework).

[0076] Among them, the demand information of microservices includes the functional demand information of microservices (such as core business functions, auxiliary functions and extended functions), performance demand information (such as response time, throughput) and reliability demand information (such as availability, fault tolerance), etc.

[0077] Exemplarily, the server obtains functional requirement information, performance requirement information, and reliability requirement information of the microservice in response to a configuration instruction for the microservice; then, the server uses the functional requirement information, performance requirement information, and reliability requirement information of the microservice as requirement information for the microservice.

[0078] Step S102: Generate target splitting solution information of the microservice according to the demand information; the target splitting solution information is used to represent the combination method between the modules in the microservice.

[0079] The target splitting scheme information is used to indicate the combination of modules in the microservice. It should be noted that different demand information corresponds to different target splitting scheme information, such as Figure 2 and Figure 3 As shown, Figure 2 The target splitting plan information corresponding to customer A’s demand information, Figure 3 The target splitting plan information corresponding to customer B’s demand information.

[0080] Exemplarily, the server preprocesses the demand information to obtain preprocessed demand information; then, the server determines, based on the preprocessed demand information, splitting scheme information corresponding to the preprocessed demand information as target splitting scheme information of the microservice.

[0081] Step S103: Determine the deployment information of each module according to the target splitting solution information.

[0082] The deployment information is used to indicate the deployment status of each module, including whether the modules are deployed in the same microservice or in different microservices. Figure 2 As shown, portal management and message engine are both deployed in the basic service, so the deployment information corresponding to portal management and message engine is that the modules are deployed in the same microservice; conference management is deployed in the business application service, so the deployment information corresponding to conference management and message engine is that the modules are deployed separately in different microservices.

[0083] Exemplarily, the server determines the location information of each module according to the target splitting solution information; then, the server determines the deployment information of each module according to the location information of each module.

[0084] Step S104: Determine the packaging method of each module according to the deployment information of each module.

[0085] The packaging method is used to indicate the combination of engineering projects in each module. It should be noted that different deployment information corresponds to different packaging methods, such as Figure 4 and Figure 5 shown. Figure 4The deployment information corresponding to conference management and message engine is that the modules are deployed in the same microservice, and the corresponding packaging method is that the business implementation file of conference management, the interface definition file of message engine, and the business implementation file of message engine are combined in the microservice application service; Figure 5 The deployment information corresponding to conference management and message engine is that the modules are deployed separately in different microservices, and the corresponding packaging method is that the business implementation files of conference management, the interface definition files of the message engine, and the remote call client files of the message engine are combined in the microservice application service, and the interface definition files of the message engine and the business implementation files of the message engine are combined in the microservice message service.

[0086] Exemplarily, the server queries the corresponding relationship between the deployment information and the packaging method according to the deployment information of each module, and obtains the packaging method corresponding to the deployment information of each module as the packaging method of each module.

[0087] Step S105, determining the microservice architecture of the microservice according to the packaging method of each module.

[0088] Among them, the microservice architecture is used to represent the composition information of each microservice.

[0089] Exemplarily, the server determines the composition information of each microservice according to the packaging method of each module as the microservice architecture of the microservice.

[0090] In the above-mentioned method for determining the detachable and combinable microservice architecture, firstly, the demand information for the microservice is obtained, and then, according to the demand information, the combination method between the modules in the microservice is generated as the target splitting scheme information of the microservice, and then, according to the target splitting scheme information, the deployment information of each module is determined, and then, according to the deployment information of each module, the packaging method of each module is determined, and finally, according to the packaging method of each module, the microservice architecture of the microservice is determined. In this way, in the process of determining the microservice architecture, by generating the target splitting scheme information matching the demand information of the microservice, the deployment information of each module in the microservice can be accurately determined, so that the packaging method of each module in the microservice can be accurately determined, and then the microservice architecture of the microservice can be more accurately determined, which is conducive to improving the accuracy of determining the microservice architecture of the microservice; moreover, the microservice architecture determination involved in this scheme is detachable and combinable, which can meet the needs of different types of customers, avoiding the traditional microservice architecture that determines the service splitting during development, which is difficult to meet the needs of different types of customers, resulting in the defect of low accuracy in determining the microservice architecture of the microservice, and further improving the accuracy of determining the microservice architecture of the microservice.

[0091] In an exemplary embodiment, the above step S105, before determining the microservice architecture of the microservice according to the packaging method of each module, specifically includes the following content: when the deployment information of each module is preset deployment information, determining the addressing information of each module.

[0092] Then, according to the packaging method of each module, the microservice architecture of the microservice is determined, which specifically includes the following contents:

[0093] According to the packaging method and addressing information of each module, the microservice architecture of the microservice is determined.

[0094] The preset deployment information refers to the pre-set deployment information, such as modules deployed separately in different microservices. It should be noted that the preset deployment information depends on the situation.

[0095] The addressing information is used to indicate the service name corresponding to each module.

[0096] Exemplarily, the server determines the deployment information of each module; when the deployment information of each module is the preset deployment information, the server determines the addressing information of each module; then, the server determines the composition information of each microservice according to the packaging method and addressing information of each module as the microservice architecture of the microservice.

[0097] In this embodiment, when the deployment information of each module is the preset deployment information, the addressing information of each module is determined, and combined with the packaging method of each module, it is possible to ensure that a more accurate microservice architecture is determined, thereby improving the accuracy of determining the microservice architecture of the microservice.

[0098] In an exemplary embodiment, the addressing information of each module is determined, specifically including the following contents: obtaining the configuration information of each module, and extracting the addressing information of each module from the configuration information; or, obtaining the module name of each module, and determining the service name of each module based on the correspondence between the module name and the service name as the addressing information of each module.

[0099] Among them, the configuration information refers to the information in the configuration files of each module.

[0100] The correspondence between the module name and the service name is used to indicate the association information between the module name and the service name. For example, module name A and module name B correspond to service name a, and module name C corresponds to service name b.

[0101] The service name can be the number of the microservice.

[0102] Exemplarily, the server determines the configuration file of each module, and extracts the configuration information in the configuration file of each module as the configuration information of each module; then, the server extracts the addressing information of each module from the configuration information.

[0103] Furthermore, the server obtains the module name of each module; then, the server queries the correspondence between the module name and the service name according to the module name of each module, and obtains the service name of each module as the addressing information of each module.

[0104] In this embodiment, the addressing information of each module can be determined in a variety of ways, thereby improving the flexibility of determining the addressing information of each module, and further enabling each module to realize automatic addressing of remote calls, so as to facilitate the subsequent microservice configuration process and provide a data basis for subsequent analysis.

[0105] In an exemplary embodiment, the method further includes the following contents: determining the module name of each module; and determining the package name, interface address name and database table name of each module according to the module name of each module.

[0106] The module name is used to indicate the name of each module.

[0107] The package name is used to indicate the source code storage directory name of each module.

[0108] The interface address name is used to represent the URL (Uniform Resource Locator) address prefix of each module.

[0109] The database table name is used to represent the database table name prefix of each module.

[0110] For example, the name of the conference management module is: km-meeting, then the Java class of the conference management module must be located under the "com.landray.km.meeting" package, the interface URL address must be prefixed with " / api / km-meeting / ", and the database table name must be prefixed with "km_meeting_". In this way, you only need to ensure the uniqueness of the module identifier to avoid naming conflicts.

[0111] Exemplarily, the server determines the module name of each module; then, the server obtains the package name to be processed, the interface address name to be processed and the database table name; then, the server combines the module name of each module with the package name to be processed to obtain the package name of each module, combines the module name of each module with the interface address name to be processed to obtain the interface address name of each module, and combines the module name of each module with the database table name to be processed to obtain the database table name of each module.

[0112] In this embodiment, by processing various name combinations of modules, more accurate identification information can be generated for each module, thereby improving the accuracy of the identification information of each module, and providing convenience for the subsequent microservice architecture determination process.

[0113] In an exemplary embodiment, the above step S102 generates target splitting scheme information of the microservice based on the demand information, which specifically includes the following contents: denoising the demand information to obtain processed demand information; performing feature extraction on the processed demand information to obtain a feature vector corresponding to the processed demand information; inputting the feature vector into a trained splitting scheme information prediction model to obtain the prediction probability of the microservice under each preset splitting scheme information; and screening out the preset splitting scheme information with the largest prediction probability from each preset splitting scheme information as the target splitting scheme information.

[0114] The processed demand information refers to the demand information after denoising.

[0115] Among them, the feature vector is used to represent the characterization vector corresponding to the processed demand information.

[0116] The splitting scheme information prediction model refers to a network model that can utilize the demand information of microservices to obtain the target splitting scheme information of microservices, such as a recurrent neural network model.

[0117] The preset splitting scheme information refers to the splitting scheme information predicted by the splitting scheme information prediction model.

[0118] The prediction probability is used to indicate the possibility that the splitting scheme information prediction model determines that the preset splitting scheme information is correct.

[0119] Exemplarily, the server uses text fingerprint technology to identify noise information in the demand information; then, the server denoises the demand information according to the noise information in the demand information to obtain processed demand information; then, the server inputs the processed demand information into the feature extraction model, and performs feature extraction on the processed demand information through the feature extraction model to obtain a feature vector corresponding to the processed demand information; then, the server inputs the feature vector into the trained splitting scheme information prediction model, and obtains the prediction probability of the microservice under each preset splitting scheme information through the splitting scheme information prediction model; then, the server screens out the preset splitting scheme information with the largest prediction probability from each preset splitting scheme information, and uses the preset splitting scheme information as the target splitting scheme information.

[0120] In this embodiment, by denoising and feature extracting the demand information, using a trained splitting scheme information prediction model, and screening the prediction probabilities under each preset splitting scheme information through microservices, it is possible to obtain target splitting scheme information that better matches the demand information, thereby improving the accuracy of determining the target splitting scheme information.

[0121] In an exemplary embodiment, the above step S102, before generating the target splitting plan information of the microservice according to the demand information, specifically includes the following contents: inputting the demand information into the trained importance prediction model to obtain the importance of each demand information; from each demand information, screening out the demand information whose importance is greater than the preset importance as the key demand information.

[0122] Then, the above step S102, generating target splitting scheme information of microservices according to the demand information, specifically includes the following contents: generating target splitting scheme information of microservices according to the key demand information.

[0123] The importance prediction model refers to a network model that can predict the importance of data.

[0124] Among them, importance is used to indicate the impact of demand information.

[0125] The preset importance refers to a preset importance threshold. It should be noted that the preset importance depends on the situation.

[0126] Among them, key demand information refers to demand information whose importance is greater than the preset importance.

[0127] Exemplarily, the server inputs the demand information into a trained importance prediction model, and obtains the importance of each demand information through the importance prediction model; then, the server filters out the demand information whose importance is greater than a preset importance from each demand information, and uses the demand information as the key demand information; then, the server determines the splitting plan information corresponding to the key demand information based on the key demand information, as the target splitting plan information of the microservice.

[0128] In this embodiment, by utilizing the trained importance prediction model, the importance of each piece of demand information can be quantified, so that the key demand information in each piece of demand information can be determined, and then the target splitting plan information of the microservice can be determined more accurately, which is conducive to improving the accuracy of determining the target splitting plan information.

[0129] In an exemplary embodiment, Figure 6 As shown, another method for determining a detachable and combinable microservice architecture is provided, and the method is applied to the server as an example for explanation, including the following steps:

[0130] Step S601, obtaining demand information for microservices.

[0131] Step S602, performing denoising processing on the demand information to obtain processed demand information; performing feature extraction processing on the processed demand information to obtain a feature vector corresponding to the processed demand information.

[0132] Step S603: input the feature vector into the trained splitting scheme information prediction model to obtain the prediction probability of the microservice under each preset splitting scheme information.

[0133] Step S604: Filter out the preset splitting scheme information with the largest predicted probability from each preset splitting scheme information as the target splitting scheme information; the target splitting scheme information is used to represent the combination method between the modules in the microservice.

[0134] Step S605: Determine the deployment information of each module according to the target splitting solution information.

[0135] Step S606: Determine the packaging method of each module according to the deployment information of each module.

[0136] Step S607, when the deployment information of each module is the preset deployment information, obtain the configuration information of each module, and extract the addressing information of each module from the configuration information; or, obtain the module name of each module, and determine the service name of each module according to the correspondence between the module name and the service name, as the addressing information of each module.

[0137] Step S608, determining the microservice architecture of the microservice according to the packaging method and addressing information of each module.

[0138] In the above-mentioned method for determining a detachable and combinable microservice architecture, in the process of determining the microservice architecture, by generating target splitting scheme information that matches the demand information of the microservice, the deployment information of each module in the microservice can be accurately determined, so that the packaging method of each module in the microservice can be accurately determined, and then the microservice architecture of the microservice can be more accurately determined, which is conducive to improving the accuracy of determining the microservice architecture of the microservice; moreover, the microservice architecture determined by this scheme is detachable and combinable, and can meet the needs of different types of customers, avoiding the traditional microservice architecture that determines the service splitting during development, which is difficult to meet the needs of different types of customers, resulting in the defect of low accuracy in determining the microservice architecture of the microservice, and further improving the accuracy of determining the microservice architecture of the microservice.

[0139] In an exemplary embodiment, in order to more clearly illustrate the method for determining a detachable and combinable microservice architecture provided in the embodiment of the present application, the method for determining a detachable and combinable microservice architecture is specifically described below with a specific embodiment. Figure 7 As shown, the present application also provides a detachable and combinable microservice architecture. In the process of determining the microservice architecture, the demand information for the microservice is first obtained, and then the combination method between the modules in the microservice is generated according to the demand information as the target splitting scheme information of the microservice. Then, according to the target splitting scheme information, the deployment information of each module is determined, and then, according to the deployment information of each module, the packaging method of each module is determined. Finally, according to the packaging method of each module, the microservice architecture of the microservice is determined. Specifically, it includes the following contents:

[0140] The detachable and combinable microservice architecture involved in this embodiment, after determining the user's usage requirements, reassemble the modules into new services through configuration management. The overall development process is as follows: Figure 7 shown.

[0141] The splitting and combining here mainly refers to the business modules, while the basic services of the microservice architecture such as the registration center and service gateway are not within the scope of splitting and combining. To achieve the splitting and combining of business modules, the system requirements must first be split into modular ones. In the modular development process, the following problems must be solved:

[0142] Question 1: When modules are deployed in the same microservice, there must be no naming conflicts: Java (a programming language) class name, interface URL address, database table name, etc.

[0143] Question 2: When modules are deployed in the same microservice, jar package conflicts must not occur, that is, different modules must rely on inconsistent versions of third-party jar packages.

[0144] Question 3 (key question): There is a calling relationship between modules. For example, meeting management needs to call the messaging engine to notify users when the meeting will start. When the meeting management and messaging engine are deployed in the same microservice, the local program can be automatically called; when the meeting management and messaging engine are deployed separately, they can accurately address and complete the remote call.

[0145] Regarding the first problem, global naming conflicts. If you define a unique identifier for the module when creating it, for example, the identifier of conference management is km-meeting, then the Java class of the conference management module must be located under the "com.landray.km.meeting" package, the interface URL address must be prefixed with " / api / km-meeting / ", and the database table name must be prefixed with "km_meeting_". In this way, you only need to ensure the uniqueness of the module identifier to avoid naming conflicts.

[0146] For the second problem, the jar package version conflict. Refer to the practical solution of the Spring framework, use Maven to manage the third-party jar package version, and create a mk-parent Maven subproject to manage all third-party jar package versions. The parent (parent project) of the Maven project under each module must point to the mk-parent subproject, and the Maven project under the module is not allowed to specify the version of the dependent jar package.

[0147] Regarding the third problem (key problem), the addressing problem of service calls. Using the previous example, the conference management (km-meeting) calls the interface of the message engine (sys-notify) to notify the user when the meeting will start.

[0148] When conference management and messaging engines are deployed in the same microservice, this function is generally implemented as follows:

[0149] 1. The message engine defines an interface with a send method.

[0150] 2. The message engine defines a class to implement the previous interface and complete the business logic of the send method.

[0151] 3. Conference management uses Spring (an application framework) dependency injection, injects the implementation class through the interface of the message engine, and then calls the send method of the interface to implement the message sending function.

[0152] When conference management and messaging engines are deployed in different microservices, this functionality is generally implemented in Spring CloudOpenFeign (a microservice development framework) as follows:

[0153] 1. The implementation class of the message engine is marked with the @RestController annotation (the second annotation) and the address of the remote call is declared.

[0154] 2. The message engine defines an interface with a send method, annotated with @FeignClient (the first annotation), and declares the microservice name and service address of the remote call (consistent with the address in the implementation class).

[0155] 3. Conference management uses Spring's dependency injection to inject FeignClient's remote proxy implementation through the message engine's interface, and then calls the send method of the interface to implement the message sending function.

[0156] Adjust the code structure based on conventional methods, such as Figure 8 shown.

[0157] Then, split the message engine module into three Maven projects: mk-sys-notify-api (message engine interface definition), mk-sys-notify-core (message engine business implementation), and mk-sys-notify-client (message engine remote call client). Put the "message engine interface" into the mk-sys-notify-api project, the "message engine interface implementation" into the mk-sys-notify-core project, and the "message service remote client" into the mk-sys-notify-client project.

[0158] Combined with the business implementation project of the conference management module: mk-km-meeting-core, when the conference management module and the message engine module need to be deployed in the same microservice, the packaging method is as follows Figure 4 When the conference management module injects the message service interface, it will automatically find the implementation class in mk-sys-notify-core.jar and inject it, completing the local call.

[0159] When the conference management module and the message engine module need to be deployed in different microservices, the packaging method is as follows Figure 5 As shown. At this time, when the conference management module injects the message service interface, it will automatically find the FeignClient (a client interface component) remote proxy class in mk-sys-notify-client.jar and inject it, completing the remote call. So how does the FeignClient remote proxy know the address of the message service? Originally, it was necessary to specify the service name of the microservice in the @FeignClient annotation (the first annotation), but during development, since the service on which the message engine is deployed has not been determined, the service name cannot be determined. Let's continue to explore this issue.

[0160] The third problem is the automatic addressing of remote calls. There are two solutions to this problem:

[0161] Solution 1: Implemented through parameter configuration. In the @FeignClient annotation (the first annotation), specify the service name as "${kmss.svr.sys-notify.app}". After the configuration management package is packaged, it is clear that mk-sys-notify-core.jar will be deployed in the microservice named notify-server. Then add the configuration in the configuration file: "kmss.svr.sys-notify.app=notify-server" to solve the problem.

[0162] Although Solution 1 is simple and effective, there are hundreds of modules in the whole system, and it is difficult to know which module will call which module in configuration management. The safest way is to generate a configuration for each module, which will result in hundreds of configurations, causing great trouble to local development. Therefore, Solution 2 was proposed.

[0163] Solution 2: Add a framework-level microservice (also called a plug-in center) to record program-level metadata. The plug-in center must be started before other detachable and combinable microservices. After the detachable and combinable service is started, it will automatically scan the local module list and register the correspondence between the module name and the service name in the plug-in center. Specify the service name as "module / sys-notify" in the @FeignClient annotation (the first annotation), and then add a FeignClient interceptor. If the service name starts with "module / ", it will automatically correct it to the correct service name based on the mapping table between the module name and the service name.

[0164] The idea of ​​solution 2 can also be applied to the service gateway (Spring Cloud Gateway), which can reduce the configuration complexity of the service gateway. In order to solve the naming conflict problem of problem 1, it is stipulated that the module identifier is added to the URL naming specification, such as " / api / km-meeting / **". In the plug-in center, when the mapping relationship between the module name and the service name changes, an event broadcast is added, and an event listener is added to the service gateway, so that the routing information of Spring Cloud Gateway can be automatically updated dynamically according to the URL naming specification.

[0165] Solution 2 reduces configuration, but it cannot completely replace Solution 1. The two solutions work better together. When the detachable and detachable service is started, it needs to call the registration service of the plug-in center. At this time, the module list cannot be obtained, so Solution 2 cannot be used to obtain the service name of the plug-in center. There are also some special services that cannot register information in the plug-in center, which are also suitable for Solution 1.

[0166] In the above-mentioned embodiment, in the process of determining the microservice architecture, by generating target splitting scheme information that matches the demand information of the microservice, the deployment information of each module in the microservice can be accurately determined, so that the packaging method of each module in the microservice can be accurately determined, and then the microservice architecture of the microservice can be more accurately determined, which is conducive to improving the accuracy of determining the microservice architecture of the microservice; moreover, the microservice architecture involved in this scheme is determined to be detachable and combinable, and can meet the needs of different types of customers, avoiding the traditional microservice architecture that determines the service splitting during development, which is difficult to meet the needs of different types of customers, resulting in the defect of low accuracy in determining the microservice architecture of the microservice, and further improving the accuracy of determining the microservice architecture of the microservice.

[0167] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0168] Based on the same inventive concept, the embodiment of the present application also provides a detachable and combinable microservice architecture determination device for implementing the above-mentioned detachable and combinable microservice architecture determination method. The implementation solution provided by the device to solve the problem is similar to the implementation solution recorded in the above-mentioned method, so the specific limitations in one or more detachable and combinable microservice architecture determination device embodiments provided below can refer to the limitations of the detachable and combinable microservice architecture determination method above, and will not be repeated here.

[0169] In an exemplary embodiment, Fig. 9As shown, a detachable and combinable microservice architecture determination device is provided, including: a demand acquisition module 901, a solution generation module 902, an information determination module 903, a method determination module 904 and an architecture determination module 905, wherein:

[0170] The demand acquisition module 901 is used to obtain demand information for microservices.

[0171] The solution generation module 902 is used to generate target splitting solution information of the microservice according to the demand information; the target splitting solution information is used to represent the combination method between the modules in the microservice.

[0172] The information determination module 903 is used to determine the deployment information of each module according to the target splitting solution information.

[0173] The method determination module 904 is used to determine the packaging method of each module according to the deployment information of each module.

[0174] The architecture determination module 905 is used to determine the microservice architecture of the microservice according to the packaging method of each module.

[0175] In an exemplary embodiment, the detachable microservice architecture determination device also includes an addressing determination module, which is used to determine the addressing information of each module when the deployment information of each module is preset deployment information; the architecture determination module 905 is also used to determine the microservice architecture of the microservice based on the target identification information, version information, packaging method and addressing information of each module.

[0176] In an exemplary embodiment, the addressing determination module is also used to obtain the configuration information of each module and extract the addressing information of each module from the configuration information; or, obtain the module name of each module and determine the service name of each module based on the correspondence between the module name and the service name as the addressing information of each module.

[0177] In an exemplary embodiment, the detachable and combinable microservice architecture determination device also includes a name determination module, which is used to determine the module name of each module; based on the module name of each module, the package name, interface address name and database table name of each module are determined.

[0178] In an exemplary embodiment, the solution generation module 902 is also used to perform denoising on the demand information to obtain processed demand information; perform feature extraction on the processed demand information to obtain a feature vector corresponding to the processed demand information; input the feature vector into a trained splitting solution information prediction model to obtain the prediction probability of the microservice under each preset splitting solution information; and filter out the preset splitting solution information with the largest prediction probability from each preset splitting solution information as the target splitting solution information.

[0179] In an exemplary embodiment, the detachable and associable microservice architecture determination device also includes an information screening module, which is used to input demand information into a trained importance prediction model to obtain the importance of each demand information; from each demand information, the demand information whose importance is greater than the preset importance is screened out as key demand information; the solution generation module 902 is also used to generate target splitting solution information of the microservice based on the key demand information.

[0180] Each module in the above-mentioned detachable and combinable microservice architecture determination device can be implemented in whole or in part by software, hardware, and a combination thereof. The above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0181] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Fig.10 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store data such as demand information and target splitting scheme information. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a method for determining a detachable and combinable microservice architecture is implemented.

[0182] Those skilled in the art will understand that Fig.10 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0183] In an exemplary embodiment, a computer device is further provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

[0184] In an exemplary embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0185] In an exemplary embodiment, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0186] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0187] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0188] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A method for determining a detachable and combinable microservice architecture, characterized in that: The method comprises: Obtain demand information for microservices; Generate target splitting scheme information of the microservice according to the demand information; the target splitting scheme information is used to represent the combination mode between the modules in the microservice; According to the target splitting scheme information, the location information of each module is determined, and according to the location information of each module, the deployment information of each module is determined; the deployment information of each module includes the modules being deployed in the same microservice and the modules being deployed separately in different microservices; According to the deployment information of each module, the corresponding relationship between the deployment information and the packaging method is queried to obtain the packaging method of each module; the packaging method of each module is used to represent the combination of engineering projects in each module; Determine the microservice architecture of the microservice according to the packaging method of each module; Before determining the microservice architecture of the microservice according to the packaging method of each module, the method further includes: In the case where the deployment information of each module is preset deployment information, determining the addressing information of each module; the preset deployment information means that the modules are separately deployed in different microservices; the addressing information of each module is determined by the configuration information or module name of each module; Determining the microservice architecture of the microservice according to the packaging method of each module includes: According to the packaging method and addressing information of each module, a microservice architecture of the microservice is determined.

2. The method according to claim 1, characterized in that The determining of the addressing information of each module includes: Acquire configuration information of each module, and extract addressing information of each module from the configuration information; or, The module name of each module is obtained, and the service name of each module is determined according to the correspondence between the module name and the service name as the addressing information of each module.

3. The method according to claim 1, characterized in that The method further comprises: Determine the module name of each module; According to the module name of each module, the package name, interface address name and database table name of each module are determined.

4. The method according to any one of claims 1 to 3, characterized in that: Generating target splitting scheme information of the microservice according to the demand information includes: Performing denoising processing on the demand information to obtain processed demand information; Performing feature extraction processing on the processed demand information to obtain a feature vector corresponding to the processed demand information; Input the feature vector into the trained splitting scheme information prediction model to obtain the prediction probability of the microservice under each preset splitting scheme information; From the preset splitting scheme information, the preset splitting scheme information with the largest prediction probability is screened out as the target splitting scheme information.

5. The method according to any one of claims 1 to 3, characterized in that: Before generating the target splitting solution information of the microservice according to the demand information, the method further includes: Inputting the demand information into the trained importance prediction model to obtain the importance of each demand information; Filtering out the demand information whose importance is greater than a preset importance from each of the demand information as key demand information; The generating target splitting scheme information of the microservice according to the demand information also includes: According to the key requirement information, target splitting solution information of the microservice is generated.

6. A detachable and combinable microservice architecture determination device, characterized in that: The device comprises: Demand acquisition module, used to obtain demand information for microservices; A solution generation module, used to generate target splitting solution information of the microservice according to the demand information; the target splitting solution information is used to represent the combination mode between the modules in the microservice; An information determination module, used to determine the location information of each module according to the target splitting scheme information, and determine the deployment information of each module according to the location information of each module; the deployment information of each module includes the modules being deployed in the same microservice and the modules being deployed separately in different microservices; A mode determination module is used to query the corresponding relationship between the deployment information and the packaging mode according to the deployment information of each module, and obtain the packaging mode of each module; the packaging mode of each module is used to represent the combination of engineering projects in each module; an architecture determination module is used to determine the microservice architecture of the microservice according to the packaging mode of each module; The device further includes an addressing determination module, which is used to determine the addressing information of each module when the deployment information of each module is preset deployment information; the preset deployment information refers to that the modules are separately deployed in different microservices; the addressing information of each module is determined by the configuration information or module name of each module; The architecture determination module is also used to determine the microservice architecture of the microservice according to the packaging method and addressing information of each module.

7. The device according to claim 6, characterized in that The device also includes a name determination module, which is used to determine the module name of each module; according to the module name of each module, the package name, interface address name and database table name of each module are determined.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 5 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images