Shulou(Shulou.com)06/02 Report--

Service mesh is a new concept that has emerged in recent years. It can solve the problem of more and more complex communication between micro-services. So what is Service mesh? What specific functions does it have? What is its architecture? What is its relationship with Kubernetes? All the answers are understood!

Under the banner of digital transformation, a major change in the IT world is that large single applications are decomposed into micro-service architectures, that is, small, discrete functional units, and these applications run in containers. Packages that contain all service code and dependencies are isolated and can be easily migrated from one server to another.

Containerized architectures like this are easy to expand and run in the cloud, and can quickly iterate and roll out each microservice. However, as applications get larger and run multiple instances on the same service at the same time, communication between microservices becomes more complex. The emergence of Service mesh, an emerging form of architecture that aims to connect these micro-services in the form of reduced administrative and programming overhead, will solve this problem.

What is Service mesh?

The most widely accepted view about the definition of Service mesh is that it is a way to control different parts of an application to share data with each other. This description covers all aspects of service mesh. In fact, it sounds more like middleware that most developers are familiar with from client-server applications.

Service mesh also has its own unique features: it can adapt to the unique nature of the distributed micro-service environment. In large-scale applications built in micro-services, there are many established service instances that run across local and cloud servers. All these mobile components obviously make it difficult for microservices to find other services with which they need to communicate. Service mesh can automatically process discovery and connection services in a short period of time without the need for developers and individual micro-services to match themselves.

We can equate service mesh to layer 7 of the OSI network model for software-defined networks (SDN). Just as the network administrator does not have to deal with physical network connections after SDN creates an abstraction layer, service mesh decouples the underlying infrastructure of the applications that interact with you in the abstract architecture.

As developers began to work on the problem of a really large distributed architecture, the concept of service mesh emerged at the right time. The first project in this area was Linkerd, which started as a branch of Twitter internal projects. Istio is another very popular service mesh project, which originated from Lyft and is now supported by many enterprises.

Service mesh load balancing

One of the key functions of Service mesh is load balancing. We often think of load balancing as a network function-you want to prevent servers or network links from being flooded with traffic, so you route your packets accordingly, and Service mesh is doing something similar at the application level.

In essence, one of Service mesh's jobs is to track which instances of the various micro-services distributed across the infrastructure are "the healthiest." It may survey them to see how they work or track which instances are slow to respond to service requests and send subsequent requests to other instances. In addition, service mesh will do similar work for network routing, and if it is found that when a message takes a long time to arrive, then service mesh will use other routes to compensate. These slowdowns may be due to problems with the underlying hardware, or simply due to request overload or insufficient processing capacity of the service. But it doesn't matter, service mesh will find another instance of the same service and route it to replace the slow-responding instance, making efficient use of the resources of the entire application.

Service mesh vs Kubernetes

If you are a little familiar with container-based architecture, you may wonder whether Kubernetes, a popular open source container choreography platform, is suitable for this situation. After all, doesn't Kubernetes manage how your containers communicate with each other? You can think of Kubernetes "service" resources as a very basic service mesh because it provides polling scheduling balance for service discovery and requests. But the full service mesh provides richer features, such as managing security policies and encryption, "disconnecting" to suspend requests to slow-responding instances, and load balancing as described above.

Keep in mind that most service mesh do need an orchestration system like Kubernetes. Service mesh only provides extended functionality, not an alternative choreography platform.

Service mesh vs API Gateway

Each microservice provides an API that acts as a means for other services to communicate with it. This raises the problem of differences between service mesh and other more traditional forms of API management, such as API gateways. The API gateway, which sits between a set of microservices and the "external" world, routes service requests as needed so that the requestor does not need to know that it is processing microservice-based applications to complete the request. On the other hand, service mesh mediates requests within the microservice application, and the various components fully understand its environment.

On the other hand, service mesh is used to optimize east-west traffic within the cluster (server-server traffic), and API gateway is used for north-south traffic to and from the cluster (server-client traffic). But service mesh is still in its early stage and is still in the process of development and change. Many service mesh (including Linkerd and Istio) can now provide north-south functionality.

Service mesh architecture

The concept of Service mesh has not been around for a long time, and there are already a number of different ways to solve the problem of "service mesh", such as managing microservice communications. Currently, three possible locations of communication layers created by service mesh have been identified:

Library imported by each microservice

A node agent that provides services to all containers at a specific node

A sidecar container that runs with the application container

The sidecar-based model is currently one of the most popular patterns of service mesh, so much so that it has become synonymous with service mesh to some extent. Although this statement is not rigorous, sidecar has attracted a lot of attention, and we will look at this architecture in more detail below.

Sidecar

What does it mean to run the Sidecar container with your application container? In this type of service mesh, each micro-service container has another proxy container corresponding to it. All requirements for inter-service communication are abstracted out of the microservice and put into the sidecar.

This seems complicated, after all, you effectively doubled the number of containers in your application. But the design pattern you use is critical to simplifying distributed applications. By putting all the network and communication code in a separate container as part of the infrastructure and eliminating the need for developers to implement it as part of the application.

In essence, what you leave behind is a microservice that focuses on business logic. This microservice does not need to know how to communicate with all other services in the environment in which it runs. It only needs to know how to communicate with sidecar, and the rest will be done by sidecar.

Service mesh star projects: Linkerd, Envio, Istio, Consul

So after all that has been said, what is the available service mesh? At present, there are no completely ready-made commercial products in this field. Most service mesh projects are open source projects, which need to be implemented through certain operational steps. Now the more well-known projects are:

Released in Linkerd:2016, it is the oldest of these projects. Linkerd is separated from the library developed by Twitter. Another heavyweight player in this field, Conduit, has entered the Linkerd project and formed the foundation of Linkerd 2.0.

Envoy: created by Lyft, Envoy occupies the part of the "data plane" and matches it in order to provide complete service mesh functionality.

Istio: jointly developed by Lyft, IBM and google, Istio can easily add features such as load balancing and authentication to microservices without modifying the source code. It can control all traffic by controlling proxy services such as Envoy. In addition, Istio provides fault tolerance, canary deployment, Amax B testing, monitoring and other functions, as well as support custom components and integration.

Istio is supported on Rancher version 2.3 Preview2. Users can launch Istio directly in the UI interface and can inject automatic sidecar for each namespace. Rancher has a built-in dashboard that supports Kiali to simplify the installation and configuration of Istio. All this makes it easy and fast to deploy and manage Istio. HashiCorp Consul: a feature called Connect has been introduced with Consul 1.2, which adds service encryption and identity-based authorization to HashiCorp's distributed systems for service discovery and configuration.

Which service mesh suits you? If you want to make a comprehensive comparison, it is beyond the scope of this article. But all of the above products have been tested in large and demanding environments. At present, Linkerd and Istio contain the richest feature set, but everything is still developing rapidly, and it is too early to tell.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.