TL;DR

For cloud native app, it usually consists of multi services, with each service has multi instances. We shouldn’t expect to expose each service instance as a independent Web service to publish, hence we got Gateway as a single service exposing to public world and help us redirect all inbound traffic.

Further more, while services are divided into pieces, the relationship between services become topology. Internal service-to-service traffic is another primary scenario of Service mesh.

Service mesh can be consider as traffic dealer for multiple services. It usually provide functionalities:

• Service discovery
  • Support to monitor healthy services and maintain an available list
• Traffic management
  • Support to have earlier-stage interception on requests, to validate requests, apply custom rules to request etc.
  • Support to redirect requests to available services which is considered to have best-performance.
  • Support to applying more network techs to shorten request duration
    • Reuse TCP connection for multi requests

Reference: Linkerd: Where did the service mesh come from?

How it works?

For all the hype, the service mesh is architecturally pretty straightforward. It’s nothing more than a bunch of userspace proxies, stuck “next” to your services (we’ll talk about what “next” means in a bit), plus a set of management processes. The proxies are referred to as the service mesh’s data plane, and the management processes as its control plane. The data plane intercepts calls between services and “does stuff” with these calls; the control plane coordinates the behavior of the proxies, and provides an API for you, the operator, to manipulate and measure the mesh as a whole.

Reference: https://buoyant.io/service-mesh-manifesto