ہیلو! میرا نام Vadim Madison ہے، میں Avito سسٹم پلیٹ فارم کی ترقی کی قیادت کرتا ہوں۔ یہ ایک سے زیادہ بار کہا گیا ہے کہ ہم کس طرح کمپنی میں یک سنگی فن تعمیر سے مائیکرو سروسز کی طرف بڑھ رہے ہیں۔ یہ بتانے کا وقت ہے کہ ہم نے مائیکرو سروسز سے زیادہ سے زیادہ فائدہ اٹھانے اور خود کو ان میں گم ہونے سے روکنے کے لیے اپنے بنیادی ڈھانچے کو کس طرح تبدیل کیا ہے۔ PaaS یہاں ہماری مدد کیسے کرتا ہے، کس طرح ہم نے تعیناتی کو آسان بنایا اور مائیکرو سروس کی تخلیق کو ایک کلک تک کم کیا - آگے پڑھیں۔ جو کچھ میں ذیل میں لکھتا ہوں وہ Avito میں مکمل طور پر نافذ نہیں ہوتا ہے، اس میں سے کچھ یہ ہے کہ ہم اپنے پلیٹ فارم کو کیسے تیار کرتے ہیں۔

(اور اس مضمون کے آخر میں، میں مائیکرو سروس آرکیٹیکچر کے ماہر کرس رچرڈسن کے تین روزہ سیمینار میں شرکت کے موقع کے بارے میں بات کروں گا)۔

ہم مائیکرو سروسز پر کیسے آئے

Avito دنیا کی سب سے بڑی کلاسیفائیڈ سائٹس میں سے ایک ہے؛ اس پر روزانہ 15 ملین سے زیادہ نئے اشتہارات شائع ہوتے ہیں۔ ہمارا بیک اینڈ فی سیکنڈ 20 ہزار سے زیادہ درخواستیں قبول کرتا ہے۔ ہمارے پاس اس وقت کئی سو مائیکرو سروسز ہیں۔

ہم کئی سالوں سے ایک مائیکرو سروس فن تعمیر کر رہے ہیں۔ کس طرح بالکل - تفصیل میں ہمارے ساتھیوں بتایا RIT++ 2017 میں ہمارے سیکشن میں۔ CodeFest 2017 میں (دیکھیں۔ ویڈیو)، Sergey Orlov اور Mikhail Prokopchuk نے تفصیل سے بتایا کہ ہمیں مائیکرو سروسز میں منتقلی کی ضرورت کیوں پڑی اور یہاں Kubernetes نے کیا کردار ادا کیا۔ ٹھیک ہے، اب ہم اسکیلنگ کے اخراجات کو کم کرنے کے لیے سب کچھ کر رہے ہیں جو اس طرح کے فن تعمیر میں شامل ہیں۔

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

اب PaaS CLI یوٹیلیٹی میں، ایک کمانڈ کے ساتھ ایک نئی سروس بنائی جاتی ہے، اور ایک نیا ڈیٹا بیس مزید دو کے ساتھ شامل کیا جاتا ہے اور اسٹیج پر تعینات کیا جاتا ہے۔

"مائیکرو سروس فریگمنٹیشن" کے دور پر کیسے قابو پایا جائے

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

اس کے علاوہ، مائیکرو سرویس فن تعمیر کے موثر ہونے کے لیے، بہت سے عمل کو قائم کرنے کی ضرورت ہے، یعنی:

لاگنگ؛
ٹریسنگ کی درخواست (جیگر)؛
غلطی کا مجموعہ (سینٹری)؛
• اسٹیٹس، پیغامات، کبرنیٹس کے واقعات (ایونٹ اسٹریم پروسیسنگ)؛
• ریس کی حد / سرکٹ بریکر (آپ Hystrix استعمال کر سکتے ہیں)؛
• سروس کنیکٹیویٹی کا کنٹرول (ہم نیٹرمیش استعمال کرتے ہیں)؛
نگرانی (Grafana)؛
• اسمبلی (ٹیم سٹی)؛
• مواصلات اور اطلاع (سست، ای میل)؛
• ٹاسک ٹریکنگ؛ (جیرا)
• دستاویزات کی تیاری۔

اس بات کو یقینی بنانے کے لیے کہ نظام اپنی سالمیت سے محروم نہ ہو اور اس کے پیمانے پر موثر رہے، ہم نے Avito میں مائیکرو سروسز کی تنظیم پر دوبارہ غور کیا۔

ہم کس طرح مائیکرو سروسز کا نظم کرتے ہیں۔

کئی Avito مائیکرو سروسز کے درمیان ایک متحد "پارٹی پالیسی" کو نافذ کرنے میں درج ذیل مدد:

• بنیادی ڈھانچے کو تہوں میں تقسیم کرنا؛
• پلیٹ فارم بطور سروس (PaaS) تصور؛
• مائیکرو سروسز کے ساتھ ہونے والی ہر چیز کی نگرانی کرنا۔

بنیادی ڈھانچے کی تجریدی تہوں میں تین پرتیں شامل ہیں۔ آئیے اوپر سے نیچے تک چلتے ہیں۔

A. ٹاپ - سروس میش۔ سب سے پہلے ہم نے Istio کو آزمایا، لیکن پتہ چلا کہ یہ بہت زیادہ وسائل استعمال کرتا ہے، جو ہماری جلدوں کے لیے بہت مہنگا ہے۔ لہذا، فن تعمیر کی ٹیم میں سینئر انجینئر الیگزینڈر لوکیانچینکو نے اپنا حل تیار کیا - نیترمیش (اوپن سورس میں دستیاب ہے)، جسے ہم فی الحال پروڈکشن میں استعمال کرتے ہیں اور جو اسٹیو سے کئی گنا کم وسائل استعمال کرتا ہے (لیکن وہ سب کچھ نہیں کرتا جس پر اسٹیو فخر کر سکتا ہے)۔
B. میڈیم - Kubernetes. ہم اس پر مائیکرو سروسز تعینات اور چلاتے ہیں۔
C. نیچے - ننگی دھات۔ ہم بادلوں یا OpenStack جیسی چیزوں کا استعمال نہیں کرتے ہیں، لیکن مکمل طور پر ننگی دھات پر انحصار کرتے ہیں۔

تمام تہوں کو PaaS کے ذریعے ملایا گیا ہے۔ اور یہ پلیٹ فارم، بدلے میں، تین حصوں پر مشتمل ہے۔

I. جنریٹرز، CLI یوٹیلیٹی کے ذریعے کنٹرول کیا جاتا ہے۔ یہ وہی ہے جو درست طریقے سے اور کم سے کم کوشش کے ساتھ ایک مائیکرو سروس بنانے میں ڈویلپر کی مدد کرتی ہے۔

II اکٹھا جمع کرنے والا ایک مشترکہ ڈیش بورڈ کے ذریعے تمام ٹولز کے کنٹرول کے ساتھ۔

III ذخیرہ. شیڈیولرز کے ساتھ جوڑتا ہے جو خود بخود اہم کارروائیوں کے لیے محرکات مرتب کرتے ہیں۔ اس طرح کے نظام کی بدولت ایک بھی ٹاسک صرف اس وجہ سے نہیں چھوڑا جاتا کہ کوئی جیرا میں ٹاسک سیٹ کرنا بھول گیا ہو۔ ہم اس کے لیے اٹلس نامی ایک اندرونی ٹول استعمال کرتے ہیں۔

ایویٹو میں مائیکرو سروسز کا نفاذ بھی ایک ہی اسکیم کے مطابق کیا جاتا ہے، جو ترقی اور رہائی کے ہر مرحلے پر ان پر کنٹرول کو آسان بناتا ہے۔

معیاری مائیکرو سروس ڈیولپمنٹ پائپ لائن کیسے کام کرتی ہے؟

عام طور پر، مائیکرو سروس تخلیق کا سلسلہ اس طرح لگتا ہے:

CLI-push → Continuous Integration → Bake → Deploy → مصنوعی ٹیسٹ → Canary tests → Squeeze Testing → Production → Maintenance۔

آئیے اس ترتیب میں بالکل اس کے ذریعے جائیں۔

CLI-دھکا

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

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

- ایک ٹیمپلیٹ کے مطابق ایک سروس بناتا ہے - قدم بہ قدم، "وزرڈ" موڈ میں۔ ہمارے پاس Avito پسدید میں اہم پروگرامنگ زبانوں کے لیے ٹیمپلیٹس ہیں: PHP، Golang اور Python۔

- ایک وقت میں ایک کمانڈ ایک مخصوص مشین پر مقامی ترقی کے لیے ماحول کو متعین کرتی ہے - منی کیوب کو لانچ کیا جاتا ہے، ہیلم چارٹس خود بخود تیار ہوتے ہیں اور مقامی کبرنیٹس میں لانچ ہوتے ہیں۔

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

- یہ لائیو اسمبلی خود انجام دیتا ہے۔ فرض کریں کہ ایک ڈویلپر نے اپنے IDE کے ذریعے مائیکرو سروس میں کچھ درست کیا۔ یوٹیلیٹی فائل سسٹم میں تبدیلیاں دیکھتی ہے اور ان کی بنیاد پر ایپلیکیشن کو دوبارہ بناتی ہے (گولانگ کے لیے) اور دوبارہ شروع ہوتی ہے۔ پی ایچ پی کے لیے، ہم صرف ڈائرکٹری کو کیوب کے اندر فارورڈ کرتے ہیں اور وہاں لائیو ری لوڈ "خودکار طور پر" حاصل کیا جاتا ہے۔

- آٹو ٹیسٹ تیار کرتا ہے۔ خالی جگہوں کی شکل میں، لیکن استعمال کے لیے کافی موزوں ہے۔

• مائیکرو سروس کی تعیناتی.

مائیکرو سروس کو تعینات کرنا ہمارے لیے تھوڑا سا کام ہوتا تھا۔ درج ذیل کی ضرورت تھی:

I. ڈاکر فائل۔

II ترتیب
III ہیلم چارٹ، جو خود بوجھل ہے اور اس میں شامل ہیں:

- خود چارٹ؛
- ٹیمپلیٹس؛
- مختلف ماحول کو مدنظر رکھتے ہوئے مخصوص اقدار۔

ہم نے Kubernetes مینی فیسٹس کو دوبارہ کام کرنے سے درد کو ختم کر دیا ہے لہذا وہ اب خود بخود پیدا ہو گئے ہیں۔ لیکن سب سے اہم بات، انہوں نے تعیناتی کو حد تک آسان کر دیا۔ اب سے ہمارے پاس ایک Dockerfile ہے، اور ڈویلپر پوری ترتیب کو ایک ہی مختصر app.toml فائل میں لکھتا ہے۔

ہاں، اور app.toml میں ہی ایک منٹ کے لیے کچھ نہیں ہے۔ ہم بتاتے ہیں کہ سروس کی کہاں اور کتنی کاپیاں جمع کرنی ہیں (ڈیو سرور پر، سٹیجنگ پر، پروڈکشن میں)، اور اس کے انحصار کی نشاندہی کرتے ہیں۔ [انجن] بلاک میں لائن کا سائز = "چھوٹا" دیکھیں۔ یہ وہ حد ہے جو Kubernetes کے ذریعے سروس کے لیے مختص کی جائے گی۔

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

• بنیادی توثیق۔ ایسے چیک بھی خودکار ہوتے ہیں۔
ٹریک کرنے کی ضرورت ہے:
- کیا کوئی ڈاکر فائل ہے؟
- کیا وہاں app.toml ہے؛
- کیا دستاویزات دستیاب ہیں؟
- کیا انحصار ترتیب میں ہے؟
- چاہے الرٹ کے اصول طے کیے گئے ہوں۔
آخری نقطہ تک: سروس کا مالک خود طے کرتا ہے کہ کس پروڈکٹ کی پیمائش کی نگرانی کرنی ہے۔

• دستاویزات کی تیاری۔
اب بھی ایک مسئلہ کا علاقہ۔ ایسا لگتا ہے کہ یہ سب سے زیادہ واضح ہے، لیکن ایک ہی وقت میں یہ "اکثر بھولا ہوا" ریکارڈ بھی ہے، اور اس وجہ سے سلسلہ میں ایک کمزور لنک ہے۔
یہ ضروری ہے کہ ہر مائیکرو سروس کے لیے دستاویزات موجود ہوں۔ اس میں درج ذیل بلاکس شامل ہیں۔

I. سروس کی مختصر تفصیل. یہ کیا کرتا ہے اور اس کی ضرورت کیوں ہے اس کے بارے میں لفظی طور پر چند جملے۔

II آرکیٹیکچر ڈایاگرام لنک. یہ ضروری ہے کہ اس پر ایک سرسری نظر ڈالنے سے یہ سمجھنا آسان ہو، مثال کے طور پر، آیا آپ Redis کو کیشنگ کے لیے استعمال کر رہے ہیں یا مستقل موڈ میں مرکزی ڈیٹا اسٹور کے طور پر۔ ایویٹو میں فی الحال یہ سنگم کا ایک لنک ہے۔

III رن بک. سروس شروع کرنے اور اس سے نمٹنے کی پیچیدگیوں کے بارے میں ایک مختصر رہنما۔

چہارم۔ عمومی سوالاتجہاں خدمت کے ساتھ کام کرتے وقت آپ کے ساتھیوں کو درپیش مسائل کا اندازہ لگانا اچھا ہوگا۔

V. API کے اختتامی پوائنٹس کی تفصیل. اگر اچانک آپ نے منزلوں کی وضاحت نہیں کی ہے، تو وہ ساتھی جن کی مائیکرو سروسز آپ سے متعلق ہیں تقریباً یقینی طور پر اس کی ادائیگی کریں گے۔ اب ہم Swagger استعمال کرتے ہیں اور اس کے لیے ہمارا حل مختصر کہا جاتا ہے۔

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

VII خدمت کے مالک یا مالکان. زیادہ تر معاملات میں، یہ — یا ان — کا تعین PaaS کا استعمال کرتے ہوئے خود بخود کیا جا سکتا ہے، لیکن محفوظ ہونے کے لیے، ہمیں ڈویلپر سے ان کی دستی طور پر وضاحت کرنے کی ضرورت ہوتی ہے۔

آخر میں، کوڈ کے جائزے کی طرح دستاویزات کا جائزہ لینا ایک اچھا عمل ہے۔

مسلسل انضمام

• مخزنوں کی تیاری۔
• TeamCity میں پائپ لائن بنانا۔
• حقوق کا تعین کرنا۔
• خدمت کے مالکان کو تلاش کریں۔ یہاں ایک ہائبرڈ اسکیم ہے - PaaS سے دستی مارکنگ اور کم سے کم آٹومیشن۔ ایک مکمل خودکار اسکیم اس وقت ناکام ہو جاتی ہے جب خدمات کسی اور ترقیاتی ٹیم کو سپورٹ کے لیے منتقل کی جاتی ہیں یا، مثال کے طور پر، اگر سروس ڈیولپر چھوڑ دیتا ہے۔
• اٹلس میں سروس رجسٹر کرنا (اوپر ملاحظہ کریں). اس کے تمام مالکان اور انحصار کے ساتھ۔
• نقل مکانی کی جانچ کر رہا ہے۔ ہم چیک کرتے ہیں کہ آیا ان میں سے کوئی بھی ممکنہ طور پر خطرناک ہے۔ مثال کے طور پر، ان میں سے ایک میں ایک الٹر ٹیبل یا کوئی اور چیز پاپ اپ ہوتی ہے جو سروس کے مختلف ورژنز کے درمیان ڈیٹا اسکیما کی مطابقت کو توڑ سکتی ہے۔ پھر منتقلی نہیں کی جاتی ہے، لیکن اسے سبسکرپشن میں رکھا جاتا ہے - PaaS کو سروس کے مالک کو سگنل دینا چاہیے جب یہ استعمال کرنا محفوظ ہو۔

بناو

اگلا مرحلہ تعیناتی سے پہلے پیکیجنگ خدمات ہے۔

• درخواست کی تعمیر کلاسیکی کے مطابق - ایک ڈوکر امیج میں۔
• خود خدمت اور متعلقہ وسائل کے لیے ہیلم چارٹس کی تخلیق۔ ڈیٹا بیس اور کیشے سمیت۔ وہ app.toml کی تشکیل کے مطابق خود بخود بنائے جاتے ہیں جو CLI-push مرحلے پر تیار کی گئی تھی۔
• منتظمین کے لیے بندرگاہیں کھولنے کے لیے ٹکٹ بنانا (جب ضرورت ہو)۔
• یونٹ ٹیسٹ چلانا اور کوڈ کوریج کا حساب لگانا. اگر کوڈ کی کوریج مخصوص حد سے نیچے ہے، تو زیادہ تر امکان ہے کہ سروس مزید نہیں جائے گی - تعیناتی تک۔ اگر یہ قابل قبول ہونے کے دہانے پر ہے، تو سروس کو ایک "متاثر کرنے والا" گتانک تفویض کیا جائے گا: پھر، اگر وقت کے ساتھ اشارے میں کوئی بہتری نہیں آتی ہے، تو ڈویلپر کو ایک اطلاع موصول ہوگی کہ ٹیسٹ کے معاملے میں کوئی پیش رفت نہیں ہوئی ہے ( اور اس کے بارے میں کچھ کرنے کی ضرورت ہے)۔
• میموری اور سی پی یو کی حدود کے لیے اکاؤنٹنگ. ہم بنیادی طور پر گولانگ میں مائیکرو سروسز لکھتے ہیں اور انہیں Kubernetes میں چلاتے ہیں۔ اس لیے گولانگ زبان کی خاصیت کے ساتھ ایک باریکیت وابستہ ہے: پہلے سے طے شدہ طور پر، شروع کرتے وقت، مشین پر موجود تمام کور استعمال کیے جاتے ہیں، اگر آپ واضح طور پر GOMAXPROCS متغیر کو سیٹ نہیں کرتے ہیں، اور جب ایک ہی مشین پر ایسی کئی خدمات شروع کی جاتی ہیں، تو وہ شروع ہو جاتی ہیں۔ وسائل کے لیے مقابلہ کرنا، ایک دوسرے کے ساتھ مداخلت کرنا۔ نیچے دیے گئے گراف دکھاتے ہیں کہ اگر آپ ایپلیکیشن کو بغیر کسی تنازعہ اور وسائل کے موڈ کی دوڑ میں چلاتے ہیں تو عملدرآمد کا وقت کیسے بدلتا ہے۔ (گراف کے ذرائع یہ ہیں۔ یہاں).

پھانسی کا وقت، کم بہتر ہے. زیادہ سے زیادہ: 643ms، کم از کم: 42ms تصویر قابل کلک ہے۔

سرجری کے لئے وقت، کم بہتر ہے. زیادہ سے زیادہ: 14091 این ایس، کم از کم: 151 این ایس۔ تصویر قابل کلک ہے۔

اسمبلی کی تیاری کے مرحلے پر، آپ اس متغیر کو واضح طور پر سیٹ کر سکتے ہیں یا آپ لائبریری کا استعمال کر سکتے ہیں۔ automaxprocs Uber کے لڑکوں سے۔

تعینات کریں۔

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

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

مصنوعی ٹیسٹ

• بند لوپ ٹیسٹنگ۔ اس کے لیے اب ہم اوپن سورس استعمال کر رہے ہیں۔ Hoverfly.io. سب سے پہلے، یہ سروس پر حقیقی بوجھ کو ریکارڈ کرتا ہے، پھر - صرف ایک بند لوپ میں - یہ اس کی تقلید کرتا ہے۔

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

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

a) ہم کل بوجھ کو دیکھتے ہیں۔
- بہت چھوٹا - اگر بوجھ اچانک کئی بار گر جائے تو زیادہ امکان ہے کہ کوئی چیز کام نہیں کرتی ہے۔
- بہت بڑا - اصلاح کی ضرورت ہے۔

ب) ہم آر پی ایس کے مطابق کٹ آف کو دیکھتے ہیں۔
یہاں ہم موجودہ ورژن اور پچھلے ورژن اور کل مقدار کے درمیان فرق کو دیکھتے ہیں۔ مثال کے طور پر، اگر کوئی سروس 100 آر پی ایس پیدا کرتی ہے، تو یہ یا تو خراب لکھا گیا ہے، یا یہ اس کی خصوصیت ہے، لیکن کسی بھی صورت میں، یہ سروس کو بہت قریب سے دیکھنے کی ایک وجہ ہے۔
اگر، اس کے برعکس، بہت زیادہ آر پی ایس ہیں، تو شاید کسی قسم کا بگ ہے اور کچھ اینڈ پوائنٹس نے پے لوڈ پر عمل درآمد کرنا بند کر دیا ہے، اور کوئی اور صرف ٹرگر ہو گیا ہے۔ return true;

کینری ٹیسٹ

مصنوعی ٹیسٹ پاس کرنے کے بعد، ہم بہت کم صارفین پر مائیکرو سروس کی جانچ کرتے ہیں۔ ہم احتیاط سے شروع کرتے ہیں، سروس کے مطلوبہ سامعین کے ایک چھوٹے سے حصے کے ساتھ - 0,1% سے کم۔ اس مرحلے پر، یہ بہت ضروری ہے کہ مانیٹرنگ میں درست تکنیکی اور پروڈکٹ میٹرکس کو شامل کیا جائے تاکہ وہ جلد از جلد سروس میں مسئلہ کو ظاہر کریں۔ کینری ٹیسٹ کے لیے کم از کم وقت 5 منٹ ہے، اہم وقت 2 گھنٹے ہے۔ پیچیدہ خدمات کے لیے، ہم دستی طور پر وقت مقرر کرتے ہیں۔
آئیے تجزیہ کرتے ہیں:
- زبان سے متعلق میٹرکس، خاص طور پر، php-fpm کارکن؛
- سنتری میں غلطیاں؛
- ردعمل کے حالات؛
- جوابی وقت، عین مطابق اور اوسط؛
- تاخیر؛
- مستثنیات، پروسیس شدہ اور غیر ہینڈل؛
- پروڈکٹ میٹرکس۔

نچوڑ ٹیسٹنگ

Squeeze Testing کو "squeezing" ٹیسٹنگ بھی کہا جاتا ہے۔ تکنیک کا نام Netflix میں متعارف کرایا گیا تھا۔ اس کا خلاصہ یہ ہے کہ پہلے ہم ایک مثال کو حقیقی ٹریفک سے ناکامی کے مقام تک بھرتے ہیں اور اس طرح اس کی حد مقرر کرتے ہیں۔ پھر ہم ایک اور مثال شامل کرتے ہیں اور اس جوڑے کو لوڈ کرتے ہیں - دوبارہ زیادہ سے زیادہ تک؛ ہم ان کی چھت اور ڈیلٹا کو پہلے "نچوڑ" کے ساتھ دیکھتے ہیں۔ اور اس طرح ہم ایک وقت میں ایک مثال کو جوڑتے ہیں اور تبدیلیوں کے پیٹرن کا حساب لگاتے ہیں۔
"نچوڑنے" کے ذریعے ٹیسٹ کا ڈیٹا ایک عام میٹرکس ڈیٹا بیس میں بھی جاتا ہے، جہاں ہم یا تو مصنوعی بوجھ کے نتائج کو ان کے ساتھ افزودہ کرتے ہیں، یا یہاں تک کہ "مصنوعات" کو ان سے بدل دیتے ہیں۔

پیداوار

• پیمانہ کاری۔ جب ہم کسی سروس کو پروڈکشن کے لیے رول آؤٹ کرتے ہیں، تو ہم نگرانی کرتے ہیں کہ اس کی پیمائش کیسے ہوتی ہے۔ ہمارے تجربے میں، صرف CPU اشارے کی نگرانی کرنا غیر موثر ہے۔ آر پی ایس بینچ مارکنگ کے ساتھ آٹو اسکیلنگ اپنی خالص شکل میں کام کرتی ہے، لیکن صرف آن لائن سٹریمنگ جیسی مخصوص خدمات کے لیے۔ لہذا ہم سب سے پہلے ایپلیکیشن کے ساتھ مخصوص پروڈکٹ میٹرکس کو دیکھتے ہیں۔

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

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

سروس

مائیکرو سروس کے کام کرنے کے بعد، ہم اس کے ساتھ محرکات منسلک کر سکتے ہیں۔

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

کچھ محرکات آپریشن کے استحکام کے لیے ذمہ دار ہیں، کچھ - نظام کی دیکھ بھال کے کام کے طور پر - مثال کے طور پر، کچھ سروس طویل عرصے سے تعینات نہیں کی گئی ہے اور اس کی بنیادی تصویر نے سیکیورٹی چیک پاس کرنا چھوڑ دیا ہے۔

ڈیش بورڈ

مختصراً، ڈیش بورڈ ہمارے پورے PaaS کا کنٹرول پینل ہے۔

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

مجموعی طور پر

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

میں نے HighLoad++ 2018 کے لیے اس موضوع پر ایک رپورٹ دی، آپ اسے دیکھ سکتے ہیں۔ ویڈیو и پریزنٹیشن.

آخر تک پڑھنے والوں کے لیے بونس ٹریک

ہم Avito میں سے ڈویلپرز کے لیے تین روزہ اندرونی تربیت کا اہتمام کر رہے ہیں۔ کرس رچرڈسنمائیکرو سروس فن تعمیر میں ماہر۔ ہم اس پوسٹ کے قارئین میں سے ایک کو اس میں شرکت کا موقع دینا چاہیں گے۔ یہاں تربیتی پروگرام پوسٹ کر دیا گیا ہے۔

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

آپ شرکت کے لیے درخواست دے سکتے ہیں۔ اس گوگل فارم میں. آپ کی طرف سے - اس سوال کا جواب کیوں کہ آپ کو تربیت میں شرکت کرنے کی ضرورت ہے اور آپ سے رابطہ کرنے کے بارے میں معلومات۔ انگریزی میں جواب دیں، کیونکہ کرس اس شریک کا انتخاب کرے گا جو خود تربیت میں شرکت کرے گا۔
ہم اس پوسٹ کی تازہ کاری میں اور سوشل نیٹ ورک Avito برائے ڈویلپرز (AvitoTech in Фейсбуке, Vkontakte, ٹویٹر) 19 جولائی کے بعد نہیں۔

ماخذ: www.habr.com