A service mesh is a dedicated layer that handles communication between services in a microservices system. Lightweight proxies, commonly deployed as sidecars beside each service instance, intercept traffic, while a control plane distributes configuration to them.
Why it matters
As the number of services grows, every one needs the same plumbing: encrypted connections, timeouts, retries, traffic splitting and metrics. A mesh provides these consistently instead of each team re-implementing them in different languages. Typical features include mutual TLS between services, canary traffic shifts and detailed latency data per call. Istio and Linkerd are widely known examples.
The cost is complexity and resource use: extra proxies add CPU, memory and a new thing that can fail or be misconfigured.
Example
A traffic rule that sends 5 percent of requests to a new version:
service: checkout
v1: 95%
v2: 5%If error rates for v2 rise, the rule is changed back with no redeploy of the application itself.
Common mistakes
- Adopting a mesh for a handful of services, where a library or ingress would do.
- Setting aggressive retries that multiply load during an outage.
- Not monitoring the proxies themselves.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.