This article is the first in the Service Mesh series
With the advent of the cloud native era, people who use microservice architectures are starting to hear a new technical term — Service Mesh (which is not new now).
For learning a new technology, there are always two problems:
- What is it?
- Why is it needed?
This article will focus on these two issues and hopefully provide an overview of Service Mesh.
Finally, a core thought is triggered:
- Who really needs a Service Mesh?
1. What is Service Mesh
Service Mesh is translated as “Service Mesh” in China.
William Morgan, CEO of Buoyant, has a definition that’s generally accepted:
Service Mesh is a dedicated infrastructure layer for handling service-to-service communication. Cloud Native has a complex service topology that is responsible for reliably delivering requests. In fact, a Service Mesh is typically implemented as a set of lightweight network agents that are deployed with application code without application awareness.
This definition seems a bit complicated, but if we extract the key words, it may become clearer:
-
Infrastructure layer for service-to-service communication (positioning)
-
Reliably deliver requests (targets) in complex service topologies
-
Lightweight Network Proxy Implementation (Implementation)
-
Application not aware (features)
What do we associate with positioning, goals, and characteristics?
Yes, TCP/IP!
For micro-services in cloud native environment, Service Mesh is an infrastructure equivalent to TCP/IP protocol, which is responsible for network invocation, route management, traffic limiting, and monitoring among services.
With Service Mesh, we don’t need to worry about framework adaptation and upgrading of inter-service calls, such as Spring Cloud and Dubbo, when writing applications. Just like we used to when we were writing applications, the TCP/IP layer is no longer a concern.
In addition, from an implementation perspective, this lightweight network Proxy implementation is often called a Sidecar (actually a Proxy).
Let’s look at the architecture of the Service Mesh.
(image from philcalcado.com/2017/08/03/…
The Service Grid is divided into two core parts:
-
Data plane. The Sidecar serves as the data plane node, which is transparent to applications. All incoming and outgoing traffic passes through the Sidecar.
-
Control plane. The centralized control plane provides unified upper-layer o&M access. All Sidecar agents interact with the control plane to update network topology policies and report single-node data.
2. Why is a Service Mesh needed
The emergence and introduction of a new technology is bound to solve existing problems. The Service Mesh is also introduced to solve the problems of existing microservice frameworks.
In order to have a deeper understanding of the problems solved by Service Mesh, we combined Phil Calcado’s article Pattern: Service Mesh to sort out the evolution process of Service development mode and Service Mesh technology.
1) Primitive Communication age 1.0
In the primitive communication era (before the emergence of TCP), services had to deal with a series of Flow Control problems such as packet loss, out-of-order, and retry. So in addition to the business logic code, you need to consider dealing with network transport issues.
2) Primitive Communication Age 2.0
In order to solve this business-independent transport problem over the network, TCP/IP emerged and “sank” this part of the Flow Control problem down to the operating system level. Business development no longer needs to focus on network transport and can focus on business logic development.
3) Service governance 1.0 of microservices
With the popularization of microservice architecture, single service gradually develops into distributed system, and inter-service invocation becomes more and more complex.
At this point, “Flow Control” problems under the microservice architecture continue to appear, including service registration and discovery, traffic limiting, circuit breaker, and so on. Therefore, in the business logic code, we need to develop some modules to solve this kind of business irrelevant problems.
4) Service Governance 2.0 for Microservices — microservices framework
In order to solve the common communication problem under the microservice architecture, various microservice frameworks have emerged. Spring Cloud, Dubbo and other frameworks are created to solve this kind of common communication problem.
These frameworks mask processing logic from business development, including service registration and discovery, limiting traffic, and fusing, in the form of client dependency packages, enabling a robust microservice architecture with simple configuration.
5) Service Governance 3.0 for Microservices — Service Mesh
Although the microservice framework can solve the problem of universal service governance, it also has some disadvantages in practice:
- The client – dependent package form is destined to be strongly bound to the development language. The more mainstream microservice frameworks are basically Implemented in Java, and if there are services in other languages in the business architecture, it is difficult to enjoy the same convenience. Developing a microservices framework for different languages is expensive and difficult to maintain. Being limited to a development language by a microservice framework is obviously not a good thing.
- Client dependency packages are destined to require services to upgrade and adapt dependency packages. Some complex projects rely on a large number of packages, and often need to deal with the problem of packet conflict, which makes a lot of heads. At the same time, the upgrade of the framework library cannot be transparent to the service, so business must be promoted to complete it. Business development students and framework maintenance students are tired, Sigh ~~
This problem can be solved if, like TCP/IP, service governance “sinks” and is completely decoupled from application services.
Therefore, the Sidecar mode Service Mesh products represented by Linkerd, Envoy and NginxMesh came into being. They separate the Sidecar service from the common problems of microservice communication, such as service registration discovery, traffic limiting, fusing, monitoring and other functions. They completely take over the network communication between services and run independently, completely decoupled from business applications. This solves the pain point of traditional client-side microservices frameworks.
Later, Service Mesh products represented by Istiol introduced a unified control plane based on the Sidecar model (Sidecar in ISTIO adopts Envoy), facilitating management and maintenance updates.
At this point, WE believe that we have a deep understanding of “why Service Mesh is needed”. It is based on the above evolution history that we have the current Service governance solution Service Mesh for microservices.
3. Who needs Service Mesh
Since the Service Mesh is so good, can we not think about it? As a matter of fact, no.
Why is that?
Service Mesh In terms of Service governance, there are not many new “functional” features, but some interesting basic features include:
- Natural cloud-native components
- Can upgrade and evolve independently
- Language independence
However, in a relatively mature production environment, no matter Dubbo, Spring Cloud or self-developed microservice frameworks, they are all relatively mature, with relatively complete governance capabilities, and seldom need to be upgraded or expanded.
Especially if the core functions of service registration and discovery remain the same, some extension upgrades do not require all back-end services to upgrade and adapt.
A feature based on “ability to upgrade and evolve independently” is not so compelling, at least not as driven by “business value.”
So who is the right person to introduce a Service Mesh?
1) New enterprises (new production lines) based on cloud native
Starting from scratch and based on the cloud native stack, a new enterprise is ideally suited to introduce Service Mesh directly.
With cloud native Service registry discovery, Service governance, and cloud native observability all centered around Service Mesh, business development can better focus on business iterations rather than iterations of business-independent infrastructure.
Of course, some infrastructure maintainer with a deep understanding of the cloud native stack is essential.
2) Mature enterprises with diversified technology stacks
For a relatively mature enterprise, the micro-service framework, configuration center, full-link tracking system, etc., have all been mature, and their governance capabilities are perfect, so they rarely need to be upgraded or expanded.
Therefore, the introduction of Service Mesh is largely based on the need for “stack diversification”.
The so-called “technology stack diversification” includes:
- Service scenarios have different features. For example, Java is used for web projects, go/c++ is used for back-end high-performance computing services, Faas is used for businesses with drastic fluctuations in business requests, and nodejs is used for front-end microservices.
- Some special hiring needs.
The complex architecture brought by the diversification of technology stack has brought great challenges to the traditional microservice framework, and the client-side mode (strong language binding) microservice framework has been unable to meet such complex requirements.
Therefore, in the cloud native architecture, the “language independence” feature of Service Mesh makes heterogeneous applications more feasible, allowing users to quickly orchestrate applications with complex environments and dependencies.
4. Summary
This article provides an overview of ServiceMesh based on “What is A ServiceMesh” and “Why do we need a ServiceMesh”.
Finally, according to the actual situation of production landing, the scenario that is really suitable for Service Mesh landing is considered.
I hope to inspire you.
See the end, the original is not easy, point a concern, point a like it ~
Reorganize the knowledge fragments and construct the Java knowledge graph: github.com/saigu/JavaK… (Easy access to historical articles)