The differences and characteristics of blue-green release, rolling release, and gray release of microservice deployment

In the process of project iteration, it is inevitable to "go online". Going online corresponds to deployment or redeployment; deployment corresponds to modification; modification means risk. There are many technologies deployed and released, here is a summary of the common ones.

The above is inevitably a bit abstract. Take a scenario example. Add you as the person in charge of the Weibo project. Now the new version has a lot of changes from the original old version. This design includes service architecture, front-end UI, etc., after testing, there is no function Obstacles, so how do you let users switch to the new version at this time?

Obviously, the first release of the application does not have this problem. This kind of thinking about how to release will only appear in subsequent version iterations.

Blue-green release

In the blue-green deployment, there are two sets of systems: one is the service system (that is, the old version mentioned above), marked as "green"; the other is the system ready to be released, marked as "blue". Both systems are fully functional, and the systems that are running are only different in system versions and external services. The old system that is providing services to the outside world is the green system, and the newly deployed system is the blue system.

The blue system does not provide external services, what is it used for?

It is used for pre-release testing. Any problems found during the testing process can be modified directly on the blue system without interfering with the system that the user is using.

After repeated testing, modification, and verification of the blue system, after confirming that it meets the online standard, the user is directly switched to the blue system. After the switching, the blue and green systems still coexist, but the user accesses the blue system. Color system. During this time, observe the working status of the blue system (new system), if there is a problem, switch back to the green system directly.

When it is believed that the blue system that provides services to the outside world is working properly, and the green system that does not provide services to the outside world is no longer needed, the blue system officially becomes the service system to the outside world and becomes the new green system. The original green system can be destroyed to free up resources for the deployment of the next blue system.

Blue-green release characteristics

• The purpose of blue-green deployment is to reduce the interruption time during release and to be able to withdraw the release quickly.
• Only when the two systems are not coupled can they be 100% guaranteed not to interfere

Blue-green release notes

Blue-green deployment is only one of the online strategies, it is not a panacea that can deal with all situations. The premise of blue-green deployment can be implemented simply and quickly. The assumption is that the target system is very cohesive. If the target system is quite complex, then how to switch, whether the data of the two systems are required and how to synchronize, etc., all need to be carefully considered.

When you switch to the blue environment, you need to properly handle unfinished business and new business. If your database backend cannot handle it, it will be a troublesome problem;

• There may be situations in which "microservice architecture applications" and "traditional architecture applications" need to be processed at the same time. If the two are not properly coordinated in the blue-green deployment, it may still cause the service to stop.
• It is necessary to consider in advance the issue of synchronous migration/rollback of database and application deployment.
• Blue-green deployment requires infrastructure support.
• Performing blue-green deployment on non-isolated infrastructure (VM, Docker, etc.), the blue environment and the green environment are at risk of being destroyed.

Rolling release

Generally, one or more servers are taken out to stop the service, perform the update, and put them back into use. Repeatedly, until all the instances in the cluster are updated to the new version.

Release process:

Compared with the blue-green release that requires a complete set of machines, rolling release only requires one machine (here for understanding, there may be more than one), we only need to deploy some of the functions on this machine, and then replace it The running machine, as shown above, deploy the updated function on Server1, and then Server1 replaces the running Server, and the replaced physical machine can continue to deploy the new version of Server2, and then replace the working Server2, with And so on, until all servers have been replaced, at this point, the service update is complete.

Rolling release features

• Compared with blue-green deployment, this deployment method saves more resources-it does not need to run two clusters and twice the number of instances. We can deploy partly, for example, only take out 20% of the cluster for upgrade each time.
• Difficulty rolling back

Notes for rolling release

• There is no definite viable environment for rolling releases. Using blue-green deployment, we can clearly know that the old version is feasible, while using rolling release, we can't be sure.
• Modified the existing environment.
• Difficulty rolling back. For example, in a certain release, we need to update 100 instances, each update of 10 instances, each deployment takes 5 minutes. When scrolling to the 80th instance, a problem was found and a rollback was required. This rollback was a painful and long process.
• Sometimes, we may also dynamically scale the system. If the system automatically expands/shrinks during deployment, we still need to determine which node is using which code. Although there are some automated operation and maintenance tools, it is still frightening.
• Because it is a gradual update, when we launch the code, there will be a short period of inconsistency between the new and the old version. If there are scenarios with high online requirements, then we need to consider how to do a good job of compatibility.

Grayscale release

Grayscale release, also called canary release. It refers to a publishing method that can smoothly transition between black and white. AB test is a gray-scale publishing method. Some users continue to use A and some users start to use B. If users have no objections to B, then gradually expand the scope and migrate all users to B. Grayscale release can ensure the stability of the overall system. Problems can be found and adjusted at the initial grayscale to ensure their impact. What we usually call canary deployment is a way of grayscale release. Recommendation: based on Nginx to achieve grayscale release and AB test

Specific to the server, more control can be done in actual operation. For example, set a lower weight for the initially updated 10 servers, control the number of requests sent to these 10 servers, and then gradually increase the weight and the number of requests . An idea of smooth transition, this control is called "flow segmentation".

In the 17th century, British mine workers discovered that canaries are very sensitive to gas. Even if there is a tiny amount of gas in the air, the canary will stop singing; when the gas content exceeds a certain limit, although the dull humans are unaware of it, the canary has long been poisoned and killed. At that time, with the relatively rudimentary mining equipment, the workers would bring a canary as a "gas detection indicator" every time they went down the well for emergency evacuation in dangerous situations.

process

• Be prepared to deploy artifacts at various stages, including: build artifacts, test scripts, configuration files, and deployment manifest files.
• Deploy the "Canary" server into the server and test it.
• Remove the "canary" server from the load balancing list.
• Upgrade the "Canary" application (drain the original traffic and deploy).
• Automate testing of applications.
• Add the "Canary" server back to the load balancing list (connectivity and health check).
• If the "Canary" online use test is successful, upgrade the remaining other servers. (Otherwise, roll back)

A/B testing

A/B testing and blue-green releases, rolling releases, and canary releases are completely different things.

Blue-green release, rolling release and canary are release strategies. The goal is to ensure the stability of the newly launched system and focus on the bugs and hidden dangers of the new system.

A/B testing is an effect test. There are multiple versions of services for external services at the same time. These services are all services that have been tested enough to meet the online standards. There are differences but no distinction between the new and the old (they may use blue and green when they are online. Deployment method).

A/B testing focuses on the actual effects of different versions of services, such as conversion rates and order status.

During A/B testing, multiple versions of services are running online at the same time. These services usually have some experience differences, such as different page styles, colors, and operating procedures. Relevant personnel analyze the actual effect of each version of the service and select the version with the best effect.

Author: Harmonica Can't Wait
Link: cnblogs.com/Courage129/p/14498788.html