A microservice partitioning method and apparatus

Abstract

The application relates to the technical field of computers and provides a micro-service division method and device.The method comprises the following steps: finding the association relationship between interfaces and data forms according to the parameters of the interfaces and the data in the data forms; and generating one or more first relationship graphs according to the association relationship between the interfaces and the data forms, so that the micro-service division can be performed according to the first relationship graphs; wherein, in the first relationship graph, the data forms are taken as vertices, and the interfaces associated with the multiple data forms are taken as edges used for connecting two data forms in the multiple data forms. The application comprehensively considers the relationship between interfaces, the relationship between interfaces and data forms, and the relationship between data forms, so that the micro-service division is performed, the reasonable division of micro-services and / or databases is realized, the database corresponding to communication of one micro-service is as few as possible, and the communication overhead between micro-services is reduced.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a microservice partitioning method and apparatus. Background Technology

[0002] Microservices are a widely used software development architecture and concept that advocates building applications using services that can be developed independently, decoupled from each other, communicate and coordinate with each other, and be deployed independently. Microservices transform a monolithic system into the development of multiple services. In the process of microservice development, the first thing developers need to consider is how to divide the system into microservices. Inappropriate microservice division may lead to developers having to write a large amount of code for communication between services. This not only increases the resource consumption of inter-service communication and affects system performance, but also may lead to the risk of needing to refactor some services later on as development progresses. Microservice division is a crucial factor affecting the overall development efficiency and system performance stability of a project, and it is also an important issue studied in the field of microservice technology.

[0003] In related technologies, existing monolithic projects or code files are used to identify the relationships and couplings between business functions, thus dividing the system into multiple microservices. These technologies rely on the existence of a complete monolithic project or existing project code, and are primarily used for refactoring legacy projects. However, when developing new microservice projects, developers face entirely new projects without existing monolithic projects or code. Without a foundation for applying these technologies, developers cannot use them for microservice division.

[0004] Other related technologies overlook the impact of databases on microservice partitioning and fail to consider a crucial principle of microservices: "each microservice corresponds to a separate database." Ignoring the database factor means that subsequent development still relies on developers' experience to partition the database. Inappropriate partitioning can increase communication overhead between microservices, potentially reducing system performance and increasing the probability of system failure.

[0005] Therefore, overcoming the shortcomings of the existing technology is an urgent problem to be solved in this technical field. Summary of the Invention

[0006] The technical problem that this invention aims to solve is that existing microservice partitioning does not consider the relationship between interfaces and databases, which leads to each microservice needing to communicate with multiple databases after partitioning, resulting in increased communication overhead between microservices.

[0007] The present invention adopts the following technical solution:

[0008] In a first aspect, the present invention provides a microservice partitioning method, including:

[0009] Based on the parameters of the interface and the data in the data form, find the relationship between the interface and the data form;

[0010] Based on the relationship between the interface and the data form, generate one or more first relationship diagrams to facilitate the division of microservices according to the first relationship diagrams;

[0011] In the first relational graph, data forms are used as vertices, and interfaces associated with multiple data forms are used as edges for pairwise connections between the multiple data forms.

[0012] Preferably, finding the association between the interface and the data form based on the interface parameters and the data in the data form specifically includes:

[0013] Convert the parameters of the interface into corresponding parameter vectors, and convert the field names of the data in the data form into corresponding data vectors;

[0014] Calculate the similarity between each parameter vector and each data vector;

[0015] If the similarity between at least one first parameter vector and at least one first data vector is greater than a preset similarity, then the first interface is associated with the first data form; wherein, the first parameter vector is a parameter vector obtained by converting the parameters of the first interface, and the first data vector is a data vector obtained by converting the field names of the data in the first data form.

[0016] Preferably, when the number of components in the first relationship graph is less than the preset microservice granularity, the step of dividing the service into microservices based on the first relationship graph specifically includes:

[0017] Based on the number of data forms in each first relationship graph, the first relationship graph with the most data forms is split; wherein, in one split, a first relationship graph is split into multiple connected relationship graphs, and the multiple connected relationship graphs are used as multiple first relationship graphs to participate in the next split, until the total number of connected relationship graphs and unsplit first relationship graphs equals the preset microservice granularity;

[0018] Each interconnected relationship graph and each unsplit first relationship graph are used as a second relationship graph. Based on each second relationship graph, microservices are divided.

[0019] Preferably, the step of splitting a first relational graph into multiple connected relational graphs specifically includes:

[0020] The weight values ​​of the first data form, the second data form, and the interfaces that are associated with both the first and second data forms are weighted and summed to obtain the edge weight value of the edge connecting the first and second data forms.

[0021] Based on the edge weights of all edges in the first relation graph, the corresponding edges in the first relation graph are selectively split to divide the first relation graph into multiple relation graphs, and the sum of the edge weights of all split edges is minimized.

[0022] Preferably, the step of dividing the data into microservices based on each second relationship graph specifically includes:

[0023] For each second relationship graph, a corresponding microservice is established. All interfaces corresponding to unsplit edges in the second relationship graph are assigned to the corresponding microservices. Interfaces corresponding to split edges are assigned to the microservices most closely associated with those interfaces. Among them, the microservice corresponding to the second relationship graph with the largest number of data forms associated with the first interface is taken as the microservice most closely associated with the first interface.

[0024] And / or, for each second relational graph, establish a corresponding database and divide all data forms in the second relational graph into the corresponding database.

[0025] Preferably, when the number of the first relationship graphs is greater than the preset microservice granularity, the step of dividing the microservices according to the first relationship graphs specifically includes:

[0026] Based on the number of data forms in each first relationship graph, the two first relationship graphs with the fewest data forms are merged; wherein, in one merge, multiple first relationship graphs are merged into multiple merged relationship graphs, and the merged relationship graphs are used as first relationship graphs in the next merge, until the total number of merged relationship graphs and unmerged first relationship graphs equals the preset microservice granularity.

[0027] Each merged relation graph and each unmerged first relation graph are used as a second relation graph. Based on each second relation graph, microservices are divided.

[0028] Preferably, the step of dividing the data into microservices based on each second relationship graph specifically includes:

[0029] For each second relation graph, a corresponding microservice is established, and the interfaces corresponding to all edges in the second relation graph are assigned to the corresponding microservices;

[0030] And / or, for each second relational graph, establish a corresponding database and divide all data forms in the second relational graph into the corresponding database.

[0031] Preferably, the interface is stored in a request-response complex, which stores the request parameters and response parameters of the interface.

[0032] The request-response complex also stores data forms associated with the interface to represent the relationship between the interface and the data forms.

[0033] Preferably, the interface is obtained from the API design document, and the data form is obtained from the data form design document.

[0034] Secondly, the present invention also provides a microservice partitioning apparatus for implementing the microservice partitioning method described in the first aspect, the apparatus comprising:

[0035] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor for performing the microservice partitioning method described in the first aspect.

[0036] Thirdly, the present invention also provides a non-volatile computer storage medium storing computer-executable instructions that are executed by one or more processors to perform the microservice partitioning method described in the first aspect.

[0037] This invention generates a first relationship graph based on the association between interfaces and data forms. Microservices are then partitioned according to this graph. In the first relationship graph, interfaces serve as edges connecting various data forms, allowing the graph to comprehensively represent the relationships between interfaces, between interfaces and data forms, and between data forms. This enables the partitioning of microservices by comprehensively considering these relationships, achieving a reasonable division of microservices and / or databases. This minimizes the number of databases a microservice communicates with, thereby reducing communication overhead between microservices. Attached Figure Description

[0038] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0039] Figure 1 This is a flowchart illustrating a microservice partitioning method provided in an embodiment of the present invention;

[0040] Figure 2This is a schematic diagram of a request-response complex in a microservice partitioning method provided in an embodiment of the present invention;

[0041] Figure 3 This is a schematic diagram of the request-response complex in another microservice partitioning method provided by an embodiment of the present invention;

[0042] Figure 4 This is a schematic diagram illustrating the generation of a first relationship graph in a microservice partitioning method provided in an embodiment of the present invention;

[0043] Figure 5 This is a schematic diagram illustrating the generation of the first relationship graph in another microservice partitioning method provided in this embodiment of the invention;

[0044] Figure 6 This is a schematic diagram illustrating the generation of the first relationship graph in another microservice partitioning method provided in this embodiment of the invention;

[0045] Figure 7 This is a flowchart illustrating the process of finding relationships in a microservice partitioning method provided in an embodiment of the present invention.

[0046] Figure 8 This is a schematic diagram illustrating the splitting of a first relationship graph in a microservice partitioning method provided by an embodiment of the present invention;

[0047] Figure 9 This is a schematic diagram of the process of splitting the first relationship graph in a microservice partitioning method provided by an embodiment of the present invention;

[0048] Figure 10 This is a flowchart illustrating another microservice partitioning method provided in an embodiment of the present invention;

[0049] Figure 11 This is a flowchart illustrating the process of obtaining the request-response complex in a microservice partitioning method provided by an embodiment of the present invention;

[0050] Figure 12 This is a flowchart illustrating the process of finding relationships in another microservice partitioning method provided in this embodiment of the invention;

[0051] Figure 13 This is a flowchart illustrating another microservice partitioning method provided in an embodiment of the present invention;

[0052] Figure 14 This is a schematic diagram of the process for calculating the global minimum cut in a microservice partitioning method provided in an embodiment of the present invention;

[0053] Figure 15 This is a schematic diagram of the architecture of a microservice partitioning device provided in an embodiment of the present invention. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0055] In this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0056] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0057] Example 1:

[0058] Existing microservice partitioning does not consider the relationship between interfaces and databases, resulting in each microservice needing to communicate with multiple databases after partitioning, leading to increased communication overhead between microservices. To address this issue, Embodiment 1 of this invention provides a microservice partitioning method, such as... Figure 1 As shown, it includes:

[0059] In step 201, the association between the interface and the data form is found based on the parameters of the interface and the data in the data form; the association is usually manifested as the data represented by the parameters in the interface being stored in the corresponding field of the corresponding data form.

[0060] The interface is obtained from the API (Application Programming Interface) design document, and the data form is obtained from the data form design document. The interface is stored in a request-response complex, which stores the request parameters and response parameters of the interface, such as... Figure 2 As shown, request_param represents the request parameters, and response_param represents the response parameters. The request and response parameters are deduplicated and then stored as a composite parameter, synthesized_param, in the request-response composite body. The request-response composite body also stores data forms associated with the interface to represent the relationship between the interface and the data forms, such as... Figure 3 As shown, a new `table_list` parameter is added to the request-response complex to store pointers to a linked list of data forms. The linked list pointed to by these pointers stores all data forms associated with the interface.

[0061] In step 202, one or more first relationship graphs are generated based on the association between interfaces and data forms to facilitate microservice partitioning. In these first relationship graphs, data forms are used as vertices, and interfaces associated with multiple data forms are used as edges for pairwise connections between the data forms. The first relationship graph can be an undirected graph, and the resulting first relationship graph is as follows: Figure 6 As shown, the data tables table 1, table 2, table 3, table 4, and table 5 are connected to form the first relationship. Figure 1 Interface 6 is only associated with data form table 6, and data form table 6 is not associated with any other interfaces. Therefore, table 6 forms a separate first relationship. Figure 2 Data forms table 8 and table 9 are both associated with interface 7, and the connection between data forms table 8 and table 9 forms a first relationship. Figure 3 When an interface is associated with only a single data form, or when the interfaces associated with a data form are not associated with any other data forms, the data form and the interface are relatively independent. After the microservices are divided, the relatively independent data forms are assigned to databases with fewer data forms, and the interfaces associated with the corresponding data forms are assigned to the microservices that match that data form. A microservice typically refers to a set of one or more interfaces, and is usually divided based on a graph corresponding to a microservice. The division of microservices according to the first relationship graph can be achieved by assigning all edges in the first relationship graph to a single microservice, establishing a corresponding database for that microservice, and assigning all data forms in the first relationship graph to that database.

[0062] In this context, "using data forms as vertices" means that vertices in the first relationship graph represent data forms, and "using interfaces associated with multiple data forms as edges for connecting the multiple data forms in pairs" means that edges in the first relationship graph represent interfaces. In actual use, one edge can represent multiple interfaces.

[0063] The term "pairwise connection" refers to the connection between any two data forms. Figure 4 For example, when interface a is associated with table 1, table 2, and table 3, it forms the following: Figure 4 The first relational graph is similar to a triangle, where table 1, table 2 and table 3 are three vertices, and the three vertices are connected to each other. The edges connecting each vertex represent interface a.

[0064] When multiple interfaces are associated with multiple data forms, such as Figure 5 As shown, interface a is associated with table 1, table 2 and table 3, and interface b is associated with table 1, table 2 and table 3. Then table 1, table 2 and table 3 are three vertices, and the three vertices are connected to each other to form the first relation graph. The edges connected by the three vertices represent interface a and interface b.

[0065] This embodiment generates a first relationship graph based on the association between interfaces and data forms. Microservices are then divided according to this relationship graph. In the first relationship graph, interfaces serve as edges connecting various data forms. This allows the first relationship graph to comprehensively represent the relationships between interfaces, between interfaces and data forms, and between data forms. By comprehensively considering these relationships, microservices can be divided, achieving a reasonable division of microservices and / or databases. This minimizes the number of databases that a microservice communicates with, thereby reducing communication overhead between microservices.

[0066] In practical use, the relationship between the interface and the data form is found based on the interface parameters and the data in the data form, such as... Figure 7 As shown, it specifically includes:

[0067] In step 301, the interface parameters are converted into corresponding parameter vectors, and the field names in the data forms are converted into corresponding data vectors. For example, the parameters in each request-response complex and the field names in each data form are imported into a pre-trained word vector model, which outputs word vectors of a preset dimension for each parameter and field name. The word vector model can be a word2vec (word to vector) model, a glove model, or a BERT (Bidirectional Encoder Representation from Transformers) model, etc.

[0068] In step 302, the similarity between each parameter vector and each data vector is calculated; the similarity can be calculated using methods such as Euclidean distance and cosine similarity. For example, cosine similarity can be used to calculate the similarity of vectors. Where, x i Let y be the i-th dimension of the parameter vector. i Let i be the i-th dimension of the data vector.

[0069] In step 303, if the similarity between at least one first parameter vector and at least one first data vector is greater than a preset similarity, then the first interface is associated with the first data form. Here, the first parameter vector is a parameter vector converted from the parameters of the first interface, and the first data vector is a data vector converted from the field names of the data in the first data form. For example, if interface A contains 3 parameters, then 3 parameter vectors are generated accordingly. When interface A is the first interface, all 3 parameter vectors are first parameter vectors. If data form table 1 contains 4 field names, then 4 data vectors are generated accordingly. When data form table 1 is the first data form, all 4 data vectors are first data vectors. If the similarity between any one of the 3 parameter vectors and any one of the 4 data vectors is greater than a preset similarity, then interface A is associated with data form table 1. The preset similarity is obtained by those skilled in the art based on the interface design characteristics and data form design characteristics. In an optional embodiment, the preset similarity can be 0.9. For example, after obtaining the 300-dimensional word vectors (i.e., the parameter vector and data vector) corresponding to the parameters in each request-response complex and the field names of the data forms, the parameters in each request-response complex are traversed sequentially, and the word vector of the current parameter is compared with the word vectors of all field names of the data forms for similarity verification. When the word vector similarity between the two is greater than or equal to 0.9, the two are considered to be a match.

[0070] In specific application scenarios, it is often necessary to control the number of microservices when performing microservice partitioning. For this scenario, the following optional implementation method is provided: when the number of microservices in the first relationship graph is less than the preset microservice granularity, the partitioning of microservices based on the first relationship graph specifically includes:

[0071] Based on the number of data forms in each first relationship graph, the first relationship graph with the most data forms is split; wherein, in one split, a first relationship graph is split into multiple connected relationship graphs, and the multiple connected relationship graphs are used as multiple first relationship graphs in the next split, until the total number of connected relationship graphs and unsplit first relationship graphs equals the preset microservice granularity; the preset microservice granularity is obtained by those skilled in the art based on microservice partitioning requirements analysis.

[0072] Each connected relation graph and each unsplit first relation graph are used as a second relation graph. Microservices are then partitioned based on these second relation graphs. Specifically, each connected relation graph and each unsplit first relation graph is considered a second relation graph. Using each connected relation graph and each unsplit first relation graph as a second relation graph means using each graph in the set of all graphs formed after splitting as a second relation graph. Unsplit first relation graphs can be understood as those generated without undergoing any splitting. Figure 8 Relationship graphs b and c in the diagram represent the unsplit first-level relationship graphs. Here, each connected relationship graph can be understood as any graph that has undergone at least one split, such as... Figure 8 The relationship diagrams d, f, and g are shown.

[0073] by Figure 8 For example, if the preset microservice granularity is 5, the generated first relationship graphs are relationship graph a, relationship graph b, and relationship graph c, totaling 3. In the first split, relationship graph a, which has the most data forms (represented by the most vertices in the first relationship graph), is split into relationship graph d and relationship graph e (i.e., the connected relationship graph). In the second split, among relationship graphs d, e, b, and c, relationship graph e, which has the most data forms, is selected for splitting. Relationship graph e is split into relationship graph f and relationship graph g. Thus, the resulting relationship graphs (including the connected relationship graph and the first relationship graph) are relationship graph d, relationship graph f, relationship graph g, relationship graph b, and relationship graph c, totaling 5, which is equal to the preset microservice granularity. These relationship graphs are the second relationship graphs.

[0074] In practical use, the degree of association between different interfaces and different data forms, or between different data forms, may vary. For example, if a corresponding interface interacts frequently with a corresponding data form, the association is relatively strong; conversely, if the corresponding interface interacts less frequently with a corresponding data form, the association is relatively weak. If the degree of association is not considered, during the splitting process, objects with strong associations may be split into different second relationship graphs, ultimately leading to them being assigned to different microservices or databases that do not correspond to the corresponding microservices. To solve this problem, this embodiment also provides a preferred implementation method, namely, splitting a first relationship graph into multiple connected relationship graphs, such as... Figure 9 As shown, it specifically includes:

[0075] In step 401, the weight values ​​of the first data form, the second data form, and the interface associated with both the first and second data forms are weighted and summed to obtain the edge weight value of the edge connecting the first and second data forms.

[0076] For example, suppose the weight of each interface is w. e If the corresponding data form is marked as a core form by the developer, then the weight value of that core form is w. t w t ≥w e Otherwise, the weight of the data form is 0. Then the weight w of the edge connecting two data forms (such as the first data form and the second data form) is w = w e *n1+w t *n2, where n1 is the number of interfaces associated with both the first and second data forms, i.e., the total number of interfaces corresponding to the edges connecting the first and second data forms, and n2 is the number of these two data forms marked as core forms. It should be noted that this is only a simplified example; in actual use, the weight values ​​of each interface, each data form, and the edges connecting the first and second data forms may differ. Among them, w ei w represents the weight value of the i-th interface corresponding to the edge connecting the first data form and the second data form. t1 w is the weight value of the first data form. t2 The weight values ​​for the second data form are as follows: The weight value for each interface is obtained by those skilled in the art based on the interaction requirements between the interface and the data form, and the weight value for each data form is obtained by those skilled in the art based on the usage requirements of the data form.

[0077] In step 402, based on the edge weight values ​​of all edges in the first relation graph, the corresponding edges in the first relation graph are selectively split to split the first relation graph into multiple relation graphs, and the sum of the edge weight values ​​of all split edges is minimized.

[0078] The selective splitting of the corresponding edges in the first relation graph can be achieved by calculating the global minimum cut of the first relation graph and splitting the edges corresponding to the global minimum cut. The principle of the global minimum cut is to delete some edges in the first relation graph so that the original undirected graph is divided into two connected components. When the sum of the weights of the deleted edge set is the minimum, then the edge set is the global minimum cut of the first relation graph.

[0079] In this embodiment, the vertices of the first relationship graph represent data forms, and the edges represent interfaces. Finding the global minimum cut of this first relationship graph means finding the edge that divides these data forms into two databases with the least amount of interface communication between the databases. Based on the idea of ​​"one database per microservice," meaning that most of the business logic and data in a microservice should be directly obtained from its corresponding database, with a smaller portion of data obtained through communication between microservices, the division of data forms essentially determines the basis for microservice partitioning. The algorithm used to calculate the global minimum cut of the first relationship graph can be the Stoer-Wagner algorithm.

[0080] In a preferred embodiment, the weight value of each interface is also determined based on the number of data forms associated with the interface. The more data forms an interface is associated with, the higher its weight value; the fewer data forms an interface is associated with, the lower its weight value. As a result, the edges corresponding to the interfaces with the most associated data forms have high edge weights, so these edges are preferentially retained and not split during the splitting process.

[0081] The interfaces corresponding to the split edges can be assigned to any microservice corresponding to the second relation graph obtained from the split. There is also a preferred implementation method, where the division of microservices based on each second relation graph specifically includes: establishing a corresponding microservice for each second relation graph; assigning all interfaces corresponding to unsplit edges in the second relation graph to the corresponding microservice; assigning interfaces corresponding to split edges to the microservice most closely associated with that interface; wherein the microservice corresponding to the second relation graph with the largest number of data forms associated with the first interface is considered the microservice most closely associated with the first interface; and / or, establishing a corresponding database for each second relation graph; assigning all data forms in the second relation graph to the corresponding database.

[0082] The unsplit edges are those edges that were not split during the splitting process of the first relationship graph. The split edges are those edges that were split during the splitting process of the first relationship graph. A split edge can represent an interface that, after splitting, has a relationship with data forms in multiple second relationship graphs. Where an interface corresponds to both a split edge and an unsplit edge, the interface is processed according to the interface corresponding to the split edge. An unsplit edge can represent an interface that, after splitting, has a relationship with only one data form in a second relationship graph.

[0083] When the number of elements in the first relationship graph exceeds the preset microservice granularity, the step of dividing the service into microservices based on the first relationship graph specifically includes:

[0084] Based on the number of data forms in each first relationship graph, the two first relationship graphs with the fewest data forms are merged; wherein, in one merge, multiple first relationship graphs are merged into multiple merged relationship graphs, and the merged relationship graphs are used as first relationship graphs in the next merge, until the total number of merged relationship graphs and unmerged first relationship graphs equals the preset microservice granularity.

[0085] The merged relation graphs and the unmerged first relation graphs are used as second relation graphs. Microservices are then partitioned based on these second relation graphs. Here, the unmerged first relation graphs can be understood as those that have not undergone any merging after generation. The merged relation graphs can be understood as any graph that has undergone at least one merging. It should be noted that in this embodiment, merging two first relation graphs does not mean connecting them with edges, but rather treating them as a single entity.

[0086] When the number of elements in the first relationship graph exceeds the preset microservice granularity, since edge splitting is not involved, the process of dividing microservices based on each second relationship graph specifically includes:

[0087] For each second relation graph, establish a corresponding microservice and assign the interfaces corresponding to all edges in the second relation graph to the corresponding microservice; and / or, for each second relation graph, establish a corresponding database and assign all data forms in the second relation graph to the corresponding database.

[0088] When the number of first relationship graphs is equal to the preset microservice granularity, microservices and / or databases are directly partitioned based on each first relationship graph.

[0089] In practical use, the splitting and merging of the first relationship graph is not entirely determined by the preset microservice granularity. In practical use, the splitting or merging of the first relationship graph may also be carried out for the sake of resource balance between microservices or databases. The corresponding splitting and merging process is implemented based on the same concept as in the above embodiments, and will not be described in detail here.

[0090] Example 2:

[0091] Based on the method described in Embodiment 1, this invention combines specific application scenarios and uses technical descriptions in relevant scenarios to illustrate the implementation process of the features of this invention in those scenarios.

[0092] This invention uses the scenario of dividing microservices and databases based on developers' API design documents and data form design documents as an example. Specifically, developers write standard API design documents and data form design documents based on requirements analysis. After completing these two documents, developers set the desired microservice granularity and use the method described in this invention to divide the microservices, such as... Figure 10 As shown, it specifically includes:

[0093] In step 501, the developer inputs a standard API design document and a data form design document, and inputs the desired microservice granularity k (k≥2). The standard API design document input by the developer must conform to general software development API design document writing specifications, meaning that each interface must include: interface URL (Uniform Resource Locator), interface description, request parameter table, and response parameter table. The data form design input by the developer must conform to general software development data form design specifications. It can be an SQL (Structured Query Language) file that creates the form, or a parameter list containing the form's field names and data types.

[0094] In step 502, the request and response parameters of each interface in the standard API design document are extracted. After data transformation, cleaning, and deduplication, a complete list of request and response parameters is obtained, which is called the "request and response complex". It should be noted that the request and response complex can be understood as an interface in essence. In subsequent embodiments, the request and response complex will also be used as an alternative form of interface.

[0095] In step 503, extract the field names from each data form design to form a corresponding parameter list. For some special field names, such as ID, add the prefix "table_name". This prompts developers to mark the core forms.

[0096] In step 504, each parameter in each request-response complex is matched with the parameters of all extracted data forms to construct the association between the request-response complex and the data forms (which can be understood as the association between the interface and the data form in Example 1). This association reveals the implicit relationships between interfaces, between interfaces and data forms, and between data forms, which is the key to microservice partitioning.

[0097] In step 505, based on the association between the request-response complex and the data form, a corresponding undirected graph set is constructed. Each undirected graph can be understood as the first relationship graph in Example 1. Relatively independent data forms are marked, and the elements in the undirected graph set are divided according to the microservice granularity expected by the developer (i.e., the preset microservice granularity in Example 1) to obtain the partitioning criteria for the candidate database.

[0098] In step 506, the data forms marked in step 505 are randomly assigned to elements with a lower number of vertices in the undirected graph set to obtain the final microservice partitioning criteria. These data forms are relatively independent in terms of business logic and do not communicate with other databases on business data. After these data forms are assigned, all data forms are contained within the elements of the undirected graph set. Each element reflects the aggregation relationship of the data forms and forms the basis for microservice partitioning. Finally, the data forms contained in each element will each constitute a database partition. The database iterates through each element, filters out the data forms in each element, and identifies the interfaces corresponding to the request-response complex, thus forming a microservice partition.

[0099] In step 507, based on the obtained final database partitioning criteria, a corresponding number of temporary database names are generated, and the temporary database names and their associated data form table names are stored in a set. Based on the association between the request-response complex and the data forms, the association between the interface to which the request-response complex belongs and the database is established, and each interface and database is further partitioned, outputting the final microservice partitioning criteria.

[0100] In step 502, the request and response parameters of each interface design in the standard API design document are extracted, and after data transformation, cleaning, and deduplication, a request-response composite is obtained, such as... Figure 11 As shown, it specifically includes:

[0101] In step 601, obtain the standard API design document.

[0102] In step 602, extract the request and response parameters of all interface designs.

[0103] In step 603, the objects and collections in the request and response parameters are decomposed into individual parameters. It should be noted that in interface design, some request or response parameters inevitably wrap more information using objects or collections, such as Lists. <t>Map<K,V> For data structures like these, standard API design documents will list and describe the objects and parameters within the data structure. If developers overlook this in their API design documentation and fail to list or describe certain parameters, these omissions will be marked and the developers will be prompted to address them.

[0104] In step 604, common parameters and parameters with little relevance to business logic are removed from the request and response parameters. For example, common parameters and parameters with little relevance to business logic that are removed from the request and response parameters may include parameters such as code, desc, time, createTime, and updateTime. These types of parameters have little correlation with actual business data and are general identifiers and descriptions set during the front-end and back-end information interaction process.

[0105] In step 605, the request parameters and response parameters are merged, and data deduplication is performed (i.e., the same request parameters and response parameters in the same interface are deduplicated) to obtain the request-response composite.

[0106] In step 606, obtain all request-response complexes from the API design document.

[0107] In an optional implementation, after extracting the parameter list of all data forms, a prompt is pushed to the developer to select the core data form. The developer can select or skip it as needed. In a system or business process, some data forms are queried and modified far more frequently than other data forms. These forms are the important support for the core business and have a significant impact on the microservice division.

[0108] In step 504, each parameter in each request-response complex is matched with the parameters of all extracted data forms (which can be understood as the form data in Example 1) to construct the association between the request-response complex and the data forms, such as... Figure 12 As shown, it specifically includes:

[0109] In step 701, all request-response complexes and transformed data form parameters are imported into the trained word vector model to obtain a 300-dimensional word vector corresponding to each parameter. The word vector model trained in this embodiment is the word2vec model. Compared to BERT, this model requires less training time. Furthermore, in typical API design documentation and data form designs, request-response parameters and data form fields are required to be concise and clearly defined. Considering semantic complexity, training time, and actual parameter matching performance, the word2vec model better meets these requirements.

[0110] In step 702, all request-response complexes are traversed, and one request-response complex is selected.

[0111] In step 703, each parameter of the current request-response complex is traversed, a request-response complex parameter is selected (i.e., a parameter vector is selected), and the matching list of the parameter is initialized to store the data form parameters that are successfully matched.

[0112] In step 704, all parameters of the data form are traversed, and word vector similarity is compared with the parameters of the current request-response complex. That is, the similarity between the currently traversed parameter vector and the currently traversed data vector is calculated. In this embodiment of the invention, cosine similarity is used to measure the similarity of word vectors, and its formula is: Where, x i Let y be the i-th dimension of the parameter vector. i Let i be the i-th dimension of the data vector.

[0113] In step 705, it is determined whether the similarity between the parameters of the current data form and the parameters of the current request-response complex is greater than or equal to 0.9 (i.e., the preset similarity in Example 1); if the similarity is greater than or equal to 0.9, it is considered that the parameters of the current request-response complex match the parameters of the current data form, and proceed to step 706; otherwise, jump to step 707.

[0114] In step 706, the data form parameter is stored in the matching list of the request-response complex parameters.

[0115] In step 707, it is determined whether the data form parameters have been completely traversed. If they have been completely traversed, proceed to step 708; otherwise, proceed to step 704.

[0116] In step 708, it is determined whether the parameters of the current request-response complex have been traversed. If they have been traversed, proceed to step 709; otherwise, proceed to step 703.

[0117] In step 709, it is determined whether the current request-response complex is the last request-response complex. If the current request-response complex is the last request-response complex, it means that the parameter similarity comparison between all request-response complexes and the data form has been completed, and the process jumps directly to step 710; otherwise, the process jumps to step 702.

[0118] In step 710, a matching list of all request-response body parameters is obtained. Lists with zero or more elements in the matching list are then filtered out, and the developer is prompted for confirmation. During the matching process between the request-response body and the data form parameters, due to objective factors such as redundant fields and polysemous terms in the data form design, the correctness of lists with zero or more elements in the matching list needs further verification. Therefore, the system will filter out these lists and prompt the developer for confirmation and modification.

[0119] In step 711, a matching list of all correct request-response complex parameters is obtained, and the association between the request-response complex and the data form is established.

[0120] In step 505, constructing a corresponding undirected graph set based on the association between the request-response complex and the data forms specifically includes: using data forms as vertices and interfaces associated with multiple data forms as edges for pairwise connections between the multiple data forms, thus constructing the undirected graph set. The elements in the undirected graph set are undirected graphs, and each vertex of an undirected graph represents a data form. When the matching list of all parameters of a request-response complex contains parameters from multiple different data forms, these data forms can be paired with vertices in the undirected graph. The edge is denoted as e, and the weight w of edge e is jointly determined by the weight of the request-response complex and the weight of the core data table. The weight calculation rules are as follows:

[0121] Each request-response complex assigns a weight w to edge e. e The same applies. If a data form is marked as a core form by the developer, then that core form can also assign weights w to edge e. t , where w t ≥w e .

[0122] If two data forms can be associated through multiple request-response complexes, meaning each request-response complex is associated with both data forms, then the weight of edge e between the two data forms needs to be accumulated by adding the weights of the multiple request-response complexes: w = w e *n1+w t *n2. Where n1 is the number of the above request-response complexes, and n2 is the number of forms marked as core forms in the current two data forms.

[0123] It's important to note that not all data forms can be used to construct an undirected graph. Some interfaces communicate with only one data form, meaning that some independent data forms cannot establish connections with other data forms through their associated request-response complexes. These independent data forms are selected and stored separately. The undirected graphs constructed from the remaining data forms directly reflect their clustering and correlation. Following the idea of ​​"each microservice corresponding to a separate database," these clustered data forms should be assigned to a single database, forming a microservice together with the interfaces corresponding to their associated request-response complexes. Therefore, undirected graphs can serve as candidate microservice partitioning criteria. Based on the relationship between the developer's desired microservice granularity k and the number of elements β in the undirected graph set, the candidate microservice partitioning criteria include the following:

[0124] If k = β (the number of the first relation graphs is equal to the preset microservice granularity), then the elements in the current undirected graph set are used as the dividing criteria, and the resulting candidate microservice granularities can meet the microservice granularities expected by the developers.

[0125] If k < β (the number of elements in the first relationship graph is greater than the preset microservice granularity), then the elements in the undirected graph set are sorted in ascending order of the number of vertices. The first and second elements are grouped together and merged into one element. This process is iterated until the number of elements in the set matches the microservice granularity desired by the developers. Finally, the elements in the set are used as the candidate microservice partitioning criteria.

[0126] If k > β (the number of elements in the first relation graph is less than the preset microservice granularity), then the elements in the undirected graph set will be partitioned to increase the number of elements in the set until the number of elements in the set matches the microservice granularity expected by the developer.

[0127] Taking all three scenarios into account, in step 506, the elements in the undirected graph set are partitioned according to the microservice granularity desired by the developer to obtain the partitioning criteria for the candidate database, such as... Figure 13 As shown, the steps include:

[0128] In step 801, it is determined whether the expected microservice granularity β is equal to the number of elements k in the undirected graph set. If they are equal, the process jumps to step 802; otherwise, it jumps to step 803.

[0129] In step 802, the current undirected graph set is output, and each element of the set is a candidate database partitioning criterion.

[0130] In step 803, the elements in the undirected graph set are sorted in ascending order of the number of vertices.

[0131] In step 804, it is determined whether the expected microservice granularity β is greater than the number of elements k in the undirected graph set. If the condition is met, the process jumps to step 805; otherwise, it jumps to step 807.

[0132] In step 805, the last element is extracted, and the global minimum cut of the undirected graph is calculated. The global minimum cut of the undirected graph is calculated to minimize the weight of the edge set lost during the undirected graph split.

[0133] In step 806, the element is cut into two new elements according to the global minimum cut, that is, the first relation graph is split into two connected relation graphs, and the original undirected graph set is updated. The updated undirected graph set includes the unsplit first relation graph and the split connected relation graph.

[0134] In step 807, the first element and the second element are merged into one element, that is, the two first relation graphs are merged into multiple merged relation graphs, and the original undirected graph set is updated. The updated undirected graph set includes the merged relation graphs and the unmerged first relation graphs.

[0135] In this embodiment, the vertices of the undirected graph represent data forms, the edges represent request-response complexes, and the request-response complexes further represent interfaces. Finding the global minimum cut of this undirected graph means finding a way to divide these data forms into two databases with minimal interface communication between the databases. Based on the idea of ​​"one database per microservice," meaning that most of the business and data in a microservice should be obtained directly from its corresponding database, and a smaller portion of the data can be obtained through communication between microservices, the division of data forms has essentially determined the basis for the microservice division. In this embodiment, the Stoer-Wagner algorithm is used to calculate the global minimum cut of the undirected graph, such as... Figure 14 As shown, it specifically includes:

[0136] In step 901, a subset A is defined to belong to the initial undirected graph (i.e., the first relation graph that needs to be split), and a vertex t of the initial undirected graph is randomly selected. n Place it into subset A, and treat A as a vertex.

[0137] It should be noted that subset A is considered a vertex in an undirected graph, and the vertices connected to it are the other vertices that were originally connected to vertices in the subset. Similarly, the edge weight between subset A and its connected vertices is the sum of the edge weights of the other vertices that were originally connected to vertices in the subset.

[0138] In step 902, the initial undirected graph is copied, and the calculations are performed in the new undirected graph.

[0139] In step 903, a vertex that is connected to subset A and has the largest edge weight is selected from the remaining vertices of the current undirected graph and added to subset A.

[0140] In step 904, determine whether the number of vertices in the current undirected graph is equal to 3. If the number of vertices is equal to 3, jump to step 905; otherwise, jump to step 903.

[0141] In step 905, calculate the minimum weight sum of the edge sets connected to each vertex except for subset A, denoted as the current minimum cut, and record the current minimum cut, the cut vertex, and the cut edge set.

[0142] In step 906, the two vertices other than A are merged into a subset, treated as a single vertex, and updated to the initial undirected graph.

[0143] In step 907, it is determined whether the number of vertices in the initial undirected graph is less than 3. If the condition is met, the process jumps to step 908; otherwise, it jumps directly to step 902.

[0144] In step 908, the iteration is stopped, the smallest current minimum cut is selected from the records as the global minimum cut, and its corresponding cutting edge set and cutting point set are selected.

[0145] In practical use, after obtaining the aggregation relationship of the data forms through the above implementation method and being able to partition the database, it is still necessary to map each interface to a database one-to-one to form a complete microservice. Specifically, this includes: after obtaining the final undirected graph set, extracting each element from the set sequentially, generating a corresponding number of temporary database names based on the number of elements in the set, and storing the temporary database names and the table names of the included data forms in a first set. Based on the association relationship between the request-response complex and the data forms, establishing associations between all interfaces and data forms, and storing the interface URLs and the table names of the data forms in a second set. Traversing the first and second sets, establishing associations between all interfaces and databases, and storing the database names and the associated interface URLs in a third set. Traversing the third set, filtering out interface URLs associated with two or more databases. These interface URLs involve cross-database communication. To address this, the allocation is based on the number of data forms actually associated with the interface in the associated databases. Specifically: if the maximum number of data forms actually associated with the interface is equal across multiple databases associated with the interface URL, the interface URL can be randomly assigned to one of the associated databases; if the maximum number of data forms actually associated with the interface is not equal across multiple databases associated with the interface URL, the interface URL can be assigned to the database with the largest number of data forms associated with the interface.

[0146] The following section combines specific application scenarios with the associated steps in this embodiment to provide a relatively complete logical demonstration, specifically including:

[0147] Developers need to write standard API documentation and design data forms based on requirements analysis. Once these two documents are completed, developers can upload them to the software system hosting this invention and input the desired microservice granularity.

[0148] This embodiment parses the standard API documentation and the SQL file for the data form design uploaded by the developer. It identifies the interface URL in the standard API documentation and the request and response parameters contained within it. First, it decomposes the parameters in the API documentation that specify additional parameters. For example, the `deviceList` in the request / response body contains device-related parameters. This embodiment extracts these parameters and filters them along with the request and response parameters. Data filtering in this embodiment removes generic parameters such as `code`, `desc`, and `createTime`. Then, it deduplicates the filtered data, ultimately obtaining a complete list containing both request and response parameters, referred to hereafter as the "request / response composite." The interface URL and the request / response composite are stored in a set with the key `interface URL` and the value `request / response composite`. Finally, a set containing all interface URLs and their request / response composites from the standard API documentation is obtained. Similarly, this embodiment filters the data in the user-uploaded data form SQL (Structured Query Language) file, forming a set with the key `table name` and the value `field name`. Finally, the data extraction and filtering are completed, transforming the input file into data that can be computed, executed, and stored. After parsing the SQL file of the data form, this embodiment prompts the user to select a core data form. The system assigns a separate weight to the core data form, influencing the division of microservices.

[0149] Based on these data sets, this embodiment imports the elements from the request-response complex or field name list of each set into a pre-trained word vector model to obtain 300-dimensional word vectors for the attributes in each request-response complex and the elements in the field name list. These vectors are then stored in a set with the key "interface URL_request-response complex attribute name" or "data form name_field name" and the value being the corresponding 300-dimensional word vector.

[0150] After obtaining the 300-dimensional word vectors corresponding to the parameters in each request-response complex and the field names of the data forms, this embodiment iterates through the parameters in each request-response complex, performing similarity checks between the word vector of the current parameter and the word vectors of all data form field names. If the similarity is greater than or equal to 0.9, the two are considered a match. The matched data form field names are then stored in a data list, forming a set with the current parameter in the current request-response complex as the key and the data list of the data form field names matched by the current parameter in the current request-response complex as the value. Finally, traversing this set yields the matching relationship between each request-response complex and the data forms, forming a set with the request-response complex as the key and the data form list as the value. This set is then traversed to obtain the number of data forms matched by each request-response complex. If the number of data forms matched by a request-response complex is 1, this embodiment considers that request-response complex and that data form to be a match. Due to inherent issues in database form design, such as redundant fields and multiple meanings of terms, the accuracy of a match needs further verification when a request-response combination matches zero or more data forms. In such cases, the system will filter out these request-response combinations and prompt the developer for confirmation and modification.

[0151] After completing the above steps and obtaining the matching relationships between all request-response complex parameters and data forms, it can be observed that some request-response complexes match two or more data forms. This indicates that the interface to which the request-response complex belongs communicates with multiple data forms. When an interface communicates with multiple data forms, this embodiment considers that these multiple data forms interact through this interface, meaning that these multiple data forms exhibit a certain degree of correlation and clustering. Based on the clustering and correlation exhibited between data forms, an undirected graph can be constructed, where the vertices of the undirected graph are data forms, and the weights of the edges connecting the vertices are jointly determined by the weights of the request-response complex and the core data tables. It should be noted that the edges between vertices do not actually exist; they are merely a mathematical way of describing the association between the data forms they represent.

[0152] In this embodiment, the weights assigned to edges are consistent across all request-response complexes and all core data forms. By traversing the matching relationships between all request-response complexes and data forms, the associations between all data forms can be obtained, and an undirected graph can be constructed. Ultimately, a set of undirected graphs can be obtained, whose child elements are undirected graphs composed of aggregated data forms. Not all database forms can be used to construct undirected graphs; some interfaces only communicate with one database form, meaning that some independent database forms cannot establish connections with other database forms through their associated request-response complexes. Therefore, in this embodiment, these independent database forms are filtered out and stored separately.

[0153] The elements of the undirected graph set obtained above form the basis for aggregating data forms into a database. Based on the idea that "each microservice corresponds to one database," once the database partitioning criteria are obtained, the partitioning of microservices is largely determined.

[0154] At this point, partitioning the database according to the elements of the current undirected graph set is the most reasonable approach, and the resulting microservices are the most ideal. The microservice granularity input by the developer is a crucial factor influencing microservice partitioning. Therefore, this embodiment compares the user's desired microservice granularity with the number of elements in the undirected graph set, categorizing the cases as follows:

[0155] If the granularity of the microservices is consistent with the number of elements in the undirected graph set, then the database partitioning standard is directly based on each element in the current undirected graph set.

[0156] If the microservice granularity is smaller than the number of elements in the undirected graph set, then the elements in the undirected graph set are sorted in ascending order of the number of vertices. The first and second elements are grouped together and merged into one element. This process is iterated until the number of elements in the set matches the microservice granularity desired by the developers. Finally, the elements in the set are used as the candidate microservice partitioning criteria.

[0157] If the microservice granularity is larger than the number of elements in the undirected graph set, the elements in the undirected graph set are partitioned to increase the number of elements in the set until the number of elements in the set matches the microservice granularity desired by the developer. The partitioning method used in this embodiment is to find the global minimum cut of the undirected graph and divide the undirected graph into two connected components according to the global minimum cut.

[0158] After obtaining the final undirected graph set, extract each element from the set sequentially. Generate a corresponding number of temporary database names based on the number of elements in the set, and store these temporary database names along with the table names of the contained data forms in the first set. Based on the association between the request / response complex and the data forms, establish associations between all interfaces and data forms, storing the interface URLs and data form table names in the second set. Iterate through the first and second sets, establishing associations between all interfaces and databases, storing the database names and associated interface URLs in the third set. Iterate through the third set, filtering out interface URLs associated with two or more databases. These interface URLs involve cross-database communication. Therefore, it is necessary to divide them based on the number of data forms actually associated with the interface in the associated databases. If the maximum number of data forms actually associated with an interface URL is equal across multiple associated databases, the interface URL can be randomly assigned to one of the associated databases. If the maximum number of data forms actually associated with an interface URL is not equal across multiple associated databases, the interface URL can be assigned to the database with the most data forms associated with the interface.

[0159] After aggregating and partitioning the data forms and API URLs, the microservice partitioning is complete. Finally, this embodiment will output the most ideal microservice partitioning criteria and the partitioning criteria that meet the user's desired microservice granularity.

[0160] Example 3:

[0161] like Figure 15 The diagram shown is an architectural schematic of a microservice partitioning device according to an embodiment of the present invention. The microservice partitioning device of this embodiment includes one or more processors 21 and a memory 22. Figure 15 Take a processor 21 as an example.

[0162] Processor 21 and memory 22 can be connected via a bus or other means. Figure 15 Taking the example of a connection between China and Israel via a bus.

[0163] The memory 22, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs and non-volatile computer-executable programs, such as the microservice partitioning method in Embodiment 1. The processor 21 executes the microservice partitioning method by running the non-volatile software programs and instructions stored in the memory 22.

[0164] Memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 22 may optionally include memory remotely located relative to processor 21, which can be connected to processor 21 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0165] The program instructions / modules are stored in the memory 22 and, when executed by one or more processors 21, execute the microservice partitioning method in Embodiment 1 above.

[0166] It is worth noting that the information interaction and execution process between the modules and units in the above-mentioned device and system are based on the same concept as the processing method embodiment of the present invention. For details, please refer to the description in the method embodiment of the present invention, and will not be repeated here.

[0167] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk, etc.

[0168] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.< / t>

Claims

1. A microservice partitioning method, characterized in that, include: Based on the parameters of the interface and the data in the data form, find the relationship between the interface and the data form; Based on the relationship between the interface and the data form, generate one or more first relationship diagrams to facilitate the division of microservices according to the first relationship diagrams; When the number of first relationship graphs is less than the preset microservice granularity, the division of microservices based on the first relationship graphs includes: splitting the first relationship graph with the most data forms based on the number of data forms in each first relationship graph; wherein, in one split, a first relationship graph is split into multiple connected relationship graphs, and the multiple connected relationship graphs are used as multiple first relationship graphs in the next split, until the sum of the number of connected relationship graphs and the number of unsplit first relationship graphs equals the preset microservice granularity; each connected relationship graph and each unsplit first relationship graph are used as a second relationship graph, and the division of microservices is performed based on each second relationship graph; In the first relational graph, data forms are used as vertices, and interfaces associated with multiple data forms are used as edges for pairwise connections between the multiple data forms.

2. The microservice partitioning method according to claim 1, characterized in that, The step of finding the association between the interface and the data form based on the interface parameters and the data in the data form specifically includes: Convert the parameters of the interface into corresponding parameter vectors, and convert the field names of the data in the data form into corresponding data vectors; Calculate the similarity between each parameter vector and each data vector; If the similarity between at least one first parameter vector and at least one first data vector is greater than a preset similarity, then the first interface is associated with the first data form; wherein, the first parameter vector is a parameter vector obtained by converting the parameters of the first interface, and the first data vector is a data vector obtained by converting the field names of the data in the first data form.

3. The microservice partitioning method according to claim 1, characterized in that, The step of splitting a first relational graph into multiple connected relational graphs specifically includes: The weight values ​​of the first data form, the second data form, and the interfaces that are associated with both the first and second data forms are weighted and summed to obtain the edge weight value of the edge connecting the first and second data forms. Based on the edge weights of all edges in the first relation graph, the corresponding edges in the first relation graph are selectively split to divide the first relation graph into multiple relation graphs, and the sum of the edge weights of all split edges is minimized.

4. The microservice partitioning method according to claim 1, characterized in that, The process of dividing services into microservices based on each second relationship graph specifically includes: For each second relationship graph, a corresponding microservice is established. All interfaces corresponding to unsplit edges in the second relationship graph are assigned to the corresponding microservices. Interfaces corresponding to split edges are assigned to the microservices most closely associated with those interfaces. Among them, the microservice corresponding to the second relationship graph with the largest number of data forms associated with the first interface is taken as the microservice most closely associated with the first interface. And / or, for each second relational graph, establish a corresponding database and divide all data forms in the second relational graph into the corresponding database.

5. The microservice partitioning method according to claim 1, characterized in that, When the number of elements in the first relationship graph exceeds the preset microservice granularity, the step of dividing the service into microservices based on the first relationship graph specifically includes: Based on the number of data forms in each first relationship graph, the two first relationship graphs with the fewest data forms are merged; wherein, in one merge, multiple first relationship graphs are merged into multiple merged relationship graphs, and the merged relationship graphs are used as first relationship graphs in the next merge, until the total number of merged relationship graphs and unmerged first relationship graphs equals the preset microservice granularity. Each merged relation graph and each unmerged first relation graph are used as a second relation graph. Based on each second relation graph, microservices are divided.

6. The microservice partitioning method according to claim 5, characterized in that, The process of dividing services into microservices based on each second relationship graph specifically includes: For each second relation graph, a corresponding microservice is established, and the interfaces corresponding to all edges in the second relation graph are assigned to the corresponding microservices; And / or, for each second relational graph, establish a corresponding database and divide all data forms in the second relational graph into the corresponding database.

7. The microservice partitioning method according to any one of claims 1-6, characterized in that, The interface is stored in a request-response complex, which stores the request parameters and response parameters of the interface. The request-response complex also stores data forms associated with the interface to represent the relationship between the interface and the data forms.

8. The microservice partitioning method according to any one of claims 1-6, characterized in that, The interface is obtained from the API design document, and the data form is obtained from the data form design document.

9. A microservice partitioning device, characterized in that, The device includes: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor for performing the microservice partitioning method according to any one of claims 1-8.

Images