WO2023098241A1

WO2023098241A1 - Request processing method and apparatus

Info

Publication number: WO2023098241A1
Application number: PCT/CN2022/120218
Authority: WO
Inventors: 陈劲豪
Original assignee: 深圳前海微众银行股份有限公司
Priority date: 2021-12-03
Filing date: 2022-09-21
Publication date: 2023-06-08
Also published as: CN114090193A

Abstract

The present invention relates to the field of Fintech. Disclosed are a request processing method and apparatus. The method comprises: for a received service request, determining an interface which corresponds to the service request; if it is determined that a dynamic proxy object is injected into the interface, determining a first implementation class of the interface from a preset routing relationship by means of a routing parameter in the service request and interface information of the interface; and processing the service request by means of an instance of the first implementation class. A routing relationship is described by using annotation technology, and on the basis of a dynamic proxy, the calling of an implementation object is routed without the need for compiling a factory class for each interface; and a service interface injected into a controller is replaced with a dynamic proxy object, such that an interface caller is as transparent as possible.

Description

A request processing method and device

Cross References to Related Applications

This application claims the priority of a Chinese patent application with application number 202111461675.2 and application title "A Method and Device for Request Processing" filed with the China Patent Office on December 03, 2021, the entire contents of which are hereby incorporated by reference in this application .

technical field

The embodiments of the present application relate to the field of financial technology (Fintech), and in particular, to a request processing method and device.

Background technique

With the development of computer technology, more and more technologies (such as cloud computing, big data or blockchain) are applied in the financial field, and the traditional financial industry is gradually transforming into financial technology. For example, based on the system architecture in which the server provides services to clients, banks can build relevant financial products and deploy them on the server, so that users can conveniently handle some financial services through their daily terminals, improving user experience.

Wherein, after receiving the user request, the server can execute the corresponding implementation method of the interface according to the routing parameters in the user request, so as to process the user request. For example, at present, when processing user requests, it can be realized through the factory design pattern. Specifically, the factory design pattern can return instances of different implementation classes of the same interface according to the routing parameters passed in by the front end, so as to achieve the effect of executing the corresponding method. As shown in Figure 1, it is a flow chart of the development of a factory design pattern provided by the prior art. Based on Figure 1, it can be seen that in the process of interface development, if the factory design pattern is used, it is necessary to write a factory class for each interface, which obviously makes the development and maintenance work cumbersome; in addition, when the developed interface is called, You need to manually obtain the routing parameters from the request first, and then obtain the instance explicitly, which obviously costs a lot.

Contents of the invention

The present application provides a request processing method and device, which are used to simplify the complexity of interface development and maintenance, and to be as transparent as possible to the controller when processing the request.

In the first aspect, the embodiment of the present application provides a request processing method, which is applicable to the Spring open source framework; the method includes: for the received service request, determining the interface corresponding to the service request; if it is determined that the injection in the interface is dynamic Proxy object, then through the routing parameters in the business request and the interface information of the interface, determine the first implementation class of the interface from the preset routing relationship; wherein, the dynamic proxy object is the Spring container based on the modeling object BeanDefinition obtained by instantiating the factory object FactoryBean in ; the preset routing relationship is set with a mapping relationship between routing parameters+interface information and implementation class; the service request is processed through the instance of the first implementation class.

In the above solution, by using annotation technology to describe the routing relationship, based on dynamic proxy, the call of the implementation object is routed, without writing a factory class for each interface; and, by replacing the service interface injected by the controller with a dynamic proxy object, the realization To be as transparent as possible to the interface caller.

In a possible implementation method, the dynamic proxy object is obtained by the Spring container based on the instantiation of the factory object FactoryBean in the modeling object BeanDefinition, including: for any interface, if the interface is provided with an interface annotation, the The implementation class of the object Bean indicated by the BeanDefinition of the interface is changed to FactoryBean, and the interface information of the interface is transferred to the FactoryBean; the FactoryBean is used to instantiate the Bean to obtain the dynamic proxy object of the interface.

In the above solution, by modifying the implementation class of the object Bean indicated by the BeanDefinition of the interface with interface annotations to FactoryBean, and passing the interface information of the interface to FactoryBean, when the Spring container instantiates the bean, it can be used FactoryBean to instantiate the bean to obtain the dynamic proxy object of the interface. By processing business requests based on dynamic proxy objects, the controller can be as transparent as possible.

In a possible implementation method, the FactoryBean is used to instantiate the Bean to obtain the dynamic proxy object of the interface, including: setting the enabled state of the Primary parameter in the BeanDefinition; the Spring container is instantiating the Bean , based on the enabled state of the Primary parameter, instantiate the Bean through the FactoryBean to obtain the dynamic proxy object of the interface.

In the above scheme, before the Spring container instantiates the Bean, by setting the Primary parameter in the BeanDefinition to the enabled state, when the Bean is instantiated, the Spring container can use the FactoryBean to instantiate the Bean, that is, it can inject into the Spring container The dynamic proxy object of the interface, instead of injecting the specific implementation Bean based on BeanDefinition.

In a possible implementation method, it is determined whether the interface is provided with an interface annotation in the following manner, including: after the Spring container receives the startup instruction, it traverses each BeanDefinition through the package scanning technology; for any BeanDefinition, determine the BeanDefinition Whether the indicated Bean corresponds to an interface and whether there is an interface annotation; if it is determined that the Bean indicated by the BeanDefinition does not correspond to an interface, then determine whether the implementation class corresponding to the Bean indicated by the BeanDefinition includes class annotations.

In the above solution, for the scenario where an interface corresponds to at least two implementation classes, by adding annotations to the interface and the implementation class, it is possible to determine whether the Bean indicated by each BeanDefinition in the source code is Corresponding to the interface or implementation class, and when determining whether it is the corresponding interface or the corresponding implementation class, further determine whether the interface or implementation class has interface annotations or class annotations, so that for the next establishment of routing relationships and changes to the BeanDefinition of the interface where the interface annotation is located Each implementation class lays the foundation.

In a possible implementation method, the preset routing relationship is obtained in the following manner, including: for any implementation class, if the implementation class is set with class annotations, then traversing the various implementation classes implemented by the implementation class Interface; for any interface in each interface, if the interface is provided with an interface annotation, the routing relationship between the interface and the implementation class is constructed; the routing relationship between the interface and the implementation class is provided with the class annotation The routing parameters carried in + the mapping relationship between the interface information of the interface and the implementation class.

In the above scheme, by traversing the implementation classes and traversing the interfaces implemented by the implementation classes with class annotations set, if an interface is set with interface annotations, the routing relationship between the current interface and the current implementation class can be constructed, where the routing relationship Including the corresponding relationship between the interface and the implementation class, and the corresponding relationship between the routing parameters carried in the class annotation and the implementation class; based on the routing relationship built, when responding to user requests, you can quickly locate based on routing parameters and interface information The corresponding implementation class, and finally by calling the corresponding method of the implementation class, the user request can be processed.

In a possible implementation method, the dynamic proxy object obtains the routing parameters in the business request in the following manner, including: saving the routing parameters in the business request in the thread local variable ThreadLocal through aspect-oriented programming AOP In; the dynamic proxy object obtains the routing parameters in the service request from the ThreadLocal.

In the above solution, by saving the routing parameters in ThreadLocal through AOP technology, it is possible to avoid writing the acquisition logic of the routing field in each method of the controller.

In a possible implementation method, if it is determined that the injection in the interface is an implementation object, then obtain the second implementation class of the interface; the implementation object is obtained by the Spring container based on BeanDefinition instantiation, the The interface is in one-to-one correspondence with the second implementation class; the service request is processed through the instance of the second implementation class.

In the above solution, for the scenario where an interface corresponds to only one implementation class, during the startup process of the Spring container, if it is determined that an interface corresponds to only one implementation class through package scanning technology, there is no need to establish a routing relationship between the interface and the implementation class, and In the process of instantiating beans in the Spring container, the Spring container can directly instantiate a specific implementation Bean based on the BeanDefinition, that is, the implementation object. In this way, when a user requests to enter, the user request can be processed directly based on the second implementation class pointed to by the implementation object.

In the second aspect, the embodiment of the present application provides a request processing device, which is applicable to the Spring open source framework; the device includes: an interface determination unit, for determining the interface corresponding to the business request received; the implementation class determination unit , if it is determined that the injection into the interface is a dynamic proxy object, determine the first implementation class of the interface from the preset routing relationship through the routing parameters in the service request and the interface information of the interface; wherein , the dynamic proxy object is obtained by the Spring container based on the instantiation of the factory object FactoryBean in the modeling object BeanDefinition; the preset routing relationship is provided with a mapping relationship between routing parameters+interface information and implementation classes; The instance of the first implementation class processes the service request.

In a third aspect, the embodiment of the present application provides a computing device, including:

memory for storing program instructions;

The processor is configured to call the program instructions stored in the memory, and execute any implementation method according to the first aspect according to the obtained program.

In a fourth aspect, the embodiment of the present application provides a computer-readable storage medium, the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to make a computer execute any one of the implementations of the first aspect. method.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings that need to be used in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For Those skilled in the art can also obtain other drawings based on these drawings without any creative effort.

Fig. 1 is the development flow diagram of a kind of factory design mode that prior art provides;

FIG. 2 is a schematic diagram of a request processing method provided by an embodiment of the present application;

Fig. 3 is the flow chart of a kind of Spring container initialization that the embodiment of the present application provides;

FIG. 4 is a schematic diagram of a routing relationship configuration provided in an embodiment of the present application;

FIG. 5 is a schematic diagram of a request processing device provided by an embodiment of the present application;

FIG. 6 is a schematic diagram of a computing device provided by an embodiment of the present application.

Detailed ways

In order to make the purpose, technical solution and advantages of the application clearer, the application will be further described in detail below in conjunction with the accompanying drawings. Apparently, the described embodiments are only some of the embodiments of the application, not all of them. Based on the embodiments in this application, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the scope of protection of this application.

At present, the server can write different implementation classes for each interface based on the factory design pattern, so that when the server responds to user requests, it can return instances of different implementation classes of the same interface according to the parameters passed in from the front end. Then achieve the effect of executing the corresponding method.

However, in the process of interface development, the above method has the disadvantage of cumbersome development and maintenance due to the need to write a factory class for each interface. In addition, when the interface is called, it is first necessary to manually obtain the routing parameters, and then pass the routing parameters to the factory. To obtain the instance, and finally the caller of the instance can execute the corresponding method, so there is a disadvantage of not being transparent to the interface caller.

In view of the above technical problems, the embodiment of the present application provides a request processing method, which is applicable to the Spring framework. As shown in Figure 2, it is a schematic diagram of a request processing method provided by the embodiment of the present application, and the method includes the following steps:

Step 201, for the received service request, determine the interface corresponding to the service request;

Step 202, if it is determined that the injection into the interface is a dynamic proxy object, then determine the first implementation class of the interface from the preset routing relationship through the routing parameters in the service request and the interface information of the interface; Wherein, the dynamic proxy object is obtained by the Spring container based on the instantiation of the factory object FactoryBean in the modeling object BeanDefinition; the preset routing relationship is provided with routing parameters+interface information and the mapping relationship of the implementation class;

Step 203, process the service request through the instance of the first implementation class.

Some of the above steps will be described in detail below in combination with examples.

In some implementations of the present application, the Spring container traverses each BeanDefinition through package scanning technology after receiving the startup instruction; for any BeanDefinition, determine whether the Bean indicated by the BeanDefinition corresponds to an interface and whether there is an interface annotation; If the Bean indicated by the BeanDefinition does not correspond to an interface, determine whether the implementation class corresponding to the Bean indicated by the BeanDefinition includes class annotations.

In some implementations of the present application, for any implementation class, if the implementation class is set with class annotations, then traverse the interfaces implemented by the implementation class; for any interface in each interface, if the interface is set If there is an interface annotation, then construct the routing relationship between the interface and the implementation class; the routing relationship between the interface and the implementation class is set with the routing parameters carried in the class annotation + the interface information of the interface and the Realize the mapping relationship of classes.

In the embodiment of this application, the server uses the Spring open source framework as an example for illustration. In addition, interface annotations and class annotations can be designed in this embodiment of the application. As an example, the interface annotation can be expressed as @RouteInterface, and the class annotation can be expressed as @RouteImpl. These two designed annotations are respectively modified on the interface and implementation On the class, the annotation @RouteImpl will carry the set routing parameters. Through these two annotations, a routing relationship can be described, that is, when the user request contains setting routing parameters and calls the @RouteInterface annotated interface, it will actually call the @RouteImpl annotation that is the same as setting the routing parameters Implementation class. For the establishment of the routing relationship in the embodiment of the present application, when the Spring container is initialized, the package scanning technology can be used to read the annotation, so as to establish the routing relationship. The specific content is as follows:

The routing relationship is established in the life cycle BeanDefinitionRegistryPostProcessor started by the Spring container. Among them, the package scan traverses all the implementation classes in the source code, when encountering the implementation class α with @RouteImpl annotation, read the routing parameter β in the annotation, and traverse the interfaces implemented by the implementation class; when there is such When the interface γ implemented by the implementation class is annotated with @RouteInterface, the routing relationship (β, γ) -> α is established.

In some implementations of the present application, for any interface, if the interface is provided with interface annotations, the implementation class of the object Bean indicated by the BeanDefinition of the interface is modified to FactoryBean, and the FactoryBean is passed in the Interface information of the interface; the FactoryBean is used to instantiate the Bean to obtain the dynamic proxy object of the interface.

In some implementations of the present application, the FactoryBean is used to instantiate the Bean to obtain the dynamic proxy object of the interface, including: setting the enabled state of the Primary parameter in the BeanDefinition; the Spring container is instantiating the Bean , based on the enabled state of the Primary parameter, instantiate the Bean through the FactoryBean to obtain the dynamic proxy object of the interface.

During the initialization process of the Spring container, in addition to establishing the routing relationship, it is also necessary to register the dynamic proxy object Bean into the Spring container. Among them, registering the dynamic proxy object Bean into the Spring container is also carried out in the life cycle BeanDefinitionRegistryPostProcessor started by the Spring container. Since the life cycle is before the Spring instantiates the Bean, it is still allowed to modify the BeanDefinition at this time. Specifically, when registering the dynamic proxy object Bean in the Spring container, it can also use the package scanning technology to traverse, but this package scanning will traverse all the interfaces in the source code, when encountering the interface γ with @RouteInterface annotation , modify each implementation class in its BeanDefinition to the factory object FactoryBean one by one, and pass in the interface name, namely γ, to the FactoryBean, and set the Primary parameter to enable. Therefore, when Spring instantiates the Bean, it will instantiate the dynamic proxy object of the interface γ based on the FactoryBean.

The process of establishing the routing relationship described above and the process of registering the dynamic proxy object Bean into the Spring container can be visually displayed through the flowchart of Spring container initialization shown in Figure 3 . As shown in Figure 3, a flow chart of Spring container initialization provided by the embodiment of the present application includes the following steps:

Step 301, Spring container initialization starts.

In step 302, the package scans and traverses the BeanDefinition.

Step 303, determine the corresponding interface or implementation class of the Bean indicated by the current BeanDefinition. If the corresponding interface is determined, step 304 is performed; if the corresponding implementation class is determined, step 306 is performed.

Step 304, determine whether the current interface γ contains the annotation @RouteInterface. If it is determined that it is included, go to step 305 , otherwise go to step 310 .

Step 305 , modify the implementation class corresponding to the interface γ to the factory object FactoryBean, and pass the interface name γ into the FactoryBean, and execute step 310 .

Step 306, determine whether the current implementation class α contains the annotation @RouteImpl. If it is determined that it is included, go to step 307 , otherwise go to step 310 .

Step 307, traversing the interfaces realized by the implementation class α.

Step 308, determine whether the current interface γ contains the annotation @RouteInterface. If it is determined that it is included, go to step 309 , otherwise go to step 310 .

Step 309, read the routing parameter β in @RouteImpl to establish the routing relationship (β, γ)->α, and execute step 310.

Step 310, determine whether the packet scanning ends. If it is determined that it is not finished, then execute steps 302-310 again, otherwise, execute step 311.

In step 311, the initialization of the Spring container ends.

The following are some descriptions of the flowchart shown in FIG. 3 .

First, the operations corresponding to the flowchart shown in Figure 3 occur in the BeanDefinitionRegistryPostProcessor of the Spring lifecycle. Among them, in this life cycle, it is allowed to modify the BeanDefinition.

Secondly, the package scanning in step 302 can be implemented by inheriting and extending the ClassPathBeanDefinitionScanner class, which will scan the BeanDefinition in the ClassPath through the configured package path. The metadata of the class will be provided in the BeanDefinition. Since the metadata contains detailed parameters such as the interface properties and annotation information of the Bean implementation class, the branch judgment of

steps

303, 304, 306 and 308 can be completed according to the metadata during the package scanning process.

In addition, through

steps

304 and 305, the BeanDefinition of the interface γ annotated with @RouteInterface can be modified and registered in the Spring container. Specifically, each implementation class in the BeanDefinition of interface γ will be modified one by one into the factory object FactoryBean, so that FactoryBean can generate a dynamic proxy object that implements interface γ when instantiated, so that when the method of this object is called, the dynamic proxy The object can find the specific implementation bean according to the routing parameters and routing relationship, and call the bean's method with the same name. At the same time, the Primary parameter of the BeanDefinition of the factory object FactoryBean can be set to a high priority; thus when the Spring container instantiates the Bean, specifically when @Autowired injects the interface with the @RouteInterface annotation, due to the priority relationship, the injected It will be a dynamic proxy object instead of a specific implementation Bean.

Finally, the acquisition of the routing relationship can be completed through steps 306-309, that is, reflect the implementation class with @RouteImpl annotation to obtain its interface information and take out the routing parameters in the annotation, and judge whether the @RouteInterface annotation is attached to each interface. If it can be found, a routing relationship can be established.

Based on the above-described flow chart of dynamic proxy object call routing, the embodiment of the present application no longer needs to develop and maintain factories to handle the relationship between routing parameters and implementation classes, and the caller does not need to repeat routing parameters in the method. Get the implementation class, but by using the dynamic proxy object injected by Spring.

As an example, a specific example is used to describe the initialization of the Spring container.

As shown in FIG. 4 , it is a schematic diagram of routing relationship configuration provided by the embodiment of the present application. Based on the processing logic of each business, the design engineer configured the interface-implementation class correspondence as shown in Figure 4. In Figure 4, the upper line represents the implementation class, and it is assumed that there are 4 implementation classes, which are recorded as A1, A2, A3, and A4 respectively; the bottom line represents the interface, and it is assumed that it includes 6 interfaces, which are respectively recorded as C1, C2, and C3. , C4, C5 and C6.

Among them, through the observation of the corresponding relationship between the interface and the implementation class shown in Figure 4, it can be known that the following two situations are included:

Case 1, an interface corresponds to at least two implementation classes. For example, interface C2 corresponds to two implementation classes A1 and A2, and interface C4 corresponds to three implementation classes A2, A3, and A4.

In case 2, an interface corresponds to only one implementation class. For example, interfaces C1, C3, C5, and C6 respectively correspond to only one implementation class, namely A1, A2, A4, and A3.

Then, based on the interface-implementation class correspondence shown in Figure 4, the engineer will decorate the interface annotation @RouteInterface on interface C2 and interface C4 respectively, and the class annotation @RouteImpl on A1, A2, A3 and A4 respectively, However, the interface annotation @RouteInterface will not be modified on the interfaces C1, C3, C5, and C6 respectively. So:

When the Spring container is initialized, on the one hand, through the package scanning technology, when traversing the implementation classes and setting the traversal to the implementation class A1, since A1 is decorated with the annotation @RouteImpl, you can continue to traverse the interfaces implemented by A1 ; Among them, when traversing to the interface C2, since C2 is decorated with the annotation @RouteInterface, a routing relationship can be established: (β _A1 ,γ _C2 )->α _A1 .

Among them, β _A1 represents the routing parameters included in the annotation @RouteImpl of the implementation class A1, γ _C2 represents the interface C2 with the @RouteInterface annotation, and α _A1 represents the implementation class A1 with the @RouteImpl annotation.

Similarly, after the packet scanning, a total of 5 routing relationships can be obtained, namely: (β _A1 ,γ _C2 )->α _A1 , (β _A2 ,γ _C2 )->α _A2 , (β _A2 ,γ _C4 )->α _A2 , (β _A3 ,γ _C4 )->α _A3 and (β _A4 ,γ _C4 )->α _A4 .

However, for the interface C1 in Figure 4, since it only corresponds to the implementation class of A1, and has not been modified with the annotation @RouteInterface, there is no need to establish the route between C1-A1 after the packet scanning is completed. Routing relationship. Interfaces C3, C5 and C6 are the same as C1.

On the other hand, when the Spring container is initialized, through the package scanning technology, when traversing each interface and setting the traversal to interface C2, since C2 is decorated with the annotation @RouteInterface, each implementation class in its BeanDefinition can be modified For the factory object FactoryBean, and pass the name of the interface C2 to the FactoryBean, and at the same time set the Primary parameter of the FactoryBean in the BeanDefinition to the enabled state, so that when the Spring container instantiates the Bean after the package scanning is completed, the Spring container regarding the interface C2 What is injected is a dynamic proxy object, rather than a specific implementation Bean. For example, when traversing to the interface C2 decorated with the annotation @RouteInterface, the BeanDefinition corresponding to the interface C2 will include two implementation classes, namely the implementation classes A1 and A2, among which, for each implementation class, such as for A1, You can modify A1 to the factory object FactoryBean_A1, and pass the name of the interface C2 to FactoryBean_A1, and set the Primary parameter of FactoryBean_A1 in BeanDefinition to the enabled state, so that after the package scanning is completed, when the Spring container instantiates the bean, Spring What the container injects with respect to the interface C2 and the implementation class A1 is a dynamic proxy object instead of a specific implementation bean.

However, when traversing to interface C1, since there is no @RouteInterface annotation on C1, there is no need to modify the only implementation class in its BeanDefinition to the factory object FactoryBean; and, for this case, after the package scanning is completed, the Spring container When instantiating the Bean, the Spring container injects the interface C1 and the implementation class A1 into specific implementation beans.

In some implementations of the present application, the routing parameters in the business request are saved in the thread local variable ThreadLocal through aspect-oriented programming AOP; the dynamic proxy object obtains the routing in the business request from the ThreadLocal parameter.

The runtime dynamic proxy object needs to determine the implementation class according to the routing parameters and routing relationship. Since the Spring container startup process has obtained the routing relationship, the routing parameters need to be obtained next. Route parameters will contain route fields. In order to avoid writing routing field acquisition logic in each method of the controller, the embodiment of the present application uses AOP technology to process user requests, and uniformly saves routing parameters in ThreadLocal.

When the specified service interface is injected into the controller, that is, the interface with interface annotations, because the BeanDefinition is modified and the priority relationship brought by the Primary parameter, the dynamic proxy object is actually injected. The controller will call the method in the service interface during the process of processing the client request, which will be handled by the dynamic proxy object at this time. The original interface information γ is saved in the dynamic proxy object, and the routing parameter β is taken out from ThreadLocal, and the implementation object is obtained according to the routing rule (β, γ)->α, and the method with the same name is called through reflection technology.

For example, based on the interface-implementation class correspondence shown in Figure 4, when the interface corresponding to the received service request is C2, since C2 is configured with two implementation classes A1 and A2, C2 is decorated with the annotation @ RouteInterface, which shows that when the Spring container instantiates the Bean, the Spring container injects the dynamic proxy object into the interface C2; at this time, it is assumed that the dynamic proxy object obtains β _A1 for the routing parameters stored in the ThreadLocal of the business request , it means that the dynamic proxy object can find the specific implementation bean according to the routing parameter β _A1 and the routing relationship (β _A1 , γ _C2 ) -> α _A1 , and call the method of the same name of the bean to process the service request.

In some implementations of the present application, if it is determined that the injection in the interface is an implementation object, obtain the second implementation class of the interface; the implementation object is obtained by instantiating the Spring container based on BeanDefinition, and the interface One-to-one correspondence with the second implementation class; the service request is processed through the instance of the second implementation class.

For a business request, if the interface corresponding to the business request is not the specified service interface injected in the controller, that is, the interface does not have interface annotations, then it may be because the interface is actually injected during the instantiation process of the interface. To implement the Bean, the controller can directly call the implementation class corresponding to the implemented Bean to process the service request.

For example, based on the interface-implementation class correspondence shown in Figure 4, when the interface corresponding to the received service request is C1, since C1 is only configured with an implementation class of A1, C1 is not modified with the annotation @RouteInterface , which shows that when the Spring container instantiates the Bean, the Spring container injects the specific implementation Bean (implementation object) about the interface C1, so the controller can directly call the instance of the implementation class (ie A1) of the interface C1 to implement the business The request is processed.

Based on the same idea, the embodiment of the present application provides a request processing device, which is applicable to the Spring open source framework. As shown in FIG. 5 , it is a schematic diagram of a request processing device provided in the embodiment of the present application, which includes an interface determination unit 501, an implementation class determination unit 502, and a processing unit 503;

An interface determining unit 501, configured to determine an interface corresponding to the service request for the received service request;

The implementation class determination unit 502 is configured to determine the first route of the interface from the preset routing relationship through the routing parameters in the service request and the interface information of the interface if it is determined that the injection into the interface is a dynamic proxy object. An implementation class; wherein, the dynamic proxy object is obtained by the Spring container based on the instantiation of the factory object FactoryBean in the modeling object BeanDefinition; the preset routing relationship is provided with routing parameters+interface information and the mapping relationship of the implementation class;

The processing unit 503 is configured to process the service request through the instance of the first implementation class.

Further, for the device, it also includes a dynamic proxy object generation unit 504; the dynamic proxy object generation unit 504 is configured to: for any interface, if the interface is provided with an interface annotation, the object indicated by the BeanDefinition of the interface The implementation class of the Bean is changed to FactoryBean, and the interface information of the interface is transferred to the FactoryBean; the FactoryBean is used to instantiate the Bean to obtain a dynamic proxy object of the interface.

Further, for this device, the dynamic proxy object generation unit 504 is specifically used to: set the enabled state of the Primary parameter in the BeanDefinition; when the Spring container instantiates the Bean, based on the enabled state of the Primary parameter, through The FactoryBean instantiates the Bean to obtain the dynamic proxy object of the interface.

Further, for the device, an annotation determination unit 505 is also included; the annotation determination unit 505 is used for: after the Spring container receives the startup instruction, it traverses each BeanDefinition through the package scanning technology; for any BeanDefinition, determine the BeanDefinition indicated by the BeanDefinition Whether the Bean corresponds to the interface and whether there is an interface annotation; if it is determined that the Bean indicated by the BeanDefinition does not correspond to the interface, then determine whether the implementation class corresponding to the Bean indicated by the BeanDefinition includes class annotations.

Further, for the device, it also includes a routing relationship acquisition unit 506; the routing relationship acquisition unit 506 is configured to: for any implementation class, if the implementation class is provided with class annotations, then traverse each implementation class implemented by the implementation class Interface; For any interface in each interface, if the interface is provided with an interface annotation, then construct the routing relationship between the interface and the implementation class; the routing relationship between the interface and the implementation class is set with the class annotation The routing parameters carried in + the mapping relationship between the interface information of the interface and the implementation class.

Further, for the device, it also includes a routing parameter acquisition unit 507; the routing parameter acquisition unit 507 is used to: save the routing parameters in the service request in the thread local variable ThreadLocal through the aspect-oriented programming AOP; the dynamic The proxy object obtains the routing parameters in the service request from the ThreadLocal.

Further, for this device, the implementation class determination unit 502 is also used for: if it is determined that the injection in the interface is an implementation object, obtain the second implementation class of the interface; the implementation object is the Spring container based on BeanDefinition obtained by instantiation, the interface is in one-to-one correspondence with the second implementation class; the processing unit is further configured to process the service request through the instance of the second implementation class.

The embodiment of the present application also provides a computing device, which may specifically be a desktop computer, a portable computer, a smart phone, a tablet computer, a personal digital assistant (Personal Digital Assistant, PDA), etc. The computing device may include a central processing unit (Center Processing Unit, CPU), memory, input/output devices, etc., the input device may include a keyboard, mouse, touch screen, etc., and the output device may include a display device, such as a liquid crystal display (Liquid Crystal Display, LCD), cathode ray tube (Cathode Ray Tube, CRT), etc.

The memory, which may include read-only memory (ROM) and random-access memory (RAM), provides the processor with program instructions and data stored in the memory. In the embodiment of the present application, the memory may be used to store program instructions of the request processing method;

The processor is configured to call the program instructions stored in the memory, and execute the request processing method according to the obtained program.

As shown in FIG. 6, it is a schematic diagram of a computing device provided in the embodiment of the present application. The computing device includes:

A processor 601, a memory 602, a transceiver 603, and a bus interface 604; wherein, the processor 601, the memory 602, and the transceiver 603 are connected through a bus 605;

The processor 601 is configured to read the program in the memory 602, and execute the above request processing method;

The processor 601 may be a central processing unit (central processing unit, CPU for short), a network processor (network processor, NP for short), or a combination of CPU and NP. It may also be a hardware chip. The aforementioned hardware chip may be an application-specific integrated circuit (ASIC for short), a programmable logic device (PLD for short), or a combination thereof. The above-mentioned PLD can be a complex programmable logic device (complex programmable logic device, CPLD for short), a field-programmable gate array (field-programmable gate array, FPGA for short), a generic array logic (generic array logic, GAL for short) or any combination.

The memory 602 is used to store one or more executable programs, and may store data used by the processor 601 when performing operations.

Specifically, the program may include program code, and the program code includes computer operation instructions. The memory 602 may include a volatile memory (volatile memory), such as a random-access memory (random-access memory, RAM for short); the memory 602 may also include a non-volatile memory (non-volatile memory), such as a flash memory ( flash memory), hard disk (hard disk drive, referred to as HDD) or solid-state drive (solid-state drive, referred to as SSD); the memory 602 may also include a combination of the above-mentioned types of memory.

The memory 602 stores the following elements, executable modules or data structures, or their subsets, or their extended sets:

Operation instructions: include various operation instructions for realizing various operations.

Operating system: includes various system programs for implementing various basic services and processing hardware-based tasks.

The bus 605 may be a peripheral component interconnect standard (PCI for short) bus or an extended industry standard architecture (EISA for short) bus or the like. The bus can be divided into address bus, data bus, control bus and so on. For ease of representation, only one thick line is used in FIG. 6 , but it does not mean that there is only one bus or one type of bus.

The bus interface 604 may be a wired communication access interface, a wireless bus interface or a combination thereof, wherein the wired bus interface may be, for example, an Ethernet interface. The Ethernet interface can be an optical interface, an electrical interface or a combination thereof. The wireless bus interface may be a WLAN interface.

The embodiment of the present application also provides a computer-readable storage medium, where the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to cause a computer to execute the request processing method.

Those skilled in the art should understand that the embodiments of the present application may be provided as methods or computer program products. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present application is described with reference to flowcharts and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present application. It should be understood that each procedure and/or block in the flowchart and/or block diagram, and a combination of procedures and/or blocks in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions may be provided to a general purpose computer, special purpose computer, embedded processor, or processor of other programmable data processing equipment to produce a machine such that the instructions executed by the processor of the computer or other programmable data processing equipment produce a An apparatus for realizing the functions specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture comprising instruction means, the instructions The device realizes the function specified in one or more procedures of the flowchart and/or one or more blocks of the block diagram.

These computer program instructions can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby The instructions provide steps for implementing the functions specified in the flow chart or blocks of the flowchart and/or the block or blocks of the block diagrams.

While preferred embodiments of the present application have been described, additional changes and modifications can be made to these embodiments by those skilled in the art once the basic inventive concept is appreciated. Therefore, the appended claims are intended to be construed to cover the preferred embodiment and all changes and modifications which fall within the scope of the application.

Obviously, those skilled in the art can make various changes and modifications to the application without departing from the spirit and scope of the application. In this way, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these modifications and variations.

Claims

A kind of request processing method is characterized in that, is applicable to Spring open source framework; Described method comprises:

For the received service request, determine the interface corresponding to the service request;

If it is determined that the injection into the interface is a dynamic proxy object, then determine the first implementation class of the interface from the preset routing relationship through the routing parameters in the service request and the interface information of the interface; wherein, dynamic The proxy object is instantiated by the Spring container based on the factory object FactoryBean in the modeling object BeanDefinition; the preset routing relationship is provided with a mapping relationship between routing parameters+interface information and implementation classes;

The service request is processed through the instance of the first implementation class.
The method of claim 1, wherein

The dynamic proxy object is obtained by the Spring container based on the instantiation of the factory object FactoryBean in the modeling object BeanDefinition, including:

For any interface, if the interface is provided with interface annotations, then the implementation class of the object Bean indicated by the BeanDefinition of the interface is modified to FactoryBean, and the interface information of the interface is passed in to the FactoryBean; Obtain the dynamic proxy object of the interface by instantiating the bean.
The method according to claim 2, wherein said FactoryBean is used to instantiate said Bean to obtain a dynamic proxy object of said interface, comprising:

Set the enabled state of the Primary parameter in the BeanDefinition;

When instantiating the Bean, the Spring container instantiates the Bean through the FactoryBean based on the enabled state of the Primary parameter to obtain the dynamic proxy object of the interface.
The method according to claim 2, wherein determining whether the interface is provided with an interface annotation is performed in the following manner, comprising:

After the Spring container receives the startup command, it traverses each BeanDefinition through the package scanning technology; for any BeanDefinition, it is determined whether the Bean indicated by the BeanDefinition corresponds to the interface and whether there is an interface annotation;

If it is determined that the Bean indicated by the BeanDefinition does not correspond to an interface, it is determined whether the implementation class corresponding to the Bean indicated by the BeanDefinition includes a class annotation.
The method of claim 1, wherein

The preset routing relationship is obtained through the following methods, including:

For any implementation class, if the implementation class is provided with class annotations, then traverse each interface implemented by the implementation class;

For any interface in each interface, if the interface is provided with an interface annotation, then construct the routing relationship between the interface and the implementation class; the routing relationship between the interface and the implementation class is set to be carried in the class annotation routing parameters + the mapping relationship between the interface information of the interface and the implementation class.
The method according to any one of claims 1-5, characterized in that,

The dynamic proxy object obtains the routing parameters in the service request through the following methods, including:

By aspect-oriented programming AOP, the routing parameters in the service request are stored in the thread local variable ThreadLocal;

The dynamic proxy object obtains the routing parameters in the service request from the ThreadLocal.
The method of claim 1, further comprising:

If it is determined that the injection in the interface is an implementation object, then obtain the second implementation class of the interface; the implementation object is obtained by the Spring container based on BeanDefinition instantiation, and the interface is the same as the second implementation class one-to-one correspondence;

The service request is processed through the instance of the second implementation class.
A kind of request processing device is characterized in that, is applicable to Spring open source framework; Described device comprises:

An interface determination unit, configured to determine an interface corresponding to the service request for the received service request;

An implementation class determining unit, configured to determine the first route of the interface from the preset routing relationship through the routing parameters in the service request and the interface information of the interface if it is determined that the injection into the interface is a dynamic proxy object. An implementation class; wherein, the dynamic proxy object is obtained by the Spring container based on the instantiation of the factory object FactoryBean in the modeling object BeanDefinition; the preset routing relationship is provided with routing parameters+interface information and the mapping relationship of the implementation class;

A processing unit, configured to process the service request through the instance of the first implementation class.
A computer device, characterized in that it includes:

memory for storing computer programs;

A processor, configured to call the computer program stored in the memory, and execute the method according to any one of claims 1-7 according to the obtained program.
A computer-readable storage medium, wherein the storage medium stores computer-executable instructions, and the computer-executable instructions are used to cause a computer to execute the method according to any one of claims 1-7.