When I first entered Ali, I didn’t even know what gray scale was, but the concept of gray scale is very common in Dachang. As long as there is a certain number of users, applications will involve gray scale release. Therefore, students preparing to enter Dachang must understand the concept of gray scale release.

What is gray scale release?

Grayscale publishing, also known as canary publishing, refers to the smooth transition between a new release feature and an old feature, like the smooth transition of multiple colors of canary feathers.

For example, a system that is already online and in operation needs a new function iteration. However, due to the great changes in functions, the release needs to consider users’ feedback and the possibility of some unknown anomalies in the code. At this time, new functions need to be gradually pushed to users in batches.

In the process of the gradual measures, can according to user acceptance (how much you have customer complaint) and observe the function before the existence of online found no abnormalities, to decide whether to continue to push new function, poor feedback if the new function or dysfunction problems, stop peatlands or roll back to previous ones and stable version, modify the problem in time.

In this way, users can avoid the problem of online problems suddenly rising and blocking users in the case of a push.

Two. Grayscale release advantages

1. Collect users’ opinions in advance and improve product functions in time. 2. If the product has external problems (such as compliance), it can be rolled back to the old version in time

Three. Front gray release elements

1. Volume rule

If new features are phased in, there must be a rule that allows users to be grouped into groups based on certain characteristics, such as age, city, or user id when they sign up. For example, when the user registers, there is a serial number from 0 to increase, when the gray scale can take the serial number as the dimension, from small to large volume, until 100 percent complete.

A perfect system at the beginning of the design will be considering the gray level scheme, if you look at the user’s uid during registration there must be a serial number and id like in 15th place from 0 to 9 serial number, average users uid will stay of two as on the serial number, gray level when the two is as a general grayscale characteristics.

2. Old and new versions of resources

Can clearly identify to show the user two kinds of page form, can be in the form of front-end static version number, such as each release of resources, static resource version number link changes, at this time the gray level is actually two different resource request link gradually from the old to the new process.

Four. Gray realization principle

Below is gray the implementation of the basic principle of the key judging or gray user operation in this step, you can before the request to judge, and then directly request corresponding resources, also can request to the server, the server to distinguish whether the user belongs to gray list, then return the corresponding resources content, specific to see how the front-end application deployment, the form of It doesn’t matter if it’s server-side rendering or client-side rendering.

Five. Several ways to release the front gray scale

1. Render the application on the server

It is important to know that the server render application renders the static template before returning it to the client. This means that the grayscale process is completed before the user’s request is returned, and nothing grayscale is processed on the client side. The diagram below:

Simple description, first, the user request, the server will not be directly assembled static resources, but go to the gray level rules in the access list, then render will be treated as gray list to get the judge to decide that a template resource to give to the client, the final show in gray list of users new version of the page, Instead of the list of users to continue to use the old version of the page content, such as the need to volume, directly in the gray rules can be modified.

Take a look at the following code example

// Server code
// Static template
const model1 = (a)= > {
 return ` 
         
       
         
      

        I am A interface 
      
  
       '
}
const model2 = (a)= > {
 return ` 
         
       
         
      

        I am B interface 
      
  
       '
}
const isPass = getRule(req.uid) // Query rules
if (isPass) { // In the whitelist
  res.render(model2)
} else {
  res.render(model1)
}
...Copy the code

In the above code, there are two versions of the interface, A, B, the user requested resources before returning to obtain gray rules through getRule, determine whether the white list, and then decide to return that set of template content.


2. Application of semi-separation of front and rear ends

Here the front and back half separated application refers to a part of the front application of the HTML file is still on the server side, but actually in the client side rendering, I believe you see more, such as the following code.


        
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
</head>
<body>
<div id="react-content"></div>
</body>
<script src="http://cdn.com/1.0.1/my.js"></script>
</html>Copy the code

When we use React or Vue, we end up packing the code into a JavaScript file and loading it into an HTML file. The HTML file is put into a server system, and when the user requests a resource, the HTML is returned to the client. The client to get the content after loading on the http://cdn.com/1.0.1/my.js network resources, then the local rendering.

For example, the above version is 1.0.1. Here, the CDN storage path is also 1.0.1/my.js. Use the uniqueness of the path to distinguish the inconsistency with other versions, of course, you can also add the version number to the file name, such as /my_1. As long as you can identify the uniqueness of the resource is ok.

So let’s do a little pseudocode here to see what grayscale looks like.

// Server code
const isPass = getRule(req.uid) // Query rules
let version = 1.01.; // Old version number
if (isPass) { // In the whitelist
  version = 2.0. 0
}
// Static template
const model = version= > {
 return ` 
         
       
         
      
    `
}
res.render(model(version))  // Return the template with the version numberCopy the code

In this code, because of the requirements of two iterations, the front-end developer packaged the front-end resources into two resource packages and uploaded them to different locations of THE CDN respectively. The version number was used as the identification to determine the old and new contents.

When the user’s request is received, getRule obtains the grayscale rule to determine which version of the resource to show to the current user, and then returns the template content with the resource version. After receiving the template, the client loads the corresponding version of the resource, so as to meet the grayscale requirements.


3. Front-end application of client rendering

At present, the most common type of deployment, after the front-end development is completed, directly packaged to the CDN, and then use Nginx to request static resources, at this time the CDN server will not do grayscale judgment related operations, that is, at this time can not let the back end through a gray logic to control version. While the front-end data requests are asynchronous Ajax, how to do gray scale?

The first idea is:

We can write two sets of content in the front-end code, before the page rendering asynchronously to obtain gray rule request, after the results in the client to decide to render that set of pages, so as to meet the requirements of gray.

Take a look at the pseudocode below:

// Client-side code
/ / component
const component1 = (a)= > {
 return (<div>I'm component A</div>)}const component2 = (a)= > {
 return (<div>I'm component B</div>)}const isPass = $.ajax('/getRule? uid') // Query rules. render() {if (isPass) { // In the whitelist
    return model2()
  } else {
    return model1()
  }
}
...Copy the code

Above the client code to complete the user gray, but there is a problem, when the late demand increased front-end code will be very large, and every time new demand release is bound to test whether to return to the old version has been changed to maintain two sets of content, as maintenance becomes very tired get wider applications.

Second idea:

Would this be solved if we kept the version number to distinguish each iteration and just got the correct version resources to render before rendering?

Take a look at the pseudocode below:

// Client-side code
const syncLoadJs = function (version, fn) {
  const oScript = document.createElement('script');
  oScript.setAttribute('src'.`https://cdn.com/{version}/my.js`);
  oScript.setAttribute('type'.'text/javascript');
  oScript.onload = fn;
  oScript.onerror = function() { window.location.href = '/error.htm' };
  document.body.appendChild(oScript); },... const isPass = $.ajax('/getRule? uid') // Query rules
let version = 1.01.; // Old version number
if (isPass) { // In the whitelist
  version = 2.0. 0
}
syncLoadJs(version, function(){
  ReactDOM.render());  // The client gets the resource and renders it})...Copy the code

In this case, the resource version is asynchronously retrieved before the client rendering, and the page rendering is performed after the resource version is retrieved.

However, there is a problem here. Each page needs to obtain grayscale rules and judge whether it is grayscale. This grayscale request will block the page and may cause poor user experience, so we can consider using localStrage of the client to store whether the user is grayscale user. Instead of sending a request every time a resource is requested to determine whether it is a grayscale user, and then periodically updating the values stored in localStrage, replacing the experience problems caused by a large number of requests.


The above content is their own summary, there will be mistakes or understanding bias, if there are questions, I hope you leave a message to correct, so as not to mistake people, if there are any questions please leave a message, we will try our best to answer it. !


Highlights from the past

Why don’t the id numbers repeat