Recently, Service Mesh has become more and more popular and popular, and various community discussions have emerged. In the face of such a hot technology, we have some questions: What exactly is Service Mesh and what does it solve? In this article, we try to briefly explain the architectural design of Service Mesh and introduce its popular solution, Istio.
Starting with distributed systems
Modern applications rarely use monolithic architectures anymore, and when distributed architectures become mainstream, network calls between system components become a natural problem.
Of course, when the number of services is relatively small, the service can record the network location of other services through the configuration file, and only need to read the configuration when making calls, but when the system becomes larger and more automated, the configuration file will become a burden in this way. Therefore, a Service Center is introduced to unify all services, similar to a system-level DNS, to help a service find the services it depends on.
The above diagram is a common service center process, and Eureka in the Spring family bucket follows this pattern. The features of this pattern are quite obvious: 1. the service is self-registering, and 2. the service actively looks up the addresses of other services in the Service Name System. In other words, the service is aware of the existence of a service center, and some of the logic intrudes into the code.
Of course, there is also a non-code-intrusive architectural approach, which is to sink the registration and discovery of services to the infrastructure, and run a proxy process on the host, through which the service initiates access to other components.
As shown above, the service itself may not be aware of the existence of the service center or agent, but the entire system still has the ability to register and discover services.
Service Mesh’s Grid
This is the best picture of what a Service Mesh “looks like”.
The green part is our self-defined service, and the blue part is Sidecar, which works similar to the second service discovery pattern mentioned above, but in a more advanced version, because instead of deploying a Proxy on the host, each service has its own Proxy (Sidecar).
But only Proxy is not enough, we need a Service Name System, and Service Mesh is not enough with Sidecar, we need a control plane.
But the control plane is not just a registry, there are many powerful functions, below, I will introduce the specific Service Mesh solution: Istio.
Istio
Istio Service Mesh is logically divided into a data plane and a control plane.
- The Data Plane consists of a set of intelligent agents deployed as sidecar. These agents regulate and control all network communication between microservices and Mixers.
- The Control Plane is responsible for managing and configuring agents to route traffic. In addition, the control plane configures the Mixer to enforce policies and collect telemetry data.
Officially, Envoy is a C++ high-performance agent with dynamic service discovery, load balancing, multi-protocol support, etc. If deployed via Kubernetes, you only need to put Envoy and business services in the same Pod, and after simple configuration, you can access the grid.
Istio’s control plane is designed with an easily expandable structure, consisting of Pilot, Mixer, and Citadel components, which can be plugged in or expanded according to your needs.
The Pilot plays the role of the Service Name System mentioned above, and is responsible for service discovery, intelligent routing, and traffic control.
Mixer’s main roles are checking and telemetry, such as pre-condition checking (e.g. authentication, whitelisting, etc.), quota checking (e.g. determining whether the access frequency of a service is over the limit, etc.), and monitoring (e.g. link tracing, logging, etc.).
It is also because Mixer plays an uncompromising stewardship role in the entire network that it bears the brunt of performance criticism. However, Mixer is a relatively independent component, so if the system already has its own monitoring and authentication scheme, it can be used without Mixer.
In Istio, all communication between services is done through Sidecar, and Citadel is responsible for the security of communication between the two services, which provides end-user authentication and traffic encryption.
Istio’s components are relatively simple, but it’s also its simple architecture that helps us accomplish and cover up a lot of complex things. Of course, Istio is not the only choice, the old Linkerd, Huawei, Ali according to their own needs to improve and open source SM solutions, are very good choices.
How to look at Service Mesh
How to look at the current hot Service Mesh it? Before that, let’s look at what it solves for us?
- traffic management
- security
- observability
In addition to that, what are the pitfalls for users?
- the architecture becomes more complex and the difficulty of operation and maintenance escalates
- need to understand, there is a certain learning cost
- two hops are added to each request, making it difficult to troubleshoot and a potential performance problem
Therefore, if the introduction of Service Mesh is not to solve the current problems faced, there is no need to introduce it, or the old saying: “Do not add entities if not necessary”, not to mention that this entity is still a black box. However, if the introduction of Service Mesh is to solve the current problem, then you need to think clearly whether you can afford the above mentioned hidden problems, after all, nothing will be a silver bullet.