Mesher Overview

What Is Mesher?

Mesher provides the Service Mesh, which is a lightweight proxy service that runs together with microservices in Sidecar mode.

Service Mesh is defined by William Morgan.

A Service Mesh is a dedicated infrastructure layer for handling service-to-service communication. It's responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the Service Mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

The concept of the Service Mesh as a separate layer is tied to the rise of the cloud native application. In the cloud native model, a single application might consist of hundreds of services; each service might have thousands of instances; and each of those instances might be in a constantly-changing state. Not only is service communication in this world incredibly complex, it's a pervasive and fundamental part of runtime behavior. Managing it is vital to ensuring end-to-end performance and reliability.

The Service Mesh is a networking model that sits at a layer of abstraction above TCP/IP. It assumes that the underlying L3/L4 network is present and capable of delivering bytes from point to point. (It also assumes that this network, as with every other aspect of the environment, is unreliable; the Service Mesh must therefore also be capable of handling network failures.)

In some ways, the Service Mesh is analogous to TCP/IP. Just as the TCP stack abstracts the mechanics of reliably delivering bytes between network endpoints, the Service Mesh abstracts the mechanics of reliably delivering requests between services. Like TCP, the Service Mesh does not care about the actual payload or how it is encoded. The application has a high-level goal ("send something from A to B"), and the job of the Service Mesh, like that of TCP, is to accomplish this goal while handling any failures along the way.

Unlike TCP, the Service Mesh has a significant goal beyond "just make it work": it provides a uniform, application-wide point for introducing visibility and control into the application runtime. The explicit goal of the Service Mesh is to move service communication out of the realm of the invisible, implied infrastructure, so that it can be monitored, managed and controlled in the ecosystem.

Why Mesher?

• Service codes do not need to be reconstructed.
• Existing applications can be accessed.
• Common applications quickly become cloud-native.
• Service codes do no need to be modified.

Basic Implementation Principle

Mesher is the proxy of Layer 7 protocols. It runs in Sidecar mode in a pod where applications reside, and shares network and storage resources with the pod.

1. Applications in the Pod use Mesher as the HTTP proxy to automatically discover other services.
2. Instead of applications in the Pod, Mesher registers with the registry center to be discovered by other services.

The network request process of a consumer and provider using Service Mesh is as follows:

• Scenario 1. Only the consumer uses Mesher in Sidecar mode.

  Provider needs to implement service registry and discovery or use the Java development framework. Otherwise, the consumer connected through Mesher cannot discover the provider.

  The network request process between applications is as follows:

  consumer-> Mesher -> provider

• Scenario 2: Both the consumer and provider use Mesher in Sidecar mode.

  In this scenario, the microservice development framework is not required.

  The network request process between applications is as follows:

  consumer -> Mesher -> Mesher ->provider

• Scenario 3. Only the provider uses Mesher in Sidecar mode.

  Consumer needs the Java development framework.

  The network request process between applications is as follows:

  consumer -> Mesher -> provider

Precautions

Configurations need to be modified after applications are deployed on the cloud. For example, before Mesher is deployed, the consumer uses http://IP:port/ to access the provider; after Mesher is deployed, the consumer uses http://provider:port/ to access the provider. For details, see Connecting Mesher Applications to CSE.