Help Center > > Developer Guide> Microservice Development Guide> Connecting Microservice Applications to CSE> Connecting Mesher Applications to CSE> Mesher Overview

Mesher Overview

Updated at: Sep 17, 2021 GMT+08:00

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.

    In this scenario, the provider needs to be available for service registry and discovery, or uses the Java or Go chassis development framework. Otherwise, the AccountService cannot be discovered.

    The network request process between applications is as follows:

    Store web -> Mesher -> Account service

  • 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:

    Store web -> Mesher -> Mesher -> Account service

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

    Consumers need to use the Java or Go chassis development framework.

    The network request process between applications is as follows:

    Store web -> Mesher -> Account service


Configurations need to be modified accordingly after applications are deployed on the cloud. For example, when Mesher is not used, StoreWeb uses http://IP:port/ to access AccountService. After Mesher is used, StoreWeb uses http://AccountService:port/ to access AccountService, which is explained in detail in the following.

Did you find this page helpful?

Submit successfully!

Thank you for your feedback. Your feedback helps make our documentation better.

Failed to submit the feedback. Please try again later.

Which of the following issues have you encountered?

Please complete at least one feedback item.

Content most length 200 character

Content is empty.

OK Cancel