سروس میش (service mesh) کیا ہے اور آپ اسے کیوں استعمال کریں گے؟

Question

Accepted Answer

ایک **سروس میش** (Istio، Linkerd) کراس کاٹنے والے نیٹ ورکنگ مسائل — دوبارہ کوشش، ٹائم آؤٹ، mTLS، ٹریفک روٹنگ، نگرانی — کو **ایپلیکیشن کوڈ سے نکال کر** **سائڈ کار پروکسیز** کی نیٹ ورک انفراسٹرکچر لیئر میں منتقل کرتا ہے۔

## یہ کیسے کام کرتا ہے

ہر سروس مثال ایک **سائڈ کار پروکسی** (مثال کے طور پر، Envoy) کے ساتھ چلتی ہے۔ تمام ٹریفک پروکسیز سے گزرتی ہے، جو **ڈیٹا پلین** بناتے ہیں؛ ایک **کنٹرول پلین** انہیں ترتیب دیتا ہے۔

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

## یہ کیا فراہم کرتا ہے

- سروسز کے درمیان **mTLS** خودکار طور پر (کوئی ایپ تبدیلی نہیں)۔
- **لچک** — دوبارہ کوشش، ٹائم آؤٹ، پروکسی پر سرکٹ برکنگ۔
- **ٹریفک مینجمنٹ** — canary، A/B، وزن والی روٹنگ۔
- **نگرانی** — یکساں میٹرکس، ٹریسز، لاگز۔

## مثال کی پالیسی

```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
```

## نقصان و فوائد

ایک میش تاخیر (اضافی ہاپس)، وسائل کا سربوجھ (ہر pod کے لیے ایک پروکسی)، اور حقیقی آپریشنل پیچیدگی شامل کرتا ہے۔

## یہ کیوں اہم ہے

ایک میش ہر سروس میں لچک، سیکیورٹی، اور نگرانی کو معیاری بناتا ہے، بغیر ہر ٹیم کے انہیں مختلف زبانوں میں دوبارہ لاگو کیے۔

لیکن یہ بھاری ہے: اسے صرف اس وقت اپنائیں جب آپ کے پاس اتنی سروسز ہوں کہ ڈپلیکیٹ نیٹ ورکنگ منطق میش کی آپریشنل لاگت سے زیادہ ہو۔