Microservice development support system and microservice development support method

Abstract

To reduce the microservice development burden.SOLUTION: A microservice development support system includes: an input section that receives an industry type for providing a microservice; a graph selection section that selects a trade-off relationship graph on the basis of the received industry type; a combination processing section that obtains a feasibility of a microservice by a combination of levels of required performance items included in the selected trade-off relationship graph; and an output section that outputs a data store and a library function corresponding to the combination of the levels of the required performance items as a microservice configuration plan when the obtained feasibility satisfies a predetermined criterion.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a microservice development support system and a microservice development support method. [Background technology]

[0002] Distributed transaction functionality is required to provide monolithic applications in which multiple service modules work closely together within a single process, which are currently operating in various fields, as microservices, which are realized by multiple independent service modules.

[0003] By appropriately using a library with transaction control middleware, distributed transaction functions can be provided efficiently.

[0004] In conventional technology, distributed transaction microservices have been developed by introducing architectures and distributed transaction management servers that provide distributed transaction functionality for specific databases and specific data formats.

[0005] However, the problem is that it takes time to develop distributed transaction functionality for such microservices.

[0006] For example, there are problems with libraries that include transaction control middleware, such as the inability to build functions that meet required performance, the time required for trial and error to improve performance in cases where the required performance cannot be met, and the difficulty of combinatorial optimization, which makes it time-consuming to build and consider the architecture.

[0007] For this reason, it is desirable for developers to propose combinations of required performance, data stores, architectures, etc. that are suited to the target industry when developing distributed transactions for microservices.

[0008] Patent Document 1 discloses a management system that accepts input of a distributed transaction flow that specifies the call order of participating systems and service characteristic information that represents the service characteristics of each participating system, and based on pattern information that includes information for each pattern that represents the constraints on the service characteristics of the called participating system, identifies, for each participating system, a pattern that satisfies the constraints corresponding to the service characteristics of that participating system as an application pattern, generates a call program with the pattern applied for each participating system, and generates a distributed transaction program based on each call program with the pattern applied and the call order of the participating systems. [Prior art documents] [Patent documents]

[0009] [Patent Document 1] Japanese Patent Publication No. 2022-189463 Summary of the Invention [Problem to be solved by the invention]

[0010] We provide a microservice development support system that determines and proposes combinations of required performance, data stores, architectures, etc. that are suited to the target industry of developers of microservices that use transaction control middleware libraries, based on the target industry of developers, the performance of the data stores used, the data handled, and the performance required by users of the microservices. [Means for solving the problem]

[0011] The above-mentioned object is achieved by a microservice development support system that includes an input unit that accepts the industry in which the microservice will be provided, a graph selection unit that selects a trade-off relationship graph based on the accepted industry, a combination processing unit that determines the feasibility of a microservice based on a combination of levels of required performance items included in the selected trade-off relationship graph, and an output unit that outputs, when the determined feasibility satisfies a predetermined standard, a data store and library function that correspond to the combination of levels of required performance items as a microservice configuration proposal. [Effects of the Invention]

[0012] According to the present invention, the burden of microservice development can be reduced. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a diagram illustrating an example of a configuration of a microservice development support system according to an embodiment of the present invention. [Figure 2] 10 is an example of data store information according to an embodiment of the present invention. [Figure 3] 10 is an example of library information according to an embodiment of the present invention. [Figure 4] 10 is an example of required performance information according to an embodiment of the present invention. [Figure 5] 10 is an example of a configuration plan table according to an embodiment of the present invention. [Figure 6] FIG. 1 is a diagram illustrating a trade relationship graph according to an embodiment of the present invention. [Figure 7] 10 is an example of a method for determining a combination of required performance in an embodiment of the present invention. [Figure 8] 10 is an example of a method for calculating feasibility using weights between required performances in an embodiment of the present invention. [Figure 9] 10 is an example of adjusting required performance using a trade relationship graph according to an embodiment of the present invention. [Figure 10] 10 is an example of selecting a data store using a trade relationship graph according to an embodiment of the present invention. [Figure 11] 10 is an example of selecting a library function using a trade relationship graph according to an embodiment of the present invention. [Figure 12] 1 is an example of a flowchart illustrating processing of a microservice development support system according to an embodiment of the present invention. [Figure 13] 10 is a flowchart illustrating an example of a combination process according to an embodiment of the present invention. [Figure 14] 10 is an example of a flowchart illustrating an architecture selection process according to an embodiment of the present invention. [Figure 15] 10 is an example of a flowchart illustrating a library selection process according to an embodiment of the present invention. [Figure 16] 10 is an example of an output screen according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0014] Hereinafter, embodiments of the present invention will be described with reference to the drawings. In each drawing for explaining the embodiments, the same components are given the same names and reference numerals as much as possible, and repeated explanations thereof will be omitted.

[0015] The present invention is not limited to the following examples, and includes various modifications and equivalent configurations within the spirit and scope of the appended claims. For example, the above examples have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations.

[0016] Furthermore, the processing units and processing modules described in the embodiments may be realized in part or in whole in hardware, for example by designing them as integrated circuits, or may be realized in software by having a processor interpret and execute a program that realizes each function.

[0017] The information explained in the embodiment may be a table, a database (DB), or data stored in the main memory.

[0018] FIG. 1 is a diagram illustrating an example of a configuration of a microservice development support system according to an embodiment of the present invention.

[0019] The microservice development support system 1 is configured with a computer including a CPU (Central Processing Unit) 2, a main memory device 3, an external memory device 4, and an input / output unit 5. It may also be realized by using a cloud service that provides computer resources.

[0020] The main memory device 3 includes an input information storage unit 10 and a combination processing unit 11, and the combination processing unit 11 includes a graph selection unit 14 that selects a trade-off relationship graph, a library function selection unit 12 that selects library functions, and an architecture selection unit 13 that selects a data store.

[0021] These processing units are realized as software modules and are executed by the CPU 2 with reference to data stored in the external storage device 4 .

[0022] The external storage device 4 stores a trade-off relationship graph DB 15 that stores trade-off relationship graphs corresponding to the industry, data store information 16 that stores information about the characteristics of data stores, library information 17 that stores functional information about libraries, required performance information 18 that stores required performance levels for required performance items, and a configuration proposal table 19 that stores configuration information that satisfies the conditions entered by the user, and is composed of devices such as an HDD (Hard Disk Drive) and an SSD (Solid State Drive).

[0023] The input / output unit 5 accepts processing requests from users and outputs the processing results of the microservice development support system. The input / output unit 5 may be divided into an input unit and an output unit. It is composed of devices such as a NIC (Network Interface Card) and an HBA (Host Bus Adapter).

[0024] FIG. 2 shows an example of data store information according to an embodiment of the present invention.

[0025] Stores the type of each item entered by the user. The type stored will vary depending on how the user uses the system, but at least the industry type will be accepted.

[0026] The industry type is used to select a trade-off relationship graph that reflects the feasibility of microservices at the performance item level for each industry type, and for other items, the type specification is accepted and the accepted type is used to obtain a configuration that gives priority to it.

[0027] FIG. 3 shows an example of library information in an embodiment of the present invention.

[0028] The library function and the value specifying whether or not the function is required are stored as 1 or 0. For library functions specified as available, a configuration in which the function can be used is preferentially selected.

[0029] FIG. 4 shows an example of required performance information in the embodiment of the present invention.

[0030] Required performance items and their required performance levels are stored in association with each other. Required performance items include the isolation level for controlling transaction behavior, the latency level, which is the time it takes for a request to be processed, and the reliability level, such as ACID characteristics, and the level can be specified using a numerical value defined in the microservice development support system.

[0031] Here, the ACID properties are Atomicity, Consistency, Isolation, and Durability.

[0032] When providing microservices, you specify which required performance items are important. The importance of each required performance item varies depending on the industry, but even within the same industry, it can differ depending on the target customers, system scale, etc.

[0033] FIG. 5 is an example of a configuration plan table in the embodiment of the present invention.

[0034] The combination processor 11 stores the combination plan of the required item level and the data store obtained.

[0035] 6 is a diagram illustrating a trade relationship graph according to an embodiment of the present invention. It includes required performance items 30, a data store 31, and a library function 32. The required performance items 30 include required performance item nodes, the data store 31 includes data store nodes, and the library functions 32 include library function nodes. Other items may also be included.

[0036] In the required performance item 30, nodes that indicate the required performance level, such as the isolation level, are connected by edges. The presence of an edge indicates that the combination of the nodes connected by the edge is feasible. Furthermore, each edge is assigned a weight that indicates feasibility.

[0037] Isolation level 4 is more difficult to achieve than isolation level 1. Similarly, latency level 4 is more difficult to achieve than latency level 1.

[0038] In this example, solid edges indicate 81% to 100% feasibility, dashed edges indicate 61% to 80%, 41% to 60%, or 21% to 40% feasibility, depending on the dash type. No line indicates 0% to 20% feasibility.

[0039] The feasibility can be specified in more detail or can be specified as two types: 0% and 100%. Although not shown in the trade relationship graph in Figure 7, feasibility can also be specified between the isolation level and the data store.

[0040] This example shows that it is 100% possible to achieve latency level 1 with isolation level 1, and that in this case any of the following data stores can be used: MongoDB (registered trademark), RDB (Relational Data Base), Scalar DB, and S3.

[0041] When using MongoDB, Local TX (local transaction), JSON data, and language support Python (registered trademark) can all be used, and when using JSON data, it is possible to use library functions that perform try processing and confirm processing.

[0042] However, it is shown that it is difficult to use data store S3 when isolation level 4 and latency level 4 are selected.

[0043] FIG. 7 shows an example of how to determine a combination of required performance in an embodiment of the present invention.

[0044] We will explain the case where the required performance of isolation level 4, reliability level 3, and latency level 3 is specified, and the trade-off relationship graph selected based on the industry is a graph showing feasibility as shown in Figure 8.

[0045] For simplicity, edges drawn with solid lines indicate 100% feasibility, edges drawn with dotted lines indicate 40% feasibility, and no edges indicated indicate 0% feasibility.

[0046] Furthermore, in this example, we assume that there is a 100% possibility of achieving a balance between isolation and latency, regardless of the level.

[0047] As can be seen from Figure 7, there is no edge between reliability level 3 and latency level 3 at the specified required performance level, and it can be seen that the feasibility is 0%.

[0048] This relationship is shown in the left diagram of Figure 8, which shows a triangle with no edge between latency and reliability. In this case, the average edge weight is (100% + 40% + 0%) / 3 ≒ 47%. Therefore, we lower the level of the required performance with the smallest edge weight to find the average edge weight.

[0049] Lowering the reliability level does not increase the edge weight, so if we lower the latency level weight, the edge weight between latency and reliability becomes 40%, as shown in the right diagram of Figure 8, and the average edge weight becomes (100% + 40% + 40%) / 3 = 60%.

[0050] If the feasibility is set to 50% or more, it is possible to obtain a combination of feasible required performance items by changing the required performance level in this way.

[0051] As a result, a graph is obtained that selects latency level 2 surrounded by a solid line from latency level 3 surrounded by a dotted line, as shown in the trade-off relationship graph in Figure 9, making it possible to confirm the appropriateness of the levels of required performance items.

[0052] Figure 10 shows an example of data store selection using a trade relationship graph in an embodiment of the present invention. This graph omits all information other than the required performance items and data stores. As shown in Figure 10, if isolation level 4, reliability level 3, and latency level 2 are selected, the feasible data store is MongoDB.

[0053] MongoDB's features include local consistency, use of JSON data, and language support for Python.

[0054] Figure 11 shows an example of library function selection using a trade relationship graph in an embodiment of the present invention. This graph omits everything except the required performance items and library functions. As shown in Figure 11, when Isolation Level 4, Reliability Level 3, and Latency Level 2 are selected, the available library functions are Try, Confirm, Cancel, and Lock.

[0055] Next, we will explain how the above process is executed on Microservice Development Support System 1, which is shown in the block diagram in Figure 1.

[0056] FIG. 12 is an example of a flowchart illustrating the processing of the microservice development support system according to the embodiment of the present invention.

[0057] The input information storage unit 10 receives the selection of the business type and stores it in the data store information 16 (S1). Next, data store information other than the business type, such as the type of DB to be used and the type of data format to be used, is received (S2) and stored in the data store information 16.

[0058] Library information, which is a function that may be used by users of the microservice, is received (S3) and stored in library information 17.

[0059] Required performance such as an isolation level indicating the degree to which multiple transaction processes do not interfere with each other, a latency level that is the response time of the database, and a reliability level of transaction processing is accepted (S4) and stored in required performance information 18.

[0060] Each level may be defined by the microservice development support system, and in this embodiment, it is defined in five stages from level 1 to level 5, with level 5 being the highest level.

[0061] If the microservice development support system displays and allows users to select from supported industries and database candidates, it will be possible to propose more reliable configurations.

[0062] Since the industry is essential information, an error may be output if it is not selected, but other information does not have to be selected.

[0063] Next, the trade-off relationship graph to be used is obtained from the trade-off relationship graph DB 15 based on the accepted industry type (S5).

[0064] The trade-off relationship graph is a graph as shown in Fig. 6. It includes required performance items 30, a data store 31, and a library function 32. Other items may also be included.

[0065] Using the obtained trade-off relationship graph, the combination processing unit 11 changes the isolation level, latency level, reliability level, etc. to obtain a combination of each required performance level that is highly feasible (S6).

[0066] The architecture selection unit 13 determines a data store that corresponds to the determined combination of required performance levels (S7).

[0067] The library function selection unit 12 determines the library functions supported by the determined data store (S8).

[0068] The input / output unit 5 outputs the selected required performance level, data store, library function, etc. to the screen (S9).

[0069] FIG. 13 is an example of a flowchart showing the combination process according to an embodiment of the present invention.

[0070] The required performance information 18 is referenced (S10) to determine the required performance item level designated by the user. If the required performance item level is not designated by the user, the highest required performance item level is set as the default.

[0071] A trade-off relationship graph selected based on the type of business is obtained from the trade-off relationship graph DB 15, and the average value of the weight of the edge indicating the feasibility connecting the specified requirement item levels is calculated (S11).

[0072] It is determined whether the calculated average value of the weights is equal to or greater than a predetermined value (S12). In this example, the determination is made based on whether it exceeds 50, but a higher or lower value may be used. Using a lower value increases the difficulty of microservice development, while using a higher value makes microservice development easier.

[0073] If the predetermined value is not reached, the node with the highest level among the requirement performance item nodes at both ends of the edge with the smallest edge weight connecting the requirement performance item nodes is lowered by one level (S13). Other criteria may also be used to adjust the average edge weight to 50 or more.

[0074] The average value of the edge weights is recalculated using the changed required performance item level (S14), and the process returns to S12 to determine the average value of the weights.

[0075] If the average value of the weights is equal to or greater than a predetermined value in S12, the combination of the levels of the required performance items that meets the conditions is stored in the configuration plan table 19 (S15).

[0076] FIG. 14 is a flowchart showing an example of the architecture selection process according to the embodiment of the present invention.

[0077] The required performance item levels obtained by the combination process are fixed in the trade-off relationship graph (S20). If the user has specified a data store, the data store node is fixed (S21).

[0078] The average weight of the edges between the fixed required performance item node and the selected data store node and data store characteristic node is calculated (S22). If no data store is specified, the default data store is used.

[0079] It is determined whether the calculated average value is equal to or greater than a predetermined value (S23). In this example, it is determined whether the average value is equal to or greater than 50.

[0080] If the weight does not reach the predetermined value, one of the nodes at both ends of the edge with the smallest weight connecting the data store node and the data store property node is changed (S24).If a data store is specified, the data store node is not changed.

[0081] The average value of the edge weight is recalculated using the changed node (S25), and the process returns to S23.

[0082] If the predetermined value is reached in S23, the selected data store and data store characteristics are stored in the configuration plan table 19 (S26).

[0083] FIG. 15 is an example of a flowchart showing the library selection process according to an embodiment of the present invention.

[0084] The required performance item levels obtained in the combination process are fixed in the trade-off relationship graph (S30). The data stores and data store properties selected in the architecture selection process are fixed (S31). If the user has specified a library function, the library function node is fixed.

[0085] The average weights of the edges between the fixed required performance items, the data stores and the properties of the data stores, and the library function items are calculated (S32).

[0086] It is determined whether the calculated average value is equal to or greater than a predetermined value (S33). In this example, it is determined whether the average value is equal to or greater than 50.

[0087] If the predetermined value is not reached, the library function node is changed (S24).If a library function is specified, there is no room for changing the library function, so an error is output.

[0088] The average value of the edge weight is recalculated using the changed node (S35), and the process returns to S33.

[0089] If the predetermined value is reached in S33, the selected library function is stored in the configuration plan table 19 (S36).

[0090] FIG. 16 is an example of an output screen in an embodiment of the present invention.

[0091] Specify the industry 50, data store 51, library function 52, and required performance 53, and press the Build Proposal button 54 to output a microservice construction proposal 56. When the MS construction proposal number 57 is selected, the trade-off relationship graph used to obtain the selected construction proposal is displayed, and the selected node is enclosed in a square.

[0092] The industry type 50 is a required input item for selecting a trade-off relationship graph according to the industry type, but the data store 51, library function 52, and required performance 53 do not have to be specified. If they are entered, an error occurs if a configuration plan exceeding the predetermined feasibility cannot be found. In such cases, specifying fewer options increases the chances of obtaining a configuration plan. [Explanation of symbols]

[0093] 1: Microservices development support system 2: CPU 3: Main memory 4: External storage device 5: Input / output section 10: Input information storage section 11: Combination processing unit 12: Library function selection section 13: Architecture selection section 14: Graph selection section 15: Trade-off relationship graph DB 16: Data store information 17: Library information 18:Required performance information 19: Composition table 20: Library candidate information

Claims

1. In a microservice development support system, an input unit that accepts the industry in which the microservice is provided; a graph selection unit that selects a trade-off relationship graph based on the received industry; a combination processing unit that determines the feasibility of a microservice by combining the levels of required performance items included in the selected trade-off relationship graph; A microservice development support system that includes an output unit that outputs a data store and library functions corresponding to a combination of levels of required performance items as a microservice configuration plan when the desired feasibility meets predetermined standards.

2. The microservice development support system according to claim 1, The required performance items for the microservice development support system include isolation, latency, and reliability.

3. The microservice development support system according to claim 1, A microservice development support system in which the trade-off relationship graph includes required performance item nodes, data store nodes, and library function nodes, and the nodes are connected by edges corresponding to feasibility.

4. The microservice development support system according to claim 3, A microservice development support system in which edges of the trade-off relationship graph are associated with weights indicating feasibility.

5. The microservice development support system according to claim 4, A microservice development support system in which the combination processing unit calculates the average value of the weights associated with the edges included in the combination of required performance items as a feasibility of a microservice based on a combination of the levels of the required performance items, and if the calculated average value exceeds a predetermined value, the microservice configuration proposal is adopted.

6. The microservice development support system according to claim 5, If the calculated average value does not reach a predetermined value, the combination processing unit lowers the level of the required performance item connected by the edge with the smallest weight connecting the required performance item nodes, and calculates the average value again.

7. The microservice development support system according to claim 1, The input section accepts the level of required performance items, The combination processing unit determines the feasibility of the microservice based on the level of the required performance items received by the input unit, The output unit is a microservice development support system that outputs data stores and library functions corresponding to combinations of the levels of required performance items as a microservice configuration plan that satisfies the levels of the received required performance items.

8. The microservice development support system according to claim 1, The input part accepts the data store, The combination processing unit determines a microservice configuration plan with the highest required performance level when using the received data store, The output section is a microservice development support system that outputs a microservice configuration plan with the highest required performance level.

9. In the microservice development support method, The input section accepts the industry for which the microservice is provided, A graph selection unit selects a trade-off relationship graph based on the accepted industry. A combination processing unit determines the feasibility of the microservice by combining the levels of the required performance items included in the selected trade-off relationship graph, A microservice development support method in which, when the output unit determines that the desired feasibility satisfies a predetermined standard, it outputs a data store and a library function corresponding to a combination of levels of required performance items as a microservice configuration proposal.

Images