Source code of this article: GitHub·click here || GitEE·click here
1. Introduction to Service Release
Under the distributed system architecture, service release is a very troublesome thing, especially in the two core aspects of building an automatic release process and a gray-scale test strategy. Normally, if the grayscale process at the data level is not involved, the service can be launched in grayscale or rolled online. These two methods are very common; if the grayscale of the data is involved, an intermediate service may be required to balance the data of different versions , Or shut down for maintenance to deal with data and online issues at one time, but the latter approach is more risky.
Two, blue-green deployment
When the new version is online, the old version is not stopped. The old and the new version are running at the same time. Usually, the old version service processing request is inclined to the old version in the load balancing strategy, so that the new version has an execution observation period transition period. After the new version runs smoothly for a period of time, all requests are sent to the new version of the service, and the old version of the service is completed offline. This method is rarely used in a distributed architecture and requires too much server.
Three, rolling release
Rolling release can avoid server resource occupancy for blue-green deployment. First release a new version of the service, then stop an old version of the service. After the new version of the service is observed, then gradually replace all the old version of the service, so that the service environment changes More frequent and relatively unstable.
Four, grayscale release
The above two methods are considered to operate well in ordinary business scenarios. The gray-scale publishing of complex programs in a distributed system is relatively high. The basic process is as follows:
The new version is online, which may involve multiple gray-scale services under distributed distribution. Therefore, when the service is distributed on the entire link, it is necessary to determine whether the next request is routed to a normal service or a gray-scale service, and a request for the gray-scale service The weight control can not let the gray service handle a large number of requests.
Actual strategy : In the actual gray-scale release process of a distributed system, the following strategy is usually adopted:
- Configure a flag indicating whether the grayscale is turned on;
- Configure a batch of gray accounts, usually internal staff;
- Configure gray service version identification;
- When the request is executed on the link, it is judged whether the gray scale is turned on;
- Determine whether the current user identity is a gray test account;
- Get the list of services that can be requested currently;
- Select the specific service requested according to the gray service version;
This process is very complicated and requires a lot of custom strategies. You must also be familiar with the underlying API principles of the distributed framework. It needs to be rewritten twice to adapt to the gray-scale strategy. Rewriting the native API can easily trigger some surprises.
Five, database grayscale
If you say the most difficult gray mode to deal with, it is the version gray problem of the database. Usually the business upgrades to the database are actually handled through shutdown maintenance. Maybe many developments have experienced it, and the suspension announcement is issued, and then All the data will be equalized within the specified time or transported a second time, and then the service will be provided again. However, there are always some business scenarios that cannot be shut down for maintenance. The basic strategy for processing gray data is as follows:
In this mode, in addition to the normal grayscale process, a data allocation service needs to be provided between the grayscale database and the normal data to solve the following problems: the grayscale database lacks data and needs to be temporarily pulled from the normal database. If the version fails, the new data needs to be re-integrated and written into the original normal library; the gray version is successful, and the old version data is migrated; finally, the smooth upgrade of the data is guaranteed.
Six, source code address
GitHub·地址
https://github.com/cicadasmile/data-manage-parent
GitEE·地址
https://gitee.com/cicadasmile/data-manage-parent
Recommended reading: finishing programming system
| Serial number | project name | GitHub address | GitEE address | Recommended |
|---|---|---|---|---|
| 01 | Java describes design patterns, algorithms, and data structures | GitHub·click here | GitEE·Click here | ☆☆☆☆☆ |
| 02 | Java foundation, concurrency, object-oriented, web development | GitHub·click here | GitEE·Click here | ☆☆☆☆ |
| 03 | Detailed explanation of SpringCloud microservice basic component case | GitHub·click here | GitEE·Click here | ☆☆☆ |
| 04 | SpringCloud microservice architecture actual combat comprehensive case | GitHub·click here | GitEE·Click here | ☆☆☆☆☆ |
| 05 | Getting started with SpringBoot framework basic application to advanced | GitHub·click here | GitEE·Click here | ☆☆☆☆ |
| 06 | SpringBoot framework integrates and develops common middleware | GitHub·click here | GitEE·Click here | ☆☆☆☆☆ |
| 07 | Basic case of data management, distribution, architecture design | GitHub·click here | GitEE·Click here | ☆☆☆☆☆ |
| 08 | Big data series, storage, components, computing and other frameworks | GitHub·click here | GitEE·Click here | ☆☆☆☆☆ |