Micro-service splitting suggestion method, device, storage medium and electronic device

Abstract

The present disclosure provides a microservice splitting suggestion method, device, computer readable storage medium and electronic equipment, and relates to the field of cloud services. The microservice splitting suggestion method comprises: constructing an initial microservice architecture graph based on communication traffic information between microservices, the initial microservice architecture graph comprising microservice nodes and links connecting the microservice nodes; determining a microservice node in the initial microservice architecture graph whose stress score satisfies a preset node splitting condition as a suggested splitting node; determining the initial microservice architecture graph after splitting the suggested splitting node as an intermediate microservice architecture graph, cutting the intermediate microservice architecture graph into one or more target microservice architecture graphs based on the weights of the links in the intermediate microservice architecture graph, and determining a suggested merging node in the microservice node according to the merging score of each subgraph in the target microservice architecture graph. The present disclosure improves the microservice splitting efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of cloud services, and more particularly to a microservice decomposition proposal method, a microservice decomposition proposal apparatus, a computer-readable storage medium, and an electronic device. Background Technology

[0002] With the advancement of industrial digital transformation, system microservices have become an inevitable choice in communication services. System microservices first break down large communication systems into multiple medium-sized communication systems. As service functions expand and service volume increases, medium-sized communication systems are further broken down into multiple small communication systems. It is evident that microservice decomposition is an important part of system microservices.

[0003] In related technologies, microservice architecture decomposition requires manual work by staff based on Domain Driven Design (DDD) and experience. Clearly, this method incurs high manpower and time costs, making microservice decomposition inefficient. Summary of the Invention

[0004] This disclosure provides a microservice decomposition proposal method, a microservice decomposition proposal apparatus, a computer-readable storage medium, and an electronic device, thereby improving the problem of low efficiency in microservice decomposition to at least some extent.

[0005] Other features and advantages of this disclosure will become apparent from the following detailed description, or may be learned in part from practice of this disclosure.

[0006] According to a first aspect of this disclosure, a method for proposing microservice splitting is provided, comprising: constructing an initial microservice architecture diagram based on communication traffic information between microservices, the initial microservice architecture diagram including microservice nodes and links connecting the microservice nodes; determining microservice nodes in the initial microservice architecture diagram whose pressure scores meet preset node splitting conditions as proposed splitting nodes; determining the initial microservice architecture diagram with the proposed splitting nodes as an intermediate microservice architecture diagram; in the intermediate microservice architecture diagram, dividing the intermediate microservice architecture diagram into one or more target microservice architecture diagrams based on the weights of the links; and determining proposed merging nodes at the microservice nodes according to the merging scores of each subgraph in the target microservice architecture diagrams.

[0007] Optionally, the method further includes: determining the recommended number of microservices to be supported based on the ratio of the number of microservice maintenance team members to the number of microservices requiring maintenance; and issuing a signal to recommend merging microservices when the number of microservice nodes in the initial microservice architecture diagram is greater than the recommended number of microservices to be supported; and identifying microservice nodes with pressure scores higher than a preset pressure score threshold as high-scoring microservice nodes in the initial microservice architecture diagram, and issuing a signal to recommend splitting microservices when the number of high-scoring microservice nodes reaches a split alarm threshold.

[0008] Optionally, constructing the initial microservice architecture diagram based on communication traffic information between microservices includes: determining the microservice nodes according to the microservices; determining the links connecting the microservice nodes based on the communication traffic information between the microservices; and connecting the corresponding microservice nodes connected to the links to construct the initial microservice architecture diagram.

[0009] Optionally, determining the microservice nodes whose pressure scores meet the preset node splitting conditions in the initial microservice architecture diagram as suggested splitting nodes includes: determining the pressure score of each microservice node based on the weighted sum of the communication traffic information corresponding to each microservice node and the correlation information of the database table; determining the top N microservice nodes with the highest pressure scores in the initial microservice architecture diagram as suggested splitting nodes; or, determining the microservice nodes whose pressure scores are greater than the preset pressure score threshold as suggested splitting nodes (N is a natural number).

[0010] Optionally, before dividing the intermediate microservice architecture diagram into one or more target microservice architecture diagrams based on the weight of the link, the method further includes: determining the weight of the link based on the sum of the communication traffic information corresponding to the microservice nodes connected by the link and the association information of the database table.

[0011] Optionally, the step of dividing the intermediate microservice architecture graph into one or more target microservice architecture graphs based on the weight of the link includes: dividing the links whose weights satisfy preset dividing conditions, so as to obtain the one or more target microservice architecture graphs based on the connectivity graph in the divided intermediate microservice architecture graph.

[0012] Optionally, determining the recommended merging node in the microservice node based on the merging score of each subgraph in the target microservice architecture diagram includes: determining the merging score of the microservice node based on the weight of the link and the ratio of the sum of the pressure scores of the microservice nodes connected to the link; determining the N microservice nodes with the highest merging scores as recommended merging nodes; or, determining the microservice nodes with merging scores greater than a preset merging score threshold as recommended merging nodes.

[0013] According to a second aspect of this disclosure, a microservice splitting suggestion apparatus is provided, comprising: an initial microservice architecture diagram generation module configured to construct an initial microservice architecture diagram based on communication traffic information between microservices, the initial microservice architecture diagram including microservice nodes and links connecting the microservice nodes; a suggested splitting node determination module configured to determine microservice nodes in the initial microservice architecture diagram whose pressure scores meet preset node splitting conditions as suggested splitting nodes; and a suggested merging node determination module configured to determine the initial microservice architecture diagram with the suggested splitting nodes as an intermediate microservice architecture diagram, wherein the intermediate microservice architecture diagram is segmented into one or more target microservice architecture diagrams based on the weights of the links, and suggested merging nodes are determined at the microservice nodes according to the merging scores of each subgraph in the target microservice architecture diagram.

[0014] According to a third aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the microservice decomposition proposal method of the first aspect and its possible implementations.

[0015] According to a fourth aspect of this disclosure, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor. The processor is configured to execute the microservice decomposition proposal method and its possible implementations described in the first aspect by executing the executable instructions.

[0016] The technical solution disclosed herein has the following beneficial effects:

[0017] On the one hand, this solution automates the generation of microservice decomposition suggestions, significantly improving decomposition efficiency compared to manual analysis of the microservice architecture by staff, which relies on experience for decomposition. On the other hand, this solution generates a microservice architecture diagram by combining communication traffic information between microservices and determines suggested decomposition nodes and suggested merging nodes based on pressure scores and merging scores, respectively. Compared to the method where staff rely solely on subjective judgment to determine the decomposition plan, this solution provides a reference for staff to decompose microservices, avoiding the problem of having no reference when staff propose conflicting decomposition plans. This makes the obtained suggested decomposition nodes and suggested merging nodes more reliable and further improves the reliability of the decomposition process.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0020] Figure 1 This illustrates the system operating architecture of this exemplary embodiment;

[0021] Figure 2 This diagram illustrates a flowchart of a microservice splitting proposal method in this exemplary embodiment;

[0022] Figure 3 This diagram illustrates a process for obtaining an initial microservice architecture diagram in this exemplary embodiment.

[0023] Figure 4 This illustration shows a flowchart of a process for determining a suggested split node in this exemplary embodiment;

[0024] Figure 5A This diagram illustrates an initial microservice architecture diagram in this exemplary embodiment.

[0025] Figure 5B A schematic diagram illustrating a first microservice architecture in this exemplary embodiment is shown.

[0026] Figure 5C A schematic diagram illustrating a target microservice architecture in this exemplary embodiment is shown.

[0027] Figure 5D A schematic diagram showing a sub-diagram in this exemplary embodiment;

[0028] Figure 6 This illustration shows a flowchart of a process for determining a recommended merge node in this exemplary embodiment;

[0029] Figure 7 This diagram illustrates an information collection process according to this exemplary embodiment;

[0030] Figure 8 This diagram illustrates the structure of a microservice splitting recommendation device in this exemplary embodiment.

[0031] Figure 9 A schematic diagram of the structure of an electronic device in this exemplary embodiment is shown. Detailed Implementation

[0032] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this disclosure more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a full understanding of embodiments of this disclosure. However, those skilled in the art will recognize that the technical solutions of this disclosure can be practiced with one or more specific details omitted, or other methods, components, apparatus, steps, etc., can be employed. In other instances, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of this disclosure.

[0033] Furthermore, the accompanying drawings are merely illustrative of this disclosure and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0034] In related technologies, staff typically perform microservice architecture decomposition manually based on Domain Driven Design (DDD) and previous decomposition experience. However, due to differing understandings of the business by each staff member and the lack of readily available data for reference during the microservice decomposition process, inefficiency in discussing decomposition solutions is common. Furthermore, because the microservice decomposition process is highly dependent on staff, when the microservice architecture is large and there are numerous decomposition requirements, staff need to expend a significant amount of time and effort, resulting in low efficiency in microservice decomposition.

[0035] In view of one or more of the above-mentioned problems, this disclosure first provides a microservice decomposition recommendation method through exemplary embodiments. The following is in conjunction with... Figure 1 The system architecture of the operating environment for this exemplary embodiment will be described.

[0036] refer to Figure 1 As shown, system architecture 100 may include terminal device 110 and server 120. Terminal device 110 may be an electronic device such as a laptop, tablet, or desktop computer, and can be used to build an initial microservice architecture diagram. Server 120 generally refers to the backend system that provides services related to microservice decomposition suggestions in this exemplary embodiment, such as a server that implements the microservice decomposition suggestion method. Server 120 may be a single server or a cluster of multiple servers, and this disclosure does not limit this. Terminal device 110 and server 120 can be connected via wired or wireless communication links for data interaction.

[0037] The microservice decomposition suggestion method in this exemplary embodiment can be executed by the terminal device 110. For example, the terminal device 110 can be a computer used by staff. Before decomposing the microservice architecture, staff can execute the microservice decomposition suggestion method on the terminal device 110 to obtain suggested decomposition nodes and suggested merging nodes. Staff can formulate a microservice decomposition plan based on the suggested decomposition nodes, suggested merging nodes, and their own experience, thereby improving the efficiency of microservice decomposition.

[0038] In one implementation, terminal device 110 can monitor the communication traffic information between microservices and send the communication traffic information to server 120. After receiving the communication traffic information, server 120 constructs an initial microservice architecture diagram based on the communication traffic information between microservices, and determines the microservice nodes in the initial microservice architecture diagram whose pressure scores meet the preset node splitting conditions as suggested splitting nodes. Then, based on the pressure scores of the microservice nodes in the initial microservice architecture diagram and the weights of the links, the microservice nodes are split into one or more target microservice architecture diagrams. Finally, based on the merging score of each microservice node in the target microservice architecture diagram, suggested merging nodes are determined among the microservice nodes.

[0039] As can be seen from the above, the microservice splitting suggestion method in this exemplary embodiment can be executed by the terminal device 110 or the server 120.

[0040] The following is combined Figure 2 This section explains the recommended approach for microservice decomposition. Figure 2 An exemplary flow of a microservice decomposition proposal method is shown, including the following steps S210 to S230:

[0041] Step S210: Construct an initial microservice architecture diagram based on the communication traffic information between microservices. The initial microservice architecture diagram includes microservice nodes and links connecting the microservice nodes.

[0042] Step S220: In the initial microservice architecture diagram, the microservice nodes whose pressure scores meet the preset node splitting conditions are identified as recommended splitting nodes.

[0043] Step S230: The initial microservice architecture diagram with the proposed split nodes is determined as the intermediate microservice architecture diagram. In the intermediate microservice architecture diagram, the intermediate microservice architecture diagram is divided into one or more target microservice architecture diagrams based on the weight of the links. Based on the merging score of each subgraph in the target microservice architecture diagram, the proposed merging node is determined at the microservice node.

[0044] Based on the above method, on the one hand, it achieves automated generation of microservice decomposition suggestions, greatly improving decomposition efficiency compared to the method of manually analyzing the microservice architecture and then decomposing microservices based on experience. On the other hand, this solution can generate a microservice architecture diagram by combining communication traffic information between microservices, and determine suggested decomposition nodes and suggested merging nodes based on pressure scores and merging scores, respectively. Compared to the method of staff determining the decomposition plan solely based on subjective judgment, this provides a reference for staff to decompose microservices, and to a certain extent avoids the problem of having no reference when staff propose conflicting microservice decomposition plans. This makes the obtained suggested decomposition nodes and suggested merging nodes more referential, further improving the reliability of the decomposition process.

[0045] The following is about Figure 2 Each step in the process will be explained in detail.

[0046] refer to Figure 2 In step S210, an initial microservice architecture diagram is constructed based on the communication traffic information between microservices. The initial microservice architecture diagram includes microservice nodes and links connecting the microservice nodes.

[0047] The communication traffic information can be information used to characterize the communication business relevance between microservices. This disclosure does not specifically limit the method of obtaining communication traffic information. For example, communication traffic information may include the data transmission volume and direction between microservices, and can be obtained through a third-party monitoring component. The initial microservice architecture diagram can be a topology diagram used to characterize the connection relationship between microservices and the degree of business correlation between microservices. Microservice nodes are used to represent microservices in the initial microservice architecture diagram, and links are used to characterize the connection relationship between microservices.

[0048] In one implementation, the above-mentioned initial microservice architecture diagram is constructed based on communication traffic information between microservices, referencing... Figure 3 As shown, steps S310 to S320 may be included:

[0049] Step S310: Determine the microservice nodes based on the microservices, and determine the links connecting the microservice nodes based on the communication traffic information between the microservices;

[0050] Step S320: Connect the corresponding microservice nodes connected to the link using the link to build the initial microservice architecture diagram.

[0051] For example, an initial microservice architecture diagram can be obtained by using microservice nodes to represent microservices, connecting microservice nodes with data transmission relationships using links, and determining the direction of the links based on the data transmission direction between microservices (i.e., communication traffic information).

[0052] Obtaining the initial microservice architecture diagram based on the communication traffic information between microservices can clearly show the data transmission relationship between microservices, which is beneficial to improving the efficiency of microservice decomposition.

[0053] Continue to refer to Figure 2 In step S220, the microservice nodes in the initial microservice architecture diagram whose pressure scores meet the preset node splitting conditions are identified as recommended splitting nodes.

[0054] The stress score can be a metric used to characterize the communication pressure on microservice nodes. A higher stress score indicates greater service pressure on the microservice node, making it more likely to be split. Suggested split nodes can include recommended microservice nodes for splitting. Preset node splitting conditions can serve as the basis for determining whether a microservice node needs to be split.

[0055] In one implementation, the microservice nodes in the initial microservice architecture diagram that meet the preset node splitting conditions are identified as recommended splitting nodes, as referenced. Figure 4 As shown, steps S410 to S420 may be included:

[0056] Step S410: Determine the pressure score of each microservice node based on the weighted sum of the communication traffic information corresponding to each microservice node and the correlation information of the database table.

[0057] The database tables can include tables in the database of the microservice corresponding to the microservice node. The association information of the database tables can be used to characterize the communication service association between the microservice node and the microservice nodes it communicates with, and can also reflect the communication frequency between the microservice node and the microservice nodes it communicates with. This disclosure does not impose special limitations on the method of obtaining the association of the database tables. For example, the association degree of the database tables can be obtained based on the number of database tables in the microservice node and the database access volume. The number of tables in each database of the microservice should not be too large, as too many tables make the microservice difficult to maintain. Database access volume can be obtained by collecting microservice database log information, and the database access volume can characterize the data exchange pressure of the microservice node.

[0058] In one implementation, determining the stress score for each microservice node based on the weighted sum of communication traffic information corresponding to each microservice node and the correlation information of the database table may include the following steps:

[0059] The communication traffic value and the correlation value are obtained based on the correlation information between the communication traffic information and the database table;

[0060] Obtain communication traffic values ​​and their corresponding weights based on the correlation values. Calculate the pressure score for each microservice node based on the communication traffic values, correlation values, and their respective weights.

[0061] The communication traffic value and correlation value can be communication traffic data directly extracted from communication traffic information, or the number of database tables and database access volume extracted based on the correlation information of database tables. Alternatively, they can be the processing results obtained after processing the communication traffic data, the number of database tables, and the database access volume. This disclosure does not impose any special limitations on the method of obtaining the communication traffic value and correlation value. For example, the communication traffic value and correlation value can be obtained by standardizing the correlation information between the communication traffic information and the database tables.

[0062] It should be noted that the stress score can be directly calculated based on the weighted sum of communication traffic information and the correlation information of the database table, or it can be obtained from the data processing result of the weighted sum of communication traffic information and the correlation information of the database table. This disclosure does not impose any special limitation on the data processing method. For example, data processing may include standardizing the weighted sum of communication traffic information and the correlation information of the database table to obtain the stress score.

[0063] For example, the correlation information between communication traffic information and database tables can be standardized using other standardization methods such as min-max, z-score standardization, and decimal scaling to obtain standard values ​​for communication traffic, database table data, and database access volume. Then, the CRITIC weighting method can be used to determine the first weight corresponding to the standard value of communication traffic, the second weight corresponding to the standard value of database table data, and the third weight corresponding to the standard value of database access volume, based on the correlation between these three values. Alternatively, the first, second, and third weights can be determined manually based on these values. Finally, the pressure score of the microservice node is obtained by standardizing the weighted sum of the standard values ​​of communication traffic, database table data, and database access volume, along with the first, second, and third weights.

[0064] The method described above, which determines the stress score by weighting the correlation between communication traffic information and database table information, reduces the complexity of obtaining the stress score. At the same time, it comprehensively determines the stress score from dimensions such as the correlation between communication traffic and database, making the obtained stress score more reliable.

[0065] Step S420: In the initial microservice architecture diagram, the top N microservice nodes with the highest pressure scores are identified as recommended split nodes; or, the microservice nodes with pressure scores greater than a preset pressure score threshold are identified as recommended split nodes (N is a natural number).

[0066] The preset pressure score threshold can be used as a basis for judging whether the pressure of a microservice exceeds the service pressure that the microservice can bear. This disclosure does not make any special restrictions on the specific value and acquisition method of the preset pressure score threshold. For example, the preset pressure score threshold can be 0.5.

[0067] For example, if the stress scores of the microservice nodes in the initial microservice architecture diagram are 0.7, 0.8, 0.2, 0.9, and 0.1, then the stress scores are ranked from highest to lowest as follows: 0.9, 0.8, 0.7, 0.2, and 0.1. Therefore, the microservice node with a stress score of 0.8 and the microservice node with a stress score of 0.9 can be identified as the recommended split nodes.

[0068] In one implementation, after determining the pressure score of each microservice node based on a weighted sum of communication traffic information corresponding to each microservice node and the correlation information of the database table, the above method may further include:

[0069] The pressure level is determined based on the pressure score of the microservice node, and the microservice nodes with the preset pressure level splitting conditions are identified as recommended splitting nodes.

[0070] The pressure level is determined based on the pressure score and is an indicator used to assess the service pressure of a microservice node. The higher the pressure level, the more likely the microservice node needs to be split. For example, the pressure score can range from 0 to 1. Therefore, a pressure score of [0, 0.2] is determined as "Level 1"; a pressure score of (0.2, 0.4] is determined as "Level 2"; a pressure score of (0.4, 0.6) is determined as "Level 3"; and a pressure score of (0.6, 1) is determined as "Level 4". The preset splitting level condition can be the basis for determining whether a microservice node needs to be split based on the pressure level. This disclosure does not specifically limit the content of the preset splitting level condition. For example, the preset splitting level condition could be that when the pressure level is greater than a preset pressure level threshold, the microservice node corresponding to that pressure level is identified as a recommended splitting node. Alternatively, it could be that the top N microservice nodes with the highest pressure levels in the initial microservice architecture diagram are identified as recommended splitting nodes.

[0071] Determining the pressure level based on the pressure score of the microservice node can more intuitively reflect the service pressure of the microservice node and help improve the speed of determining the recommended node splitting.

[0072] based on Figure 4The method identifies microservice nodes with high pressure scores as recommended splitting nodes, making the identified recommended splitting nodes more reliable and providing a basis for staff to formulate microservice splitting plans, thereby further improving the efficiency of microservice splitting.

[0073] Continue to refer to Figure 2 In step S230, the initial microservice architecture diagram with the proposed split nodes is determined as the intermediate microservice architecture diagram. In the intermediate microservice architecture diagram, the intermediate microservice architecture diagram is divided into one or more target microservice architecture diagrams based on the weight of the links. Based on the merging score of each subgraph in the target microservice architecture diagram, the proposed merging node is determined at the microservice node.

[0074] The merge score is a metric used to evaluate whether microservice nodes need to be merged. Recommended merge nodes can include microservice nodes that are recommended for merging. The intermediate microservice architecture diagram can be the microservice architecture diagram obtained after splitting the recommended split nodes from the initial microservice architecture diagram. The link weight reflects the communication frequency and data volume between microservice nodes connected by that link. The target microservice architecture diagram can be a connected graph obtained after splitting the first microservice architecture diagram. Subgraphs can be architecture diagrams composed of microservice nodes and links with data transmission relationships in the target microservice architecture diagram.

[0075] In one implementation, before dividing the intermediate microservice architecture graph into one or more target microservice architecture graphs based on link weights, the following steps may also be included:

[0076] The weight of the link is determined by summing the communication traffic information of the microservice nodes connected by the link with the association information of the database table.

[0077] It should be noted that the weight can be directly calculated based on the sum of communication traffic information and the correlation information of the database table, or it can be obtained from the data processing result of the sum of communication traffic information and the correlation information of the database table. This disclosure does not impose any special limitation on the data processing method. For example, data processing may include standardizing the sum of communication traffic information and the correlation information of the database table to obtain the weight.

[0078] For example, based on the communication traffic information of the microservice nodes connected to the link, and the standardized values ​​of the correlation information in the database table, the communication traffic value and the correlation value can be obtained. Then, the sum of the communication traffic value and the correlation value is standardized to determine the link weight. Figure 5A As shown, Figure 5A An initial microservice architecture diagram is shown, which includes microservice node 510, link 520, pressure score 530, and weight 540. Because... Figure 5A The two microservice nodes with the highest stress scores are microservice node 2 and microservice node 8. Therefore, microservice node 2 and microservice node 8 are identified as the recommended split nodes. After splitting the recommended split nodes in the initial microservice architecture diagram, we can obtain... Figure 5B The diagram shows the intermediate microservice architecture.

[0079] By combining communication traffic information and the correlation information of database tables to obtain the link weight, the obtained weight can integrate information from multiple dimensions, thus making the weight more reliable.

[0080] In one implementation, the aforementioned root-based segmentation of the intermediate microservice architecture graph into one or more target microservice architecture graphs based on link weights may include the following steps:

[0081] Links whose weights meet preset cutting conditions are cut, and one or more target microservice architecture diagrams are obtained based on the connectivity graph in the intermediate microservice architecture diagram after cutting.

[0082] The preset cutting conditions are used as the basis for determining whether a micro-link needs to be cut. This disclosure does not specifically limit the content of the preset cutting conditions. For example, the preset cutting conditions may be to cut the link corresponding to the weight when the weight is less than the preset weight threshold, or to cut the first N links with the smallest weight in the first microservice architecture diagram.

[0083] For example, a middleware microservice architecture diagram can be as follows: Figure 5B As shown in the intermediate microservice architecture diagram, the stress score and weight have been standardized, so the values ​​range from 0 to 1; with a preset splitting threshold of 0.5, the stress score and weight are... Figure 5B In the process, links with a weight less than 0.5 are cut off. Figure 5B In the process, links 521 and 522 are cut. After cutting links 521 and 522, the following can be obtained: Figure 5C The connected graph shown is the target microservice architecture diagram.

[0084] By cutting links that meet preset cutting conditions in the intermediate microservice architecture diagram, the service correlation between microservice nodes in the resulting target microservice architecture diagram can be stronger. This ensures that the suggested merge nodes obtained based on the target microservice architecture diagram are more reliable and helps improve the reliability of the microservice decomposition process.

[0085] In one implementation, the above-mentioned method determines the recommended merging node at the microservice node level based on the merging score of each subgraph in the target microservice architecture diagram, referring to... Figure 6 As shown, steps S610 to S630 may be included:

[0086] Step S610: Determine one or more sub-graphs in the target microservice architecture diagram according to the data transmission direction of the link;

[0087] Step S620: Determine the merge score of the subgraph based on the ratio of the sum of the weights of the links in the subgraph to the sum of the pressure scores of the microservice nodes connected by the links.

[0088] Step S630: Determine the microservice nodes in the N subgraphs with the highest merging scores as recommended merging nodes; or, determine the microservice nodes in the subgraphs with merging scores greater than a preset merging score threshold as recommended merging nodes.

[0089] The preset merging score threshold is used as the basis for determining whether microservice nodes need to be merged. This disclosure does not impose any special limitation on the specific value of the preset merging score threshold. For example, the preset merging score threshold can be 0.5.

[0090] For example, in obtaining Figure 5C After seeing the target microservice architecture diagram, you can then... Figure 5C The data transmission direction of the mid-link is in Figure 5C Determine the subgraph in the middle, refer to Figure 5D As shown, subgraphs 551, 552, 553, 554, and 555 are included. The merging score of a subgraph is determined based on the ratio of the sum of the weights of the links in the subgraph to the sum of the pressure scores of the microservice nodes connected by those links. For example, if subgraph 551 includes microservice nodes 4 and 7, and a link with a weight of 0.8, then the merging score of subgraph 551 is 0.8 / (0.2+0.3); the merging score of subgraph 552 is 1.3 / 1; the merging score of subgraph 553 is 0.5 / 0.7; the merging score of subgraph 554 is 0.5 / 0.9; and the merging score of subgraph 555 is 0.5 / 0.6. Therefore, microservice nodes 4 and 7 in subgraph 551, which have the highest merging score, are identified as recommended merging nodes.

[0091] based on Figure 6 The method identifies the microservice nodes in the subgraph with the highest merging score as the recommended merging nodes. This ensures that microservice nodes with strong inter-service relationships and low service pressure are identified as recommended merging nodes, thereby improving the reference value of the obtained recommended merging nodes.

[0092] In one embodiment, the above method may further include:

[0093] Based on the ratio of the number of microservice maintenance team members to the number of microservice maintenance personnel required, determine the recommended number of microservices to support. If the number of microservice nodes in the initial microservice architecture diagram is greater than the recommended number of microservices to support, issue a signal to merge microservices.

[0094] In the initial microservice architecture diagram, microservice nodes with stress scores higher than the preset stress score threshold are identified as high-scoring microservice nodes. When the number of high-scoring microservice nodes reaches the split alarm threshold, a signal is issued suggesting the splitting of microservices.

[0095] The recommended number of microservices can be determined by comprehensively considering the number of microservice maintenance team members and the number of personnel required to maintain each microservice. The "Suggest merging microservices" signal alerts staff when the current number of microservices exceeds the maintenance team's capacity, reminding them to merge microservices to reduce the number of microservices the maintenance team needs to maintain. This disclosure does not specifically limit the content of the "Suggest merging microservices" signal; for example, it could be a pop-up window containing the message "Suggest merging microservices". High-scoring microservice nodes can be microservice nodes with high pressure scores in the initial microservice architecture diagram. The "Suggest splitting microservices" signal alerts staff when there are many high-pressure microservice nodes in the initial microservice architecture diagram, reminding them to split microservices to reduce service pressure. This disclosure does not specifically limit the content of the "Suggest splitting microservices" signal; for example, it could be a pop-up window containing the message "Suggest splitting microservices".

[0096] By automatically detecting when the number of microservices in the initial microservice architecture diagram exceeds the maintenance capacity of the maintenance team and issuing a signal to suggest merging microservices, and reminding staff to split microservices when the service pressure of microservices in the initial microservice architecture diagram is high, the system can automatically detect the service status of microservices and report them in a timely manner when anomalies are about to occur, thereby further improving the reliability of microservices.

[0097] For example, after discussing communication system requirements, staff can briefly decompose existing microservices based on their experience and business type; then, they can execute the microservice decomposition suggestion method of this exemplary embodiment on the terminal device. Before executing the microservice decomposition suggestion method of this exemplary embodiment, information collection is first required, referring to... Figure 7As shown, application interface data (such as API (Application Programming Interface), RPC remote service call, and SideCar call information) of microservices can be collected from the database tables and code of microservices. Service dynamic data (such as inter-service communication traffic, traffic flow, number of database tables, and database access volume) can be obtained through third-party monitoring components and database logs, as well as team information (including the number of microservice maintenance personnel and the number of personnel required for each microservice) can be collected manually. The application interface data, service dynamic data, and team information are stored in the data storage unit.

[0098] After storing the application interface data, service dynamic data, and team information in the data storage unit, staff can obtain the application interface data, service dynamic data, and team information in the data storage unit by executing the microservice splitting suggestion method of this exemplary embodiment. Based on the application interface data, service dynamic data, and team information, staff can obtain suggested merge nodes and suggested split nodes. Staff can also automatically monitor the microservice nodes in the initial microservice architecture diagram and issue suggested merge microservice signals or suggested split microservice signals.

[0099] For example, after receiving a signal suggesting the splitting of microservices, staff can execute the microservice splitting suggestion method of this exemplary implementation to obtain suggested merge nodes and suggested split nodes. At this time, staff can combine their own experience with the suggested merge nodes and suggested split nodes recommended by the microservice splitting suggestion method to determine the final microservice splitting scheme, so as to split the microservices based on the microservice splitting scheme.

[0100] Based on the above methods, the efficiency of microservice decomposition and the reliability of the microservice decomposition process are improved.

[0101] Exemplary embodiments of this disclosure also provide a face model generation apparatus. For example... Figure 8 As shown, the face model generation device 800 may include:

[0102] The initial microservice architecture diagram generation module 810 is configured to construct an initial microservice architecture diagram based on the communication traffic information between microservices. The initial microservice architecture diagram includes microservice nodes and links connecting the microservice nodes.

[0103] The recommended splitting node determination module 820 is configured to determine microservice nodes in the initial microservice architecture diagram that meet the preset node splitting conditions as recommended splitting nodes.

[0104] The module 830 for determining the recommended merge node is configured to determine the initial microservice architecture diagram, which has been split into recommended split nodes, as an intermediate microservice architecture diagram. In the intermediate microservice architecture diagram, the intermediate microservice architecture diagram is divided into one or more target microservice architecture diagrams based on the weight of the links, and the recommended merge node is determined at the microservice node according to the merging score of each subgraph in the target microservice architecture diagram.

[0105] In one embodiment, the above-mentioned apparatus may further include:

[0106] Based on the ratio of the number of microservice maintenance team members to the number of microservice maintenance personnel required, determine the recommended number of microservices to support. If the number of microservice nodes in the initial microservice architecture diagram is greater than the recommended number of microservices to support, issue a signal to merge microservices.

[0107] In the initial microservice architecture diagram, microservice nodes with stress scores higher than the preset stress score threshold are identified as high-scoring microservice nodes. When the number of high-scoring microservice nodes reaches the split alarm threshold, a signal is issued suggesting the splitting of microservices.

[0108] In one implementation, the above-mentioned construction of the initial microservice architecture diagram based on communication traffic information between microservices may include:

[0109] Microservice nodes are determined based on microservices, and the links connecting microservice nodes are determined based on the communication traffic information between microservices.

[0110] Connect the corresponding microservice nodes on the link using the link to build the initial microservice architecture diagram.

[0111] In one implementation, determining the microservice nodes whose stress scores meet the preset node splitting conditions in the initial microservice architecture diagram as recommended splitting nodes may include:

[0112] The pressure score for each microservice node is determined by a weighted sum of communication traffic information corresponding to each microservice node and the correlation information of the database table.

[0113] In the initial microservice architecture diagram, the top N microservice nodes with the highest stress scores are identified as recommended split nodes; or, microservice nodes with stress scores greater than a preset stress score threshold are identified as recommended split nodes (N is a natural number).

[0114] In one implementation, before segmenting the intermediate microservice architecture graph into one or more target microservice architecture graphs based on link weights, the above apparatus may further include:

[0115] The weight of the link is determined by summing the communication traffic information of the microservice nodes connected by the link with the association information of the database table.

[0116] In one implementation, the link-based weighting that segments the intermediate microservice architecture graph into one or more target microservice architecture graphs may include:

[0117] Links whose weights meet preset cutting conditions are cut, and one or more target microservice architecture diagrams are obtained based on the connectivity graph in the intermediate microservice architecture diagram after cutting.

[0118] In one implementation, determining the recommended merging node at the microservice node based on the merging score of each subgraph in the target microservice architecture graph may include:

[0119] The combined score of a microservice node is determined by the ratio of the weight of the link to the sum of the pressure scores of the microservice nodes connected to the link.

[0120] The N microservice nodes with the highest merging scores are identified as recommended merging nodes; or, the microservice nodes with merging scores greater than the preset merging score threshold are identified as recommended merging nodes.

[0121] The specific details of each part of the above-mentioned device have been described in detail in the method section of the implementation, and therefore will not be repeated here.

[0122] Exemplary embodiments of this disclosure also provide a computer-readable storage medium that can be implemented as a program product including program code, which, when run on an electronic device, causes the electronic device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure. In an alternative embodiment, the program product can be implemented as a portable compact disc read-only memory (CD-ROM) including program code and can run on an electronic device, such as a personal computer. However, the program product of this disclosure is not limited thereto. In this document, the readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0123] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0124] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0125] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0126] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing devices can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0127] Exemplary embodiments of this disclosure also provide an electronic device. The electronic device may include a processor and a memory. The memory stores executable instructions for the processor, such as program code. The processor executes the executable instructions to perform the methods of this exemplary embodiment.

[0128] The following is for reference. Figure 9 The electronic device is illustrated by way of a general-purpose computing device. It should be understood that... Figure 9 The electronic device 900 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0129] like Figure 9 As shown, the electronic device 900 may include: a processor 910, a memory 920, a bus 930, an I / O (input / output) interface 940, and a network adapter 950.

[0130] Processor 910 may include one or more processing units, such as a central processing unit (CPU), an application processor (AP), a modem processor, a display processing unit (DPU), a graphics processing unit (GPU), an image signal processor (ISP), a controller, an encoder, a decoder, a digital signal processor (DSP), a baseband processor, an artificial intelligence processor, etc. In one implementation, the artificial intelligence processor can construct an initial microservice architecture diagram based on communication traffic information between microservices; and determine the microservice nodes in the initial microservice architecture diagram whose pressure scores meet preset node splitting conditions as suggested splitting nodes; the initial microservice architecture diagram with the suggested splitting nodes is determined as an intermediate microservice architecture diagram. In the intermediate microservice architecture diagram, the intermediate microservice architecture diagram is divided into one or more target microservice architecture diagrams based on the link weights, and suggested merging nodes are determined at the microservice nodes according to the merging score of each subgraph in the target microservice architecture diagram.

[0131] The memory 920 may include volatile memory, such as RAM 921 and cache unit 922, and may also include non-volatile memory, such as ROM 923. The memory 920 may also include one or more program modules 924, including but not limited to: an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. For example, program module 924 may include the modules in the aforementioned device 800.

[0132] Bus 930 is used to connect different components of electronic device 900 and may include data bus, address bus and control bus.

[0133] Electronic device 900 can communicate with one or more external devices 1000 (such as keyboard, mouse, external controller, etc.) through I / O interface 940.

[0134] Electronic device 900 can communicate with one or more networks via network adapter 950. For example, network adapter 950 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, and near-field communication. Network adapter 950 can communicate with other modules of electronic device 900 via bus 930.

[0135] although Figure 9 Other hardware and / or software modules, including but not limited to: displays, microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems, may also be configured in electronic device 900.

[0136] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to exemplary embodiments of this disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0137] Those skilled in the art will understand that various aspects of this disclosure can be implemented as systems, methods, or program products. Therefore, various aspects of this disclosure can be embodied in entirely hardware implementations, entirely software implementations (including firmware, microcode, etc.), or implementations combining hardware and software aspects, collectively referred to herein as “circuit,” “module,” or “system.” Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and embodiments are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0138] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is defined only by the appended claims.

Claims

1. A method for proposing microservice decomposition, characterized in that, include: An initial microservice architecture diagram is constructed based on the communication traffic information between microservices. The initial microservice architecture diagram includes microservice nodes and links connecting the microservice nodes. In the initial microservice architecture diagram, the microservice nodes whose pressure scores meet the preset node splitting conditions are determined as suggested splitting nodes. The pressure score of each microservice node is determined by a weighted sum of the communication traffic information corresponding to each microservice node and the correlation information of the database table. The initial microservice architecture diagram, after splitting the suggested split nodes, is determined as an intermediate microservice architecture diagram. In the intermediate microservice architecture diagram, based on the weight of the link, the intermediate microservice architecture diagram is divided into one or more target microservice architecture diagrams. Based on the merging score of each subgraph in the target microservice architecture diagram, suggested merging nodes are determined at the microservice nodes. The merging score of each microservice node is determined by the ratio of the weight of the link to the sum of the pressure scores of the microservice nodes connected to the link.

2. The method according to claim 1, characterized in that, The method further includes: Based on the ratio of the number of microservice maintenance team members to the number of microservices required for maintenance, the recommended number of microservices to be supported is determined. If the number of microservice nodes in the initial microservice architecture diagram is greater than the recommended number of microservices to be supported, a signal to merge microservices is issued. In the initial microservice architecture diagram, the microservice nodes whose pressure scores are higher than the preset pressure score threshold are identified as high-scoring microservice nodes. When the number of high-scoring microservice nodes reaches the split alarm threshold, a signal is issued suggesting the splitting of microservices.

3. The method according to claim 1, characterized in that, The initial microservice architecture diagram is constructed based on the communication traffic information between microservices, including: The microservice node is determined based on the microservice, and the link connecting the microservice node is determined based on the communication traffic information between the microservices; The microservice nodes corresponding to the links are connected using the links to construct the initial microservice architecture diagram.

4. The method according to claim 1, characterized in that, The step of determining microservice nodes in the initial microservice architecture diagram whose pressure scores meet preset node splitting conditions as recommended splitting nodes includes: In the initial microservice architecture diagram, the top N microservice nodes with the highest pressure scores are identified as suggested splitting nodes; or, the microservice nodes with pressure scores greater than a preset pressure score threshold are identified as suggested splitting nodes (N is a natural number).

5. The method according to claim 1, characterized in that, Before segmenting the intermediate microservice architecture graph into one or more target microservice architecture graphs based on the weights of the links, the method further includes: The weight of the link is determined by summing the communication traffic information of the microservice node connected by the link with the association information of the database table.

6. The method according to claim 5, characterized in that, The step of dividing the intermediate microservice architecture diagram into one or more target microservice architecture diagrams based on the weights of the links includes: The links whose weights meet the preset cutting conditions are cut, and the one or more target microservice architecture diagrams are obtained based on the connectivity graph in the intermediate microservice architecture diagram after the cutting.

7. The method according to claim 1, characterized in that, The step of determining the recommended merging node at the microservice node based on the merging score of each subgraph in the target microservice architecture diagram includes: The N microservice nodes with the highest merging scores are identified as recommended merging nodes; or, the microservice nodes with merging scores greater than a preset merging score threshold are identified as recommended merging nodes.

8. A microservice decomposition suggestion device, characterized in that, include: The initial microservice architecture diagram generation module is configured to construct an initial microservice architecture diagram based on communication traffic information between microservices. The initial microservice architecture diagram includes microservice nodes and links connecting the microservice nodes. The recommended splitting node determination module is configured to determine the microservice nodes in the initial microservice architecture diagram that meet the preset node splitting conditions as recommended splitting nodes. The pressure score of each microservice node is determined based on the weighted sum of the communication traffic information corresponding to each microservice node and the correlation information of the database table. The module for determining recommended merge nodes is configured to determine the initial microservice architecture diagram, which has been split into the recommended split nodes, as an intermediate microservice architecture diagram. In the intermediate microservice architecture diagram, the intermediate microservice architecture diagram is divided into one or more target microservice architecture diagrams based on the weight of the links. Based on the merging score of each subgraph in the target microservice architecture diagram, a recommended merge node is determined in the microservice nodes. The merging score of each microservice node is determined by the ratio of the weight of the link to the sum of the pressure scores of the microservice nodes connected to the link.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

10. An electronic device, characterized in that, include: processor; Memory for storing the executable instructions of the processor; The processor is configured to execute the method of any one of claims 1 to 7 by executing the executable instructions.

Images