As the pronoun of the next generation of microservice technology, Service Mesh is a fledgling but won the hearts and minds of the people, and there is a trend to dominate the era of microservices.
So what exactly is Service Mesh?
In a word: Service Mesh is the TCP protocol of the microservice era.
With such a perceptual preliminary understanding, let's look at what a Service Mesh is.
When it comes to Service Mesh, you have to mention microservices. According to the definition of Wikipedia:
Microservices is a software architecture style. It is based on Small Building Blocks that focus on a single responsibility and function. It uses a modular approach to combine complex large-scale applications. Each functional area Blocks communicate with each other using a language-independent/language agnostic API set.
At present, there are numerous development platforms and frameworks related to microservices in the industry: Spring Cloud, Service Fabric, Linkerd, Envoy, Istio...
What is the connection between these various products and Sevice Mesh? Which belong to the category of Service Mesh?
In order to clarify these complicated products and concepts, let's first understand the historical development context of microservices and Service Mesh technology.
If you understand the main context of the technology, you can clearly know which node in the technical context the various platforms and frameworks mentioned above belong to, and the relationship between them is clear at a glance.
Phil Calçado's article "Pattern: Service Mesh" describes in detail the evolution of service development models and Service Mesh technology from the perspective of developers. Personally, I think it is a very classic material for learning Service Mesh.
Here I borrow the context of the article, combine my own understanding and simplify it, trying to clarify the concept of ServiceMesh and the historical inevitability of the birth of this technology.
Era 0: The way developers imagine communication between different services
The abstract representation is as follows:
Era 1: The era of primitive communications
However, the reality is far more complicated than imagined. In the actual situation, communication requires a physical layer capable of transmitting bytecode and electronic signals at the bottom to complete. Before the advent of the TCP protocol, the service needs to deal with packet loss and disorder faced by network communication. A series of flow control problems such as, retry, etc. Therefore, in addition to business logic, the service implementation is also mixed with processing logic for network transmission problems.
Era 2: TCP Era
In order to avoid the need for each service to implement a set of similar network transmission processing logic, the TCP protocol appeared, which solved the general flow control problem in network transmission, moved the technology stack down, and separated it from the realization of the service. Become part of the operating system network layer.
Era 3: The first generation of microservices
After the advent of TCP, network communication between machines is no longer a problem, and distributed systems represented by GFS/BigTable/MapReduce have flourished. At this time, the unique communication semantics of distributed systems appear again, such as fusing strategy, load balancing, service discovery, authentication and authorization, quota restriction, trace and monitoring, etc., so the service realizes part of the required communication semantics according to business requirements .
Era 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 microservice architecture have emerged, such as Twitter's Finagle, Facebook's Proxygen, and Spring Cloud. These frameworks implement various general semantic functions required for distributed system communication: such as load balancing and service discovery, etc., so these communication details are shielded to a certain extent, so that developers can develop robust distributions with less framework code式系统。 Type system.
Era 5: The first generation of Service Mesh
The second-generation microservice model seemed perfect, but the developers soon discovered that it also has some essential problems:
- First, although the framework itself shields the implementation details of some common functions of distributed system communication, developers have to spend more energy to master and manage the complex framework itself, and in actual applications, to track and solve the problems of the framework It is not easy;
- Second, development frameworks usually only support one or a few 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 that are not supported by the framework are very It is difficult to integrate into a microservice-oriented architecture system, and it is difficult to implement different modules in the architecture system in multiple languages according to local conditions;
- Third, the framework is combined with services in the form of a lib library. The problem of library version compatibility when complex projects depend on is very difficult. At the same time, the upgrade of the framework library cannot be transparent to the service, and the service will be affected by the upgrade of the lib library that has nothing to do with the business. Forced to upgrade.
Therefore, the proxy mode (sidecar mode) represented by Linkerd, Envoy, and Ngixmesh came into being. This is the first generation of Service Mesh, which abstracts the communication of distributed services into a single layer, and realizes load balancing in this layer. , Service discovery, authentication and authorization, monitoring and tracking, flow control and other functions required by distributed systems, as a proxy service equivalent to the service, deployed with the service, taking over the service traffic, and indirectly completed through the communication between the agents Communication requests between services, so that the three problems mentioned above can be easily solved.
If we look at it from a global perspective, we will get the following deployment diagram:
If we ignore the service for now, just look at the network composed of the stand-alone components of Service Mesh:
I believe that now, everyone already understands what is called Service Mesh, that is, service mesh. It does look like an intricate grid composed of several service agents.
Era 6: The second generation of Service Mesh
The first generation of Service Mesh consists of a series of stand-alone proxy services that run independently. In order to provide a unified upper-level operation and maintenance portal, a centralized control panel has evolved. All stand-alone proxy components update the network topology strategy through interaction with the control panel. And the report of stand-alone data. This is the second generation of Service Mesh represented by Istio.
Just look at the stand-alone proxy component (data panel) and the Service Mesh global deployment view of the control panel as follows:
So far, having witnessed the changes of six eras, everyone must have a clear idea of what the Service Mesh technology is and how it has evolved step by step to its present form.
Now, let’s look back at Buoyant’s CEO William Morgan, the inventor of the term Service Mesh, and his definition of Service Mesh:
The service grid is an infrastructure layer that handles communication between services. Cloud-native applications have complex service topologies, and the service grid ensures that requests travel reliably in these topologies. In practical applications, the service grid is usually composed of a series of lightweight network agents, which are deployed together with the application, but are transparent to the application.
In this definition, there are four key words:
- The infrastructure layer + requests reliably shuttle in these topologies: these two words together describe the positioning and function of the Service Mesh, are they familiar? Yes, you must have thought of TCP;
- Network Agent: This describes the implementation form of Service Mesh;
- Transparency to applications: This describes the key features of Service Mesh. It is precisely because of this feature that Service Mesh can solve the 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 the service only needs to focus on business logic;
- The real language has nothing to do with the service, and the service can be written in any language, just communicate with Service Mesh;
- Transparent to applications, Service Mesh components can be upgraded separately.
Of course, Service Mesh currently faces some challenges:
- Service Mesh components calculate and forward requests in proxy mode, which will reduce the performance of the communication system to a certain extent and increase the system resource overhead;
- 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 surprisingly similar. In order to solve the problem of end-to-end bytecode communication, the TCP protocol was born, making multi-machine communication simple and reliable; in the era of microservices, Service Mesh emerged as the times require, shielding the many complexities of distributed systems, allowing developers to return to business , Focus on true value.