સર્વિસ મેશ શું છે અને તમે તેનો ઉપયોગ શા માટે કરશો?

Question

Accepted Answer

એક **service mesh** (Istio, Linkerd) ક્રોસ-કટીંગ નેટવર્કીંગ સંબંધો — retries, timeouts, mTLS, traffic routing, observability — **એપ્લીકેશન કોડની બહાર** અને **sidecar proxies** ના નેટવર્ક ઇન્ફ્રાસ્ટ્રક્ચર લેયરમાં લઈ જાય છે.

## તે કેવી રીતે કાર્ય કરે છે

પ્રતિটি service instance એક **sidecar proxy** (દા.ત., Envoy) નીચે ચલાય છે. બધી traffic proxies દ્વારા વહે છે, જે **data plane** બનાવે છે; **control plane** તેમને configure કરે છે.

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

## તે શું પૂરું પાડે છે

- **mTLS** સેવાઓ વચ્ચે આપોઆપ (શૂન્ય app ફેરફાર).
- **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
```

## Trade-offs

મેશ latency (વધારાના hops), resource overhead (પ્રતિ pod એક proxy), અને વાસ્તવિક operational complexity ઉમેરે છે.

## તે શા માટે મહત્વપૂર્ણ છે

મેશ resilience, security, અને observability ને બધી સેવાઓમાં પ્રમાણીકૃત કરે છે કે જેમાં દરેક team તેમને વિવિધ ભાષાઓમાં પુનઃલાગુ કરતું નથી.

પરંતુ તે ભારે છે: તેને માત્ર ત્યારે અપનાવો જ્યારે તમારી પાસે એટલી બધી સેવાઓ હોય કે duplicated networking logic mesh ના operational cost ને ટાળી દે.