Lightweight computer micro-service framework and construction method thereof

Abstract

The invention discloses a lightweight computer micro-service framework and a construction method thereof, and the construction method comprises the steps: providing various types of technical middleware based on a WFS development framework, and determining a user-defined annotation mechanism of business service of a business layer, the technical middleware comprises one or more of a registration center, cache middleware, message middleware and a database; based on the determined custom annotation mechanism, generating a corresponding module implementation component for the currently provided technical middleware; according to the determined user-defined annotation mechanism, performing user-defined annotation on the newly-built business service; and in response to starting of a computer system of the micro-service framework, scanning the custom annotation information of each business service so as to load the module implementation component corresponding to the business service. When the technical middleware is updated, the module implementation component is regenerated based on the current custom annotation mechanism without changing a business layer.

Description

Technical Field

[0001] This invention relates to the field of microservice software development, and in particular to a lightweight computer microservice framework and its construction method. Background Technology

[0002] The underlying development framework of bank software systems exhibits a degree of coupling and nesting among its various fundamental technical components, resulting in relatively redundant and complex external dependencies. This poses potential risks to the overall system stability and, due to the numerous redundant external dependencies, extends the overall system startup time, increasing the complexity of managing third-party external dependency security. Furthermore, the diverse range of systems and significant differences in development frameworks and technology stacks between different teams, coupled with the substantial workload and significant human and material costs required to integrate new systems with the bank's designated middleware, further complicates the situation.

[0003] Commonly used microservice development frameworks in the industry include Spring Cloud and Spring Cloud-Alibaba. Different frameworks offer different development kits, such as service registry centers, service registration / discovery and invocation frameworks, and asynchronous message communication mechanisms. Due to differences in the designers and developers, their own scenario constraints, the constraints of their development kit technology choices, and their own ecosystem considerations, the development and usage methods for upper-layer business applications to access these frameworks vary considerably. If there is a change in the underlying technology selection, such as switching from a proprietary RPC protocol to a general HTTP protocol, the upper-layer business code may need to undergo adjustments to its code structure, annotations, and invocation methods. Since the middleware such as JSF, R2M, and FMQ provided by the financial cloud PaaS platform is not open source, existing open-source microservice development frameworks such as Spring Cloud do not support the integration of these commercial, non-open-source middleware, which imposes certain constraints on the selection of underlying technologies.

[0004] While existing open-source microservice frameworks offer different solutions for common scenarios, these solutions do not shield users from differences in usage methods. This leads to additional overhead, such as adaptation and modification of the business application layer, when switching between different solutions. Adapting such middleware to an open-source microservice framework would involve a significant, challenging, and risky development workload.

[0005] The above background information is provided only to aid in understanding the concept and technical solution of this application. It does not necessarily belong to the prior art of this application, nor does it necessarily provide technical guidance. In the absence of clear evidence that the above information was disclosed before the filing date of this application, the above background information should not be used to evaluate the novelty and inventiveness of this application. Summary of the Invention

[0006] The purpose of this invention is to provide a solution that uses unified annotations and unified APIs to carry differentiated underlying implementations for different development kit systems and different usage styles, thereby promoting the overall lightweighting of business services.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0008] A method for constructing a lightweight computer microservice framework includes:

[0009] Based on the WFS development framework, various types of technical middleware are provided, and a custom annotation mechanism for business services in the business layer is determined. The technical middleware includes one or more of the following: a registry center, a cache middleware, a message middleware, and a database.

[0010] Based on a defined custom annotation mechanism, corresponding module implementation components are generated for the currently provided technology middleware;

[0011] Custom annotations are created for newly established business services according to the established custom annotation mechanism;

[0012] In response to the startup of a computer system based on a microservices framework, the system scans the custom annotation information of each business service to load the corresponding module implementation components.

[0013] Furthermore, based on any one or a combination of the aforementioned technical solutions, when the technical middleware is updated, the module implementation components are regenerated based on the current custom annotation mechanism;

[0014] Keep the custom annotation information of the current business services unchanged;

[0015] In response to the startup of a computer system based on a microservices framework, the system scans the custom annotation information of each business service to load the regenerated module implementation components corresponding to that business service.

[0016] Furthermore, following any one or a combination of the aforementioned technical solutions, the module implementation components corresponding to the business service are loaded in the following manner:

[0017] Scan the custom annotation information of the business service and distinguish whether the custom annotation information belongs to the producer parsing type or the consumer parsing type;

[0018] If it belongs to the producer parsing type, the annotation parameters are parsed to obtain the global registration interface descriptor; the global registration interface descriptor obtained by parsing is used to provide a global interface query service; and according to the Export mechanism, the interface service corresponding to the query request is output.

[0019] If it belongs to the consumer resolution type, the call instance is registered based on the Import mechanism to create a consumer instance in the Spring container; and the BeanDefinition metadata is registered based on the custom FactoryBean interface.

[0020] Furthermore, based on any one or a combination of the aforementioned technical solutions, and according to the Export mechanism, the interface services corresponding to the query request are output, including:

[0021] The global registration interface descriptor is a URI, and the interface definition for remote procedure calls is obtained from the interface definition layer based on the URI;

[0022] The RPC-JSF business logic implementation based on remote procedure calls loads the automatic configuration file corresponding to the interface definition of the remote procedure call by calling the export function, and then registers the JSF protocol URL and publishes the registered services to the registry center.

[0023] The registry center notifies service consumers of the service instances that have been published, based on the published services.

[0024] Furthermore, following any one or a combination of the aforementioned technical solutions, registering the calling instance based on the Import mechanism to create a consumer instance in the Spring container includes:

[0025] The global registration interface descriptor is a URI, and the message interface definition is obtained from the interface definition layer based on the URI;

[0026] The process of generating dynamic proxies includes: using the ImportBeanDefinitionRegistrar mechanism to actively scan consumer annotation configuration information, automatically load and parse the metadata of annotation classes, and send the parsed annotation class information to FactoryBean; and using FactoryBean's getTarget interface to return the corresponding consumer dynamic proxy class.

[0027] After generating the dynamic proxy, inject the proxy object and send it to the business layer through the Spring container.

[0028] Furthermore, following any one or a combination of the aforementioned technical solutions, after the call instance injection is completed via dynamic proxy under the consumer resolution type, both intra-virtual machine call mode and cross-virtual machine remote call mode are supported, including:

[0029] In response to the call request, perform an instance query to determine whether the call type is an intra-virtual machine call or a cross-virtual machine remote call;

[0030] If it is a virtual machine internal call mode, the call is completed and returned based on the locally injected Bean metadata;

[0031] If it is a cross-virtual machine remote call mode, the annotation metadata is parsed, and the JSF protocol descriptor is obtained from the registry center based on the parsed metadata; the request for method signature serialization is sent through the JSF protocol and the request for calling based on the JSF RPC mechanism is made; and the return value after the RPC call is deserialized.

[0032] Furthermore, based on any or a combination of the aforementioned technical solutions, the module implementation components include core business logic implementation, protocol adaptation layer, Spring Boot auto-configuration, and interface definition layer.

[0033] Furthermore, based on any one or a combination of the aforementioned technical solutions, in response to the interaction scenarios between the microservice framework and external systems, compatibility is achieved through the following methods:

[0034] Obtain the interface class information of external systems and parse annotations to determine whether the external system also uses the WFS development framework;

[0035] If so, an isomorphic call is performed, including: obtaining a ServiceRegistry instance from the WFS core container and addressing it based on the URI to obtain the global service retrieval interface; and calling the WfsService.api function based on the global service retrieval interface to return the interface's Class object.

[0036] If they are different, heterogeneous calls are made, including: directly reading predefined interface classes from the annotation parsing of interface class information from external systems; and directly using local configuration to connect the directly read interface classes to the interfaces defined in the business layer without accessing the registry center.

[0037] According to another aspect of the present invention, a lightweight computer microservice framework is provided, including a business layer, a WFS-API interface layer, a technology middleware, and module implementation components, wherein the microservice framework is constructed using the method described above.

[0038] Furthermore, based on any or a combination of the aforementioned technical solutions, the WFS-API interface layer supports interfacing with middleware such as JSF, R2M, and FMQ;

[0039] And / or, the microservice framework supports switching from the Spring Cloud system to the JSF system.

[0040] The beneficial effects of the technical solution provided by this invention are as follows:

[0041] a. For different development kit systems, use unified annotations and unified APIs to carry different underlying layers, develop lightweight dependencies, and support on-demand loading;

[0042] b. The WFS technology framework can load and support multiple RPC communication protocols, including JSF, on demand, and connect to R2M cache and FMQ message middleware;

[0043] c. It can simultaneously support both virtual machine intra-virtual machine call mode and cross-virtual machine remote call mode;

[0044] d. It enables compatibility between the microservice framework and external systems in various interaction scenarios. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 A flowchart illustrating a method for constructing a lightweight computer microservice framework, provided as an exemplary embodiment of the present invention;

[0047] Figure 2 A schematic diagram of the structure of a computer microservice framework provided as an exemplary embodiment of the present invention;

[0048] Figure 3 A schematic diagram illustrating the module implementation component loading process for a business service provided in an exemplary embodiment of the present invention;

[0049] Figure 4 A flowchart illustrating the process of outputting an interface service corresponding to a query request under the producer parsing type according to the Export mechanism, as an exemplary embodiment of the present invention;

[0050] Figure 5A schematic diagram illustrating the process of registering a call instance based on the Import mechanism under a consumer parsing type, as provided in an exemplary embodiment of the present invention;

[0051] Figure 6 A flowchart illustrating a framework provided for an exemplary embodiment of the present invention that simultaneously supports intra-virtual machine call mode and cross-virtual machine remote call mode;

[0052] Figure 7 This is a schematic diagram illustrating a compatible microservice framework implementation as provided in an exemplary embodiment of the present invention. Detailed Implementation

[0053] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0054] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, apparatus, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0055] In one embodiment of the present invention, a method for constructing a lightweight computer microservice framework is provided, such as... Figure 1 As shown, it includes the following steps:

[0056] Step 1: Based on the WFS development framework, provide various types of technical middleware and determine the custom annotation mechanism for business services in the business layer. The technical middleware includes one or more of the following: a registry center, a cache middleware, a message middleware, and a database.

[0057] Specifically, the WFS development framework builds a business middleware enhancement layer on top of the infrastructure layer provided by Spring Cloud. In other words, WFS builds business enhancement capabilities on top of Spring Cloud, forming a complementary and collaborative layered architecture.

[0058] Step 2: Based on the established custom annotation mechanism, generate corresponding module implementation components for the currently provided technology middleware. These can include core business logic implementation, protocol adaptation layer, Spring Boot auto-configuration, interface definition layer, etc. Among them, the -core file type is responsible for the core framework loading logic implementation, such as annotation scanning and parsing; the -jsf / -fmq file type is responsible for the technology suite adaptation layer, where JSF is the JD.com JSF communication protocol and FMQ is the JD.com message middleware; the -starter file type is responsible for the Spring Boot application dependency configuration module; and the -api file type is responsible for the interface definition layer.

[0059] Step 3: Create custom annotations for the newly created business services according to the established custom annotation mechanism;

[0060] By using custom annotations, the underlying capabilities are automatically loaded and injected, shielding the impact of switching between technical components in different scenarios. The upper-level business code only needs to focus on the development of business logic, while the complexity of common basic technologies such as communication and caching is uniformly solved by the framework.

[0061] Step 4: In response to the startup of the computer system in the microservice framework, scan the custom annotation information of each business service to load the module implementation components corresponding to that business service.

[0062] Based on this, when the technology middleware is updated, the module implementation components are regenerated based on the current custom annotation mechanism;

[0063] Keep the custom annotation information of the current business services unchanged;

[0064] In response to the startup of a computer system based on a microservices framework, the system scans the custom annotation information of each business service to load the regenerated module implementation components corresponding to that business service.

[0065] like Figure 2 As shown, the computer microservice framework in this embodiment is applicable to projects with a group of credit risk systems. It connects the business services of different systems to a unified API through unified annotations, reduces external dependency redundancy, improves the overall stability of the system, reduces the complexity of the system in terms of third-party external dependency security management, and effectively "slims down" the credit risk system, shortening the system startup time.

[0066] The unified lightweight framework constructed in this embodiment follows the principle of convention over configuration, providing a unified development dependency suite. This enables rapid integration with the financial cloud, reduces technical development complexity, eliminates or mitigates technical barriers between different development teams, and shields the application layer from the impact of differences in underlying technology selection. Based on Spring's powerful extension mechanism, it dynamically loads different underlying implementation mechanisms through custom annotations, providing a unified access standard for the application layer, thereby protecting against the impact of changes in underlying technologies.

[0067] By customizing newly created business services according to a preset custom annotation mechanism, when the technology middleware is updated, the module implementation components are regenerated without modifying the business services. This decouples the underlying technology from the upper-layer business, reduces technical complexity, lowers the development complexity of the upper-layer business, and reduces the cost of integrating new services into the current lightweight framework system's technology middleware.

[0068] based on Figure 2 The framework adheres to the principle of convention over configuration and is designed according to the Spring-Boot ecosystem. It provides various lightweight basic capability Starter technology components, offering a one-stop solution for dependencies on various technology development kits. Following the design principles of high cohesion and low coupling, it achieves on-demand loading, avoiding redundancy in upper-level dependencies caused by high coupling at the lower level. Through the framework's lightweight mechanism, it promotes the overall lightweighting of business services. Specifically, as follows... Figure 3 As shown, the module implementation components corresponding to the business service are loaded in the following ways:

[0069] After the system starts, it scans the custom annotation information of the business services and distinguishes whether the custom annotation information belongs to the producer parsing type or the consumer parsing type.

[0070] If it belongs to the producer parsing type, the annotation parameters are parsed to obtain the global registration interface descriptor; the global registration interface descriptor obtained by parsing is used to provide a global interface query service; and according to the Export mechanism, the interface service corresponding to the query request is output, specifically as follows: Figure 4 As shown, the global registration interface descriptor is a URI. The interface definition of the remote procedure call is obtained from the interface definition layer based on the URI. The RPC-JSF business logic implementation based on the remote procedure call loads the automatic configuration file corresponding to the interface definition of the remote procedure call by calling the export function, and then registers the JSF protocol URL and publishes the registered service to the registry center. The registry center notifies the service consumers of the published service instances based on the published services.

[0071] Continue to refer to Figure 3If the custom annotation information belongs to the consumer parsing type, then the call instance is registered based on the Import mechanism to create a consumer instance in the Spring container; and the BeanDefinition metadata is registered according to the custom FactoryBean interface. Specifically, as follows... Figure 5 As shown, the global registration interface descriptor is a URI. The message interface definition is obtained from the interface definition layer based on the URI. The dynamic proxy generation includes: using the ImportBeanDefinitionRegistrar mechanism to actively scan the consumer annotation configuration information, automatically load and parse the metadata of the annotation class, and send the parsed annotation class information to FactoryBean; using the getTarget interface of FactoryBean to return the corresponding consumer dynamic proxy class; after generating the dynamic proxy, injecting the proxy object, and sending it to the business layer through the Spring container.

[0072] On the other hand, after the consumer resolution type completes the instance injection via dynamic proxy, it supports both intra-virtual machine call mode and cross-virtual machine remote call mode, such as... Figure 6 As shown:

[0073] In response to the call request, perform an instance query to determine whether the call type is an intra-virtual machine call or a cross-virtual machine remote call;

[0074] If it is a virtual machine internal call mode, the call is completed and returned based on the locally injected Bean metadata;

[0075] If it is a cross-virtual machine remote call mode, the annotation metadata is parsed, and the JSF protocol descriptor is obtained from the registry center based on the parsed metadata; the request for method signature serialization is sent through the JSF protocol and the request for calling based on the JSF RPC mechanism is made; and the return value after the RPC call is deserialized.

[0076] Furthermore, in response to the interaction scenarios between the microservice framework and external systems, the microservice framework implementation in this embodiment is compatible, such as... Figure 7 As shown:

[0077] Obtain the interface class information of external systems and parse annotations to determine whether the external system also uses the WFS development framework;

[0078] If so, an isomorphic call is performed, including: obtaining a ServiceRegistry instance from the WFS core container and addressing it based on the URI to obtain the global service retrieval interface; and calling the WfsService.api function based on the global service retrieval interface to return the interface's Class object.

[0079] If they are different, heterogeneous calls are made, including: directly reading predefined interface classes from the annotation parsing of interface class information from external systems; and directly using local configuration to connect the directly read interface classes to the interfaces defined in the business layer without accessing the registry center.

[0080] According to another aspect of the present invention, a lightweight computer microservice framework is provided, such as... Figure 2 As shown, it includes a business layer (which can contain multiple business functions), a WFS-API interface layer, technical middleware (registration center, caching middleware, message middleware, database, etc.), and module implementation components ( Figure 2 The microservice framework is constructed using the method described above, with the lowest-level file type being the most common.

[0081] In one specific embodiment, the WFS-API interface layer supports middleware integration with JSF, R2M, and FMQ; the microservice framework supports switching from the Spring Cloud system to the JSF system.

[0082] Based on Spring's annotation extension mechanism, custom annotations are loaded and parsed during system startup using BeanPostProcessor and ImportBeanDefinitionRegistrar. On the Producer side, global registration of all service interface method descriptors is completed.<URI,interfaceType> The system registers all service interfaces with a remote registry center and exposes the global service retrieval interface. On the Consumer side, it injects the call instance through dynamic proxy. At the same time, it utilizes the API interfaces provided by the underlying technology suite to load the overall framework.

[0083] On the Consumer side, instance injection is accomplished through dynamic proxies, supporting both intra-virtual machine calls and cross-virtual machine remote calls, thus flexibly supporting the merging and splitting of upper-layer business services. In the remote call scenario, a global service retrieval interface is used to query the interface descriptor, assemble parameters, and then the JSF native RPC mechanism is used to complete the remote interface call.

[0084] There are two main modes in the interaction scenarios within the system and with external business systems. The first is the homogeneous mode, where both parties are based on the same development framework; the second is the heterogeneous mode, where one party is based on the self-developed WFS framework, and the other party is based on the native JSF. To ensure compatibility between these two interaction scenarios, the framework annotations provide two interface addressing methods: one is URI-based addressing; the other is addressing based on custom interface classes.

[0085] In summary, the microservice framework in this embodiment supports seamless switching of Spring Cloud application code to JSF, the switching of underlying system technologies is imperceptible to upper-layer business logic, the development framework has lightweight dependencies, and supports on-demand loading.

[0086] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0087] The above description is only a specific embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for constructing a lightweight computer microservice framework, characterized in that, include: Based on the WFS development framework, various types of technical middleware are provided, and a custom annotation mechanism for business services in the business layer is determined. The technical middleware includes one or more of the following: a registry center, a cache middleware, a message middleware, and a database. Based on a defined custom annotation mechanism, corresponding module implementation components are generated for the currently provided technology middleware; Custom annotations are created for newly established business services according to the established custom annotation mechanism; In response to the startup of a computer system based on a microservices framework, the system scans the custom annotation information of each business service to load the corresponding module implementation components.

2. The lightweight computer microservice framework construction method according to claim 1, characterized in that, When the technology middleware is updated, the module implementation components are regenerated based on the current custom annotation mechanism; Keep the custom annotation information of the current business services unchanged; In response to the startup of a computer system based on a microservices framework, the system scans the custom annotation information of each business service to load the regenerated module implementation components corresponding to that business service.

3. The method for constructing a lightweight computer microservice framework according to claim 1, characterized in that, Load the module implementation components corresponding to the business service in the following ways: Scan the custom annotation information of the business service and distinguish whether the custom annotation information belongs to the producer parsing type or the consumer parsing type; If it belongs to the producer parsing type, then parse the annotation parameters to obtain the global registration interface descriptor; use the obtained global registration interface descriptor to provide a global interface query service; And according to the Export mechanism, output the interface service corresponding to the query request; If it belongs to the consumer resolution type, the call instance is registered based on the Import mechanism to create a consumer instance in the Spring container; And based on the custom FactoryBean interface, complete the registration of BeanDefinition metadata.

4. The method for constructing a lightweight computer microservice framework according to claim 3, characterized in that, According to the Export mechanism, the interface services corresponding to the query request include: The global registration interface descriptor is a URI, and the interface definition for remote procedure calls is obtained from the interface definition layer based on the URI; The RPC-JSF business logic implementation based on remote procedure calls loads the automatic configuration file corresponding to the interface definition of the remote procedure call by calling the export function, and then registers the JSF protocol URL and publishes the registered services to the registry center. The registry center notifies service consumers of the service instances that have been published, based on the published services.

5. The method for constructing a lightweight computer microservice framework according to claim 3, characterized in that, Registering call instances based on the Import mechanism to create consumer instances in the Spring container includes: The global registration interface descriptor is a URI, and the message interface definition is obtained from the interface definition layer based on the URI; The process of generating dynamic proxies includes: using the ImportBeanDefinitionRegistrar mechanism to actively scan consumer annotation configuration information, automatically load and parse the metadata of annotation classes, and send the parsed annotation class information to FactoryBean; and using FactoryBean's getTarget interface to return the corresponding consumer dynamic proxy class. After generating the dynamic proxy, inject the proxy object and send it to the business layer through the Spring container.

6. The method for constructing a lightweight computer microservice framework according to claim 3, characterized in that, After the consumer resolution type completes the instance injection via dynamic proxy, it supports both intra-virtual machine call mode and cross-virtual machine remote call mode, including: In response to the call request, perform an instance query to determine whether the call type is an intra-virtual machine call or a cross-virtual machine remote call; If it is a virtual machine internal call mode, the call is completed and returned based on the locally injected Bean metadata; If it is a cross-virtual machine remote call mode, the annotation metadata is parsed, and the JSF protocol descriptor is obtained from the registry center based on the parsed metadata; the request for method signature serialization is sent through the JSF protocol and the request for calling based on the JSF RPC mechanism is made; and the return value after the RPC call is deserialized.

7. The method for constructing a lightweight computer microservice framework according to claim 1, characterized in that, The module implementation components include core business logic implementation, protocol adaptation layer, Spring Boot auto-configuration, and interface definition layer.

8. The method for constructing a lightweight computer microservice framework according to any one of claims 1 to 7, characterized in that, To address the interaction scenarios between the microservice framework and external systems, compatibility is achieved through the following methods: Obtain the interface class information of external systems and parse annotations to determine whether the external system also uses the WFS development framework; If so, an isomorphic call is performed, including: obtaining a ServiceRegistry instance from the WFS core container and addressing it based on the URI to obtain the global service retrieval interface; and calling the WfsService.api function based on the global service retrieval interface to return the interface's Class object. If they are different, heterogeneous calls are made, including: directly reading predefined interface classes from the annotation parsing of interface class information from external systems; and directly using local configuration to connect the directly read interface classes to the interfaces defined in the business layer without accessing the registry center.

9. A lightweight computer microservice framework, characterized in that, The microservice framework comprises a business layer, a WFS-API interface layer, technical middleware, and module implementation components, and is constructed using the method described in any one of claims 1 to 8.

10. The lightweight computer microservice framework according to claim 9, characterized in that, The WFS-API interface layer supports interfacing with middleware such as JSF, R2M, and FMQ; And / or, the microservice framework supports switching from the Spring Cloud system to the JSF system.

Images