Method and device for decomposing software system microservice

Abstract

The application discloses a kind of software system microservice's disassembly method and device, wherein the method includes: software system is split into multiple business modules, each business module is split into multiple function modules;According to the work of each user each day to each function module operation, the work of function module that each two business modules exist intersection is determined;According to the work of function module that each two business modules exist intersection, and the total work of the two business module corresponding function module, the intersection rate between the two business modules is determined;According to the intersection rate between the two business modules, and preset intersection rate threshold value, determine whether the two business modules are split into two microservices.The application can realize reasonably microservice disassembly.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of microservices, and in particular to a software system microservice disassembly method and device. BACKGROUND

[0002] This section is intended to provide background or context to the embodiments of the application recited in the claims. The description herein does not constitute admission that the subject matter disclosed in this section is prior art to the present application.

[0003] At present, in the process of enterprise and enterprise informationization construction, the relatively complex but relatively independent business is faced, and the microservice technology architecture is applied more and more widely. The application of microservice technology architecture is easy to develop and maintain, and each service is not restricted by technology, such as some services apply to MQ (Message Queue, message queue), and some services do not apply to MQ. That is, other technical components can be introduced on demand in the service layer. In terms of maintenance, it can be upgraded on demand as much as possible to affect the main business.

[0004] The complex business relationship of the software system determines that there will be no completely independent (decoupled) business module. How to reasonably split the complex business into relatively independent microservices needs to be subjectively divided by the development manager according to the specific business demand. At present, the standard for division is: split the completely independent or largely independent business module into an independent service. However, there is no mature theoretical system to divide the microservice, so once the microservice splitting is unreasonable, it will bring great difficulty to the development and maintenance work, which will lose the significance of applying the microservice technology architecture. SUMMARY

[0005] The embodiment of the present application provides a software system microservice disassembly method for reasonably disassembling microservices. The method comprises:

[0006] Splitting the software system into a plurality of business modules, and splitting each business module into a plurality of function modules;

[0007] According to the work amount of each user per day on each function module, the work amount of the function module existing between each two business modules is determined;

[0008] According to the work amount of the function module existing between each two business modules, and the total work amount of the function module corresponding to the two business modules, the cross rate between the two business modules is determined;

[0009] According to the cross rate between the two business modules and the preset cross rate threshold, it is determined whether the two business modules are split into two microservices.

[0010] The embodiment of the present application also provides a software system micro-service disassembling device for reasonably performing micro-service disassembling, the device comprises:

[0011] a splitting unit configured to split the software system into a plurality of business modules and split each business module into a plurality of function modules;

[0012] a workload determining unit configured to determine the workload of the function module existing in the intersection of each two business modules according to the workload of each user operating each function module per day;

[0013] a cross rate determining unit configured to determine the cross rate between the two business modules according to the workload of the function module existing in the intersection of each two business modules and the total workload of the function modules corresponding to the two business modules;

[0014] a disassembling determining unit configured to determine whether to split the two business modules into two micro-services according to the cross rate between the two business modules and a preset cross rate threshold.

[0015] The embodiment of the present application also provides a computer device comprising a memory, a processor and a computer program stored in the memory and capable of running on the processor, and the processor implements the software system micro-service disassembling method when executing the computer program.

[0016] The embodiment of the present application also provides a computer readable storage medium, wherein the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the software system micro-service disassembling method.

[0017] The embodiment of the present application also provides a computer program product, wherein the computer program product comprises a computer program, and the computer program is executed by a processor to implement the software system micro-service disassembling method.

[0018] In the embodiment of the present application, the software system micro-service disassembling scheme comprises the following steps: splitting the software system into a plurality of business modules and splitting each business module into a plurality of function modules; determining the workload of the function module existing in the intersection of each two business modules according to the workload of each user operating each function module per day; determining the cross rate between the two business modules according to the workload of the function module existing in the intersection of each two business modules and the total workload of the function modules corresponding to the two business modules; and determining whether to split the two business modules into two micro-services according to the cross rate between the two business modules and a preset cross rate threshold, so that the micro-service disassembling can be reasonably performed. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description only constitute some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor. In the drawings:

[0020] Figure 1 The principle diagram of the software system micro-service disassembly in the embodiments of the present application;

[0021] Figure 2 The disassembly idea diagram of the software system micro-service in the embodiments of the present application;

[0022] Figure 3 The function structure diagram of the software system micro-service disassembly in the embodiments of the present application;

[0023] Figure 4 The function cross diagram of the software system micro-service disassembly in the embodiments of the present application;

[0024] Figure 5 The completion diagram of the software system micro-service disassembly in the embodiments of the present application;

[0025] Figure 6 The flow diagram of the software system micro-service disassembly method in the embodiments of the present application;

[0026] Figure 7 The structure diagram of the software system micro-service disassembly device in the embodiments of the present application. DETAILED DESCRIPTION

[0027] In order to make the purpose, technical solutions and advantages of the embodiments of the present application more clear and explicit, the following will further describe the embodiments of the present application in combination with the drawings. Herein, the illustrative embodiments of the present application and their descriptions are used to explain the present application, but not as a limitation of the present application.

[0028] Figure 6 The flow diagram of the software system micro-service disassembly method in the embodiments of the present application, as shown in Figure 6 The method comprises the following steps:

[0029] Step 101: splitting the software system into a plurality of business modules, and splitting each business module into a plurality of function modules;

[0030] Step 102: determining the workload of the function modules existing in the intersection of each two business modules according to the workload of each user operating each function module per day;

[0031] Step 103: Determine the overlap rate between two business modules based on the workload of the functional modules that overlap between them and the total workload of the corresponding functional modules.

[0032] Step 104: Based on the crossover rate between the two business modules and the preset crossover rate threshold, determine whether to split the two business modules into two microservices.

[0033] The software system microservice decomposition method provided in this invention involves: dividing the software system into multiple business modules, and further dividing each business module into multiple functional modules; determining the workload of overlapping functional modules between any two business modules based on the daily workload of each user on each functional module; determining the overlap rate between two business modules based on the overlap of their functional modules and the total workload of their corresponding functional modules; and determining whether to split the two business modules into two microservices based on the overlap rate and a preset overlap rate threshold, thus achieving reasonable microservice decomposition. The following provides a detailed description of this software system microservice decomposition method.

[0034] Considering the technical issues of the current microservice decomposition process, such as... Figure 1 As shown, the inventors proposed the following approach for this invention: the core parameter of the splitting result is the crossover rate, and the core calculation element of the crossover rate is the workload assessment table (as shown in Table 1 below). Therefore, the direct influencing factor on the splitting result is the accuracy of the workload assessment based on requirements. Thus, the existence of subjective human judgment factors can interfere, and the accuracy of the splitting primarily depends on the assessment level of the architect or development manager. Figure 2 As shown, the embodiments of the present invention divide functional modules based on the business requirements (requirement documents) of the patent pre-examination system, and form a structure consisting of surfaces (such as...). Figure 3 The "patent pre-examination system" shown in the image is connected to the online system (e.g., the patent pre- Figure 3 The terms "System Management," "Process Management," and "Preliminary Review Management" shown in the diagram are arranged from lines to points (e.g., ...). Figure 3 The diagram shows a functional structure of "dots" (e.g., "User Management," "Role Management," "Model Management," "Approval Management," "CPC Viewing," "Category Management," etc.), and uses this diagram to assess whether there is significant overlap between the dots. If the overlap is large (e.g., exceeding 20%), it is not advisable to split it into multiple microservices. If there is minimal (less than 20%) business overlap, and the business requirements and data are independent, then such a dot should be split into independent microservices, using Feign calls to handle the limited data interaction between dots.

[0035] Therefore, the embodiment of the present application proposes a software system micro-service disassembly method, which forms a set of micro-service splitting methods based on the business requirements of the patent pre-examination system, and applies the method to complete the design and development of the pre-examination system, and completes the implementation of the patent pre-examination system of multiple intellectual property protection centers. Next, taking the patent pre-examination business system as an example, the software system micro-service disassembly method is introduced in detail.

[0036] The pros and cons of micro-service disassembly mainly depend on whether the understanding of the requirements is in place. According to the requirements of the overall business system, the module is divided. In step 101, the module division basis can be: the system module can be divided from the user group of the demand, the business type, and then the sub-module (business module, such as the system management business module, process management business module and pre-examination management business module in Figure 3 ) is disassembled under the patent pre-examination system module in Figure 3 . After the sub-module disassembly, the function points (function modules, such as the corresponding function modules under each business module shown in Figure 3 , such as "user management", "role management", "log management" in system management, "model management", "approval management" in process management, "CPC viewing", "classification management", "case approval" in pre-examination management, etc.) are divided. In step 102, after the relatively detailed requirements are found, the data, business, such as the business workload in the following formula, that need to be interacted between the modules are considered. In step 103, the function points (function modules) with interaction are marked, and then based on Table 1, the cross rate is calculated according to the following formula: cross rate = (cross face workload / cross module total workload x 100) %. In step 104, if the cross rate exceeds the preset cross rate threshold (for example, 20%), it is judged that the micro-service disassembly of the module is not feasible, that is, in an embodiment, according to the cross rate between the two business modules and the preset cross rate threshold, whether to split the two business modules into two micro-services can include: when the cross rate between the two business modules exceeds the preset cross rate threshold, it is determined that the two business modules are not split into two micro-services. If the cross rate does not exceed 20%, that is, it is lower than the preset cross rate threshold, it proves that there is disassembly feasibility, that is, in an embodiment, according to the cross rate between the two business modules and the preset cross rate threshold, whether to split the two business modules into two micro-services can include: when the cross rate between the two business modules is lower than the preset cross rate threshold, it is determined that the two business modules are split into two micro-services. The lower the cross rate, the higher the micro-service disassembly feasibility.

[0037] Table 1: Workload evaluation table

[0038]

[0039] To facilitate understanding of how the present application is implemented, the following will be introduced in detail in combination with Figures 3 to 5 The analysis starts from the "patent pre-trial system" shown in Figure 3 , whether there is a theoretical split of microservices, if split: system management, process management, pre-trial management three microservices. Then the system management, process management and business (pre-trial management) relationship is not big, belongs to the highly decoupled, but process management, business management (pre-trial management) is inseparable from the user, the user management is distributed in the system management. In addition to the user, there is no cross correlation, then the Feign call in the microservice architecture can be used to realize the communication between the process management business module, the pre-trial management business module and the system management business module. The process model (such as "process management" shown in Figure 3 ) needs to be approved by the user, and the role of the system management can be used to find the approval user according to the role, so that the system management provides an interface for searching the user according to the role number, and the process management uses Feign to call. In an embodiment, the above-mentioned software system microservice splitting method can also include: for the function modules between the two microservices which are split into two microservices, the Feign call interface method is used for the interaction between the two microservices. Pre-trial management needs to conduct case approval, and the approval support is provided by process management. Process management needs to abstract the initiation and approval of the document, and then pre-trial management transfers data through Feign call. According to the demand, different business actions need to be generated in each link of the pre-trial management approval process. The model of the approval is from the process management, so as to realize different things at different approval points of the process model. It is necessary to configure different interface calls on the approval nodes of the process model, and the pre-trial system needs to provide corresponding interfaces according to the demand scenario to supply the process management for calling. According to the functional structure Figure 3 and the corresponding logical analysis, the functional cross graph of the surface, line and point is formed as shown in Figure 4 . According to the functional cross graph, the workload evaluation of the cross surface (see the cross rate table, that is, Table 2 below) can be carried out. It can be seen from the cross rate result that they are all less than 20% (split standard), so that the system management, process management and pre-trial management three business modules can be split into three microservices, as shown in Figure 5 : system management service, process management service and pre-trial management service.

[0040] Table 2: Cross rate table

[0041]

[0042] In summary, the application embodiment divides the application into three micro-service modules, i.e., system management service, process management service and pre-examination business service, by using the micro-service splitting scheme, and designs and develops the patent pre-examination system based on the division, and in the implementation and online use of the pre-examination system in multiple protection centers, the purpose of the micro-service technical architecture, i.e., easy development and maintenance, is achieved, which lays a solid foundation for the stable operation of the system.

[0043] The application embodiment also provides a software system micro-service splitting device, as described in the following embodiment. Since the principle of solving the problem of the device is similar to the software system micro-service splitting method, the implementation of the device can be referred to the implementation of the software system micro-service splitting method, and the repeated parts will not be described again.

[0044] Figure 7 The structure of the software system micro-service splitting device in the application embodiment is shown in FIG. 1, which includes the following units. Figure 7

[0045] The splitting unit 01 is configured to split the software system into multiple business modules and split each business module into multiple function modules.

[0046] The workload determining unit 02 is configured to determine the workload of the function module existing in the intersection of each two business modules according to the workload of each user operating each function module per day.

[0047] The intersection rate determining unit 03 is configured to determine the intersection rate between the two business modules according to the workload of the function module existing in the intersection of each two business modules and the total workload of the function module corresponding to the two business modules.

[0048] The splitting determining unit 04 is configured to determine whether to split the two business modules into two micro-services according to the intersection rate between the two business modules and the preset intersection rate threshold.

[0049] In one embodiment, the software system micro-service splitting device can further include a calling unit configured to use the Feign calling interface method to interact between the two micro-services for the function module existing in the intersection of the two micro-services.

[0050] In one embodiment, the splitting determining unit can be specifically configured to determine to split the two business modules into two micro-services when the intersection rate between the two business modules is lower than the preset intersection rate threshold.

[0051] In one embodiment, the splitting determining unit can be specifically configured to determine not to split the two business modules into two micro-services when the intersection rate between the two business modules exceeds the preset intersection rate threshold. ​

[0052] In one embodiment, the software system can be a patent pre-examination business system.

[0053] The embodiment of the present application further provides a computer device, which comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the processor implements the above-mentioned method for decomposing micro services of a software system when executing the computer program.

[0054] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program, and the computer program implements the above-mentioned method for decomposing micro services of a software system when executed by a processor.

[0055] The embodiment of the present application further provides a computer program product, which comprises a computer program, and the computer program implements the above-mentioned method for decomposing micro services of a software system when executed by a processor.

[0056] In the embodiment of the present application, the decomposing scheme of the micro services of the software system is as follows: the software system is split into a plurality of business modules, each business module is split into a plurality of function modules; the workload of the function modules existing in the intersection of each two business modules is determined according to the workload of each user on each function module per day; the intersection rate between the two business modules is determined according to the workload of the function modules existing in the intersection of the two business modules and the total workload of the function modules corresponding to the two business modules; and whether to split the two business modules into two micro services is determined according to the intersection rate between the two business modules and a preset intersection rate threshold, so that the micro services can be reasonably decomposed.

[0057] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system or a computer program product. Therefore, the present application can be in the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. Moreover, the present application can be in the form of a computer program product implemented on one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program code.

[0058] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks

[0059] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks

[0060] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flow or blocks Figure 1 one or more flow or blocks

[0061] The above-described specific embodiments are merely intended to further describe and explain the purpose, technical solutions and beneficial effects of the present application, and it should be understood that the above-described specific embodiments are merely specific embodiments of the present application and are not used to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method for decomposing microservices in a software system, characterized in that, include: The software system is divided into multiple business modules, and each business module is further divided into multiple functional modules according to the system's business requirements, forming a functional structure diagram from system modules to business modules and from business modules to functional modules. Based on the workload of each user's daily operation of each functional module, the functional structure diagram and the corresponding logical analysis are used to form a functional cross diagram of system modules, business modules and functional modules. The workload is evaluated based on the functional cross diagram to determine the workload of functional modules that overlap between two business modules. Mark every two overlapping business modules. Based on the workload assessment table, and according to the workload of the functional modules that overlap between the two business modules, as well as the total workload of the corresponding functional modules of the two business modules, obtain the crossover rate table. Determine the crossover rate between the two business modules based on the crossover rate table. When the crossover rate between the two business modules is lower than the preset crossover rate threshold, it proves that the decomposition is feasible. Therefore, the two business modules are split into two microservices to achieve reasonable microservice decomposition. The lower the crossover rate, the more feasible it is to decompose microservices; For functional modules that are split into two microservices and have overlap, Feign is used to call the interface to facilitate interaction and data flow between the two microservices.

2. The method as described in claim 1, characterized in that, Also includes: If the crossover rate between the two business modules exceeds the preset crossover rate threshold, it will be determined not to split the two business modules into two microservices.

3. The method as described in claim 1, characterized in that, The software system is a patent pre-examination business system.

4. A device for disassembling microservices in a software system, characterized in that, include: The splitting unit is used to split the software system into multiple business modules. Each business module is further divided into multiple functional modules according to the system's business requirements, forming a functional structure diagram from system modules to business modules and from business modules to functional modules. The workload determination unit is used to form a functional cross diagram of system modules, business modules and functional modules based on the workload of each user's daily operation of each functional module, the functional structure diagram and the corresponding logical analysis, and to evaluate the workload based on the functional cross diagram to determine the workload of functional modules that have overlap between two business modules. The crossover rate determination unit is used to mark every two business modules that have crossovers. Based on the workload evaluation table, the crossover rate table is obtained according to the workload of the functional modules that have crossovers between the two business modules and the total workload of the corresponding functional modules of the two business modules. The crossover rate between the two business modules is determined according to the crossover rate table. The decomposition determination unit is used to prove that decomposition is feasible when the cross rate between the two business modules is lower than the preset cross rate threshold, and to determine that the two business modules are split into two microservices in order to achieve reasonable microservice decomposition. The lower the crossover rate, the more feasible it is to decompose microservices; The calling unit is used to facilitate interaction and data flow between two microservices that have overlapping functional modules, using the Feign API call method.

5. The apparatus as described in claim 4, characterized in that, The decomposition determination unit is further configured to: determine not to split the two business modules into two microservices when the cross rate between the two business modules exceeds a preset cross rate threshold.

6. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 3.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 3.

8. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 3.

Images