19 ستمبر کو ماسکو میں پہلی موضوعاتی میٹنگ HUG (Highload++ User Group)، جو مائیکرو سروسز کے لیے وقف تھی۔ ایک پریزنٹیشن تھی "آپریٹنگ مائیکرو سروسز: سائز کے معاملات، یہاں تک کہ اگر آپ کے پاس کبرنیٹس بھی ہیں،" جس میں ہم نے مائیکرو سروسز فن تعمیر کے ساتھ آپریٹنگ پروجیکٹس میں فلانٹ کے وسیع تجربے کا اشتراک کیا۔ سب سے پہلے، یہ ان تمام ڈویلپرز کے لیے مفید ہو گا جو اپنے موجودہ یا مستقبل کے پروجیکٹ میں اس طریقہ کار کو استعمال کرنے کے بارے میں سوچ رہے ہیں۔
متعارف کروا رہا ہے۔ (50 منٹ، مضمون سے کہیں زیادہ معلوماتی)، نیز متن کی شکل میں اس سے اہم اقتباس۔
نوٹ: اس پوسٹ کے آخر میں ویڈیو اور پریزنٹیشن بھی دستیاب ہے۔
تعارف
عام طور پر ایک اچھی کہانی کا آغاز، ایک مرکزی پلاٹ اور ایک حل ہوتا ہے۔ یہ رپورٹ ایک تمہید کی طرح ہے، اور اس میں ایک المناک ہے۔ یہ نوٹ کرنا بھی ضروری ہے کہ یہ مائیکرو سروسز کے بارے میں باہر کا نظریہ فراہم کرتا ہے۔ آپریٹنگ.
میں اس گراف سے شروع کروں گا، جس کا مصنف (2015 میں) مارٹن فولر:
یہ ظاہر کرتا ہے کہ کس طرح، یک سنگی استعمال کی صورت میں جو ایک خاص قدر تک پہنچ جاتی ہے، پیداواری صلاحیت میں کمی آنا شروع ہو جاتی ہے۔ مائیکرو سروسز اس لحاظ سے مختلف ہیں کہ ان کے ساتھ ابتدائی پیداواری صلاحیت کم ہے، لیکن جیسے جیسے پیچیدگی بڑھتی ہے، کارکردگی میں انحطاط ان کے لیے اتنا قابل توجہ نہیں ہوتا ہے۔
میں Kubernetes استعمال کرنے کے معاملے کے لیے اس گراف میں اضافہ کروں گا:
مائیکرو سروسز والی ایپلیکیشن کیوں بہتر ہے؟ کیونکہ اس طرح کا فن تعمیر فن تعمیر کے لیے سنجیدہ تقاضوں کو پیش کرتا ہے، جس کے نتیجے میں کوبرنیٹس کی صلاحیتوں کا مکمل احاطہ کیا جاتا ہے۔ دوسری طرف، اس میں سے کچھ فعالیت یک سنگی کے لیے کارآمد ہو گی، خاص طور پر اس لیے کہ آج کا عام یک سنگی بالکل یک سنگی نہیں ہے (تفصیلات بعد میں رپورٹ میں ہوں گی)۔
جیسا کہ آپ دیکھ سکتے ہیں، فائنل گراف (جب یک سنگی اور مائیکرو سروس دونوں ایپلیکیشنز Kubernetes کے ساتھ انفراسٹرکچر میں ہوں) اصل گراف سے بہت مختلف نہیں ہے۔ اگلا ہم Kubernetes کے استعمال سے چلنے والی ایپلی کیشنز کے بارے میں بات کریں گے۔
مفید اور نقصان دہ مائیکرو سروسز
اور یہاں بنیادی خیال ہے:
کیا ہے؟ عام microservice فن تعمیر؟ اس سے آپ کو حقیقی فوائد حاصل ہونے چاہئیں، آپ کے کام کی کارکردگی میں اضافہ ہونا چاہیے۔ اگر ہم گراف پر واپس جائیں تو یہ ہے:
اگر تم اسے بلاؤ مفید، پھر گراف کے دوسری طرف ہوگا۔ نقصان دہ مائیکرو سروسز (کام میں مداخلت):
"اصل خیال" کی طرف لوٹنا: کیا مجھے اپنے تجربے پر بالکل بھروسہ کرنا چاہیے؟ اس سال کے آغاز سے میں نے دیکھا ہے۔ 85 منصوبے. ان میں سے سبھی مائیکرو سروسز نہیں تھے (ان میں سے تقریباً ایک تہائی سے آدھے تک ایسا فن تعمیر تھا)، لیکن یہ اب بھی ایک بڑی تعداد ہے۔ ہم (Flant کمپنی) بطور آؤٹ سورس چھوٹی کمپنیوں (5 ڈویلپرز کے ساتھ) اور بڑی کمپنیوں (~ 500 ڈویلپرز کے ساتھ) دونوں میں تیار کردہ ایپلیکیشنز کی وسیع اقسام کو دیکھنے کا انتظام کرتے ہیں۔ ایک اضافی فائدہ یہ ہے کہ ہم ان ایپلی کیشنز کو سالوں میں زندہ اور تیار ہوتے دیکھتے ہیں۔
مائیکرو سروسز کیوں؟
مائیکرو سروسز کے فوائد کے بارے میں سوال ہے۔ پہلے ہی ذکر کردہ مارٹن فولر سے:
- ماڈیولرٹی کی واضح حدود؛
- آزاد تعیناتی؛
- ٹیکنالوجی کے انتخاب کی آزادی۔
میں نے سافٹ ویئر آرکیٹیکٹس اور ڈویلپرز سے بہت بات کی ہے اور پوچھا ہے کہ انہیں مائیکرو سروسز کی ضرورت کیوں ہے۔ اور میں نے ان کی توقعات کی فہرست بنائی۔ یہاں کیا ہوا ہے:
اگر ہم کچھ نکات کو "احساسات میں" بیان کرتے ہیں تو:
- ماڈیولز کی واضح حدود: یہاں ہمارے پاس ایک خوفناک یک سنگی ہے، اور اب ہر چیز کو گٹ ریپوزٹریز میں صاف ستھرا ترتیب دیا جائے گا، جس میں ہر چیز "شیلفز پر" ہے، گرم اور نرم کو ملا نہیں ہے؛
- تعیناتی کی آزادی: ہم آزادانہ طور پر خدمات کو رول آؤٹ کرنے کے قابل ہو جائیں گے تاکہ ترقی تیزی سے ہو (متوازی طور پر نئی خصوصیات شائع کریں)؛
- ترقی کی آزادی: ہم یہ مائیکرو سروس ایک ٹیم/ڈیولپر کو دے سکتے ہیں، اور وہ ایک دوسرے کو، جس کی بدولت ہم تیزی سے ترقی کر سکتے ہیں۔
- боزیادہ وشوسنییتا: اگر جزوی تنزلی ہوتی ہے (20 میں سے ایک مائیکرو سروس گر جاتی ہے)، تو صرف ایک بٹن کام کرنا بند کر دے گا، اور نظام مجموعی طور پر کام کرتا رہے گا۔
عام (نقصان دہ) مائیکرو سروس فن تعمیر
یہ بتانے کے لیے کہ حقیقت ہماری توقع کے مطابق کیوں نہیں ہے، میں پیش کروں گا۔ اجتماعی بہت سے مختلف منصوبوں کے تجربے پر مبنی مائیکرو سروس فن تعمیر کی تصویر۔
ایک مثال ایک خلاصہ آن لائن اسٹور ہو گا جو ایمیزون یا کم از کم اوزون کے ساتھ مقابلہ کرنے جا رہا ہے۔ اس کا مائیکرو سروس فن تعمیر اس طرح لگتا ہے:
وجوہات کے مجموعہ کے لیے، یہ مائیکرو سروسز مختلف پلیٹ فارمز پر لکھی گئی ہیں:
چونکہ ہر مائیکرو سروس کو خود مختاری ہونی چاہیے، ان میں سے بہت سے کو اپنے ڈیٹا بیس اور کیش کی ضرورت ہوتی ہے۔ حتمی فن تعمیر مندرجہ ذیل ہے:
اس کے نتائج کیا ہیں؟
فولر کے پاس بھی یہ ہے۔ - مائیکرو سروسز استعمال کرنے کے لیے "ادائیگی" کے بارے میں:
اور ہم دیکھیں گے کہ آیا ہماری توقعات پوری ہوئیں۔
ماڈیولز کی واضح حدود...
لیکن ہمیں اصل میں کتنی مائیکرو سروسز کو ٹھیک کرنے کی ضرورت ہے؟تبدیلی کو رول کرنے کے لیے؟ کیا ہم یہ بھی اندازہ لگا سکتے ہیں کہ تقسیم شدہ ٹریسر کے بغیر سب کچھ کیسے کام کرتا ہے (آخر کار، کسی بھی درخواست پر نصف مائیکرو سروسز کے ذریعے کارروائی کی جاتی ہے)؟
ایک نمونہ ہے""، اور یہاں یہ گندگی کی تقسیم شدہ گانٹھ نکلی۔ اس کی تصدیق کرنے کے لیے، درخواستیں کیسے جاتی ہیں اس کی ایک تخمینی مثال یہ ہے:
تعیناتی کی آزادی...
تکنیکی طور پر، یہ حاصل کر لیا گیا ہے: ہم ہر مائیکرو سروس کو الگ الگ کر سکتے ہیں۔ لیکن عملی طور پر آپ کو اس بات کو ذہن میں رکھنے کی ضرورت ہے کہ یہ ہمیشہ باہر آتا ہے۔ بہت سی مائیکرو سروسز، اور ہمیں اکاؤنٹ میں لینے کی ضرورت ہے۔ ان کے رول آؤٹ کا حکم. اچھے طریقے سے، ہمیں عام طور پر الگ سرکٹ میں جانچنے کی ضرورت ہوتی ہے کہ آیا ہم ریلیز کو صحیح ترتیب میں کر رہے ہیں۔
ٹیکنالوجی کے انتخاب کی آزادی...
وہ ہے. بس یاد رکھیں کہ آزادی اکثر لاقانونیت سے جڑی ہوتی ہے۔ یہاں یہ بہت اہم ہے کہ صرف ان کے ساتھ "کھیلنے" کے لیے ٹیکنالوجیز کا انتخاب نہ کریں۔
ترقی کی آزادی...
پوری ایپلیکیشن (بہت سارے اجزاء کے ساتھ) کے لیے ٹیسٹ لوپ کیسے بنایا جائے؟ لیکن آپ کو اب بھی اسے اپ ٹو ڈیٹ رکھنے کی ضرورت ہے۔ یہ سب اس حقیقت کی طرف جاتا ہے۔ ٹیسٹ سرکٹس کی اصل تعدادجس میں ہم اصولی طور پر شامل ہو سکتے ہیں، کم سے کم نکلا.
یہ سب کچھ مقامی طور پر تعینات کرنے کے بارے میں کیا خیال ہے؟... یہ پتہ چلتا ہے کہ اکثر ڈویلپر اپنا کام آزادانہ طور پر کرتا ہے، لیکن "بے ترتیب"، کیونکہ اسے سرکٹ کے ٹیسٹ کے لیے آزاد ہونے تک انتظار کرنے پر مجبور کیا جاتا ہے۔
الگ اسکیلنگ...
ہاں، لیکن یہ استعمال شدہ DBMS کے علاقے میں محدود ہے۔ دی گئی فن تعمیر کی مثال میں، کیسینڈرا کو پریشانی نہیں ہوگی، لیکن MySQL اور PostgreSQL ہوں گے۔
Боزیادہ وشوسنییتا...
حقیقت میں نہ صرف ایک مائیکرو سروس کی ناکامی اکثر پورے نظام کے درست کام کو توڑ دیتی ہے، بلکہ ایک نیا مسئلہ بھی ہے: ہر مائیکرو سروس کو فالٹ ٹولرنٹ بنانا بہت مشکل ہے۔. چونکہ مائیکرو سروسز مختلف ٹیکنالوجیز (میمکیچ، ریڈیس وغیرہ) استعمال کرتی ہیں، ہر ایک کے لیے آپ کو ہر چیز کے بارے میں سوچنے اور اس پر عمل درآمد کرنے کی ضرورت ہے، جو یقیناً ممکن ہے، لیکن اس کے لیے بہت زیادہ وسائل درکار ہیں۔
لوڈ کی پیمائش...
یہ واقعی اچھا ہے۔
مائیکرو سروسز کی "ہلکی پن"...
ہمارے پاس نہ صرف بہت بڑا ہے۔ نیٹ ورک اوور ہیڈ (DNS کے لیے درخواستیں کئی گنا بڑھ رہی ہیں، وغیرہ)، لیکن ہم نے شروع کیے گئے بہت سے ذیلی سوالات کی وجہ سے بھی نقل ڈیٹا (اسٹور کیچز)، جس کی وجہ سے کافی مقدار میں اسٹوریج ہوا۔
اور یہاں ہماری توقعات کو پورا کرنے کا نتیجہ ہے:
لیکن یہ سب نہیں ہے!
کیونکہ:
- زیادہ امکان ہے کہ ہمیں ایک پیغام بس کی ضرورت ہوگی۔
- صحیح وقت پر مستقل بیک اپ کیسے بنایا جائے؟ صرف ایک حقیقی اس کے لیے ٹریفک بند کرنے کا آپشن ہے۔ لیکن پیداوار میں یہ کیسے کریں؟
- اگر ہم کئی خطوں کو سپورٹ کرنے کی بات کر رہے ہیں، تو ان میں سے ہر ایک میں پائیداری کو منظم کرنا بہت محنت طلب کام ہے۔
- مرکزی تبدیلیاں کرنے کا مسئلہ پیدا ہوتا ہے۔ مثال کے طور پر، اگر ہمیں پی ایچ پی ورژن کو اپ ڈیٹ کرنے کی ضرورت ہے، تو ہمیں ہر ایک مخزن (اور ان میں سے درجنوں ہیں) کا عہد کرنا ہوگا۔
- آپریشنل پیچیدگی میں اضافہ، آف ہینڈ، ایکسپونینشنل ہے۔
اس سب کا کیا کیا جائے؟
یک سنگی درخواست کے ساتھ شروع کریں۔. فولر کا تجربہ کہ تقریباً تمام کامیاب مائیکرو سروس ایپلی کیشنز ایک یک سنگی کے طور پر شروع ہوئیں جو بہت بڑی ہو گئیں اور پھر ٹوٹ گئیں۔ ایک ہی وقت میں، مائیکرو سروسز کے طور پر بنائے گئے تقریباً تمام سسٹمز کو جلد یا بدیر سنگین مسائل کا سامنا کرنا پڑا۔
ایک اور قیمتی سوچ یہ ہے کہ مائیکرو سروس آرکیٹیکچر والے پروجیکٹ کے کامیاب ہونے کے لیے، آپ کو اچھی طرح جاننا ضروری ہے اور موضوع کا علاقہ، اور مائیکرو سروسز بنانے کا طریقہ. اور سبجیکٹ ایریا سیکھنے کا بہترین طریقہ یہ ہے کہ یک سنگی بنانا۔
لیکن کیا ہوگا اگر ہم پہلے ہی اس حالت میں ہیں؟
کسی بھی مسئلے کو حل کرنے کا پہلا قدم یہ ہے کہ اس سے اتفاق کیا جائے اور یہ سمجھ لیا جائے کہ یہ ایک مسئلہ ہے، جس کا ہم مزید شکار نہیں ہونا چاہتے۔
اگر، ایک حد سے زیادہ بڑھے ہوئے یک سنگی کی صورت میں (جب ہمارے پاس اس کے لیے اضافی وسائل خریدنے کا موقع ختم ہو جاتا ہے)، تو ہم اسے کاٹ دیتے ہیں، تو اس صورت میں اس کے برعکس کہانی نکلتی ہے: جب ضرورت سے زیادہ مائیکرو سروسز مدد نہیں کرتیں، بلکہ رکاوٹ بنتی ہیں۔ اضافی کاٹ دیں اور بڑا کریں!
مثال کے طور پر، اوپر زیر بحث اجتماعی تصویر کے لیے...
انتہائی قابل اعتراض مائیکرو سروسز سے چھٹکارا حاصل کریں:
فرنٹ اینڈ جنریشن کے لیے ذمہ دار تمام مائیکرو سروسز کو یکجا کریں:
... ایک مائیکرو سروس میں، ایک میں لکھا گیا (جدید اور عام، جیسا کہ آپ خود سوچتے ہیں) زبان/فریم ورک:
اس میں ایک ORM (ایک DBMS) اور پہلے کچھ ایپلی کیشنز ہوں گی:
... لیکن عام طور پر آپ مندرجہ ذیل نتیجہ حاصل کرتے ہوئے وہاں بہت کچھ منتقل کر سکتے ہیں:
مزید برآں، Kubernetes میں ہم یہ سب الگ الگ مثالوں میں چلاتے ہیں، جس کا مطلب ہے کہ ہم اب بھی بوجھ کی پیمائش کر سکتے ہیں اور انہیں الگ سے پیمانہ کر سکتے ہیں۔
مختصر کرنے کے لئے
بڑی تصویر کو دیکھیں۔ اکثر، مائیکرو سروسز کے ساتھ یہ تمام مسائل پیدا ہوتے ہیں کیونکہ کسی نے اپنا کام لیا، لیکن "مائیکرو سروسز کے ساتھ کھیلنا" چاہتا تھا۔
لفظ "مائیکرو سروسز" میں "مائیکرو" حصہ بے کار ہے۔. وہ صرف اس لیے "مائیکرو" ہیں کیونکہ وہ ایک بہت بڑے یک سنگی سے چھوٹے ہیں۔ لیکن ان کو چھوٹی چیز نہ سمجھیں۔
اور حتمی سوچ کے لیے، آئیے اصل چارٹ کی طرف لوٹتے ہیں:
اس پر لکھا ہوا نوٹ (اوپر سے دایاں) اس حقیقت پر ابلتا ہے آپ کے پروجیکٹ کو بنانے والی ٹیم کی مہارتیں ہمیشہ بنیادی ہوتی ہیں۔ - وہ مائیکرو سروسز اور یک سنگی کے درمیان آپ کی پسند میں کلیدی کردار ادا کریں گے۔ اگر ٹیم کے پاس کافی مہارت نہیں ہے، لیکن وہ مائیکرو سروسز بنانا شروع کر دیتی ہے، تو کہانی یقینی طور پر مہلک ہوگی۔
ویڈیوز اور سلائیڈز
تقریر کی ویڈیو (~50 منٹ؛ بدقسمتی سے، یہ دیکھنے والوں کے بے شمار جذبات کو بیان نہیں کرتا، جس نے بڑی حد تک رپورٹ کے مزاج کا تعین کیا، لیکن یہ اس طرح ہے):
رپورٹ کی پیشکش:
PS
ہمارے بلاگ پر دیگر رپورٹس:
- «» (دمتری اسٹولیاروف؛ 28 مئی 2018 کو روٹ کانف میں);
- «» (دمتری اسٹولیاروف؛ 7 نومبر 2017 ہائی لوڈ++ پر);
- «» (دمتری اسٹولیاروف؛ 6 جون، 2017 روٹ کانف میں);
- «» (دمتری اسٹولیاروف؛ 8 نومبر 2016 ہائی لوڈ++ پر);
- «» (دمتری اسٹولیاروف؛ 31 مئی 2016 کو روٹ کانف میں).
آپ کو درج ذیل اشاعتوں میں بھی دلچسپی ہو سکتی ہے:
- «؛ "
- «؛ "
- «'.
ماخذ: www.habr.com