सर्विस मेश क्या है और आप इसका उपयोग क्यों करेंगे?

Question

Accepted Answer

एक **service mesh** (Istio, Linkerd) क्रॉस-कटिंग नेटवर्किंग चिंताओं — retries, timeouts, mTLS, traffic routing, observability — को **एप्लिकेशन कोड के बाहर** और **sidecar proxies** के नेटवर्क इन्फ्रास्ट्रक्चर लेयर में ले जाता है।

## यह कैसे काम करता है

प्रत्येक सर्विस इंस्टेंस एक **sidecar proxy** (जैसे, Envoy) के आगे चलता है। सभी traffic proxies के माध्यम से प्रवाहित होता है, जो **data plane** बनाते हैं; एक **control plane** उन्हें कॉन्फ़िगर करता है।

```text
┌─────────────────┐        ┌─────────────────┐
│ Service A       │        │ Service B       │
│  app  ⇄ [proxy] │◀──────▶│ [proxy] ⇄  app  │
└─────────────────┘  mTLS  └─────────────────┘
        ▲ configured by ▲
        └──── Control Plane (Istio/Linkerd) ────┘
```

## यह क्या प्रदान करता है

- **mTLS** सेवाओं के बीच स्वचालित रूप से (शून्य ऐप परिवर्तन)।
- **Resilience** — retries, timeouts, circuit breaking proxy पर।
- **Traffic management** — canary, A/B, weighted routing।
- **Observability** — uniform metrics, traces, logs।

## नीति का उदाहरण

```yaml
# shift 10% of traffic to v2 (canary), no code change
route:
  - destination: { host: orders, subset: v1 }
    weight: 90
  - destination: { host: orders, subset: v2 }
    weight: 10
```

## ट्रेड-ऑफ्स

एक mesh latency (अतिरिक्त hops), संसाधन ओवरहेड (प्रति pod एक proxy), और वास्तविक operational complexity जोड़ता है।

## यह क्यों महत्वपूर्ण है

एक mesh सभी सेवाओं में resilience, security, और observability को मानकीकृत करता है बिना इसके कि प्रत्येक टीम उन्हें विभिन्न भाषाओं में फिर से लागू करे।

लेकिन यह भारी है: इसे केवल तब अपनाएं जब आपके पास इतनी सेवाएं हों कि duplicated networking logic mesh के operational cost को काट दे।