سائیڈ کار پیٹرن: کوڈ میں ترمیم کیے بغیر مائیکرو سروسز کو بڑھانا
جدید کلاؤڈ-نیٹیو سسٹم میں، مائیکرو سروسز سے توقع کی جاتی ہے کہ وہ کاروباری منطق کو چلانے سے کہیں زیادہ کام کریں گے۔ انہیں لاگنگ کو سنبھالنا، SSL/TLS سرٹیفکیٹس کا نظم کرنا، میٹرکس جمع کرنا، دوبارہ کوشش کرنے کے طریقہ کار کو نافذ کرنا، اور دیگر خدمات کے ساتھ محفوظ مواصلات کو مربوط کرنا چاہیے۔
اگر ہم اس تمام کراس کٹنگ فعالیت کو براہ راست ہر ایپلیکیشن کے کوڈ بیس کے اندر ایمبیڈ کرتے ہیں، تو ہم کوڈ بلوٹ، ٹائٹ کپلنگ، اور لینگویج لاک ان کے ساتھ ختم ہوتے ہیں۔
یہ وہ جگہ ہے جہاں سائیڈ کار پیٹرن آتا ہے۔ اس گائیڈ میں، ہم یہ بتائیں گے کہ سائیڈ کار پیٹرن کیا ہے، یہ جدید مائیکرو سروس آرکیٹیکچرز کے لیے کیوں ضروری ہے، اور یہ سادہ تشبیہات اور کوبرنیٹس کنفیگریشن مثالوں کا استعمال کرتے ہوئے کیسے کام کرتا ہے۔
حقیقی دنیا کی تشبیہ: موٹر سائیکل سائیڈ کار
اس پیٹرن کو سمجھنے کا سب سے آسان طریقہ یہ ہے کہ سائیڈ کار والی موٹرسائیکل کے بارے میں سوچیں۔
تصور کریں کہ آپ کے پاس ایک اعلیٰ کارکردگی والی موٹر سائیکل ہے۔ یہ ایک چیز کو غیر معمولی طور پر اچھی طرح سے کرنے کے لیے ڈیزائن کیا گیا ہے: ایک سوار کو تیزی سے منتقل کریں۔ اب، فرض کریں کہ آپ کو مسافروں کا سامان لے جانے کی ضرورت ہے یا ایک اضافی سیٹ شامل کرنا ہے۔
آپ موٹرسائیکل کے فریم، انجن اور پہیوں کو مکمل طور پر دوبارہ ڈیزائن کر کے اسے کار میں تبدیل کر سکتے ہیں۔ تاہم، اس کے لیے بڑی محنت کی ضرورت ہوتی ہے، یہ موٹر سائیکل کی سادگی کو برباد کر دیتا ہے، اور اسے برقرار رکھنا مشکل بنا دیتا ہے۔
اس کے بجائے، آپ ایک سائیڈ کار منسلک کرتے ہیں۔
سائڈ کار ایک الگ، خود ساختہ یونٹ ہے جو موٹرسائیکل سے جڑتا ہے۔ یہ موٹرسائیکل کے سفر کا اشتراک کرتا ہے، جہاں بھی موٹر سائیکل جاتی ہے وہاں جاتی ہے، اور قریب سے چلتی ہے۔ پھر بھی، موٹرسائیکل کا بنیادی انجن اچھوت رہتا ہے۔
سافٹ ویئر فن تعمیر میں:
- موٹر سائیکل آپ کا بنیادی ایپلیکیشن کنٹینر ہے (آپ کی بنیادی کاروباری منطق کو چلانا، جیسے چیک آؤٹ یا صارف کی تصدیق)۔
- The Sidecar ایک علیحدہ مددگار کنٹینر ہے (یوٹیلٹی کاموں کو چلانا، جیسے SSL ختم کرنا، نگرانی کرنا، یا لاگ شپنگ)۔
- The Journey تعیناتی کا لائف سائیکل ہے (مثال کے طور پر، ایک Kubernetes Pod)۔
مسئلہ: کراس کٹنگ کنسرنز اور کوڈ بلوٹ
سائڈ کارس سے پہلے، ڈویلپرز کو مددگار لائبریریوں کو براہ راست اپنے ایپلیکیشن کوڈ میں شامل کرنا پڑتا تھا۔ مثال کے طور پر، اگر آپ مرکزی سرور پر لاگ بھیجنا چاہتے ہیں، تو آپ نے لاگنگ لائبریری درآمد کی ہے۔ اگر آپ کو میٹرکس کی ضرورت ہے، تو آپ نے میٹرکس SDK شامل کیا۔
لائبریری پر مبنی اس نقطہ نظر نے کئی اہم چیلنجز پیدا کیے:
- لینگویج لاک ان: اگر مانیٹرنگ لائبریری صرف گو میں لکھی گئی ہے، تو آپ اسے ازگر یا جاوا مائیکرو سروس میں آسانی سے استعمال نہیں کر سکتے۔ آپ کو اپنے اسٹیک میں ہر زبان کے لیے ایک لائبریری تلاش کرنا یا بنانا ہے۔
- کوڈ آلودگی: کاروبار کی منطق دوبارہ کوششوں، سروس کی دریافت، خفیہ کاری، اور لاگنگ کے لیے بنیادی ڈھانچے کے مخصوص کوڈ کے ساتھ بے ترتیب ہو جاتی ہے۔
- پیچیدہ اپ گریڈ: اگر کمیونیکیشن لائبریری میں کوئی حفاظتی خطرہ پایا جاتا ہے، تو ہر ایک مائیکرو سروس کو اپنی انحصار کو اپ ڈیٹ کرنا، دوبارہ مرتب کرنا، اور دوبارہ تعینات کرنا چاہیے۔
- وسائل کا تنازعہ: مددگار کوڈ اسی رن ٹائم پراسیس میں چلتا ہے جیسے مین ایپلیکیشن، یعنی لاگر میں میموری کا لیک ہونے سے آپ کی پوری بنیادی ایپلیکیشن کریش ہوسکتی ہے۔
حل: سائیڈ کار پیٹرن
سائیڈ کار پیٹرن مددگار کاموں کو اہم درخواست کے عمل سے باہر منتقل کرکے اور انہیں درخواست کے بالکل ساتھ چلنے والے ایک علیحدہ، خودمختار عمل میں رکھ کر ان مسائل کو حل کرتا ہے۔
کنٹینرائزڈ ماحول جیسے Kubernetes میں، ایپلیکیشن کنٹینر اور سائڈ کار کنٹینر ایک ہی Pod کے اندر چلتے ہیں۔ کیونکہ وہ ایک ہی پوڈ کا اشتراک کرتے ہیں:
ایک ہی نیٹ ورک نیم اسپیس: وہ ایک ہی IP ایڈریس اور نیٹ ورک پورٹس کا اشتراک کرتے ہیں۔ وہ عملی طور پر صفر تاخیر کے ساتھ localhost پر فوری طور پر ایک دوسرے سے بات کر سکتے ہیں۔
- مشترکہ اسٹوریج والیوم: وہ بالکل اسی ڈسک اسٹوریج تک رسائی حاصل کرسکتے ہیں، جس سے سائڈ کار کو لاگ فائلوں کو پڑھنے یا مین ایپلی کیشن کے ذریعہ لکھی گئی کنفیگریشن فائلوں کو لوڈ کرنے کی اجازت ملتی ہے۔
- ایک جیسی لائف سائیکل: سائڈ کار کو پرائمری ایپلیکیشن کے ساتھ ہی تعینات، شروع، روکا اور اسکیل کیا جاتا ہے۔
سائیڈ کار پیٹرن کے کلیدی استعمال کے کیسز
Sidecars ناقابل یقین حد تک ورسٹائل ہیں. کچھ عام ایپلی کیشنز میں شامل ہیں:
1. سروس میش پراکسینگ (جیسے، ایلچی، لنکرڈ)
آپ کی ایپلیکیشن دوسری سروسز پر براہ راست HTTP کال کرنے کے بجائے، یہ اپنے مقامی سائڈ کار پراکسی کو درخواستیں بھیجتی ہے۔ سائڈ کار پراکسی روٹنگ، دوبارہ کوششیں، لوڈ بیلنسنگ، سرکٹ بریکنگ، اور باہمی TLS (mTLS) انکرپشن کو ہینڈل کرتی ہے، پھر درخواست کو آگے بھیجتی ہے۔ ایپلی کیشن نیٹ ورک کی ان پیچیدگیوں سے پوری طرح بے خبر ہے۔
2. لاگ جمع کرنا اور آگے بڑھانا (جیسے، روانی بٹ)
آپ کی ایپلی کیشن اپنے لاگ سٹیٹمنٹس کو معیاری آؤٹ پٹ یا مقامی لاگ فائل میں لکھتی ہے۔ ایک سائڈ کار کنٹینر اس فائل کی نگرانی کرتا ہے، لاگز کو پارس کرتا ہے، اور انہیں مرکزی تجزیاتی انجن جیسے Elasticsearch یا Datadog پر بھیج دیتا ہے۔
3. کنفیگریشن اور سیکرٹ ری لوڈنگ
ایک سائیڈ کار کنفیگریشن اپ ڈیٹس یا کرپٹوگرافک کلیدی گردشوں کے لیے ریموٹ سرور (جیسے قونصل یا والٹ) دیکھ سکتا ہے۔ جب کسی تبدیلی کا پتہ چلتا ہے، تو یہ نئی فائلوں کو مشترکہ والیوم میں ڈاؤن لوڈ کرتا ہے اور ری اسٹارٹ کیے بغیر مرکزی ایپلیکیشن کو دوبارہ لوڈ کرنے کا اشارہ دیتا ہے۔
Kubernetes نفاذ کی مثال
کوبرنیٹس میں سائڈ کار سیٹ کرنا سیدھا سیدھا ہے۔ یہاں ایک سادہ YAML کنفیگریشن ہے جس میں ایک ایپلیکیشن کنٹینر کو ایک مشترکہ والیوم میں لاگز لکھتے ہوئے دکھایا گیا ہے، اور ایک Fluent Bit sidecar کنٹینر ان لاگز کو پڑھ کر بھیج رہا ہے:
apiVersion: v1
kind: Pod
metadata:
name: app-with-logging-sidecar
labels:
app: billing-service
spec:
containers:
# 1. Primary Application Container
- name: web-app
image: node:18-alpine
command: ["/bin/sh", "-c"]
args:
- >
while true; do
echo "$(date) [INFO] Transaction processed successfully" >> /var/log/app/output.log;
sleep 5;
done
volumeMounts:
- name: shared-logs
mountPath: /var/log/app
# 2. Sidecar Container (Log Shipper)
- name: log-shipper
image: fluent/fluent-bit:latest
volumeMounts:
- name: shared-logs
mountPath: /var/log/app
# In a real setup, Fluent Bit config would read /var/log/app/output.log
# and forward it to an external logging system.
# Shared disk storage accessible by both containers
volumes:
- name: shared-logs
emptyDir: {}
سائیڈ کار پیٹرن کے فائدے اور نقصانات
کسی بھی ڈیزائن کے پیٹرن کی طرح، سائڈکارس ٹریڈ آف کے ساتھ آتی ہیں:
| فائدہ (پرو) | نقصان (کون) |
|---|---|
| Language Agnostic: سائڈ کار اپنے ماحول میں چلتی ہے۔ آپ Go، Java، Python، یا Ruby ایپس کے آگے وہی سائڈ کار مددگار استعمال کر سکتے ہیں۔ | ریورس اوور ہیڈ: فی پوڈ متعدد کنٹینرز چلانے سے CPU اور میموری کی کھپت بڑھ جاتی ہے۔ |
| ڈیکپلڈ لائف سائیکل: انفراسٹرکچر ٹیمیں ایپلیکیشن کوڈ کو چھوئے بغیر سائڈ کار کے سیکیورٹی پیچ کو اپ ڈیٹ کرسکتی ہیں۔ | اضافہ پیچیدگی: دو گنا زیادہ کنٹینرز کا انتظام تعیناتی کی ترتیب، ڈیبگنگ اور شیڈولنگ کو پیچیدہ بناتا ہے۔ |
| انڈیپینڈنٹ فیلور آئسولیشن: اگر سائڈ کار کنٹینر کریش ہو جاتا ہے، تو Kubernetes مین ایپلیکیشن کو ہٹائے بغیر اسے خود بخود دوبارہ شروع کر سکتا ہے۔ | ذرا سا نیٹ ورک لیٹنسی: مقامی پراکسی سائڈ کار کے ذریعے ٹریفک روٹنگ ایک چھوٹی سی ہاپ کا اضافہ کرتی ہے، حالانکہ یہ عام طور پر نہ ہونے کے برابر ہے (< 1ms)۔ |
نتیجہ
سائڈکار پیٹرن جدید کلاؤڈ-آبائی فن تعمیر کا ایک بنیادی تعمیراتی بلاک ہے۔ کراس کٹنگ خدشات کو الگ کر کے — جیسے کہ نیٹ ورک پراکسینگ، سیکیورٹی، لاگنگ، اور کنفیگریشن مینجمنٹ — کو ایک الگ ساتھی عمل میں، یہ ڈویلپرز کو مکمل طور پر کاروباری قدر بڑھانے پر توجہ مرکوز کرنے کی اجازت دیتا ہے۔
جب کہ یہ اضافی وسائل اوور ہیڈ متعارف کراتی ہے اور مؤثر طریقے سے انتظام کرنے کے لیے Kubernetes جیسے کنٹینر آرکیسٹریشن پلیٹ فارمز کی ضرورت ہوتی ہے، کلینر کوڈ بیس، زبان کی لچک، اور آزاد اسکیلنگ کے فوائد اسے انٹرپرائز مائیکرو سروسز کے لیے ایک ناگزیر نمونہ بناتے ہیں۔
غزنکس بلاگ پر مزید سافٹ ویئر ڈویلپمنٹ اور بیک اینڈ انجینئرنگ کی بصیرتیں دریافت کریں →