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

This article mainly explains "how to understand Service Mesh". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how to understand Service Mesh".

Time 0: developers imagine the way different services communicate with each other

The abstract representation is as follows:

Time 1: the era of primitive Communication

However, the reality is much more complex than imagined. In the actual situation, communication needs the physical layer that can transmit bytecode and electronic signals. Before the emergence of TCP protocol, the service needs to deal with a series of flow control problems faced by network communication, such as packet loss, disorder, retry and so on. Therefore, in the service implementation, in addition to business logic, it is also mixed with the processing logic of network transmission.

Era 2:TCP era

In order to avoid that each service needs to implement a set of similar network transmission processing logic, TCP protocol appears, which solves the general flow control problem in network transmission, moves the technology stack down, pulls out from the implementation of the service, and becomes a part of the network layer of the operating system.

Time 3: the first generation of micro-services

After the emergence of TCP, the network communication between machines is no longer a difficult problem, and the distributed system represented by GFS/BigTable/MapReduce is booming. At this time, the unique communication semantics of distributed systems appear again, such as circuit breaker strategy, load balancing, service discovery, authentication and authorization, quota restrictions, trace and monitoring, etc., so services realize part of the required communication semantics according to business requirements.

Time 4: the second generation of microservices

In order to avoid the need for each service to implement a set of semantic functions for distributed system communication, with the development of technology, some development frameworks for micro-service architecture have emerged, such as Twitter's Finagle, Facebook's Proxygen and Spring Cloud, and so on. These frameworks implement a variety of general semantic functions needed for distributed system communication, such as load balancing and service discovery, so these communication details are shielded to some extent. It enables developers to develop robust distributed systems with less framework code.

Time 5: the first generation of Service Mesh

The second-generation microservice model seemed perfect, but developers soon discovered that it also had some essential problems:

First, although the framework itself shields some common functional implementation details of distributed system communication, developers have to spend more energy on mastering and managing the complex framework itself. In practical applications, it is not easy to track and solve problems in the framework.

Second, the development framework usually supports only one or more specific languages. Looking back at the definition of micro-services at the beginning of the article, an important feature is that they are language-independent, but those services written in languages that are not supported by the framework are difficult to integrate into the micro-service-oriented architecture, and it is difficult to implement different modules in the architecture system in multiple languages according to local conditions.

Third, the framework is linked with services in the form of lib library, and the compatibility of the library version when complex projects depend is very thorny. At the same time, the upgrade of the framework library is not transparent to the service, and the service will be forced to upgrade because of the lib library upgrade that has nothing to do with business.

Therefore, the agent mode (side car mode) represented by Linkerd,Envoy,Ngixmesh arises at the historic moment, which is the first generation Service Mesh, which abstracts the communication of distributed services into a single layer, in which it implements the functions needed by distributed systems, such as load balancing, service discovery, authentication and authorization, monitoring and tracking, flow control, etc., as a proxy service equivalent to the service, it is deployed with the service to take over the traffic of the service. The communication requests between services are completed indirectly through the communication between agents, so that the three problems mentioned above can also be easily solved.

If we look at it from a global perspective, we will get the following deployment diagram:

If we skip the service for a while and just look at the network of stand-alone components of Service Mesh:

I believe that by now, you have understood the so-called Service Mesh, that is, the service grid. It does look like an intricate grid of several service proxies.

Time 6: the second generation Service Mesh

The first generation of Service Mesh consists of a series of stand-alone agent services that run independently. In order to provide a unified upper operation and maintenance entrance, a centralized control panel is evolved. All stand-alone agent components update network topology strategies and report stand-alone data by interacting with the control panel. This is the second generation Service Mesh represented by Istio.

The Service Mesh global deployment view of the stand-alone agent component (data panel) and control panel is as follows:

At this point, after witnessing the changes of six times, we must have a clear understanding of what Service Mesh technology is and how it has evolved into such a form step by step.

Now, let's go back to the definition of Service Mesh in Buoyant's CEO William Morgan, the inventor of the word Service Mesh:

The service grid is an infrastructure layer that handles communication between services. Cloud native applications have complex service topologies, and service grids ensure that requests travel reliably through these topologies. In practical applications, the service grid is usually composed of a series of lightweight network agents, which are deployed with the application, but transparent to the application.

There are four key words in this definition:

Infrastructure layer + requests travel reliably through these topologies: is it deja vu that these two words together describe the location and function of Service Mesh? Yes, you must have thought of TCP.

Network proxy: this describes the implementation form of Service Mesh

Transparency to applications: this describes the key features of Service Mesh, and it is precisely because of this feature that Service Mesh can solve three essential problems faced by the second generation micro-service framework represented by Spring Cloud.

Thank you for your reading, the above is the content of "how to understand Service Mesh", after the study of this article, I believe you have a deeper understanding of how to understand Service Mesh, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.