Architecture switching method and device, equipment and medium
By adopting the microservice architecture in the software development stage and following the monolithic architecture specifications, merging code and calculating dependencies, the problem of difficulty in maintaining the monolithic architecture and high resource consumption of microservice architecture is solved, and flexible architecture conversion is achieved, reducing maintenance costs and risks.
Patent Information
- Application Number
- CN202510538147.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-27
- Publication Date
- 2025-07-18
AI Technical Summary
In the prior art, software applications cannot be adjusted according to actual conditions after the deployment architecture is determined, which makes it difficult to maintain and expand in a single architecture, while microservice architectures have problems such as large resource consumption and high operation and maintenance complexity.
Use microservice architecture to write code, and follow the monolithic architecture specifications to ensure that the module name is not duplicated. When it is determined to switch to a monolithic architecture, merge the code and calculate the module dependencies to generate a comprehensive dependency structure.
It realizes the flexibility and efficiency of leveraging the microservice architecture in the development stage, switch to the monolithic architecture according to actual needs during the deployment stage, reduces the cost and risks of reconstruction, and finds a balance between rapid development, easy maintenance and scalability.
Smart Images

Figure CN120335781A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular, to an architecture switching method, device, equipment and medium. Background Art
[0002] When developing current software applications, the deployment architecture is usually directly determined. For example, a monolithic architecture is used, or a microservices architecture is used. The monolithic architecture is easy to manage in the initial stage of the project, but it becomes difficult to maintain and expand as the application grows. On the contrary, the microservices architecture provides better flexibility and scalability, but there are too many microservices after deployment, resulting in excessive resource consumption. And once the deployment architecture of the application is determined, it cannot be changed anymore, resulting in the inability to adjust according to the actual situation later. Summary of the Invention
[0003] The purpose of the present invention is to provide an architecture switching method, device, equipment and medium, which can flexibly switch the microservices architecture to a monolithic application architecture as needed, and find a balance among rapid development, easy maintenance and scalability.
[0004] To solve the above technical problems, the present invention provides an architecture switching method, including:
[0005] In the application development stage, write the code in the way of a microservices architecture;
[0006] During the process of writing the code, follow the specifications of the monolithic architecture to ensure that the relevant names corresponding to each independently developed module are not repeated;
[0007] When it is determined that the application deployment architecture is to be switched to a monolithic architecture, merge the codes of each module;
[0008] Calculate the dependency relationships between each module to generate a comprehensive dependency relationship structure, so as to switch the microservices architecture to a monolithic architecture.
[0009] In a first aspect, in the above architecture switching method provided by the present invention, writing the code in the way of a microservices architecture includes:
[0010] According to the hierarchical division of the interface layer, service layer, communication layer and data layer, write the code in the way of a microservices architecture; wherein, each independently developed module includes the service layer, the communication layer and the data layer;
[0011] The interface layer is the entry of the application program, and is used to receive external requests and return response results;
[0012] The service layer is used to undertake the requests of the interface layer and perform business logic processing; the service layer of each module has its own directory structure;
[0013] The communication layer is used for data transmission and communication coordination within and between modules;
[0014] The data layer is used for data storage and reading, providing data support for the communication layer.
[0015] On the other hand, in the above architecture switching method provided by the present invention, following the specifications of the monolithic architecture, the relevant names of each module are made non - repetitive, including:
[0016] Independently develop the service layer of each module using the same development language; each service layer uses the same secondary directory structure;
[0017] The first - level directory names of each secondary directory structure are the same, and the second - level directory names are different.
[0018] On the other hand, in the above architecture switching method provided by the present invention, calculate the dependency relationships between modules to generate a comprehensive dependency relationship structure, including:
[0019] Collect the dependency relationships between modules;
[0020] Use a topological sorting algorithm to calculate the dependency relationships between modules to generate a comprehensive dependency relationship structure.
[0021] On the other hand, in the above architecture switching method provided by the present invention, use a topological sorting algorithm to calculate the dependency relationships between modules, including:
[0022] Use a topological sorting algorithm to calculate the dependency relationships between modules by processing a directed acyclic graph to generate a comprehensive dependency relationship structure;
[0023] Among them, each vertex of each topology in the directed acyclic graph represents a module, and the direction of each edge represents the dependency relationship between modules.
[0024] On the other hand, in the above architecture switching method provided by the present invention, while using a topological sorting algorithm to calculate the dependency relationships between modules by processing a directed acyclic graph, it also includes:
[0025] Calculate the dependency relationships between modules according to a dependency management program; different development languages use different said dependency management programs; the dependency management program is written in different modules.
[0026] On the other hand, in the above architecture switching method provided by the present invention, when it is determined that the application deployment architecture is to be switched to a monolithic architecture, merge the codes of each module, including:
[0027] Read the configuration to determine whether the application deployment architecture needs to be switched;
[0028] If not, determine that the application deployment architecture is a microservices architecture and directly deploy the current architecture;
[0029] If so, determine that the application deployment architecture is to be switched to a monolithic architecture and merge the service layer application codes of each module.
[0030] To solve the above technical problems, the present invention also provides an architecture switching device, including:
[0031] A first development module for writing codes in the manner of a microservices architecture during the application development stage;
[0032] A second development module for following the specifications of a monolithic architecture during the process of writing codes to ensure that the relevant names corresponding to each independently developed module are not repeated;
[0033] A code merging module for merging the codes of each module when it is determined that the application deployment architecture is to be switched to a monolithic architecture;
[0034] A dependency relationship calculation module for calculating the dependency relationships between each module and generating a comprehensive dependency relationship structure to switch the microservices architecture to a monolithic architecture.
[0035] To solve the above technical problems, the present invention also provides an electronic device, including:
[0036] A memory for storing a computer program;
[0037] A processor for implementing the steps of the above architecture switching method when executing the computer program.
[0038] To solve the above technical problems, the present invention also provides a computer-readable storage medium, on which a computer program is stored, and the computer program implements the steps of the above architecture switching method when executed by a processor.
[0039] As can be seen from the above technical solutions, an architecture switching method provided by the present invention includes: during the application development stage, writing codes in the manner of a microservices architecture; during the process of writing codes, following the specifications of a monolithic architecture to ensure that the relevant names corresponding to each independently developed module are not repeated; when it is determined that the application deployment architecture is to be switched to a monolithic architecture, merging the codes of each module; calculating the dependency relationships between each module and generating a comprehensive dependency relationship structure to switch the microservices architecture to a monolithic architecture.
[0040] The beneficial effects of the present invention are as follows. The above-mentioned architecture switching method provided by the present invention can start from two aspects of early development and code packaging. First, in the application development stage, the micro-service architecture is adopted to write code; during the process of writing code, the specifications of the monolithic architecture are followed to ensure that the relevant names corresponding to each independently developed module do not repeat, maintaining the independence of the modules, making the code of each module relatively independent, and improving the maintainability and scalability of the code; then when it is determined that the application deployment architecture is to be switched to the monolithic architecture, the codes of each module are merged, and the dependency relationships between the modules are calculated to generate a comprehensive dependency relationship structure. In this way, the micro-service architecture can be flexibly switched to the monolithic application architecture as needed, and the switching process is smooth and controllable, reducing the cost and risk of refactoring. This takes into account the advantages of both the micro-service architecture and the monolithic architecture, utilizes the flexibility and efficiency of the micro-service architecture in the development stage, and can be flexibly switched to the monolithic architecture according to actual needs in the deployment stage, being able to find a balance among rapid development, easy maintenance, and scalability. By implementing this flexible architecture conversion, it can more effectively respond to market changes, accelerate product iteration, and at the same time reduce the maintenance cost.
[0041] In addition, the present invention also provides a corresponding architecture switching device, electronic device, and computer-readable storage medium for the architecture switching method, which have the same or corresponding technical features as the above-mentioned architecture switching method, and the effects are the same. BRIEF DESCRIPTION OF THE DRAWINGS
[0042] In order to more clearly illustrate the embodiments of the present invention, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.
[0043] Figure 1 It is a flowchart of the architecture switching method provided for the embodiments of the present invention;
[0044] Figure 2 It is a schematic diagram of the overall code architecture division in the architecture switching method provided for the embodiments of the present invention;
[0045] Figure 3 It is a schematic diagram of code merging in the architecture switching method provided for the embodiments of the present invention;
[0046] Figure 4 It is a schematic diagram of application architecture deployment in the architecture switching method provided for the embodiments of the present invention;
[0047] Figure 5 It is a schematic diagram corresponding to the directed acyclic graph provided for the embodiments of the present invention;
[0048] Figure 6 Schematic diagram of generating a comprehensive dependency relationship structure provided by an embodiment of the present invention;
[0049] Figure 7 Schematic diagram of the structure of an architecture switching device provided by an embodiment of the present invention;
[0050] Figure 8 Schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Detailed implementation manners
[0051] When developing current software applications, the deployment architecture is usually determined. When developing applications using a monolithic architecture, there is a relatively fast development speed in the early stage of development. However, when the functions of the software increase and become complex in the later stage, and different customers have different requirements, it is very difficult to expand the software because all the code is written in the same application. Therefore, a small modification may cause problems that affect the entire application. When developing applications using a microservices architecture, the development is relatively slow in the early stage, and the deployment is also very complex. However, in products with long-term maintenance, applications with a microservices architecture can develop new functional modules quickly and independently, and complete the update with little impact on the original application. Relatively speaking, the later maintenance work will become very complex. The resources occupied by multiple independent microservices after running are much larger than those of a monolithic application, and a large amount of server resources need to be consumed. Moreover, the implementation methods of each independent microservice are relatively independent, and it is impossible for operation and maintenance personnel to develop and maintain them in a unified manner.
[0052] Therefore, traditional monolithic applications and microservices architectures have their own advantages and disadvantages. The monolithic architecture is easier to manage in the initial stage of the project, but it becomes difficult to maintain and expand as the application grows. On the contrary, the microservices architecture provides better flexibility and scalability, but brings higher development, deployment, and operation and maintenance complexity. Once the deployment architecture of the application is determined, it cannot be changed, resulting in the inability to adjust according to the actual situation in the later stage. To solve this technical problem, the present invention provides an architecture switching method, which can flexibly switch the microservices architecture to a monolithic application architecture as needed, and find a balance among rapid development, easy maintenance, and scalability.
[0053] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.
[0054] To enable those skilled in the art to better understand the solution of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Figure 1 It is a flowchart of the architecture switching method provided by an embodiment of the present invention. As Figure 1 shown, the method includes the following steps:
[0055] S101. In the application development stage, write the code in the form of a microservice architecture.
[0056] It should be noted that the microservice architecture (or microservices) is a cloud-native architecture method that includes multiple loosely coupled and independently deployable small services in a single application. In the application development stage of the present invention, the microservice architecture is adopted, and each microservice module can be developed in parallel. The microservice architecture itself has the characteristics of high cohesion and low coupling, and each microservice module has clear responsibilities and boundaries. The microservice architecture allows different modules to select the most suitable technology stack according to their specific business needs.
[0057] S102. During the process of writing the code, follow the specifications of the monolithic architecture to ensure that the relevant names corresponding to each independently developed module are not repeated.
[0058] It should be noted that the monolithic architecture is an architecture method that integrates all functions into a single independent application. In the process of writing the code in the present invention, following the specifications of the monolithic architecture to ensure that the relevant names of each independently developed module are not repeated helps to maintain the consistency and standardization of the code. Moreover, while following the specifications of the monolithic architecture, maintaining the independence of the microservice modules makes the code of each module relatively independent and has a single function. When a certain function needs to be modified or extended, only the corresponding module needs to be concerned, without affecting other irrelevant modules, which improves the maintainability and scalability of the code.
[0059] S103. When it is determined that the application deployment architecture is to be switched to the monolithic architecture, merge the code of each module.
[0060] In practical applications, it may be necessary to make a choice between the monolithic and microservice architectures according to specific situations (such as resource limitations, time pressure, and technology stack compatibility). For example: when there are many functions and sufficient server resources, it is necessary to deploy in the form of a microservice architecture; when there are few functions and the budget and server resources are insufficient, in terms of implementation cost, it is best to deploy in the form of a monolithic architecture.
[0061] After determining the application deployment architecture according to specific situations, the present invention can flexibly switch between the microservice architecture and the monolithic architecture; for example, when it is determined that the application deployment architecture is to be switched to the monolithic architecture, the code of each module can be merged first, and then step S104 is executed.
[0062] S104. Calculate the dependency relationships between modules to generate a comprehensive dependency relationship structure, so as to switch the microservice architecture to a monolithic architecture.
[0063] In implementation, after merging the codes of each module, calculate the dependency relationships between modules to generate a comprehensive dependency relationship structure. This method makes the switching process from the microservice architecture to the monolithic architecture smoother and more controllable. By calculating the dependency relationships in advance, it is possible to better handle the interactions and dependencies between modules when merging the codes, avoid system failures or errors caused by dependency problems, and ensure that the system can operate normally after switching the architecture.
[0064] In the above architecture switching method provided by the embodiments of the present invention, it is possible to start from two perspectives of early development and code packaging. First, in the application development stage, the microservice architecture is adopted to write the code; during the process of writing the code, follow the specifications of the monolithic architecture to ensure that the relevant names corresponding to the independently developed modules do not repeat, maintain the independence of the modules, make the code of each module relatively independent, and improve the maintainability and scalability of the code; then when it is determined that the application deployment architecture needs to be switched to the monolithic architecture, merge the codes of each module, calculate the dependency relationships between modules, and generate a comprehensive dependency relationship structure. This method can flexibly switch the microservice architecture to the monolithic application architecture as needed, and the switching process is smooth and controllable, reducing the cost and risk of refactoring. In this way, the advantages of both the microservice architecture and the monolithic architecture are taken into account. The flexibility and efficiency of the microservice architecture are utilized in the development stage, and in the deployment stage, it can be flexibly switched to the monolithic architecture according to actual needs. It is possible to find a balance among rapid development, easy maintenance, and scalability. By implementing this flexible architecture conversion, it is possible to more effectively respond to market changes, accelerate product iteration, and at the same time reduce the maintenance cost.
[0065] It should be noted that when it is determined that the application deployment architecture does not need to be switched, directly package and deploy the microservice architecture by code. And after switching to the monolithic architecture, if it is necessary to switch the monolithic architecture to the microservice architecture, then split the codes of each module to switch the monolithic architecture to the microservice architecture.
[0066] Further, in specific implementation, in the above architecture switching method provided by the embodiments of the present invention, step S101 is to write code in the form of a microservice architecture, which may specifically include: writing code in the form of a microservice architecture according to the hierarchical division of the interface layer, service layer, communication layer, and data layer; among them, each independently developed module includes a service layer, a communication layer, and a data layer; the interface layer is the entry of the application program, used to receive external requests and return response results; the service layer is used to receive the requests of the interface layer and perform business logic processing; the service layer of each module has its own directory structure; the communication layer is used to perform data transmission and communication coordination within and between modules; the data layer is used for data storage and reading, providing data support for the communication layer.
[0067] Figure 2 This is a schematic diagram of the overall code architecture division in the architecture switching method provided by the embodiments of the present invention. In implementation, as Figure 2 shown, during the application program development process of the present invention, the overall framework can be divided into four layers: the interface layer, the service layer, the communication layer, and the data layer. Among them, the interface layer: covers the user interface and the external API part, is the entry of the application program, and all input and output data are transmitted through this layer. Whether in a monolithic architecture application or a microservice architecture application, this layer remains unchanged. The service layer: is used to receive the requests of the interface layer and perform business logic processing. The communication layer: is the communication implementation code for calling other modules in the service layer, developed independently in each module, but using the same development language. The data layer: is the part where the application program accesses the database. Each module can be developed independently, but uses the same language.
[0068] Further, in specific implementation, in the above architecture switching method provided by the embodiments of the present invention, step S102 follows the specifications of the monolithic architecture to ensure that the relevant names of each module are not repeated, which may specifically include: independently developing the service layer of each module using the same development language; each service layer uses the same secondary directory architecture; the first-level directory names of each secondary directory architecture are the same, and the second-level directory names are different.
[0069] In implementation, as Figure 2 shown, when developing the service layer, the same secondary directory architecture can be used, with no more than two levels of directories. The first-level directory names must be the same, for example, all use "service", and the second-level directory names must be different. For example, in module A, the secondary directory "dirA" (such as secondary directories "a1", "a2", "a3") is used. Then in module B, the name "dirA" cannot be used, but the secondary directory "dirB" (such as secondary directories "b1", "b2", "b3") is used. Develop business logic independently in different modules, but the overall structure must be the same and use the same development language.
[0070] It should be noted that during the application development process, it is written in accordance with the microservices architecture to achieve the deployment of the microservices architecture. However, when actually writing the code, it needs to be developed according to the monolithic architecture specifications. For example, the directory names, file names, variable names, etc. should not be repeated, which is required for merging the code when switching to the monolithic architecture deployment.
[0071] Furthermore, in specific implementation, in the above architecture switching method provided by the embodiments of the present invention, in step S103, when it is determined that the application deployment architecture is to be switched to the monolithic architecture, the codes of each module are merged. Specifically, it may include: reading the configuration to determine whether the application deployment architecture needs to be switched; if not, it is determined that the application deployment architecture is the microservices architecture and the current architecture is directly deployed; if so, it is determined that the application deployment architecture is to be switched to the monolithic architecture, and the service layer application codes of each module are merged.
[0072] Figure 3 This is a schematic diagram of code merging in the architecture switching method provided by the embodiments of the present invention. In implementation, as Figure 3 shown, the left part presents the code writing method of the microservices architecture, with three independent service layers corresponding to the first-level directories A, B, and C respectively. Each first-level directory has its own second-level directories. For example, under the first-level directory A, there are second-level directories a1, a2, and a3; under the first-level directory B, there are second-level directories b1, b2, and b3; under the first-level directory C, there are second-level directories c1, c2, and c3. Each service layer is independent of each other, reflecting the characteristics of independent development and deployment of different service modules in the microservices architecture. The right part shows the monolithic architecture formed after merging through a Directed Acyclic Graph (DAG). At this time, the originally independent three service layers are integrated together, and the first-level directories A, B, and C and their corresponding second-level directories are all concentrated in one architecture, becoming an overall monolithic application structure.
[0073] Furthermore, in specific implementation, in the above architecture switching method provided by the embodiments of the present invention, in step S104, the dependency relationships between each module are calculated to generate a comprehensive dependency relationship structure. Specifically, it may include: collecting the dependency relationships between each module; using the topological sorting algorithm to calculate the dependency relationships between each module to generate a comprehensive dependency relationship structure.
[0074] In implementation, according to the design specifications of the present invention, when converting the microservices architecture into a monolithic architecture application, since completely different naming methods are adopted, there will be no conflicting files generated after merging. However, this is only a merger at the architectural level. The complexity of the microservices architecture application lies in the mutual dependency relationships between modules. For example, module A references module B, and module B references module C. Therefore, the present invention can use the topological sorting algorithm to solve the dependency problem.
[0075] Figure 4 This is a schematic diagram of the application architecture deployment in the architecture switching method provided by the embodiments of the present invention. As Figure 4 shown, in the present invention, through code merging and module dependency relationship sorting, an application program with a microservice architecture can be transformed into a monolithic application architecture. During deployment, it can be decided whether to perform the transformation according to needs. If resources are sufficient and the later maintenance ability is perfect, the application can be directly packaged and deployed in a microservice architecture; if resources are limited and the project changes are within a controllable range, then the merging is started through a configuration file, the topological sorting algorithm is used to calculate the dependency relationships between modules, a comprehensive dependency relationship structure is generated, and finally the project is deployed in a monolithic architecture manner.
[0076] Further, in specific implementation, in the above steps, when using the topological sorting algorithm to calculate the dependency relationships between modules, it may specifically include: using the topological sorting algorithm to calculate the dependency relationships between modules by processing a directed acyclic graph to generate a comprehensive dependency relationship structure; wherein, each vertex of each topology in the directed acyclic graph represents a module, and the direction of each edge represents the dependency relationship between modules.
[0077] In implementation, the topological sorting algorithm is an algorithm in computer science, used to sort nodes in a directed graph. After sorting, for the directed edge U->V of any problem, that is, from vertex U pointing to vertex V, and U must be before V. Therefore, in module merging, each vertex of each topology is equivalent to a module of the microservice architecture, and the direction of each edge represents the dependency relationship between modules. Figure 5 This is a schematic diagram corresponding to the directed acyclic graph provided by the embodiments of the present invention. As Figure 5 shown, module A depends on module B and module D, module B depends on module C and module E, and module D depends on module E. The final result is a directed acyclic graph.
[0078] Further, in specific implementation, in the above architecture switching method provided by the embodiments of the present invention, when using the topological sorting algorithm to calculate the dependency relationships between modules by processing a directed acyclic graph, it may further include: calculating the dependency relationships between modules according to a dependency management program; different development languages use different dependency management programs; the dependency management program is written in different modules.
[0079] In implementation, to calculate the dependency relationships between modules through a topological sorting algorithm, analysis can be performed based on the existing dependency management programs. Different programming languages use different dependency management programs. For example, JAVA uses MAVEN as the dependency management software, and PHP uses COMPOSER as the dependency management software. Since the dependency management software is written in different modules, the present invention needs to collect the dependency relationships of each module and analyze them using the topological sorting algorithm to obtain the final dependency relationship structure, and dynamically generate code in the merged monolithic application according to the algorithm results.
[0080] Figure 6 This is a schematic diagram of generating an integrated dependency relationship structure provided by an embodiment of the present invention. As Figure 6 shown, the microservice architecture part includes three independent modules, namely Module A, Module B, and Module C. Each module contains its own code, namely Code A, Code B, and Code C. Each module also has independent dependencies, namely Dependency A, Dependency B, and Dependency C. This reflects the relative independence of each module in the microservice architecture, with its own code and dependency management. The present invention processes the independent dependency relationships of each module through a topological sorting algorithm and organizes them into an integrated dependency relationship. The topological sorting algorithm is often used to process the order of nodes in a directed acyclic graph and can be used here to sort out the order and association between module dependencies to ensure the correct dependency relationship during integration. After integration, a monolithic application architecture is formed, and the code of the three modules (Code A, Code B, and Code C) is concentrated together, and the dependency relationships are also integrated into an overall dependency. At this time, each module is no longer independent but becomes an interrelated part of the monolithic application.
[0081] In summary, when developing the present invention, the microservice architecture application method is used for development. However, during the development process, it is necessary to develop in the monolithic architecture application, including that the directory names and file names cannot be repeated, etc. After development, during actual deployment, the configuration is modified according to needs to determine the application deployment method. If the microservice architecture is adopted, the application itself does not need to be modified and can be directly deployed; if the monolithic application architecture is used for development, the code of each module is merged, and the topological sorting algorithm is used to generate an overall dependency relationship for module dependencies and take effect in the application program, that is, it can be deployed using the monolithic architecture. This solves the problem that the same application software can be deployed according to the actual situation under different requirements. The present invention is compatible with both the microservice architecture and the monolithic architecture applications, can effectively utilize resources, avoid waste of resources, and can select a suitable deployment architecture according to the scale of the later operation and maintenance team.
[0082] In the above embodiments, the architecture switching method has been described in detail. The present invention also provides corresponding embodiments of an architecture switching device and an electronic device. It should be noted that the embodiments of the device part of the present invention are described from two perspectives, one is from the perspective of functional modules, and the other is from the perspective of hardware.
[0083] Figure 7 FIG. is a schematic structural diagram of the architecture switching device provided by an embodiment of the present invention. In this embodiment, from the perspective of functional modules, as Figure 7 shown, the device includes:
[0084] A first development module 10, configured to write code in the manner of a microservices architecture during the application development stage;
[0085] A second development module 11, configured to follow the specifications of a monolithic architecture during the process of writing code, so that the relevant names corresponding to each independently developed module are not repeated;
[0086] A code merging module 12, configured to merge the code of each module when it is determined that the application deployment architecture is to be switched to a monolithic architecture;
[0087] A dependency relationship calculation module 13, configured to calculate the dependency relationships between modules and generate a comprehensive dependency relationship structure, so as to switch the microservices architecture to a monolithic architecture.
[0088] In the above architecture switching device provided by an embodiment of the present invention, through the interaction of the above four modules, it is possible to start from two perspectives of early development and code packaging, maintain the independence of modules, make the code of each module relatively independent, improve the maintainability and scalability of the code; and flexibly switch the microservices architecture to a monolithic application architecture as needed, and the switching process is smooth and controllable, reducing the cost and risk of refactoring. In this way, the advantages of both the microservices architecture and the monolithic architecture are taken into account. The flexibility and efficiency of the microservices architecture are utilized in the development stage, and it can be flexibly switched to the monolithic architecture according to actual needs in the deployment stage. It is possible to find a balance among rapid development, easy maintenance, and scalability. By implementing this flexible architecture conversion, it is possible to more effectively respond to market changes, accelerate product iteration, and at the same time reduce maintenance costs.
[0089] Since the embodiments of the device part correspond to the embodiments of the method part, for the embodiments of the device part, please refer to the description of the embodiments of the method part, which will not be elaborated here. And it has the same beneficial effects as the above-mentioned architecture switching method.
[0090] Further, in specific implementation, in the above architecture switching device provided by the embodiments of the present invention, the first development module 10 can specifically be used to write code in the way of a microservices architecture according to the hierarchical division of the interface layer, service layer, communication layer, and data layer; among them, each independently developed module includes a service layer, a communication layer, and a data layer; the interface layer is the entry of the application program, used to receive external requests and return response results; the service layer is used to undertake the requests of the interface layer and perform business logic processing; the service layer of each module has its own directory structure; the communication layer is used to perform data transmission and communication coordination within and between modules; the data layer is used for data storage and reading, providing data support for the communication layer.
[0091] Further, in specific implementation, in the above architecture switching device provided by the embodiments of the present invention, the second development module 11 can specifically be used to independently develop the service layers of each module using the same development language; each service layer uses the same secondary directory architecture; the first-level directories of each secondary directory architecture have the same name, and the second-level directories have different names.
[0092] Further, in specific implementation, in the above architecture switching device provided by the embodiments of the present invention, the code merging module 12 can specifically be used to read the configuration and determine whether the application deployment architecture needs to be switched; if not, it is determined that the application deployment architecture is a microservices architecture, and the current architecture is directly deployed; if so, it is determined that the application deployment architecture is to be switched to a monolithic architecture, and the service layer application codes of each module are merged.
[0093] Further, in specific implementation, in the above architecture switching device provided by the embodiments of the present invention, the dependency calculation module 13 can specifically be used to collect the dependency relationships between each module; use the topological sorting algorithm to calculate the dependency relationships between each module and generate a comprehensive dependency relationship structure.
[0094] Specifically, the topological sorting algorithm can be used to calculate the dependency relationships between each module by processing a directed acyclic graph and generate a comprehensive dependency relationship structure; among them, each vertex of each topology in the directed acyclic graph represents a module, and the direction of each edge represents the dependency relationship between each module.
[0095] Figure 8 It is a schematic structural diagram of an electronic device provided by an embodiment of the present invention. Based on the hardware perspective, as Figure 8 shown, the electronic device includes:
[0096] A memory 20, used to store a computer program;
[0097] A processor 21, used to implement the steps of the architecture switching method as mentioned in the above embodiments when executing the computer program.
[0098] Among them, the processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 21 may be implemented in at least one hardware form of a Digital Signal Processor (DSP), a Field-Programmable Gate Array (FPGA), or a Programmable Logic Array (PLA). The processor 21 may also include a main processor and a coprocessor. The main processor is a processor used to process data in the wake state, also known as the CPU; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may be integrated with a Graphics Processing Unit (GPU), and the GPU is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 21 may also include an Artificial Intelligence (AI) processor, and the AI processor is used to process computational operations related to machine learning.
[0099] The memory 20 may include one or more computer-readable storage media, and the computer-readable storage media may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices and flash storage devices. In this embodiment, the memory 20 is at least used to store the following computer program 201. After the computer program is loaded and executed by the processor 21, it can implement the relevant steps of the architecture switching method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, the data involved in the architecture switching method mentioned above.
[0100] In some embodiments, the electronic device may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26. Those skilled in the art can understand that Figure 8 the structure shown does not constitute a limitation on the electronic device, and it may include more or fewer components than those shown in the figure. The electronic device provided by the embodiments of the present invention includes a memory and a processor. When the processor executes the program stored in the memory, it can implement the architecture switching method as mentioned above, and the effect is the same.
[0101] Finally, the present invention also provides an embodiment corresponding to a computer-readable storage medium. A computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps recorded in the above method embodiments are implemented.
[0102] It can be understood that if the method in the above embodiments is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and executes all or part of the steps of the methods described in the various embodiments of the present invention. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs that can store program codes. The computer-readable storage medium provided by the present invention can implement the above-mentioned architecture switching method, and the effect is the same.
[0103] Finally, the present invention also provides an embodiment corresponding to a computer program product. The computer program product includes computer programs / instructions, and when the computer programs / instructions are executed by a processor, the steps recorded in the above architecture switching method embodiments are implemented. The computer program product provided by the present invention can implement the above-mentioned architecture switching method, and the effect is the same.
[0104] It should also be noted that in this specification, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover a non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or further includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, article or device comprising the element.
[0105] The above has introduced in detail the architecture switching method, device, equipment and medium provided by the present invention. The various embodiments in the specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. For the same or similar parts among the various embodiments, reference can be made to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple. For the relevant parts, reference can be made to the description in the method part. It should be noted that for those of ordinary skill in the art in the technical field of the present invention, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the present invention.
Claims
1. An architecture switching method, characterized in that, Including: During the application development stage, write the code in the way of microservice architecture. During the process of writing the code, follow the specifications of the monolithic architecture to ensure that the relevant names corresponding to each independently developed module are not repeated. When it is determined that the application deployment architecture is to be switched to the monolithic architecture, merge the code of each module. Calculate the dependency relationships between each module to generate a comprehensive dependency relationship structure, so as to switch the microservice architecture to the monolithic architecture.
2. The architecture switching method according to claim 1, wherein Writing the code in the way of microservice architecture includes: According to the layer division of the interface layer, service layer, communication layer and data layer, write the code in the way of microservice architecture; among them, each independently developed module includes the service layer, the communication layer and the data layer. The interface layer is the entry of the application, used to receive external requests and return response results. The service layer is used to undertake the requests of the interface layer and perform business logic processing; the service layer of each module has its own directory structure. The communication layer is used for data transmission and communication coordination within and between modules. The data layer is used for data storage and reading, providing data support for the communication layer.
3. The architecture switching method according to claim 2, wherein Following the specifications of the monolithic architecture to ensure that the relevant names of each module are not repeated includes: Independently develop the service layer of each module using the same development language; each service layer uses the same secondary directory architecture. The first-level directory names of each secondary directory architecture are the same, and the second-level directory names are different.
4. The architecture switching method according to claim 1, wherein Calculating the dependency relationships between each module to generate a comprehensive dependency relationship structure includes: Collect the dependency relationships between each module. Use the topological sorting algorithm to calculate the dependency relationships between each module to generate a comprehensive dependency relationship structure.
5. The architecture switching method according to claim 4, wherein Using the topological sorting algorithm to calculate the dependency relationships between each module includes: Use the topological sorting algorithm to calculate the dependency relationships between each module by processing the directed acyclic graph to generate a comprehensive dependency relationship structure. Among them, each vertex of each topology in the directed acyclic graph represents a module, and the direction of each edge represents the dependency relationship between each module.
6. The architecture switching method according to claim 5, wherein When using the topological sorting algorithm to calculate the dependency relationships between each module by processing the directed acyclic graph, it also includes: Calculate the dependency relationships between each module according to the dependency management program; different development languages use different dependency management programs; the dependency management program is written in different modules.
7. The architecture switching method according to claim 1, characterized in that When it is determined that the application deployment architecture is to be switched to the monolithic architecture, merging the code of each module includes: Read the configuration and determine whether the application deployment architecture needs to be switched. If not, determine that the application deployment architecture is the microservice architecture and directly deploy the current architecture. If so, determine that the application deployment architecture is to be switched to the monolithic architecture and merge the service layer application code of each module.
8. An architecture switching device, characterized in that, Including: The first development module is used to write the code in the way of microservice architecture during the application development stage. The second development module is used to follow the specifications of the monolithic architecture during the process of writing the code to ensure that the relevant names corresponding to each independently developed module are not repeated. A code merging module, configured to merge the codes of each module when it is determined that the application deployment architecture is to be switched to a monolithic architecture; A dependency relationship calculation module, configured to calculate the dependency relationships between each module and generate a comprehensive dependency relationship structure, so as to switch the microservice architecture to a monolithic architecture.
9. An electronic device, characterized in that, Including: A memory, configured to store a computer program; A processor, configured to implement the steps of the architecture switching method according to any one of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the architecture switching method according to any one of claims 1 to 7 are implemented.