As the pronoun of the next generation of microservice technology, service mesh is a novice but popular one. It has a great trend of unifying the microservice era.
So what is service mesh?
In a word: service mesh is the TCP protocol in the era of microservices.
With such a perceptual preliminary cognition, let’s look at what service mesh is.
When it comes to service mesh, you have to mention micro services. According to the definition of Wikipedia:
Microservices is a software architecture style. It is based on small building blocks focusing on single responsibility and function, and combines complex large-scale applications in a modular way. Each functional block communicates with each other using language independent / language agnostic API sets.
At present, there are countless development platforms and frameworks related to microservices in the industry: spring cloud, service fabric, linkerd, envoy, istio
What is the relationship between these complex products and sevice mesh? What are the categories of service mesh?
In order to clarify these complex products and concepts, let’s first understand the historical development of microservices and service mesh technology.
If you understand the main context of technology, you can clearly know which node of the above platforms and frameworks belongs to, and the relationship between them is clear at a glance.
Phil cal ç ADO’s article “pattern: service mesh” introduces in detail the evolution process of service development mode and service mesh technology from the perspective of developers. Personally, it is a very classic material for learning service mesh. Here we borrow the context of the article, combine our own understanding and simplify it, and try to clarify the concept of servicemesh and the historical inevitability of the birth of this technology. You can read this article as a Chinese translation of the original text.
Time 0: in the imagination of developers, the communication mode between different services is abstractly expressed as follows:
Era 1: primitive Communication Era
However, the reality is far more complicated than expected. In reality, the communication needs to be completed by the physical layer that can transmit bytecode and electronic signals at the bottom. 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 and retry. Therefore, in addition to business logic, It is also mixed with the processing logic of network transmission problems.
Era 2: TCP Era
In order to avoid that each service needs to implement a similar set of network transmission processing logic, TCP protocol appears. It solves the general flow control problem in network transmission, moves the technology stack down, separates it from the implementation of the service, and becomes a part of the network layer of the operating system.
Era 3: the first generation of micro services
After the emergence of TCP, the network communication between machines is no longer a problem, and the distributed system represented by GFS / BigTable / MapReduce has flourished. At this time, the unique communication semantics of distributed system appear again, such as fuse policy, load balancing, service discovery, authentication and authorization, quota restriction, trace and monitoring, etc. Therefore, the service realizes part of the required communication semantics according to the business requirements.
Era 4: second generation micro services
In order to avoid that each service needs to implement a set of semantic functions of distributed system communication, with the development of technology, some development frameworks for micro service architecture have emerged, such as twitter finagle, Facebook proxygen and spring cloud. These frameworks realize various general semantic functions required by distributed system communication, such as load balancing and service discovery, Therefore, these communication details are shielded to a certain extent, so that developers can develop robust distributed systems with less framework code.
Time 5: first generation service mesh
The second generation microservice model seems perfect, but developers soon found that it also has some essential problems:
- First, although the framework itself shields some general function implementation details of distributed system communication, developers have to spend more energy to master and manage the complex framework itself. In practical application, it is not easy to track and solve the problems of the framework;
- Second, the development framework usually only supports one or several specific languages. Looking back at the definition of microservices at the beginning of the article, an important feature is that they are language independent, but those services written in languages without framework support are difficult to integrate into the microservice oriented architecture, It is also 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. The compatibility of Library versions when complex projects rely on is very difficult. At the same time, the upgrading of framework library cannot be transparent to services, and services will be forced to upgrade due to the upgrading of Lib library unrelated to business;
Therefore, the agent mode (side car mode) represented by linkerd, envoy and nginxmesh came into being. This is the first generation service mesh. It abstracts the communication of distributed services into a single layer, in which the functions required by distributed systems such as load balancing, service discovery, authentication and authorization, monitoring and tracking, flow control and so on are realized, As a proxy service equivalent to the service, it is deployed with the service, takes over the service traffic, and indirectly completes the communication request between services through the communication between agents. In this way, the above three problems can be solved.
From a global perspective, we can get the following deployment diagram:
If we omit the service temporarily, we only look at the network composed of stand-alone components of service mesh:
I believe that now we have understood the so-called service mesh, that is, service grid. It really looks like an intricate grid composed of several service agents.
Time 6: second generation service mesh
The first generation service mesh is composed of a series of stand-alone agent services running independently. In order to provide a unified upper operation and maintenance entrance, a centralized control panel has been evolved. All stand-alone agent components update network topology policies and report stand-alone data through interaction with the control panel. This is the second generation service mesh represented by istio.
Just look at the service mesh global deployment view of the stand-alone agent component (data panel) and control panel as follows:
So far, we have witnessed the changes of six times. We must know what service mesh technology is and how it has evolved to today’s form step by step.
Now, let’s look back at the definition of service mesh by William Morgan, CEO of Buyant, that is, the inventor of the word service mesh:
Service grid is an infrastructure layer used to handle communication between services. Cloud native applications have complex service topologies, and the service grid ensures that requests shuttle reliably in these topologies. In practical applications, service grid is usually composed of a series of lightweight network agents, which are deployed with the application, but transparent to the application.
In this definition, there are four Keywords:
Infrastructure layer + requests reliably shuttle through these topologies: these two words together describe the positioning and functions of service mesh. Are they deja vu? Yes, you must have thought of TCP;
Network agent: This describes the implementation form of service mesh;
Transparent to application: This describes the key features of service mesh. Because of this feature, service mesh can solve three essential problems faced by the second generation microservice framework represented by spring cloud;
To sum up, service mesh has the following advantages:
- Shield the complexity of distributed system communication (load balancing, service discovery, authentication and authorization, monitoring and tracking, flow control, etc.), and services only focus on business logic;
- The real language is irrelevant. The service can be written in any language and only needs to communicate with the service mesh;
- Transparent to applications, service mesh components can be upgraded separately;
Of course, service mesh also faces some challenges:
- Service mesh component calculates and forwards requests in proxy mode, which will reduce the performance of communication system and increase the overhead of system resources to a certain extent;
- The service mesh component takes over the network traffic, so the overall stability of the service depends on the service mesh. At the same time, the operation, maintenance and management of a large number of additional service mesh service instances is also a challenge;
History is always strikingly similar. In order to solve the problem of end-to-end bytecode communication, TCP protocol was born, which makes multi machine communication simple and reliable; In the era of micro services, service mesh came into being, shielding many complexities of distributed systems, so that developers can return to business and focus on real value.