Switching method and system for integrated monomer architecture and micro-service architecture

Abstract

The invention discloses a switching method and system for an integrated monomer architecture and a micro-service architecture, and the method comprises the steps: constructing an integrated service architecture in combination with a user-defined application programming interface, a control layer, a first business logic layer and a second business logic layer; dynamically identifying the integrated service architecture through a service discovery mechanism, and generating an interface calling activation instruction; and based on the interface calling activation instruction, controlling the integrated service architecture to switch between the single architecture and the micro-service architecture according to the service calling logic link. According to the embodiment of the invention, the reusability of underlying logic codes can be improved, and the complexity of development and maintenance of an integrated service architecture is reduced. The method can be widely applied to the technical field of software application architecture.

Description

Technical Field

[0001] The present application relates to the technical field of software application architecture, and in particular to a switching method and system for integrating a monolithic architecture and a microservice architecture. Background Art

[0002] In the process of software development, as the complexity of applications increases, traditional monolithic architectures face many challenges in development, maintenance, and expansion. To address these issues, microservice architectures have been widely adopted, which achieve system flexibility and scalability by splitting applications into multiple independent service modules. However, microservice architectures also introduce the complexity of distributed systems, making development and maintenance more complicated. In related technologies, developers often need to design different development frameworks for monolithic architectures and microservice architectures, resulting in duplicate development work and increased development and maintenance costs.

[0003] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the invention

[0004] The main purpose of the embodiments of the present application is to propose a switching method and system for integrating a monolithic architecture and a microservice architecture, which can improve the reusability of the underlying logic code and reduce the complexity of the development and maintenance of the integrated service architecture.

[0005] To achieve the above objectives, an embodiment of the present application provides a method for switching between an integrated monolithic architecture and a microservice architecture, the method comprising:

[0006] Combine custom application programming interfaces, control layers, first business logic layers, and second business logic layers to build an integrated service architecture;

[0007] Dynamically identify the integrated service architecture through a service discovery mechanism and generate an interface call activation instruction;

[0008] Based on the interface call activation instruction, the integrated service architecture is controlled according to the service call logical link to switch between the monolithic architecture and the microservice architecture.

[0009] In some embodiments, a preset service call annotation is added to the custom application programming interface.

[0010] In some embodiments, the integrated service architecture includes the monolithic architecture and the microservice architecture, the monolithic architecture includes the custom application programming interface, the control layer and the first business logic layer, the microservice architecture includes the custom application programming interface, the control layer and the second business logic layer, and the monolithic architecture and the microservice architecture share the custom application programming interface and the control layer.

[0011] In some embodiments, a monomer application module is provided in the monomer architecture, and the monomer application module includes a plurality of functional sub-modules, and the plurality of functional sub-modules integrate the custom application programming interface, the control layer and the first business logic layer.

[0012] In some embodiments, there are several microservice application modules in the microservice architecture, several of which have independent business logic, and the custom application programming interface and the control layer are integrated in the same microservice application module, and the second business logic layer is set in another microservice application module.

[0013] In some embodiments, dynamically identifying the integrated service architecture through a service discovery mechanism and generating an interface call activation instruction includes:

[0014] Obtain service startup request information and register the information with the service registration center;

[0015] The registration information of the service registration center is queried to generate the interface call activation instruction.

[0016] In some embodiments, the interface call activation instruction includes a first interface call activation instruction and a second interface call activation instruction, the first interface call activation instruction calls the first business logic layer through the custom application programming interface, and the second interface call activation instruction calls the second business logic layer through the preset service call annotation in the custom application programming interface.

[0017] In some embodiments, the service call logic link includes a monolithic architecture service call logic link and a microservice architecture service call logic link.

[0018] In some embodiments, the step of controlling the integrated service architecture to switch between a monolithic architecture and a microservice architecture based on the interface calling activation instruction and according to the service calling logical link includes:

[0019] Obtaining the first interface call activation instruction, activating the single architecture service call logical link, and switching the integrated service architecture to the single architecture;

[0020] The second interface call activation instruction is obtained, the microservice architecture service call logical link is activated, and the integrated service architecture is switched to the microservice architecture.

[0021] To achieve the above objectives, another aspect of the embodiment of the present application provides a switching system integrating a monolithic architecture and a microservice architecture, the system comprising:

[0022] The first module is used to build an integrated service architecture by combining the custom application programming interface, the control layer, the first business logic layer and the second business logic layer;

[0023] The second module is used to dynamically identify the integrated service architecture through a service discovery mechanism and generate an interface call activation instruction;

[0024] The third module is used to control the integrated service architecture to switch between the monolithic architecture and the microservice architecture based on the interface call activation instruction and the service call logical link.

[0025] The embodiments of the present application include at least the following beneficial effects: The present application provides a method and system for switching between an integrated monolithic architecture and a microservice architecture. The solution builds an integrated service architecture through a custom application programming interface, and then combines the control layer, the first business logic layer and the second business logic layer. The integrated service architecture is further dynamically identified through a service discovery mechanism, and an interface call activation instruction is generated, thereby ensuring the dynamic and flexibility of service calls, and effectively supporting the dynamic expansion and fault recovery of microservices. Finally, based on the interface call activation instruction, the integrated service architecture is controlled according to the service call logical link to switch between the monolithic architecture and the microservice architecture, thereby realizing a general development framework compatible with the monolithic architecture and the microservice architecture, greatly improving the code reusability and system flexibility, and effectively reducing the complexity of development and maintenance. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 It is a flow chart of a method for switching between an integrated monolithic architecture and a microservice architecture provided in an embodiment of the present application;

[0027] Figure 2 It is a structural diagram of a switching system integrating a monolithic architecture and a microservice architecture provided in an embodiment of the present application;

[0028] Figure 3 It is a structural diagram of a single architecture service call logical link provided in an embodiment of the present application;

[0029] Figure 4 It is a structural diagram of a microservice architecture service call logical link provided by an embodiment of the present application;

[0030] Figure 5 This is a code diagram for defining an API interface provided in an embodiment of the present application;

[0031] Figure 6 This is a code diagram for calling an API interface in the Service layer provided in an embodiment of the present application;

[0032] Figure 7This is a schematic diagram of calling the API interface code in the Controller layer provided in an embodiment of the present application;

[0033] Figure 8 It is a code schematic diagram of the monolithic architecture deployment provided in an embodiment of the present application;

[0034] Fig. 9 It is a code schematic diagram of the microservice architecture deployment provided in the embodiment of the present application;

[0035] Fig.10 It is a code schematic diagram of calling a service instance in the microservice architecture provided in an embodiment of the present application;

[0036] Fig.11 It is a code diagram of the service discovery configuration provided in the embodiment of the present application. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is further described in detail below in conjunction with the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the embodiments of the present application. They are only examples of systems and methods consistent with some aspects of the embodiments of the present application as detailed in the attached claims.

[0038] It is understood that the terms "first", "second", etc. used in this application can be used to describe various concepts in this article, but unless otherwise specified, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another concept. For example, without departing from the scope of the embodiment of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the words "if" and "if" as used herein can be interpreted as "at the time of" or "when" or "in response to determination".

[0039] The terms "at least one", "multiple", "each", "any", etc. used in this application, at least one includes one, two or more, multiple includes two or more, each refers to each of the corresponding multiple, and any refers to any one of the multiple.

[0040] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0041] Before describing the embodiments of the present application in detail, some nouns and terms involved in the embodiments of the present application are first described. The nouns and terms involved in the embodiments of the present application are subject to the following explanations.

[0042] 1) Monolithic architecture: An application design pattern in which all functional modules (such as user management, order processing, payment system, etc.) are integrated into a single deployment unit. All modules share a code base and usually run in the same process. The advantage of monolithic architecture is that development and deployment are relatively simple, but as the scale of the application increases, it may lead to increased difficulty in maintenance and expansion.

[0043] 2) Microservice architecture: An application design pattern that splits a large application into multiple independent services, each responsible for a single business function. Each microservice can be independently developed, deployed, and expanded, and uses lightweight communication mechanisms (such as HTTP / REST, message queues, etc.) to interact with other services. The microservice architecture achieves high scalability and flexibility of the system through loose coupling, but it also brings the complexity of distributed systems.

[0044] 3) Controller: The component in the application that is responsible for receiving and processing requests from the client. It is usually at the front end of the application and interacts directly with the user or other systems. The controller parses the received request and passes it to the corresponding business logic layer (such as the Service layer) for processing, and then returns the processing result to the client. The controller is a key component in the MVC (Model-View-Controller) architecture, which is used to implement the input control logic of the application.

[0045] 4) Application Programming Interface (API): A set of standard interfaces used to define interactions between software components in a system. API provides an abstraction layer that defines how data is exchanged and functions are called between different modules, services, or systems. In a microservice architecture, API is often used to define the functions and contracts provided by services, so that services can communicate through API. The design goal of the API layer is to decouple business logic and provide a unified interface for other components or systems to call.

[0046] 5) Business Logic Layer (Service): An independent functional module responsible for handling specific business logic. Services usually implement the interface methods defined in the API layer and can be directly called as local modules or independently deployed in a distributed environment and remotely called through the network. In a microservice architecture, each service is usually an independent application that can be independently deployed, expanded, and updated. The implementation of services can include data processing, business rule execution, and interaction with other services.

[0047] Reference Figure 1 , Figure 1 A flowchart of a method for switching between an integrated monolithic architecture and a microservice architecture provided by an embodiment of the present invention, referring to Figure 1 , the method comprises the following steps:

[0048] S100, building an integrated service architecture by combining the custom application programming interface, the control layer, the first business logic layer, and the second business logic layer;

[0049] First of all, it should be noted that the preset service call annotation is added to the custom application programming interface.

[0050] Specifically, the embodiment of the present invention extracts a layer of API interface as an abstract layer, and supports remote calls in the microservice architecture by adding the @FeignClient annotation to the API interface. Different from the traditional interface, this design method enables the Controller layer to rely only on the API interface during development without having to worry about the specific implementation method. In actual deployment, different Service implementation modules can be introduced as needed to achieve flexible switching of the architecture. In the monolithic architecture, the API interface is used as a common interface; in the microservice architecture, the API interface is used as a Feign client to provide remote calling capabilities. This design greatly improves the reusability of the code and significantly reduces the cost of switching the system architecture.

[0051] It should be explained that @FeignClient is an annotation used to declare a Feign client in Spring Cloud. Through this annotation, an interface can be declared as a Feign client and the remote service method can be directly called through this interface.

[0052] Furthermore, it should be noted that the integrated service architecture includes a monolithic architecture and a microservice architecture. The monolithic architecture includes a custom application programming interface, a control layer and a first business logic layer. The microservice architecture includes a custom application programming interface, a control layer and a second business logic layer. The monolithic architecture and the microservice architecture share the custom application programming interface and the control layer.

[0053] Specifically, the control layer, or Controller layer, is responsible for receiving and processing requests from clients and delegating the requests to the API layer for processing. The Controller layer only depends on the API layer and does not interact directly with the Service layer, thereby achieving the decoupling of the Controller and Service. Whether it is a monolithic architecture or a microservice architecture, the code of the Controller layer can remain unchanged.

[0054] The custom application programming interface, or API layer, is an interface layer used to define the interface of the business logic. The interface definition of the API layer is as general as possible, avoiding specific implementation details. In the microservice architecture, the API layer can implement remote calls by adding the @FeignClient annotation, while in the monolithic architecture it is used as a normal interface, which can be implemented either locally (monolithic architecture) or remotely (microservice architecture).

[0055] The first business logic layer and the second business logic layer are the Service layer. They are responsible for implementing the business logic defined by the API layer. In the monolithic architecture, the Service layer is directly introduced into the project and locally bound to the interface of the API layer; in the microservice architecture, the Service layer can be independently deployed as a microservice and remotely called through the service discovery mechanism.

[0056] Among them, a monomer application module is provided in the monomer architecture, and the monomer application module includes a plurality of functional sub-modules, and the plurality of functional sub-modules integrate a custom application programming interface, a control layer and a first business logic layer.

[0057] Specifically, in this embodiment, based on the monolithic architecture, developers can introduce the three modules of Controller, API and Service into the same project at the same time to form a complete application. The Controller layer directly calls the locally implemented Service layer through the API layer, and the application is deployed as a whole.

[0058] There are several microservice application modules in the microservice architecture, and some microservice application modules have independent business logic. The custom application programming interface and the control layer are integrated in the same microservice application module, and the second business logic layer is set in another microservice application module.

[0059] Specifically, in this embodiment, based on the microservice architecture, developers only need to introduce the Controller and API modules, and the Service layer can be independently deployed as a microservice. The API layer calls the remotely deployed Service through the network to implement distributed processing of business logic. Through the abstraction of the API layer, developers can switch from a monolithic architecture to a microservice architecture without modifying the code of the Controller layer.

[0060] In summary, the embodiments of the present invention allow developers to flexibly choose the deployment method according to actual needs. In a monolithic architecture, all modules (Controller, API, Service) can be packaged into an executable application and deployed as a whole. In a microservice architecture, each Service module can be deployed independently and called through the API layer. This flexibility enables the system to be quickly adjusted and expanded according to business needs, avoiding repeated development and complex system migration.

[0061] S200, dynamically identifying the integrated service architecture through a service discovery mechanism, and generating an interface call activation instruction;

[0062] It should be noted that, in some embodiments, step S200 may include steps S210 to S220.

[0063] S210, obtaining service start request information and registering the information with the service registration center;

[0064] S220: Query the registration information of the service registration center and generate an interface call activation instruction.

[0065] In some specific embodiments, the interface call activation instruction includes a first interface call activation instruction and a second interface call activation instruction. The first interface call activation instruction calls the first business logic layer through a custom application programming interface, and the second interface call activation instruction calls the second business logic layer through a preset service call annotation in the custom application programming interface.

[0066] In this embodiment, in order to solve the service location problem in the microservice architecture, an embodiment of the present invention provides a service discovery mechanism. When the Service layer is deployed independently as a microservice, each service will automatically register its network location (such as IP address and port) with the service registration center when it is started. When the API layer calls the interface of the Service layer, it can query the service registration center to discover and call the appropriate Service instance. This mechanism ensures the dynamic and flexibility of service calls and effectively supports the dynamic expansion and fault recovery of microservices.

[0067] S300, based on the interface call activation instruction, the integrated service architecture is controlled according to the service call logical link to switch between the monolithic architecture and the microservice architecture;

[0068] It should be noted that, in some embodiments, the service call logic link includes a monolithic architecture service call logic link and a microservice architecture service call logic link.

[0069] Further, step S300 may include step S310 to step S320.

[0070] S310, obtaining a first interface call activation instruction, activating a single architecture service call logical link, and switching the integrated service architecture to a single architecture;

[0071] In some specific embodiments, Figure 3 As shown in the figure, the monolithic architecture service call logic link couples all functions and modules of the entire application in a single system and is usually deployed on a single server. In the monolithic architecture, the service call logic link mainly refers to the call relationship and process between various modules or services within the application. Among them, API is an application programming interface, which defines a set of protocols, specifications or tools for communication between different software applications. The control layer (controller) is responsible for processing user requests and responses, usually receiving requests from the front end or client, and calling the corresponding business logic layer (Service) to process these requests. After processing, the controller layer returns the results to the front end or client through the API. The business logic layer (Service) is responsible for processing the core business logic in the application and returning the processing results to the API layer.

[0072] S320. Obtain a first interface call activation instruction, activate a microservice architecture service call logic link, and switch the integrated service architecture to a microservice architecture.

[0073] In some specific embodiments, Figure 4 As shown in the figure, the service call logic link of the microservice architecture splits the system into several small services. Each service only focuses on its own business logic and collaborates and integrates through lightweight communication mechanisms. The front end or client directly initiates a request to the microservice backend collection. The presentation layer (controller) is responsible for processing the requests and responses sent by users to the API. The business logic layer (Service) with different functions is responsible for processing the core business logic in the application and returning the processing results to the API layer.

[0074] Finally, the embodiments of the present invention are described by using practical engineering operation examples:

[0075] 1) Define API interface: Define the API interface of business logic and add @FeignClient annotation to the interface to support remote calls between microservices, such as Figure 5 As shown in the figure, the OrderService interface defines an API interface for obtaining order information. In the microservice architecture, this interface will be remotely called through the Feign client.

[0076] 2) Implement the Service layer: Implement the API interface in the Service layer. In a monolithic architecture, the Service layer can be directly used as a local implementation module, such as Figure 6 As shown in the figure, in the microservice architecture, OrderServiceImpl can be independently deployed as a microservice application.

[0077] 3) Build the Controller layer: In the Controller layer, call the API interface to process client requests. The code of the Controller layer can be reused in the monolithic architecture and microservice architecture, such as Figure 7 shown.

[0078] 4) Monolithic architecture deployment: In a monolithic architecture, the Controller layer, API layer, and Service layer are packaged in the same Spring Boot application and deployed as a whole, such as Figure 8 As shown, at this time, OrderServiceImpl is directly called by OrderController as a local implementation module.

[0079] 5) Deployment of microservice architecture: In the microservice architecture, OrderServiceImpl is deployed as an independent microservice application, such as Fig. 9 As shown, at the same time, deploy OrderController and OrderService Feign client proxy on the microservice consumer side (such as order management application). By configuring service discovery mechanism, such as Eureka or Consul, ensure that the OrderService interface can dynamically discover and call the service instance of OrderServiceImpl, as shown below: Fig.10 As shown, in this case, the OrderService interface initiates an HTTP request through the Feign client to call the remotely deployed OrderServiceImpl service.

[0080] 6) Service discovery configuration: To implement service discovery, you can use Eureka for configuration in Spring Cloud. OrderServiceImpl is registered with the Eureka service registry at startup, such as Fig.11 As shown in the figure, the consumer side dynamically discovers and calls the OrderServiceImpl instance through Eureka.

[0081] 7) Testing and verification: After deployment, the system functions can be tested and verified by calling the API interface of the order management application. In the monolithic architecture, OrderController directly calls the locally implemented OrderServiceImpl; in the microservice architecture, OrderController calls the remote OrderServiceImpl service through the Feign client.

[0082] In summary, the embodiments of the present invention can implement the application of monolithic architecture and microservice architecture on the same code basis, greatly improving the reusability of the code and the flexibility of the system. Developers can flexibly choose the deployment method according to specific business needs, and easily switch between different architectures without making large-scale modifications to the business logic code. That is, the design of the API layer makes it unnecessary to make large-scale code modifications when the system switches architectures, thereby reducing the maintenance cost of the system. This general development framework design method effectively reduces the complexity of development and maintenance, provides a general development framework design method that is compatible with monolithic architecture and microservice architecture, and improves the scalability and stability of the system.

[0083] See also Figure 2 The embodiment of the present application further provides a switching system for integrating a monolithic architecture and a microservice architecture, which can implement the above-mentioned switching method for integrating a monolithic architecture and a microservice architecture, and the system includes:

[0084] The first module 201 is used to build an integrated service architecture by combining a custom application programming interface, a control layer, a first business logic layer and a second business logic layer;

[0085] The second module 202 is used to dynamically identify the integrated service architecture through a service discovery mechanism and generate an interface call activation instruction;

[0086] The third module 203 is used to switch between the monolithic architecture and the microservice architecture based on the interface call activation instruction and the service call logical link control integrated service architecture.

[0087] It can be understood that the contents of the above method embodiments are all applicable to the present system embodiments, the functions specifically implemented by the present system embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0088] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but the scope of the rights of the present invention is not limited thereto. Any modification, equivalent substitution and improvement made by a person skilled in the art without departing from the scope and essence of the present invention should be within the scope of the rights of the present invention.

Claims

1. A method for switching between an integrated monolithic architecture and a microservice architecture, characterized in that: The method comprises the following steps: Combine custom application programming interfaces, control layers, first business logic layers, and second business logic layers to build an integrated service architecture; Dynamically identify the integrated service architecture through a service discovery mechanism and generate an interface call activation instruction; Based on the interface call activation instruction, the integrated service architecture is controlled according to the service call logical link to switch between the monolithic architecture and the microservice architecture.

2. The method according to claim 1, characterized in that: Add a preset service call annotation to the custom application programming interface.

3. The method according to claim 1, characterized in that The integrated service architecture includes the monolithic architecture and the microservice architecture. The monolithic architecture includes the custom application programming interface, the control layer and the first business logic layer. The microservice architecture includes the custom application programming interface, the control layer and the second business logic layer. The monolithic architecture and the microservice architecture share the custom application programming interface and the control layer.

4. The method according to claim 3, characterized in that: A monomer application module is provided in the monomer architecture, and the monomer application module includes a plurality of functional sub-modules, and the plurality of functional sub-modules integrate the custom application programming interface, the control layer and the first business logic layer.

5. The method according to claim 3, characterized in that: There are several microservice application modules in the microservice architecture, and several of the microservice application modules have independent business logic. The custom application programming interface and the control layer are integrated in the same microservice application module, and the second business logic layer is set in another microservice application module.

6. The method according to claim 1, characterized in that The step of dynamically identifying the integrated service architecture through a service discovery mechanism and generating an interface call activation instruction includes: Obtain service startup request information and register the information with the service registration center; The registration information of the service registration center is queried to generate the interface call activation instruction.

7. The method according to claim 2, characterized in that: The interface call activation instruction includes a first interface call activation instruction and a second interface call activation instruction. The first interface call activation instruction calls the first business logic layer through the custom application programming interface, and the second interface call activation instruction calls the second business logic layer through the preset service call annotation in the custom application programming interface.

8. The method according to claim 1, characterized in that The service call logic link includes a monolithic architecture service call logic link and a microservice architecture service call logic link.

9. The method according to claim 8, characterized in that The step of controlling the integrated service architecture to switch between a monolithic architecture and a microservice architecture based on the interface calling activation instruction and according to the service calling logical link includes: Obtaining the first interface call activation instruction, activating the single architecture service call logical link, and switching the integrated service architecture to the single architecture; The second interface call activation instruction is obtained, the microservice architecture service call logical link is activated, and the integrated service architecture is switched to the microservice architecture.

10. A switching system integrating a monolithic architecture and a microservice architecture, characterized in that: The system comprises: The first module is used to build an integrated service architecture by combining the custom application programming interface, the control layer, the first business logic layer and the second business logic layer; The second module is used to dynamically identify the integrated service architecture through a service discovery mechanism and generate an interface call activation instruction; The third module is used to control the integrated service architecture to switch between the monolithic architecture and the microservice architecture based on the interface call activation instruction and the service call logical link.

Images