ہم انٹرپرائز سروس میش کیوں بنا رہے ہیں؟

سروس میش مائیکرو سروسز کو مربوط کرنے اور کلاؤڈ انفراسٹرکچر میں منتقلی کے لیے ایک معروف آرکیٹیکچرل پیٹرن ہے۔ آج کلاؤڈ کنٹینر کی دنیا میں اس کے بغیر کرنا کافی مشکل ہے۔ کئی اوپن سورس سروس میش نفاذ پہلے سے ہی مارکیٹ میں دستیاب ہیں، لیکن ان کی فعالیت، بھروسے اور حفاظت ہمیشہ کافی نہیں ہوتی، خاص طور پر جب ملک بھر میں بڑی مالیاتی کمپنیوں کی ضروریات کا تعلق ہو۔ اسی لیے ہم نے Sbertech میں سروس میش کو اپنی مرضی کے مطابق بنانے کا فیصلہ کیا اور اس بارے میں بات کرنا چاہتے ہیں کہ سروس میش کے بارے میں کیا اچھا ہے، کیا اچھا نہیں ہے، اور ہم اس کے بارے میں کیا کرنے جا رہے ہیں۔

سروس میش پیٹرن کی مقبولیت کلاؤڈ ٹیکنالوجیز کی مقبولیت کے ساتھ بڑھ رہی ہے۔ یہ ایک وقف شدہ انفراسٹرکچر پرت ہے جو مختلف نیٹ ورک سروسز کے درمیان تعامل کو آسان بناتی ہے۔ جدید کلاؤڈ ایپلی کیشنز سینکڑوں یا اس سے بھی ہزاروں ایسی خدمات پر مشتمل ہیں، جن میں سے ہر ایک کی ہزاروں کاپیاں ہوسکتی ہیں۔

ان خدمات کے درمیان تعامل اور انتظام سروس میش کا ایک اہم کام ہے۔ درحقیقت، یہ بہت سے پراکسیوں کا ایک نیٹ ورک ماڈل ہے، جو مرکزی طور پر منظم ہوتا ہے اور بہت مفید افعال کا ایک سیٹ انجام دیتا ہے۔

پراکسی سطح پر (ڈیٹا طیارہ):

• روٹنگ اور ٹریفک توازن کی پالیسیاں تفویض اور تقسیم کرنا
• چابیاں، سرٹیفکیٹ، ٹوکن کی تقسیم
• ٹیلی میٹری کا مجموعہ، مانیٹرنگ میٹرکس کی تخلیق
• سیکورٹی اور نگرانی کے بنیادی ڈھانچے کے ساتھ انضمام

کنٹرول ہوائی جہاز کی سطح پر:

• روٹنگ اور ٹریفک میں توازن کی پالیسیاں لاگو کرنا
• دوبارہ کوششوں اور ٹائم آؤٹ کا انتظام کرنا، "مردہ" نوڈس کا پتہ لگانا (سرکٹ بریکنگ)، انجیکشن کی خرابیوں کا انتظام کرنا اور دیگر میکانزم کے ذریعے سروس کی لچک کو یقینی بنانا
• کال کی توثیق / اجازت
• ڈراپنگ میٹرکس (مشاہدہ)

اس ٹیکنالوجی کی ترقی میں دلچسپی رکھنے والے صارفین کی حد بہت وسیع ہے - چھوٹے اسٹارٹ اپس سے لے کر بڑی انٹرنیٹ کارپوریشنز تک، مثال کے طور پر، پے پال۔

کارپوریٹ سیکٹر میں سروس میش کی ضرورت کیوں ہے؟

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

اس کے علاوہ، سروس میش سپلائرز اور صارفین کے درمیان تعلقات کو آسان بناتا ہے۔ آج، API فراہم کنندگان اور صارفین کے لیے انٹرفیس اور معاہدوں پر اپنے طور پر متفق ہونا بہت آسان ہے، بغیر کسی خصوصی انضمام کے درمیانی اور ثالث - انٹرپرائز سروس بس۔ یہ نقطہ نظر نمایاں طور پر دو اشارے کو متاثر کرتا ہے۔ مارکیٹ (ٹائم ٹو مارکیٹ) میں نئی ​​فعالیت لانے کی رفتار بڑھ جاتی ہے، لیکن ساتھ ہی حل کی قیمت بھی بڑھ جاتی ہے، کیونکہ انضمام کو آزادانہ طور پر کرنا پڑتا ہے۔ بزنس فنکشنلٹی ڈیولپمنٹ ٹیموں کے ذریعہ سروس میش کا استعمال یہاں توازن برقرار رکھنے میں مدد کرتا ہے۔ نتیجے کے طور پر، API فراہم کنندگان اپنی سروس کے ایپلیکیشن جزو پر خصوصی توجہ مرکوز کر سکتے ہیں اور اسے سروس میش میں شائع کر سکتے ہیں - API فوری طور پر تمام کلائنٹس کے لیے دستیاب ہو جائے گا، اور انضمام کا معیار پروڈکشن کے لیے تیار ہو جائے گا اور اس کے لیے کسی ایک کی ضرورت نہیں پڑے گی۔ اضافی کوڈ کی لائن۔

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

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

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

اس کے علاوہ سروس میش ہمیں ریئل ٹائم SLA کنٹرول فراہم کرتا ہے۔. تقسیم شدہ پراکسی سسٹم سروس کو ناکام ہونے کی اجازت نہیں دے گا جب کلائنٹ میں سے ایک اس کو تفویض کردہ کوٹہ سے تجاوز کرتا ہے۔ اگر API تھرو پٹ محدود ہے، تو کوئی بھی اسے بڑی تعداد میں لین دین سے مغلوب نہیں کر سکے گا: سروس میش سروس کے سامنے کھڑا ہے اور غیر ضروری ٹریفک کی اجازت نہیں دیتا ہے۔ یہ انضمام کی پرت میں آسانی سے لڑے گا، اور خدمات خود اس پر توجہ کیے بغیر کام کرتی رہیں گی۔

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

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

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

آپ کو سروس میش حسب ضرورت کیوں ہے؟

ہماری کمپنی میں، سینکڑوں سسٹمز اور ماڈیولز ایک ساتھ رہتے ہیں، اور رن ٹائم بہت بھرا ہوا ہے۔ لہذا ایک سسٹم کا ایک سادہ نمونہ دوسرے کو کال کرنا اور جواب موصول کرنا کافی نہیں ہے، کیونکہ پیداوار میں ہم مزید چاہتے ہیں۔ آپ کو انٹرپرائز سروس میش سے اور کیا چاہیے؟

ایونٹ پروسیسنگ سروس

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

یہ کافی عجیب بات ہے کہ ریموٹ پروسیجر کال (RPC) کو سروس میش کے تمام ورژنز کی حمایت حاصل ہے، لیکن وہ EDA کے ساتھ دوستانہ نہیں ہیں۔ کیونکہ سروس میش جدید تقسیم شدہ انضمام کی ایک قسم ہے، اور EDA ایک بہت ہی متعلقہ آرکیٹیکچرل پیٹرن ہے جو آپ کو کسٹمر کے تجربے کے لحاظ سے منفرد چیزیں کرنے کی اجازت دیتا ہے۔

ہماری انٹرپرائز سروس میش کو اس مسئلے کو حل کرنا چاہئے۔ اس کے علاوہ، ہم اس میں مختلف قسم کے فلٹرز اور ٹیمپلیٹس کا استعمال کرتے ہوئے گارنٹی ڈلیوری، اسٹریمنگ اور پیچیدہ ایونٹ پروسیسنگ کا نفاذ دیکھنا چاہتے ہیں۔

فائل ٹرانسفر سروس

EDA کے علاوہ، فائلوں کو منتقل کرنے کے قابل ہونا اچھا ہوگا: انٹرپرائز پیمانے پر، اکثر صرف فائلوں کا انضمام ممکن ہوتا ہے۔ خاص طور پر، ETL (ایکسٹریکٹ، ٹرانسفارم، لوڈ) آرکیٹیکچرل پیٹرن استعمال کیا جاتا ہے۔ اس میں، ایک اصول کے طور پر، ہر کوئی خصوصی طور پر فائلوں کا تبادلہ کرتا ہے: بڑا ڈیٹا استعمال کیا جاتا ہے، جسے الگ الگ درخواستوں کو آگے بڑھانا غیر عملی ہے۔ انٹرپرائز سروس میش میں فائل ٹرانسفر کو مقامی طور پر سپورٹ کرنے کی صلاحیت آپ کو وہ لچک دیتی ہے جو آپ کے کاروبار کی ضرورت ہے۔

آرکیسٹریشن سروس

بڑی تنظیموں میں تقریباً ہمیشہ مختلف ٹیمیں ہوتی ہیں جو مختلف مصنوعات بناتی ہیں۔ مثال کے طور پر، ایک بینک میں، کچھ ٹیمیں ڈپازٹ کے ساتھ کام کرتی ہیں، جب کہ دیگر لون پروڈکٹس کے ساتھ کام کرتی ہیں، اور اس طرح کے کیسز بہت زیادہ ہیں۔ یہ مختلف لوگ ہیں، مختلف ٹیمیں جو اپنی مصنوعات بناتے ہیں، اپنے API تیار کرتے ہیں اور دوسروں کو فراہم کرتے ہیں۔ اور اکثر اوقات ان سروسز کو کمپوز کرنے کے ساتھ ساتھ APIs کے سیٹ کو ترتیب وار کال کرنے کے لیے پیچیدہ منطق کو لاگو کرنے کی ضرورت ہوتی ہے۔ اس مسئلے کو حل کرنے کے لیے، آپ کو انٹیگریشن لیئر میں ایک ایسا حل درکار ہے جو اس تمام جامع منطق کو آسان بنائے (کئی APIs کو کال کرنا، درخواست کے راستے کی وضاحت کرنا وغیرہ)۔ یہ انٹرپرائز سروس میش میں آرکیسٹریشن سروس ہے۔

اے آئی اور ایم ایل

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

API گیٹ وے سروس

عام طور پر، سروس میش میں پراکسی اور خدمات ہوتی ہیں جو ایک دوسرے سے قابل اعتماد دائرہ میں بات کرتی ہیں۔ لیکن بیرونی ہم منصب بھی ہیں۔ صارفین کے اس گروپ کے سامنے APIs کی ضروریات بہت زیادہ شدید ہیں۔ ہم اس کام کو دو اہم حصوں میں تقسیم کرتے ہیں۔

• سیکورٹی. ڈی ڈی اوز، پروٹوکول کی کمزوری، ایپلی کیشنز، آپریٹنگ سسٹم وغیرہ سے متعلق مسائل۔
• پیمانہ. جب APIs کی تعداد جو کلائنٹس کو پیش کرنے کی ضرورت ہوتی ہے ہزاروں یا اس سے بھی سینکڑوں ہزاروں تک پہنچ جاتی ہے، تو APIs کے اس سیٹ کے لیے کسی قسم کے انتظامی ٹول کی ضرورت ہوتی ہے۔ آپ کو API کی مسلسل نگرانی کرنے کی ضرورت ہے: آیا وہ کام کر رہے ہیں یا نہیں، ان کی حیثیت کیا ہے، کیا ٹریفک چل رہی ہے، کون سے اعداد و شمار وغیرہ۔ ایک API گیٹ وے کو پورے عمل کو قابل انتظام اور محفوظ بناتے ہوئے اس کام کو سنبھالنا چاہیے۔ اس جزو کی بدولت، انٹرپرائز سروس میش اندرونی اور بیرونی دونوں APIs کو آسانی سے شائع کرنا سیکھتا ہے۔

مخصوص پروٹوکولز اور ڈیٹا فارمیٹس کے لیے سپورٹ سروس (AS گیٹ وے)

فی الحال، زیادہ تر سروس میش حل مقامی طور پر صرف HTTP اور HTTP2 ٹریفک کے ساتھ یا TCP/IP سطح پر کم موڈ میں کام کر سکتے ہیں۔ انٹرپرائز سروس میش بہت سے دوسرے انتہائی مخصوص ڈیٹا ٹرانسفر پروٹوکول کے ساتھ ابھر رہی ہے۔ کچھ سسٹم میسج بروکرز استعمال کر سکتے ہیں، دوسرے ڈیٹا بیس کی سطح پر مربوط ہیں۔ اگر کمپنی کے پاس SAP ہے، تو وہ اپنا انٹیگریشن سسٹم بھی استعمال کر سکتی ہے۔ مزید یہ کہ یہ سب کام کرتا ہے اور کاروبار کا ایک اہم حصہ ہے۔

آپ صرف یہ نہیں کہہ سکتے: "آئیے میراث چھوڑ دیں اور نئے سسٹم بنائیں جو سروس میش کو استعمال کر سکیں۔" تمام پرانے سسٹمز کو نئے سسٹمز سے جوڑنے کے لیے (مائیکرو سروس آرکیٹیکچر پر)، جو سسٹم سروس میش استعمال کر سکتے ہیں انہیں کسی قسم کے اڈاپٹر، انٹرمیڈیری، گیٹ وے کی ضرورت ہوگی۔ متفق ہوں، اگر یہ سروس کے ساتھ ایک باکس میں آجائے تو اچھا ہوگا۔ AC گیٹ وے کسی بھی انضمام کے آپشن کو سپورٹ کر سکتا ہے۔ ذرا تصور کریں، آپ صرف انٹرپرائز سروس میش انسٹال کرتے ہیں اور یہ آپ کو درکار تمام پروٹوکولز کے ساتھ تعامل کے لیے تیار ہے۔ یہ نقطہ نظر ہمارے لیے بہت اہم ہے۔

ہم سروس میش (انٹرپرائز سروس میش) کے کارپوریٹ ورژن کا تقریباً یہی تصور کرتے ہیں۔ بیان کردہ حسب ضرورت انضمام پلیٹ فارم کے ریڈی میڈ اوپن سورس ورژن استعمال کرنے کی کوشش کرتے وقت پیدا ہونے والے زیادہ تر مسائل کو حل کرتی ہے۔ صرف چند سال قبل متعارف کرایا گیا، سروس میش فن تعمیر کا ارتقا جاری ہے، اور ہم اس کی ترقی میں اپنا حصہ ڈالنے کے قابل ہونے پر پرجوش ہیں۔ ہمیں امید ہے کہ ہمارا تجربہ آپ کے لیے کارآمد ثابت ہوگا۔

ماخذ: www.habr.com