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

How to carry out the practice of operation and maintenance of the development and test environment based on .net micro-service architecture, many novices are not very clear about this. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

At present, to do Internet applications, the hottest architecture is micro-services, and the hottest R & D management is DevOps. Microservices and DevOps have been widely used, and they can do anything as legend has it. Through more than two years of practice, we have found that it is not as simple as everyone said. Everyone reports the good news but not the bad news. The water is too deep. Who knows who does it? Today, I would like to share with you some pain points and solutions for developing a test environment under the micro-service architecture + DevOps.

The complexity of the architecture directly determines the workload of operation and maintenance. The architecture is not the more complex the better, but the best fit. Let's briefly talk about the advantages and disadvantages of several architectures. Based on. Net in building applications, the most commonly used method is to use Asp.net MVC, front-end, back-end All in to a site, saving time and effort, do not care about the complexity of deployment operation and maintenance. But the drawback is also very obvious, all the content is deployed under one site, if the business is complex, the system changes frequently, the stability is worrying, and there is no solution. More complicated is the separation of front and rear ends: H5 (or Winform) + WebAPI, which separates the front and back end changes, but the back end logic is not used, and there are a lot of common methods or repetitive code. What is more complicated is: front-end + WebAPI+Service. Although public services are extracted in this mode, the deployment granularity is still very coarse, and it will basically be deployed in multiple clusters according to the business scope. Under the same cluster, if too many services are deployed, it is still difficult to solve the problems such as assembly conflicts and service changes and restart the cluster. Therefore, in order to isolate changes and reduce the impact on other services, the division granularity of clusters will become smaller and smaller, and even evolve into a service cluster, which is the form of micro-services. To sum up, these architectural patterns are the changes of horizontal and vertical dimensions, and the horizontal dimension has changed from one kind of site to many kinds of sites, in order to solve the problems of access and code consumption caused by the changes. The vertical dimension changes from all applications deployed in one site to one service and one cluster, isolating the impact of the change. The evolution of the architecture from one point to two dimensions will eventually lead to an exponential increase in operation and maintenance costs. The following is the micro-service architecture diagram of Tencent Cloud platform, from which we can see that the overall architecture is more complex.

In order to support the national charging business, Tailai Yunping currently has nearly 1000 servers, application class 100 +, WebAPI interface 2000, service interface 500, and dozens of development and test environments. Only the generated environment will be hot updated as many as 20 times a day. More than 20 hot updates must be unit tested, deployed to a test environment that is almost the same as the production environment for interface testing, UI testing, and then regression testing in the quasi-production environment before it can be released to the two data centers in grayscale. At this point, you will probably think of standardizing the synchronization of the environment through DevOps: after CI is complete, product updates are deployed to multiple environments for testing through CD, and then released to the production environment. Yes, under normal circumstances, this process is fine, but the reality is very cruel. There are too many factors that cause the test environment to be inconsistent with production. Let's talk about it briefly:

Net Framework cannot adopt Docker, and there are not only program file updates, but also configuration updates and SQL updates in the update package. In such a large scale, the cost of manual renewal is so high that it basically needs a full-time post to do it. If you do it manually, it is easy to make mistakes. It must be instrumented and automated, and patch updates must be done 100% through tools without human intervention, otherwise inconsistencies will occur in different environments.

The system changes almost every hour, the common increase or decrease of applications, services, WebAPI, these information changes will affect the system environment. As long as a program, interface, service management is not in place, the system may give you color to see. All machine information, service information and configuration information must be managed and maintained centrally and synchronized automatically in all kinds of environments. CMDB is a necessary management system.

In the daily research and development, many requirements will involve the joint development of multiple product R & D departments, the cycle of integration testing is very long, but the number of test environment is limited, there are often some embarrassing problems that some urgent requirements do not have a test environment.

The test environment will perform updates frequently, and even an update will be repeated many times, which can easily lead to a mismatch between the test environment and the production environment. As a result, there is a bug after the hot update of the program, which needs to be backed back urgently.

The development test environment is open to every developer, and everyone will log in to the system Debug. You know, as long as you Debug once, there is a good chance that the program will change.

A business may need several or even more than a dozen programs to provide services to run normally. If there is a problem in one link, the whole system will go wrong. How to analyze and troubleshoot problems quickly is a painful problem. This is a problem that drives a lot of people crazy.

. . .

In the face of so many changes, DevOps becomes very ideal and powerless. The landing of DevOps needs to find a balance in continuous improvement. Our solution is:

Build a CMDB system to manage the deployment information of all kinds of environments. For example: cluster information, process information, service information, WebAPI information, configuration information and so on. And the changes of these information should be managed centrally through the system, and the inconsistency between CMDB information and deployment information must not be allowed.

Build a patch system. Standardized management of development deliverables. Through the patch production tool, make the formatted patch, through the patch installation platform to achieve the installation of the patch package. The changes of system program and SQL are all carried out through the patch platform. The patch system is a very complex system, which will be described in more detail later.

Build the template machine environment, when the production system updates the patch or CMDB information changes, through automated tools, actively push to the template machine. Ensure the real-time synchronization of the production environment and the test environment. All kinds of test environments are cloned from the template machine and change synchronously with the template machine through tools. After the synchronization is complete, make sure that the environment is available through automated testing tools and environmental checking tools.

Develop a full-link monitoring system and bury points at each entrance of the system to help developers analyze system problems. The full-link monitoring system is also a very complex system, which will be introduced in detail later. The following is the basic schematic diagram and operation effect diagram of the full link.

To do Internet application requires not only genes, but also the courage and perseverance to fill the hole. The process of filling the hole is the process of climbing the technological peak, which is endless!

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.