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

Make sure that your Microservices optimizes which of the five rules are. For this question, this article describes in detail the corresponding analysis and solutions, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

In recent years, everyone seems to be fascinated by micro-services, while monolithic architecture is slowly fading out of people's sight.

Of course, hot trends always come and go, and the attention they receive is often exaggerated by the media, which is not always the case. For microservices, however, there seems to be a consensus that this trend will last forever. It makes sense. From a conceptual point of view, microservices extend the same principles that engineers have adopted for decades.

Once you start using the microservice architecture, you may need the five rules mentioned in this article to help you run them successfully.

The other side of microservices

Separation of concerns (SoC) is a design principle that states that different parts of software should be built based on "concerns" or overall functions, and has been used to determine how to build technologies for more than 30 years. In the single application, it is reflected in the separation of the presentation layer, the business layer and the data layer in the typical three-tier architecture.

Microservices adopt this concept and subvert it. They separate the same application in such a way that a single code base of the application can be decomposed and deployed separately. The benefits of doing so are huge, but there are also costs, which are usually reflected in the high cost of operation and maintenance in terms of time and money. In addition to the huge upfront investment of transitioning an existing application to a container, maintaining the application presents new challenges.

Challenge 1: it seems difficult to monitor the whole

Although monolithic applications have their own challenges, the process of rolling back a "bad" version in a monolithic is fairly simple. In containerized applications, things become much more complicated. Whether you are gradually breaking down a single application into micro-services or building a new system from scratch, you now have more services to monitor. Each of them may:

Use different technologies and / or languages.

Run on different machines and / or containers

Containerization and orchestration using K8s or similar technology

As a result, the system becomes highly decentralized and needs centralized monitoring. Unfortunately, this also means that there are more things to monitor. There used to be only one single process, but now there may be dozens of containerized processes running in different areas, sometimes even different clouds. This means that there is no longer a single set of operations metrics to dominate them, which the IT/ operations team can use to assess the general uptime of the application. Instead, teams now have to deal with hundreds (or even thousands) of metrics, events, and alarm types from which they need to separate valid signals and invalid noise.

Solution

DevOps monitoring needs to move from a flat data model to a hierarchical model, in which a series of advanced system and business KPI can be observed at any time. As long as there is a slight deviation, the team must be able to enter the metric hierarchy to see which micro-service the interference is coming from, and from there to understand the container that actually failed. This is likely to require re-tuning the DevOps toolchain from a data storage and visualization perspective. Open source temporal DB tools such as Prometheus and Grafana 7. 0 make this goal very easy to achieve.

Challenge 2: cross-service logging

When talking about monitoring applications, one of the first things to mention is: logs. The daily IT logs generated by the server are equivalent to carbon emissions, resulting in overflowed hard drives and frenzied ingestion, storage and tool costs. Even with a single architecture, your journal may have given your engineer a headache.

With microservices, logs become more fragmented. A simple user business can now be done through a number of services, all of which have their own logging framework. To solve the problem, you must extract all the different logs from all the services the business may pass to understand the problem.

Solution

The main challenge here is to understand how a single business "flows" between different services. In order to achieve this, it is necessary to make a lot of changes to how traditional single programs usually record all events during sequential business execution. Although many frameworks have emerged to help developers (we particularly like Jaeger's approach), for companies looking to restructure monoliths into micro-services, the transition to asynchronous, trace-driven logging is still a daunting effort.

Challenge 3: deploying one service destroys another

A key assumption in the single-chip world is that all code is deployed at the same time, which means that the time frame in which the application is in the most vulnerable state is a known and relatively short period of time (that is, the first 24-48 hours after deployment). In the world of microservices, this assumption is no longer true: because microservices are intrinsically intertwined, minor changes in one service can lead to behavioral or performance problems that can be reflected in the other. So the challenge is that the current malfunctioning microservices make it impossible for another development team to anticipate interruptions in their code. This can lead to unexpected instability of the entire application as well as friction within some organizations. While the microservice architecture may make the process of deploying code easier, it actually makes it more difficult to verify the behavior of the code after deployment.

Solution

Enterprises must create shared release calendars and allocate resources to closely test and monitor the behavior of the entire application whenever related micro-services are deployed. Deploying new versions of microservices without cross-team coordination, like avocado and toast, is the secret of success in solving this challenge.

Challenge 4: it is difficult to find the root cause of the problem

At this point, you have locked down the problematic service and extracted all the data you need to extract, including stack traces and some variable values in the log. You may also have some APM solutions, such as New Relic, AppDynamics, or Dynatrace. From there, you will get some additional data about the unusually high processing time of some related methods. But. What is the root cause of the problem?

The first few variables you get from the log are likely not to be those moving needles. They are usually more like bread crumbs, pointing in the direction of the next clue rather than a further reason. At this point, we need to try our best to discover the "magic" of more applications. Traditionally, this requires issuing detailed information about the status of each failed transaction (that is, why it failed). The challenge here is that developers need to be highly prescient to know what information they need to troubleshoot the problem in advance.

Solution

When the root causes of errors in microservices span multiple services, it is important to develop a centralized method to detect the root causes of problems. The team must consider which information particles are needed to diagnose future problems, and at what level they should be logged to take into account performance and security factors-this is a high mountain and a never-ending mountain.

Challenge 5: version management

We think the problem worth emphasizing is the transition from a layer model in a typical monolithic architecture to a graph model for microservices. Since more than 80% of application code is usually third-party code, managing the sharing of third-party code between the company's different microservices is a key factor in avoiding unprecedented dependency hell.

Consider a situation where some teams are using the X.Y version of third-party components or shared instance programs (available in almost all companies), while others are using the X.Z version. This increases the risk of critical software problems due to a lack of compatibility between different versions, or slight changes in behavior between different versions, which can lead to the need to troubleshoot the most specific and painful software bug.

Before all this, we have to remind ourselves that any microservice that uses an older or more vulnerable version of third-party code will create security problems-a paradise for hackers. Allowing different teams to manage their dependencies in an island-like repo may be feasible in a single world, but it is absolutely not possible in a micro-services architecture.

Solution

Companies must invest in redesigning their build processes to take advantage of centralized artifact repositories (Artifactory will be one of them) for third-party and shared utility code. Teams should only be allowed to store their own code in separate repositories.

The last thought

Like most advances in the technology industry, microservices have adopted a familiar concept and subverted it. They rethink the way large-scale applications are designed, built, and maintained. They bring many benefits, but they also bring new challenges. When we look at these five major challenges together, we can see that they all come from the same idea. Therefore, whenever you adopt a new technology such as microservices, the bottom line is that you need to rethink as well as adjust the way your code is built, deployed, and observed. The advantages of microservices are hard to refuse-but the risks are also huge.

This is the answer to the question about what are the five rules to ensure the optimal operation of your Microservices. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

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.