WO2018103320A1 - Gated launch method, system, server, and storage medium - Google Patents

Abstract

A gated launch system, comprising: a Redis server (102) and an Nginx server (104). The Nginx server (104) is used to search a cache to determine whether the cache contains a traffic division policy identifier. If not, then the Ngix server reads a current traffic division policy identifier from a predetermined location in the Redis server (102), and searches, according to the current traffic division policy identifier, a memory to determine whether the memory contains a policy parsing file and a user information parsing file corresponding to the current traffic division policy identifier. If not, then the Nginx server loads, according to the current traffic division policy identifier and by means of character string loading, a policy parsing file and a user information parsing file stored on the Redis server (102) in a character string format to the memory by means of Lua, and performs a launch according to a traffic division policy obtained by parsing the policy parsing file.

Description

Grayscale publishing method, system, server and storage medium

The present application claims the priority of the Chinese Patent Application, the entire disclosure of which is hereby incorporated by reference.

[Technical Field]

The present invention relates to the field of computer processing, and in particular, to a grayscale publishing method, system, server, and storage medium.

【Background technique】

Grayscale publishing is a kind of publishing method that can smoothly transition between black and white. AB Test is a grayscale publishing method, which allows some users to continue to use A, and some users start to use B. If the user has no objection to B, then gradually expand the scope and move all users to B. The grayscale release can ensure the stability of the overall system, and the problem can be found and adjusted at the initial gray level to ensure its influence. ABtest is based on the traffic distribution policy configured in the system. In the test phase, if a problem is found, a traffic distribution policy is added to the Redis server (cache server). Each traffic distribution policy corresponds to a policy resolution file and user. The information parsing file, because the traditional parsing policy corresponding to the policy parsing file and the user information parsing file is stored in the memory of the Nginx server (which is a performance-oriented HTTP server), so if you add a diversion policy, you need to The policy parsing file and user information parsing file corresponding to the new offloading policy are uploaded to the Nginx server. In this process, the Nginx server needs to be reloaded or restarted. Restarting the Nginx server is not only time-consuming but also very troublesome.

[Summary of the Invention]

In accordance with various embodiments of the present application, a grayscale publishing method and system is provided.

A grayscale publishing system comprising:

The Redis server is configured to receive and upload the uploaded traffic splitting policy and the policy parsing file and the user information parsing file corresponding to the shunting policy, where the policy parsing file and the user information parsing file are stored in the form of a string. And

The Nginx server is configured to check whether the traffic distribution policy identifier exists in the Cache. If the traffic distribution policy identifier does not exist in the Cache, the current traffic distribution policy identifier is read from the preset location in the Redis server.

The Nginx server is further configured to: according to the current offloading policy identifier, a search for a policy parsing file and a user information parsing file corresponding to the current shunting policy identifier, if the memory does not have a corresponding corresponding to the current shunting policy identifier. The policy parsing file and the user information parsing file are loaded into the memory by the lua in the form of a string in the manner of loading the string according to the current shunting policy identifier. Medium;

The Nginx server is further configured to perform the publishing according to the offloading policy parsed by the policy parsing file.

A grayscale publishing method, comprising:

The Nginx server periodically searches for the traffic distribution policy identifier in the Cache according to the preset rule. If the traffic distribution policy does not exist in the Cache, the current traffic distribution policy identifier is read from the preset location in the Redis server, where the Redis server stores The current splitting policy identifier and the corresponding policy parsing file and user parsing file exist in the form of a string;

Determining, by the current offloading policy identifier, whether a policy parsing file and a user information parsing file corresponding to the current shunting policy identifier exist in the memory;

If the policy parsing file and the user information parsing file corresponding to the current shunting policy identifier are not in the memory, the policy in the form of a string in the Redis server is used to load the string according to the current shunting policy identifier. Parsing files and user information parsing files are loaded into memory via lua; and

The distribution policy is parsed according to the policy parsing file.

A server comprising a memory and a processor, the memory storing computer readable instructions, the computer readable instructions being executed by the processor such that the processor performs the following steps:

If the traffic policy is not found in the Cache, the current traffic distribution policy identifier is read from the preset location in the Redis server. The Redis server stores the current traffic policy. The traffic policy identifier and the corresponding policy parsing file and user parsing file exist in the form of a string;

Determining, by the current offloading policy identifier, whether a policy parsing file and a user information parsing file corresponding to the current shunting policy identifier exist in the memory;

If the policy parsing file and the user information parsing file corresponding to the current shunting policy identifier are not in the memory, the policy in the form of a string in the Redis server is used to load the string according to the current shunting policy identifier. Parsing files and user information parsing files are loaded into memory via lua; and

The distribution policy is parsed according to the policy parsing file.

One or more non-volatile readable storage media storing computer-executable instructions, when executed by one or more processors, cause the one or more processors to perform the following steps:

If the traffic policy is not found in the Cache, the current traffic distribution policy identifier is read from the preset location in the Redis server. The Redis server stores the current traffic policy. The traffic policy identifier and the corresponding policy parsing file and user parsing file exist in the form of a string;

Determining, by the current offloading policy identifier, whether a policy parsing file and a user information parsing file corresponding to the current shunting policy identifier exist in the memory;

If the policy parsing file and the user information parsing file corresponding to the current shunting policy identifier are not in the memory, the policy in the form of a string in the Redis server is used to load the string according to the current shunting policy identifier. Parsing files and user information parsing files are loaded into memory via lua; and

The distribution policy is parsed according to the policy parsing file.

Details of one or more embodiments of the invention are set forth in the accompanying drawings and description below. Other features, objects, and advantages of the invention will be apparent from the description and appended claims.

[Description of the Drawings]

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the embodiments or the description of the prior art will be briefly described below. Obviously, the drawings in the following description are only It is a certain embodiment of the present invention, and other drawings can be obtained from those skilled in the art without any creative work.

1 is an architectural diagram of a grayscale distribution system in an embodiment;

2 is a flow chart of a grayscale publishing method in an embodiment;

3 is a flowchart of a method for loading a policy parsing file and a user information parsing file according to a current shunting policy according to an embodiment;

4 is a flow chart of a grayscale publishing method in another embodiment;

Figure 5 is a diagram showing the internal structure of an Nginx server in one embodiment.

 【detailed description】

The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It is understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

As shown in FIG. 1, in one embodiment, a grayscale publishing system is proposed, the system comprising: a Redis server 102 and an Nginx server 104;

The Redis server 102 is configured to receive and upload the uploaded traffic splitting policy and the policy parsing file and the user information parsing file corresponding to the traffic diverting policy, where the policy parsing file and the user information parsing file are stored in the form of a string.

In one embodiment, the ABtest (AB test) is based on the offloading policy configured in the system. For each of the traffic distribution policies, a policy resolution file and a user information analysis file are required. The policy analysis file is used to parse the traffic distribution policy, and the correspondence between the user features and the forwarding path in the traffic distribution policy is analyzed. The user information parsing file is used to parse the obtained user information, parse the user feature in the user information, and then determine a specific forwarding path corresponding to the user feature, and forward the packet according to the determined forwarding path. In this embodiment, when a new traffic distribution policy is required, the policy analysis file and the user information analysis file corresponding to the traffic distribution policy and the traffic distribution policy are directly uploaded to the Redis server through the background management page, where the policy corresponding to the traffic distribution policy needs to be resolved. The file and user information parsing file is first converted into a string form and then uploaded to the Redis server. That is, the policy parsing file and the user information parsing file in the Redis server are stored in the form of a string.

The Nginx server 104 is configured to search for a traffic distribution policy identifier in the Cache. If not, the current traffic distribution policy identifier is read from a preset location in the Redis server.

In this embodiment, the traffic distribution policy identifier is used to uniquely identify a traffic distribution policy, and the current traffic distribution policy identifier may be an identifier corresponding to the currently used traffic distribution policy. Generally, the current traffic distribution policy identifier is stored in the Cache (cache memory) of the Nginx server. However, if the traffic distribution policy needs to be replaced, the content in the Cache is first cleared, that is, if a new traffic off policy is to be used. The traffic policy identifier in the Cache needs to be cleared. That is, when the new traffic distribution policy is used for the first time, there is no traffic distribution policy identifier in the Cache. The Cache (cache memory) belongs to the internal memory, and the content of the Cache can be cleared by using a special clearing mechanism, that is, an interface for clearing the contents of the Cache is set, and the content is cleared through the interface. You can also set the time limit for the contents of the Cache. For example, if you do not use the offload policy ID in more than 1 minute, it will be automatically cleared. The traffic policy ID in the Cache. There is no restriction on how to empty the contents of the Cache. In an embodiment, the Nginx server periodically searches for a traffic distribution policy identifier according to a preset rule. If not, the current traffic distribution policy is replaced. The current traffic distribution policy is set in the Redis server. Therefore, if the current traffic distribution policy identifier does not exist in the Cache, the Nginx server needs to read the current traffic distribution policy identifier from the preset location in the Redis server. In one embodiment, the Nginx server stores the location (ie, the address) of the current traffic distribution policy identifier, reads the current traffic distribution policy identifier from the Redis server according to the storage location, and saves the read current traffic distribution policy identifier to the Cache, which facilitates subsequent offload forwarding.

The Nginx server 104 is further configured to: according to the current traffic distribution policy identifier, a policy parsing file and a user information parsing file corresponding to the current shunting policy identifier are found in the memory, and if not, the redisets are loaded according to the current shunting policy identifier. The policy parsing file and the user information parsing file in the form of a string in the server are loaded into the memory through lua.

In this embodiment, after obtaining the current traffic distribution policy identifier, the Nginx server first searches for the policy resolution file and the user information analysis file corresponding to the current traffic distribution policy identifier according to the current traffic distribution policy identifier, and if not, The traffic distribution policy corresponding to the current traffic distribution policy identifier is a new traffic distribution policy. The corresponding policy resolution file and user information analysis file exist in the form of a string on the Redis server. The Nginx server needs to load the policy parsing file and the user information parsing file in the Redis server in the form of a string into the memory by loading the string (loadString). Lua is a dynamic scripting language that can be embedded into Nginx server configuration files. In one embodiment, the Nginx server first loads the policy parsing file and the user information parsing file in the form of a string into lua, and then converts the policy parsing file and the user information parsing file in the form of a string into lua into lua. The Table form is then stored in memory. Among them, the Table form is a form that can be directly called by the Nginx server. In this embodiment, the Nginx server can load the policy parsing file and the user information parsing file in the Redis server into the memory by loading the string, so when the file needs to be added, only the new file needs to be added. It is converted to a string, and then uploaded to the Redis server through the background management page, and then the new traffic distribution policy is set to the current traffic distribution policy to implement the traffic policy update without restarting the Nginx server.

The Nginx server 104 is further configured to perform the distribution according to the offloading policy parsed by the policy parsing file.

In this embodiment, after the Nginx server loads the policy parsing file and the user information parsing file into the memory, the corresponding grayscale publishing may be performed according to the shunting policy parsed by the policy parsing file. In an embodiment, the Nginx server parses the corresponding traffic splitting policy by using the policy parsing file, and can obtain a specific correspondence between the traffic splitting policies, that is, the at least one parameter information and the forwarding path (upstream) in the traffic splitting policy can be parsed. Correspondence relationship. For example, if the traffic distribution policy is based on the city information, the policy analysis file can resolve the correspondence between the city information and the forwarding path in the traffic distribution policy, and the corresponding file is parsed from the user according to the user information. The user feature extracted from the information must also be the city information. Therefore, the forwarding path corresponding to the user feature can be determined by the correspondence between the parsed city information and the forwarding path. For example, the parsed city information and forwarding path are: Shanghai (SH) corresponds to forwarding path 1, Beijing (BJ) corresponds to forwarding path 2, and the remaining cities correspond to forwarding path 3. If the extracted user feature is Shanghai, then the forwarding path corresponding to the user feature is 1. The corresponding relationship between the parsed at least one parameter information and the forwarding path is saved to the Cache, so that when the next user requests to come over, the parsed shunting policy can be directly used for offloading and forwarding.

In this embodiment, when a new traffic distribution policy is required, the policy analysis file and the user information analysis file corresponding to the new traffic distribution policy are converted into a string and uploaded to the Redis server. The Nginx server needs to use the newly added policy resolution. When the file and user information are parsed, the corresponding new policy parsing file and user information parsing file are searched from the Redis server, and then the policy parsing file and user in the form of a string in the Redis server are loaded by using a string. The information parsing file is loaded into the memory through lua, and then distributed according to the shunting policy parsed by the policy parsing file. In this process, when a new traffic splitting policy is required, the policy resolution file and the user information parsing file corresponding to the traffic splitting policy need to be converted into a string and stored in the Redis server. The Nginx server can dynamically load new policy resolution files and user information parsing files from the Redis server into memory. It does not require reloading and restarting the Nginx server. It is easy to operate and saves time, thus improving the forwarding efficiency.

In an embodiment, the Nginx server is further configured to search for a policy resolution file ID and a user information resolution file ID corresponding to the current distribution policy identifier according to the current distribution policy identifier, and parse the file ID and the user information according to the policy. The ID parses the policy parsing file and the user information parsing file in the Redis server in the form of a string into the memory and converts it into a table for storage.

In this embodiment, Nginx After obtaining the current traffic distribution policy identifier, the server searches the Redis server for the policy resolution file ID and the user information resolution file ID corresponding to the current traffic distribution policy identifier. The ID is used to uniquely identify a file or content. In an embodiment, the mapping between the traffic policy identifier and the policy resolution file ID and the user information resolution file ID is pre-stored in the Redis server, and the current traffic distribution policy can be found in the Redis server according to the current traffic policy identifier. Identifies the corresponding policy resolution file ID and user information resolution file ID. After obtaining the policy resolution file ID and the user information resolution file ID, the Nginx server can find the corresponding policy resolution file and user information analysis file according to the policy resolution file ID and the user information resolution file ID in the Redis server. The user information parsing file exists in the form of a string (String) in the Redis server, and the form of the string cannot be directly called, so it is necessary to parse the file and user information by using the policy in the form of a string. The file is loaded into the memory through lua, and the form of the string (String) is converted into a Table form for storage in the memory, so that the Nginx server can directly call the policy parsing file and the user information parsing file to parse and determine the user request. The corresponding forwarding path is also convenient for calling the corresponding policy parsing file and user information parsing file directly from the memory next time.

In an embodiment, the Nginx server is further configured to parse the corresponding offloading policy by using the policy parsing file, and parse the correspondence between the at least one parameter information and the forwarding path in the offloading policy. And saving the correspondence between the at least one parameter information and the forwarding path to the Cache.

In this embodiment, although the correspondence between the parameter information and the forwarding path has been set in the traffic distribution policy, since the corresponding relationship between the parameter information and the forwarding path in the traffic distribution policy cannot be directly identified in the computer, Therefore, the corresponding splitting policy is parsed by calling the policy parsing file, and the correspondence between the at least one parameter information and the forwarding path in the splitting policy is parsed, and the parsed at least one parameter information and the forwarding path are The corresponding relationship is saved to the Cache, so that when the next user requests to come over, the split traffic policy can be directly used for offload forwarding. Among them, the parameter information has various types according to the type and the corresponding position. If there are four types commonly used by type, one type of city information (City), one type is UID (User). Identification, user identification) information, one is IP information, and the other is URL information. The UID information may be divided into a UID suffix shunt, a specified special UID shunt, and a UID user segment shunt according to different extraction locations. The shunting strategy is divided into single-level shunt and multi-level shunt. Single-stage splitting is relatively simple, which means that only one parameter information needs to be referenced to find the corresponding forwarding path. Multi-level shunting needs to refer to a variety of parameter information. Among them, multi-level shunting is divided into two types: union and intersection. The so-called union is that as long as one of the conditions is met, the shunting can be realized, and the intersection must satisfy multiple The condition can only realize the forwarding of the offload. Taking the three-level split as an example, the first-level split is the split of the city: divided into two types, Shanghai (SH), Beijing (BJ), and its corresponding split strategy is: SH The upstream (forward path) is beta1, the upstream of BJ is beta2; the second-level offload is the split of UID collection: UID is 123, 124, The upstream of 125 is beta1, the upstream of UID is 567, 568, 569 is beta2; the third-level shunting is IP-wide shunting: IP's long value range is 1000001~2000000, upstream is beta1, and ip's long value is 2000001~ The 3000000 upstream is beta2; if the union is used, the city information is first extracted from the user information. If the city information SH or BJ can be extracted, the request is forwarded to beta1 or beta2, and the UID and IP information are not considered. If the city information is not extracted, or the city information is not within the scope of SH and BJ, then the UID is continuously determined. If the UID is 567, the request is forwarded to beta2, and so on, as long as the forwarding condition is met, the forwarding is not necessary. The information behind. If the intersection method is adopted, the same three conditions must be met at the same time, that is, if the acquired city information is SH, and its corresponding upstream is beta1, it is necessary to continue to obtain the information and IP range of the UID set. Information, and the information of the acquired UID set is also beta1, and the information of the IP range must correspond to beta1, then the user request will be forwarded to beta1, if the corresponding information or the upstream corresponding to the obtained information is not obtained Inconsistent, for example, the acquired city information is SH, and the acquired UID set information is 567. Since the two correspond to beta1 and beta2, respectively, three conditions are not met at the same time, so the forwarding of the offload cannot be realized, but in practice Instead of using the form of intersection alone, the intersection and union are used.

In an embodiment, the Nginx server is further configured to receive a request sent by the client, extract user information in the request, and extract at least one parameter information from the user information according to a preset extraction manner in the user information parsing file, where The extracted at least one type of parameter information is used as a user feature, and the forwarding path corresponding to the user feature is determined according to the correspondence between the at least one parameter information and the forwarding path stored in the Cache, and the corresponding forwarding is performed according to the forwarding path.

In this embodiment, the Nginx server receives the request sent by the client, extracts the user information in the request, and parses the user information according to the user information parsing file corresponding to the current traffic distribution policy identifier previously stored in the memory, from the user information. Extracting at least one parameter information, and then extracting the extracted at least one parameter information as a user feature. The extracting of the user feature is related to the corresponding splitting strategy. In an embodiment, if the traffic distribution policy is offloaded according to the city information (City), the user information analysis file corresponding to the traffic distribution policy naturally extracts the city information in the user information, and the extracted city information is the user feature. . Of course, the traffic offloading strategy may be based on one parameter information, or may be based on multiple parameter information. If the shunt operation is performed according to multiple parameter information, multiple parameter information needs to be extracted from the user information, for example, simultaneous extraction. If the city information and UID information are not extracted, the IP information may need to be further extracted. What information is specifically extracted as a user feature is determined by the corresponding offloading strategy. After the user feature is extracted, the forwarding path corresponding to the user feature is determined according to the correspondence between the at least one parameter information and the forwarding path stored in the Cache, and then the corresponding forwarding is performed according to the forwarding path.

In an embodiment, the Nginx server is further configured to parse the corresponding traffic distribution policy by using a policy resolution file, parse the corresponding percentage policy, and perform corresponding release according to the percentage policy.

In this embodiment, the traffic distribution policy is forwarded according to the percentage policy. The Nginx server parses the corresponding traffic distribution policy by using the policy resolution file, and parses out the specific percentage policy, that is, how much is forwarded to the path A, and the percentage is How much is forwarded to path B. For example, there are 2 sets of upstream, which are beta1 and beta2, which can set 30% of requests to beta1, 70% of requests to beta2, and then publish correspondingly according to the percentage policy. In addition, in order to ensure that the same user can always forward to the same path, it is necessary to introduce the customer number as a parameter. If the same customer number is unchanged, the user request is always forwarded to the same upstream, so only in a large number Ideally, the 30% and 70% allocation strategies are possible.

As shown in FIG. 2, in one embodiment, a grayscale publishing method is proposed, the method comprising:

Step 202: The Nginx server periodically searches for a traffic distribution policy identifier in the Cache according to the preset rule. If yes, the process proceeds directly to step 206. If not, the process proceeds to step 204.

Step 204: Read the current offload policy identifier from a preset location in the Redis server.

In this embodiment, the traffic distribution policy identifier is used to uniquely identify a traffic distribution policy, and the current traffic distribution policy identifier may be an identifier corresponding to the currently used traffic distribution policy. The Redis server stores the current traffic distribution policy identifier and the corresponding policy analysis file and user resolution file that exist in the form of a string. Generally, the current traffic distribution policy identifier is stored in the Cache (cache memory) of the Nginx server. However, if the traffic distribution policy needs to be replaced, the content in the Cache is first cleared, that is, if a new traffic off policy is to be used. The traffic policy identifier in the Cache needs to be cleared. That is, when the new traffic distribution policy is used for the first time, there is no traffic distribution policy identifier in the Cache. The content of the Cache can be cleared by using a special clearing mechanism, that is, setting an interface for clearing the contents of the Cache, and clearing the content through the interface. You can also set the time limit for the contents of the Cache. For example, if you do not use the offload policy ID in more than 1 minute, it will be automatically cleared. The traffic policy ID in the Cache. There is no restriction on how to empty the contents of the Cache. In an embodiment, the Nginx server periodically searches for a traffic distribution policy identifier according to a preset rule. If not, the current traffic distribution policy is replaced. The current traffic distribution policy is set in the Redis server. Therefore, if the current traffic distribution policy identifier does not exist in the Cache, the Nginx server needs to read the current traffic distribution policy identifier from the preset location in the Redis server. In one embodiment, the Nginx server stores the location (ie, the address) of the current traffic distribution policy identifier, reads the current traffic distribution policy identifier from the Redis server according to the storage location, and saves the read current traffic distribution policy identifier to the Cache, which facilitates subsequent offload forwarding.

Step 206: Search for the policy analysis file and the user information analysis file corresponding to the current traffic distribution policy identifier in the memory according to the current traffic distribution policy identifier. If yes, go directly to step 210. If not, go to step 208.

In this embodiment, after obtaining the current traffic distribution policy identifier, the Nginx server first searches for the policy resolution file and the user information analysis file corresponding to the current traffic distribution policy identifier according to the current traffic distribution policy identifier, and if not, The traffic distribution policy corresponding to the current traffic distribution policy identifier is a new traffic distribution policy. The corresponding policy resolution file and user information analysis file exist in the form of a string on the Redis server. In an embodiment, when a new traffic distribution policy is required, the policy analysis file and the user information analysis file corresponding to the traffic distribution policy and the traffic distribution policy are directly uploaded to the Redis server through the background management page, where the policy corresponding to the traffic distribution policy needs to be resolved. File and user information parsing files are first converted to strings and then uploaded to the Redis server. In the Redis server, the policy parsing file and the user information parsing file are stored in the form of strings.

Step 208: The policy parsing file and the user information parsing file in the form of a string in the Redis server are loaded into the memory by using lua according to the current shunting policy identifier.

In this embodiment, the Nginx server needs to load the policy parsing file and the user information parsing file in the form of a string in the Redis server into the memory by loading the string (loadString). Lua is a dynamic scripting language that can be embedded into Nginx server configuration files. In one embodiment, the Nginx server first loads the policy parsing file and the user information parsing file in the form of a string into lua, and then converts the policy parsing file and the user information parsing file in the form of a string into lua into lua. The Table form is then stored in memory, where the Table form is directly available to the Nginx server. In this embodiment, since the policy parsing file and the user information parsing file are initially stored in the Redis server in the form of a string, instead of being directly stored in the Nginx server, when the new file needs to be added, only the new file needs to be added. The file is converted to a string, and then uploaded to the Redis server through the background management page, and then the new traffic distribution policy is set to the current traffic distribution policy to implement the traffic policy update.

Step 210: Publish according to the offloading policy parsed by the policy parsing file.

In this embodiment, after the Nginx server loads the policy parsing file and the user information parsing file into the memory, the corresponding grayscale publishing may be performed according to the shunting policy parsed by the policy parsing file. In an embodiment, the Nginx server parses the corresponding traffic splitting policy by using the policy parsing file, and can obtain a specific correspondence between the traffic splitting policies, that is, the at least one parameter information and the forwarding path (upstream) in the traffic splitting policy can be parsed. Correspondence relationship. For example, if the traffic distribution policy is based on the city information, the policy analysis file can resolve the correspondence between the city information and the forwarding path in the traffic distribution policy, and the corresponding file is parsed from the user according to the user information. The user feature extracted from the information must also be the city information. Therefore, the forwarding path corresponding to the user feature can be determined by the correspondence between the parsed city information and the forwarding path. For example, the parsed city information and forwarding path are: Shanghai (SH) corresponds to forwarding path 1, Beijing (BJ) corresponds to forwarding path 2, and the remaining cities correspond to forwarding path 3. If the extracted user feature is Shanghai, then the forwarding path corresponding to the user feature is 1. The corresponding relationship between the parsed at least one parameter information and the forwarding path is saved to the Cache, so that when the next user requests to come over, the parsed shunting policy can be directly used for offloading and forwarding.

In this embodiment, when a new traffic distribution policy is required, the policy analysis file and the user information analysis file corresponding to the new traffic distribution policy are converted into a string and uploaded to the Redis server. The Nginx server needs to use the newly added policy resolution. When the file and user information are parsed, the corresponding new policy parsing file and user information parsing file are searched from the Redis server, and then the policy parsing file and user in the form of a string in the Redis server are loaded by using a string. The information parsing file is loaded into the memory through lua, and then distributed according to the shunting policy parsed by the policy parsing file. In this process, when a new traffic splitting policy is required, the policy resolution file and the user information parsing file corresponding to the traffic splitting policy need to be converted into a string and stored in the Redis server. The Nginx server can dynamically load new policy resolution files and user information parsing files from the Redis server into memory. It does not require reloading and restarting the Nginx server. It is easy to operate and saves time, thus improving the forwarding efficiency.

As shown in FIG. 3, in one embodiment, the policy parsing file and the user information parsing file in the form of a string in the Redis server are loaded into the memory through lua according to the current shunting policy identifier. Step 208 includes:

Step 208A: Search for the policy resolution file ID and the user information resolution file ID corresponding to the current traffic distribution policy identifier according to the current traffic distribution policy identifier.

In this embodiment, Nginx After obtaining the current traffic distribution policy identifier, the server searches the Redis server for the policy resolution file ID and the user information resolution file ID corresponding to the current traffic distribution policy identifier. The ID is used to uniquely identify a file or content. In an embodiment, the mapping between the traffic policy identifier and the policy resolution file ID and the user information resolution file ID is pre-stored in the Redis server, and the current traffic distribution policy can be found in the Redis server according to the current traffic policy identifier. Identifies the corresponding policy resolution file ID and user information resolution file ID.

Step 208B: The policy parsing file and the user information parsing file in the form of a string in the Redis server are loaded into the memory by the lua and converted into Table by loading the string according to the policy parsing file ID and the user information parsing file ID. The form is stored.

In this embodiment, after obtaining the policy parsing file ID and the user information parsing file ID, the Nginx server can find the corresponding policy parsing file and user information parsing according to the policy parsing file ID and the user information parsing file ID in the Redis server. The file, because the policy parsing file and the user information parsing file exist in the form of a string in the Redis server, and the form of the string cannot be directly called, so it is necessary to adopt a strategy that exists in the form of a string. The parsing file and the user information parsing file are loaded into the memory by lua, and the string (String) form is converted into a Table form for storage, so that the Nginx server can directly call the policy parsing file and the user information parsing file pair. The user requests to parse and determine the corresponding forwarding path, and it is also convenient to call the corresponding policy parsing file and user information parsing file directly from the memory next time.

In an embodiment, the step of distributing the splitting policy according to the policy parsing file includes: parsing the corresponding splitting policy by using the policy parsing file, and parsing between at least one parameter information and the forwarding path in the splitting policy Corresponding relationship, and storing the correspondence between the at least one parameter information and the forwarding path to the Cache, and publishing according to the correspondence between the at least one parameter information in the Cache and the forwarding path.

In this embodiment, although the correspondence between the parameter information and the forwarding path has been set in the traffic distribution policy, since the correspondence between the parameter information and the forwarding path in the traffic distribution policy cannot be identified in the computer, The corresponding splitting policy is parsed by calling the policy parsing file, and the correspondence between the at least one parameter information and the forwarding path in the splitting policy is parsed, and the correspondence between the parsed at least one parameter information and the forwarding path is analyzed. The relationship is saved to the Cache, so that when the next user requests to come over, the split traffic policy can be directly used for offload forwarding. Among them, the parameter information has various types according to the type and the corresponding position. If there are four types commonly used by type, one type of city information (City), one type is UID information, one is IP information, and the other is URL. information. The UID information may be divided into a UID suffix shunt, a specified special UID shunt, and a UID user segment shunt according to different extraction locations. The shunting strategy is divided into single-level shunt and multi-level shunt. Single-stage splitting is relatively simple, which means that only one parameter information needs to be referenced to find the corresponding forwarding path. Multi-level shunting needs to refer to a variety of parameter information. Among them, multi-level shunting is divided into two types: union and intersection. The so-called union is that as long as one of the conditions is met, the shunting can be realized, and the intersection must satisfy multiple The condition can only realize the forwarding of the offload. Taking the three-level split as an example, the first-level split is the split of the city: divided into two types, Shanghai (SH), Beijing (BJ), and its corresponding split strategy is: SH The upstream (forward path) is beta1, the upstream of BJ is beta2; the second-level offload is the split of UID collection: UID is 123, 124, The upstream of 125 is beta1, the upstream of UID is 567, 568, 569 is beta2; the third-level shunting is IP-wide shunting: IP's long value range is 1000001~2000000, upstream is beta1, and ip's long value is 2000001~ The 3000000 upstream is beta2; if the union is used, the city information is first extracted from the user information. If the city information SH or BJ can be extracted, the request is forwarded to beta1 or beta2, and the UID and IP information are not considered. If the city information is not extracted, or the city information is not within the scope of SH and BJ, then the UID is continuously determined. If the UID is 567, the request is forwarded to beta2, and so on, as long as the forwarding condition is met, the forwarding is not necessary. The information behind. If the intersection method is adopted, the same three conditions must be met at the same time, that is, if the acquired city information is SH, and its corresponding upstream is beta1, it is necessary to continue to obtain the information and IP range of the UID set. Information, and the information of the acquired UID set is also beta1, and the information of the IP range must correspond to beta1, then the user request will be forwarded to beta1, if the corresponding information or the upstream corresponding to the obtained information is not obtained Inconsistent, for example, the acquired city information is SH, and the acquired UID set information is 567. Since the two correspond to beta1 and beta2, respectively, three conditions are not met at the same time, so the forwarding of the offload cannot be realized, but in practice Instead of using the form of intersection alone, the intersection and union are used.

As shown in FIG. 4, in an embodiment, the grayscale publishing method further includes:

Step 402: The Nginx server periodically searches for a traffic distribution policy identifier in the Cache according to a preset rule. If yes, the process proceeds directly to step 406. If not, the process proceeds to step 404.

Step 404: Read the current offload policy identifier from a preset location in the Redis server.

In step 406, the policy analysis file and the user information analysis file corresponding to the current traffic distribution policy identifier are found in the memory according to the current traffic distribution policy identifier. If yes, the process proceeds directly to step 410. If not, the process proceeds to step 408.

Step 408: The policy parsing file and the user information parsing file in the form of a string in the Redis server are loaded into the memory by lua according to the current shunting policy identifier.

Step 410: The policy analysis file is used to parse the corresponding traffic distribution policy, and the correspondence between the at least one parameter information and the forwarding path in the traffic distribution policy is parsed, and the correspondence between the at least one parameter information and the forwarding path is analyzed. The relationship is saved to the Cache.

Step 412: Receive a request sent by the client, and extract user information in the request.

In this embodiment, the Nginx server receives the request sent by the client, and extracts the user information in the request. The user information includes city information, IP address information, and UID information. At least one of remote address information and the like.

Step 414: Extract at least one parameter information from the user information according to a preset extraction manner in the user information parsing file, and use the extracted at least one parameter information as a user feature.

In this embodiment, the Nginx server parses the user information according to the current user information analysis file in the memory, and extracts at least one parameter information from the user information according to a preset extraction manner, and then extracts the extracted information. The at least one parameter information is used as a user feature. The extracting of the user feature is related to the corresponding splitting strategy. In an embodiment, if the traffic distribution policy is offloaded according to the city information (City), the user information analysis file corresponding to the traffic distribution policy naturally extracts the city information in the user information, and the extracted city information is the user feature. . Of course, the traffic offloading strategy may be based on one parameter information, or may be based on multiple parameter information. If the shunt operation is performed according to multiple parameter information, multiple parameter information needs to be extracted from the user information, for example, simultaneous extraction. If the city information and UID information are not extracted, the IP information may need to be further extracted. What information is specifically extracted as a user feature is determined by the corresponding offloading strategy.

Step 416: Determine a forwarding path corresponding to the user feature according to the correspondence between the at least one parameter information and the forwarding path stored in the Cache, and perform corresponding forwarding according to the forwarding path.

In this embodiment, after the user feature is extracted, the forwarding path corresponding to the user feature is determined according to the correspondence between the at least one parameter information and the forwarding path stored in the Cache, and then the corresponding forwarding path is performed according to the forwarding path. Forward. Taking multi-level shunting as an example, a shunting strategy using intersection and union is adopted. Among them, the first level of the split includes two strategies, which is the intersection relationship: the city ID is 0 for the strategy ID, the beta1 for the Shanghai (SH), the beta2 for the Beijing (BJ), and the UID for the strategy ID of 1. Set splitting, the upstream of UID is 123, 124, 125 is beta1, the upstream of UID is 567, 568, 569 is beta2; the second-level split is the union of the first-level split, and the second-level split is only one strategy. The strategy is 2 is the ip range of the shunt, ip long value range is 1000001 ~ 2000000 of the upstream is beta1, ip long value range of 2000001 ~ 3000000 of the upstream is beta2; In this embodiment, if the city information in the user information is SH and the UID is 123, then the first level is offloaded, and the request is forwarded to beta1. If the city information in the user information is SH, and the UID is 567, due to the respective If the forwarded inbound stream is inconsistent and does not meet the level 1 splitting policy, the second-level offloading policy is continued. If the long value of the IP is 1200000, the request is forwarded to beta1.

In an embodiment, the step of distributing the splitting policy according to the policy parsing file includes: parsing the corresponding traffic splitting policy by using the policy parsing file, parsing the corresponding percentage policy, and performing corresponding publishing according to the percentage policy.

In this embodiment, the traffic distribution policy is forwarded according to the percentage policy. The Nginx server parses the corresponding traffic distribution policy by using the policy resolution file, and parses out the specific percentage policy, that is, how much is forwarded to the path A, and the percentage is How much is forwarded to path B. For example, there are 2 sets of upstream, which are beta1 and beta2, which can set 30% of requests to beta1, 70% of requests to beta2, and then publish correspondingly according to the percentage policy. In addition, in order to ensure that the same user can always forward to the same path, it is necessary to introduce the customer number as a parameter. If the same customer number is unchanged, the user request is always forwarded to the same upstream, so only in a large number Ideally, the 30% and 70% allocation strategies are possible.

As shown in FIG. 5, in one embodiment, the internal structure of the Nginx server 104 is as shown in FIG. 5, which includes a processor connected through a system bus, a non-volatile storage medium, an internal memory, and a network interface. Wherein, the non-volatile storage medium of the Nginx server stores an operating system and computer readable instructions executable by the processor to implement a grayscale publishing method suitable for the Nginx server. This processor is used to provide computing and control capabilities to support the operation of the entire server. The internal memory in the Nginx server 104 provides an environment for the operation of operating systems and computer executable instructions in a non-volatile storage medium for network communication. It will be understood by those skilled in the art that the structure shown in FIG. 5 is only a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation of the Nginx server 104 to which the solution of the present application is applied, and a specific Nginx server. 104 may include more or fewer components than shown, or some components may be combined, or have different component arrangements.

In one embodiment, Figure 5 When the computer readable instructions in the Nginx server are executed by the processor, the processor is configured to: perform a step of searching for a shunt policy identifier in the Cache according to a preset rule timing, and if not present, preset from the Redis server The location is configured to read the current traffic distribution policy identifier; the current traffic distribution policy identifier is used to search for the policy resolution file and the user information analysis file corresponding to the current traffic distribution policy identifier; if the current traffic distribution policy identifier does not exist in the memory, The policy parsing file and the user information parsing file are loaded into the memory by the lua in the form of a string in the manner of loading the string according to the current shunting policy identifier. And publishing according to the offloading policy parsed by the policy parsing file.

In an embodiment, if the policy parsing file and the user information parsing file corresponding to the current shunting policy identifier are not present in the memory, the method for loading the string according to the current shunting policy identifier is The step of loading the policy parsing file and the user information parsing file in the form of a string into the memory by the lua in the redis server includes: if the in-memory does not exist, the policy parsing file corresponding to the current shunting policy identifier and the user information parsing And searching for the policy resolution file ID and the user information resolution file ID corresponding to the current distribution policy identifier according to the current distribution policy identifier; and parsing the file ID according to the policy and parsing the file ID with the user information by loading the string The policy parsing file and the user information parsing file in the form of a string in the Redis server are loaded into the memory by lua and converted into a Table for storage.

In an embodiment, the performing the distribution of the offloading policy that is parsed according to the policy parsing file by the processor includes: parsing the corresponding offloading policy by using the policy parsing file, and parsing at least one of the offloading policies. Correspondence between parameter information and forwarding path, And storing the correspondence between the at least one parameter information and the forwarding path to the Cache; and publishing according to the correspondence between the at least one parameter information and the forwarding path in the Cache.

In an embodiment, the processor is further configured to: receive a request sent by the client, extract user information in the request, and parse the user from the user according to a preset extraction manner in the file. At least one parameter information is extracted from the information, and the extracted at least one parameter information is used as a user feature; and the forwarding corresponding to the user feature is determined according to the correspondence between the at least one parameter information and the forwarding path stored in the Cache. The path is forwarded according to the forwarding path.

In an embodiment, the performing the distribution of the offloading policy that is parsed according to the policy parsing file by the processor includes: parsing the corresponding offloading policy by using the policy parsing file, and parsing the corresponding percentage policy, according to The percentage policy is correspondingly released.

A person skilled in the art can understand that all or part of the process of implementing the above embodiment method can be completed by a computer program to instruct related hardware, and the computer program can be stored in a computer readable storage medium. When executed, the flow of an embodiment of the methods as described above may be included. The foregoing storage medium may be a magnetic disk, an optical disk, or a read-only storage memory (Read-Only) A nonvolatile storage medium such as a memory or a ROM, or a random access memory (RAM).

The technical features of the above-described embodiments may be arbitrarily combined. For the sake of brevity of description, all possible combinations of the technical features in the above embodiments are not described. However, as long as there is no contradiction between the combinations of these technical features, All should be considered as the scope of this manual.

The above-described embodiments are merely illustrative of several embodiments of the present invention, and the description thereof is more specific and detailed, but is not to be construed as limiting the scope of the invention. It should be noted that a number of variations and modifications may be made by those skilled in the art without departing from the spirit and scope of the invention. Therefore, the scope of the invention should be determined by the appended claims.

Claims (20)

A grayscale publishing system comprising: The Redis server is configured to receive and upload the uploaded traffic splitting policy and the policy parsing file and the user information parsing file corresponding to the shunting policy, where the policy parsing file and the user information parsing file are stored in the form of a string. ;and The Nginx server is configured to check whether the traffic distribution policy identifier exists in the Cache. If the traffic distribution policy identifier does not exist in the Cache, the current traffic distribution policy identifier is read from the preset location in the Redis server. The Nginx server is further configured to: according to the current offloading policy identifier, a policy parsing file and a user information parsing file corresponding to the current shunting policy identifier are found in the memory, if there is no policy corresponding to the current shunting policy identifier in the memory. And parsing the file and the user information parsing file, and loading the policy parsing file and the user information parsing file in the form of a string in the Redis server into the memory by using a loading string according to the current shunting policy identifier; among them, The Nginx server is further configured to perform the publishing according to the offloading policy parsed by the policy parsing file. The system according to claim 1, wherein the Nginx server is further configured to search for a policy resolution file ID and a user information resolution file ID corresponding to the current distribution policy identifier according to the current distribution policy identifier, according to the The policy parsing file ID and the user information parsing file ID are used to load the policy parsing file and the user information parsing file in the form of a string in the Redis server by way of loading the string into the memory and converting it into a table for storage. The system according to claim 1, wherein the Nginx server is further configured to parse the corresponding offloading policy by using the policy parsing file, and parse between at least one parameter information and a forwarding path in the offloading policy. Correspondence relationship, And saving the correspondence between the at least one parameter information and the forwarding path to the Cache. The system according to claim 3, wherein the Nginx server is further configured to receive a request sent by the client, extract user information in the request, and parse the preset extraction manner in the file according to the user information. At least one parameter information is extracted from the user information, and the extracted at least one parameter information is used as a user feature, and the user feature is determined according to a correspondence between at least one parameter information and a forwarding path stored in the Cache. Corresponding forwarding paths are forwarded according to the forwarding path. The system according to claim 1, wherein the Nginx server is further configured to parse the corresponding offloading policy by using the policy parsing file, parse out a corresponding percentage policy, and perform corresponding publishing according to the percentage policy. . A grayscale publishing method, comprising: The Nginx server periodically searches for the traffic distribution policy identifier in the Cache according to the preset rule. If the traffic distribution policy does not exist in the Cache, the current traffic distribution policy identifier is read from the preset location in the Redis server, where the Redis server stores The current splitting policy identifier and the corresponding policy parsing file and user parsing file exist in the form of a string; Determining, by the current offloading policy identifier, whether a policy parsing file and a user information parsing file corresponding to the current shunting policy identifier exist in the memory; If the policy parsing file and the user information parsing file corresponding to the current shunting policy identifier are not in the memory, the policy in the form of a string in the Redis server is used to load the string according to the current shunting policy identifier. Parsing files and user information parsing files are loaded into memory via lua; and The distribution policy is parsed according to the policy parsing file. The method according to claim 6, wherein if the policy parsing file and the user information parsing file corresponding to the current shunting policy identifier do not exist in the memory, the loading string is used according to the current shunting policy identifier. The method of loading the policy parsing file and the user information parsing file in the form of a string in the Redis server into the memory through lua includes: If the policy analysis file and the user information analysis file corresponding to the current traffic distribution policy identifier are not in the memory, the policy resolution file ID and the user information analysis file ID corresponding to the current traffic distribution policy identifier are searched according to the current traffic distribution policy identifier; According to the policy parsing file ID and the user information parsing file ID, the policy parsing file and the user information parsing file in the form of a string in the Redis server are loaded into the memory through lua and converted into a Table by loading a string. Store. The method according to claim 6, wherein the distributing according to the splitting policy parsed by the policy parsing file comprises: The policy analysis file is used to parse the corresponding traffic distribution policy, and the correspondence between the at least one parameter information and the forwarding path in the traffic distribution policy is analyzed. And saving the correspondence between the at least one parameter information and the forwarding path to the Cache; The advertised according to the correspondence between the at least one parameter information in the Cache and the forwarding path. The method of claim 8 further comprising: Receiving a request sent by the client, and extracting user information in the request; And extracting at least one parameter information from the user information according to a preset extraction manner in the user information parsing file, and using the extracted at least one parameter information as a user feature; And determining, according to the correspondence between the at least one parameter information and the forwarding path, the forwarding path corresponding to the user feature, and performing corresponding forwarding according to the forwarding path. The method according to claim 6, wherein the distributing according to the splitting policy parsed by the policy parsing file comprises: The policy analysis file is used to parse the corresponding traffic distribution policy, and the corresponding percentage policy is parsed, and the corresponding release is performed according to the percentage policy. A server comprising a memory and a processor, the memory storing computer readable instructions, the computer readable instructions being executed by the processor such that the processor performs the following steps: If the traffic policy is not found in the Cache, the current traffic distribution policy identifier is read from the preset location in the Redis server. The Redis server stores the current traffic policy. The traffic policy identifier and the corresponding policy parsing file and user parsing file exist in the form of a string; Determining, by the current offloading policy identifier, whether a policy parsing file and a user information parsing file corresponding to the current shunting policy identifier exist in the memory; If the policy parsing file and the user information parsing file corresponding to the current shunting policy identifier are not in the memory, the policy in the form of a string in the Redis server is used to load the string according to the current shunting policy identifier. Parsing files and user information parsing files are loaded into memory via lua; and The distribution policy is parsed according to the policy parsing file. The server according to claim 11, wherein if the policy parsing file and the user information parsing file corresponding to the current shunting policy identifier are not present in the memory, the current shunting policy identifier is The steps of loading the policy parsing file and the user information parsing file in the form of a string into the memory by using the load string in the manner of loading the string into the memory include: If the policy analysis file and the user information analysis file corresponding to the current traffic distribution policy identifier are not in the memory, the policy resolution file ID and the user information analysis file ID corresponding to the current traffic distribution policy identifier are searched according to the current traffic distribution policy identifier; According to the policy parsing file ID and the user information parsing file ID, the policy parsing file and the user information parsing file in the form of a string in the Redis server are loaded into the memory through lua and converted into a Table by loading a string. Store. The server according to claim 11, wherein the step of publishing by the processor according to the splitting policy parsed by the policy parsing file comprises: The policy analysis file is used to parse the corresponding traffic distribution policy, and the correspondence between the at least one parameter information and the forwarding path in the traffic distribution policy is analyzed. And saving the correspondence between the at least one parameter information and the forwarding path to the Cache; The advertised according to the correspondence between the at least one parameter information in the Cache and the forwarding path. The server according to claim 13, wherein the processor is further configured to perform the following steps: Receiving a request sent by the client, and extracting user information in the request; And extracting at least one parameter information from the user information according to a preset extraction manner in the user information parsing file, and using the extracted at least one parameter information as a user feature; And determining, according to the correspondence between the at least one parameter information and the forwarding path, the forwarding path corresponding to the user feature, and performing corresponding forwarding according to the forwarding path. The server according to claim 11, wherein the step of issuing the offloading policy parsed according to the policy parsing file performed by the processor comprises: The policy analysis file is used to parse the corresponding traffic distribution policy, and the corresponding percentage policy is parsed, and the corresponding release is performed according to the percentage policy. One or more computer readable non-volatile storage media storing computer readable instructions, when executed by one or more processors, cause the one or more processors to perform the steps of: If the traffic policy is not found in the Cache, the current traffic distribution policy identifier is read from the preset location in the Redis server. The Redis server stores the current traffic policy. The traffic policy identifier and the corresponding policy parsing file and user parsing file exist in the form of a string; Determining, by the current offloading policy identifier, whether a policy parsing file and a user information parsing file corresponding to the current shunting policy identifier exist in the memory; If the policy parsing file and the user information parsing file corresponding to the current shunting policy identifier are not in the memory, the policy in the form of a string in the Redis server is used to load the string according to the current shunting policy identifier. Parsing files and user information parsing files are loaded into memory via lua; and The distribution policy is parsed according to the policy parsing file. The non-volatile storage medium according to claim 16, wherein if the policy parsing file and the user information parsing file corresponding to the current shunting policy identifier are not present in the memory, The step of loading the policy parsing file and the user information parsing file in the form of a string in the Redis server into the memory by using the load string in the manner of loading the string includes: If the policy analysis file and the user information analysis file corresponding to the current traffic distribution policy identifier are not in the memory, the policy resolution file ID and the user information analysis file ID corresponding to the current traffic distribution policy identifier are searched according to the current traffic distribution policy identifier; According to the policy parsing file ID and the user information parsing file ID, the policy parsing file and the user information parsing file in the form of a string in the Redis server are loaded into the memory through lua and converted into a Table by loading a string. Store. The non-volatile storage medium according to claim 16, wherein the step of issuing the offloading policy parsed according to the policy parsing file by the processor comprises: The policy analysis file is used to parse the corresponding traffic distribution policy, and the correspondence between the at least one parameter information and the forwarding path in the traffic distribution policy is analyzed. And saving the correspondence between the at least one parameter information and the forwarding path to the Cache; The advertised according to the correspondence between the at least one parameter information in the Cache and the forwarding path. The non-volatile storage medium according to claim 18, wherein the processor is further configured to perform the following steps: Receiving a request sent by the client, and extracting user information in the request; And extracting at least one parameter information from the user information according to a preset extraction manner in the user information parsing file, and using the extracted at least one parameter information as a user feature; And determining, according to the correspondence between the at least one parameter information and the forwarding path, the forwarding path corresponding to the user feature, and performing corresponding forwarding according to the forwarding path. The non-volatile storage medium of claim 16, wherein the step of issuing the offloading policy parsed according to the policy parsing file by the processor comprises: The policy analysis file is used to parse the corresponding traffic distribution policy, and the corresponding percentage policy is parsed, and the corresponding release is performed according to the percentage policy.