نوٹ. ترجمہ: اس مضمون کا مصنف (Luc Perkins) CNCF تنظیم میں ایک ڈویلپر ایڈووکیٹ ہے، جو Linkerd، SMI (سروس میش انٹرفیس) اور Kuma جیسے اوپن سورس پروجیکٹس کا گھر ہے (ویسے، کیا آپ نے یہ بھی سوچا ہے کہ Istio کیوں ہے؟ اس فہرست میں نہیں؟) ایک بار پھر DevOps کمیونٹی کو "سروس میش" نامی جدید ہائپ کی بہتر تفہیم دلانے کی کوشش کرتے ہوئے، وہ 16 خصوصیات کی فہرست دیتا ہے جو اس طرح کے حل فراہم کرتے ہیں۔
آج - سافٹ ویئر انجینئرنگ کے میدان میں سب سے مشہور موضوعات میں سے ایک (اور بجا طور پر!) میرے خیال میں یہ ٹکنالوجی ناقابل یقین حد تک امید افزا ہے اور میں اسے بڑے پیمانے پر اپنایا ہوا دیکھنا چاہوں گا (جب یقیناً اس کا مطلب ہو)۔ تاہم، یہ اب بھی زیادہ تر لوگوں کے لیے اسرار کی چمک سے گھرا ہوا ہے۔ ایک ہی وقت میں، وہ بھی جو اچھی طرح سے جانا جاتا ہے اس کے ساتھ، اس کے فوائد اور یہ بالکل کیا ہے (بشمول آپ کے واقعی) کو مرتب کرنا اکثر مشکل ہوتا ہے۔ اس مضمون میں میں مختلف کی فہرست بنا کر صورتحال کو درست کرنے کی کوشش کروں گا۔ مقدمات کا استعمال کریں "سروس میشز"*۔
* نوٹ ترجمہ: یہاں اور آگے مضمون میں بالکل یہ ترجمہ ("سروس میش") اب بھی نئی اصطلاح سروس میش کے لیے استعمال کیا جائے گا۔
لیکن پہلے میں چند تبصرے کرنا چاہتا ہوں:
- میں نے کبھی بھی سروس میشز کے ساتھ کام نہیں کیا اور نہ ہی انہیں اپنی تعلیم کے لیے شروع کیے گئے پروجیکٹوں کے باہر استعمال کیا۔ دوسری طرف، میں وہ تھا جس نے 2015 میں ٹویٹر کی اندرونی سروس میش کے لیے دستاویزات کا ایک گروپ لکھا تھا (اس وقت اسے "سروس میش" بھی نہیں کہا جاتا تھا) اور ویب سائٹ کی ترقی اور اس کے لیے دستاویزات میں حصہ لیا ، تو اس کا مطلب کچھ ہے۔
- میری فہرست تخمینی اور نامکمل ہے۔ ہو سکتا ہے کہ استعمال کے ایسے معاملات ہوں جو میرے لیے نامعلوم ہیں، اور وقت کے ساتھ ساتھ ٹیکنالوجی کے ترقی اور اس کی مقبولیت میں اضافے کے ساتھ ساتھ نئے اختیارات بھی سامنے آئیں گے۔
- ایک ہی وقت میں، ہر موجودہ سروس میش کا نفاذ درج کردہ استعمال کے تمام معاملات کی حمایت نہیں کرتا ہے۔ اس لیے، میرے بیانات جیسے "سروس میش کر سکتے ہیں..." کو "انفرادی، اور شاید تمام مقبول سروس میش کے نفاذ کو..." کے طور پر پڑھا جانا چاہیے۔
- مثالوں کی ترتیب سے کوئی فرق نہیں پڑتا۔
مختصر فہرست:
- سروس کی دریافت؛
- خفیہ کاری؛
- تصدیق اور اجازت؛
- وزن کو متوازن کرنا؛
- سرکٹ توڑنے؛
- آٹو اسکیلنگ
- کینری تعیناتیاں؛
- نیلے سبز کی تعیناتی؛
- صحت کی جانچ؛
- لوڈ شیڈنگ؛
- ٹریفک کی عکس بندی؛
- موصلیت؛
- درخواست کی شرح محدود، دوبارہ کوششیں اور ٹائم آؤٹ؛
- ٹیلی میٹری
- آڈٹ؛
- تصور
1. سروس کی دریافت
TL;DR: سادہ ناموں کا استعمال کرتے ہوئے نیٹ ورک پر دیگر خدمات سے جڑیں۔
خدمات کو مناسب ناموں کا استعمال کرتے ہوئے ایک دوسرے کو خود بخود "تلاش" کرنے کے قابل ہونا چاہئے - مثال کے طور پر، service.api.production, pets/staging یا cassandra. کلاؤڈ ماحول لچکدار ہیں، اور ایک نام ایک سروس کی بہت سی مثالوں کو چھپا سکتا ہے۔ یہ واضح ہے کہ ایسی صورت حال میں تمام IP پتوں کو ہارڈ کوڈ کرنا جسمانی طور پر ناممکن ہے۔
اس کے علاوہ، جب ایک سروس کو دوسری مل جاتی ہے، تو اسے اس سروس کو اس خوف کے بغیر درخواستیں بھیجنے کے قابل ہونا چاہیے کہ وہ اس کی ٹوٹی ہوئی مثال کے ان پٹ پر ختم ہو جائیں گی۔ دوسرے الفاظ میں، سروس میش کو تمام سروس مثالوں کی صحت کی نگرانی کرنی چاہیے اور میزبانوں کی فہرست کو ہر ممکن حد تک تازہ ترین رکھنا چاہیے۔
ہر سروس میش سروس کی دریافت کے طریقہ کار کو مختلف طریقے سے نافذ کرتا ہے۔ اس وقت، سب سے عام طریقہ یہ ہے کہ کوبرنیٹس ڈی این ایس جیسے بیرونی عمل کو تفویض کیا جائے۔ ماضی میں ٹویٹر پر ہم نے اس مقصد کے لیے نام دینے کا نظام استعمال کیا تھا۔ . اس کے علاوہ، سروس میش ٹکنالوجی اپنی مرضی کے مطابق نام دینے کے طریقہ کار کو ابھرنا ممکن بناتی ہے (حالانکہ میں نے ابھی تک ایسی فعالیت کے ساتھ کوئی SM عمل درآمد نہیں دیکھا ہے)۔
2. خفیہ کاری
TL;DR: خدمات کے درمیان غیر خفیہ کردہ ٹریفک سے چھٹکارا حاصل کریں اور اس عمل کو خودکار اور توسیع پذیر بنائیں۔
یہ جان کر خوشی ہوئی کہ حملہ آور آپ کے اندرونی نیٹ ورک میں داخل نہیں ہو سکتے۔ فائر وال اس کا بہت اچھا کام کرتے ہیں۔ لیکن اگر کوئی ہیکر اندر آجائے تو کیا ہوگا؟ کیا وہ انٹرا سروس ٹریفک کے ساتھ جو چاہے کر سکے گا؟ آئیے امید کرتے ہیں کہ آخر ایسا نہیں ہوگا۔ اس منظر نامے کو روکنے کے لیے، آپ کو ایک زیرو ٹرسٹ نیٹ ورک نافذ کرنا چاہیے جس میں سروسز کے درمیان تمام ٹریفک کو خفیہ کیا جاتا ہے۔ زیادہ تر جدید سروس میشز باہمی کے ذریعے اسے حاصل کرتی ہیں۔ (باہمی TLS، mTLS)۔ کچھ صورتوں میں، mTLS پورے بادلوں اور کلسٹرز میں کام کرتا ہے (میرے خیال میں کسی دن بین سیاروں کی مواصلات اسی طرح ترتیب دی جائیں گی)۔
بلاشبہ، mTLS سروس میش کے لیے اختیاری. ہر سروس اپنے TLS کا خیال رکھ سکتی ہے، لیکن اس کا مطلب یہ ہے کہ آپ کو سرٹیفکیٹ بنانے، انہیں سروس میزبانوں میں تقسیم کرنے، اور ایپلی کیشن میں کوڈ شامل کرنے کی ضرورت ہوگی جو فائلوں سے ان سرٹیفکیٹس کو لوڈ کرے گا۔ اوہ، اور باقاعدگی سے وقفوں پر ان سرٹیفکیٹس کی تجدید کرنا نہ بھولیں۔ سروس جیسے سسٹمز کے ساتھ ایم ٹی ایل ایس کو خودکار میش کرتی ہے۔ ، جو بدلے میں، سرٹیفکیٹ جاری کرنے اور گھومنے کے عمل کو خودکار کرتا ہے۔
3. تصدیق اور اجازت
TL؛ DR: درخواست کرنے والا کون ہے اور اس کی وضاحت کریں کہ درخواست سروس تک پہنچنے سے پہلے انہیں کیا کرنے کی اجازت ہے۔
خدمات اکثر جاننا چاہتی ہیں۔ کون درخواست (تصدیق) کو انجام دیتا ہے، اور اس معلومات کو استعمال کرتے ہوئے، فیصلہ کرتا ہے۔ کہ ایک دی گئی ہستی کو کرنے کی اجازت ہے (اجازت)۔ اس صورت میں، ضمیر "کون" چھپا سکتا ہے:
- دیگر خدمات۔ اسے کہتے ہیں "تصدیق" ساتھی" مثال کے طور پر، خدمت
webسروس تک رسائی حاصل کرنا چاہتا ہے۔db. سروس میشز عام طور پر mTLS کا استعمال کرتے ہوئے اس طرح کے مسائل کو حل کرتے ہیں: اس معاملے میں سرٹیفکیٹ ضروری شناخت کنندہ کے طور پر کام کرتے ہیں۔ - کچھ انسانی صارفین۔ اسے کہتے ہیں "تصدیق" درخواست" مثال کے طور پر، صارف
haxor69ایک نیا لیمپ خریدنا چاہتا ہے۔ سروس میشز مختلف میکانزم فراہم کرتے ہیں، جیسے .ہم میں سے بہت سے لوگوں نے یہ ایپلیکیشن کوڈ میں کیا ہے۔ ایک درخواست آتی ہے، ہم میز کے ذریعے دیکھتے ہیں
usersصارف کو تلاش کریں اور پاس ورڈ کا موازنہ کریں، پھر کالم چیک کریں۔permissionsوغیرہ سروس میش کی صورت میں، درخواست کے سروس تک پہنچنے سے پہلے ایسا ہوتا ہے۔
ایک بار جب ہم یہ طے کر لیں کہ درخواست کس کی طرف سے آئی ہے، ہمیں یہ تعین کرنے کی ضرورت ہے کہ اس ادارے کو کیا کرنے کی اجازت ہے۔ کچھ سروس میشز آپ کو بنیادی پالیسیاں ترتیب دینے کی اجازت دیتی ہیں (اس بارے میں کہ کون کیا کر سکتا ہے) بطور YAML فائلوں یا کمانڈ لائن پر، جبکہ دیگر فریم ورک کے ساتھ انضمام پیش کرتے ہیں جیسے . حتمی مقصد یہ ہے کہ آپ کی خدمات کسی بھی درخواست کو محفوظ طریقے سے قبول کریں، یہ فرض کرتے ہوئے کہ یہ کسی قابل اعتماد ذریعہ سے آئی ہے۔ и اس کارروائی کی اجازت ہے.
4. لوڈ بیلنسنگ
TL؛ DR: ایک مخصوص پیٹرن کے مطابق لوڈ کو تمام سروس مثالوں میں تقسیم کریں۔
سروس سیکشن کے اندر ایک "خدمت" اکثر ایک جیسی مثالوں پر مشتمل ہوتی ہے۔ مثال کے طور پر، آج کی خدمت cache 5 کاپیوں پر مشتمل ہے، اور کل ان کی تعداد 11 تک بڑھ سکتی ہے۔ cache، ایک خاص مقصد کے مطابق تقسیم کیا جانا چاہئے۔ مثال کے طور پر، تاخیر کو کم سے کم کریں یا کام کرنے کی مثال تک پہنچنے کے امکان کو زیادہ سے زیادہ کریں۔ سب سے زیادہ استعمال ہونے والا الگورتھم راؤنڈ رابن ہے، لیکن بہت سے دوسرے ہیں - مثال کے طور پر، وزنی طریقہ (وزن والا) سوالات (آپ ترجیحی اہداف کو منتخب کر سکتے ہیں)، انگوٹی کریں۔ (انگوٹھی) ہیشنگ (اپ اسٹریم میزبانوں میں مستقل ہیشنگ کا استعمال کرتے ہوئے) یا کم از کم درخواست کا طریقہ (بہت سے کم درخواستوں کے ساتھ مثال کو ترجیح دی جاتی ہے)۔
کلاسک بیلنسرز کے دیگر افعال ہوتے ہیں، جیسے کہ HTTP کیشنگ اور DDoS تحفظ، لیکن وہ مشرق-مغربی ٹریفک کے لیے بہت زیادہ متعلقہ نہیں ہیں (یعنی ڈیٹا سینٹر کے اندر بہنے والی ٹریفک کے لیے - تقریباً ترجمہ) (سروس میش کا مخصوص دائرہ کار)۔ بلاشبہ، لوڈ بیلنسنگ کے لیے سروس میش کا استعمال کرنا ضروری نہیں ہے، لیکن یہ آپ کو ہر سروس کے لیے ایک سنٹرلائزڈ کنٹرول لیئر سے بیلنسنگ پالیسیاں ترتیب دینے اور کنٹرول کرنے کی اجازت دیتا ہے، اس طرح نیٹ ورک اسٹیک میں علیحدہ لوڈ بیلنسرز کو چلانے اور ترتیب دینے کی ضرورت ختم ہوجاتی ہے۔ .
5. سرکٹ توڑنا
TL;DR: پریشانی والی سروس پر ٹریفک روکیں اور بدترین حالات میں نقصان کو کنٹرول کریں۔
اگر کسی وجہ سے سروس ٹریفک کا مقابلہ نہیں کر سکتی ہے، تو سروس میش اس مسئلے کو حل کرنے کے لیے کئی آپشنز فراہم کرتی ہے (دیگر مناسب حصوں میں زیر بحث آئیں گے)۔ سروس کو ٹریفک سے منقطع کرنے کے لیے سرکٹ بریکنگ سب سے سخت آپشن ہے۔ تاہم، بذات خود اس کا کوئی مطلب نہیں ہے - ایک بیک اپ پلان کی ضرورت ہے۔ بیک پریشر فراہم کیا جا سکتا ہے () ایسی خدمات کے لیے جو درخواستیں کرتی ہیں (صرف اس کے لیے اپنی سروس میش کو ترتیب دینا نہ بھولیں!)، یا، مثال کے طور پر، اسٹیٹس پیج کو سرخ رنگ دینا اور صارفین کو صفحہ کے دوسرے ورژن پر "گرنے والی وہیل" کے ساتھ ری ڈائریکٹ کرنا ("Twitter is نیچے")۔
سروس میشز نہ صرف آپ کو وضاحت کرنے کی اجازت دیتے ہیں۔ جب شٹ ڈاؤن کی پیروی کریں گے اور کہ یہ پیروی کرے گا. اس صورت میں، "کب" میں مخصوص پیرامیٹرز کا کوئی بھی مجموعہ شامل ہوسکتا ہے: ایک مخصوص مدت کے لیے درخواستوں کی کل تعداد، متوازی کنکشنز کی تعداد، زیر التواء درخواستیں، دوبارہ کوششیں، وغیرہ۔
آپ شاید سرکٹ بریکنگ کا غلط استعمال نہیں کرنا چاہتے، لیکن یہ جان کر خوشی ہوئی کہ ایمرجنسی کی صورت میں آپ کے پاس بیک اپ پلان ہے۔
6. آٹو اسکیلنگ
TL؛ DR: مخصوص معیار پر منحصر خدمت کے واقعات کی تعداد میں اضافہ یا کمی کریں۔
سروس میش شیڈولر نہیں ہیں، لہذا وہ نہیں کرتے ہیں باہر لے اپنے آپ کو پیمانہ بنانا. تاہم، وہ معلومات فراہم کر سکتے ہیں کہ کن منصوبہ ساز اپنے فیصلوں کی بنیاد رکھیں گے۔ چونکہ سروس میشز کو سروسز کے درمیان تمام ٹریفک تک رسائی حاصل ہوتی ہے، اس لیے ان کے پاس اس بارے میں وسیع معلومات ہوتی ہیں کہ کیا ہو رہا ہے: کون سی سروسز مسائل کا سامنا کر رہی ہیں، کون سی سروسز بہت ہلکی بھری ہوئی ہیں (ان کے لیے مختص کی گئی صلاحیت ضائع ہو گئی ہے)، وغیرہ۔
مثال کے طور پر، Kubernetes پوڈز کے CPU اور میموری کے استعمال کی بنیاد پر خدمات کی پیمائش کرتا ہے۔ (ہماری رپورٹ دیکھیں"" - تقریبا. ترجمہ)لیکن اگر آپ کسی دوسرے میٹرک کی بنیاد پر پیمانہ کرنے کا فیصلہ کرتے ہیں (ہمارے معاملے میں، ٹریفک سے متعلق)، آپ کو ایک خاص میٹرک کی ضرورت ہوگی۔ انتظام دکھاتا ہے کہ اس کے ساتھ کیسے کرنا ہے۔ , и ، لیکن عمل خود کافی پیچیدہ ہے۔ ہم چاہیں گے کہ سروس میش اس کو آسان بنائے اور ہمیں صرف "سروس کی مثالوں کی تعداد میں اضافہ" جیسی شرائط قائم کرنے کی اجازت دے کر auth، اگر زیر التواء درخواستوں کی تعداد ایک منٹ کے اندر حد سے تجاوز کر جاتی ہے۔"
7. کینری تعیناتیاں
TL؛ DR: صارفین کے سب سیٹ پر نئی خصوصیات یا سروس ورژن کی جانچ کریں۔
فرض کریں کہ آپ SaaS پروڈکٹ تیار کر رہے ہیں اور اس کا ایک نیا نیا ورژن متعارف کروانے کا ارادہ رکھتے ہیں۔ آپ نے اسے اسٹیجنگ میں آزمایا اور اس نے بہت اچھا کام کیا۔ لیکن حقیقی حالات میں اس کے رویے کے بارے میں اب بھی کچھ خدشات موجود ہیں۔ دوسرے الفاظ میں، آپ کو صارف کے اعتماد کو خطرے میں ڈالے بغیر حقیقی مسائل پر نئے ورژن کی جانچ کرنے کی ضرورت ہے۔ کینری کی تعیناتیاں اس کے لیے بہترین ہیں۔ وہ آپ کو صارفین کے ذیلی سیٹ کو ایک نئی خصوصیت کا مظاہرہ کرنے کی اجازت دیتے ہیں۔ اس ذیلی سیٹ میں سب سے زیادہ وفادار صارفین یا وہ لوگ جو پروڈکٹ کے مفت ورژن کے ساتھ کام کرتے ہیں، یا ایسے صارفین پر مشتمل ہو سکتا ہے جنہوں نے "گنی پگز" بننے کی خواہش کا اظہار کیا ہو۔
سروس میش آپ کو ایسے معیارات کی وضاحت کرنے کی اجازت دے کر لاگو کرتے ہیں جو یہ طے کرتے ہیں کہ کون ایپلیکیشن کا کون سا ورژن دیکھے گا، اور اس کے مطابق ٹریفک کو روٹ کر رہا ہے۔ تاہم، خود خدمات کے لیے کچھ بھی تبدیل نہیں ہوتا ہے۔ سروس کے ورژن 1.0 کا خیال ہے کہ تمام درخواستیں ان صارفین کی طرف سے آتی ہیں جنہیں اسے دیکھنا چاہیے، اور ورژن 1.1 اپنے صارفین کے لیے بھی ایسا ہی مانتا ہے۔ دریں اثنا، آپ پرانے اور نئے ورژن کے درمیان ٹریفک کے فیصد کو تبدیل کر سکتے ہیں، صارفین کی بڑھتی ہوئی تعداد کو نئے کی طرف بھیج سکتے ہیں اگر یہ مستحکم طریقے سے کام کرتا ہے اور آپ کے "گائنی پگز" آگے بڑھتے ہیں۔
8. نیلے سبز کی تعیناتی۔
TL؛ DR: ایک عمدہ نئی خصوصیت کو رول آؤٹ کریں، لیکن فوری طور پر سب کچھ واپس لینے کے لیے تیار رہیں۔
مطلب ایک نئی "بلیو" سروس کو شروع کرنا ہے، اسے پرانی، "سبز" سروس کے متوازی طور پر شروع کرنا ہے۔ اگر سب کچھ آسانی سے چلتا ہے اور نئی سروس اچھی کارکردگی کا مظاہرہ کرتی ہے، تو پرانی کو آہستہ آہستہ غیر فعال کیا جا سکتا ہے۔ (افسوس، کسی دن یہ نئی "نیلی" سروس "سبز" والے کی تقدیر کو دہرائے گی اور غائب ہو جائے گی...) نیلے سبز کی تعیناتی کینری سے مختلف ہے جس میں نئے فنکشن کا احاطہ کیا گیا ہے۔ سب ایک ساتھ صارفین (حصہ نہیں)؛ یہاں نقطہ یہ ہے کہ کچھ غلط ہونے کی صورت میں ایک "محفوظ بندرگاہ" تیار ہو۔
سروس میشز "نیلی" سروس کو جانچنے کا ایک بہت ہی آسان طریقہ پیش کرتے ہیں اور مسائل کی صورت میں فوری طور پر کام کرنے والے "سبز" پر سوئچ کرتے ہیں۔ اس حقیقت کا ذکر نہ کرنا کہ راستے میں وہ "نیلے" کے کام کے بارے میں بہت ساری معلومات فراہم کرتے ہیں (نیچے "ٹیلی میٹری" دیکھیں)، جو یہ سمجھنے میں مدد کرتا ہے کہ آیا یہ مکمل آپریشن کے لیے تیار ہے یا نہیں۔
نوٹ. ترجمہ: آپ Kubernetes میں تعیناتی کی مختلف حکمت عملیوں کے بارے میں مزید پڑھ سکتے ہیں (بشمول مذکورہ کینری، نیلا/سبز اور دیگر) .
9. صحت کی جانچ
TL؛ DR: اس بات کا سراغ لگائیں کہ کون سی سروس مثالیں فعال ہیں اور ان کا جواب دیں جو اب کام نہیں کر رہے ہیں۔
صحت کی جانچ (صحت کی جانچ) یہ فیصلہ کرنے میں مدد کرتا ہے کہ آیا سروس کی مثالیں ٹریفک کو قبول کرنے اور اس پر کارروائی کرنے کے لیے تیار ہیں۔ مثال کے طور پر، HTTP خدمات کے معاملے میں، صحت کی جانچ اختتامی نقطہ پر GET کی درخواست کی طرح نظر آتی ہے۔ /health. جواب دیں۔ 200 OK اس کا مطلب یہ ہوگا کہ مثال صحت مند ہے، کوئی اور - کہ یہ ٹریفک حاصل کرنے کے لیے تیار نہیں ہے۔ سروس میش آپ کو دونوں طریقوں کی وضاحت کرنے کی اجازت دیتے ہیں جس میں فعالیت کی جانچ کی جائے گی اور اس کی تعدد جس کے ساتھ یہ چیک کیا جائے گا۔ اس معلومات کو پھر دوسرے مقاصد کے لیے استعمال کیا جا سکتا ہے - مثال کے طور پر، لوڈ بیلنسنگ اور سرکٹ توڑنے کے لیے۔
اس طرح، صحت کی جانچ پڑتال اکیلے استعمال کا معاملہ نہیں ہے، لیکن عام طور پر دوسرے مقاصد کے حصول کے لیے استعمال ہوتا ہے۔ اس کے علاوہ، صحت کی جانچ کے نتائج پر منحصر ہے، دوسرے سروس میش اہداف سے باہر کی کارروائیوں کی ضرورت ہو سکتی ہے: مثال کے طور پر، اسٹیٹس پیج کو اپ ڈیٹ کرنا، GitHub پر مسئلہ پیدا کرنا، یا JIRA ٹکٹ بھرنا۔ اور سروس میش اس سب کو خودکار کرنے کے لیے ایک آسان طریقہ کار پیش کرتا ہے۔
10. لوڈ شیڈنگ
TL;DR: استعمال میں عارضی اضافے کے جواب میں ٹریفک کو ری ڈائریکٹ کریں۔
اگر کوئی خاص سروس ٹریفک سے بھری ہوئی ہے، تو آپ اس ٹریفک میں سے کچھ کو عارضی طور پر کسی دوسرے مقام پر بھیج سکتے ہیں (یعنی "ڈمپ"، "منتقلی" (شیڈ) وہ وہاں)۔ مثال کے طور پر، بیک اپ سروس یا ڈیٹا سینٹر، یا مستقل کو موضوع۔ نتیجتاً، سروس کریش ہونے اور ہر چیز کو مکمل طور پر پروسیسنگ کو روکنے کے بجائے کچھ درخواستوں پر کارروائی کرتی رہے گی۔ لوڈ شیڈنگ سرکٹ کو توڑنے سے افضل ہے لیکن پھر بھی اس کا غلط استعمال کرنا مناسب نہیں۔ یہ جھرن کی ناکامیوں کو روکنے میں مدد کرتا ہے جس کی وجہ سے ڈاؤن اسٹریم سروسز کریش ہو جاتی ہیں۔
11. ٹریفک متوازی/آئینہ کاری
TL؛ DR: ایک ساتھ کئی جگہوں پر ایک درخواست بھیجیں۔
بعض اوقات ایک ہی وقت میں متعدد خدمات کو درخواست (یا درخواستوں کا ایک خاص انتخاب) بھیجنے کی ضرورت ہوتی ہے۔ ایک عام مثال پروڈکشن ٹریفک کا کچھ حصہ سٹیجنگ سروس کو بھیجنا ہے۔ مین پروڈکشن ویب سرور ڈاؤن اسٹریم سروس کو ایک درخواست بھیجتا ہے۔ products.production اور صرف اس کے لئے. اور سروس میش ذہانت کے ساتھ اس درخواست کو کاپی کرتا ہے اور اسے بھیجتا ہے۔ products.stagingجس کا ویب سرور کو بھی علم نہیں ہے۔
ایک اور متعلقہ سروس میش استعمال کیس جو ٹریفک کے متوازی کے اوپر لاگو کیا جاسکتا ہے۔ . اس میں سروس کے مختلف ورژنز کو ایک جیسی درخواستیں بھیجنا اور یہ جانچنا شامل ہے کہ آیا تمام ورژن ایک جیسا برتاؤ کرتے ہیں۔ میں نے ابھی تک ایک مربوط ریگریشن ٹیسٹنگ سسٹم کے ساتھ سروس میش پر عمل درآمد نہیں کیا ہے۔ ، لیکن خیال خود امید افزا لگتا ہے۔
12. موصلیت
TL;DR: اپنی سروس میش کو منی نیٹ ورکس میں توڑ دیں۔
اس نام سے بہی جانا جاتاہے انقطاعتنہائی ایک سروس میش کو منطقی طور پر الگ الگ حصوں میں تقسیم کرنے کا فن ہے جو ایک دوسرے کے بارے میں کچھ نہیں جانتے ہیں۔ تنہائی ورچوئل پرائیویٹ نیٹ ورک بنانے کی طرح ہے۔ بنیادی فرق یہ ہے کہ آپ اب بھی سروس میش (جیسے سروس کی دریافت) کے تمام فوائد سے لطف اندوز ہوسکتے ہیں، لیکن اضافی سیکیورٹی کے ساتھ۔ مثال کے طور پر، اگر کوئی حملہ آور ایک سب نیٹ پر کسی سروس میں داخل ہونے کا انتظام کرتا ہے، تو وہ یہ نہیں دیکھ سکے گا کہ دوسرے سب نیٹ پر کون سی سروسز چل رہی ہیں یا ان کی ٹریفک کو روک نہیں سکے گا۔
اس کے علاوہ، فوائد بھی تنظیمی ہوسکتے ہیں. آپ اپنی خدمات کو اپنی کمپنی کے ڈھانچے کی بنیاد پر سب نیٹ کرنا چاہتے ہیں اور ڈویلپرز کو پوری سروس میش کو ذہن میں رکھنے کے علمی بوجھ سے نجات دلانا چاہتے ہیں۔
13. شرح کو محدود کرنے، دوبارہ کوششوں اور ٹائم آؤٹس کی درخواست کریں۔
TL؛ DR: آپ کو کوڈ بیس میں دبانے کی درخواست کے انتظام کے کاموں کو شامل کرنے کی ضرورت نہیں ہے۔
ان تمام چیزوں کو الگ الگ استعمال کے معاملات پر غور کیا جا سکتا ہے، لیکن میں نے ایک عام خصوصیت کی وجہ سے ان کو یکجا کرنے کا فیصلہ کیا: وہ درخواست لائف سائیکل مینجمنٹ کے کاموں کو سنبھالتے ہیں جو عام طور پر ایپلی کیشن لائبریریوں کے ذریعہ سنبھالے جاتے ہیں۔ اگر آپ روبی آن ریلز میں ایک ویب سرور تیار کر رہے ہیں (سروس میش کے ساتھ مربوط نہیں ہے) جو بیک اینڈ سروسز کے لیے درخواستیں کرتا ہے۔ ، درخواست کو فیصلہ کرنا ہوگا کہ اگر N درخواستیں ناکام ہوجاتی ہیں تو کیا کرنا ہے۔ آپ کو یہ بھی معلوم کرنا پڑے گا کہ یہ سروسز ایک خصوصی لائبریری کا استعمال کرتے ہوئے ان پیرامیٹرز کو پروسیس اور ہارڈ کوڈ کرنے کے قابل ہوں گی۔ اس کے علاوہ، درخواست کو یہ فیصلہ کرنا ہو گا کہ کب ہار ماننے کا وقت ہے اور درخواست کو ختم ہونے دیں گے (ٹائم آؤٹ کی بنیاد پر)۔ اور مندرجہ بالا پیرامیٹرز میں سے کسی کو تبدیل کرنے کے لیے، ویب سرور کو روکنا، دوبارہ ترتیب دینا اور دوبارہ شروع کرنا ہوگا۔
ان کاموں کو سروس میش پر آف لوڈ کرنے کا نہ صرف یہ مطلب ہے کہ سروس ڈویلپرز کو ان کے بارے میں سوچنے کی ضرورت نہیں ہوگی، بلکہ یہ بھی کہ انہیں زیادہ عالمی انداز میں دیکھا جا سکتا ہے۔ اگر خدمات کا ایک پیچیدہ سلسلہ استعمال کیا جاتا ہے تو، A -> B -> C -> D -> E، درخواست کے پورے لائف سائیکل کو مدنظر رکھا جانا چاہیے۔ اگر کام سروس C میں ٹائم آؤٹ کو بڑھانا ہے، تو یہ سب کچھ ایک ساتھ کرنا منطقی ہے، نہ کہ حصوں میں: سروس کوڈ کو اپ ڈیٹ کرکے اور اس وقت تک انتظار کریں جب تک کہ پل کی درخواست قبول نہ ہوجائے اور CI سسٹم اپڈیٹڈ سروس کو متعین کرے۔
14. ٹیلی میٹری
TL؛ DR: خدمات سے تمام ضروری (اور کافی نہیں) معلومات اکٹھی کریں۔
ٹیلی میٹری ایک عام اصطلاح ہے جس میں میٹرکس، تقسیم شدہ ٹریسنگ، اور لاگز شامل ہیں۔ سروس میش تینوں قسم کے ڈیٹا کو اکٹھا کرنے اور اس پر کارروائی کرنے کا طریقہ کار پیش کرتے ہیں۔ یہ وہ جگہ ہے جہاں چیزیں تھوڑی دھندلی ہوجاتی ہیں کیونکہ ممکنہ اختیارات کی تعداد بہت زیادہ ہے۔ میٹرکس جمع کرنے کے لیے وہاں ہے۔ اور دوسرے ٹولز جو نوشتہ جات جمع کرنے کے لیے استعمال کیے جاسکتے ہیں۔ , , وغیرہ (مثال کے طور پر ہمارے ساتھ کلک ہاؤس K8s کے لیے - تقریبا ترجمہ)، تقسیم شدہ ٹریسنگ کے لیے موجود ہے۔ اور اسی طرح۔ ہر سروس میش کچھ ٹولز کو سپورٹ کر سکتا ہے اور دوسروں کو نہیں۔ یہ دیکھنا دلچسپ ہوگا کہ آیا یہ منصوبہ کامیاب ہو سکتا ہے۔ کچھ ہم آہنگی فراہم کریں.
اس صورت میں، سروس میش ٹیکنالوجی کا فائدہ یہ ہے کہ سائڈ کار کنٹینرز، اصولی طور پر، اپنی خدمات سے مندرجہ بالا تمام ڈیٹا اکٹھا کر سکتے ہیں۔ دوسرے الفاظ میں، آپ کے اختیار میں ایک ہی ٹیلی میٹری جمع کرنے کا نظام ہے، اور سروس میش اس تمام معلومات کو مختلف طریقوں سے پروسیس کر سکتا ہے۔ مثال کے طور پر:
- CLI میں کسی خاص سروس سے ٹیل لاگز؛
- سروس میش ڈیش بورڈ سے درخواستوں کے حجم کی نگرانی کریں۔
- تقسیم شدہ نشانات کو جمع کریں اور انہیں جیگر جیسے سسٹم میں بھیجیں۔
توجہ، موضوعی فیصلہ: عام طور پر، ٹیلی میٹری ایک ایسا علاقہ ہے جس میں سروس میش کی مضبوط مداخلت ناپسندیدہ ہے۔ بنیادی معلومات اکٹھا کرنا اور پرواز کے دوران کچھ سنہری میٹرکس جیسے درخواست کی کامیابی کی شرح اور تاخیر کا پتہ لگانا ٹھیک ہے، لیکن آئیے امید کرتے ہیں کہ ہم فرینکن اسٹائن اسٹیکس کو ابھرتے ہوئے نہیں دیکھیں گے جو خصوصی نظاموں کو تبدیل کرنے کی کوشش کرتے ہیں، جن میں سے کچھ نے پہلے ہی خود کو ثابت کیا ہے اور اچھی طرح سے مطالعہ کیا ہے۔ .
15. آڈٹ
TL؛ DR: جو لوگ تاریخ کے اسباق کو بھول جاتے ہیں وہ انہیں دہرانے کے لیے برباد ہوتے ہیں۔
آڈیٹنگ سسٹم میں اہم واقعات کا مشاہدہ کرنے کا فن ہے۔ سروس میش کے معاملے میں، اس کا مطلب یہ ہو سکتا ہے کہ ٹریکنگ کس نے مخصوص سروسز کے لیے مخصوص اینڈ پوائنٹس پر درخواستیں کی ہیں، یا پچھلے مہینے میں سیکیورٹی سے متعلق کوئی واقعہ کتنی بار پیش آیا ہے۔
یہ واضح ہے کہ آڈیٹنگ کا ٹیلی میٹری سے بہت گہرا تعلق ہے۔ فرق یہ ہے کہ ٹیلی میٹری عام طور پر پیداواری صلاحیت اور تکنیکی سالمیت جیسی چیزوں سے منسلک ہوتی ہے، جب کہ آڈیٹنگ قانونی اور دیگر مسائل سے متعلق ہو سکتی ہے جو سخت تکنیکی دائرے سے باہر ہوتے ہیں (مثال کے طور پر، GDPR کی تعمیل - ڈیٹا پروٹیکشن پر EU جنرل ریگولیشن)۔
16. پیش نظارہ
TL;DR: لانگ لائیو React.js - فینسی انٹرفیس کا ایک لازوال ذریعہ۔
اس سے بہتر اصطلاح ہو سکتی ہے، لیکن میں اسے نہیں جانتا۔ میرا سیدھا مطلب ہے سروس میش یا اس کے کچھ اجزاء کی تصویری نمائندگی۔ ان تصورات میں اشارے شامل ہو سکتے ہیں جیسے اوسط تاخیر، سائڈ کار کنفیگریشن کی معلومات، صحت کی جانچ کے نتائج، اور الرٹس۔
خدمت پر مبنی ماحول میں کام کرنے میں ہز میجسٹی دی مونولیتھ کے مقابلے میں بہت زیادہ علمی بوجھ شامل ہوتا ہے۔ اس لیے علمی دباؤ کو ہر صورت کم کیا جانا چاہیے۔ بٹن پر کلک کرنے اور مطلوبہ نتیجہ حاصل کرنے کی صلاحیت کے ساتھ سروس میش کے لیے ایک سادہ گرافیکل انٹرفیس اس ٹیکنالوجی کی مقبولیت میں اضافے کے لیے فیصلہ کن ثابت ہو سکتا ہے۔
فہرست میں شامل نہیں تھے۔
میں نے اصل میں فہرست میں استعمال کے چند مزید کیسز شامل کرنے کا ارادہ کیا تھا، لیکن پھر نہ کرنے کا فیصلہ کیا۔ میرے فیصلے کی وجوہات کے ساتھ وہ یہ ہیں:
- ملٹی ڈیٹا سینٹر. میری رائے میں، یہ اتنا زیادہ استعمال کا معاملہ نہیں ہے جتنا کہ سروس میش کے استعمال کے ایک تنگ اور مخصوص علاقے یا سروس کی دریافت جیسے افعال کے کچھ سیٹ۔
- داخل ہونا اور نکلنا. یہ ایک متعلقہ علاقہ ہے، لیکن میں نے خود کو (شاید مصنوعی طور پر) "مشرق-مغربی ٹریفک" کے استعمال کے معاملے تک محدود رکھا ہے۔ داخل اور اخراج ایک الگ مضمون کے مستحق ہیں۔
حاصل يہ ہوا
ابھی کے لیے بس اتنا ہی ہے! ایک بار پھر، یہ فہرست بہت من مانی ہے اور غالباً نامکمل ہے۔ اگر آپ کو لگتا ہے کہ میں نے کچھ کھو دیا ہے یا کچھ غلط ہو گیا ہے، تو براہ کرم مجھ سے ٹویٹر پر رابطہ کریں ()۔ براہ کرم شائستگی کے اصولوں کا احترام کریں۔
مترجم سے PS
مضمون کے عنوان کی مثال مضمون کی تصویر پر مبنی ہے۔"(گریگوری میک کینن کے ذریعہ)۔ یہ ظاہر کرتا ہے کہ کس طرح ایپلی کیشنز کی کچھ فعالیت (سبز رنگ میں) ایک سروس میش میں منتقل ہوئی ہے جو ان کے درمیان باہمی ربط فراہم کرتی ہے (نیلے رنگ میں)۔
ہمارے بلاگ پر بھی پڑھیں:
- «؛ "
- «؛ "
- «'.
ماخذ: www.habr.com
