Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to understand the distributed structure, service department release". In daily operation, I believe many people have doubts about how to understand the distributed structure, service department release. Xiaobian consulted all kinds of materials and sorted out simple and easy operation methods. I hope to help you answer the doubts of "how to understand the distributed structure, service department release"! Next, please follow the small series to learn together!

I. Introduction to Service Release

Service publishing can be a hassle in distributed systems architecture, especially in the core areas of building automated publishing processes and gray scale testing strategies. Usually, if the grayscale process at the data level is not involved, the service can be gray online or rolling online, which are very common; if the data grayscale is involved, it may be necessary to level between different versions of data by intermediate services, or stop maintenance to handle the data and online problems at one time, but the latter method is risky.

II. Blue-green deployment

When a new version goes online, it does not stop dropping the old version. The old version and the new version run simultaneously. Usually, the Load Balancer policy tends to favor the old version service to process requests. In this way, the new version has an observation period transition period for execution. After the new version runs smoothly for a period of time, all requests are sent to the new version service, and the old version service is completely offline. This approach is rarely used in distributed architectures and is too demanding on servers.

III. Rolling release

Rolling release can avoid the server resource occupation of 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, gradually replace all the old versions of the service. In this way, the environment of the service changes frequently and is relatively unstable.

IV. Grayscale release

The above two methods are still good to operate in ordinary business scenarios, and the gray level distribution of complex programs in distributed systems is relatively high. The basic process is as follows:

When the new version is launched, it may involve multiple gray scale services distributed, so when the service is distributed on the whole link, it is necessary to judge whether the next request is routed to the normal service or the gray scale service, and the weight control of the request is also performed for the gray scale service, so that the gray scale service cannot handle a large number of requests.

Actual strategy: In the actual distributed system grayscale publishing process, one of the following strategies is usually adopted:

configuring an identification of whether the gray scale is turned on;

Configure a batch of grayscale accounts, usually internal personnel;

Configure grayscale service version identification;

when the request is executed, judging whether the gray scale is turned on or not;

jud whether that identity of the current us is a gray scale test account;

obtaining a list of services currently available for request;

selecting the requested specific service according to the grayscale service version;

This process is very complex, requiring a lot of custom policies, but also familiar with the underlying API principles of the distributed framework, to be rewritten twice to adapt to the gray policy, design rewriting native API is also easy to trigger some surprise problems.

V. Database Grayscale

If the most difficult gray mode to deal with is what is the version of the database gray problem, usually the business to upgrade the database, in fact, through downtime maintenance to deal with, may be a lot of development have experienced, release stop service announcement, and then in the specified time to all the data level or secondary transport, and then re-provide services. However, there are always some business scenarios that cannot be shut down for maintenance. The basic strategy for processing grayscale data is as follows:

In this mode, in addition to the normal grayscale process, it is necessary to provide a data allocation service between the grayscale database and the normal data to solve the following problems: the grayscale database is missing data, it needs to be temporarily taken from the normal Kula, the grayscale version fails, and the new data needs to be re-integrated into the original normal database; the grayscale version succeeds, the old version data is migrated, etc.; and finally, the smooth upgrading of data is guaranteed.

VI. Source code address GitHub·Address https://github.com/cicadasmile/data-manage-parentGitEE·Address https://gitee.com/cicadasmile/data-manage-parent Here, the study on "how to understand distributed structure, service department release" is over, hoping to solve everyone's doubts. Theory and practice can better match to help everyone learn, go and try it! If you want to continue learning more relevant knowledge, please continue to pay attention to the website, Xiaobian will continue to strive to bring more practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.