Service Mesh, as a synonym for the next generation of micro-service technology, has emerged from its infancy but gained popularity and is expected to dominate the micro-service era.
So what exactly is a Service Mesh?
In a word: Service Mesh is the TCP protocol of the microservices era.
With this emotional primer, let’s look at what a Service Mesh is.
When we talk about Service Mesh, we have to mention microservices. According to Wikipedia:
Microservices is a style of software architecture that combines large, complex applications in a modular manner based on Small Building Blocks that focus on a single responsibility and function. Functional blocks communicate with each other using a language-independent /Language agnostic SET of apis.
The list of microservice-related development platforms and frameworks is endless: Spring Cloud, Service Fabric, Linkerd, Envoy, Istio…
How do these various products relate to the Sevice Mesh? What falls under Service Mesh?
To understand these complex products and concepts, let’s take a look at the history of microservices and Service Mesh.
After understanding the main context of technology, we can clearly know which node of each platform and framework belong to the technical context, and the relationship between them will be clear at a glance.
Phil Calcado’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 study of Service Mesh materials.
Using the context of the article, combined with my own understanding and simplification, I try to clarify the concept of ServiceMesh and the historical inevitability of the birth of this technology.
Time 0: How developers imagine services communicating with each other
The abstraction is as follows:
Age 1: The age of primitive communication
Complex, but the reality is far better than to imagine in the actual cases, the communication to the underlying byte code and electronic signal can be transmitted to complete the physical, the TCP protocol, service facing the need to deal with network communication packet loss, out-of-order and try again, and a series of flow control problem, therefore the service implementation, in addition to the business logic, Also mixed with the network transmission problem processing logic.
Period 2: TCP era
In order to avoid the need for each service to implement a similar set of network transmission processing logic, TCP protocol emerged, it solves the common traffic control problem in network transmission, moves the technology stack down from the implementation of services, and becomes part of the operating system network layer.
Era 3: The first generation of microservices
After the emergence of TCP, the network communication between machines is no longer a problem, and the distributed system represented by GFS/BigTable/MapReduce can flourish. At this point, communication semantics specific to distributed systems emerge, such as circuit breakers, load balancing, service discovery, authentication and authorization, quota limits, trace, and monitoring, so that services implement some of the required communication semantics based on business requirements.
Era 4: The second generation of micro services
In order to avoid the need for each service to implement a set of semantic functions of distributed system communication, with the development of technology, some development frameworks oriented to micro-service architecture have emerged, such as Twitter’s Finagle, Facebook’s Proxygen and Spring Cloud, etc. These frameworks implement a variety of common semantic functions needed for distributed system communication, such as load balancing and service discovery, so they shield these communication details to a certain extent, allowing developers to develop robust distributed systems with less framework code.
Generation 5: First generation Service Mesh
The second-generation microservices model looks perfect, but developers soon find that it has some fundamental problems:
- First, although the framework itself hides some common functional implementation details of distributed system communication, developers have to spend more energy to master and manage the complex framework itself, and in practical applications, it is not easy to track and solve the problems of the framework.
- Second, the development framework support are usually only one or several specific language, looking back on it the article the first definition of micro service, is an important feature of language has nothing to do, but those who do not support framework written in a language service, it is difficult to blend in micro service oriented architecture system, to adjust measures to local conditions in various language implementation architecture system of different modules is also hard to do,
- Third, the framework is linked with services in the form of lib libraries, so the compatibility of library versions when complex projects depend on them is very difficult. At the same time, the upgrade of framework libraries cannot be transparent to services, and services will be forced to upgrade because of the upgrade of lib libraries unrelated to business.
Hence the proxy patterns (sidecar patterns) represented by Linkerd, Envoy, and Ngixmesh. This was the first generation of Service Mesh, which abstracted the communication of distributed services into a single layer. Load balancing in this layer, service discovery, authorized certification, monitoring, tracking and traffic control, a distributed system, the required functionality as a service and peer agent service, and service deployment in together, take over the service flow, through the agency of communication between the communication between the indirect service request, so said above three problems are solved.
If we take a global view, we get the following deployment diagram:
If we omit services for the moment and look at the network of standalone components of Service Mesh:
Now you know what a Service Mesh is. It does look like an intricate grid of several service brokers.
Generation 6: Second generation Service Mesh
The first-generation Service Mesh consists of a series of stand-alone agent services that run independently. In order to provide a unified upper-layer operation and maintenance entrance, a centralized control panel is evolved. All stand-alone agent components interact with the control panel to update network topology policies and report stand-alone data. This is the second generation of Service Mesh represented by Istio.
The global deployment view of Service Mesh on the standalone agent component (data panel) and control panel is as follows:
Now that you’ve seen six eras, you’ve got a good idea of what Service Mesh is and how it evolved into what it is today.
Now let’s go back to The definition of Service Mesh by Buoyant CEO William Morgan, who coined the term 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 are reliably shuttled through these topologies. In practice, a service grid is typically composed of a series of lightweight network agents that are deployed with, but transparent to, applications.
In this definition, there are four key words:
- Infrastructure layer + requests reliably navigate these topologies: do these two words together describe the positioning and functionality of the Service Mesh? Yes, you must think of TCP;
- Network proxy: This describes the implementation of the Service Mesh.
- Transparency to Applications: This describes a key feature of Service Mesh that solves three fundamental problems faced by the second generation of microservices frameworks represented by Spring Cloud.
To summarize, Service Mesh has the following advantages:
- Shielding the complexity of distributed system communication (load balancing, service discovery, authentication and authorization, monitoring and tracking, traffic control, etc.), services focus only on business logic;
- The true language is independent. The Service can be written in any language and only needs to communicate with the Service Mesh.
- Transparent to applications, the Service Mesh component can be upgraded separately.
Of course, Service Mesh currently faces some challenges:
- The Service Mesh component calculates and forwards requests in proxy mode, which reduces the performance of the communication system and increases the cost 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. Meanwhile, the operation and management of a large number of additional Service Mesh instances is also a challenge.
History has always been strikingly similar. In order to solve the problem of end-to-end bytecode communication, TCP protocol was born, making multi-machine communication simple and reliable. In the era of microservices, Service Mesh emerged to mask the complexity of distributed systems and allow developers to get back to business and focus on real value.