A microservice development system with pluggable governance functions and an implementation method

Abstract

The present invention relates to a microservice development framework with governance function plug-inization and its implementation method. By adopting the plug-in implementation method, through object-oriented interface design and design schemes such as dependency injection, it solves the business problem of how to make functional modules general and loosely coupled with the framework, greatly reducing the usage and maintenance costs of the access party and reducing the internal complexity of the microservice development framework. At the same time, the present invention defines the aggregation definition of public interfaces for independent functions such as configuration update in the microservice development framework. When the plug-in implements these interface definitions, the framework can handle the corresponding logic to provide support for the independent update of the plug-in itself. In the face of specific business scenarios, the plug-in can ensure independent service provision without being affected by other businesses, decoupled from the business and other plug-ins.

Description

Technical Field

[0001] The present invention belongs to the field of microservice development frameworks, and particularly relates to a microservice development system with pluggable governance functions and an implementation method thereof. Background Art

[0002] A microservice refers to splitting a large single application and service into multiple manageable services without changing the function. Each service can select its own technology stack according to its needs, without mutual influence, which is convenient for development and maintenance. The advantage is that the application can be effectively split to achieve agile development and deployment. After microservice transformation, there will be intricate dependencies between services. For example, a front-end request generally depends on multiple back-end services. In an actual production environment, services are not always 100% reliable, and services may go wrong or experience delays. If an application cannot tolerate faults and isolate itself from the failures of its dependencies, then the application itself is at risk of being dragged down. When such requests increase and the computer resources occupied increase, it will lead to system bottlenecks, causing other requests to become unavailable as well, ultimately resulting in the collapse of the business system. To prevent such problems from occurring, microservices incorporate service governance-related strategies in their architectures, such as service rate limiting, degradation, circuit breaking, fault tolerance, etc. However, these governance strategies are highly coupled with the microservice code, making it necessary to modify the microservice code when modifying the microservice governance strategy. This also increases the difficulty of code maintenance and the complexity of operation and maintenance.

[0003] Since microservice development frameworks all need to introduce governance functions. Currently, there are two main solutions in the industry for "introducing new functions": directly integrating the function internally or passing parameters by calling an interface. Due to the aggregation characteristics of microservice clusters, the same governance function is often used in the same microservice cluster. The above two solutions generally have the following problems in this scenario: 1. Developers need to perceive and define the function implementation. If the governance functions held by microservice individuals in a large microservice cluster are the same, it is unnecessary for each microservice developer to perceive and define this level of function implementation. Since each function requires developers to use a large amount of processing logic at the code level, and sometimes for general concepts, business encapsulation is also carried out, increasing the understanding cost of different microservices. 2. When the function is integrated internally, when the current function technology selection does not conform to the business status quo, it is impossible to conveniently complete the replacement of a single function. 3. For different microservice development frameworks, if the function registration methods are different, when switching frameworks, there is a scenario where the function implementation needs to be rewritten, increasing the development cost.

[0004] Currently, there is no standard and effective solution for the dependencies of plugins. In the industry, developers can only handle the initialization logic by passing parameters on their own. This very easily couples the logic with the framework. For developers, they also need to pay attention to the lifecycle of the plugins, and the problem of decoupling or using loose coupling of plugin dependencies cannot be solved. Summary of the Invention

[0005] The purpose of the present invention is to provide a microservice development system and implementation method with pluginized governance functions, which can simultaneously meet the unified definition and convenient replacement of microservice governance functions, and support the independent use of governance function modules from the microservice development framework.

[0006] To achieve the above purpose, the technical solution adopted by the present invention is:

[0007] A microservice development system with pluginized governance functions, which includes a network layer, a governance function layer, and an infrastructure layer;

[0008] During the operation of the microservice development system, the network layer undertakes the inflow of actual network requests and passes them down to the governance function layer;

[0009] The infrastructure layer includes infrastructure instances and a constructor pool; the constructor pool stores the function methods of all plugin constructors and infrastructure constructors. The plugin constructors and infrastructure constructors refer to constructor methods that can have input parameter dependencies and return values; the function methods stored in the constructor pool are uniformly used for dependency injection and instance generation using the fx framework during the startup process of the microservice development system; the plugins generated by the plugin constructor functions will be placed in the corresponding function modules of the governance function layer, and the infrastructure instances generated by the infrastructure constructors will be placed in the infrastructure layer; during the startup process of the microservice development system, the infrastructure layer generates the plugins or infrastructure instances required by each function module through the constructor pool;

[0010] The governance function layer includes multiple function modules, and each function module includes multiple plugins; during the operation of the microservice development system, the governance function layer provides corresponding governance functions for the service by means of middleware, configuration callbacks, or directly providing instances;

[0011] Based on the implementation characteristics of the governance function, each function module splits the governance function into different aggregations to be used in cooperation with plugins. By defining a unified interface for the plugin, the specific behavior of a certain type of plugin is defined, and each function module has a relatively independent interface definition;

[0012] The plug-in refers to the aggregation for providing services within each functional module, including middleware logic and the logic triggered when configuration changes. Each plug-in has independent configuration and independent invocation logic; the logics in each plug-in are relatively independent and do not depend on each other; each plug-in is loaded into different microservice development systems as middleware or an independent function;

[0013] The behavior refers to the interface definition of the functional module, which is used to represent the specific implementation interface of a certain plug-in instance;

[0014] The governance function layer in the microservice development system is split into different functional modules, and unified interface definitions are provided for multiple plug-ins. When developing a certain plug-in, according to the functional characteristics involved in the plug-in, select the associated functional module interface behavior for implementation, load it into the corresponding functional module, and finally register the functional module into the framework to complete the access of the function.

[0015] An implementation method of a microservice development system with plug-in governance functions, which is implemented based on the above-mentioned microservice development system. The method includes a registration step and a running step; the registration step is as follows:

[0016] (1) The microservice development system provides a registration constructor behavior externally;

[0017] The registration constructor behavior refers to injecting a plug-in constructor or an infrastructure constructor with a specified signature into the corresponding constructor in the infrastructure layer through the interface provided by the microservice development system to complete the registration;

[0018] (2) The infrastructure layer processing step;

[0019] The infrastructure layer injects the registered plug-in constructor into the constructor pool inside the development framework. All registered plug-in constructor pointers and infrastructure constructor pointers on the corresponding plug-in constructor signatures are stored in this constructor pool;

[0020] All constructor pointers in the constructor pool are processed using the fx open-source dependency injection framework to complete the initialization process of the constructors; when the constructor pool is processed by the fx dependency injection framework, the return values of the function pointers of all constructors are given instance values, and these instances can be used for function calls; this fx open-source dependency injection framework is an application framework that performs topological sorting on all registered constructors according to the dependency relationships on the function signatures and calls them for initialization in sequence;

[0021] (3) The governance function layer processing step;

[0022] The governance function layer performs function call injection on the existing instances returned by various plugin constructors to inject the corresponding function modules, and completes the calls of the plugin instances to the methods of various implemented function modules;

[0023] The running steps are as follows:

[0024] The plugins that have been registered in all the function modules of the microservice development system use the data of the network layer that provides the external routing service to externally implement the corresponding function services;

[0025] When the microservice development system is running and a user request enters, it first enters the network layer for processing, and then enters the middleware function processing. Through the infrastructure layer of the microservice development system, an infrastructure instance is obtained, and the infrastructure instance is loaded or operated in the middleware extended function; after the middleware extended function is processed, it enters the business through the middleware behavior interface of the plugin, and the plugin instance is obtained or the plugin instance is operated according to the operation business logic in the function governance layer for processing; after the business processing is completed, the data is returned, and the final processing of the middleware is completed. Subsequently, a response is returned to the user via the network layer. Among them, obtaining an instance or operating an instance is processed through the function governance layer, and the configuration update is an asynchronous operation, and the updated object will replace the old object.

[0026] The present invention adopts the implementation method of plugins, and through object-oriented interface design and design schemes such as dependency injection, solves the business problem of how to make function modules general and loosely coupled with the framework, greatly reduces the use and maintenance costs of the access party, and at the same time reduces the internal complexity of the microservice development framework.

[0027] The present invention provides a plugin concept based on object-oriented design at the framework level, which is used to carry the main function aggregation of the microservice development framework. By estimating that the functions inside the microservice development framework are roughly divided into several function modules, the corresponding function modules are designed in an object-oriented style, and the interfaces corresponding to the function modules are defined. When the interface definitions of the function modules are determined, a module division based on function types will be formed.

[0028] The present invention also proposes to introduce the concept of dependency injection at the framework level. Through the open-source dependency injection fx framework, the injection of plugin instances is disassembled from the specific dependency logic in the plugin, allowing developers to call the injection interface, and pass the constructor of the dependency object and the constructor of the plugin into the framework internal (the provide concept in the fx framework), and then assign values by passing in the specified object (the populate concept in the fx framework). Furthermore, instead of directly obtaining the plugin instance through an interface call, the instance is obtained in a decoupled manner for various logical processes.

[0029] The present invention divides and unifies the definition of plugins based on the concept of functional modules. Since the unified interface definition of the plugins included in the functional modules in the microservice development framework, the microservice development framework can conveniently replace the plugins through the functional module interfaces, and can uniformly maintain the developed plugins to achieve the aggregation of business technologies. When developing a certain plugin, according to the functional characteristics involved in the plugin, select the associated functional module interface behavior to implement and register it into the framework, and the function access can be completed. When it is necessary to replace or delete a function, modify the logic of whether the corresponding plugin implementation is registered, and the logic of rapid replacement can be completed.

[0030] The present invention defines the aggregation definition of public interfaces for independent functions such as configuration update in the microservice development framework. When the plugin implements these interface definitions, the framework can handle the corresponding logic to provide support for the independent update of the plugin itself. In the face of specific business scenarios, the plugin can ensure the independent provision of services and is not affected by other businesses, decoupled from the business and other plugins. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 is the framework structure diagram of the microservice development framework of the present invention;

[0032] Figure 2 is the schematic diagram of the principle of defining the governance function module of the microservice development framework of the present invention;

[0033] Figure 3 is the schematic diagram of the specific process of registering plugins of the present invention;

[0034] Figure 4 is the schematic diagram of the operation process of the microservice development framework of the present invention;

[0035] Figure 5 is the schematic diagram of registering the interface of the functional module definition into the microservice development framework of the present invention.

[0036] The following further details the present invention in conjunction with the accompanying drawings and specific embodiments. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0037] As Figure 1 shown, the microservice development framework of the present invention includes a network layer, a governance function layer, and an infrastructure layer, where:

[0038] During the operation of the microservice development framework, the network layer undertakes the inflow of actual network requests and passes them down to the governance function layer.

[0039] The infrastructure layer includes infrastructure instances and a constructor pool; the constructor pool stores the functional methods of all plugin constructors and infrastructure constructors; the constructor refers to a constructor method that can have input parameter dependencies and has a return value. For example, a plugin creation method with an input parameter dependency of A and a return value of B plugin means a constructor function method for the B plugin that depends on A; the functional methods stored in the constructor pool are uniformly used for dependency injection and instance generation using the fx framework during the startup process of the microservice development framework; the plugins generated by the plugin constructors will be placed in the corresponding functional modules of the governance function layer, and the infrastructure instances generated by the infrastructure constructors will be placed in the infrastructure layer; during the startup process of the microservice development framework, the infrastructure layer generates the plugins or infrastructure instances required by each functional module through the constructor pool.

[0040] The governance function layer includes several functional modules, and each functional module includes several plugins; during the running process of the microservice development framework, the governance function layer provides corresponding governance functions for the service through middleware, configuration callbacks, or directly providing instances, etc. For example, a link tracing plugin in the functional module is generated through the constructor pool, and the link tracing function is provided through the middleware. The governance functions include specific behaviors such as middleware functions or instance functions. As long as a certain behavior is defined in the functional module and the plugin can implement this behavior, this behavior is regarded as a governance function. For example, the two behaviors of registering configuration nodes and listening for configuration node callbacks correspond to two functional methods respectively. When the plugin implements these two functional methods, it means that the plugin has these two behaviors and can provide the two governance functions of registering configuration nodes and listening for configuration node callbacks.

[0041] Based on the implementation characteristics of the governance function, the governance function is split into different aggregations to be used in cooperation with the plugins. By defining a unified interface for the plugins, the specific behaviors of a certain type of plugin are defined. Each functional module has a relatively independent interface definition and can set the content of the functional module according to the actual demand scenario. As Figure 5 shown, the governance function modules include a configuration module, a service registration module, a service discovery module, a service governance high-availability module, etc. used by the microservice development framework.

[0042] The plugin refers to the aggregation used to provide services within each functional module, including middleware logic and the logic triggered when the configuration changes. Each plugin has an independent configuration and an independent call logic. The logics in each plugin are relatively independent, and the plugins do not depend on each other and can be added or deleted. According to the different functions implemented by each functional module, the specific logic inside the plugin is different to implement different behaviors. The same plugin can simultaneously meet the behavior definitions of multiple functional modules and be loaded into different functional modules. Each plugin can be loaded into different microservice development frameworks as middleware or an independent function.

[0043] As Figure 2 shown, the behavior refers to the interface definition of the functional module, which is used to represent the specific implementation interface of a certain plugin instance. The governance function layer in the microservice development framework is split into different functional modules to unify the interface definition for multiple plugins. When developing a certain plugin, according to the functional characteristics involved in the plugin, select the relevant functional module interface behavior for implementation, load it into the corresponding functional module, and finally register the functional module into the framework to complete the access of the function.

[0044] As Figure 3 shown, an implementation method of a microservice development framework with pluggable governance functions of the present invention includes the following steps:

[0045] (1) The microservice development framework provides a registration constructor behavior externally;

[0046] The registration constructor behavior refers to injecting a plugin constructor or infrastructure constructor with a specified signature into the corresponding constructor in the infrastructure layer through the interface provided by the microservice development framework to complete the registration.

[0047] When developing a certain plugin, according to the functional characteristics involved in the plugin, select the relevant functional module interface behavior for implementation, register the plugin into the corresponding plugin constructor in the framework, and the access of the function can be completed. When it is necessary to replace or delete the function, modify the registration logic of the corresponding plugin implementation to quickly replace or delete the plugin; because this microservice development framework only defines the access of the interface specification plugin, this plugin can have independent configuration and independent call logic, and can be loaded into different microservice development frameworks as middleware or other independent functions;

[0048] (2) Infrastructure layer processing steps;

[0049] The infrastructure layer injects the registered plugin constructors into the constructor pool inside the development framework. All registered plugin constructor pointers and the infrastructure constructor pointers on the corresponding plugin constructor signatures are stored in this constructor pool. All the constructor pointers in the constructor pool are processed using the fx open-source dependency injection framework to complete the initialization process of the constructors. After the constructor pool is processed by the fx dependency injection framework, the return values of the function pointers of all constructors are given instance values, and these instances can be used for function calls. This fx open-source dependency injection framework is an application framework that performs a topological sort on all the registered constructors according to the dependency relationships on the function signatures and calls them for initialization in sequence. Since only the plugin constructors are passed in during the processing of the fx dependency injection framework, there is no need to first construct the underlying dependencies and then construct layer by layer upwards (for example, if C depends on B and B depends on A, the traditional approach is to first construct A, then construct B from A, and then construct C from B). In the present invention, the constructors of A, B, and C are directly passed into the constructor pool, and the fx open-source dependency injection framework completes the logical sorting. Then, the processing logics of A, B, and C on the outer layer are decoupled, thus achieving the decoupling between the instance constructors.

[0050] Through the way of dependency injection, the present invention enables the introduced plugin functions to be called or supplementary dependency content to be added. The plugin itself can have dependency content and complete the initialization creation through the way of dependency injection. When a configuration update is triggered, there is no need to stop the microservice from running. Since the plugin implements the agreed general configuration update interface, the infrastructure layer will perform a hot update during the microservice operation, regenerate new instances through callback of the configuration update interface and dependency injection, and replace the old instances.

[0051] (3) Processing steps of the governance function layer;

[0052] The governance function layer performs function call injection of corresponding functional modules on the existing instances returned by various plugin constructors to complete the calls of the plugin instances to the method of various implemented functional modules. For example, if plugin A implements the registration node interface of the defined configuration module, then the governance function layer will call this registration node interface to complete the function of registering the node. After the governance function layer completes all the function registrations, it will bind the registered functions, that is, various behaviors defined by each functional module, to the development framework to provide corresponding module functions, such as specific functional behaviors like registering nodes.

[0053] Since each instance generated by each plugin constructor is different and their implementations do not depend on each other, the functions corresponding to the plugins are independent and decoupled from each other and from the logic of the framework itself in the present invention.

[0054] In the present invention, the functional module defines a function method behavior as an interface. The plug-in only implements the function method behavior as an instance. When it is necessary to implement the parameter passing or storage function, the functional module is used as an interface to carry these plug-in instances that have implemented the function method. Thus, the classification of the plug-in instances can be completed by whether the function method is implemented;

[0055] The present invention introduces a design scheme of dependency injection in the microservice development framework, restricting the plug-ins exposed to the users (developers) to the plug-in constructors. This can effectively shield the users (developers) from the understanding of the plug-in implementation and only focus on the behavior of registering the plug-ins themselves. Then, through the dependency injection constructor pool, other objects required by the plug-in constructors can be initialized and constructed in the constructor pool, without considering the loading order and time point.

[0056] Such as Figure 4 shown, the plug-ins that have been registered in all functional modules of the microservice development framework use the network layer data providing the external routing service to externally implement the corresponding functional services.

[0057] The network layer data includes relevant parameters such as interface routing and interface processing logic, which are used to start the complete network service. Registering the network layer data behavior means that the network layer data accessed by the user network request is loaded into the microservice development framework after being processed by the network layer, and the listening for specific interfaces is implemented through the native net package of golang.

[0058] When the microservice development framework is running, when a user request enters, it will first enter the network layer for processing, and then enter the middleware function processing. Through the infrastructure layer of the microservice development framework, the infrastructure instance is obtained, and the infrastructure instance is loaded or operated in the middleware extended function. After the middleware extended function is processed, it enters the business through the middleware behavior interface of the plug-in, and the plug-in instance is obtained or the plug-in instance is operated for processing according to the operation business logic in the function governance layer. After the business processing is completed, the data is returned, and the final processing of the middleware is completed. Subsequently, a response is returned to the user via the network layer. Among them, obtaining the instance or operating the instance is all processed through the function governance layer, and the configuration update is an asynchronous operation, and the updated object will replace the old object, ensuring the characteristics of configuration hot update.

[0059] To better understand the above technical solution, an application scenario is used to assist in explaining the framework characteristics of the fast switching function brought by using dependency injection. For example, when microservice developers migrate the traffic limiting function from a certain implementation to the implementation of the open-source solution Sentinel, first determine that the traffic limiting function is middleware processing logic, that is, perform traffic limiting processing on requests. When traffic limiting, the microservice development framework directly intercepts and returns a response without entering the business processing, and classifies it into the service governance high-availability module class. When designing, developers only need to focus on the behavior of the plugin itself, shield the plugin implementation at the bottom layer, and users do not need to understand the plugin implementation. As long as they focus on the behavior of the plugin itself, the cost of migrating the original function can be reduced to only modifying one line of code to complete the processing. The following is the specific implementation in Golang code:

[0060] / / Assume the framework manager is app and has adopted the solution mentioned in the present invention

[0061] / / Under the original self-developed solution, register the plugin

[0062] app.RegisterPlugin(New)

[0063] / / Switch to the open-source solution implementation

[0064] app.RegisterPlugin(NewSentinel)

[0065] The present invention reasonably divides the functional modules, unifies the behavior of the plugin interfaces, reduces the design complexity, fits with the dependency injection solution, and is more convenient for managing the construction of instances. As Figure 5 shown, the functional modules provided by the microservice development framework of the present invention at least include a configuration module, a service registration module, a service discovery module, a service governance high-availability module, and a common interface definition module. For each functional module, specific behaviors need to be defined. When a plugin implements the behaviors corresponding to the functional module, it is considered that the plugin can provide the functions of the corresponding module. In the present invention, when constructing the functional module, developers can customize the specific behaviors of the module according to needs. For example, the specific behavior definitions of the above functional modules are:

[0066] The configuration module defines three main behaviors: initialization, registering the configuration callback of the specified node, and obtaining the configuration content of the specified node;

[0067] The service registration module defines two main behaviors: registering a service and unregistering a service;

[0068] The service discovery module defines three main behaviors: listening for a service, unregistering the listening service, and obtaining the information of the specified service;

[0069] The highly available module of service governance defines a main behavior of the middleware processing logic. Through the bounded context and the onion model, the middleware processing logic can complete the two-level logic processing of request entry and response return with only one function, thus reducing the interface definition of the middleware processing logic to the execution of a single function;

[0070] The common interface definition module adds three additional behaviors for the plug-ins to meet the characteristics of independent operation: configuration update, middleware processing logic, and instance acquisition. When a plug-in implements any of the above behaviors, it can provide support for developers to run the plug-in. The configuration update behavior can provide additional configuration content for the plug-in, decoupling the possible dependent content of the plug-in from the code. The middleware processing logic here is the same as the behavior defined by the highly available module of service governance and is an onion structure, which is convenient for developers to directly define behavior implementations. At the same time, it also prepares for future expansion of the behavior definition of the highly available module of service governance; The instance acquisition behavior is used to run the plug-in, so that the internally exposed instances can be returned to the caller through interface calls.

[0071] By defining the specific behaviors of the functional modules as the above content, the present invention reasonably divides the governance functions into different modules, processes the behaviors, and can directly replace the plug-ins that implement the same behaviors.

[0072] The plug-ins of the present invention can have independent configuration content. By implementing the configuration update callback interface (OnConfigUpdate) by the plug-ins themselves, the microservice development framework passes the corresponding configuration content to the plug-ins by calling this configuration callback interface, enabling the plug-ins to complete the initialization logic, making the configurable content of the plug-ins more independent, and eliminating the need to set plug-in function options by parameter passing. The configuration hot update feature of a single plug-in provides functional independence for the microservice development framework. Service maintenance personnel can control the functions inside a single plug-in by adjusting the configuration content without changing the code.

[0073] The present invention introduces plugins into the microservice development framework, thereby shielding the underlying implementation and only retaining the behavioral concept of registering objects for developers. Through solutions such as dependency injection and onion architecture design, the operation of calling interfaces is simplified, and the requirement of quickly migrating and converting microservice cluster functions in the current complex business scenarios can be fulfilled. At the same time, the simple division of the behavioral functions of the microservice development framework incorporates the main functions into four main functional modules and a common interface definition module. It is very convenient to implement the interfaces of the plugins. After the interfaces are implemented according to the above implementation steps, the source code of the plugins can be shared among different project groups, with sufficient independence and project aggregation characteristics, breaking the bottleneck that currently requires a set of implementations for each function in a project and resulting in high maintenance costs. The relatively independent functional characteristics of the plugins and the implementation of configuration callbacks also provide a more efficient method for developers to research and implement new technology stacks.

[0074] As described above, these are only embodiments of the present invention and do not impose any limitation on the technical scope of the present invention. Therefore, any minor modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention still fall within the scope of the technical solution of the present invention.

Claims

1. A microservice development system with pluggable governance functions, characterized in that: The microservice development system includes a network layer, a governance function layer, and an infrastructure layer; During the operation of the microservice development system, the network layer undertakes the inflow of actual network requests and passes them down to the governance function layer; The infrastructure layer includes infrastructure instances and a constructor pool; the constructor pool stores the function methods of all plugin constructors and infrastructure constructors. The plugin constructors and infrastructure constructors refer to constructor methods with input parameter dependencies and return values. The function methods stored in the constructor pool are uniformly used for dependency injection and instance generation using the fx framework during the startup process of the microservice development system; The plugins generated by the plugin constructors will be placed in the corresponding function modules of the governance function layer, and the infrastructure instances generated by the infrastructure constructors will be placed in the infrastructure layer. During the startup process of the microservice development system, the infrastructure layer generates the plugins or infrastructure instances required by each function module through the constructor pool; The governance function layer includes multiple function modules, and each function module includes multiple plugins. During the operation of the microservice development system, the governance function layer provides corresponding governance functions for the service through middleware, configuration callbacks, or directly providing instances; Based on the implementation characteristics of the governance function, the governance function is split into different aggregations to be used in cooperation with the plugins. By defining a unified interface for the plugin, the specific behavior of a certain type of plugin is defined, and each function module has a relatively independent interface definition; The plugin refers to the aggregation used to provide services within each function module, including middleware logic and the logic triggered when the configuration changes. Each plugin has an independent configuration and an independent call logic; the logic in each plugin is relatively independent, and the plugins do not depend on each other. Each plugin is loaded into different microservice development systems as middleware or an independent function; The behavior refers to the interface definition of the function module, which is used to represent the specific implementation interface of a certain plugin instance; The governance function layer in the microservice development system is split into different function modules, and a unified interface is defined for multiple plugins. When developing a certain plugin, according to the functional characteristics involved in the plugin, the associated function module interface behavior is selected for implementation, loaded into the corresponding function module, and finally the function module is registered into the system to complete the access of the function.

2. An implementation method of a microservice development system with governance function plug-in, characterized in that: The method is implemented based on the microservice development system described in claim 1, and it includes a registration step and a running step; the registration step is as follows: (1) The microservice development system externally provides a registration constructor behavior; The registration constructor behavior refers to injecting a plugin constructor or an infrastructure constructor with a specified signature into the corresponding constructor in the infrastructure layer through the interface provided by the microservice development system to complete the registration; (2) Infrastructure layer processing step; The infrastructure layer injects the registered plugin constructor into the constructor pool inside the development system. The constructor pool stores all the registered plugin constructor pointers and the infrastructure constructor pointers on the corresponding plugin constructor signatures; All constructor pointers in the constructor pool are processed using the fx open-source dependency injection framework to complete the initialization process of the constructors; After the constructor pool is processed by the fx dependency injection framework, the return values of the function pointers of all constructors are given instance values, and these instances can be used for function calls; the fx open-source dependency injection framework is an application framework that topologically sorts all registered constructors according to the dependency relationships in the function signatures and calls them for initialization in sequence; (3) Governance function layer processing steps; The governance function layer makes function calls to inject corresponding functional modules into the existing instances returned by various plugin constructors, completing the calls of the plugin instances to the methods of various implemented functional modules; The running steps are as follows: All registered plugins in the functional modules of the microservice development system use the data of the network layer that provides external routing services to externally implement corresponding functional services; During the operation of the microservice development system, when a user request enters, it first enters the network layer for processing, then enters the middleware function processing. Through the infrastructure layer of the microservice development system, an infrastructure instance is obtained, and the infrastructure instance is loaded or operated in the middleware extended function; after the middleware extended function is processed, it enters the business through the middleware behavior interface of the plugin, and the plugin instance is obtained or the plugin instance is operated according to the operation business logic in the functional governance layer for processing; after the business processing is completed, data is returned, and the final processing of the middleware is completed. Subsequently, a response is returned to the user via the network layer. Among them, obtaining an instance or operating an instance is all processed through the functional governance layer, and the configuration update is an asynchronous operation, and the updated object will replace the old object.

Images