Overview

This article was compiled by me in May 2019, but I never finished it and put it in the draft box, so I suddenly came up with it today, so I edited it by hand. In fact, the reason I didn’t finish it was because I translated a lot of content before, and I felt that I had failed to live up to some of my own understanding by directly playing the name of translation, so I piled it up, and then gradually added my own experience and understanding to it, so I organized it today.

What is Service Mesh

Service Mesh is a tool that adds observability, security and reliability features to an application by inserting them at the platform layer instead of the application layer.

Service Mesh is typically implemented as a set of scalable web proxies that are deployed with application code (a model sometimes referred to as sidecar). These agents handle the communication between microservices and also act as a point where the functionality of the service mesh can be introduced. Proxies comprise the data plane of the service mesh and are controlled as a whole by its control plane. For example, Istio, one of the most popular Service Mesh frameworks, is typical of this architecture. By default, Istio places a Sidecar between the client and the server: Envoy. The client and server feel like they are directly connected to each other.

Service Grid Features

  • Lightweight web proxy
  • Application-unaware
  • Inter-application traffic is taken over by the Service Grid
  • Sink possible timeouts/retries/monitoring/tracing of inter-service calls to the service grid layer to handle them

Service Mesh Architecture

Service Mesh (Isito and Linkerd, including the ones developed by our company itself) today (2021) are composed of a data plane and a control plane.

  • Data plane: the real request path for application data
    • mainly responsible for traffic forwarding, policy implementation and telemetry data reporting.
    • Core components: Envoy, Linkerd-proxy
  • Control plane: controls how the data plane handles data
    • Mainly the user’s configuration into specific routing rules and handed to the data plane (Envoy, Linkerd-Proxy), and then collect telemetry data for guiding the control policy
    • Core components.
      • Previously, Istio had several.
        • Mixer: Telemetry management
        • Pilot: Traffic management
        • Citadel: authentication management
      • Istio now combines all of these into one, which is a trend to simplify the deployment model as much as possible and not to run multiple processes if you can run one.
Figure 1: Schematic of older versions of Istio
Figure 2: Schematic of the new version of Istio

Features supported by Istio

  • Istio supports load balancing for different protocol traffic: HTTP, gRPC, WebSocket and TCP.
  • providing rich fine-grained control of traffic behavior such as routing rules, retries, failover and failover injection through the concepts of Vritual Service and Destionation Rule.
  • Providing pluggable policy layers and configuration APIs that support access control, rate limiting and quotas.
  • Control, tracking and monitoring through ingress and egress of Ingress and Outgress cluster traffic.
  • Secure communication between services through identity-based authentication and authorization.

Reference