Gateway traffic scheduling method, system and device and storage medium
By receiving service requests in the gateway and determining traffic shunt rules and node grouping rules based on traffic identification, the problem of high implementation difficulty and cost of gateway traffic scheduling systems in the prior art is solved, and traffic scheduling of different service versions at the gateway level is realized.
Patent Information
- Application Number
- CN202411819000.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-11
- Publication Date
- 2025-03-28
AI Technical Summary
In the prior art, when the gateway traffic scheduling system executes traffic scheduling strategies, it requires different modules of the system to collaborate on developing plug-in code, which leads to high implementation difficulty and cost.
By receiving service requests from the user, the target service and upstream service instance collection is determined, the traffic shunt rules and node grouping rules are determined based on the traffic identification of the service request, and the target instance is determined, and the service request is sent to the target instance for processing.
Implementing traffic scheduling for different service versions at the gateway level simplifies the implementation process and reduces the implementation difficulty and cost.
Smart Images

Figure CN119728792A_ABST
Abstract
Description
Technical Field
[0001] The embodiments of the present application relate to the field of computer technology, and in particular to a gateway traffic scheduling method, system, device and storage medium. Background Art
[0002] Currently, when performing traffic scheduling based on the gateway, the gateway will match the received requests according to the routing rules and find the corresponding service. The request is forwarded to the set of upstream service instances defined in the service. The upstream service instance set distributes the request to one or more service instances for processing based on the load balancing strategy. In the process of traffic scheduling, traffic scheduling based on grayscale release or blue-green release strategies is often involved. Grayscale release refers to scheduling part of the traffic to the old version of the service instance, and part of the traffic to the new version of the service instance. By gradually expanding the traffic scheduling range, all traffic is scheduled to the new version of the service instance. Blue-green release is a strategy that switches traffic from the current version to the new version of the service instance at one time.
[0003] However, when the traffic scheduling system executes relevant traffic scheduling strategies, it is necessary to configure the plug-in of the corresponding service instance on the gateway, and then update the plug-in code according to the traffic scheduling strategy. The whole process requires collaboration between different modules of the system. The code development is highly complex, resulting in relatively great difficulty in implementing the traffic scheduling strategy and high implementation cost. Summary of the invention
[0004] The embodiments of the present application provide a gateway traffic scheduling method, system, device and storage medium, which can implement traffic scheduling of different service versions at the gateway, simplify the implementation process of traffic scheduling for different service versions, and solve the technical problem of high complexity in implementing traffic scheduling strategies for different service versions.
[0005] In a first aspect, an embodiment of the present application provides a gateway traffic scheduling method, including:
[0006] Receive a service request from a user, determine a target service for the service request, pre-configure a mapped upstream service instance set for the target service, the upstream service instance set includes at least one service instance that processes the service request, and register the service instance from a registration center and synchronize it to the upstream service instance set based on a synchronization service;
[0007] Determine the traffic diversion rule pre-configured for the target service according to the traffic identifier of the service request, and query the node grouping rule pre-configured for the upstream service instance set based on the traffic diversion rule. The traffic diversion rule includes a mapping relationship between the traffic identifier and the traffic scheduling label, and the node grouping rule includes a mapping relationship between the traffic scheduling label and the corresponding service instance;
[0008] The target instance is determined based on the queried node grouping rules, and the service request is sent to the target instance for processing.
[0009] In a second aspect, an embodiment of the present application provides a gateway traffic scheduling system, including:
[0010] A target determination module is configured to receive a service request from a user terminal, determine a target service for the service request, pre-configure a mapped upstream service instance set for the target service, the upstream service instance set includes at least one service instance for processing the service request, and the service instance is registered from a registration center and synchronized to the upstream service instance set based on a synchronization service;
[0011] A rule determination module is configured to determine a traffic diversion rule pre-configured for a target service according to a traffic identifier of a service request, and query a node grouping rule pre-configured for an upstream service instance set based on the traffic diversion rule, wherein the traffic diversion rule includes a mapping relationship between a traffic identifier and a traffic scheduling label, and the node grouping rule includes a mapping relationship between a traffic scheduling label and a corresponding service instance;
[0012] The scheduling module is configured to determine the target instance based on the queried node grouping rule and send the service request to the target instance for processing.
[0013] In a third aspect, an embodiment of the present application provides a gateway traffic scheduling device, including:
[0014] memory and one or more processors;
[0015] The memory is configured to store one or more programs;
[0016] When the one or more programs are executed by the one or more processors, the one or more processors implement the gateway traffic scheduling method as described in the first aspect.
[0017] In a fourth aspect, an embodiment of the present application provides a non-volatile computer-readable storage medium, which stores computer-executable instructions, and the computer-executable instructions are configured to execute the gateway traffic scheduling method described in the first aspect when executed by a computer processor.
[0018] In a fifth aspect, an embodiment of the present application provides a computer program product, which includes instructions. When the instructions are executed on a computer or a processor, the computer or the processor executes the gateway traffic scheduling method as described in the first aspect.
[0019] The embodiment of the present application receives a service request from a user end, determines the target service of the service request, and pre-configures a set of upstream service instances mapped to the target service. The upstream service instance set includes at least one service instance that processes the service request. The service instance is registered from a registration center and synchronized to the upstream service instance set based on a synchronization service; determines the pre-configured traffic diversion rule of the target service according to the traffic identifier of the service request, queries the pre-configured node grouping rule of the upstream service instance set based on the traffic diversion rule, the traffic diversion rule includes a mapping relationship between the traffic identifier and the traffic scheduling label, and the node grouping rule includes a mapping relationship between the traffic scheduling label and the corresponding service instance; determines the target instance based on the queried node grouping rule, and sends the service request to the target instance for processing. Using the above technical means, the pre-configured traffic diversion rule of the target service is determined by the traffic identifier of the service request, and the pre-configured node grouping rule of the upstream service instance set is queried based on the traffic diversion rule, and then the service request is sent to the target instance for processing by determining the target instance. In this way, traffic scheduling of different service versions can be implemented at the gateway, and the service request can be sent to the corresponding service instance for processing according to the traffic scheduling requirements. Avoid the situation where different modules collaborate to develop traffic scheduling codes, which makes it difficult to implement traffic scheduling for different service versions, and reduce the implementation cost and difficulty of the traffic scheduling system. BRIEF DESCRIPTION OF THE DRAWINGS
[0020] Figure 1 It is a flow chart of a gateway traffic scheduling method provided by an embodiment of the present application;
[0021] Figure 2 is a structural diagram of a traffic scheduling system in an embodiment of the present application;
[0022] Figure 3 It is a schematic diagram of the traffic scheduling strategy configuration in an embodiment of the present application;
[0023] Figure 4 is a schematic diagram of traffic scheduling based on traffic scheduling tags in an embodiment of the present application;
[0024] Figure 5 This is a schematic diagram of transparent transmission of service requests based on traffic scheduling tags in an embodiment of the present application;
[0025] Figure 6 It is a structural diagram of a gateway traffic scheduling system provided in an embodiment of the present application;
[0026] Figure 7 It is a structural diagram of a gateway traffic scheduling device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0027] In order to make the purpose, technical scheme and advantages of the present application clearer, the specific embodiments of the present application are further described in detail below in conjunction with the accompanying drawings. It is understood that the specific embodiments described herein are only used to explain the present application, rather than to limit the present application. It should also be noted that, for the convenience of description, only the part related to the present application but not all the contents are shown in the accompanying drawings. Before discussing the exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flow charts. Although the flow chart describes each operation (or step) as a sequential process, many of the operations therein can be implemented in parallel, concurrently or simultaneously. In addition, the order of each operation can be rearranged. The process can be terminated when its operation is completed, but it can also have additional steps not included in the accompanying drawings. The process can correspond to a method, a function, a procedure, a subroutine, a subprogram, etc.
[0028] The gateway traffic scheduling method provided in this application aims to determine the traffic diversion rules pre-configured for the target service through the traffic identifier of the service request, query the node grouping rules pre-configured for the upstream service instance set based on the traffic diversion rules, and then send the service request to the target instance for processing by determining the target instance. This can realize traffic scheduling of different service versions at the gateway and reduce the implementation cost and difficulty of the traffic scheduling system.
[0029] When the traffic scheduling system executes the relevant traffic scheduling strategy, it is necessary to configure the plug-in of the corresponding service instance on the gateway, and then update the plug-in code according to the traffic scheduling strategy. The whole process requires the collaboration of different modules of the system, and the code development complexity is relatively high. Based on this, a gateway traffic scheduling method of an embodiment of the present application is provided to solve the technical problem of high complexity in implementing traffic scheduling strategies of different service versions.
[0030] Example:
[0031] Figure 1 A flow chart of a gateway traffic scheduling method provided in an embodiment of the present application is given. The gateway traffic scheduling method provided in this embodiment can be executed by a gateway traffic scheduling device, which can be implemented by software and / or hardware. The gateway traffic scheduling device can be composed of two or more physical entities, or can be composed of one physical entity. Generally speaking, the gateway traffic scheduling device can be a processing device such as a gateway device and a gateway controller.
[0032] The following description is made by taking the gateway traffic scheduling device as an example of the subject for executing the gateway traffic scheduling method. Figure 1 , the gateway traffic scheduling method specifically includes:
[0033] S110. Receive a service request from the user, determine the target service of the service request, pre-configure a mapped upstream service instance set for the target service, the upstream service instance set includes at least one service instance that processes the service request, and the service instance is registered from the registration center and synchronized to the upstream service instance set based on the synchronization service.
[0034] When performing gateway traffic scheduling, the present application receives service requests through a gateway device, determines the target instance for processing the service request based on pre-set traffic diversion rules and node grouping rules, and sends the service request to the target instance for processing, so as to implement traffic scheduling of different service versions at the gateway level, while simplifying the implementation process and reducing the implementation complexity.
[0035] Reference Figure 2 , a structural diagram of the traffic scheduling system of the present application is provided, and the traffic scheduling system includes a gateway, a synchronization service, a registration center and a gateway traffic scheduling platform. Among them, a gateway is a device or software in a computer network, which is mainly used for data exchange and communication between different networks or different protocols. As a converter, the gateway allows effective data transmission and communication between different network systems, even if these systems use different data formats or communication protocols. Common gateways include: kong, springcloud gateway, envoygateway, etc. Taking the kong gateway as an example below, the internal components of kong are: route route, service service, upstream service instance collection upstream, target target and plug-in Plugin.
[0036] Among them, the route defines how to map external requests to specific services. Each route consists of one or more rules, which can be domain names, paths, IP addresses, ports, etc. The route is the first object matched when the client request arrives at Kong.
[0037] ServiceService is an abstraction of an upstream service that service requests want to be proxied through Kong. It contains the URL of the upstream service (i.e. where to find the service), and Kong will forward the request to this URL. A service can have multiple routes associated with it, so that different routing rules can point to the same service.
[0038] The upstream service instance set Upstream is a virtual name that represents a set of servers that provide the same service. It is used for load balancing and can distribute requests to multiple upstream service instances. The upstream is defined by specifying a name and an associated set of targets.
[0039] The target is a specific service instance in the upstream, which contains information such as the IP address, port, and weight of the actual service instance. Kong distributes requests to these targets through polling or other load balancing algorithms.
[0040] In each module, a route points to a service and defines the rules for how requests reach the service. A service is associated with an upstream service instance set, which specifies the details of the upstream service to which the request should be forwarded. The upstream service instance set contains multiple targets, which are specific service instances of the upstream service.
[0041] A plugin is a configuration that can be executed during the lifecycle of an HTTP request / response. They can add various features to services running behind Kong, such as authentication, current limiting, logging, request transformation, etc. Plugins can be applied to different entities of Kong in different ways, including:
[0042] Global plugin: Applies to all services and routes and is not associated with any specific API or consumer.
[0043] Service (service plug-in): acts on a specific service, and all requests related to the service will execute the plug-in.
[0044] Route (routing plugin): acts on a specific route, and only requests that match the route will execute the plugin.
[0045] When processing a request, Kong works according to the following process:
[0046] First, the client sends a request to Kong. Kong matches the request according to the Route routing rules and finds the corresponding Service. Kong forwards the request to the Upstream defined in the service. The Upstream distributes the request to one or more Target targets (specific instances of the upstream service) based on the load balancing strategy. In addition, the present application sets a diversion plug-in between the service and the Upstream to perform traffic scheduling based on the relevant rules set by the gateway traffic scheduling platform, so as to realize traffic scheduling for different service versions at the gateway level.
[0047] The registration center provides basic capabilities such as service registration, service discovery, and service health check, allowing developers to easily manage services. The registration center provides corresponding services, which are software functions provided to clients through predefined interface network access. For each service, there are multiple service instances, and the service instance provides one or more processes with accessible network addresses (IP:Port) for the service. The service provider puts its own instance on the registration center. The caller dynamically obtains the addresses of n instances on the service through the registration center.
[0048] The synchronization service component is used for data synchronization from the registration center to the gateway kong. The synchronization service component is named nacosSync, and its function is to synchronize the instance of the registration center service to the upstream of kong as a target. For example, when registering service x, instance a of service x is registered with the registration center, and the synchronization service component nacosSync listens to the registration event of the registration center, and writes the instance a of service x to the upstream named xUpstream of kong as one of the targets. When instance b of service x goes offline from the registration center, the synchronization service component nacosSync listens to the registration event of the registration center, and compares instance b of service x to all targets on the upstream named xUpstream of kong. If there is a target whose IP port is the same as instance b, remove it.
[0049] like Figure 2 As shown, through service instance synchronization, service instances such as service instance.xxx, service instance.abc, and service instance.yyy are synchronized to the gateway to process the corresponding service requests.
[0050] Based on the above traffic scheduling system, when traffic scheduling of different service versions is required, it is only necessary to issue corresponding rules on the gateway traffic scheduling platform according to the traffic scheduling strategy, so that the gateway can find the corresponding service instance for the service request demand scheduling according to the rules. The gateway receives the service request and determines the service requested by the service request, which is defined as the target service. Based on the target service, a pre-configured set of upstream service instances can be determined to select a service instance as the target instance to process the currently received service request.
[0051] S120. Determine the pre-configured traffic diversion rules for the target service according to the traffic identifier of the service request, and query the pre-configured node grouping rules of the upstream service instance set based on the traffic diversion rules. The traffic diversion rules include a mapping relationship between the traffic identifier and the traffic scheduling label, and the node grouping rules include a mapping relationship between the traffic scheduling label and the corresponding service instance.
[0052] Specifically, before receiving the service request from the user, the following steps are included:
[0053] When synchronizing the target instance from the registration center to the upstream service instance set, the receiving gateway traffic scheduling platform configures the traffic diversion rules and node grouping rules for the corresponding target instance. The traffic diversion rules are built based on the traffic identifier and traffic scheduling label entered by the user when creating the target instance, and the node grouping rules are built based on the traffic scheduling label entered by the user when creating the target instance.
[0054] Based on the traffic scheduling requirements, the gateway traffic scheduling platform will simultaneously configure traffic diversion rules and node grouping rules when registering different service instances to the registration center for a service. The traffic diversion rules include the mapping relationship between traffic identifiers and traffic scheduling labels, and the node grouping rules include the mapping relationship between traffic scheduling labels and corresponding service instances. The traffic diversion rules are sent to the diversion plug-in, and the node grouping rules are synchronized to the upstream service instance set of the gateway through the synchronization service, so that the corresponding target service instance can be determined based on the received service request.
[0055] Among them, based on the actual traffic scheduling strategy, the user can enter the traffic identifier and traffic scheduling label of the corresponding service instance when creating a new version of the service instance. Based on the traffic scheduling label and traffic identifier, the corresponding traffic diversion rules can be constructed. Based on the user-created service instance and traffic scheduling label, the node grouping rules can be obtained.
[0056] Based on the above-mentioned pre-built traffic diversion rules and node diversion rules, based on the mapping relationship between the traffic identifier and the traffic scheduling label contained in the traffic diversion rules, and the mapping relationship between the traffic scheduling label and the corresponding service instance contained in the node grouping rules, the pre-configured traffic diversion rules of the target service can be determined according to the traffic identifier of the service request, and then the pre-configured node grouping rules of the upstream service instance set are queried based on the traffic diversion rules. The node grouping rules identify the corresponding version of the service instance that processes the current service request.
[0057] Optionally, the traffic identifier of the traffic diversion rule includes a target identifier and a target parameter value configured for the corresponding service request;
[0058] Determine the traffic diversion rules pre-configured for the target service based on the traffic identifier of the service request, including:
[0059] The traffic diversion rule is compared with the traffic identifier of the service request to determine the traffic diversion rule whose target identifier and target parameter value match the traffic identifier of the service request.
[0060] It is used to configure traffic scheduling labels for different versions of the same service according to the actual traffic scheduling strategy. For example, for service requests corresponding to the same target service, add a traffic scheduling label to the service request whose user ID uid (i.e. target ID) in the request header is 123. If it is a blue-green release strategy, the traffic scheduling label a can be a dyed label of the corresponding color, and the target parameter value a is further set to 1. For the service request, if the uid in the request header of the service request is 123 and the value of a is 1, the corresponding traffic diversion rule can be determined, and then the corresponding node grouping rule can be found according to the traffic diversion rule.
[0061] S130 . Determine a target instance based on the queried node grouping rule, and send the service request to the target instance for processing.
[0062] After that, according to the mapping relationship between the traffic scheduling label and the corresponding service instance defined by the node grouping rule, the corresponding service instance is selected as the target instance in the upstream service instance set. The target instance is the service instance of the corresponding version used to process the current service request.
[0063] According to the actual traffic scheduling requirements, you only need to pre-configure traffic diversion rules and node grouping rules for service instances of different versions of the same target service. You can then determine the target instance to process the service request based on the traffic diversion rules and node grouping rules hit by the target service, thereby achieving traffic scheduling for different service versions at the gateway level, while simplifying the implementation process and reducing implementation complexity.
[0064] Specifically, taking the blue-green release strategy configuration as an example, according to the actual traffic scheduling requirements, the user configures service instances of different service versions in the configuration interface of the gateway traffic scheduling platform. Assume that the upstream service instance set corresponding to the target service has 3 service instance nodes, and none of them are configured with traffic scheduling labels. After the user clicks the "Turn on blue-green release" button, the configuration interface of the target service pops up. The user can create a new coloring group color (that is, traffic scheduling label), assuming that two new colors, red and blue, are created. Based on the newly created coloring group color, the user takes offline one of the unlabeled (uncolored) service instances, and then goes online with a service instance with a color of red. When registering the service in the registration center, the metadata has the color red. Through synchronization nacosSync, it is synchronized to the upstream service instance set of kong. After the operation is completed, the red coloring group is configured with a corresponding service instance. The user further clicks the "Introduce Traffic" button and fills in the rules, such as Figure 3 As shown in the figure, it can be seen that the user sets the header name a, the service request with a value of 1, and is routed to the red service instance; the request with the header name b and a value that matches the regular expression ^[0-9].* is routed to the blue service instance.
[0065] Based on the above configuration, traffic diversion rules and node grouping rules can be generated and configured in the gateway. Figure 4 For requests with header name a and value 1, they will be routed to the red service instance through the diversion plug-in. If the blue service instance is not registered, the configuration will not take effect.
[0066] Optionally, after determining the traffic diversion rule preconfigured for the target service according to the traffic identifier of the service request, the method further includes:
[0067] When no node grouping rule pre-configured for the upstream service instance set is found based on the traffic diversion rule, the service request is sent to a designated candidate node of the upstream service instance set for processing.
[0068] For requests with header name b and value regular matching ^[0-9].*, they should normally be routed to the service instance of blue color. However, because there is no service instance registered for blue color, they need to be routed to the alternative service instance. The designated alternative nodes include the associated region target instance, the region benchmark instance to which they belong, and the associated region benchmark instance, which are set in the order of alternative scheduling priority. The associated region target instance is pre-configured with a traffic scheduling label, while the region benchmark instance to which they belong and the associated region benchmark instance are not configured with a traffic scheduling label. According to the actual scheduling requirements, the corresponding service instance can be adaptively configured to route the service request to the corresponding service instance for processing.
[0069] Optionally, the node grouping rule is configured based on a grayscale release strategy or a blue-green release strategy. When the node grouping rule corresponds to the blue-green release strategy configuration, the node grouping rule further includes call link information corresponding to the traffic scheduling label configuration;
[0070] After the service request is sent to the target instance for processing, it includes:
[0071] Add traffic scheduling tags to the service request and transparently transmit the service request to the downstream instance node of the target instance based on the call link information.
[0072] Grayscale release is to gradually introduce the new version into the production environment, and only direct a small part of the new version's traffic to the new function or service. By registering the corresponding new version and configuring the corresponding traffic diversion rules and node grouping rules, a small part of the new version's traffic can be directed to the new service instance for processing.
[0073] For color release, create several new versions of service instances and configure corresponding traffic diversion rules and node grouping rules. Different versions correspond to different color labels (traffic scheduling labels). Then match the traffic and service instances, and route the traffic of a certain color label to the service instance of the corresponding color. In addition, color release also requires the service request to be transparently transmitted to the entire call link. Figure 5 As shown in the figure, the service request carrying the colored label will be passed to the next service instance for processing, and so on, until the service processing of the entire call link is completed.
[0074] After transparently transmitting the service request to the downstream instance node of the target instance based on the call link information, it includes:
[0075] When the blue-green release strategy is completed, the target instance and the corresponding configured traffic diversion rules and node grouping rules are deleted, and the service request of the corresponding target service is routed to the specified service instance in the upstream service instance set for processing. The specified service instance is not configured with the corresponding traffic scheduling label.
[0076] After completing the blue-green release strategy, for service instances carrying colored labels, the corresponding configured traffic diversion rules and node grouping rules can be deleted in the registration center. At this time, the service instance information deleted by the synchronization service is synchronized to the upstream service instance set, and the service instance carrying the colored label in the upstream service instance set is deleted. After that, the service request for the target service will be routed to the specified service instance in the upstream service instance set that does not carry the colored label for processing. The specified service instance can be the above-mentioned regional benchmark instance and the associated regional benchmark instance.
[0077] In the above, by receiving the service request from the user end, the target service of the service request is determined, and the target service pre-configures a set of mapped upstream service instances. The upstream service instance set includes at least one service instance that processes the service request. The service instance is registered from the registration center and synchronized to the upstream service instance set based on the synchronization service; the traffic diversion rule pre-configured for the target service is determined according to the traffic identifier of the service request, and the node grouping rule pre-configured for the upstream service instance set is queried based on the traffic diversion rule. The traffic diversion rule includes a mapping relationship between the traffic identifier and the traffic scheduling label, and the node grouping rule includes a mapping relationship between the traffic scheduling label and the corresponding service instance; the target instance is determined based on the queried node grouping rule, and the service request is sent to the target instance for processing. By adopting the above technical means, the traffic diversion rule pre-configured for the target service is determined by the traffic identifier of the service request, and the node grouping rule pre-configured for the upstream service instance set is queried based on the traffic diversion rule, and then the service request is sent to the target instance for processing by determining the target instance. In this way, traffic scheduling of different service versions can be realized at the gateway, and the service request can be sent to the corresponding service instance for processing according to the traffic scheduling requirements. Avoid the situation where different modules collaborate to develop traffic scheduling codes, which makes it difficult to implement traffic scheduling for different service versions, and reduce the implementation cost and difficulty of the traffic scheduling system.
[0078] Based on the above embodiments, Figure 6 A schematic diagram of the structure of a gateway traffic scheduling system provided by this application. Figure 6 The gateway traffic scheduling system provided in this embodiment specifically includes: a target determination module 21, a rule determination module 22 and a scheduling module 23.
[0079] The target determination module 21 is configured to receive a service request from a user terminal, determine a target service of the service request, pre-configure a mapped upstream service instance set for the target service, the upstream service instance set includes at least one service instance that processes the service request, and the service instance is registered from a registration center and synchronized to the upstream service instance set based on a synchronization service;
[0080] The rule determination module 22 is configured to determine the traffic diversion rule preconfigured for the target service according to the traffic identifier of the service request, and query the node grouping rule preconfigured for the upstream service instance set based on the traffic diversion rule, the traffic diversion rule includes a mapping relationship between the traffic identifier and the traffic scheduling label, and the node grouping rule includes a mapping relationship between the traffic scheduling label and the corresponding service instance;
[0081] The scheduling module 23 is configured to determine the target instance based on the queried node grouping rule, and send the service request to the target instance for processing.
[0082] Specifically, before receiving the service request from the user terminal, the method includes:
[0083] When synchronizing the target instance from the registration center to the upstream service instance set, the receiving gateway traffic scheduling platform configures the traffic diversion rules and node grouping rules for the corresponding target instance. The traffic diversion rules are built based on the traffic identifier and traffic scheduling label entered by the user when creating the target instance, and the node grouping rules are built based on the traffic scheduling label entered by the user when creating the target instance.
[0084] The traffic identifier of the traffic diversion rule includes a target identifier and a target parameter value configured for the corresponding service request;
[0085] Determine the traffic diversion rules pre-configured for the target service based on the traffic identifier of the service request, including:
[0086] The traffic diversion rule is compared with the traffic identifier of the service request to determine the traffic diversion rule whose target identifier and target parameter value match the traffic identifier of the service request.
[0087] Specifically, the node grouping rule is based on the grayscale release strategy or the blue-green release strategy configuration. When the node grouping rule corresponds to the blue-green release strategy configuration, the node grouping rule also includes the call link information corresponding to the traffic scheduling label configuration;
[0088] After the service request is sent to the target instance for processing, it includes:
[0089] Add traffic scheduling tags to the service request and transparently transmit the service request to the downstream instance node of the target instance based on the call link information.
[0090] After transparently transmitting the service request to the downstream instance node of the target instance based on the call link information, it includes:
[0091] When the blue-green release strategy is completed, the target instance and the corresponding configured traffic diversion rules and node grouping rules are deleted, and the service request of the corresponding target service is routed to the specified service instance in the upstream service instance set for processing. The specified service instance is not configured with the corresponding traffic scheduling label.
[0092] After determining the traffic diversion rule pre-configured for the target service according to the traffic identifier of the service request, the following is also included:
[0093] When no node grouping rule pre-configured for the upstream service instance set is found based on the traffic diversion rule, the service request is sent to a designated candidate node of the upstream service instance set for processing.
[0094] The designated candidate nodes include the associated regional target instance, the belonging regional benchmark instance and the associated regional benchmark instance set in the order of the candidate scheduling priority. The associated regional target instance is pre-configured with a traffic scheduling label, and the belonging regional benchmark instance and the associated regional benchmark instance are not configured with a traffic scheduling label.
[0095] In the above, by receiving the service request from the user end, the target service of the service request is determined, and the target service pre-configures a set of mapped upstream service instances. The upstream service instance set includes at least one service instance that processes the service request. The service instance is registered from the registration center and synchronized to the upstream service instance set based on the synchronization service; the traffic diversion rule pre-configured for the target service is determined according to the traffic identifier of the service request, and the node grouping rule pre-configured for the upstream service instance set is queried based on the traffic diversion rule. The traffic diversion rule includes a mapping relationship between the traffic identifier and the traffic scheduling label, and the node grouping rule includes a mapping relationship between the traffic scheduling label and the corresponding service instance; the target instance is determined based on the queried node grouping rule, and the service request is sent to the target instance for processing. By adopting the above technical means, the traffic diversion rule pre-configured for the target service is determined by the traffic identifier of the service request, and the node grouping rule pre-configured for the upstream service instance set is queried based on the traffic diversion rule, and then the service request is sent to the target instance for processing by determining the target instance. In this way, traffic scheduling of different service versions can be realized at the gateway, and the service request can be sent to the corresponding service instance for processing according to the traffic scheduling requirements. Avoid the situation where different modules collaborate to develop traffic scheduling codes, which makes it difficult to implement traffic scheduling for different service versions, and reduce the implementation cost and difficulty of the traffic scheduling system.
[0096] The gateway traffic scheduling system provided in the embodiment of the present application can be configured to execute the gateway traffic scheduling method provided in the above embodiment, and has corresponding functions and beneficial effects.
[0097] Based on the above practical example, the present application embodiment also provides a gateway traffic scheduling device, referring to Figure 7 , the gateway traffic scheduling device includes: a processor 31, a memory 32, a communication module 33, an input device 34 and an output device 35. The memory, as a computer-readable storage medium, can be configured to store software programs, computer executable programs and modules, such as program instructions / modules corresponding to the gateway traffic scheduling method described in any embodiment of the present application (for example, a target determination module, a rule determination module and a scheduling module in the gateway traffic scheduling system). The communication module is configured to perform data transmission. The processor executes various functional applications and data processing of the device by running the software programs, instructions and modules stored in the memory, that is, realizing the above-mentioned gateway traffic scheduling method. The input device can be configured to receive input digital or character information, and generate key signal input related to the user settings and function control of the device. The output device may include a display device such as a display screen. The gateway traffic scheduling device provided above can be configured to execute the gateway traffic scheduling method provided in the above-mentioned embodiment, and has corresponding functions and beneficial effects.
[0098] On the basis of the above embodiments, the embodiments of the present application further provide a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer-executable instructions, wherein the computer-executable instructions are configured to execute a gateway traffic scheduling method when executed by a computer processor, and the storage medium may be any of various types of memory devices or storage devices. Of course, the non-volatile computer-readable storage medium provided in the embodiments of the present application, whose computer-executable instructions are not limited to the gateway traffic scheduling method described above, can also execute the related operations in the gateway traffic scheduling method provided in any embodiment of the present application.
[0099] On the basis of the above embodiments, the embodiments of the present application also provide a computer program product. The technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer program product is stored in a storage medium, including a number of instructions for enabling a computer device, a mobile terminal or a processor therein to execute all or part of the steps of the gateway traffic scheduling method described in each embodiment of the present application.
Claims
1. A gateway traffic scheduling method, characterized in that: include: Receive a service request from a user, determine a target service of the service request, the target service pre-configures a mapped upstream service instance set, the upstream service instance set includes at least one service instance that processes the service request, the service instance is registered from a registration center and synchronized to the upstream service instance set based on a synchronization service; Determine the traffic diversion rule preconfigured for the target service according to the traffic identifier of the service request, and query the node grouping rule preconfigured for the upstream service instance set based on the traffic diversion rule, wherein the traffic diversion rule includes a mapping relationship between the traffic identifier and the traffic scheduling label, and the node grouping rule includes a mapping relationship between the traffic scheduling label and the corresponding service instance; The target instance is determined based on the queried node grouping rule, and the service request is sent to the target instance for processing.
2. The gateway traffic scheduling method according to claim 1, characterized in that: The node grouping rule is configured based on a grayscale release strategy or a blue-green release strategy. When the node grouping rule corresponds to the blue-green release strategy configuration, the node grouping rule further includes call link information corresponding to the traffic scheduling label configuration; After sending the service request to the target instance for processing, the method further comprises: The traffic scheduling tag is added to the service request, and the service request is transparently transmitted to the downstream instance node of the target instance based on the call link information.
3. The gateway traffic scheduling method according to claim 2, characterized in that: After transparently transmitting the service request to the downstream instance node of the target instance based on the call link information, the method further includes: When the blue-green release strategy is completed, the target instance and the corresponding configured traffic diversion rules and node grouping rules are deleted, and the service request corresponding to the target service is routed to the designated service instance of the upstream service instance set for processing. The designated service instance is not configured with the corresponding traffic scheduling label.
4. The gateway traffic scheduling method according to claim 1, characterized in that: Before receiving the service request from the user, the method includes: When synchronizing the target instance from the registration center to the upstream service instance set, the receiving gateway traffic scheduling platform configures the traffic diversion rule and the node grouping rule corresponding to the target instance, wherein the traffic diversion rule is constructed based on the traffic identifier and the traffic scheduling label entered by the user when creating the target instance, and the node grouping rule is constructed based on the traffic scheduling label entered by the user when creating the target instance.
5. The gateway traffic scheduling method according to claim 4, characterized in that: The traffic identifier of the traffic diversion rule includes a target identifier and a target parameter value configured corresponding to the service request; The determining of the traffic diversion rule preconfigured for the target service according to the traffic identifier of the service request includes: The traffic diversion rule is compared with the traffic identifier of the service request to determine the traffic diversion rule in which the target identifier and the target parameter value match the traffic identifier of the service request.
6. The gateway traffic scheduling method according to any one of claims 1 to 5, characterized in that: After determining the traffic diversion rule preconfigured for the target service according to the traffic identifier of the service request, the method further includes: When no node grouping rule pre-configured for the upstream service instance set is found based on the traffic diversion rule, the service request is sent to a designated candidate node of the upstream service instance set for processing.
7. The gateway traffic scheduling method according to claim 6, characterized in that: The designated candidate node includes an associated large-area target instance, a belonging large-area benchmark instance and an associated large-area benchmark instance arranged in the order of alternative scheduling priority. The associated large-area target instance is pre-configured with the traffic scheduling label, and the belonging large-area benchmark instance and the associated large-area benchmark instance are not configured with the traffic scheduling label.
8. A gateway traffic scheduling system, characterized in that: include: A target determination module is configured to receive a service request from a user terminal, determine a target service of the service request, the target service pre-configures a mapped upstream service instance set, the upstream service instance set includes at least one service instance that processes the service request, and the service instance is registered from a registration center and synchronized to the upstream service instance set based on a synchronization service; A rule determination module, configured to determine the traffic diversion rule preconfigured for the target service according to the traffic identifier of the service request, and query the node grouping rule preconfigured for the upstream service instance set based on the traffic diversion rule, wherein the traffic diversion rule includes a mapping relationship between the traffic identifier and the traffic scheduling label, and the node grouping rule includes a mapping relationship between the traffic scheduling label and the corresponding service instance; The scheduling module is configured to determine a target instance based on the queried node grouping rule, and send the service request to the target instance for processing.
9. A gateway traffic scheduling device, characterized in that: include: memory and one or more processors; The memory is configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the gateway traffic scheduling method as described in any one of claims 1-7.
10. A non-volatile computer-readable storage medium, characterized in that: The non-volatile computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a computer processor, they are configured to execute the gateway traffic scheduling method according to any one of claims 1-7.
11. A computer program product, characterized in that The computer program product includes instructions, and when the instructions are executed on a computer or a processor, the computer or the processor executes the gateway traffic scheduling method as described in any one of claims 1-7.