Request processing method, apparatus, device, medium, product

Abstract

This disclosure provides a request processing method, apparatus, device, medium, and product, which can be applied to the fields of computer technology and microservice technology. The request processing method includes: in response to receiving an access request, obtaining request attribute information associated with the access request; determining a target service instance from multiple candidate service instances based on the request attribute information, wherein the target service instance is used to provide a version of the service matching the request attribute information; and routing the access request to the target service instance according to the service identifier of the target service instance, so as to utilize the target service instance to process the access request.

Description

Technical Field

[0001] This disclosure relates to the fields of computer technology and microservices technology, and more specifically, to a request processing method, apparatus, device, medium, and product. Background Technology

[0002] With the widespread adoption of microservice architecture and cloud-native technologies, the iteration frequency of software systems has increased significantly. To reduce the impact of launching a new version on all users, canary releases have become a common release strategy in the industry. This involves first directing a small portion of user traffic to the new version service instance for verification, and then gradually increasing the proportion of traffic after successful verification, until a full switch is completed. Summary of the Invention

[0003] In view of the above, this disclosure provides a request processing method, apparatus, device, medium, and product.

[0004] According to one aspect of this disclosure, a request processing method is provided, comprising: in response to receiving an access request, obtaining request attribute information associated with the access request; determining a target service instance among a plurality of candidate service instances based on the request attribute information, wherein the target service instance is used to provide a version of a service that matches the request attribute information; and routing the access request to the target service instance according to the service identifier of the target service instance, so as to process the access request using the target service instance.

[0005] According to another aspect of this disclosure, a request processing apparatus is provided, comprising: an acquisition module, configured to acquire request attribute information associated with the access request in response to receiving an access request; a determination module, configured to determine a target service instance from a plurality of candidate service instances based on the request attribute information, wherein the target service instance is configured to provide a version of a service that matches the request attribute information; and a processing module, configured to route the access request to the target service instance according to the service identifier of the target service instance, so as to process the access request using the target service instance.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more instructions, wherein, when executed by the one or more processors, the one or more processors cause the one or more processors to perform the method as described in this disclosure.

[0007] According to another aspect of this disclosure, a computer-readable storage medium is provided having executable instructions stored thereon, which, when executed by a processor, cause the processor to perform the methods described in this disclosure.

[0008] According to another aspect of this disclosure, a computer program product is provided, which includes computer-executable instructions that, when executed, are used to perform the methods described in this disclosure. Attached Figure Description

[0009] The above and other objects, features and advantages of this disclosure will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0010] Figure 1 This illustration schematically shows a system architecture to which a request processing method can be applied according to embodiments of the present disclosure;

[0011] Figure 2 A flowchart illustrating a request processing method according to an embodiment of the present disclosure is shown schematically.

[0012] Figure 3A This illustration schematically shows an example diagram of a service instance deployment process according to an embodiment of the present disclosure;

[0013] Figure 3B This illustration schematically shows an example diagram of a service instance creation process according to an embodiment of the present disclosure;

[0014] Figure 3C This illustration schematically shows an example diagram of a configuration information configuration process according to an embodiment of the present disclosure;

[0015] Figure 3D This illustration schematically shows an example diagram of a traffic allocation weight configuration process according to an embodiment of the present disclosure;

[0016] Figure 3E This illustration schematically shows an example diagram of a target interface configuration process according to an embodiment of the present disclosure;

[0017] Figure 4 This illustration schematically shows an example diagram of a request processing procedure according to an embodiment of the present disclosure;

[0018] Figure 5 This illustration schematically shows an example diagram of a request processing procedure according to another embodiment of the present disclosure;

[0019] Figure 6 This illustration schematically shows an example diagram of a request processing procedure according to yet another embodiment of the present disclosure;

[0020] Figure 7 A block diagram of a request processing apparatus according to embodiments of the present disclosure is schematically shown; and

[0021] Figure 8 A block diagram of an electronic device suitable for implementing a request processing method according to an embodiment of the present disclosure is shown schematically. Detailed Implementation

[0022] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concepts of the present disclosure.

[0023] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this disclosure. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0024] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0025] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0026] In the technical solution of this invention, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0027] In one example, the number of new version instances can be controlled by configuring the number of canary containers and the canary traffic ratio. A canary tag is added to the startup script of the canary application instance, allowing the gateway to find the canary instance and allocate traffic based on this tag. However, this approach has the following problems: First, canary container tagging requires tagging each application being canary-released. When multiple applications and full-chain microservices are involved, each microservice in the chain needs to be tampered with, which is cumbersome and error-prone. Second, this solution only supports coarse-grained traffic allocation based on traffic percentages and cannot perform precise canary traffic control based on business attributes (such as user's department, organization, gender, user profile, etc.), limiting the expressive power of the canary strategy.

[0028] In another example, canary releases can also be implemented using a sidecar load balancing component. The gateway receives service requests and matches them against a canary release policy, marking successfully matched requests with a color. The sidecar component intercepts requests and checks for color markings; if a color mark exists, it selects the canary version instance for forwarding. While this approach enables end-to-end canary releases, it still has the following problems: First, deploying the sidecar component requires additional resources, as each microservice Pod needs to be injected with a sidecar proxy, increasing the complexity of the technical architecture and operational costs. Second, users need to prepare and maintain consistency of all fields to be marked throughout the entire process before canary releases, resulting in a large marking workload and an inability to flexibly adapt to dynamic changes in business attributes. Third, as an additional proxy layer, the sidecar increases the number of hops in the request chain, potentially introducing additional latency and points of failure, impacting overall system performance and reliability.

[0029] To this end, this disclosure provides a request processing method, apparatus, device, medium, and product that can be applied to the fields of computer technology and microservice technology. The request processing method includes: in response to receiving an access request, obtaining request attribute information associated with the access request; determining a target service instance from multiple candidate service instances based on the request attribute information, wherein the target service instance is used to provide a version of the service matching the request attribute information; and routing the access request to the target service instance according to the service identifier of the target service instance, so as to utilize the target service instance to process the access request.

[0030] Figure 1 The illustration schematically depicts a system architecture to which a request processing method can be applied according to embodiments of this disclosure. It should be noted that... Figure 1 The examples shown are merely examples of system architectures that can be applied to the embodiments of this disclosure, in order to help those skilled in the art understand the technical content of this disclosure, but do not mean that the embodiments of this disclosure cannot be used in other devices, systems, environments or scenarios.

[0031] like Figure 1As shown, the system architecture 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between different devices.

[0032] It should be noted that the request processing method provided in this embodiment can generally be executed by server 105. Accordingly, the request processing device provided in this embodiment can generally be located in server 105.

[0033] Alternatively, the request processing method provided in this embodiment of the present disclosure can also be executed by the first terminal device 101, the second terminal device 102, or the third terminal device 103. Correspondingly, the request processing apparatus provided in this embodiment of the present disclosure can also be disposed in the first terminal device 101, the second terminal device 102, or the third terminal device 103.

[0034] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0035] It should be noted that the sequence numbers of the operations in the following methods are for descriptive purposes only and should not be considered as indicating the execution order of the operations. Unless explicitly stated otherwise, the method does not need to be executed in the exact order shown.

[0036] The foregoing section described the system architecture for which request processing methods can be applied, as provided in this disclosure. The following section will use... Figure 2 The request processing procedure of this disclosure is further illustrated as an example.

[0037] Figure 2 A flowchart illustrating a request processing method according to an embodiment of the present disclosure is shown schematically.

[0038] like Figure 2 As shown, the request processing method 200 includes operations S210 to S230.

[0039] In operation S210, in response to receiving an access request, request attribute information associated with the access request is obtained.

[0040] In operation S220, based on the request attribute information, a target service instance is determined from multiple candidate service instances, wherein the target service instance is used to provide a version of the service that matches the request attribute information.

[0041] In operation S230, the access request is routed to the target service instance according to the service identifier of the target service instance, so that the target service instance can handle the access request.

[0042] In the embodiments of this disclosure, the request processing method described above can be applied to cloud-native gateways such as Envoy. When the gateway receives an access request initiated by a user, it can obtain request attribute information related to the canary traffic splitting decision based on the various information carriers of the request. An access request is a network call instruction initiated by a user to a service system, aimed at obtaining services or performing operations. When a large number of users initiate access requests simultaneously, these requests converge at the gateway to form traffic, thus access requests can serve as the trigger point for traffic control.

[0043] For example, an access request could be an HTTP GET request sent by the browser to the server when a user clicks the "View To-Do Items" button on a web page; it could also be an HTTPS POST request initiated by a mobile app calling a backend API interface to query the order status; or it could be a remote procedure call (gRPC) triggered by an IoT device reporting sensor data. No further limitation is made here.

[0044] Request attribute information is information that can be directly or indirectly extracted from an access request and is used to characterize the business characteristics of that access request. Request attribute information may include fields or data with business meaning, thereby reflecting business dimensions such as the identity, organizational affiliation, behavioral characteristics, and preference profile of the request initiator.

[0045] Candidate service instances are multiple service runtime entities that can provide the same business function but may be different versions (such as V1 stable version, V2 gray version, V3 experimental version, etc.). Each candidate service instance is an independently deployed and run service process or containerized Pod. They share the same business logic interface but may have different code versions, configurations or features.

[0046] A version of a service refers to the specific service form presented by the same business function at different iteration stages or with different feature configurations. Each version corresponds to an independent candidate service instance. There may be differences between versions in terms of code logic, functional features, data models, performance optimizations, etc., but the external interfaces remain compatible.

[0047] Each candidate service instance can be orchestrated and deployed using Kubernetes Deployments within a microservice architecture, and its network access capabilities can be exposed through Kubernetes native Service resources. It's important to note that all candidate service instances are deployed within the same namespace, forming a complete set of versions for the business function. For example, a user center microservice might have three candidate service instances: a stable version `userservicev1`, a gray-scale version `userservicev2`, and an experimental version `userservicev3`. These three candidate service instances can each correspond to different Service resources, such as `servicev1`, `servicev2`, and `servicev3`.

[0048] After obtaining the request attribute information, the gateway can match this information with the gray-scale rules pre-configured by the administrator to determine which version of the target service instance should handle the request from multiple candidate service instances. The target service instance is the specific service instance ultimately selected from multiple candidate service instances based on the request attribute information and the preset gray-scale matching rules; this instance can serve as the actual service version to carry and process the access request. The process of determining the target service instance is essentially a mapping process from request attributes to service versions, and the rules used for this decision can be flexibly defined by the administrator through the configuration interface.

[0049] For example, matching rules can include the relationship between field values ​​and versions, such as contain, do not contain, equal to, not equal to, exist, do not exist, and regular expression matching; multiple business fields support AND or OR relationships; traffic that meets the conditions is allocated to different versions (0%~100%) by a percentage; when no rule is hit or no business field is configured, traffic is allocated or forwarded to the default version by the default percentage.

[0050] A service identifier is an identifier that can uniquely locate and address a service instance at the network layer. In the embodiments of this disclosure, the service identifier can be a Service that leverages the native capabilities of the Kubernetes cloud-native platform. A Kubernetes Service is an abstract resource in Kubernetes that exposes a group of Pods as network services. Each Service has a globally unique name and a customizable label selector, and the gateway can achieve service discovery and traffic forwarding through the Service name.

[0051] After identifying the target service instance, the gateway can forward the access request to the target service instance at the network layer based on the instance's service identifier (such as the Kubernetes Service name), and the instance will then complete the business logic processing. Since the Service is a native Kubernetes resource, the backend business service itself does not need to add any side-wheel proxy or coloring markup, achieving zero intrusion into the business system.

[0052] In the embodiments of this disclosure, since the request attribute information is associated with the access request, the attribute characteristics carried by each request can be automatically identified. Based on this, the target service instance is determined from multiple candidate service instances. Since the traffic distribution strategy can be driven by attribute characteristics, it is possible to freely define which attribute request corresponds to which version of service. There is no need to color-mark the backend service instance or deploy sidecar proxies. By routing the access request to the target service instance according to the service identifier of the target service instance, the request traffic control logic is decoupled from the actual service deployment location, and flexible control of request traffic can be achieved.

[0053] The above provides an exemplary description of the request processing method provided in this disclosure. The following will further explain the configuration process of the candidate service instance provided in this disclosure.

[0054] According to embodiments of this disclosure, each candidate service instance can provide services to the outside world in the gateway based on its respective candidate service identifier; the candidate service instance can be created in the following way: in response to receiving a service creation instruction for the target service, multiple versions of initial service instances for processing the target service are created in the target namespace; in response to receiving candidate configuration information input by the user on the front-end interface, the initial service instances are configured according to the candidate configuration information to obtain the candidate service instance.

[0055] The gateway can be an Envoy cloud-native gateway service. The gateway can be deployed in a user's Kubernetes namespace and is responsible for receiving user access requests, extracting request attribute information, performing canary rule matching, and routing requests to the target service instance.

[0056] Candidate service instances are not directly exposed to external users. Instead, they are registered / mounted to the gateway through their candidate service identifier (such as the K8sService name). The gateway serves as a unified traffic entry point, receiving access requests from end users externally and distributing traffic to candidate service instances internally according to canary deployment rules.

[0057] A candidate service identifier is a unique identifier used at the network layer by each candidate service instance to expose its services and accept traffic. The gateway uses the candidate service identifier to address, locate, and connect to the corresponding candidate service instance, thereby forwarding access requests to the correct service version. In one embodiment, the candidate service identifier can be implemented using the native capabilities of the Kubernetes cloud-native platform, namely the name or tag of the Service resource.

[0058] For example, the above services can be created in the user's namespace through user input, and the service can be automatically created based on the version number. Each version of the candidate service instance will automatically obtain a corresponding Kubernetes Service upon creation, and the name of this Service is the candidate service identifier for that candidate service instance. The candidate service identifier is decoupled from the code, configuration, and runtime logic of the backend business service. The backend service does not need to be marked or modified in any way, and the gateway can achieve automatic addressing through the candidate service identifier.

[0059] The target business refers to a business function or microservice application that requires canary releases and traffic control. Administrators can create, orchestrate, and deploy multiple versions of the service for this target business to achieve gradual deployment, A / B testing, or refined operation based on business attributes. It should be noted that the target business can be a single microservice, such as canary releases only for the user center, or it can be multiple microservices involved in the entire chain of a single user request, such as the entire call chain of the user center, order service, and payment service.

[0060] A service creation command is an operation command initiated by an administrator through the front-end interface. This command drives the system to create a service instance of a specific version of the target business in the target namespace of the Kubernetes cluster. The service creation command includes key parameters required for service creation, such as version number, image information, resource quota, and number of replicas. For example, an administrator can click "Create Service" on the front-end interface, select the version, configure the image and resources, and submit. The system receives the command and triggers a Kubernetes API call, automatically completing the creation of the Deployment and Service in the background.

[0061] A target namespace is a logical partition in a Kubernetes cluster used for resource isolation and management. All microservices of the same user are deployed under the same target namespace, achieving resource isolation, access control, and unified management. An initial service instance is a service instance created in the target namespace after responding to a service creation command, but not yet bound to any canary deployment rules. Initial service instances can include Kubernetes Deployments for managing Pod replicas and Services for exposing network access.

[0062] The front-end interface is a graphical web page or management console provided to administrators for configuring canary release rules. Administrators can use this interface to define all canary release strategies, including selecting canary release versions, configuring business fields, setting matching conditions and weights, without writing code or manually editing configuration files.

[0063] Candidate configuration information is input by the administrator through the front-end interface, defining the conditional judgment logic that determines which candidate service instance should be routed to which type of request attribute. At runtime, the gateway uses these rules to direct user requests with different business attributes to the corresponding version of the candidate service instance.

[0064] Administrators can use the front-end configuration interface to input and bind canary deployment rules for each created initial service instance. After receiving the candidate configuration information submitted by the administrator, the system writes it to the gateway's configuration storage, making the rule effective on the gateway. Once the rule takes effect, the initial service instance is officially transformed into a candidate service instance.

[0065] In the embodiments disclosed herein, since the candidate service identifier is automatically generated based on the version number when the Deployment is created, the canary deployment control logic and business service logic are completely decoupled and non-intrusive at the architectural level. The addition or removal of canary deployment capabilities will not affect the stability of business services, code quality, and operation and maintenance processes, thereby improving reliability and request response speed. By leveraging the resource isolation and unified addressing capabilities of namespaces, multiple versions of the same target business can be deployed under the same namespace. The gateway can automatically perceive the Service information of all versions within the namespace through the native Kubernetes service discovery mechanism, enabling the gateway to obtain unified and automated perception capabilities for all microservice versions across the entire chain.

[0066] The following will combine Figures 3A-3E The configuration process for the aforementioned candidate service instances will be further explained.

[0067] Figure 3A The illustration shows an example diagram of a service instance deployment process according to an embodiment of the present disclosure.

[0068] like Figure 3A As shown in Example 300A of service instance deployment, a service creation command for a target business can be initiated by clicking "Publish New Version" in the version management interface. In response to this service creation command, a corresponding service instance can be created under the target namespace, and a service identifier (i.e., Service) can be automatically created based on the version number.

[0069] Figure 3B The illustration shows an example diagram of a service instance creation process according to an embodiment of the present disclosure.

[0070] like Figure 3B As shown in Example 300B of service instance creation, the service type can be selected using drop-down boxes corresponding to the service type on the service selection interface, the services can be filtered using drop-down boxes for clusters and namespaces, whether to enable GRPC can be selected using buttons, the port can be selected using drop-down boxes corresponding to the port, and the protocol can be selected using drop-down boxes corresponding to the protocol, thereby configuring canary rules according to business scenarios.

[0071] Figure 3C The illustration shows an example diagram of a configuration information configuration process according to an embodiment of the present disclosure.

[0072] like Figure 3C As shown in embodiment 300C, where configuration information is configured, attribute fields can be configured through the configuration interface. For example, an attribute field in the request header can be added by clicking "Add Parameter" and entering the keyword "1".

[0073] It should be noted that after configuring the attribute fields, you can use the dropdown menus corresponding to the judgment conditions to configure the regular expressions and version control relationships of the attribute fields or their corresponding attribute values. For example, when the judgment conditions are "contains", "does not contain", "equals", "not equals", "exists", "does not exist", and regular expressions are used, traffic is associated with different versions according to a percentage.

[0074] Figure 3D The illustration shows an example schematic diagram of a traffic allocation weight configuration process according to an embodiment of the present disclosure.

[0075] like Figure 3D As shown in the embodiment 300D of configuration information configuration, the traffic allocation weight can also be configured in the configuration controlled by a certain attribute field, and the traffic allocation weight value range is 0%~100%. Specifically, if the user sets the traffic allocation weight to 100% under a certain condition, then all user traffic that meets the configuration condition will be automatically allocated to this version.

[0076] Figure 3E The illustration shows an example schematic diagram of a target interface configuration process according to an embodiment of the present disclosure.

[0077] like Figure 3E As shown in Example 300E of the target interface configuration, if the gray release to be performed is based on a certain business scenario, but the business scenario information that can be identified is not directly reflected in the request information, the target interface can be configured by setting the access method, access address, load balancing strategy and timeout time.

[0078] The configuration process of the candidate service instances provided in this disclosure has been described above. The process of determining the target service instance from multiple candidate service instances based on the request attribute information provided in this disclosure will be further explained below.

[0079] According to an embodiment of this disclosure, operation S220 may include the following operations: determining an instance selection strategy based on the source of the requested attribute information, wherein the instance selection strategy defines an instance matching method for different sources; and determining a target service instance from multiple candidate service instances based on the instance selection strategy.

[0080] The source of request attribute information refers to where the request attribute information used for canary deployment decisions is obtained. In a microservice gateway scenario, information with the same business meaning may exist in different carriers of the request, while some information cannot be obtained directly from the request and needs to be indirectly derived through external interfaces.

[0081] For example, request attribute information can be directly included in the user-initiated access request itself and can be extracted without calling external services; alternatively, request attribute information may not be directly obtained from the request itself and needs to be indirectly derived by calling a pre-configured business plugin API.

[0082] The instance selection strategy defines the instance matching method to be used for different request attribute information sources to determine the target service instance from candidate service instances. The instance matching method is the specific method for establishing a correspondence between the obtained request attribute information and candidate service instances, defining which attribute values ​​correspond to which service versions.

[0083] After determining the applicable instance selection strategy, the gateway can perform matching operations between the acquired request attribute information and the version binding rules of the candidate service instances according to the instance matching method defined by the strategy, and determine the target service instance from multiple candidate service instances. For example, the instance matching method may include an exact matching method that compares the value of the request attribute information with a preset value for equality or not equality; or a fuzzy matching method that judges the value of the request attribute information with a preset value for inclusion or exclusion; or a pattern matching method that matches the value of the request attribute information with a preset regular expression, etc., which are not limited here.

[0084] In the embodiments of this disclosure, since the instance selection strategy is determined based on the source of the request attribute information, the gateway can classify information acquisition paths and pre-bind differentiated matching methods for the characteristics of different sources, improving decision-making efficiency and resource utilization. Simultaneously, due to the decoupled definition of the strategy and the source, administrators can independently adjust the matching method for a certain source without affecting the configuration of other sources, enhancing the maintainability and flexibility of the canary release rules. Based on this, by determining the target service instance from multiple candidate service instances according to the instance selection strategy, the gateway can execute version decisions according to a specific matching method adapted to the characteristics of that source. This achieves flexible canary release control based on business attributes while also considering decision-making efficiency and operational manageability.

[0085] The following will utilize Figure 4 The process of determining the target service instance described above will be further explained.

[0086] Figure 4 The illustration shows an example diagram of a request processing procedure according to an embodiment of the present disclosure.

[0087] like Figure 4 As shown, in the request processing embodiment 400, in response to receiving an access request 401, request attribute information 402 associated with the access request 401 can be obtained. After obtaining the request attribute information 402, operation S410 can be performed.

[0088] In operation S410, does the source of request attribute information 402 originate from the request information in access request 401?

[0089] If so, operation S420 can be executed. In operation S420, the request attribute information is matched with the configuration information of multiple candidate service instances to determine the target service instance.

[0090] If not, operation S430 can be executed. In operation S430, the returned information of the target interface is matched with the configuration information of multiple candidate service instances to determine the target service instance.

[0091] After performing operation S420 or S430, operation S440 can be performed. In operation S440, the access request is routed to the target service instance according to the service identifier of the target service instance, so that the target service instance can handle the access request.

[0092] In one embodiment of this disclosure, the request attribute information may be derived from the request information in the access request. The process of obtaining the request attribute information and determining the target service instance based on the request attribute information in this case will be described below.

[0093] According to embodiments of this disclosure, the source of the requested attribute information may include the request information in the access request. In this case, the business attribute values ​​used for canary deployment decisions do not need to be obtained by calling external services, but are directly extracted from the various components of the access request received by the gateway.

[0094] The request attribute information includes the attribute values ​​of multiple attribute fields. Each attribute field can represent a business dimension, such as user identifier, region, user type, channel source, etc., and the value of each field is the attribute value. Multiple attribute fields together form a multi-dimensional business feature vector, which can more accurately depict the business profile of this request, thereby achieving more refined and flexible grayscale control than single-field matching.

[0095] Based on the instance selection strategy, the target service instance is determined from multiple candidate service instances. This may include the following operations: matching multiple attribute values ​​with the configuration information of each of the multiple candidate service instances to obtain a first matching result; and determining the candidate service instance corresponding to the configuration information that matches the multiple attribute values ​​in the first matching result as the target service instance.

[0096] The configuration information is a set of conditional judgment logic predefined by the administrator through the configuration interface, used to direct request traffic with specific combinations of business attributes to a specific version of the service instance. Administrators can set multiple business fields in the canary deployment rule configuration to control traffic behavior. The control relationship between multiple attribute fields can be AND or OR. Specifically, when the relationship is AND, all values ​​of the specified fields must satisfy their respective rules for an overall match to be valid; when the relationship is OR, any field satisfying its corresponding rule is sufficient for an overall match to be valid.

[0097] After the gateway extracts multiple attribute fields and their respective attribute values ​​from the access request, it can compare and match these attribute value combinations with the grayscale configuration rules bound to each of the multiple candidate service instances one by one to generate a first matching result. The first matching result is an intermediate matching data set generated by comparing the attribute values ​​of each of the multiple attribute fields with the grayscale configuration rules bound to each of the candidate service instances one by one.

[0098] For example, the first matching result may include all matched grayscale configuration rules and their corresponding candidate service instance identifiers; in each matched rule, it may specify which attribute fields were matched successfully and which were not; if the rule contains percentage weight configuration, it may carry the weight value corresponding to each matched rule, etc., which are not limited here.

[0099] After obtaining the first matching result, the gateway can ultimately select one of these matched candidate service instances as the target service instance to actually process the access request. It should be noted that if only one rule is matched in the first matching result, the candidate service instance corresponding to that rule will be directly used as the target; if a percentage weight is configured, it will be randomly selected from multiple versions according to the weight ratio; if no rule is matched, it can fall back to the default version.

[0100] In the embodiments of this disclosure, since the source of the request attribute information includes the request information in the access request, the gateway can directly extract multi-dimensional business features from the request itself without relying on any external service calls. By matching multiple attribute values ​​with the grayscale configuration rules of multiple candidate service instances, the gateway can simultaneously evaluate the fit between all candidate versions and the current request in a single matching process. By determining the candidate service instances corresponding to the grayscale configuration rules that match multiple attribute values ​​in the first matching result as the target service instances, the gateway can perform refined selection based on the matching results, achieving refined grayscale control while ensuring the elasticity and reliability of the system.

[0101] According to an embodiment of this disclosure, operation S210 may include the following operations: matching multiple attribute fields with multiple sub-information in the request information to obtain an initial matching result, wherein the initial matching result includes the attribute values ​​of each of the multiple sub-information that match the attribute fields; and replacing the attribute values ​​extracted from the lower priority sub-information with the attribute values ​​extracted from the higher priority sub-information according to the priority order among the multiple sub-information to obtain the request attribute information, wherein the priority order is determined according to the degree of risk of each of the multiple sub-information.

[0102] Attribute fields are names of several business fields that the administrator pre-specifies in the canary deployment configuration rules and that need to be extracted from access requests. Each attribute field represents a business dimension, such as user identifier, region, user type, channel source, device type, etc., which together constitute the set of information required for canary deployment decisions. These field names can be set by the administrator through the configuration interface during the canary deployment rule configuration phase, and the gateway searches and extracts them from requests according to these field names at runtime.

[0103] The request information may include multiple sub-information items such as Param sub-information, Header sub-information, and Cookie sub-information. After receiving the access request, the gateway uses the names of multiple attribute fields pre-configured by the administrator as lookup keys to match the field names with each of the multiple sub-information items in the request one by one, checking if a field with the same name exists in each sub-information item, and summarizing and recording all the attribute values ​​found.

[0104] For each attribute field, the gateway iterates through all sub-information, checking if a field with the same name exists within that sub-information. If it does, it extracts the corresponding attribute value. The search results for all attribute fields across all sub-information are aggregated to form the initial matching result. The initial matching result may include the attribute values ​​corresponding to each attribute field in multiple sub-information pieces, as well as which sub-information piece each attribute value originates from.

[0105] Priority order is the sorting rule followed when dealing with attribute value conflicts among multiple pieces of information. Attribute values ​​extracted from higher-priority sub-information will override those extracted from lower-priority sub-information. This order can be determined by the degree of risk posed by each piece of information, which can be understood as the likelihood of tampering, the scope of exposure, and the security protection capabilities.

[0106] After obtaining the initial matching results, the gateway can resolve conflicts between different values ​​of the same attribute field in multiple sub-information according to a preset priority order: the attribute value in the higher priority sub-information overrides the attribute value in the lower priority sub-information, and finally obtains a unique value for each attribute field, which is then aggregated to form the request attribute information used for the final grayscale traffic splitting decision.

[0107] Specifically, the value is first taken from the lowest priority sub-information as the initial value, and then overwritten by the value from the higher priority sub-information; if the value of the field is missing in the higher priority sub-information, the value in the lower priority sub-information is retained and no replacement is made; if the field has no value in all sub-information, the final value of the attribute field is empty or the default value; finally, each attribute field has one and only one definite attribute value, which constitutes the requested attribute information.

[0108] In the embodiments of this disclosure, since the initial matching result is obtained by matching multiple attribute fields with multiple sub-information in the request information, the gateway achieves a full scan of each sub-information of the request during the attribute information collection stage, and can completely capture multiple values ​​that the same business field may have in different carriers. On this basis, by replacing the attribute values ​​extracted from the lower priority sub-information with attribute values ​​extracted from the higher priority sub-information according to the priority order among multiple sub-information, the gateway can automatically resolve conflicts according to the priority rules determined based on the risk level when the same attribute field has inconsistent or even contradictory values ​​in multiple sub-information. Thus, without relying on external security components, the security of the request sub-information ensures the accuracy and resistance to attacks in gray-scale traffic splitting decisions.

[0109] According to embodiments of this disclosure, the request information may include at least one of request parameters, request headers, and cookie information, with the priority order being that the priority of request parameters is lower than that of request headers, and the priority of request headers is lower than that of cookie information.

[0110] Request parameters (i.e., Param) are query string parameters organized in key-value pair format, located after the first identifier in the URL of the access request. Multiple parameters can be separated by a second identifier. The first identifier can be ?, and the second identifier can be &.

[0111] Considering the following characteristics of request parameters: they are visible in plain text in the browser address bar and are recorded and persisted in multiple places such as browser history, server access logs, intermediate proxy logs, and CDN cache logs; users can directly edit request parameter values ​​in the browser address bar, or freely modify them through browser developer tools or any HTTP client; the complete URL containing request parameters is often copied, shared, bookmarked, or spread through instant messaging tools, leading to the unintended dissemination of parameter information. Therefore, request parameters have the highest degree of risk and the lowest security among the three types of request information, and thus the lowest priority.

[0112] The request header is a series of key-value pairs of metadata located in the header area of ​​an HTTP request message, organized in the format of field name: field value. The request header is a core component of the HTTP protocol, used to transmit additional information related to the request between the client and server, such as authentication credentials, content type, client environment, and cache control, but it is not directly displayed in the URL.

[0113] Considering the following characteristics of request headers: they do not appear in the browser address bar and cannot be directly seen by ordinary users, but their content can still be viewed through browser developer tools, packet capture tools, or server-side log configuration; they can be modified through browser developer tools, browser extensions, HTTP client code, or proxy tools. Since request headers are not exposed in the URL and are difficult for ordinary users to modify directly, the risk level of request headers is lower than that of request parameters, their security is higher than that of request parameters, and therefore their priority is higher than that of request parameters.

[0114] Cookie information is a small piece of text data stored on the client side. It is pre-written to the client by the web server through the SetCookie directive in the HTTP response header. In subsequent requests to the same domain, the browser automatically sends the matching cookie back to the server in the form of a Cookie request header.

[0115] Considering that cookie information has the following characteristics: it is stored locally rather than appearing in the URL of each request; its protection can be enhanced by setting security flags; and its validity period can be controlled by setting attributes such as Expires or MaxAge, cookie information is protected by multiple browser security mechanisms, so it has the lowest risk, the highest security, and therefore the highest priority.

[0116] In the embodiments of this disclosure, by prioritizing the three types of sources according to their inherent security, when the same attribute field has inconsistent values ​​in multiple sources, the gateway automatically uses the value of the source with the highest security level, thereby ensuring the accuracy and security of the gray-scale traffic splitting decision.

[0117] In another embodiment of this disclosure, the request attribute information may also originate from the return information of the target interface used to access the request. The process of obtaining the request attribute information and determining the target service instance based on the request attribute information in this case will be described below.

[0118] According to embodiments of this disclosure, the source of the request attribute information may include the return information from the target interface used for the access request. The target interface used for the access request is a business plugin API service pre-developed and deployed by the administrator. It can receive certain basic field values ​​extracted from the access request from the gateway as input parameters, process them through internal business logic, and return the request attribute information associated with this access request.

[0119] Based on the instance selection strategy, the target service instance is determined from multiple candidate service instances. This may include the following operations: matching the returned information with the configuration information of each of the multiple candidate service instances to obtain a second matching result; and determining the candidate service instance corresponding to the configuration information that matches the returned information in the second matching result as the target service instance.

[0120] The returned information consists of business attribute data extracted from the HTTP response of the target interface after the gateway calls the target interface, according to preset rules, and used for canary deployment decisions. After successfully calling the target interface and obtaining the returned information, the gateway can compare and match the extracted business attribute values ​​with the canary deployment configuration rules bound to each of the multiple candidate service instances, generating a second matching result. The second matching result is a set of matching data generated after comparing and matching the returned information of the target interface with the canary deployment configuration rules of each of the multiple candidate service instances.

[0121] For example, the second matching result may include all matched grayscale configuration rules and their corresponding candidate service instance identifiers; for each matched rule, it may specify which attribute fields were matched successfully and which were not; if the rule contains percentage weight configuration, it may carry the weight value corresponding to each matched rule, etc., which are not limited here.

[0122] After obtaining the second matching result, the gateway can ultimately select one of these matched candidate instances as the target service instance according to a preset strategy to actually process the access request. It should be noted that if only one rule is matched in the second matching result, the candidate service instance corresponding to that rule will be directly used as the target; if a percentage weight is configured, it will be randomly selected from multiple versions according to the weight ratio; if no rule is matched, it can fall back to the default version.

[0123] In the embodiments of this disclosure, since the request attribute information can originate from the return information of the target interface used for the access request, precise grayscale control can be performed based on business attributes of any dimension, improving the flexibility of attribute information acquisition. By matching the return information with the grayscale configuration rules of multiple candidate service instances, and determining the candidate service instances corresponding to the grayscale configuration rules that match multiple attribute values ​​in the second matching result as the target service instances, the gateway can perform refined selection based on the matching results, achieving refined grayscale control while ensuring the elasticity and reliability of the system.

[0124] According to an embodiment of this disclosure, operation S210 may include the following operations: calling a target interface to process the input parameter fields extracted from the access request using the target interface and obtain return information; and extracting request attribute information from the return information.

[0125] After determining that the business attributes required for the canary deployment rules cannot be directly obtained from the request itself, the gateway can extract the specified input parameter fields from the access request according to the calling rules pre-configured by the administrator, encapsulate these input parameter fields according to the format and transmission method required by the target interface, initiate an HTTP / gRPC network call to the target interface, and wait to receive the response data returned by the target interface.

[0126] Input parameter fields are one or more fields extracted from user access requests and used as input parameters when calling the target interface. The input parameter fields themselves can originate from information included in the request. The gateway passes this basic identification data to the target interface in exchange for deeper business attribute information.

[0127] Specifically, based on the input parameter field definitions configured by the administrator, the corresponding field values ​​can be extracted from the Param / Header / Cookie of the request; a complete API call request can be constructed according to the definition of the target interface; a synchronous or asynchronous network request can be initiated to the target interface through an HTTP client or gRPC client; and the response from the target interface can be waited for and the returned information can be received.

[0128] It should be noted that the target interface can be deployed in the user's Kubernetes namespace. In this case, the gateway can automatically locate the interface through DNS resolution and service discovery using the Kubernetes Service name. Alternatively, the target interface can be deployed in a separate location. In this case, the gateway can directly access it through the IP:Port manually entered by the administrator.

[0129] The returned information is the raw data content that the target interface returns to the gateway via an HTTP response after receiving the input parameter fields from the gateway and completing its internal business logic processing. The returned information can be in a structured data format, such as JSON, XML, Protobuf, etc., and contains the business attribute data required by the gateway to make canary deployment decisions.

[0130] After successfully receiving the return information from the target interface, the gateway can accurately locate and extract the business attribute fields and their attribute values ​​required for the gray-scale traffic splitting decision from the return information according to the extraction rules pre-configured by the administrator, and obtain the request attribute information, which is then used to match the gray-scale configuration rules of each candidate service instance.

[0131] Specifically, based on the ContentType returned by the target interface, the corresponding parser can be selected to parse the original response body into a structured data object; according to the extraction path configured by the administrator, the target field can be located by navigating layer by layer in the parsed data object; the attribute value of the located field can be read; if the administrator has configured multiple grayscale business fields, the above location and extraction operations are repeated to summarize the attribute values ​​of all fields and obtain the requested attribute information.

[0132] In the embodiments of this disclosure, by utilizing the target interface to process the input parameter fields extracted from the access request, the gateway can proactively initiate a query to the external business system using the basic identifier fields already present in the request when the request itself cannot directly provide the business attributes required for grayscale deployment. Furthermore, by extracting request attribute information from the returned information, the gateway can accurately locate and extract the required business attribute values ​​from the complete response data returned by the target interface according to the field paths preset by the administrator, thus balancing the flexibility and robustness of request processing.

[0133] In the embodiments disclosed herein, there are also cases where no candidate service instance matches the requested attribute information, or where there is more than one matching candidate service instance, which will be described separately below.

[0134] According to embodiments of this disclosure, multiple candidate service instances are each associated with a traffic allocation weight. The traffic allocation weight is a numerical proportion configured for each candidate service instance, defining the proportion of access request traffic each instance should bear when a certain grayscale matching condition simultaneously matches multiple candidate service instances.

[0135] The request processing method 200 may also include the following operations: if the request attribute information matches more than one candidate service instance, determine the target service instance from multiple candidate service instances according to the traffic allocation weight associated with each candidate service instance; if the request attribute information does not match any of the multiple candidate service instances, determine the reference service instance as the target service instance.

[0136] A match can be understood as one or more attribute fields and their values ​​extracted from the request attribute information satisfying the conditions defined in the canary deployment rules bound to a candidate service instance. No match can be understood as none of the attribute fields and their values ​​in the request attribute information satisfying the conditions in the canary deployment rules bound to any non-default candidate service instance.

[0137] The criteria for matching may include, but are not limited to: equality / inequality comparison of field values, inclusion / exclusion judgment, existence / non-existence detection, regular expression pattern matching, and AND / OR combination logic judgment between multiple fields, etc., which are not limited here. When the grayscale rule of a candidate service instance is matched with the requested attribute information, the two are considered to be matched.

[0138] When the requested attribute information matches the grayscale configuration rules of multiple candidate service instances, the gateway does not randomly select one. Instead, it determines a unique target service instance from multiple matching candidate instances by using algorithms such as weighted random selection or weighted round-robin, according to the traffic allocation weight ratio pre-configured for each candidate instance.

[0139] Specifically, all matching candidate service instances and their associated weight values ​​can be extracted from the first or second matching results. If the sum of the weights of each instance is not 100%, normalization is performed to make the total weight 100%. Random decisions are generated according to the weight ratio. For example, if V1 has a weight of 30% and V2 has a weight of 70%, then a random number in the interval [0,1) is generated: if the number falls in [0,0.3), V1 is selected; if the number falls in [0.3,1.0), V2 is selected. The final target service instance is determined based on the random result.

[0140] When the requested attribute information does not match any of the grayscale configuration rules for non-default candidate service instances, that is, when no conditional rule is hit, the gateway automatically determines the pre-set reference service instance as the target service instance.

[0141] The reference service instance is the fallback service instance automatically selected when all candidate service instance grayscale configuration rules fail to match the attribute information of the current request (i.e., the request attribute information does not match any non-default rules). The reference service instance can correspond to the stable version of the business function. That is, no matter how the grayscale rules are configured or how the request attributes change, when all conditions are not met, the request still has a service version available for processing, and the request will not fail or be lost due to no matching rules.

[0142] In the embodiments of this disclosure, when the request attribute information matches more than one candidate service instance, the target service instance is determined from multiple candidate service instances by allocating weights based on the traffic associated with each candidate service instance, thus improving the flexibility of instance selection. Furthermore, when the request attribute information does not match any of the multiple candidate service instances, the high availability of canary releases is ensured by determining the reference service instance as the target service instance.

[0143] The following will combine Figure 5 This disclosure provides an explanation of the overall request processing flow.

[0144] Figure 5 The illustration shows an example diagram of a request processing procedure according to another embodiment of the present disclosure.

[0145] like Figure 5 As shown, in the request processing embodiment 500, each candidate service instance can provide services to the outside world in the gateway 510 based on its own candidate service identifier, and the configuration information 501 of each candidate service instance can be entered by the user on the front-end interface 502.

[0146] In response to receiving access request 503, request attribute information 504 associated with access request 503 can be obtained. After obtaining request attribute information 504, operation S510 can be executed. In operation S510, is the request attribute information 504 derived from the request information in access request 503?

[0147] If yes, the request attribute information 504 can be matched with the configuration information 501 of each of the multiple candidate service instances. If no, the target interface 505 can be called and the returned information from the target interface 505 can be matched with the configuration information 501 of each of the multiple candidate service instances.

[0148] In operation S520, does matching configuration information 501 exist? If not, it means that the requested attribute information 504 does not match any of the candidate service instances, and the reference service instance 506 can be determined as the target service instance 507. If yes, operation S530 can be executed.

[0149] In operation S530, is there more than one matching configuration information 501? If not, the candidate service instance corresponding to the matching configuration information 501 can be directly determined as the target service instance 507. If so, indicating that the request attribute information 504 matches more than one candidate service instance, the target service instance 507 can be determined from multiple candidate service instances based on the traffic allocation weights 508 associated with each candidate service instance.

[0150] In the embodiments of this disclosure, the number of target service instances determined based on the request attribute information can be multiple. The process of using multiple target service instances to process access requests will be described below.

[0151] According to embodiments of this disclosure, the target service instances may include M instances, where m = 1, ..., M-1 for the m-th target service instance; operation S230 may include the following operations: forwarding the m-th intermediate information to the (m+1)-th target service instance, wherein the m-th intermediate information is obtained by processing the (m-1)-th intermediate information using the m-th target service instance, and the 0th intermediate information is an access request; processing the m-th intermediate information using the (m+1)-th target service instance to obtain the (m+1)-th intermediate information.

[0152] The M target service instances are the set of the M microservice instances corresponding to their respective gray-scale versions that need to be processed sequentially during the end-to-end processing of a user access request. M is an integer greater than or equal to 2, representing the number of microservice nodes involved in the end-to-end processing of the request. Each target service instance can correspond to a processing node in the chain.

[0153] For example, the first target service instance may be a front-end service, the second target service instance may be a user center service, and the third target service instance may be a to-do query service. They are linked together to form a complete request processing pipeline.

[0154] The m-th target service instance is the canary version instance corresponding to the m-th microservice node in the end-to-end processing sequence. Since m indicates the current position of the request in the chain, after the request is processed by the m-th target service instance, the intermediate results will be passed to the (m+1)-th target service instance for further processing.

[0155] The m-th intermediate information is the result data produced by the m-th target service instance after processing the (m-1)-th intermediate information. This result data will serve as the input to the (m+1)-th target service instance. Intermediate information is processed and transmitted progressively throughout the entire link, containing both the processing results of the previous node and potentially carrying context information accumulated during transmission. The gateway can obtain the m-th intermediate information from the m-th target service instance and forward it as input to the next node in the link, namely the (m+1)-th target service instance.

[0156] For example, continuing with the three target service instances mentioned above, the first intermediate information can be the userID and request parameters parsed by the front-end service after processing the access request, and this intermediate information is sent to the user center service; the second intermediate information can be the user center service querying user attributes based on the userID, and this intermediate information is sent to the to-do query service; the third intermediate information can be the to-do query service querying the to-do list based on user attributes and request parameters.

[0157] In the embodiments of this disclosure, since the input of each target service instance is the output of the previous target service instance, the gateway can perform grayscale rule matching and target instance selection at each jump and forward the intermediate information to the next target service instance. Thus, each target service instance only needs to process the intermediate information it receives and pass the returned result to the next instance, thereby improving the efficiency of request processing.

[0158] The above has explained the normal request processing logic provided in this disclosure. The following will use... Figure 6 As an example, the logic provided in this disclosure for supporting secondary processing and forwarding of any service will be further explained.

[0159] Figure 6 The illustration shows an example diagram of a request processing procedure according to yet another embodiment of the present disclosure.

[0160] like Figure 6 As shown, in the request processing embodiment 600, each candidate service instance can provide services to the outside world in the gateway 610 based on its own candidate service identifier, and the configuration information 601 of each candidate service instance can be entered by the user on the front-end interface.

[0161] For gateway 610, any service can be intercepted at gateway 610 for secondary processing and forwarding. In response to receiving access request 602, operation S610 can be executed. Does operation S610 have the necessary permissions? If not, normal request processing logic is executed. If yes, the logic for intercepting other services 620 for secondary processing and forwarding can be executed.

[0162] Retrieve attribute field a 603 associated with access request 602; route attribute field a 603 to other service 620 according to the service identifier 621 of other service 620, so that other service 620 can convert attribute field a 603 into attribute field b through the business service, and return attribute field b to gateway 610. Gateway 610 can match attribute field b with the configuration information of multiple candidate service instances to determine the target service instance.

[0163] For example, taking the services corresponding to access request 602 as including microservices 630 and 640, microservice 630 includes service instance 633 of version 1 and service instance 634 of version 2, and microservice 640 includes service instance 642. Service instance 633 provides microservice 630 to the outside world through service identifier 631, service instance 634 provides microservice 630 to the outside world through service identifier 632, and service instance 642 provides microservice 640 to the outside world through service identifier 641.

[0164] Taking the matching of attribute field b with the configuration information of multiple service instances to determine that the target service instances include service instance 634 and service instance 642 as an example, the access request 602 can be routed to service instance 634 and service instance 642 according to service identifier 632 and service identifier 641, so that service instance 634 and service instance 642 can handle access request 602.

[0165] The above are merely exemplary embodiments, but are not limited thereto. Other request processing methods known in the art may also be included, as long as they enable flexible control over request traffic.

[0166] Based on the above request processing method, the present invention also provides a request processing apparatus. The following will be combined with... Figure 7 The device is described in detail.

[0167] Figure 7 A block diagram of a request processing apparatus according to an embodiment of the present disclosure is shown schematically.

[0168] like Figure 7 As shown, the request processing device 700 may include an acquisition module 710, a determination module 720, and a processing module 730.

[0169] The acquisition module 710 is used to acquire request attribute information associated with the access request in response to receiving an access request.

[0170] The determination module 720 is used to determine the target service instance from multiple candidate service instances based on the request attribute information, wherein the target service instance is used to provide a version of the service that matches the request attribute information.

[0171] The processing module 730 is used to route access requests to the target service instance according to the service identifier of the target service instance, so as to utilize the target service instance to process the access requests.

[0172] Any one or more of the modules according to embodiments of this disclosure, or at least part of the functionality of any one or more of them, can be implemented in one module. Any one or more of the modules according to embodiments of this disclosure can be implemented by dividing them into multiple modules. Any one or more of the modules according to embodiments of this disclosure can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or implemented in hardware or firmware by any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, one or more of the modules according to embodiments of this disclosure can be at least partially implemented as computer program modules, which, when run, can perform corresponding functions.

[0173] It should be noted that the request processing device part in the embodiments of this disclosure corresponds to the request processing method part in the embodiments of this disclosure. For a detailed description of the request processing device part, please refer to the request processing method part, which will not be repeated here.

[0174] Figure 8 A block diagram of an electronic device suitable for implementing a request processing method according to an embodiment of the present disclosure is shown schematically. Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0175] like Figure 8 As shown, a computer electronic device 800 according to an embodiment of the present disclosure includes a processor 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage portion 809 into a random access memory (RAM) 803. The processor 801 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 801 may also include onboard memory for caching purposes. The processor 801 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present disclosure.

[0176] RAM 803 stores various programs and data required for the operation of electronic device 800. Processor 801, ROM 802, and RAM 803 are interconnected via bus 804.

[0177] According to embodiments of this disclosure, the electronic device 800 may further include an input / output (I / O) interface 805, which is also connected to a bus 804. The electronic device 800 may also include one or more of the following components connected to the input / output (I / O) interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN card, modem, etc. The communication section 809 performs communication processing via a network such as the Internet. A drive 810 is also connected to the input / output (I / O) interface 805 as needed. A removable medium 811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 810 as needed so that computer programs read from it can be installed into the storage section 808 as needed.

[0178] This disclosure also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the request processing method according to the embodiments of this disclosure.

[0179] In this disclosure, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0180] Embodiments of this disclosure also include a computer program product comprising a computer program containing program code for performing the methods provided in the embodiments of this disclosure. When the computer program product is run on an electronic device, the program code is used to enable the electronic device to implement the request processing methods provided in the embodiments of this disclosure.

[0181] When the computer program is executed by the processor 801, it performs the functions defined in the system / apparatus of this disclosure embodiments. According to embodiments of this disclosure, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0182] According to embodiments of this disclosure, program code for executing computer programs provided in embodiments of this disclosure can be written in any combination of one or more programming languages.

[0183] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. It should also be noted that in some alternative implementations, the functions indicated in the boxes may occur in a different order than those shown in the drawings.

[0184] The embodiments of this disclosure have been described above. However, these embodiments are for illustrative purposes only and are not intended to limit the scope of this disclosure. Although various embodiments have been described above, this does not mean that the measures in the various embodiments cannot be used advantageously in combination. The scope of this disclosure is defined by the appended claims and their equivalents. Various substitutions and modifications can be made by those skilled in the art without departing from the scope of this disclosure, and all such substitutions and modifications should fall within the scope of this disclosure.

Claims

1. A request processing method, comprising: In response to receiving an access request, obtain the request attribute information associated with the access request; Based on the request attribute information, a target service instance is determined from multiple candidate service instances, wherein the target service instance is used to provide a version of the service that matches the request attribute information; as well as The access request is routed to the target service instance according to the service identifier of the target service instance, so that the target service instance can process the access request.

2. The method of claim 1, wherein, The step of determining the target service instance from multiple candidate service instances based on the request attribute information includes: Based on the source of the requested attribute information, an instance selection strategy is determined, wherein the instance selection strategy defines the instance matching method for different sources; and Based on the instance selection strategy, the target service instance is determined from among the multiple candidate service instances.

3. The method of claim 2, wherein, The source of the request attribute information includes the request information in the access request, and the request attribute information includes the attribute values ​​of multiple attribute fields; The step of determining the target service instance from among the multiple candidate service instances according to the instance selection strategy includes: The multiple attribute values ​​are matched with the configuration information of the multiple candidate service instances to obtain a first matching result; as well as The candidate service instances corresponding to the configuration information that match the multiple attribute values ​​in the first matching result are determined as the target service instances.

4. The method of claim 3, wherein, The step of obtaining the request attribute information associated with the access request includes: The multiple attribute fields are matched with multiple sub-information pieces in the request information to obtain an initial matching result, wherein the initial matching result includes the attribute values ​​of each of the multiple sub-information pieces that match the attribute fields; and The requested attribute information is obtained by replacing the attribute value extracted from the lower priority sub-information with the attribute value extracted from the higher priority sub-information, according to the priority order among the multiple sub-information.

5. The method of claim 4, wherein, The request information includes at least one of request parameters, request headers, and cookie information, and the priority order is that the priority of the request parameters is lower than the priority of the request headers, and the priority of the request headers is lower than the priority of the cookie information.

6. The method according to claim 2, wherein, The source of the request attribute information includes the return information from the target interface used for the access request; The step of determining the target service instance from among the multiple candidate service instances according to the instance selection strategy includes: The returned information is matched with the configuration information of each of the plurality of candidate service instances to obtain a second matching result; as well as The candidate service instance corresponding to the configuration information that matches the returned information in the second matching result is determined as the target service instance.

7. The method according to claim 6, wherein, The step of obtaining the request attribute information associated with the access request includes: The target interface is invoked to process the input parameter fields extracted from the access request and obtain the returned information; and Extract the request attribute information from the returned information.

8. The method according to any one of claims 1 to 7, wherein, Each of the candidate service instances is associated with a traffic allocation weight; The method further includes: If the requested attribute information matches more than one candidate service instance, the target service instance is determined from the plurality of candidate service instances based on the traffic allocation weight associated with each of the candidate service instances; or If the requested attribute information does not match any of the candidate service instances, the reference service instance will be determined as the target service instance.

9. The method according to any one of claims 1 to 7, wherein, Each of the candidate service instances provides services to the outside world in the gateway based on its respective candidate service identifier; The candidate service instance is created using the following method: In response to receiving a service creation instruction for a target service, initial service instances for multiple versions of the target service are created in the target namespace. as well as In response to receiving candidate configuration information input by the user on the front-end interface, the initial service instance is configured according to the candidate configuration information to obtain the candidate service instance.

10. The method according to any one of claims 1 to 7, wherein, The target service instances include M instances, where m = 1, ..., M-1 for the m-th target service instance. The step of routing the access request to the target service instance according to the service identifier of the target service instance includes: The m-th intermediate information is forwarded to the (m+1)-th target service instance, wherein the m-th intermediate information is obtained by processing the (m-1)-th intermediate information using the m-th target service instance, and the 0th intermediate information is the access request; and The m+1th target service instance is used to process the m-th intermediate information to obtain the m+1th intermediate information.

11. A request processing apparatus, comprising: The acquisition module is used to acquire request attribute information associated with the access request in response to receiving an access request; The determining module is used to determine a target service instance from multiple candidate service instances based on the request attribute information, wherein the target service instance is used to provide a version of the service that matches the request attribute information; as well as The processing module is configured to route the access request to the target service instance according to the service identifier of the target service instance, so as to process the access request using the target service instance.

12. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 10.

13. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 10.

14. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 10.

Images