Route control method and device, computer device and storage medium

Abstract

The embodiment of the application belongs to the technical field of routing and relates to a routing control method, which comprises the following steps: receiving an access request for a service through a gateway server; acquiring a gray-scale policy in the gateway server, the gray-scale policy being pre-written based on routing requirements and stored in the gateway server, the gray-scale policy being used for routing control; determining a service version corresponding to the access request based on the gray-scale policy, and routing the access request to a server supporting the service version through the gateway server, wherein the service has multiple service versions, the service is currently deployed in at least one deployment mode, and the deployment mode comprises static deployment and dynamic deployment. The application further provides a routing control device, a computer device and a storage medium. In the gray-scale release, the application realizes routing supporting both static deployment and dynamic deployment of a service.

Description

Technical Field

[0001] This application relates to the field of routing technology, and in particular to a routing control method, apparatus, computer equipment, and storage medium. Background Technology

[0002] Canary release is a common deployment technique where a subset of users are routed to a new version of the service for a safe transition. Services can be deployed statically or dynamically. Existing routing technologies typically use Nginx, a high-performance HTTP and reverse proxy web server. However, Nginx can only combine canary releases with static or dynamic deployments. Specifically, it cannot route requests to services with the same deployment method; it cannot route to both statically and dynamically deployed services simultaneously during a canary release. This limitation introduces numerous inconveniences to service deployment and canary releases. Summary of the Invention

[0003] The purpose of this application is to provide a routing control method, apparatus, computer device, and storage medium to achieve routing that simultaneously supports static and dynamic service deployment during canary releases.

[0004] To address the aforementioned technical problems, this application provides a routing control method, employing the following technical solution:

[0005] The gateway server receives access requests for the service.

[0006] Obtain the grayscale policy from the gateway server. The grayscale policy is pre-written based on routing requirements and stored in the gateway server. The grayscale policy is used for routing control.

[0007] The service version corresponding to the access request is determined based on the gray-scale policy, and the access request is routed to a server that supports the service version through the gateway server. The service has multiple service versions, and the service is currently deployed in at least one deployment method, including static deployment and dynamic deployment.

[0008] To address the aforementioned technical problems, this application also provides a routing control device, which employs the following technical solution:

[0009] The request receiving module is used to receive access requests for services through the gateway server.

[0010] The policy acquisition module is used to acquire the gray-scale policy in the gateway server. The gray-scale policy is pre-written based on routing requirements and stored in the gateway server. The gray-scale policy is used for routing control.

[0011] The request routing module is used to determine the service version corresponding to the access request based on the gray-scale policy, and to route the access request to a server that supports the service version through the gateway server. The service has multiple service versions, and the service is currently deployed in at least one deployment method, including static deployment and dynamic deployment.

[0012] To address the aforementioned technical problems, this application also provides a computer device, which includes a memory and a processor. The memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the routing control method described above.

[0013] To address the aforementioned technical problems, this application also provides a computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of the routing control method described above.

[0014] Compared with the prior art, the embodiments of this application have the following main advantages: Access requests for services are received through a gateway server, which stores canary release policies. Services can be canary released and have multiple different service versions. The canary release policies are independently written according to requirements, enabling various routing controls. During canary release, the service version corresponding to the access request is determined based on the canary release policy, and the access request is routed to a server supporting the service version through the gateway server. The service is currently deployed in at least one deployment method, including static deployment and dynamic deployment. This application achieves simultaneous support for both static and dynamic service deployment through an independent canary release policy, reducing limitations on service deployment during canary release. Attached Figure Description

[0015] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is an exemplary system architecture diagram to which this application can be applied;

[0017] Figure 2This is a flowchart of an embodiment of the routing control method according to this application;

[0018] Figure 3 This is a schematic diagram of a structure of one embodiment of the routing control device according to this application;

[0019] Figure 4 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0021] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0023] like Figure 1 As shown, system architecture 100 may include terminal devices 101 and 102, network 103, gateway server 104, and servers 105 and 106. Network 103 serves as the medium for providing communication links between terminal devices 101 and 102, gateway server 104, and servers 105 and 106. Network 103 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0024] Users can use terminal devices 101 and 102 to interact with gateway server 104 and servers 105 and 106 via network 103 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101 and 102, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0025] Terminal devices 101 and 102 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), laptops, and desktop computers, etc.

[0026] Gateway server 104 stores a gray-scale policy, which can route access requests; gateway server 104 can also support service versions, such as statically deploying services on gateway server 104.

[0027] Servers 105 and 106 can be servers that provide various services, such as backend servers that support the pages displayed on terminal devices 101 and 102. Service versions are deployed on servers 105 and 106, for example, services can be statically or dynamically deployed on servers 105 and 106.

[0028] It should be noted that the routing control method provided in this application embodiment is generally executed by the gateway server, and correspondingly, the routing control device is generally set in the gateway server.

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

[0030] Continue to refer to Figure 2 A flowchart of an embodiment of the routing control method according to this application is shown. The routing control method includes the following steps:

[0031] Step S201: Receive access requests for services through the gateway server.

[0032] In this embodiment, the routing control method operates on electronic devices (e.g., Figure 1 The gateway server shown can communicate with the terminal device or server via wired or wireless connections. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G / 5G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra-wideband) connections, and other currently known or future-developed wireless connection methods.

[0033] Services refer to software objects that can provide users with various functions, such as web pages.

[0034] Specifically, users can operate the terminal to initiate access requests for services. These access requests are used to obtain information from the service. For example, when the service is a webpage, the access request can be used to request webpage resource files so that the terminal can load the webpage based on the webpage resource files and enable users to use various functions on the webpage.

[0035] Access requests are received by the gateway server. The gateway server can be built on OpenResty, also known as ngx_openresty, a high-performance web platform based on Nginx and Lua, which integrates a large number of Lua libraries, third-party modules, and most dependencies. In this application, the gateway server acts as a proxy routing service. Besides being built on OpenResty, the gateway server can also be built on other proxy services, such as Nginx, Cloudflare, or based on a custom-written proxy service implementation.

[0036] Step S202: Obtain the grayscale policy from the gateway server. The grayscale policy is pre-written based on routing requirements and stored in the gateway server. The grayscale policy is used for routing control.

[0037] Specifically, the services in this application can be released in a gray-scale manner, so the services can have multiple different service versions. The content and functions of different service versions are different. For example, service version V1.0 does not provide a check-in function, while service version V2.0 provides a check-in function.

[0038] Therefore, this application requires routing access requests so that the appropriate service version can handle them. A canary deployment strategy is pre-configured in the gateway server. This strategy is written by developers based on routing requirements and stored on the gateway server. The canary deployment strategy determines how access requests are routed, and it can achieve routing control entirely based on routing requirements.

[0039] Step S203: Determine the service version corresponding to the access request based on the gray-scale strategy, and route the access request to the server that supports the service version through the gateway server. The service has multiple service versions, and the service is currently deployed in at least one deployment method, including static deployment and dynamic deployment.

[0040] Specifically, each service version is deployed on a server. The service version corresponding to the access request is determined according to the canary release policy, and the gateway server routes the access request to the server that supports the service version.

[0041] The services in this application can be deployed in at least one deployment method, including static deployment and dynamic deployment. That is, the services can be deployed statically and dynamically at the same time, and multiple different service versions can be deployed statically and dynamically at the same time.

[0042] Typically, canary deployments rely on Nginx for routing. Nginx can only support a combination of canary deployments and static deployments, or a combination of canary deployments and dynamic deployments; that is, when routing, Nginx requires a service to have only one deployment method. The gateway server in this application uses a separately written canary deployment strategy for routing control, instead of using Nginx methods. The canary deployment strategy is pre-written by developers according to requirements and then written into the gateway server. The gateway server makes routing decisions based on this new canary deployment strategy and no longer restricts the service's deployment method. It is important to note that although the routing server in this application can be built on proxy services such as OpenResty, Nginx, and Cloudflare, the gateway server only uses the basic capabilities of the proxy service. Other capabilities, such as routing control, are implemented based on the separately written canary deployment strategy to overcome the functional limitations of existing proxy services.

[0043] In this embodiment, access requests for services are received through a gateway server. The gateway server stores canary release policies, allowing services to be released in canary phases and having multiple different service versions. The canary release policies are independently written according to requirements and can implement various routing controls. During canary release, the service version corresponding to the access request is determined based on the canary release policy, and the access request is routed to a server that supports the service version through the gateway server. The service is currently deployed in at least one deployment method, including static deployment and dynamic deployment. This application achieves routing that simultaneously supports both static and dynamic service deployment through an independent canary release policy, reducing the limitations on service deployment during canary release.

[0044] Furthermore, after step S201 above, the method may also include: obtaining the service type of the service; when the service type is a non-grayscale service, routing the access request to the server that supports the service; when the service type is a grayscale service, obtaining the grayscale policy in the gateway server.

[0045] Specifically, after receiving an access request for a service, the gateway server first obtains the service type. The service type is determined by whether the service is subject to canary release, including non-canary services and canary services. Non-canary services do not involve canary release, and in this case, the service version and server are unique, so the access request can be directly routed to the server that supports the service. Canary services involve canary release, and in this case, the gateway server needs to obtain the canary policy in order to use the canary policy for routing.

[0046] In this embodiment, the service type of the service is obtained. When the service type is a non-grayscale service, the service does not involve grayscale, and the access request can be directly routed to the server that supports the service. When the service type is a grayscale service, the service involves grayscale, and the grayscale policy is obtained so that routing can be implemented according to the grayscale policy.

[0047] Furthermore, the steps for determining the service version corresponding to the access request based on the gray-scale policy may include: when a specified version exists in the gray-scale policy, determining the specified version as the service version corresponding to the access request; when no specified version exists in the gray-scale policy, extracting request parameters from the access request, wherein the request parameters include locator parameters, access object identifier, traffic source identifier, and Internet Protocol address; and determining the service version corresponding to the access request based on the gray-scale policy and the request parameters.

[0048] Specifically, a canary release strategy can record a specific version, which is a predefined service version. Even if a service involves canary releases, the canary release strategy can be used to set whether canary releases are currently enabled; whether a specific version is recorded in the canary release strategy can be seen as a switch to enable or disable canary releases. Furthermore, the specific version in the canary release strategy can be switched at any time, allowing for real-time modifications.

[0049] When a specified version exists in the gray-scale strategy, the specified version will be determined as the service version corresponding to the access request; the specified version can be any one of the current service versions.

[0050] When a specified version is not specified in the gray-scale strategy, it indicates that gray-scale deployment is enabled, and request parameters are extracted from the access request. Request parameters are detailed parameters contained in the access request, including locator parameters, access object identifier, traffic source identifier, and Internet Protocol address. The concept of each request parameter will be described in detail later.

[0051] The grayscale strategy describes the logic for routing based on request parameters. Based on the grayscale strategy and request parameters, the service version corresponding to the access request can be determined.

[0052] In this embodiment, the specified version is the specified service version. Whether the specified version is recorded in the gray-scale policy determines whether gray-scale is enabled. When the specified version exists in the gray-scale policy, the specified version is directly determined as the service version corresponding to the access request. When the specified version does not exist, the request parameters are extracted from the access request, and the service version corresponding to the access request is determined according to the gray-scale policy and the request parameters to realize gray-scale routing.

[0053] Furthermore, when the request parameter is a locator parameter, the steps described above for determining the service version corresponding to the access request based on the grayscale strategy and the request parameter may include: querying the service version corresponding to the locator parameter in the grayscale strategy; and determining the service version corresponding to the locator parameter as the service version corresponding to the access request.

[0054] Specifically, the access request contains a URL (Uniform Resource Locator, which is a concise representation of the location and access method of a resource that can be obtained from the Internet; it is the address of a standard resource on the Internet).

[0055] When users enter a URL, they can add locator parameters to the URL. Different locator parameters correspond to different service versions. The gateway server retrieves the locator parameters from the URL, queries the gray-scale policy for the corresponding service version, and determines the service version corresponding to the locator parameter as the service version for the access request.

[0056] In one embodiment, the locator parameter is made available to personnel of the service provider, such as testers. Using the locator parameter, users can directly access the service version and quickly conduct tests without being affected by canary releases.

[0057] In this embodiment, the service version corresponding to the locator parameter is queried in the grayscale strategy, and the service version is determined as the service version corresponding to the access request, thus realizing routing based on the locator parameter.

[0058] Furthermore, when the request parameter is an access object identifier, the steps described above for determining the service version corresponding to the access request based on the grayscale strategy and the request parameter may include: obtaining the object cache data corresponding to the access object identifier; extracting the service version and grayscale version from the object cache data; extracting the grayscale version from the grayscale strategy; and when the grayscale version in the object cache data is consistent with the grayscale version in the grayscale strategy, determining the service version in the object cache data as the service version corresponding to the access request.

[0059] Specifically, this embodiment mainly ensures consistency in accessing service versions. When a user accesses a certain service version, object cache data is generated. Object cache data, also known as cookies, refers to data (usually encrypted) stored by a service (such as a website) to identify the user, and it conforms to the RFC6265 standard.

[0060] The access object identifier is used to identify the accessed object, such as the name of the user's account, the terminal's Internet Protocol address, or physical address. The object cache data corresponding to the access object identifier is retrieved. This cache data contains a service version and a grayscale version. The service version refers to the service version the user last accessed. For example, if the user last accessed service version V1.0, the service version recorded in the object cache data is V1.0. The grayscale version refers to the version used in grayscale testing. For example, in the first round of grayscale testing, the service versions are V1.0 and V2.0, and the grayscale version is recorded as 1.0.0; in the second round of grayscale testing, the service versions are V1.0 and V3.0, and the grayscale version is recorded as 1.0.1; or, if the grayscale strategy is adjusted during the second round of grayscale testing, the grayscale version is recorded as 1.0.1.

[0061] Then, the grayscale version in the grayscale strategy is retrieved, and the grayscale version in the object cache data is compared with the grayscale version in the grayscale strategy. If they match, the consistency of the access version is maintained, and the service version in the object cache data is determined as the service version corresponding to the access request, ensuring that the user's current access to the same service version as before. If they do not match, it indicates that a new round of grayscale has been started, and the object cache data needs to be cleared and routing re-established. A new round of grayscale can be started at any time using the grayscale version in the grayscale strategy.

[0062] In this embodiment, the object cache data corresponding to the access object identifier is obtained, and the service version and grayscale version are extracted from it. The grayscale version in the grayscale strategy is also extracted. When the two grayscale versions are consistent, the service version in the object cache data is determined as the service version corresponding to the access request, which ensures the consistency of user access and realizes routing based on the access object identifier.

[0063] Furthermore, when the request parameter is a traffic source identifier, the steps of determining the service version corresponding to the access request based on the grayscale policy and the request parameter may include: when the traffic source identifier is a first source identifier, querying the service version corresponding to the first source identifier in the grayscale policy; and determining the service version corresponding to the first source identifier as the service version corresponding to the access request.

[0064] Specifically, the traffic source identifier indicates the source of the access request traffic, which includes a first source identifier and a second source identifier. In one embodiment, the first source identifier indicates that the traffic is paid traffic, and the second source identifier indicates that the traffic is free traffic. Here, paid and free traffic refer to the service operator. The service operator can place advertisements and other marketing information on the Internet. When a user accesses the service through advertising links or other marketing information, the traffic is paid traffic, and the access request contains the first source identifier. If the user does not access the service through advertising links or other marketing information, the traffic is free traffic, and the access request contains the second source identifier.

[0065] The first source identifier can be a series of parameters, such as `utm_source` and `utm_term`, added by the service operator to the URL of the ad placement. These parameters are used to track the source of traffic for data analysis. For example, an ad placed on the website 'aaa' might include parameters like `utm_channel=aaa` in the URL. When a user accesses the site through this URL, the gateway server obtains these parameters. The first source identifier determines the corresponding service version. Specifically, the service version corresponding to the first source identifier can be queried in the canary deployment strategy, and this service version is then determined as the service version corresponding to the access request. It can be understood that the service operator can modify the canary deployment strategy, thereby modifying the service version corresponding to the first source identifier.

[0066] In this embodiment, when the traffic source identifier is the first source identifier, the service version corresponding to the first source identifier is queried in the grayscale strategy; the service version corresponding to the first source identifier is determined as the service version corresponding to the access request, thus realizing routing based on the traffic source identifier. The traffic source identifier is related to the business, thus realizing the combination of routing and business.

[0067] Furthermore, when the traffic source identifier is a second source identifier, the steps for determining the service version corresponding to the access request based on the grayscale strategy and request parameters may further include: obtaining the Internet Protocol address in the request parameters; performing a hash operation on the Internet Protocol address to obtain a hash value; performing a modulo operation on the hash value to obtain a modulo result; obtaining the proportional allocation information in the grayscale strategy; determining the service version corresponding to the modulo result based on the proportional allocation information, and determining the service version corresponding to the modulo result as the service version corresponding to the access request.

[0068] Specifically, when the traffic source identifier is a second source identifier, the Internet Protocol address (also called IP address) in the request parameters is obtained. This Internet Protocol address is the terminal's Internet Protocol address.

[0069] The Internet Protocol address is hashed to obtain a hash value; then the hash value is moduloed to obtain the modulo result; when taking the modulo, the modulo can be based on the number of service versions. For example, if there are three service versions, the modulo is taken based on the hash value and the number "3".

[0070] This application allocates the modulo results proportionally. For example, to allocate 30% of the traffic to service version V1.0, the correspondence between the modulo results and each service version can be randomly determined in advance to obtain the proportional allocation information.

[0071] When applying the algorithm, after obtaining the modulus result, the proportional allocation information in the grayscale strategy is obtained. Based on the proportional allocation information, the service version corresponding to the modulus result is determined, and the service version corresponding to the modulus result is determined as the service version corresponding to the access request.

[0072] In this embodiment, the Internet Protocol address in the request parameters is obtained; a hash operation is performed on the Internet Protocol address to obtain a hash value, and a modulo operation is performed on the hash value to obtain a modulo result; the proportional allocation information in the grayscale strategy is obtained, the service version corresponding to the modulo result is determined according to the proportional allocation information, and the service version is determined as the service version corresponding to the access request, thus realizing routing based on the Internet Protocol address.

[0073] In one embodiment, when determining the service version corresponding to an access request based on a canary release policy, it is first checked whether a specified version exists in the canary release policy. If it exists, the specified version is determined as the service version corresponding to the access request; if it does not exist, routing is performed based on the request parameters and the canary release policy. As mentioned above, the request parameters include locator parameters, access object identifiers, traffic source identifiers, and Internet Protocol addresses. In this embodiment, the use of various request parameters has a specific order.

[0074] First, confirm whether the access request contains a locator parameter. If it does, query the service version corresponding to the locator parameter in the grayscale strategy and determine that service version as the service version corresponding to the access request.

[0075] If the locator parameter is not present, the access object identifier is extracted from the access request, and the corresponding object cache data is obtained. If the grayscale version in the object cache data is consistent with the grayscale version in the grayscale strategy, the service version in the object cache data is determined as the service version corresponding to the access request to achieve access version consistency.

[0076] If the grayscale version in the object cache data is inconsistent with the grayscale version in the grayscale policy, or if there is no object cache data corresponding to the access object identifier (e.g., the user accesses the service for the first time), then the traffic source identifier is extracted from the access request. When the traffic source identifier is the first source identifier, it means that the traffic is paid traffic. The service version corresponding to the first source identifier is queried in the grayscale policy, and the service version is determined as the service version corresponding to the access request.

[0077] If the traffic source identifier is a second source identifier, it indicates that the traffic is free traffic. Extract the Internet Protocol address from the access request, perform a hash operation on the Internet Protocol address to obtain a hash value, perform a modulo operation on the hash value to obtain the modulo result; obtain the proportion allocation information in the grayscale strategy, determine the service version corresponding to the modulo result based on the proportion allocation information, and determine the service version corresponding to the access request.

[0078] This embodiment comprehensively judges access requests based on the specified version, locator parameters, access object identifier, traffic source identifier, and Internet Protocol address, and can achieve routing in various situations.

[0079] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware with computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0080] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0081] Further reference Figure 3 As a response to the above Figure 2 To implement the method shown, this application provides an embodiment of a routing control device, which is similar to... Figure 2Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0082] like Figure 3 As shown, the routing control device 300 described in this embodiment includes: a request receiving module 301, a policy acquisition module 302, and a request routing module 303, wherein:

[0083] The request receiving module 301 is used to receive access requests for services through the gateway server.

[0084] The policy acquisition module 302 is used to acquire the gray-scale policies in the gateway server. The gray-scale policies are pre-written based on routing requirements and stored in the gateway server. The gray-scale policies are used for routing control.

[0085] The request routing module 303 is used to determine the service version corresponding to the access request based on the gray-scale strategy, and to route the access request to the server that supports the service version through the gateway server. The service has multiple service versions and the service is currently deployed in at least one deployment method, including static deployment and dynamic deployment.

[0086] In this embodiment, access requests for services are received through a gateway server. The gateway server stores canary release policies, allowing services to be released in canary phases and having multiple different service versions. The canary release policies are independently written according to requirements and can implement various routing controls. During canary release, the service version corresponding to the access request is determined based on the canary release policy, and the access request is routed to a server that supports the service version through the gateway server. The service is currently deployed in at least one deployment method, including static deployment and dynamic deployment. This application achieves routing that simultaneously supports both static and dynamic service deployment through an independent canary release policy, reducing the limitations on service deployment during canary release.

[0087] In some optional implementations of this embodiment, the routing control device 300 may further include: a type acquisition module and an access routing module, wherein:

[0088] The type retrieval module is used to retrieve the service type of a service.

[0089] The access routing module is used to route access requests to the server that supports the service when the service type is not a gray-scale service.

[0090] The request routing module 303 is also used to obtain the grayscale policy in the gateway server when the service type is grayscale service.

[0091] In this embodiment, the service type of the service is obtained. When the service type is a non-grayscale service, the service does not involve grayscale, and the access request can be directly routed to the server that supports the service. When the service type is a grayscale service, the service involves grayscale, and the grayscale policy is obtained so that routing can be implemented according to the grayscale policy.

[0092] In some optional implementations of this embodiment, the request routing module 303 may include: a specification determination submodule, a parameter extraction submodule, and a version determination submodule, wherein:

[0093] The specified submodule is used to determine the specified version as the service version corresponding to the access request when a specified version exists in the gray-scale strategy.

[0094] The parameter extraction submodule is used to extract request parameters from the access request when the specified version is not available in the grayscale policy. The request parameters include locator parameters, access object identifier, traffic source identifier, and Internet Protocol address.

[0095] The version determination submodule is used to determine the service version corresponding to the access request based on the gray-scale strategy and request parameters.

[0096] In this embodiment, the specified version is the specified service version. Whether the specified version is recorded in the gray-scale policy determines whether gray-scale is enabled. When the specified version exists in the gray-scale policy, the specified version is directly determined as the service version corresponding to the access request. When the specified version does not exist, the request parameters are extracted from the access request, and the service version corresponding to the access request is determined according to the gray-scale policy and the request parameters to realize gray-scale routing.

[0097] In some optional implementations of this embodiment, when the request parameter is a locator parameter, the version determination submodule may include: a version query unit and a first determination unit, wherein:

[0098] The version query unit is used to query the service version corresponding to the locator parameter in the grayscale strategy.

[0099] The first determining unit is used to determine the service version corresponding to the locator parameter as the service version corresponding to the access request.

[0100] In this embodiment, the service version corresponding to the locator parameter is queried in the grayscale strategy, and the service version is determined as the service version corresponding to the access request, thus realizing routing based on the locator parameter.

[0101] In some optional implementations of this embodiment, when the request parameter is an access object identifier, the version determination submodule may include: a cache acquisition unit, a cache extraction unit, a policy extraction unit, and a second determination unit, wherein:

[0102] The cache retrieval unit is used to retrieve the cached data of the object corresponding to the access object identifier.

[0103] The cache extraction unit is used to extract the service version and grayscale version from the object cache data.

[0104] The strategy extraction unit is used to extract the grayscale version from the grayscale strategy.

[0105] The second determining unit is used to determine the service version in the object cache data as the service version corresponding to the access request when the gray version in the object cache data is consistent with the gray version in the gray strategy.

[0106] In this embodiment, the object cache data corresponding to the access object identifier is obtained, and the service version and grayscale version are extracted from it. The grayscale version in the grayscale strategy is also extracted. When the two grayscale versions are consistent, the service version in the object cache data is determined as the service version corresponding to the access request, which ensures the consistency of user access and realizes routing based on the access object identifier.

[0107] In some optional implementations of this embodiment, when the request parameter is a traffic source identifier, the version determination submodule may include: a source query unit and a third determination unit, wherein:

[0108] The source query unit is used to query the service version corresponding to the first source identifier in the grayscale strategy when the traffic source identifier is the first source identifier.

[0109] The third determining unit is used to determine the service version corresponding to the first source identifier as the service version corresponding to the access request.

[0110] In this embodiment, when the traffic source identifier is the first source identifier, the service version corresponding to the first source identifier is queried in the grayscale strategy; the service version corresponding to the first source identifier is determined as the service version corresponding to the access request, thus realizing routing based on the traffic source identifier. The traffic source identifier is related to the business, thus realizing the combination of routing and business.

[0111] In some optional implementations of this embodiment, when the traffic source identifier is a second source identifier, the version determination submodule may include: an address acquisition unit, a hash operation unit, a modulo operation unit, a ratio acquisition unit, and a fourth determination unit, wherein:

[0112] The address acquisition unit is used to obtain the Internet Protocol address from the request parameters.

[0113] The hash operation unit is used to perform hash operations on Internet Protocol addresses to obtain hash values.

[0114] The modulo operation unit is used to perform a modulo operation on the hash value to obtain the modulo result.

[0115] The ratio acquisition unit is used to acquire the ratio allocation information in the grayscale strategy.

[0116] The fourth determining unit is used to determine the service version corresponding to the modulo result based on the proportional allocation information, and to determine the service version corresponding to the modulo result as the service version corresponding to the access request.

[0117] In this embodiment, the Internet Protocol address in the request parameters is obtained; a hash operation is performed on the Internet Protocol address to obtain a hash value, and a modulo operation is performed on the hash value to obtain a modulo result; the proportional allocation information in the grayscale strategy is obtained, the service version corresponding to the modulo result is determined according to the proportional allocation information, and the service version is determined as the service version corresponding to the access request, thus realizing routing based on the Internet Protocol address.

[0118] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0119] The computer device 4 includes a memory 41, a processor 42, and a network interface 43 that are interconnected via a system bus. It should be noted that only the computer device 4 with components 41-43 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0120] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.

[0121] The memory 41 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 41 may be an internal storage unit of the computer device 4, such as the hard disk or memory of the computer device 4. In other embodiments, the memory 41 may also be an external storage device of the computer device 4, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 4. Of course, the memory 41 may include both the internal storage unit and its external storage device of the computer device 4. In this embodiment, the memory 41 is typically used to store the operating system and various application software installed on the computer device 4, such as computer-readable instructions for routing control methods. In addition, the memory 41 can also be used to temporarily store various types of data that have been output or will be output.

[0122] In some embodiments, the processor 42 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 42 is typically used to control the overall operation of the computer device 4. In this embodiment, the processor 42 is used to execute computer-readable instructions stored in the memory 41 or to process data, for example, to execute computer-readable instructions of the routing control method.

[0123] The network interface 43 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 4 and other electronic devices.

[0124] The computer device provided in this embodiment can execute the above-described routing control method. The routing control method here can be any of the routing control methods described in the various embodiments above.

[0125] In this embodiment, access requests for services are received through a gateway server. The gateway server stores canary release policies, allowing services to be released in canary phases and having multiple different service versions. The canary release policies are independently written according to requirements and can implement various routing controls. During canary release, the service version corresponding to the access request is determined based on the canary release policy, and the access request is routed to a server that supports the service version through the gateway server. The service is currently deployed in at least one deployment method, including static deployment and dynamic deployment. This application achieves routing that simultaneously supports both static and dynamic service deployment through an independent canary release policy, reducing the limitations on service deployment during canary release.

[0126] This application also provides another embodiment, namely, a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the routing control method described above. The computer-readable storage medium can be either a non-volatile storage medium or a volatile storage medium.

[0127] In this embodiment, access requests for services are received through a gateway server. The gateway server stores canary release policies, allowing services to be released in canary phases and having multiple different service versions. The canary release policies are independently written according to requirements and can implement various routing controls. During canary release, the service version corresponding to the access request is determined based on the canary release policy, and the access request is routed to a server that supports the service version through the gateway server. The service is currently deployed in at least one deployment method, including static deployment and dynamic deployment. This application achieves routing that simultaneously supports both static and dynamic service deployment through an independent canary release policy, reducing the limitations on service deployment during canary release.

[0128] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0129] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

Claims

1. A routing control method, characterized in that, Includes the following steps: Access requests for services are received through a gateway server. The gateway server is built on a proxy service and integrates Lua libraries, third-party modules, and dependencies. The gateway server acts as a proxy routing service and uses an independently written canary deployment strategy for routing control. The gateway server makes routing decisions based on the new canary deployment strategy and does not restrict the deployment method of the service. Obtain the grayscale policy from the gateway server. The grayscale policy is pre-written based on routing requirements and stored in the gateway server. The grayscale policy is used for routing control. Based on the gray-scale strategy, the service version corresponding to the access request is determined, and the access request is routed to a server that supports the service version through the gateway server. The service has multiple service versions, and the service is currently deployed in at least one deployment method, including static deployment and dynamic deployment. The service can be deployed in multiple different service versions statically and in multiple different service versions dynamically. The step of determining the service version corresponding to the access request based on the gray-scale strategy specifically includes: When a specified version exists in the grayscale strategy, the specified version is determined as the service version corresponding to the access request; When the specified version is not available in the grayscale policy, request parameters are extracted from the access request, wherein the request parameters include locator parameters, access object identifier, traffic source identifier and Internet Protocol address; Check if a locator parameter exists in the access request. If it does, query the service version corresponding to the locator parameter in the grayscale strategy and determine the service version as the service version corresponding to the access request. If no locator parameter is present, the access object identifier is extracted from the access request, and the object cache data corresponding to the access object identifier is obtained; if the gray version in the object cache data is consistent with the gray version in the gray strategy, the service version in the object cache data is determined as the service version corresponding to the access request, so as to achieve consistency of access version; If the grayscale version in the object cache data is inconsistent with the grayscale version in the grayscale policy, or if there is no object cache data corresponding to the access object identifier, the traffic source identifier is extracted from the access request; when the traffic source identifier is the first source identifier, it means that the traffic is paid traffic, the service version corresponding to the first source identifier is queried in the grayscale policy, and the service version is determined to be the service version corresponding to the access request. If the traffic source identifier is a second source identifier, it indicates that the traffic is free traffic. Extract the Internet Protocol address from the access request, perform a hash operation on the Internet Protocol address to obtain a hash value, perform a modulo operation on the hash value to obtain the modulo result; obtain the proportion allocation information in the grayscale strategy, determine the service version corresponding to the modulo result based on the proportion allocation information, and determine the service version corresponding to the access request.

2. The routing control method according to claim 1, characterized in that, Following the step of receiving the access request for the service through the gateway server, the method further includes: Obtain the service type of the service; When the service type is a non-grayscale service, the access request will be routed to a server that supports the service; When the service type is grayscale service, the step of obtaining the grayscale policy in the gateway server is executed.

3. A routing control device, characterized in that, include: The request receiving module is used to receive access requests for services through the gateway server. The gateway server is built on a proxy service and integrates Lua libraries, third-party modules and dependencies. The gateway server acts as a proxy routing service. The gateway server uses an independently written canary release strategy for routing control. The gateway server makes routing decisions based on the new canary release strategy and does not restrict the deployment method of the service. The policy acquisition module is used to acquire the gray-scale policy in the gateway server. The gray-scale policy is pre-written based on routing requirements and stored in the gateway server. The gray-scale policy is used for routing control. The request routing module is used to determine the service version corresponding to the access request based on the gray-scale policy, and to route the access request to a server that supports the service version through the gateway server. The service has multiple service versions, and the service is currently deployed in at least one deployment method, including static deployment and dynamic deployment. The deployment method includes the service statically deploying multiple different service versions and dynamically deploying multiple different service versions. The request routing module is further configured to: when a specified version exists in the grayscale policy, determine the specified version as the service version corresponding to the access request; when no specified version exists in the grayscale policy, extract request parameters from the access request, wherein the request parameters include a locator parameter, an access object identifier, a traffic source identifier, and an Internet Protocol address; confirm whether a locator parameter exists in the access request; if it exists, query the service version corresponding to the locator parameter in the grayscale policy and determine the service version corresponding to the access request; if no locator parameter exists, extract the access object identifier from the access request and obtain the object cache data corresponding to the access object identifier; if the grayscale version in the object cache data is consistent with the grayscale version in the grayscale policy, determine the service version in the object cache data as the service version corresponding to the access request. To ensure consistency in access versions, if the grayscale version in the object cache data is inconsistent with the grayscale version in the grayscale policy, or if there is no object cache data corresponding to the access object identifier, the traffic source identifier is extracted from the access request. When the traffic source identifier is the first source identifier, it indicates that the traffic is paid traffic. The service version corresponding to the first source identifier is queried in the grayscale policy, and the service version is determined to be the service version corresponding to the access request. If the traffic source identifier is the second source identifier, it indicates that the traffic is free traffic. The Internet Protocol address is extracted from the access request, a hash operation is performed on the Internet Protocol address to obtain a hash value, and a modulo operation is performed on the hash value to obtain the modulo result. The proportional allocation information in the grayscale policy is obtained, and the service version corresponding to the modulo result is determined according to the proportional allocation information, and the service version is determined to be the service version corresponding to the access request.

4. A computer device comprising a memory and a processor, the memory storing computer-readable instructions, wherein the processor, when executing the computer-readable instructions, implements the steps of the routing control method as described in any one of claims 1 to 2.

5. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the routing control method as described in any one of claims 1 to 2.

Images