"میرے جوتوں میں چلنا" - انتظار کرو، کیا وہ نشان زد ہیں؟

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

X5 میں، وہ نظام جو لیبل لگے ہوئے سامان کو ٹریک کرے گا اور ریاست اور سپلائرز کے ساتھ ڈیٹا کا تبادلہ کرے گا اسے "مارکس" کہا جاتا ہے۔ آئیے آپ کو ترتیب سے بتاتے ہیں کہ اسے کس نے اور کس نے تیار کیا، اس کی ٹیکنالوجی اسٹیک کیا ہے، اور ہمارے پاس فخر کرنے کے لیے کیوں ہے۔

اصلی ہائی لوڈ

"مارکس" بہت سے مسائل کو حل کرتا ہے، بنیادی ایک X5 انفارمیشن سسٹمز اور لیبل لگے ہوئے پروڈکٹس (GIS MP) کے لیے اسٹیٹ انفارمیشن سسٹم کے درمیان انٹیگریشن انٹریکشن ہے تاکہ لیبل لگے ہوئے پروڈکٹس کی نقل و حرکت کو ٹریک کیا جا سکے۔ یہ پلیٹ فارم ہمیں موصول ہونے والے تمام لیبلنگ کوڈز اور تمام اشیاء پر ان کوڈز کی نقل و حرکت کی پوری تاریخ کو بھی ذخیرہ کرتا ہے، اور لیبل والی مصنوعات کی دوبارہ درجہ بندی کو ختم کرنے میں مدد کرتا ہے۔ تمباکو کی مصنوعات کی مثال استعمال کرتے ہوئے، جو لیبل لگے ہوئے سامان کے پہلے گروپوں میں شامل تھے، سگریٹ کے صرف ایک ٹرک میں تقریباً 600 پیک ہوتے ہیں، جن میں سے ہر ایک کا اپنا الگ کوڈ ہوتا ہے۔ اور ہمارے سسٹم کا کام گوداموں اور اسٹورز کے درمیان اس طرح کے ہر پیک کی نقل و حرکت کی قانونی حیثیت کو ٹریک کرنا اور اس کی تصدیق کرنا ہے، اور بالآخر حتمی خریدار کو ان کی فروخت کے قابل قبول ہونے کی تصدیق کرنا ہے۔ اور ہم فی گھنٹہ تقریباً 000 نقد لین دین ریکارڈ کرتے ہیں، اور ہمیں یہ بھی ریکارڈ کرنے کی ضرورت ہے کہ اس طرح کا ہر پیک اسٹور میں کیسے آیا۔ اس طرح، اشیاء کے درمیان تمام حرکات کو مدنظر رکھتے ہوئے، ہم ہر سال دسیوں اربوں ریکارڈ کی توقع کر رہے ہیں۔

ٹیم ایم

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

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

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

ریموٹ ٹیم میٹنگ

دور دراز کے کام کے دوران ملاقاتیں

حل کی ٹیکنالوجی اسٹیک

X5 کے لیے معیاری ذخیرہ اور CI/CD ٹول GitLab ہے۔ ہم اسے کوڈ اسٹوریج، مسلسل جانچ، اور ٹیسٹ اور پروڈکشن سرورز کے لیے تعیناتی کے لیے استعمال کرتے ہیں۔ ہم کوڈ کے جائزے کی مشق بھی استعمال کرتے ہیں، جب کم از کم 2 ساتھیوں کو کوڈ میں ڈویلپر کی طرف سے کی گئی تبدیلیوں کو منظور کرنے کی ضرورت ہوتی ہے۔ جامد کوڈ تجزیہ کار SonarQube اور JaCoCo ہمارے کوڈ کو صاف رکھنے اور یونٹ ٹیسٹ کوریج کی مطلوبہ سطح کو یقینی بنانے میں ہماری مدد کرتے ہیں۔ کوڈ میں ہونے والی تمام تبدیلیوں کو ان چیکوں سے گزرنا چاہیے۔ تمام ٹیسٹ اسکرپٹ جو دستی طور پر چلائے جاتے ہیں بعد میں خودکار ہوتے ہیں۔

"مارکس" کے ذریعے کاروباری عمل کے کامیاب نفاذ کے لیے، ہمیں متعدد تکنیکی مسائل کو حل کرنا پڑا، ہر ایک کے بارے میں

ٹاسک 1. سسٹم کی افقی اسکیل ایبلٹی کی ضرورت

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

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

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

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

ٹاسک 2. پلیٹ فارم سروسز کے درمیان زیادہ بوجھ اور بہت زیادہ ڈیٹا ایکسچینج کو برقرار رکھنے کی ضرورت: صرف پروجیکٹ کے آغاز کے مرحلے کے دوران، فی سیکنڈ تقریباً 600 آپریشن کیے جاتے ہیں۔ ہم توقع کرتے ہیں کہ یہ قدر بڑھ کر 5000 ops/sec تک پہنچ جائے گی کیونکہ ریٹیل آؤٹ لیٹس ہمارے پلیٹ فارم سے جڑ جاتے ہیں۔

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

لاگز کو ٹریس کرنے پر بہت زیادہ توجہ دی گئی تاکہ سروسز کے آپریشن کے دوران یا کافکا بیچ کے ساتھ کام کرتے وقت مستثنیات پیش آنے پر ان کا TraceId ضائع نہ ہو۔ اور اگر پہلے والے کے ساتھ کوئی خاص مسئلہ نہیں تھا، تو دوسری صورت میں ہم ان تمام TraceIds کو لاگ کرنے پر مجبور ہیں جو بیچ کے ساتھ آئے تھے اور ٹریسنگ جاری رکھنے کے لیے ایک کو منتخب کریں۔ پھر، اصل TraceId کے ذریعے تلاش کرنے پر، صارف کو آسانی سے پتہ چل جائے گا کہ کس کے ساتھ ٹریسنگ جاری ہے۔

ٹاسک 3. ڈیٹا کی ایک بڑی مقدار کو ذخیرہ کرنے کی ضرورت: صرف تمباکو کے لیے ہر سال 1 بلین سے زیادہ لیبل X5 پر آتے ہیں۔ انہیں مستقل اور فوری رسائی کی ضرورت ہوتی ہے۔ مجموعی طور پر، نظام کو ان لیبل والے سامان کی نقل و حرکت کی تاریخ کے تقریباً 10 بلین ریکارڈ پر کارروائی کرنی ہوگی۔

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

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

ٹاسک 4: قطار کی دوبارہ پروسیسنگ اور نگرانی:

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

ایسی اسکیم کو نافذ کرنے کے لیے، ہمیں درج ذیل کی ضرورت ہے: اس حل کو بہار کے ساتھ مربوط کرنے اور کوڈ کی نقل سے بچنے کے لیے۔ ویب پر سرفنگ کرتے ہوئے، ہمیں Spring BeanPostProccessor پر مبنی ایک ایسا ہی حل ملا، لیکن یہ ہمارے لیے غیر ضروری طور پر بوجھل معلوم ہوا۔ ہماری ٹیم نے ایک آسان حل بنایا ہے جو ہمیں صارفین بنانے کے لیے موسم بہار کے چکر میں ضم کرنے اور اس کے علاوہ دوبارہ کوشش کرنے والے صارفین کو شامل کرنے کی اجازت دیتا ہے۔ ہم نے اسپرنگ ٹیم کو اپنے حل کا ایک پروٹو ٹائپ پیش کیا، آپ اسے دیکھ سکتے ہیں۔ یہاں. دوبارہ کوشش کرنے والے صارفین کی تعداد اور ہر صارف کے لیے کوششوں کی تعداد کو پیرامیٹرز کے ذریعے ترتیب دیا جاتا ہے، کاروباری عمل کی ضروریات پر منحصر ہے، اور ہر چیز کے کام کرنے کے لیے، جو کچھ باقی رہتا ہے وہ org.springframework.kafka.annotation.KafkaListener کو شامل کرنا ہے۔ ، جو تمام بہار کے ڈویلپرز سے واقف ہے۔

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

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

پلیٹ فارم آپریشن

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

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

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

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

ماخذ: www.habr.com