ارے حبر! مضمون کا ترجمہ آپ کی توجہ میں پیش کرتا ہوں۔ "سروس میش ڈیٹا ہوائی جہاز بمقابلہ کنٹرول ہوائی جہاز" مصنف میٹ کلین.

اس بار، میں نے سروس میش اجزاء، ڈیٹا پلین اور کنٹرول پلین دونوں کی تفصیل کو "چاہتا تھا اور ترجمہ کیا"۔ یہ تفصیل مجھے سب سے زیادہ قابل فہم اور دلچسپ لگ رہی تھی، اور سب سے اہم بات یہ کہ "کیا یہ بالکل ضروری ہے؟"

چونکہ پچھلے دو سالوں میں "سروس میش" کا خیال تیزی سے مقبول ہوا ہے (اصل مضمون 10 اکتوبر 2017) اور اسپیس میں شرکت کرنے والوں کی تعداد میں اضافہ ہوا ہے، میں نے پوری دنیا میں الجھن میں یکساں اضافہ دیکھا ہے۔ مختلف حلوں کا موازنہ اور ان کے برعکس کرنے کے بارے میں ٹیک کمیونٹی۔

صورتحال کا خلاصہ مندرجہ ذیل سلسلہ وار ٹویٹس سے ہوتا ہے جو میں نے جولائی میں لکھے تھے۔

سروس میش کنفیوژن #1: Linkerd ~ = Nginx ~ = Haproxy ~ = ایلچی۔ ان میں سے کوئی بھی اسٹیو کے برابر نہیں ہے۔ Istio بالکل مختلف چیز ہے۔ 1/

پہلے صرف ڈیٹا ہوائی جہاز ہیں۔ وہ خود کچھ نہیں کرتے۔ وہ کسی اور چیز کے موڈ میں ہوں گے۔ 2/

Istio ایک کنٹرول طیارے کی ایک مثال ہے جو حصوں کو آپس میں جوڑتا ہے۔ یہ ایک اور پرت ہے۔ /ختم

پچھلی ٹویٹس میں کئی مختلف پروجیکٹس (Linkerd, NGINX, HAProxy, Envoy, اور Istio) کا ذکر کیا گیا ہے، لیکن اس سے بھی اہم بات یہ ہے کہ ڈیٹا پلین، سروس میش، اور کنٹرول پلین کے عمومی تصورات کو متعارف کرایا گیا ہے۔ اس پوسٹ میں، میں ایک قدم پیچھے ہٹ کر اس بارے میں بات کروں گا کہ "ڈیٹا طیارہ" اور "کنٹرول طیارہ" کی اصطلاحات سے میرا کیا مطلب ہے ایک بہت ہی اعلیٰ سطح پر، اور پھر اس بارے میں بات کروں گا کہ ٹویٹس میں مذکور پراجیکٹس پر شرائط کیسے لاگو ہوتی ہیں۔

واقعی، سروس میش کیا ہے؟

شکل 1: سروس میش کا جائزہ

ساخت، پیکر 1 سروس میش کے تصور کو اس کی بنیادی سطح پر واضح کرتا ہے۔ چار سروس کلسٹرز (AD) ہیں۔ ہر خدمت کی مثال مقامی پراکسی سرور سے وابستہ ہے۔ تمام نیٹ ورک ٹریفک (HTTP، REST، gRPC، Redis، وغیرہ) کو کسی ایک ایپلیکیشن مثال سے مقامی پراکسی کے ذریعے مناسب بیرونی سروس کلسٹرز تک پہنچایا جاتا ہے۔ اس طرح، ایپلیکیشن کی مثال پورے نیٹ ورک سے بے خبر ہے اور صرف اس کی مقامی پراکسی سے واقف ہے۔ درحقیقت، تقسیم شدہ نظام کے نیٹ ورک کو سروس سے ہٹا دیا گیا تھا۔

ڈیٹا ہوائی جہاز

سروس میش میں، ایپلیکیشن کے لیے مقامی طور پر واقع ایک پراکسی سرور درج ذیل کام انجام دیتا ہے:

• سروس کی دریافت. آپ کی درخواست کے لیے کون سی خدمات/درخواستیں دستیاب ہیں؟
• صحت کی جانچ. کیا سروس کی دریافت کے ذریعے واپس کی گئی سروس مثالیں صحت مند اور نیٹ ورک ٹریفک کو قبول کرنے کے لیے تیار ہیں؟ اس میں فعال (مثلاً جواب/صحت کی جانچ) اور غیر فعال (مثلاً 3 مسلسل 5xx غلطیاں استعمال کرنا ایک غیر صحت مند سروس کی حالت کے اشارے کے طور پر) صحت کی جانچ دونوں شامل ہو سکتے ہیں۔
• روٹنگ. REST سروس سے "/foo" کی درخواست موصول ہونے پر، درخواست کس سروس کلسٹر کو بھیجی جائے؟
• وزن کو متوازن کرنا. روٹنگ کے دوران ایک بار سروس کلسٹر کا انتخاب ہو جانے کے بعد، کس سروس مثال کو درخواست بھیجی جائے؟ کس ٹائم آؤٹ کے ساتھ؟ کس سرکٹ توڑنے کی ترتیبات کے ساتھ؟ اگر درخواست ناکام ہو جاتی ہے تو کیا اسے دوبارہ آزمانا چاہیے؟
• تصدیق اور اجازت. آنے والی درخواستوں کے لیے، کیا ایم ٹی ایل ایس یا کسی اور طریقہ کار کا استعمال کرتے ہوئے کالنگ سروس کو خفیہ طور پر شناخت/مجاز کیا جا سکتا ہے؟ اگر یہ تسلیم شدہ/مجاز ہے تو کیا اسے سروس پر درخواست کردہ آپریشن (اینڈ پوائنٹ) کو کال کرنے کی اجازت ہے یا غیر مستند جواب واپس کیا جانا چاہیے؟
• مشاہدہ. تفصیلی اعدادوشمار، لاگز/لاگز، اور تقسیم شدہ ٹریس ڈیٹا ہر درخواست کے لیے تیار کیا جانا چاہیے تاکہ آپریٹرز تقسیم شدہ ٹریفک کے بہاؤ اور ڈیبگنگ کے مسائل کو پیدا ہوتے ہی سمجھ سکیں۔

ڈیٹا طیارہ سروس میش میں تمام پچھلے پوائنٹس کے لیے ذمہ دار ہے۔ درحقیقت، سروس کا پراکسی لوکل (سائیڈ کار) ڈیٹا ہوائی جہاز ہے۔ دوسرے لفظوں میں، ڈیٹا طیارہ مشروط طور پر ہر نیٹ ورک پیکٹ کی نشریات، فارورڈنگ اور نگرانی کے لیے ذمہ دار ہے جو کسی سروس کو یا اس سے بھیجا جاتا ہے۔

کنٹرول طیارہ

نیٹ ورک کا خلاصہ جو ایک مقامی پراکسی ڈیٹا جہاز میں فراہم کرتا ہے جادوئی ہے (؟)۔ تاہم، پراکسی اصل میں سروس B کے "/foo" روٹ کے بارے میں کیسے جانتی ہے؟ پراکسی درخواستوں سے بھرا ہوا سروس دریافت ڈیٹا کیسے استعمال کیا جا سکتا ہے؟ لوڈ بیلنسنگ، ٹائم آؤٹ، سرکٹ بریکنگ وغیرہ کے لیے پیرامیٹرز کیسے ترتیب دیئے گئے ہیں؟ آپ نیلے/سبز طریقہ یا خوبصورت ٹریفک کی منتقلی کا طریقہ استعمال کرتے ہوئے کسی ایپلیکیشن کو کیسے تعینات کرتے ہیں؟ سسٹم بھر میں تصدیق اور اجازت کی ترتیبات کون ترتیب دیتا ہے؟

مندرجہ بالا تمام اشیاء سروس میش کے کنٹرول طیارے کے کنٹرول میں ہیں. کنٹرول طیارہ الگ تھلگ اسٹیٹ لیس پراکسیوں کا ایک سیٹ لیتا ہے اور انہیں تقسیم شدہ نظام میں بدل دیتا ہے۔.

میرے خیال میں بہت سے تکنیکی ماہرین کو ڈیٹا طیارہ اور کنٹرول طیارے کے الگ الگ تصورات کو الجھا دینے کی وجہ یہ ہے کہ زیادہ تر لوگوں کے لیے ڈیٹا طیارہ واقف ہے جبکہ کنٹرول طیارہ غیر ملکی/نا سمجھ میں آتا ہے۔ ہم ایک طویل عرصے سے فزیکل نیٹ ورک روٹرز اور سوئچز کے ساتھ کام کر رہے ہیں۔ ہم سمجھتے ہیں کہ پیکٹ/درخواستوں کو پوائنٹ A سے پوائنٹ B تک جانے کی ضرورت ہے اور یہ کہ ہم ایسا کرنے کے لیے ہارڈ ویئر اور سافٹ ویئر استعمال کر سکتے ہیں۔ سافٹ ویئر پراکسیز کی نئی نسل ان ٹولز کے محض فینسی ورژن ہیں جو ہم ایک طویل عرصے سے استعمال کر رہے ہیں۔

شکل 2: انسانی کنٹرول طیارہ

تاہم، ہم ایک طویل عرصے سے کنٹرول ہوائی جہاز استعمال کر رہے ہیں، حالانکہ زیادہ تر نیٹ ورک آپریٹرز سسٹم کے اس حصے کو کسی ٹیکنالوجی کے جزو کے ساتھ منسلک نہیں کر سکتے ہیں۔ وجہ سادہ ہے:
آج کل استعمال ہونے والے زیادہ تر کنٹرول طیارے ہیں... ہم.

پر اعداد و شمار 2 دکھاتا ہے جسے میں "ہیومن کنٹرول ہوائی جہاز" کہتا ہوں۔ اس قسم کی تعیناتی میں، جو کہ اب بھی بہت عام ہے، ایک ممکنہ طور پر بدمزاج انسانی آپریٹر جامد کنفیگریشنز تخلیق کرتا ہے - ممکنہ طور پر اسکرپٹ کے ذریعے - اور انہیں کسی خاص عمل کے ذریعے تمام پراکسیوں پر تعینات کرتا ہے۔ اس کے بعد پراکسی اس کنفیگریشن کو استعمال کرنا شروع کر دیتے ہیں اور اپ ڈیٹ کردہ سیٹنگز کا استعمال کرتے ہوئے ڈیٹا پلین پر کارروائی کرنا شروع کر دیتے ہیں۔

شکل 3: جدید سروس میش کنٹرول ہوائی جہاز

پر اعداد و شمار 3 سروس میش کا "توسیع شدہ" کنٹرول ہوائی جہاز دکھاتا ہے۔ یہ مندرجہ ذیل حصوں پر مشتمل ہے:

• انسان: اب بھی ایک شخص ہے (امید ہے کہ کم غصہ ہے) جو پورے نظام کے حوالے سے اعلیٰ سطح کے فیصلے کرتا ہے۔
• ہوائی جہاز کے UI کو کنٹرول کریں۔: ایک شخص سسٹم کو کنٹرول کرنے کے لیے کسی قسم کے یوزر انٹرفیس سے تعامل کرتا ہے۔ یہ ویب پورٹل، کمانڈ لائن ایپلیکیشن (CLI) یا کوئی دوسرا انٹرفیس ہو سکتا ہے۔ یوزر انٹرفیس کا استعمال کرتے ہوئے، آپریٹر کو عالمی نظام کی ترتیب کے پیرامیٹرز تک رسائی حاصل ہے جیسے:
  • تعیناتی کنٹرول، نیلے/سبز اور/یا ٹریفک کی بتدریج منتقلی۔
  • تصدیق اور اجازت کے اختیارات
  • روٹنگ ٹیبل کی وضاحتیں، مثال کے طور پر جب ایپلیکیشن A "/foo" کے بارے میں معلومات کی درخواست کرتی ہے کہ کیا ہوتا ہے۔
  • لوڈ بیلنس کی ترتیبات، جیسے ٹائم آؤٹ، دوبارہ کوششیں، سرکٹ توڑنے کی ترتیبات وغیرہ۔
• کام کا بوجھ شیڈولر: خدمات بنیادی ڈھانچے پر کسی قسم کے شیڈولنگ/آرکیسٹریشن سسٹم کے ذریعے چلائی جاتی ہیں، جیسے کہ Kubernetes یا Nomad۔ شیڈولر اپنی مقامی پراکسی کے ساتھ سروس کو لوڈ کرنے کا ذمہ دار ہے۔
• سروس کی دریافت. جب شیڈیولر سروس کی مثالیں شروع اور روکتا ہے، تو یہ سروس دریافت کے نظام کو صحت کی حالت کی اطلاع دیتا ہے۔
• سائیڈ کار پراکسی کنفیگریشن APIs : مقامی پراکسی آپریٹر کی مداخلت کے بغیر بالآخر ایک مستقل ماڈل کا استعمال کرتے ہوئے نظام کے مختلف اجزاء سے متحرک طور پر حالت نکالتی ہیں۔ پورا نظام، جو اس وقت چل رہے تمام سروس انسٹینسز اور مقامی پراکسی سرورز پر مشتمل ہے، بالآخر ایک ماحولیاتی نظام میں بدل جاتا ہے۔ ایلچی کا یونیورسل ڈیٹا پلین API اس کی ایک مثال ہے کہ یہ عملی طور پر کیسے کام کرتا ہے۔

بنیادی طور پر، کنٹرول ہوائی جہاز کا مقصد اس پالیسی کو ترتیب دینا ہے جو بالآخر ڈیٹا ہوائی جہاز کے ذریعہ قبول کیا جائے گا۔ زیادہ جدید کنٹرول والے طیارے آپریٹر سے کچھ سسٹمز کے مزید حصوں کو ہٹا دیں گے اور انہیں کم دستی آپریشن کی ضرورت ہوگی، بشرطیکہ وہ صحیح طریقے سے کام کریں!...

ڈیٹا طیارہ اور کنٹرول طیارہ۔ ڈیٹا ہوائی جہاز بمقابلہ کنٹرول ہوائی جہاز کا خلاصہ

• سروس میش ڈیٹا ہوائی جہاز: سسٹم میں موجود ہر پیکٹ/درخواست کو متاثر کرتا ہے۔ ایپلیکیشن/سروس کی دریافت، صحت کی جانچ، روٹنگ، لوڈ بیلنسنگ، تصدیق/تصدیق اور مشاہدے کے لیے ذمہ دار۔
• سروس میش کنٹرول ہوائی جہاز: سروس نیٹ ورک کے اندر چلنے والے تمام ڈیٹا طیاروں کے لیے پالیسی اور کنفیگریشن فراہم کرتا ہے۔ سسٹم پر کسی بھی پیکجز/درخواستوں کو ہاتھ نہیں لگاتا۔ کنٹرول طیارہ تمام ڈیٹا طیاروں کو تقسیم شدہ نظام میں بدل دیتا ہے۔

موجودہ منصوبے کی زمین کی تزئین کی

اوپر کی وضاحت کو سمجھنے کے بعد، آئیے سروس میش پروجیکٹ کی موجودہ حالت کو دیکھتے ہیں۔

• ڈیٹا ہوائی جہاز: Linkerd, NGINX, HAProxy, Envoy, Traefik
• کنٹرول طیارے: اسٹیو، نیلسن، اسمارٹ اسٹیک

اوپر دیے گئے ہر ایک حل کے گہرائی سے تجزیہ کرنے کے بجائے، میں مختصراً ان نکات پر توجہ دوں گا جن کے بارے میں مجھے یقین ہے کہ اس وقت ماحولیاتی نظام میں بہت زیادہ الجھنیں پیدا ہو رہی ہیں۔

Linkerd 2016 کے اوائل میں سروس میش کے لیے پہلے ڈیٹا پلین پراکسی سرورز میں سے ایک تھا اور اس نے سروس میش ڈیزائن ماڈل پر بیداری اور توجہ بڑھانے کا شاندار کام کیا ہے۔ اس کے تقریباً 6 ماہ بعد، ایلچی نے Linkerd میں شمولیت اختیار کی (حالانکہ وہ 2015 کے آخر سے Lyft کے ساتھ تھا)۔ Linkerd اور Envoy وہ دو منصوبے ہیں جن کا ذکر اکثر سروس میشز پر بحث کرتے وقت کیا جاتا ہے۔

Istio کا اعلان مئی 2017 میں کیا گیا تھا۔ اسٹیو پروجیکٹ کے اہداف اس میں دکھائے گئے توسیعی کنٹرول طیارے سے بہت ملتے جلتے ہیں۔ اعداد و شمار 3. ایلچی برائے اسٹیو ڈیفالٹ پراکسی ہے۔ اس طرح، Istio کنٹرول طیارہ ہے، اور ایلچی ڈیٹا طیارہ ہے۔ تھوڑے ہی عرصے میں، اسٹیو نے کافی جوش پیدا کیا، اور دوسرے ڈیٹا پلینز نے ایلچی کے متبادل کے طور پر ضم ہونا شروع کر دیا (Linkerd اور NGINX دونوں نے Istio کے ساتھ انضمام کا مظاہرہ کیا)۔ حقیقت یہ ہے کہ ایک ہی کنٹرول ہوائی جہاز کے اندر مختلف ڈیٹا طیاروں کا استعمال کیا جا سکتا ہے اس کا مطلب یہ ہے کہ کنٹرول ہوائی جہاز اور ڈیٹا ہوائی جہاز ضروری طور پر مضبوطی سے جڑے ہوئے نہیں ہیں۔ ایک API جیسا کہ Envoy's generic data plane API نظام کے دو حصوں کے درمیان ایک پل بنا سکتا ہے۔

نیلسن اور اسمارٹ اسٹیک کنٹرول طیارے اور ڈیٹا جہاز کی علیحدگی کو مزید واضح کرنے میں مدد کرتے ہیں۔ نیلسن ایلچی کو اپنے پراکسی کے طور پر استعمال کرتا ہے اور HashiCorp اسٹیک پر مبنی سروس میش کے لیے ایک قابل اعتماد کنٹرول طیارہ بناتا ہے، یعنی خانہ بدوش وغیرہ SmartStack شاید سروس میش کی ایک نئی لہر میں سے پہلی تھی۔ SmartStack HAProxy یا NGINX کے ارد گرد ایک کنٹرول طیارہ بناتا ہے، جو ڈیٹا جہاز سے سروس میش سے کنٹرول ہوائی جہاز کو ڈیکپل کرنے کی صلاحیت کو ظاہر کرتا ہے۔

سروس میش کے ساتھ مائیکرو سروس آرکیٹیکچر زیادہ سے زیادہ توجہ حاصل کر رہا ہے (صحیح طور پر!)، اور زیادہ سے زیادہ پروجیکٹس اور وینڈرز اس سمت میں کام کرنا شروع کر رہے ہیں۔ اگلے چند سالوں میں ہم ڈیٹا پلین اور کنٹرول پلین دونوں میں بہت سی جدتیں دیکھیں گے اور ساتھ ہی مختلف اجزاء کے مزید اختلاط بھی دیکھیں گے۔ بالآخر، مائیکرو سرویس فن تعمیر کو آپریٹر کے لیے زیادہ شفاف اور جادوئی (؟) بننا چاہیے۔
امید ہے کہ کم اور کم چڑچڑاپن۔

اہم نکات

• سروس میش دو مختلف حصوں پر مشتمل ہوتا ہے: ڈیٹا ہوائی جہاز اور کنٹرول ہوائی جہاز۔ دونوں اجزاء کی ضرورت ہے، اور ان کے بغیر نظام کام نہیں کرے گا۔
• ہر کوئی کنٹرول طیارے سے واقف ہے، اور اس وقت، کنٹرول طیارہ آپ ہو سکتا ہے!
• تمام ڈیٹا ہوائی جہاز خصوصیات، کارکردگی، ترتیب، اور توسیع پذیری پر ایک دوسرے سے مقابلہ کرتے ہیں۔
• تمام کنٹرول طیارے خصوصیات، ترتیب، توسیع پذیری، اور استعمال میں آسانی میں ایک دوسرے سے مقابلہ کرتے ہیں۔
• ایک کنٹرول ہوائی جہاز میں صحیح خلاصہ اور APIs شامل ہوسکتے ہیں تاکہ متعدد ڈیٹا طیاروں کو استعمال کیا جاسکے۔

ماخذ: www.habr.com