The evolution of web application communication-from TCP to Service Mesh

1. Web application communication evolution

To understand what Service Mesh is, it is necessary to sort out the history of communication evolution in network applications. Readers who are interested can directly read Pattern: Service Mesh . This section is based on this article.

1.1 The arrival of the TCP era

Before the advent of the TCP protocol, applications needed to deal with flow control problems such as packet loss, disorder, and retry faced by network communications.In addition to business logic, the application is also mixed with processing logic for network transmission problems,As shown below

After the TCP protocol appearedSolve the general flow control problem in network transmission, This part of the logic can be extracted from the application and moved down to become part of the operating system network layer

1.2 Evolution in the era of microservices

After the advent of TCP, network communication between machines is no longer a problem, and the distributed system has developed rapidly.Microservice architecture becomes mainstream. Under the microservice architecture, a single application may consist of multiple services, and each service may contain multiple instances. In this way, new communication problems that need to be solved in distributed systems appear, such as load balancing, service discovery, etc.Services need to implement part of the required functions according to business needs, So there is the following structure:

With the development of technology, in order to prevent each service from repeatedly implementing the function of distributed system communication, some development frameworks for microservice architecture have appeared, such as Spring Cloud. These frameworks implement various general functions required for distributed system communication,And integrated in the service in the form of a software package or library, Shielding the communication details of the distributed system to a certain extent, reducing the burden on developers

1.3 Service Mesh era

The above microservice governance structure has been perfected, but people soon discovered that it also has some problems:

1. The maintenance and management of the framework itself.
   Because the framework shields the implementation details of some common functions of distributed system communication, this means that once there is a problem with the framework itself, developers have to spend more energy to track and solve the problem, which is almost the same as business logic. Is completely unrelated
2. Language independence issues
   Development frameworks usually only support a few specific languages. Services written in languages ​​that are not supported by the framework are difficult to integrate into the microservice architecture, and it is also difficult to implement different modules in the system using multiple languages.
3. Version compatibility issues The
   framework is integrated into the service in the form of a lib library. The issue of library version compatibility when complex projects depend on is very difficult. At the same time, the service will be forced to upgrade due to the upgrade of the lib library that has nothing to do with the business.

In order to solve the above problems, aBased on the agency model, the communication of distributed services is abstracted into a single layer of governance structure, which is Service Mesh. The proxy structure abstracted by Service Mesh is called Sidecar, which implements the functions required by distributed systems such as load balancing, service discovery, monitoring and tracking in Sidecar, andDeploy it as an independent agent service and service together, take over the traffic of the service, and indirectly complete the communication between services through the communication between agents. In this way, it is possible to provide a unified upper-layer operation and maintenance portal through a centralized control plane. All stand-alone agent components interact with the control plane to update the network topology strategy and report stand-alone data.

Just look at the Service Mesh global deployment view of the stand-alone proxy components and the control panel as follows. It looks like a complex grid composed of service proxies

2. Service Mesh

After the above tracing of the realization of communication between services, I believe that readers Service Meshhave a relatively intuitive impression. Simply put, it Service Mesh(服务网格)is a service governance solution under the microservice architecture.It belongs to the infrastructure layer that handles the communication between services. In essence, it separates the communication between services from the bottom layer that cannot be monitored, and achieves the goal of controlling and managing the communication itself.

2.1 Features of Service Mesh

From the perspective of function positioning and implementation form, Service Mesh mainly has the following characteristics:

1. Lightweight network proxy
   This is the implementation form of Service Mesh as the middleware layer of inter-service communication. It Sidecarexists as a proxy between the original client and server. All traffic entering and leaving the service must pass through the service first.Sidecar
2. Transparency to business services
   is a key feature of Service Mesh. Transparency of services realizes the decoupling of business services and communication requirements. On the one hand, business services do not need to care about the details of communication with other services, and on the other hand, it also enables middleware for inter-service communication. The upgrade iteration will not affect business services
3. Monitoring and management of communication between services
   This is the main functional feature of Service Mesh. Sidecar makes link tracking and other functions more elegant, and it also provides more flexibility for the expansion of functions.

2.2 Implementation of Service Mesh

Currently the most well-known of two Service Mesh project is Istioand Conduitwhere Istio 1.4版本previous architecture shown below, click to see the latest organization chart , readers who are interested can go to their own Service Mesh community View related documents

The above architecture mainly includes the following components,Istio 1.5版本后The integration of components in the control plane was rebuilt istiodand the Mixer component was abolished

1. Envoy
   Envoy is the proxy of the service, which is the implementation instance of Sidecar in Service Mesh, which is Istio数据平面
2. Pilot
   Pilot is 控制平面the core of Istio . It mainly provides service discovery for Envoy sidecar, traffic management functions for intelligent routing (such as A/B testing, etc.), and elastic functions (timeout, retry, fuse, etc.). Pilot converts advanced routing rules that control traffic behavior into environment-specific configurations, and propagates them to the sidecar at runtime
3. Mixer
   Mixer is a decision-making module. Envoy calls Mixer when processing a request to help decide whether or not to finally request a service instance. It allows users to customize service permission control, service Quota current limit, call statistics reporting, and collection and analysis capabilities

Based on the above architecture, the routing process of a request in Service Mesh is as follows:

1. Service A initiates a REST service call to Service B
2. The traffic takeover capability of node A takes over the request to the Envoy process of this node
3. Through a series of load balancing calculations and permission checks through the configuration information sent by Pilot, the Envoy process determines the instance node of target service B, and delivers the request information to the node
4. After node B receives the message, the traffic takeover capability will take over the message into Envoy
5. Envoy requests Mixer to check whether the Quota current limit policy has reached the upper limit. After the check is passed, it is routed to the service B instance in the node according to the internal routing rules issued by the Pilot
6. After the service instance receives the request, it processes the business logic

2.3 Summary

To sum up, Service Mesh can be compared to the TCP protocol under the microservice architecture . It is the infrastructure responsible for communication control between services. It has the following advantages:

1. Reduce system complexity.
   Service Mesh shields the complexity of distributed system communication (load balancing, service discovery, monitoring and tracking, etc.), so that services only need to focus on business logic
2. Language-independent
   services can be written in any language, as long as they can communicate with Service Mesh
3. Business decoupling
   Service Mesh components can be upgraded separately, without affecting business services at the code level

However, Service Mesh currently has certain problems:

1. Performance issues
   Service Mesh components calculate and forward requests in proxy mode, which will reduce communication system performance to a certain extent and increase system resource overhead
2. Stability issues
   Service Mesh components take over network traffic, so the overall stability of the service depends on Service Mesh. At the same time, a large number of additional Service Mesh service instances are a challenge to operation and maintenance management.