Micro-service determination method and related device
Automatically determine microservice objects through semantic understanding model, solving the problems of low efficiency and unstable accuracy in the prior art, and achieving efficient and accurate microservice determination.
Patent Information
- Application Number
- CN202310964974.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-08-01
- Publication Date
- 2025-02-14
AI Technical Summary
In the prior art, the use of manual sorting to determine microservices requires high accumulation of domain knowledge, and the manual efficiency and accuracy are difficult to stabilize, resulting in high cost and low efficiency.
Through the semantic understanding model, automatically determine the microservice object, obtain business demand information, conduct entity analysis, split out the correlation relationship between use cases and entities, and then automatically determine the conditions for converting into microservices.
It significantly reduces labor and time costs, improves the efficiency of microservice determination, overcomes the fluctuations in accuracy caused by human experience, and realizes automated and accurate microservice determination.
Smart Images

Figure CN119443106A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data processing, and in particular to a microservice determination method and related devices. Background Art
[0002] With the rapid development and increasing complexity of business, the traditional monolithic architecture can no longer meet the high scalability and maintainability requirements of modern software applications.
[0003] Microservice architecture came into being, which splits complex systems into multiple independent, lightweight services. Each service is responsible for handling specific business functions. A complete application product can provide corresponding services to users through the combination of multiple microservices. The advantage of microservices is that they are easy to maintain independently, and application products using microservices have strong scalability.
[0004] However, for application products that actually need to use microservices, the relevant technologies mainly use manual sorting, where experts in the field of the application product sort out and analyze the parts that can be microserviced. This manual method requires a high level of domain knowledge accumulation, and it is difficult to stabilize manual efficiency and accuracy. Summary of the invention
[0005] In order to solve the above technical problems, the present application provides a microservice determination method and related devices, which can automatically determine the target entities or target use cases that meet the conditions for conversion into microservices, significantly reducing manpower and time costs, and effectively improving the efficiency of microservice determination.
[0006] The embodiments of the present application disclose the following technical solutions:
[0007] On the one hand, an embodiment of the present application provides a microservice determination method, the method comprising:
[0008] Acquire business demand information to be processed, where the business demand information is used to describe product functions of a target product;
[0009] Determine an entity analysis result corresponding to the business requirement information through a semantic understanding model, wherein the entity analysis result includes N entities involved in the business requirement information, and the entities are used to identify objects that implement business sub-functions in the product function, where N>1;
[0010] Determine, according to the entity analysis result, an association relationship between M use cases and the N entities, wherein the M use cases are M business sub-functions split from the product function based on the entity analysis result, and the association relationship is used to identify entities involved in the implementation of the business sub-function corresponding to the use case, and M>1;
[0011] According to the association relationship, a microservice object having conditions for conversion into a microservice is determined from the M use cases and the N entities, and the microservice object includes at least one of a target entity or a target use case.
[0012] On the one hand, an embodiment of the present application provides a microservice determination device, the device comprising an acquisition unit and a determination unit:
[0013] The acquisition unit is used to acquire the business demand information to be processed, where the business demand information is used to describe the product function of the target product;
[0014] The determining unit is used to determine the entity analysis result corresponding to the business requirement information through a semantic understanding model, wherein the entity analysis result includes N entities involved in the business requirement information, and the entities are used to identify objects that implement business sub-functions in the product function, where N>1;
[0015] The determining unit is further used to determine the association relationship between the M use cases and the N entities according to the entity analysis result, the M use cases are M business sub-functions split from the product function based on the entity analysis result, and the association relationship is used to identify the entity involved in the implementation of the business sub-function corresponding to the use case, M>1;
[0016] The determining unit is further configured to determine, according to the association relationship, a microservice object having conditions for conversion into a microservice from the M use cases and the N entities, wherein the microservice object includes at least one of a target entity or a target use case.
[0017] In a possible implementation manner, the object to be identified is one use case among the M use cases or one entity among the N entities, and for the object to be identified, the determining unit is further configured to:
[0018] Based on the association relationship of the object to be identified, determining the association strength between the object to be identified and the M use cases and the N entities;
[0019] According to the association strengths respectively corresponding to the M use cases and the N entities, it is determined whether the object to be identified has the conditions for being converted into a microservice.
[0020] In a possible implementation manner, the determining unit is further configured to:
[0021] An N*M use case matrix is determined according to the entity analysis result, and the use case matrix is used to identify the association relationship between the M use cases and the N entities, wherein the element in the i-th row and j-th column in the use case matrix is used to identify whether there is an association relationship between the i-th entity among the N entities and the j-th use case among the M use cases.
[0022] In a possible implementation manner, the determining unit is further configured to:
[0023] Determine the association relationship between the M use cases and the N entities according to the business requirement information and the entity analysis result.
[0024] In a possible implementation manner, the determining unit is further configured to:
[0025] According to the entity analysis results, the association relationship between the M use cases and the N entities is determined by a relationship analysis model, wherein the relationship analysis model is trained based on training samples marked with the association relationship between the use cases and the entities, and the training samples are determined based on sample products that have completed the use case and entity splitting.
[0026] In a possible implementation manner, the determining unit is further configured to:
[0027] According to the interactive behavior parameters for the target product and the association relationship, a microservice object that meets the conditions for conversion into a microservice is determined from the M use cases and the N entities, wherein the interactive behavior parameters include at least one of the interactive behavior traffic or behavior response information corresponding to the business sub-function.
[0028] In a possible implementation manner, the determining unit is further configured to:
[0029] According to the determined microservice object, a corresponding microservice is generated, or a microservice corresponding to the microservice object is determined from existing microservices.
[0030] In a possible implementation, the device further includes an integrated deployment unit, and the basic deployment unit is used to:
[0031] Through the continuous integration / continuous deployment CI / CD module, during the operation of the target product, traffic allocation and code update are performed on the microservices corresponding to the microservice objects.
[0032] In a possible implementation manner, the entity analysis result also includes the business relationships between the N entities.
[0033] In a possible implementation manner, the determining unit is further configured to:
[0034] A class diagram reflecting the entity analysis result is generated through a semantic understanding model, the nodes in the class diagram are used to identify entities, and the edges between the nodes are used to identify the business relationships.
[0035] On the other hand, an embodiment of the present application provides a computer device, wherein the computer device includes a processor and a memory:
[0036] The memory is used to store a computer program and transmit the computer program to the processor;
[0037] The processor is configured to execute the method described above according to the computer program.
[0038] On the other hand, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium is used to store a computer program, and the computer program implements the method described in the above aspects when executed by a computer device.
[0039] On the other hand, an embodiment of the present application provides a computer program product including a computer program, which, when executed on a computer device, enables the computer device to execute the method described in the above aspects.
[0040] It can be seen from the above technical solution that for the target product that needs to be analyzed for microservices, the corresponding entity analysis results are determined through the semantic understanding model according to the business demand information describing its product functions, including N entities involved in the product functions that can implement different business sub-functions. According to the entity analysis results, the M business sub-functions separated from the product functions are used as M use cases, and the association relationship between the M use cases and the N entities is obtained. Through this association relationship, it can be reflected which entities are involved in the implementation of the business sub-functions of the target product, and it can also be reflected which business sub-functions the entity can implement. Therefore, according to this association relationship, the target entity or target use case that has the conditions for conversion into a microservice can be accurately determined from the M use cases and N entities automatically. No human intervention is required throughout the process, which overcomes the accuracy fluctuations caused by human experience, significantly reduces the manpower and time costs, and effectively improves the efficiency of microservice determination. BRIEF DESCRIPTION OF THE DRAWINGS
[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0042] Figure 1 A schematic diagram of a microservice determination scenario provided in an embodiment of the present application;
[0043] Figure 2 A method flow chart of a microservice determination method provided in an embodiment of the present application;
[0044] Figure 3 A schematic diagram of expressing entity analysis results based on a class diagram provided in an embodiment of the present application;
[0045] Figure 4 A schematic diagram of microservice determination based on functional module expression provided in an embodiment of the present application;
[0046] Figure 5 A device structure diagram of a microservice determination device provided in an embodiment of the present application;
[0047] Figure 6 A structural diagram of a terminal device provided in an embodiment of the present application;
[0048] Figure 7 A structural diagram of a server provided in an embodiment of the present application. DETAILED DESCRIPTION
[0049] The embodiments of the present application are described below in conjunction with the accompanying drawings.
[0050] For microservice analysis of an application product, the relevant technology mainly adopts the manual combing method, in which experts in the field of the application product comb and analyze the microservice parts. The manpower cost and time cost are very high, and the analysis accuracy is difficult to stabilize because it relies entirely on human experience.
[0051] To this end, the embodiments of the present application provide a microservice determination method and related devices, which can automatically determine the target entities or target use cases that meet the conditions for conversion into microservices, significantly reducing manpower and time costs, and effectively improving the efficiency of microservice determination.
[0052] The microservice determination method provided in the embodiment of the present application can be implemented by a computer device, which can be a terminal device or a server, wherein the server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Terminal devices include but are not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, etc. Terminal devices and servers can be directly or indirectly connected via wired or wireless communication, and this application does not limit this.
[0053] It is understandable that in the specific implementation of the present application, the business demand information may involve relevant data such as user information. When the above embodiments of the present application are applied to specific products or technologies, any one of them needs to obtain user permission or consent separately, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.
[0054] First, the professional terms that may be involved in the embodiments of the present application are explained.
[0055] Use case matrix: A use case matrix is a matrix that describes the functional requirements of a system. It shows the use cases in which each entity in the system participates and their associated participants and business processes. In this application, the use case matrix is used to analyze the entity relationships in business requirement information, such as the business requirement information of the face-scanning payment service, and find out the entities and use cases that need to be split into microservices.
[0056] CI / CD: Continuous Integration / Continuous Delivery / Continuous Deployment (CI / CD) is a software development practice that aims to improve the speed and quality of software development. In this application, the derived microservices are automatically deployed and updated through the CI / CD process to ensure that the business system always runs the latest code.
[0057] Microservices: Microservices is a software architecture style that splits complex systems into multiple independent, lightweight services. In this application, based on the use case matrix and entity derivation results, some business sub-function modules in the product function are split into microservices to improve the scalability, maintainability and agility of the system.
[0058] Entity derivation: Entity derivation is a process of analyzing and understanding domain knowledge by identifying and organizing important entities and concepts in the domain. In this application, semantic understanding models such as the Generative Pre-Trained Transformer (GPT) model can be used to derive entities in the business domain involved in the product functions of the target product to find entities suitable for splitting into microservices.
[0059] Use case splitting: Use case splitting is the process of breaking down complex business processes (such as product functions described by business requirements information) into smaller, easier to manage and maintain business sub-functions. In this application, the use cases of the business are split according to the use case matrix to find duplicate and redundant business logic use cases, thereby optimizing and simplifying product functions. Use case splitting helps improve the maintainability and scalability of target products, such as face-scanning payment systems.
[0060] Figure 1 A schematic diagram of a microservice determination scenario provided in an embodiment of the present application. In the embodiment, server 100 is used as the aforementioned computer device for illustration.
[0061] For target products that need microservice analysis, such as applets and applications, business requirement information describing their product functions can be generated. In order to improve automation efficiency and accuracy, the server 100 uses a configured semantic understanding model, such as a GPT model, to accurately identify keywords in the business requirement information and obtain entity analysis results, which include N entities involved in the product function that can implement different business sub-functions.
[0062] According to the entity analysis result, the server 100 takes the M business sub-functions separated from the product functions as M use cases, and obtains the association relationship between the M use cases and the N entities.
[0063] Since this association relationship can reflect which entities are involved in the implementation of the business sub-functions of the target product, and can also reflect which business sub-functions the entities can implement, based on this association relationship, the server 100 can automatically and accurately determine the target entity or target use case that has the conditions for conversion into a microservice from M use cases and N entities.
[0064] The entire process of determining microservice objects does not require human intervention, which overcomes the accuracy fluctuations caused by human experience, significantly reduces manpower and time costs, and effectively improves the efficiency of microservice determination.
[0065] Figure 2 A method flow chart of a microservice determination method provided in an embodiment of the present application. The method can be executed by a computer device. In this embodiment, the computer device is taken as a server for example.
[0066] The method comprises:
[0067] S201: Obtaining business demand information to be processed.
[0068] The target product is an application product that needs to be analyzed for microservices. The product functions can be all the functions that the target product can achieve, or one or part of the functions that the target product can achieve. This application does not limit this.
[0069] The business requirement information is used to describe the product functions of the target product, which is equivalent to descriptive information about the product functions and belongs to the domain knowledge of the field to which the product functions belong. Through the business requirement information, it is equivalent to fully describing the product functions from the perspective of business logic and business process.
[0070] For example, when the product function is "face payment", the corresponding business demand information may be "Face payment is a payment method based on facial recognition technology. Users complete facial recognition authentication on the payment terminal device and then make payment operations. The key technologies involved in face payment include facial recognition, security encryption, payment platform access, etc. In actual applications, the payment process includes steps such as identifying users, verifying account information, deducting funds, and confirming transactions."
[0071] S202: Determine the entity analysis result corresponding to the business requirement information through a semantic understanding model.
[0072] The entity analysis result includes N entities involved in the business demand information, and the entities are used to identify objects that implement business sub-functions in the product functions, where N>1.
[0073] As mentioned above, business requirement information can clearly reflect the complete business logic and business process of implementing product functions through the target product. In order to remove the influence of human experience relative to related technologies, a semantic understanding model is introduced in the embodiment of the present application to perform semantic understanding of business requirement information and screen out key information.
[0074] This application does not limit the type of semantic understanding model. Any model that can implement semantic understanding analysis and extract key information can be used, for example, the aforementioned GPT model.
[0075] The server can determine the key information of the input business requirement information through semantic analysis of the semantic understanding model, including the various implementation subjects (i.e. entities) that implement the product functions described in the business requirement information. The determined entities can be virtual entities such as some functional modules, or hardware entities such as various terminal devices, servers, etc., and can even include interactive users.
[0076] For example, in the aforementioned example of business demand information, the determined entities may include users, user accounts, face recognition modules, payment terminal devices, and payment platforms, etc.
[0077] Since the entity analysis results are mainly used for subsequent analysis of the relationship between use cases and entities, in order to better provide effective information for the follow-up, in a possible implementation, the entity analysis results also include the business relationship between the N entities.
[0078] The business relationship can reflect which entities are involved when implementing each business sub-function, or which entities are needed when a business sub-function is implemented. Since the subsequent association relationship is to identify the relationship between the business sub-function (corresponding to the use case) and the entity, the business relationship can be used as an effective auxiliary information when determining the association relationship. The relationship between the use case and the entity, and between the entities at the business level reflected by the business relationship can help improve the accuracy of determining the association relationship.
[0079] In a possible implementation, under the premise that the entity analysis result also includes business relationships, S202: determining the entity analysis result corresponding to the business demand information through a semantic understanding model includes:
[0080] A class diagram reflecting the entity analysis result is generated through a semantic understanding model, the nodes in the class diagram are used to identify entities, and the edges between the nodes are used to identify the business relationships.
[0081] Class diagrams can more intuitively reflect the entities and business relationships in the entity analysis results. They can not only provide reference for analysts through quantitative display of class diagrams, but also provide accurate and clear entity and business relationships for the subsequent determination of association relationships through the sorting of class diagrams, which helps to improve the calculation efficiency and accuracy of association relationships.
[0082] For example Figure 3 What is shown is a class diagram based on the aforementioned business requirement information example.
[0083] There are five entities, namely "user", "account", "face recognition module", "payment terminal device" and "payment platform". The entities in the class diagram can also include the attributes and responsibilities of the entity (which can be understood as the business sub-functions involved). Among them, the attributes are marked with "*", for example, the attributes of the user entity include name and account information, and the responsibilities are marked with "#", for example, the responsibilities of the face recognition module entity include identifying users.
[0084] Business relationships between entities are represented by edges between entities. The edges can also be marked with different identifiers on the sides close to the two entities. Figure 3 The identifiers are shown as "1" and "*" in the figure. The identifiers "1" and "*" represent a one-to-many relationship, for example, one payment platform corresponds to multiple accounts, and the identifiers "1" and "1" represent a one-to-one relationship, for example, one user corresponds to one account. The identifiers in the figure are exemplary and do not serve as a limitation, and the identifiers may also include but are not limited to "1" and "*".
[0085] S203: Determine the association relationship between the M use cases and the N entities according to the entity analysis result.
[0086] Among them, the M use cases are M business sub-functions separated from the product function based on the entity analysis results, and the association relationship is used to identify the entities involved in the implementation of the business sub-function corresponding to the use case, M>1.
[0087] The business sub-functions identified by the use case can reflect the interaction behavior between entities and reflect the role and function of the entity in the product function of the target product.
[0088] Since the entity analysis results can accurately provide the entities involved in the product functions, through the guidance of the entity analysis results, the server can efficiently split the relevant M business sub-functions from the product functions based on the N entities in the entity analysis results as use cases.
[0089] The association relationship can identify the relationship between N entities and M use cases (or business sub-functions), thereby clarifying which entities need to be called for each completed business sub-function when a product function is implemented.
[0090] A product function can be split into M business sub-functions in this step. The execution of the product function is realized based on the execution of the M business sub-functions through the business logic and business process described by the business requirement information.
[0091] Taking the aforementioned face-scanning payment product function as an example, the server splits the product function into use cases based on the entity analysis results, and can exemplarily obtain more than ten business sub-functions, which may include face recognition, account information verification, payment initiation, record query, etc.
[0092] For example, in this example, an association relationship can identify that the entities involved in the use case "face recognition" include users, face recognition modules, and payment terminal devices. Thus, through this association relationship, it is clearly reflected that a business sub-function "face recognition" will involve three entities when it is implemented.
[0093] In order to express the association relationship more clearly and provide effective assistance for subsequent microservice identification, the association relationship can be expressed through a use case matrix.
[0094] In a possible implementation, S203: determining the association relationship between the M use cases and the N entities according to the entity analysis result includes:
[0095] An N*M use case matrix is determined according to the entity analysis result, and the use case matrix is used to identify the association relationship between the M use cases and the N entities, wherein the element in the i-th row and j-th column in the use case matrix is used to identify whether there is an association relationship between the i-th entity among the N entities and the j-th use case among the M use cases.
[0096] Each element in the use case matrix can be represented by different symbols to indicate whether it has an association relationship or not. Taking the element in the i-th row and j-th column as an example, the element can be represented by the first symbol to indicate that the i-th entity among N entities has an association relationship with the j-th use case among M use cases, that is, the i-th entity will be involved when the business sub-function corresponding to the j-th use case is implemented. The second symbol can also be used to indicate that the i-th entity among N entities has no association relationship with the j-th use case among M use cases, that is, the i-th entity will not be involved when the business sub-function corresponding to the j-th use case is implemented.
[0097] Taking the aforementioned face-scanning payment product function as an example, Table 1 is an exemplary representation of a use case matrix corresponding to this product function. By analyzing and decomposing the product function of the target product "face-scanning payment", N=5 entities and M=10 use cases are determined, and a use case matrix is generated based on the relationship between these entities and use cases.
[0098] In this use case matrix, "×" is used as the first symbol and blank space is used as the second symbol.
[0099]
[0100] Table 1
[0101] In a possible implementation, S203: determining the association relationship between the M use cases and the N entities according to the entity analysis result includes:
[0102] Determine the association relationship between the M use cases and the N entities according to the business requirement information and the entity analysis result.
[0103] In this implementation, business requirement information is introduced to assist in determining association relationships. The business requirement information is original descriptive information about the product functions of the target product, which carries more abundant information related to determining association relationships and provides an information basis for assisting in determining association relationships.
[0104] Furthermore, when the server performs entity analysis through S202, certain entity analysis errors may inevitably occur. For example, if a certain degree of error occurs, the error will affect the accuracy of the server in determining the association relationship.
[0105] Therefore, by introducing business demand information when determining association relationships, the server can be helped to identify errors in entity analysis results and increase the effective information used when determining association relationships, thereby improving the accuracy of determining association relationships.
[0106] In a possible implementation, S203: determining the association relationship between the M use cases and the N entities according to the entity analysis result includes:
[0107] According to the entity analysis result, the association relationship between the M use cases and the N entities is determined through a relationship analysis model.
[0108] The relationship analysis model is a pre-trained model that can determine the relationship between use cases and entities based on the input entity analysis results.
[0109] Through the relationship analysis model, product functions can be accurately split into use cases (business sub-functions) based on artificial intelligence. In order to ensure the model quality of the relationship analysis model and improve the rationality of use case splitting, high-quality training samples are required.
[0110] In an embodiment of the present application, the relationship analysis model is trained based on training samples annotated with the relationship between use cases and entities, and the training samples are determined based on sample products that have completed the use case and entity splitting.
[0111] The sample product can be manually split by domain experts to obtain corresponding use cases and entities, and then the association between each use case and entity relative to the sample product is marked based on the split result. The association of the training sample can be used as a sample label, and the business requirement information of the sample product and the divided entities can be used as training samples.
[0112] The relationship analysis model trained based on such training samples can learn how to determine the relationship between use cases and entities based on the entity analysis results. Moreover, since the training samples are all high-quality training samples annotated by experts, the trained relationship analysis model can perform efficient and high-precision relationship identification.
[0113] S204: According to the association relationship, determine microservice objects that meet the conditions for conversion into microservices from the M use cases and the N entities.
[0114] The microservice object includes at least one of a target entity or a target use case.
[0115] In other words, the use cases and entities involved in the product functions can be converted into microservices, that is, the role of the use cases or entities in realizing the product functions can be completed through the corresponding microservices.
[0116] Since the main function of microservices is to realize an independent function, they can be used as a component of different application products in realizing functions. Implementing product functions through microservices is similar to splicing building blocks (microservices).
[0117] Through the association relationship, the connection between the use case and the product at the business sub-function implementation level is first reflected. Based on this, the server can determine which entities or use cases have the conditions to realize independent functions. For example, based on the reflected connection, it can be determined which use cases involve more entities and which entities involve more use cases. In product functions, when the implementation of a use case involves multiple entities, the use case is equivalent to the common part of these entities. When the implementation of multiple use cases involves the same entity, the entity is equivalent to the common part of these use cases. Entities or use cases that are common parts are more suitable for conversion into microservices to avoid repeated settings or writing code.
[0118] Therefore, based on the usage and rules of microservices, the server can determine the conditions for conversion into microservices, and use this to filter out microservice objects that meet the conditions from M use cases and N entities.
[0119] By determining the microservice objects, we can accurately guide how to subsequently transform the target products into microservices, and realize product functions more conveniently through microservices.
[0120] As mentioned earlier, if a microservice can be called by multiple entities or call multiple use cases when implementing the corresponding service through the target product, it is equivalent to providing services during the implementation of different business sub-functions through one microservice. This is also in line with the original design intention of microservices. It can not only improve the scalability, maintainability and agility of the target product, but also reduce the code redundancy of the target product, thereby reducing the data volume of the target product.
[0121] Therefore, in a possible implementation, S204: determining, according to the association relationship, microservice objects that meet the conditions for conversion into microservices from the M use cases and the N entities, includes:
[0122] Based on the association relationship of the object to be identified, determining the association strength between the object to be identified and the M use cases and the N entities;
[0123] According to the association strengths respectively corresponding to the M use cases and the N entities, it is determined whether the object to be identified has the conditions for being converted into a microservice.
[0124] In this implementation, an object to be identified is taken as an example for description, and the object to be identified is one use case among the M use cases or one entity among the N entities.
[0125] From the above description of the association relationship and Table 1, it can be concluded that the more use cases that are associated with an entity, the more important the entity is as a common part of these use cases. When the entity can be transformed into a microservice, it can be called as a common part when a large number of use cases are implemented, which can make a great contribution to the improvement of the agility of the target product and the reduction of the data volume. Similarly, the more entities that are associated with a use case, the more important the use case is as a common part of these entities. When the use case can be transformed into a microservice, it can be called as a common part by a large number of entities when it is implemented, which can also make a great contribution to the improvement of the agility of the target product and the reduction of the data volume.
[0126] It can be seen that the association strength used to identify the number of associations can effectively reflect the agility and data volume contribution that the transformation of entities or use cases into microservices can bring to the target product. Therefore, the server can treat each use case and entity as an object to be identified, determine the corresponding association strength based on the association relationship of the objects to be identified, and determine whether the objects to be identified are qualified for transformation into microservices based on the association strength determined for each use case and entity.
[0127] Generally speaking, among the association strengths corresponding to M use cases and N entities, the greater the association strength corresponding to the object to be identified, the higher the possibility that it has the conditions for conversion into a microservice.
[0128] It can be seen that for the target product that needs to be analyzed for microservices, the corresponding entity analysis results are determined through the semantic understanding model based on the business demand information that describes its product functions, including the N entities involved in the product functions that can implement different business sub-functions. According to the entity analysis results, the M business sub-functions split from the product functions are used as M use cases, and the association relationship between the M use cases and the N entities is obtained. Through this association relationship, it can be reflected which entities are involved in the implementation of the business sub-functions of the target product, and it can also be reflected which business sub-functions the entity can implement. Therefore, according to this association relationship, the target entity or target use case that has the conditions for conversion into a microservice can be accurately determined from the M use cases and N entities automatically, without the need for manual intervention throughout the process, overcoming the accuracy fluctuations caused by human experience, and significantly reducing the manpower and time costs, effectively improving the efficiency of microservice determination.
[0129] When the server determines the microservice object, in addition to considering the association relationship, the interactive behavior involved in the entities and use cases when the target product is actually used can also be considered as a dimension.
[0130] Therefore, in a possible implementation, S204: determining, according to the association relationship, microservice objects that meet the conditions for conversion into microservices from the M use cases and the N entities, includes:
[0131] According to the interaction behavior parameters for the target product and the association relationship, a microservice object having conditions for conversion into a microservice is determined from the M use cases and the N entities.
[0132] The interactive behavior parameter may include at least one of the interactive behavior flow or behavior response information corresponding to the service sub-function.
[0133] In other words, the interaction behavior parameters can reflect the importance of entities or use cases relative to the target product and product functions from the interaction level, identify the more important entities or use cases as microservice objects, transform them into microservices, improve their stability through independent maintenance, and avoid problems that may cause the entire target product to be unable to provide services normally.
[0134] Among them, the interactive behavior traffic corresponding to the business sub-function can reflect the frequency of a business sub-function being implemented. The higher the frequency, the greater the interactive behavior traffic. The greater the traffic of a business sub-function, the higher the possibility of having the conditions for conversion into a microservice. Moreover, from another perspective, when the traffic of a business sub-function is small, converting it into a microservice for independent maintenance can also effectively save system resources.
[0135] The behavior response information corresponding to the business sub-function can reflect the ability of the business sub-function to respond to interactive behaviors, for example, it can include error code parameters and business logic parameters, where the error code parameters can reflect the correctness of the business sub-function's response to interactive behaviors. The higher the error response frequency identified by the error code parameters, the lower the correctness of the business sub-function's response to interactive behaviors. The business logic parameters can reflect the business processing logic of the business sub-function in responding to interactive behaviors, thereby identifying the business processing efficiency of the business sub-function and the correctness of the response results. The better the business processing efficiency and the correctness of the response results of the business sub-function, the higher the possibility of having the conditions for conversion to microservices. Moreover, from another perspective, when the business processing efficiency and the correctness of the response results of the business sub-function are insufficient, converting it into a microservice for independent maintenance can also effectively improve the stability of the system.
[0136] It can be seen that the interaction behavior parameters can be used to identify the stability and importance of business sub-functions at the interaction level from other data dimensions. Based on this, the server can assist in measuring whether the corresponding entities or use cases have the conditions for conversion into microservices. Multi-dimensional information can provide the actual application conditions of different target products, helping the server to make microservice conversion results that are more in line with the actual situation of the target products, effectively improving the conversion accuracy of microservices.
[0137] After determining the microservice objects in the target product that meet the conditions for conversion into microservices, the server can also improve the microservices of the target product based on the microservice objects to improve the service quality of the target product.
[0138] In a possible implementation, the method further includes:
[0139] According to the determined microservice object, a corresponding microservice is generated, or a microservice corresponding to the microservice object is determined from existing microservices.
[0140] After the server determines the microservice object, the target entity or target use case representing the microservice object has the basis to be converted into a microservice, thereby improving the service quality of the target product and reducing maintenance costs.
[0141] When the microservice corresponding to the microservice object exists in the existing microservices, the corresponding microservice can be determined to replace the microservice object in the target product. When there is no existing microservice suitable to replace the microservice object, the corresponding microservice can be generated based on the business logic of the microservice object to replace the microservice object in the target product.
[0142] When the corresponding microservice is used to replace the corresponding microservice object in the target product, the microservice needs to be configured based on the association relationship and business logic of the original microservice object.
[0143] By configuring microservices reasonably, when the target product is running and the microservice object is needed, the server can implement the role of the microservice object in the product function by calling the configured microservice.
[0144] Configuring microservices in the target product can effectively improve the data processing efficiency and resource utilization efficiency of the target product, and can also improve the scalability, maintainability, and agility of the target product.
[0145] In a possible implementation, the method further includes:
[0146] Through the continuous integration / continuous deployment CI / CD module, during the operation of the target product, traffic allocation and code update are performed on the microservices corresponding to the microservice objects.
[0147] The CI / CD module can automatically deploy microservices related to the target product to the product operating environment, assist in traffic distribution to achieve load balancing, and automatically pull new code for the microservice when the code of the microservice is updated, thereby achieving the stability and availability of the microservice when the target product is running, and improving development efficiency and delivery efficiency.
[0148] Next, combine Figure 4 Provide explanation.
[0149] Based on the functional division, the embodiment of the present application can be divided into four modules, namely, an entity derivation module, a matrix derivation module, a microservice reasoning module and a CI / CD module.
[0150] Entity derivation module:
[0151] Technical principle: The domain knowledge derivation entity module mainly relies on natural language processing (NLP) technology and knowledge graph technology to analyze and identify important information in the field. By analyzing the background knowledge and business logic provided by domain experts and combining the semantic understanding ability of the GPT model, key entities and concepts are extracted.
[0152] Module architecture: The entity derivation module mainly consists of the following parts:
[0153] -Domain text parser (not shown in the figure): responsible for parsing the text materials provided by domain experts and extracting key information;
[0154] -GPT model: Improve the understanding and analysis capabilities of domain knowledge through training and parameter adjustment;
[0155] -Entity extractor (not shown in the figure): automatically identifies key entities and concepts based on the analysis results of the GPT model;
[0156] - Class diagram generator (not shown in the figure): generates corresponding class diagrams based on the extracted entities and their relationships.
[0157] The operation process of the entity derivation module is as follows:
[0158] - Input business requirement information containing domain knowledge: for example, it may include detailed business background, requirements and logic provided by domain experts;
[0159] -Analysis of business requirement information: The domain text parser analyzes the input business requirement information and extracts key information;
[0160] -GPT model analysis: The GPT model conducts in-depth analysis and understanding of the key information after parsing;
[0161] -Entity extraction: The entity extractor automatically identifies and refines key entities and concepts based on the analysis results of the GPT model;
[0162] -Class diagram generation: The class diagram generator generates a class diagram corresponding to the entity analysis results based on the extracted entities and their relationships.
[0163] Effect: The entity derivation module can effectively help domain experts extract key entities and concepts in the business scenarios of product functions, form a structured class diagram, and provide a basis for subsequent use case matrix derivation and microservice splitting. In addition, through continuous iteration and optimization, the module can improve the ability to understand domain knowledge, more accurately identify entities and concepts, and provide stronger support for the microservice derivation of the entire system.
[0164] Matrix derivation module:
[0165] Technical principle: The core idea of the use case matrix derivation module is to automatically identify and generate use cases in the system (product function) through in-depth analysis of entity analysis results. The module discovers the correlation between entities and finds the rationality of use case splitting. By mining the interaction and correlation strength between entities, the module can find out which entities involve more use cases, which helps to derive subsequent microservices.
[0166] Module architecture: The use case matrix derivation module mainly consists of entity analysis components, use case generation components and matrix construction components.
[0167] (1) The entity analysis component receives inputs of business requirements and entity analysis results, and uses data mining and machine learning methods to analyze the relationships between entities and the business sub-functions involved in the entities. By evaluating the entity relationships, it determines which entities are more closely related. These closely related entities may correspond to multiple use cases.
[0168] (3) The use case generation component identifies possible use cases based on the entity analysis results. These use cases (business sub-functions) consist of interactions between entities and reflect the role and function of the entities in the system. By analyzing the responsibilities and associations of entities, the component can identify situations where entities involve a large number of use cases.
[0169] (3) The matrix building component organizes the generated use cases into a use case matrix for further analysis. The use case matrix reveals the relationship between entities and use cases, helping developers understand the complexity of the system and the rationality of use case splitting. By analyzing the use case matrix, it is possible to identify which entities involve more use cases, thus providing strong support for subsequent microservice derivation.
[0170] Effect: The use case matrix derivation module can effectively and automatically discover the relevance between entities and the rationality of use case splitting, providing strong support for subsequent microservice derivation. By mining the interactions and association strengths between entities, the module helps to find out which entities involve more use cases, thereby optimizing the design and splitting of microservices.
[0171] Microservice reasoning module:
[0172] Technical principle: The microservice reasoning module is based on the basic knowledge of microservices and combines the entity and use case matrix information to automatically reason and split entities and use cases. The module aims to find out which entity capabilities or common parts of use cases need to be converted into microservices, thereby achieving a modular and reusable system architecture.
[0173] Module architecture: The microservice reasoning module is mainly composed of the aforementioned entity deduction module and matrix deduction module, as well as the microservice splitting component and the auxiliary decision-making component that provides interaction behavior parameters (not shown in the figure).
[0174] Operation process:
[0175] (1) The functions of the entity derivation module and the matrix derivation module are as described above.
[0176] (2) The microservice reasoning module automatically infers which entities or common parts of use cases need to be converted into microservices based on the entity analysis results, the use case matrix, and the basic knowledge of microservices.
[0177] (3) The decision-making support component receives interaction behavior parameter input, including interaction behavior flow and interaction response information. The interaction behavior parameters help improve the reasoning accuracy so as to more accurately determine which entities or common parts of use cases should be converted into microservices.
[0178] Effect: The microservice derivation module can automatically identify and extract entities and use cases suitable for conversion into microservices, thereby achieving a more efficient, scalable and maintainable system architecture. By combining other information inputs such as traffic, error codes and business logic, the module can provide more accurate microservice derivation results.
[0179] CI / CD Module
[0180] Technical principle: The CI / CD module uses the principles of continuous integration and continuous deployment to automatically complete the code building, testing, deployment and operation process. The module can achieve reasonable and effective deployment and traffic distribution based on the microservice deployment information derived by the microservice reasoning module.
[0181] Module architecture: The CI / CD module is mainly composed of a build component (not shown in the figure), a continuous integration component, a continuous deployment component, and a traffic distribution component (not shown in the figure).
[0182] Operation process:
[0183] 1. Build components through the code repository, pull the latest code, and generate executable binary files.
[0184] 2. The continuous integration component performs unit testing, integration testing, and performance testing on the generated binary files.
[0185] 3. The deployment component automatically deploys services to the production environment based on the microservice deployment information derived by the microservice inference module.
[0186] 4. The traffic distribution component is responsible for distributing traffic to different microservice instances to achieve high availability and load balancing.
[0187] Effect: The CI / CD module can automatically complete the code building, testing, deployment and operation process, ensuring the stability and availability of services and improving development and delivery efficiency.
[0188] In the aforementioned Figure 1-Figure 4 Based on the corresponding embodiments, Figure 5 This is a device structure diagram of a microservice determination device provided in an embodiment of the present application. The microservice determination device 500 includes an acquisition unit 501 and a determination unit 502:
[0189] The acquisition unit 501 is used to acquire the business demand information to be processed, where the business demand information is used to describe the product function of the target product;
[0190] The determining unit 502 is used to determine the entity analysis result corresponding to the business requirement information through a semantic understanding model, wherein the entity analysis result includes N entities involved in the business requirement information, and the entities are used to identify objects that implement business sub-functions in the product function, where N>1;
[0191] The determining unit 502 is further used to determine the association relationship between the M use cases and the N entities according to the entity analysis result, the M use cases are M business sub-functions separated from the product function based on the entity analysis result, and the association relationship is used to identify the entity involved in the implementation of the business sub-function corresponding to the use case, M>1;
[0192] The determining unit 502 is further configured to determine, according to the association relationship, a microservice object having conditions for conversion into a microservice from the M use cases and the N entities, wherein the microservice object includes at least one of a target entity or a target use case.
[0193] In a possible implementation manner, the object to be identified is one use case among the M use cases or one entity among the N entities, and for the object to be identified, the determining unit is further configured to:
[0194] Based on the association relationship of the object to be identified, determining the association strength between the object to be identified and the M use cases and the N entities;
[0195] According to the association strengths respectively corresponding to the M use cases and the N entities, it is determined whether the object to be identified has the conditions for being converted into a microservice.
[0196] In a possible implementation manner, the determining unit is further configured to:
[0197] An N*M use case matrix is determined according to the entity analysis result, and the use case matrix is used to identify the association relationship between the M use cases and the N entities, wherein the element in the i-th row and j-th column in the use case matrix is used to identify whether there is an association relationship between the i-th entity among the N entities and the j-th use case among the M use cases.
[0198] In a possible implementation manner, the determining unit is further configured to:
[0199] Determine the association relationship between the M use cases and the N entities according to the business requirement information and the entity analysis result.
[0200] In a possible implementation manner, the determining unit is further configured to:
[0201] According to the entity analysis results, the association relationship between the M use cases and the N entities is determined by a relationship analysis model, wherein the relationship analysis model is trained based on training samples marked with the association relationship between the use cases and the entities, and the training samples are determined based on sample products that have completed the use case and entity splitting.
[0202] In a possible implementation manner, the determining unit is further configured to:
[0203] According to the interactive behavior parameters for the target product and the association relationship, a microservice object that meets the conditions for conversion into a microservice is determined from the M use cases and the N entities, wherein the interactive behavior parameters include at least one of the interactive behavior traffic or behavior response information corresponding to the business sub-function.
[0204] In a possible implementation manner, the determining unit is further configured to:
[0205] According to the determined microservice object, a corresponding microservice is generated, or a microservice corresponding to the microservice object is determined from existing microservices.
[0206] In a possible implementation, the device further includes an integrated deployment unit, and the basic deployment unit is used to:
[0207] Through the continuous integration / continuous deployment CI / CD module, during the operation of the target product, traffic allocation and code update are performed on the microservices corresponding to the microservice objects.
[0208] In a possible implementation manner, the entity analysis result also includes the business relationships between the N entities.
[0209] In a possible implementation manner, the determining unit is further configured to:
[0210] A class diagram reflecting the entity analysis result is generated through a semantic understanding model, the nodes in the class diagram are used to identify entities, and the edges between the nodes are used to identify the business relationships.
[0211] It can be seen that for the target product that needs to be analyzed for microservices, the corresponding entity analysis results are determined through the semantic understanding model based on the business demand information that describes its product functions, including the N entities involved in the product functions that can implement different business sub-functions. According to the entity analysis results, the M business sub-functions split from the product functions are used as M use cases, and the association relationship between the M use cases and the N entities is obtained. Through this association relationship, it can be reflected which entities are involved in the implementation of the business sub-functions of the target product, and it can also be reflected which business sub-functions the entity can implement. Therefore, according to this association relationship, the target entity or target use case that has the conditions for conversion into a microservice can be accurately determined from the M use cases and N entities automatically, without the need for manual intervention throughout the process, overcoming the accuracy fluctuations caused by human experience, and significantly reducing the manpower and time costs, effectively improving the efficiency of microservice determination.
[0212] The embodiment of the present application further provides a computer device, which is the computer device described above and may include a terminal device or a server, and the aforementioned microservice determination device may be configured in the computer device. The computer device is described below in conjunction with the accompanying drawings.
[0213] If the computer device is a terminal device, see Figure 6 As shown, the embodiment of the present application provides a terminal device, taking the terminal device as a mobile phone as an example:
[0214] Figure 6 FIG. 1 is a block diagram showing a partial structure of a mobile phone related to a terminal device provided in an embodiment of the present application. Figure 6The mobile phone includes: a radio frequency (RF) circuit 1410, a memory 1420, an input unit 1430, a display unit 1440, a sensor 1450, an audio circuit 1460, a wireless fidelity (WiFi) module 1470, a processor 1480, and a power supply 1490. Those skilled in the art can understand that Figure 6 The mobile phone structure shown in the figure does not constitute a limitation on the mobile phone, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.
[0215] Combine the following Figure 6 A detailed introduction to the various components of the mobile phone:
[0216] The RF circuit 1410 may be used for receiving and sending signals during information transmission or communication or during a call. In particular, after receiving downlink information from a base station, the information is sent to the processor 1480 for processing. In addition, the uplink data is sent to the base station.
[0217] The memory 1420 can be used to store software programs and modules. The processor 1480 executes various functional applications and data processing of the mobile phone by running the software programs and modules stored in the memory 1420. The memory 1420 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the mobile phone (such as audio data, a phone book, etc.), etc. In addition, the memory 1420 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.
[0218] The input unit 1430 may be used to receive input digital or character information and generate key signal input related to user settings and function control of the mobile phone. Specifically, the input unit 1430 may include a touch panel 1431 and other input devices 1432 .
[0219] The display unit 1440 may be used to display information input by the user or information provided to the user and various menus of the mobile phone. The display unit 1440 may include a display panel 1441.
[0220] The mobile phone may also include at least one sensor 1450, such as a light sensor, a motion sensor, and other sensors.
[0221] The audio circuit 1460 , the speaker 1461 , and the microphone 1462 can provide an audio interface between the user and the mobile phone.
[0222] WiFi is a short-range wireless transmission technology. The mobile phone can help users send and receive emails, browse web pages and access streaming media through the WiFi module 1470. It provides users with wireless broadband Internet access.
[0223] Processor 1480 is the control center of the mobile phone. It uses various interfaces and lines to connect various parts of the entire mobile phone. It executes various functions of the mobile phone and processes data by running or executing software programs and / or modules stored in memory 1420 and calling data stored in memory 1420.
[0224] The mobile phone also includes a power source 1490 (such as a battery) for supplying power to various components.
[0225] In this embodiment, the processor 1480 included in the terminal device also has the following functions:
[0226] Acquire business demand information to be processed, where the business demand information is used to describe product functions of a target product;
[0227] Determine an entity analysis result corresponding to the business requirement information through a semantic understanding model, wherein the entity analysis result includes N entities involved in the business requirement information, and the entities are used to identify objects that implement business sub-functions in the product function, where N>1;
[0228] Determine, according to the entity analysis result, an association relationship between M use cases and the N entities, wherein the M use cases are M business sub-functions split from the product function based on the entity analysis result, and the association relationship is used to identify entities involved in the implementation of the business sub-function corresponding to the use case, and M>1;
[0229] According to the association relationship, a microservice object having conditions for conversion into a microservice is determined from the M use cases and the N entities, and the microservice object includes at least one of a target entity or a target use case.
[0230] If the computer device is a server, the present application embodiment also provides a server, see Figure 7 As shown, Figure 7The structural diagram of the server 1500 provided in the embodiment of the present application, the server 1500 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPU) 1522 (for example, one or more processors) and a memory 1532, and one or more storage media 1530 (for example, one or more mass storage devices) storing application programs 1542 or data 1544. Among them, the memory 1532 and the storage medium 1530 can be short-term storage or permanent storage. The program stored in the storage medium 1530 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations in the server. Furthermore, the central processing unit 1522 can be configured to communicate with the storage medium 1530 and execute a series of instruction operations in the storage medium 1530 on the server 1500.
[0231] The server 1500 may also include one or more power supplies 1526, one or more wired or wireless network interfaces 1550, one or more input and output interfaces 1558, and / or one or more operating systems 1541, such as Windows Server 2003 or Windows Server 2008. TM , Mac OS X TM , Unix TM ,Linux TM , FreeBSD TM etc.
[0232] The steps performed by the server in the above embodiment can be based on Figure 7 The server structure shown.
[0233] In addition, an embodiment of the present application further provides a storage medium, wherein the storage medium is used to store a computer program, and the computer program is used to execute the method provided in the above embodiment.
[0234] The embodiments of the present application also provide a computer program product including a computer program, which, when executed on a computer device, enables the computer device to execute the method provided in the above embodiments.
[0235] A person skilled in the art can understand that all or part of the steps of implementing the above method embodiment can be completed by hardware related to program instructions, and the above program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above method embodiment; and the above storage medium can be at least one of the following media: read-only memory (English: Read-only Memory, abbreviated: ROM), RAM, magnetic disk or optical disk, etc. Various media that can store computer programs.
[0236] It should be noted that each embodiment in this specification is described in a progressive manner, and the same and similar parts between the embodiments can refer to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can refer to the partial description of the method embodiments. The device and system embodiments described above are merely schematic, in which the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative work.
[0237] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions that can be easily thought of by a technician familiar with the technical field within the technical scope disclosed in the present application should be included in the protection scope of the present application. Moreover, based on the implementation methods provided in the above aspects, the present application can also be further combined to provide more implementation methods. Therefore, the protection scope of the present application should be based on the protection scope of the claims.
Claims
1. A microservice determination method, characterized in that: The method comprises: Acquire business demand information to be processed, where the business demand information is used to describe product functions of a target product; Determine an entity analysis result corresponding to the business requirement information through a semantic understanding model, wherein the entity analysis result includes N entities involved in the business requirement information, and the entities are used to identify objects that implement business sub-functions in the product function, where N>1; Determine, according to the entity analysis result, an association relationship between M use cases and the N entities, wherein the M use cases are M business sub-functions split from the product function based on the entity analysis result, and the association relationship is used to identify entities involved in the implementation of the business sub-function corresponding to the use case, and M>1; According to the association relationship, a microservice object having conditions for conversion into a microservice is determined from the M use cases and the N entities, and the microservice object includes at least one of a target entity or a target use case.
2. The method according to claim 1, characterized in that The object to be identified is one of the M use cases or one of the N entities. For the object to be identified, determining a microservice object having conditions for conversion into a microservice from the M use cases and the N entities according to the association relationship includes: Based on the association relationship of the object to be identified, determining the association strength between the object to be identified and the M use cases and the N entities; According to the association strengths respectively corresponding to the M use cases and the N entities, it is determined whether the object to be identified has the conditions for being converted into a microservice.
3. The method according to claim 1, characterized in that Determining the association relationship between the M use cases and the N entities according to the entity analysis result includes: An N*M use case matrix is determined according to the entity analysis result, and the use case matrix is used to identify the association relationship between the M use cases and the N entities, wherein the element in the i-th row and j-th column in the use case matrix is used to identify whether there is an association relationship between the i-th entity among the N entities and the j-th use case among the M use cases.
4. The method according to claim 1, characterized in that Determining the association relationship between the M use cases and the N entities according to the entity analysis result includes: Determine the association relationship between the M use cases and the N entities according to the business requirement information and the entity analysis result.
5. The method according to claim 1, characterized in that Determining the association relationship between the M use cases and the N entities according to the entity analysis result includes: According to the entity analysis results, the association relationship between the M use cases and the N entities is determined by a relationship analysis model, wherein the relationship analysis model is trained based on training samples marked with the association relationship between the use cases and the entities, and the training samples are determined based on sample products that have completed the use case and entity splitting.
6. The method according to claim 1, characterized in that The determining, according to the association relationship, from the M use cases and the N entities, a microservice object that meets the conditions for conversion into a microservice, includes: According to the interactive behavior parameters for the target product and the association relationship, a microservice object that meets the conditions for conversion into a microservice is determined from the M use cases and the N entities, wherein the interactive behavior parameters include at least one of the interactive behavior traffic or behavior response information corresponding to the business sub-function.
7. The method according to any one of claims 1 to 6, characterized in that: The method further comprises: According to the determined microservice object, a corresponding microservice is generated, or a microservice corresponding to the microservice object is determined from existing microservices.
8. The method according to claim 7, characterized in that The method further comprises: Through the continuous integration / continuous deployment CI / CD module, during the operation of the target product, traffic allocation and code update are performed on the microservices corresponding to the microservice objects.
9. The method according to any one of claims 1 to 6, characterized in that: The entity analysis result also includes the business relationships between the N entities.
10. The method according to claim 9, characterized in that The determining the entity analysis result corresponding to the business requirement information by using the semantic understanding model includes: A class diagram reflecting the entity analysis result is generated through a semantic understanding model, the nodes in the class diagram are used to identify entities, and the edges between the nodes are used to identify the business relationships.
11. A microservice determination device, characterized in that: The device comprises an acquisition unit and a determination unit: The acquisition unit is used to acquire the business demand information to be processed, where the business demand information is used to describe the product function of the target product; The determining unit is used to determine the entity analysis result corresponding to the business requirement information through a semantic understanding model, wherein the entity analysis result includes N entities involved in the business requirement information, and the entities are used to identify objects that implement business sub-functions in the product function, where N>1; The determining unit is further used to determine the association relationship between the M use cases and the N entities according to the entity analysis result, the M use cases are M business sub-functions split from the product function based on the entity analysis result, and the association relationship is used to identify the entity involved in the implementation of the business sub-function corresponding to the use case, M>1; The determining unit is further configured to determine, according to the association relationship, a microservice object having conditions for conversion into a microservice from the M use cases and the N entities, wherein the microservice object includes at least one of a target entity or a target use case.
12. A computer device, characterized in that: The computer device comprises a processor and a memory: The memory is used to store a computer program and transmit the computer program to the processor; The processor is configured to execute the method according to any one of claims 1 to 10 according to the computer program.
13. A computer-readable storage medium, characterized in that: The computer-readable storage medium is used to store a computer program, and when the computer program is executed by a computer device, the method according to any one of claims 1 to 10 is implemented.
14. A computer program product comprising a computer program, which, when executed on a computer device, causes the computer device to execute the method according to any one of claims 1 to 10.