Request processing method, apparatus, and electronic device

Abstract

The present specification relates to the technical field of financial technology, and particularly relates to a request processing method and device and electronic equipment. The request processing method comprises the following steps: obtaining a target routing strategy adapted to a received service request; extracting feature data of the service request; matching a target function module in a function module set according to the feature data and the target routing strategy; and processing the service request through the target function module. The embodiments of the present specification can decouple the configuration of the routing strategy and the function module. The execution of the function module is no longer strongly dependent on the identification result of the service request by the routing strategy. The service gateway can provide different function supports to different service requests in units of function modules, thereby enhancing the service providing capability under a complex application architecture.

Description

Technical Field

[0001] This specification relates to the field of financial technology, and in particular to a request processing method, apparatus, and electronic device. Background Technology

[0002] With the rise of microservice architecture, diverse use cases and varying server requirements have led to challenges such as high complexity and high throughput demands on the server side. To address these challenges, service gateway technology has emerged.

[0003] In existing technologies, business personnel can configure routing rules and one or more extended functions for the routing rules in the service gateway based on their own experience. This enables the service gateway to serve as a unified entry point for multiple servers, providing a unified entry service for terminal devices, and also offering extended capabilities such as request routing, load balancing, and security protection.

[0004] Business users configure the hierarchy between routing rules and extended functions in the service gateway based on their own experience. This results in a rigid and inflexible relationship between routing rules and extended functions, making it unsuitable for the increasingly complex use cases in a microservice architecture. Summary of the Invention

[0005] This specification provides a request processing method, apparatus, and electronic device to improve the accuracy and flexibility of a service gateway in processing business requests and enhance its adaptability to complex usage scenarios.

[0006] This specification provides an embodiment of a request processing method, including:

[0007] Obtain the target routing strategy that is appropriate for the received business request;

[0008] Extract the feature data of the business request;

[0009] Based on feature data and target routing strategy, match the target functional module in the functional module set;

[0010] The business request is processed through the target functional module.

[0011] This specification also provides a request processing apparatus, including:

[0012] The acquisition unit is used to acquire the target routing strategy that is adapted to the received business request.

[0013] Extraction unit, used to extract feature data of the service request;

[0014] The matching unit is used to match the target functional module in the functional module set based on feature data and target routing strategy;

[0015] The processing unit is used to process the business request through the target functional module.

[0016] This specification also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described request processing method.

[0017] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described request processing method.

[0018] This specification also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described request processing method.

[0019] The request processing method described in this specification can obtain the target routing strategy adapted to the received business request; extract the feature data of the business request; match a target functional module in a set of functional modules based on the feature data and the target routing strategy; and process the business request through the target functional module. This decouples the routing strategy from the functional modules. For a given business request, after matching the target routing strategy, the processing is not based on a set of fixed functional modules pre-configured for the target routing strategy, but rather on selecting a target functional module from the set of functional modules based on the feature data of the business request and the matched target routing strategy. This allows the service gateway to provide different functional support to different business requests on a module-by-module basis, no longer solely relying on the hierarchical relationship between the routing strategy and functional modules. This enables the service gateway to support more flexible and complex usage scenarios, enhancing its ability to provide services in complex application architectures. Attached Figure Description

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

[0021] Figure 1 This diagram illustrates the coupling relationship between routing rules and extended functions in existing technologies.

[0022] Figure 2This is a flowchart illustrating the request processing method in the embodiments of this specification;

[0023] Figure 3 This is a schematic diagram of the request processing system in the embodiments of this specification;

[0024] Figure 4 This is a schematic diagram of the request processing procedure in the embodiments of this specification;

[0025] Figure 5 This is a schematic diagram of the request processing device in the embodiments of this specification. Detailed Implementation

[0026] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. The specific embodiments described herein are only used to explain this disclosure, and not to limit this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure are within the scope of protection of this disclosure. In addition, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0027] In existing technologies, business users can configure multiple routing rules in a microservice gateway based on their experience, and select one or more extended functions to configure under each routing rule. For example... Figure 1 As shown, the microservice gateway uses routing rules as its backbone, extending with additional functionalities. However, this results in strong coupling between routing rules and extended functionalities, creating a rigid and inflexible relationship. It cannot adapt to the increasingly complex use cases within a microservice architecture. For example... Figure 1 In this context, routing rule 1 has a fixed subordinate relationship with extended function 1, extended function 2, and extended function 3. Routing rule 2 has a fixed subordinate relationship with extended function 1 and extended function 3. Routing rule 3 has a fixed subordinate relationship with extended function 2 and extended function 4.

[0028] In a microservice gateway, multiple routing rules may correspond to some of the same extended functionality. For example, in Figure 1In the existing technology, both routing rule 1 and routing rule 2 correspond to extended function 1. In this prior art, business users need to configure the same extended function separately under each routing rule, resulting in significant repetitive work. Furthermore, in some scenarios, it may be necessary for multiple routing rules to share data for the same extended function. For example, it may be necessary to rate limit the total number of requests under multiple routing rules. In the existing technology, an extended function can often only process requests under its own routing rule and cannot process requests under other routing rules. This prevents multiple routing rules from sharing data for the same extended function.

[0029] This specification provides a request processing system. The request processing system includes a terminal device, a service gateway, and one or more service devices. The terminal device includes user-facing devices, including but not limited to smartphones, desktop computers, laptops, POS devices, ATMs, and self-service terminals. The terminal device initiates business requests, such as transaction requests. The service gateway provides routing functionality to forward business requests from the terminal device to the service devices. The service gateway can also provide extended functions such as load balancing, traffic control, and security protection. The service device can process received business requests and obtain processing results; it can also send the processing results to the service gateway. The service gateway can receive and send processing results to the terminal device. The terminal device can receive and display the processing results.

[0030] For example, please see Figure 3 The client can send a service request to the service gateway. The service gateway can receive the service request and forward it to a service device, such as one or more of servers A, B, C, D, E, X, and Z.

[0031] Please see Figure 2 , Figure 3 and Figure 4 This specification provides a request processing method. The method can be applied to a gateway device. The gateway device may include a service gateway in a microservice architecture. The method may include the following steps.

[0032] Step 11: Obtain the target routing policy that is suitable for the received business request.

[0033] In some embodiments, a terminal device may send a service request to the service gateway. The service gateway may receive the service request. The terminal device may include user-facing devices, including but not limited to smartphones, desktop computers, laptops, POS devices, ATM devices, self-service terminals, etc. The service request may include account login requests, balance inquiry requests, transfer requests, payment requests, transaction requests, etc. The service request may include data elements. The data elements may include parameters of the Header field, parameters of the Cookie field, source IP address, request time, service parameters, and other data related to the service request. The service parameters may include account name, transaction amount, etc. The parameters of the Header field may include request status, request method, request content type, content length, etc. The parameters of the Cookie field include user session information, etc. The service request may follow network communication protocols, such as HTTP, TCP / IP, etc.

[0034] In some embodiments, the service gateway can provide a set of routing policies. The set of routing policies may include one or more routing policies. Within the set, the routing policies are completely decoupled, independent, and do not interfere with each other. Each routing policy may include identification information, the address of the service device, matching conditions, etc. The identification information is used to identify the routing policy. The address of the service device may include the domain name, IP address, etc., of the service device. The service device may be a downstream device used to respond to service requests. The matching conditions describe the execution requirements of the routing policy. The matching conditions are constraints for sending the service request to the service device. The matching conditions may include conditions related to one or more data elements of the service request. The matching conditions may include one condition, or multiple conditions. For example, the conditions can be formed using parameters and their values. For example, the conditions may include a parameter `ad` with a value of 17 and a parameter `af` with a value of 190. Another example is that the conditions may include a range of IP addresses belonging to a specific geographical region. Of course, other methods can also be used to form the conditions, such as conditional expressions.

[0035] In some embodiments, the service gateway can match data elements of a service request within a routing policy set to obtain a target routing policy. The routing policy must meet certain execution requirements in the execution scenario. The service gateway can traverse each routing policy in the routing policy set; for each traversed routing policy, it can compare data elements with the matching conditions in that routing policy; if the data element meets the matching conditions, the routing policy meets the execution requirements and can be used as the target routing policy; if the data element does not meet the matching conditions, the routing policy does not meet the execution requirements and can be ignored. There can be one or more target routing policies. The target routing policy is used to send the service request to a target service device. The target service device is used to process the service request. This allows for the execution of different routing policies based on the characteristics of the terminal device request, thereby forwarding the request to different servers to access services deployed on different servers.

[0036] It should be noted that the matching conditions can involve all data elements, or they can involve only some data elements. Data elements satisfying the matching conditions means that all data elements involved in the matching conditions satisfy those conditions.

[0037] Step 12: Extract the feature data of the business request.

[0038] In some embodiments, by extracting feature data from the service request, the characteristics of the service request can be perceived, facilitating the filtering of subsequent functional modules. The feature data represents the characteristics of the service request. The feature data may include feature items and their corresponding feature values. Specifically, the service request may include one or more data elements. The service gateway can then determine one or more feature data based on the one or more data elements.

[0039] The data elements may include request items and their corresponding request values. The feature data may include feature items and their corresponding feature values. The service gateway can then extract request items from the data elements as feature items, and extract the request values ​​of the request items from the data elements as feature values ​​of the feature items. For example, the User-Agent field of the Header field in the business request can be extracted as the feature item UA, and the value of the User-Agent field can be extracted as the feature value corresponding to the feature item UA. Similarly, the sessionId field in the business request can be extracted as the feature item SessionId, and the value of the sessionId field can be extracted as the feature value of the feature item SessionId. And again, the Param_1 field in the business request can be extracted as the feature item Param_1, and the value of the Param_1 field can be extracted as the feature value of the feature item Param_1.

[0040] Alternatively, the service gateway can perform feature derivation processing on the one or more data elements to obtain one or more feature data. The feature derivation method can be to generate new features by combining existing data elements in some way. For example, specific algorithms (such as addition, subtraction, multiplication, division, Cartesian product, one-hot encoding, etc.) can be used to derive new features.

[0041] Step 13: Match the target functional module in the functional module set based on the feature data and the target routing strategy.

[0042] Step 14: Process the business request through the target functional module.

[0043] In some embodiments, the service gateway may provide a set of functional modules. The set of functional modules may include one or more functional modules. In the set of functional modules, the various functional modules are completely decoupled, independent of each other, and do not interfere with each other. The functional modules are used to implement extended functions of the service gateway. The one or more functional modules may include traffic control, authentication and authorization, load balancing, content editing, security protection, transaction logs, transaction caching, etc.

[0044] The aforementioned functional modules enable the service gateway to provide diverse request processing capabilities.

[0045] In some embodiments, the functional modules in the functional module set and the routing strategies in the routing strategy set are independent of each other. No single functional module belongs to any one or more specific routing strategies. This decouples the functional modules from the routing strategies, and also decouples the identification of business requests by the routing strategies from the processing of business requests by the functional modules. The execution of a functional module no longer strongly depends on the identification result of the business request by the routing strategy. For example, if a certain routing strategy is matched, each functional module under that routing strategy will not need to process the business request. Each functional module in the functional module set has the function of identifying business requests, thus enabling it to independently identify and process business requests. The service gateway can provide different functional support to different business requests on a functional module basis. This allows the service gateway to support more flexible and complex use cases, enhancing its ability to provide services in complex application architectures.

[0046] In some embodiments, the functional modules in the functional module set may include matching conditions and execution strategies. The matching conditions are execution constraints of the functional modules. The matching conditions may include conditions related to the target routing strategy and one or more feature data. The matching conditions may include one condition, or multiple conditions. For example, the conditions can be formed using parameters and their values. Other methods can also be used to form the conditions, such as conditional expressions. The execution strategy is used to process the matched business requests.

[0047] The target functional module can be obtained by matching the feature data and target routing strategy within the functional module set. The functional module must meet certain execution requirements in the execution scenario. The service gateway can traverse each functional module in the functional module set; for each traversed functional module, the feature data and target routing strategy are compared with the matching conditions of that functional module. If the feature data and target routing strategy meet the matching conditions of the functional module, it means that the functional module meets the execution requirements and can be used as the target functional module; if the feature data and target routing strategy do not meet the matching conditions of the functional module, it means that the functional module does not meet the execution requirements and can be ignored. In this way, each functional module in the functional module set can independently and sequentially identify business requests. Each functional module in the functional module set can sequentially and in a certain order complete the steps of request reception, request matching, request processing, and request forwarding. The functional modules are completely decoupled, independently configured, and do not interfere with each other.

[0048] The number of target functional modules can be one or more. For example, the functional modules may include a transaction rate limiting module. The matching conditions for the transaction rate limiting module may include: routing policy A, feature sessionId value of abcdefg, and feature UA value of PC-windows. The transaction rate limiting module will only be triggered when the feature data and the target routing policy meet the above conditions.

[0049] In some embodiments, each time the service gateway matches a target functional module, it can process the service request through the target functional module. Specifically, the service gateway can traverse each functional module in the functional module set; for each traversed functional module, it can compare data elements with the matching conditions of that functional module; if the data element meets the matching conditions of the functional module, it means that the functional module meets the execution requirements, and the functional module can be used as the target functional module to process the service request; if the data element does not meet the matching conditions of the functional module, it means that the functional module does not meet the execution requirements, and the functional module can be ignored.

[0050] The functional modules in the functional module set can have a certain order. The service gateway can then traverse each functional module according to this order. This order can be a pre-set default order. This method is simple and direct, suitable for scenarios where the business process is relatively fixed and does not change frequently. Alternatively, the service gateway can also determine the correlation between each functional module in the functional module set and the business request based on the target routing strategy; it can sort the functional modules in the functional module set according to the correlation from highest to lowest; and it can traverse each functional module based on this sorting. This allows for flexible adjustment of the execution order of functional modules according to actual needs, meeting different usage scenarios. By prioritizing the matching and execution of functional modules with higher correlation, the overall matching efficiency can be improved.

[0051] The service gateway can process business requests according to the execution strategy in the target functional module. The way business requests are processed can vary depending on the extended functions implemented by the target functional module. For example, it can perform traffic control, authentication, load balancing, content editing, security protection, transaction logging, and transaction caching on business requests.

[0052] The number of target functional modules can be multiple. For the first matched target functional module, the service gateway processes the service request according to the execution strategy within that module. For other target functional modules besides the first one, the service gateway processes the processed service requests according to the execution strategy within each module. The processed service request is obtained from the previous target functional module.

[0053] In some embodiments, the service gateway can traverse each functional module in the functional module set; for each traversed functional module, data elements can be compared with the matching conditions of that functional module; if a data element meets the matching conditions of that functional module, it indicates that the functional module meets the execution requirements, and the functional module can be used as a target functional module. After obtaining all target functional modules, the service gateway can determine the execution chain of all target functional modules; and can process the business request according to the execution chain based on all target functional modules. The number of target functional modules can be multiple. The execution chain can include the execution order of the multiple target functional modules. For example, the service gateway can determine the correlation between each target functional module and the business request according to the target routing strategy; and can sort the target functional modules in descending order of correlation to obtain the execution chain.

[0054] In some embodiments, within a microservice architecture scenario, multiple different service functions will run on the same service device. Each service function corresponds to a service interface (API). When different types of business requests flowing to the same service device need to be processed differently through a service gateway—for example, limiting login transactions to 100 TPS while limiting other transactions to 1000 TPS; caching query transactions for 30 seconds while not caching other transactions—relying solely on the request identification capabilities of routing strategies is insufficient and too coarse-grained. Therefore, the granularity of the routing strategy can be increased. Specifically, the gateway device can distinguish between different service interfaces (APIs) deployed on the same service device, thereby achieving a more granular ability to identify service interfaces.

[0055] Each routing policy in the routing policy set can correspond to one or more service interfaces. The routing policy is used to send service requests to the corresponding service device. The corresponding service device includes the service device pointed to by the address in the routing policy. The one or more service interfaces include the interfaces of the corresponding service devices. Each service interface can correspond to a classification condition identifier and a classification condition. The classification condition identifier is used to identify the classification condition. The classification condition is a constraint condition for sending the service request to the service interface. The classification condition can include conditions related to one or more data elements of the service request. The classification condition can include one condition, or it can include multiple conditions. For example, the condition can be formed using parameters and their values. Of course, other methods can also be used to form conditions, such as condition expressions.

[0056] The service gateway can traverse one or more service interfaces of the target routing policy. For each traversed service interface, a data element can be compared with the classification conditions corresponding to that service interface. If the data element meets the classification conditions corresponding to the service interface, the service interface is considered compliant and can be used as the target service interface. If the data element does not meet the classification conditions, the service interface is considered non-compliant and can be ignored. The number of target service interfaces can be one. This allows the target service device to process business requests through the target service interface, enabling access to different services deployed on the server side based on the characteristics of the business request.

[0057] It should be noted that classification criteria may involve all data elements, or they may involve only some data elements. Data elements satisfying the classification criteria means that all data elements involved in the classification criteria satisfy those criteria.

[0058] After obtaining the target routing policy, target service interface, and feature data, the service gateway can match these data with the functional module set to obtain the target functional module. Specifically, the service gateway can traverse each functional module in the functional module set; for each traversed functional module, it can compare the feature data, target routing policy, and target service interface with the matching conditions of that functional module; if the feature data, target routing policy, and target service interface meet the matching conditions of that functional module, then the functional module meets the execution requirements and can be used as the target functional module; if the feature data, target routing policy, and target service interface do not meet the matching conditions of that functional module, then the functional module does not meet the execution requirements and can be ignored.

[0059] In some embodiments, the target functional module may intercept service requests. For example, the target functional module may include a transaction rate limiting module. When the number of service requests is large, the transaction rate limiting module can rate-limit the service requests, thereby intercepting them; when the number of service requests is small, the transaction rate limiting module can allow the service requests to pass. Therefore, when the target functional module indicates that it is intercepting the service request, the service gateway can generate a prompt message based on the interception and send the prompt message to the terminal device. The terminal device can receive and display the prompt message. The prompt message indicates that the service request has been intercepted by the service gateway, thus causing the service request to fail. Alternatively, when the target functional module indicates that it is allowing the service request, the service gateway can send the processed service request to the target service device pointed to by the target routing policy, so that the target service device can respond to the processed service request. The processed service request may include the request obtained after the target functional module processes the service request. The target service device may include the service device pointed to by the address in the target routing policy. The target service device can receive processed service requests; process the service requests to obtain processing results; and send the processing results to the service gateway. The service gateway can receive the processing results and send the processing results to the terminal device. The terminal device can receive and display the processing results.

[0060] Furthermore, the service gateway can invoke the target service interface of the target service device to send a processed service request to the target service interface. The target service device can process the service request based on the target service interface and obtain a processing result; it can also send the processing result to the service gateway through the target service interface. The service gateway can receive the processing result and send the processing result to the terminal device. The terminal device can receive and display the processing result.

[0061] The request processing method described in this specification can obtain the target routing strategy adapted to the received business request; extract the feature data of the business request; match the target functional module in the functional module set according to the feature data and the target routing strategy; and process the business request through the target functional module. This decouples the routing strategy from the configuration of the functional modules. The execution of the functional modules no longer strongly depends on the routing strategy's identification result of the business request. The service gateway can provide different functional support to different business requests on a functional module basis. This enables the service gateway to support more flexible and complex use cases, enhancing its ability to provide services under complex application architectures.

[0062] Please see Figure 5 This specification provides a request processing apparatus for a gateway device, comprising the following units.

[0063] The acquisition unit 21 is used to acquire the target routing strategy adapted to the received business request;

[0064] Extraction unit 22 is used to extract feature data of the service request;

[0065] Matching unit 23 is used to match target functional modules in the functional module set according to feature data and target routing strategy;

[0066] Processing unit 24 is used to process the business request through the target function module.

[0067] This specification also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described request processing method.

[0068] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described request processing method.

[0069] This specification also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described request processing method.

[0070] Those skilled in the art will understand that this specification can be provided as a method, system, or computer program product. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware. Furthermore, this specification 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.) containing computer-usable program code.

[0071] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments thereof. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. The computer may be a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0072] The functional units in the embodiments of this specification can be integrated into one processing unit, or each functional unit can exist physically separately, or two or more functional units can be integrated into one processing unit.

[0073] Those skilled in the art will understand that the descriptions of the various embodiments in this specification have different focuses, and parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. Furthermore, it is understood that those skilled in the art, after reading this specification, can conceive of any combination of some or all of the embodiments listed in this specification without creative effort, and such combinations are also within the scope of disclosure and protection of this specification.

[0074] Although this specification has been described through embodiments, those skilled in the art will understand that the above embodiments are merely illustrative of the core ideas of this specification. Those skilled in the art will appreciate that many variations and modifications are possible with this specification. It is intended that the appended claims encompass these variations and modifications without departing from the spirit of this specification.

Claims

1. A request processing method, characterized in that, Applied to gateway devices, including: Obtain the target routing policy adapted to the received service request. The target routing policy is used to send the service request to the target service device. The target routing policy corresponds to multiple service interfaces of the target service device. Extract the feature data of the business request; Based on the feature data, the corresponding target service interface is matched among the multiple service interfaces; Based on feature data, target routing strategy, and target service interface, target functional modules are matched in the functional module set. Wherein, no functional module in the functional module set belongs to one or more specific routing strategies, thereby decoupling the identification of business requests by the routing strategy from the processing of business requests by the functional modules. The business request is processed through the target functional module.

2. The method according to claim 1, characterized in that, The business request includes data elements; The method further includes: The target routing policy is matched with the data elements of the service request in the routing policy set. The target routing policy is used to send the service request to the target service device, and the target service device is used to process the service request.

3. The method according to claim 2, characterized in that, The functional modules in the functional module set are independent of each other; The routing policies in the routing policy set are independent of each other, and the functional modules and routing policies are independent of each other.

4. The method according to claim 1, characterized in that, The functional modules in the functional module set include matching conditions and execution strategies; the step of matching the target functional module includes: Iterate through each functional module in the functional module set; For each functional module traversed, determine whether the feature data and target routing strategy meet the matching conditions of the functional module. If so, determine the functional module as the target functional module. The steps for processing the service request include: The business request is processed using the execution strategy in the target functional module.

5. The method according to claim 1, characterized in that, The number of the target functional modules is multiple; The steps for processing the service request include: Based on feature data and target routing strategy, determine the execution links of the multiple target functional modules; The business request is processed according to the execution chain based on the multiple target functional modules.

6. The method according to claim 1, characterized in that, The method further includes: Receive the service request sent by the terminal device; Under the condition that the target functional module passes the service request, the processed service request is sent to the target service device pointed to by the target routing policy, so that the target service device can respond to the processed service request; The processing result of receiving the service request sent by the target service device; The processing result of the service request is sent to the terminal device.

7. The method according to claim 1, characterized in that, The method further includes: Receive the service request sent by the terminal device; If the target functional module intercepts the service request, a prompt message is sent to the terminal device.

8. A request processing apparatus, characterized in that, Applied to gateway devices, including: The acquisition unit is used to acquire the target routing policy adapted to the received service request. The target routing policy is used to send the service request to the target service device. The target routing policy corresponds to multiple service interfaces of the target service device. The extraction unit is used to extract the feature data of the business request and match the corresponding target service interface among the multiple service interfaces based on the feature data. The matching unit is used to match a target functional module in the functional module set according to feature data, target routing strategy and target service interface. The functional module set does not belong to one or more specific routing strategies, so that the identification of business requests by the routing strategy is decoupled from the processing of business requests by the functional module. The processing unit is used to process the business request through the target functional module.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor executes the instructions to implement the method as described in any one of claims 1-7.

Images