Service Mesh

A service mesh is a dedicated infrastructure layer built into applications to handle service-to-service communication, providing reliable, observable, and secur...

A service mesh is a dedicated infrastructure layer for handling service-to-service communication within a microservices architecture. It provides a transparent way to manage and observe the network of services, abstracting away the complexities of inter-service communication from the application code. Typically implemented as a set of lightweight network proxies (sidecars) deployed alongside each service instance, the service mesh intercepts all inbound and outbound network traffic. A control plane manages and configures these proxies, enabling features such as sophisticated traffic routing (e.g., canary deployments, A/B testing), load balancing, service discovery, and security policies (e.g., mutual TLS authentication, authorization). Observability is a key benefit, with the mesh automatically collecting detailed metrics, logs, and traces for all service interactions, providing deep insights into application performance and behavior. Trade-offs include increased operational complexity, potential latency introduced by the proxy layer, and resource overhead from running sidecar proxies. However, it significantly simplifies the development of resilient, secure, and observable distributed systems by externalizing cross-cutting concerns from individual microservices.

        graph LR
  Center["Service Mesh"]:::main
  Rel_advanced_propulsion_systems["advanced-propulsion-systems"]:::related -.-> Center
  click Rel_advanced_propulsion_systems "/terms/advanced-propulsion-systems"
  Rel_microservices["microservices"]:::related -.-> Center
  click Rel_microservices "/terms/microservices"
  Rel_observability["observability"]:::related -.-> Center
  click Rel_observability "/terms/observability"
  classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
  classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
  classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
  classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
  linkStyle default stroke:#4b5563,stroke-width:2px;

      

🧒 5歳でもわかるように説明

It's like a super-smart traffic controller for all the little helper robots in a factory. It makes sure they can talk to each other safely and efficiently, without the robots needing to know how to direct traffic themselves.

🤓 Expert Deep Dive

A service mesh abstracts the complexities of inter-service communication within a microservices architecture by deploying a network of lightweight proxies, known as sidecars, alongside each service instance. These sidecars intercept all inbound and outbound network traffic for their associated service. The control plane then configures and manages these sidecars, enforcing policies and providing telemetry.

Key components include:

Data Plane: Composed of the sidecar proxies (e.g., Envoy, Nginx). These proxies handle traffic routing, load balancing, TLS termination, authentication, authorization, and metrics collection. They typically operate at Layer 7 (HTTP/gRPC) but can also handle TCP traffic.
Control Plane: Manages and configures the data plane proxies. It exposes APIs for configuration, service discovery, policy enforcement, and telemetry aggregation. Examples include Istio (using Pilot, Citadel, Galley), Linkerd, and Consul Connect.

Architecturally, the sidecar pattern is crucial. A service A intending to communicate with service B doesn't directly connect to B. Instead, A sends its request to its local sidecar proxy. This proxy, configured by the control plane, then handles the network hop to B's sidecar proxy, which forwards it to service B. This allows for features like mutual TLS (mTLS) for secure communication, sophisticated routing rules (e.g., canary deployments, A/B testing), circuit breaking, rate limiting, and distributed tracing without developers needing to implement these concerns in their application logic. Protocols like xDS (Discovery Service) are fundamental for dynamic configuration updates between the control plane and data plane proxies.

📚 出典