پچھلے سال سے، ہماری کمپنی نے ہیکاتھون کا اہتمام کرنا شروع کیا۔ اس طرح کا پہلا مقابلہ بہت کامیاب رہا، ہم نے اس کے بارے میں لکھا . دوسری ہیکاتھون فروری 2019 میں ہوئی تھی اور یہ بھی کم کامیاب نہیں تھی۔ مؤخر الذکر کے انعقاد کے مقاصد کے بارے میں اتنی دیر پہلے نہیں۔ آرگنائزر
شرکاء کو اس کے نفاذ کے لیے ٹیکنالوجی کے اسٹیک کو منتخب کرنے میں مکمل آزادی کے ساتھ ایک دلچسپ ٹاسک دیا گیا۔ کسٹمر اسکورنگ فنکشنز کی آسان تعیناتی کے لیے فیصلہ سازی کے پلیٹ فارم کو نافذ کرنا ضروری تھا جو ایپلی کیشنز کے تیز بہاؤ کے ساتھ کام کر سکے، بھاری بوجھ برداشت کر سکے، اور سسٹم خود آسانی سے قابل توسیع تھا۔
یہ کام غیر معمولی ہے اور اسے کئی طریقوں سے حل کیا جا سکتا ہے، جیسا کہ ہم شرکاء کے منصوبوں کی حتمی پیشکشوں کے مظاہرے کے دوران قائل تھے۔ ہیکاتھون میں 6 افراد کی 5 ٹیمیں تھیں، تمام شرکاء کے پاس اچھے پروجیکٹ تھے، لیکن ہمارا پلیٹ فارم سب سے زیادہ مسابقتی نکلا۔ ہمارے پاس ایک بہت ہی دلچسپ پروجیکٹ ہے، جس کے بارے میں میں اس مضمون میں بات کرنا چاہوں گا۔
ہمارا حل Kubernetes کے اندر سرور لیس فن تعمیر پر مبنی ایک پلیٹ فارم ہے، جو پیداوار میں نئی خصوصیات لانے میں لگنے والے وقت کو کم کرتا ہے۔ یہ تجزیہ کاروں کو ان کے لیے آسان ماحول میں کوڈ لکھنے اور انجینئرز اور ڈویلپرز کی شرکت کے بغیر اسے پروڈکشن میں تعینات کرنے کی اجازت دیتا ہے۔
اسکور کیا ہے
Tinkoff.ru، بہت سی جدید کمپنیوں کی طرح، کسٹمر اسکورنگ رکھتا ہے۔ اسکورنگ ڈیٹا کے تجزیہ کے شماریاتی طریقوں پر مبنی صارف کی تشخیص کا نظام ہے۔
مثال کے طور پر، ایک کلائنٹ اسے قرض جاری کرنے، یا ہمارے ساتھ انفرادی کاروباری اکاؤنٹ کھولنے کی درخواست کے ساتھ ہم سے رجوع کرتا ہے۔ اگر ہم اسے قرض جاری کرنے کا ارادہ رکھتے ہیں، تو ہمیں اس کی سالوینسی کا اندازہ لگانے کی ضرورت ہے، اور اگر اکاؤنٹ ایک انفرادی کاروباری ہے، تو ہمیں اس بات کا یقین کرنے کی ضرورت ہے کہ مؤکل دھوکہ دہی پر مبنی لین دین نہیں کرے گا۔
اس طرح کے فیصلے کرنے کی بنیاد ریاضیاتی ماڈل ہیں جو خود ایپلیکیشن کے ڈیٹا اور ہمارے سٹوریج کے ڈیٹا دونوں کا تجزیہ کرتے ہیں۔ اسکورنگ کے علاوہ، اسی طرح کے شماریاتی طریقوں کو ہمارے کلائنٹس کے لیے نئی مصنوعات کے لیے انفرادی سفارشات تیار کرنے کی خدمت میں بھی استعمال کیا جا سکتا ہے۔
اس طرح کی تشخیص کا طریقہ مختلف قسم کے ان پٹ ڈیٹا کو قبول کر سکتا ہے۔ اور کسی وقت ہم ان پٹ میں ایک نیا پیرامیٹر شامل کر سکتے ہیں، جو تاریخی ڈیٹا کے تجزیہ کے نتائج کی بنیاد پر، سروس کے استعمال کی تبدیلی کی شرح میں اضافہ کرے گا۔
ہمارے پاس گاہک کے تعلقات کے بارے میں ڈیٹا کا ذخیرہ ہے، اور اس معلومات کا حجم مسلسل بڑھ رہا ہے۔ کام کرنے کے لیے اسکور کرنے کے لیے، ڈیٹا پروسیسنگ کے لیے ایسے اصول (یا ریاضی کے ماڈلز) کی بھی ضرورت ہوتی ہے جو آپ کو فوری طور پر یہ فیصلہ کرنے کی اجازت دیتے ہیں کہ کس کو درخواست منظور کرنی ہے، کسے انکار کرنا ہے، اور کس کو کچھ اور مصنوعات پیش کرنی ہیں، ان کی ممکنہ دلچسپی کا اندازہ لگا کر۔
ہاتھ میں کام کے لیے، ہم پہلے سے ہی ایک خصوصی فیصلہ سازی کا نظام استعمال کر رہے ہیں۔ ، جو تجزیہ کاروں، تکنیکی ماہرین اور ڈویلپرز کے مقرر کردہ اصولوں کی بنیاد پر فیصلہ کرتا ہے کہ آیا کلائنٹ کو کسی خاص بینکنگ پروڈکٹ کو منظور کرنا ہے یا انکار کرنا ہے۔
مارکیٹ میں بہت سے تیار حل موجود ہیں، دونوں اسکور کرنے والے ماڈل اور فیصلہ سازی کے نظام خود۔ ہم اپنی کمپنی میں ان میں سے ایک سسٹم استعمال کرتے ہیں۔ لیکن کاروبار بڑھ رہا ہے، متنوع ہو رہا ہے، کلائنٹس کی تعداد اور پیش کردہ مصنوعات کی تعداد دونوں میں اضافہ ہو رہا ہے، اور اس کے ساتھ ساتھ موجودہ فیصلہ سازی کے عمل کو بہتر بنانے کے بارے میں خیالات ابھر رہے ہیں۔ یقینی طور پر موجودہ نظام کے ساتھ کام کرنے والے لوگوں کے پاس اسے آسان، بہتر، زیادہ آسان بنانے کے بارے میں بہت سے خیالات ہیں، لیکن بعض اوقات باہر کے خیالات کارآمد ہوتے ہیں۔ نیو ہیکاتھون کا انعقاد صوتی خیالات کو جمع کرنے کے مقصد سے کیا گیا تھا۔
کام
ہیکاتھون کا انعقاد 23 فروری کو کیا گیا تھا۔ شرکاء کو ایک جنگی کام کی پیشکش کی گئی تھی: فیصلہ سازی کا ایک ایسا نظام تیار کرنا جس میں کئی شرائط کو پورا کرنا تھا۔
ہمیں بتایا گیا کہ موجودہ نظام کیسے کام کرتا ہے اور اس کے آپریشن کے دوران کیا مشکلات پیش آتی ہیں، ساتھ ہی یہ بھی بتایا گیا کہ ترقی یافتہ پلیٹ فارم کو کن کاروباری اہداف کو حاصل کرنا چاہیے۔ نظام میں قواعد و ضوابط تیار کرنے کے لیے ایک تیز رفتار ٹائم ٹو مارکیٹ ہونا چاہیے تاکہ تجزیہ کاروں کا ورکنگ کوڈ جلد از جلد پروڈکشن میں آجائے۔ اور درخواستوں کے آنے والے بہاؤ کے لیے، فیصلہ سازی کا وقت کم سے کم ہونا چاہیے۔ نیز، تیار کیے جانے والے سسٹم میں کراس سیل کی صلاحیتیں ہونی چاہئیں تاکہ کلائنٹ کو کمپنی کی دوسری مصنوعات خریدنے کا موقع فراہم کیا جا سکے اگر وہ ہماری طرف سے منظور شدہ ہوں اور کلائنٹ کی طرف سے ممکنہ دلچسپی ہو۔
یہ واضح ہے کہ راتوں رات ریلیز کے لئے تیار پروجیکٹ لکھنا ناممکن ہے جو یقینی طور پر پیداوار میں چلا جائے گا، اور پورے نظام کا احاطہ کرنا کافی مشکل ہے، لہذا ہم سے کہا گیا کہ کم از کم اس کے کچھ حصے کو نافذ کریں۔ متعدد تقاضے قائم کیے گئے تھے جو پروٹوٹائپ کو پورا کرنا ضروری ہے۔ تمام ضروریات کو مکمل طور پر پورا کرنے کے لیے، اور تیار کیے جانے والے پلیٹ فارم کے انفرادی حصوں پر تفصیل سے کام کرنے کی کوشش کرنا ممکن تھا۔
جہاں تک ٹیکنالوجی کا تعلق ہے، تمام شرکاء کو انتخاب کی مکمل آزادی دی گئی۔ کسی بھی تصورات اور ٹیکنالوجیز کو استعمال کرنا ممکن تھا: ڈیٹا سٹریمنگ، مشین لرننگ، ایونٹ سورسنگ، بڑا ڈیٹا اور دیگر۔
ہمارا حل
تھوڑی سی سوچ بچار کے بعد، ہم نے فیصلہ کیا کہ کام کو مکمل کرنے کے لیے ایک FaaS حل بہترین ہوگا۔
اس حل کے لیے، فیصلہ سازی کے نظام کے وضع کردہ اصولوں کو نافذ کرنے کے لیے ایک موزوں سرور لیس فریم ورک تلاش کرنا ضروری تھا۔ چونکہ Tinkoff بنیادی ڈھانچے کے انتظام کے لیے Kubernetes کو فعال طور پر استعمال کرتا ہے، اس لیے ہم نے اس پر مبنی کئی ریڈی میڈ حل دیکھے؛ میں آپ کو بعد میں اس کے بارے میں مزید بتاؤں گا۔
سب سے مؤثر حل تلاش کرنے کے لیے، ہم نے اس پروڈکٹ کو دیکھا جو اس کے صارفین کی نظروں سے تیار کی جا رہی ہے۔ ہمارے سسٹم کے اہم صارفین اصول کی ترقی میں شامل تجزیہ کار ہیں۔ قواعد کو سرور پر تعینات کیا جانا چاہیے، یا، جیسا کہ ہمارے معاملے میں، بعد میں فیصلہ سازی کے لیے، کلاؤڈ میں تعینات کیا جانا چاہیے۔ تجزیہ کار کے نقطہ نظر سے، ورک فلو اس طرح لگتا ہے:
- تجزیہ کار گودام کے ڈیٹا کی بنیاد پر اسکرپٹ، قاعدہ، یا ML ماڈل لکھتا ہے۔ ہیکاتھون کے حصے کے طور پر، ہم نے Mongodb استعمال کرنے کا فیصلہ کیا، لیکن ڈیٹا اسٹوریج سسٹم کا انتخاب یہاں اہم نہیں ہے۔
- تاریخی ڈیٹا پر تیار کردہ اصولوں کی جانچ کرنے کے بعد، تجزیہ کار اپنا کوڈ ایڈمن پینل پر اپ لوڈ کرتا ہے۔
- ورژننگ کو یقینی بنانے کے لیے، تمام کوڈ گٹ ریپوزٹریز میں جائیں گے۔
- ایڈمن پینل کے ذریعے کوڈ کو کلاؤڈ میں ایک الگ فنکشنل سرور لیس ماڈیول کے طور پر تعینات کرنا ممکن ہوگا۔
کلائنٹس کے ابتدائی ڈیٹا کو گودام کے ڈیٹا کے ساتھ ابتدائی درخواست کو تقویت دینے کے لیے ڈیزائن کردہ خصوصی افزودگی سروس سے گزرنا چاہیے۔ اس سروس کو اس طرح نافذ کرنا ضروری تھا کہ یہ ایک واحد ذخیرہ کے ساتھ کام کرے (جس سے تجزیہ کار قواعد تیار کرتے وقت ڈیٹا لیتا ہے) تاکہ ڈیٹا کا ایک متحد ڈھانچہ برقرار رکھا جاسکے۔
ہیکاتھون سے پہلے ہی، ہم نے سرور لیس فریم ورک کا فیصلہ کیا جسے ہم استعمال کریں گے۔ آج مارکیٹ میں بہت ساری ٹیکنالوجیز موجود ہیں جو اس نقطہ نظر کو نافذ کرتی ہیں۔ Kubernetes فن تعمیر کے اندر سب سے زیادہ مقبول حل ہیں Fission، Open FaaS اور Kubeless۔ بھی ہیں .
تمام فوائد اور نقصانات کو تولنے کے بعد، ہم نے انتخاب کیا۔ . یہ سرور لیس فریم ورک کا انتظام کرنا کافی آسان ہے اور کام کی ضروریات کو پورا کرتا ہے۔
Fission کے ساتھ کام کرنے کے لیے، آپ کو دو بنیادی تصورات کو سمجھنے کی ضرورت ہے: فنکشن اور ماحول۔ فنکشن کوڈ کا ایک ٹکڑا ہے جو ان زبانوں میں سے ایک میں لکھا جاتا ہے جس کے لیے فِشن ماحول ہوتا ہے۔ پائتھون، جے ایس، گو، جے وی ایم اور بہت سی دوسری مشہور زبانیں اور ٹیکنالوجیز شامل ہیں۔
فِشن ایک آرکائیو میں پہلے سے پیک کیے گئے کئی فائلوں میں تقسیم کیے گئے فنکشنز کو انجام دینے کے قابل بھی ہے۔ Kubernetes کلسٹر میں Fission کے آپریشن کو خصوصی پوڈز کے ذریعے یقینی بنایا جاتا ہے، جن کا انتظام خود فریم ورک کے ذریعے کیا جاتا ہے۔ کلسٹر پوڈز کے ساتھ تعامل کرنے کے لیے، ہر فنکشن کو اس کا اپنا راستہ تفویض کرنا چاہیے، اور جس پر آپ GET پیرامیٹرز پاس کر سکتے ہیں یا POST کی درخواست کی صورت میں باڈی کی درخواست کر سکتے ہیں۔
نتیجے کے طور پر، ہم نے ایک ایسا حل حاصل کرنے کا منصوبہ بنایا جو تجزیہ کاروں کو انجینئرز اور ڈویلپرز کی شرکت کے بغیر ترقی یافتہ اصول اسکرپٹس کو تعینات کرنے کی اجازت دے گا۔ بیان کردہ نقطہ نظر ڈویلپرز کو تجزیہ کار کوڈ کو دوسری زبان میں دوبارہ لکھنے کی ضرورت کو بھی ختم کرتا ہے۔ مثال کے طور پر، موجودہ فیصلہ سازی کے نظام کے لیے جو ہم استعمال کرتے ہیں، ہمیں انتہائی مخصوص ٹیکنالوجیز اور زبانوں میں قواعد لکھنے پڑتے ہیں، جن کا دائرہ کار انتہائی محدود ہے، اور ایپلیکیشن سرور پر بھی مضبوط انحصار ہوتا ہے، کیونکہ تمام ڈرافٹ بینک قوانین ایک ہی ماحول میں تعینات ہیں۔ نتیجے کے طور پر، نئے قوانین کو تعینات کرنے کے لئے پورے نظام کو جاری کرنا ضروری ہے.
ہمارے مجوزہ حل میں، قواعد جاری کرنے کی ضرورت نہیں ہے؛ بٹن کے کلک پر کوڈ کو آسانی سے تعینات کیا جا سکتا ہے۔ نیز، Kubernetes میں بنیادی ڈھانچے کا انتظام آپ کو لوڈ اور اسکیلنگ کے بارے میں سوچنے کی اجازت نہیں دیتا ہے؛ اس طرح کے مسائل کو باکس سے باہر حل کیا جاتا ہے۔ اور واحد ڈیٹا گودام کا استعمال تاریخی ڈیٹا کے ساتھ حقیقی وقت کے ڈیٹا کا موازنہ کرنے کی ضرورت کو ختم کرتا ہے، جو تجزیہ کار کے کام کو آسان بناتا ہے۔
جو ہمیں ملا
چونکہ ہم ہیکاتھون میں ایک تیار حل کے ساتھ آئے تھے (اپنی تصورات میں)، ہمیں بس اپنے تمام خیالات کو کوڈ کی لائنوں میں تبدیل کرنا تھا۔
کسی بھی ہیکاتھون میں کامیابی کی کلید تیاری اور اچھی طرح سے تحریری منصوبہ ہے۔ لہٰذا، ہم نے سب سے پہلے یہ فیصلہ کیا کہ ہمارا سسٹم فن تعمیر کن ماڈیولز پر مشتمل ہوگا اور ہم کون سی ٹیکنالوجی استعمال کریں گے۔
ہمارے منصوبے کا فن تعمیر اس طرح تھا:
یہ خاکہ دو انٹری پوائنٹس دکھاتا ہے، تجزیہ کار (ہمارے سسٹم کا مرکزی صارف) اور کلائنٹ۔
کام کا عمل اس طرح ترتیب دیا گیا ہے۔ تجزیہ کار اپنے ماڈل کے لیے ایک رول فنکشن اور ڈیٹا افزودگی کا فنکشن تیار کرتا ہے، اپنے کوڈ کو گٹ ریپوزٹری میں اسٹور کرتا ہے، اور ایڈمنسٹریٹر ایپلیکیشن کے ذریعے اپنے ماڈل کو کلاؤڈ پر تعینات کرتا ہے۔ آئیے غور کریں کہ کس طرح تعینات فنکشن کو بلایا جائے گا اور کلائنٹس کی جانب سے آنے والی درخواستوں پر فیصلہ کریں:
- کلائنٹ ویب سائٹ پر ایک فارم بھرتا ہے اور کنٹرولر کو اپنی درخواست بھیجتا ہے۔ ایک درخواست جس پر فیصلہ کرنے کی ضرورت ہوتی ہے وہ سسٹم ان پٹ پر آتی ہے اور ڈیٹا بیس میں اس کی اصل شکل میں ریکارڈ کی جاتی ہے۔
- اگلا، اگر ضروری ہو تو خام درخواست کو افزودگی کے لیے بھیجا جاتا ہے۔ آپ ابتدائی درخواست کو بیرونی خدمات اور اسٹوریج دونوں سے ڈیٹا کے ساتھ پورا کر سکتے ہیں۔ نتیجہ خیز استفسار بھی ڈیٹا بیس میں محفوظ کیا جاتا ہے۔
- تجزیہ کار کا فنکشن شروع کیا جاتا ہے، جو ایک افزودہ استفسار کو بطور ان پٹ لیتا ہے اور ایک حل تیار کرتا ہے، جسے اسٹوریج پر بھی لکھا جاتا ہے۔
ہم نے JSON دستاویزات کی شکل میں ڈیٹا کی دستاویز پر مبنی اسٹوریج کی وجہ سے اپنے سسٹم میں MongoDB کو بطور سٹوریج استعمال کرنے کا فیصلہ کیا، کیونکہ اصل درخواست سمیت افزودگی کی خدمات REST کنٹرولرز کے ذریعے تمام ڈیٹا کو جمع کرتی ہیں۔
لہذا، ہمارے پاس پلیٹ فارم کو نافذ کرنے کے لیے XNUMX گھنٹے تھے۔ ہم نے کافی کامیابی کے ساتھ کرداروں کو تقسیم کیا؛ ہمارے پروجیکٹ میں ٹیم کے ہر رکن کی اپنی ذمہ داری تھی:
- تجزیہ کار کے کام کے لیے فرنٹ اینڈ ایڈمن پینلز، جن کے ذریعے وہ تحریری اسکرپٹس کے ورژن کنٹرول سسٹم سے قواعد ڈاؤن لوڈ کر سکتا ہے، ان پٹ ڈیٹا کو افزودہ کرنے کے لیے آپشنز کو منتخب کر سکتا ہے اور رول اسکرپٹس کو آن لائن ایڈٹ کر سکتا ہے۔
- بیک اینڈ ایڈمن، بشمول فرنٹ کے لیے REST API اور VCS کے ساتھ انضمام۔
- گوگل کلاؤڈ میں انفراسٹرکچر ترتیب دینا اور سورس ڈیٹا کو افزودہ کرنے کے لیے ایک سروس تیار کرنا۔
- بعد میں قواعد کی تعیناتی کے لیے سرور لیس فریم ورک کے ساتھ ایڈمن ایپلیکیشن کو مربوط کرنے کے لیے ایک ماڈیول۔
- حتمی مظاہرے کے لیے پورے نظام کی کارکردگی اور آنے والی ایپلی کیشنز (فیصلے کیے گئے) پر تجزیات کا مجموعہ جانچنے کے لیے قواعد کے اسکرپٹ۔
چلو شروع کرو.
بینکنگ UI کٹ کا استعمال کرتے ہوئے ہمارا فرنٹ اینڈ انگولر 7 میں لکھا گیا تھا۔ ایڈمن پینل کا آخری ورژن اس طرح نظر آیا:
چونکہ تھوڑا وقت تھا، ہم نے صرف کلیدی فعالیت کو نافذ کرنے کی کوشش کی۔ Kubernetes کلسٹر میں کسی فنکشن کو تعینات کرنے کے لیے، ایک ایونٹ (ایک سروس جس کے لیے ایک قاعدہ کو کلاؤڈ میں تعینات کرنے کی ضرورت ہے) اور اس فنکشن کا کوڈ جو فیصلہ سازی کی منطق کو نافذ کرتا ہے کو منتخب کرنا ضروری تھا۔ منتخب سروس کے لیے ایک اصول کی ہر تعیناتی کے لیے، ہم نے اس ایونٹ کا ایک لاگ لکھا۔ ایڈمن پینل میں آپ تمام ایونٹس کے لاگز دیکھ سکتے ہیں۔
تمام فنکشن کوڈ ریموٹ گٹ ریپوزٹری میں محفوظ کیا گیا تھا، جسے ایڈمن پینل میں بھی سیٹ کرنا تھا۔ کوڈ کو ورژن بنانے کے لیے، تمام فنکشنز ریپوزٹری کی مختلف شاخوں میں محفوظ کیے گئے تھے۔ ایڈمن پینل تحریری اسکرپٹ میں ایڈجسٹمنٹ کرنے کی صلاحیت بھی فراہم کرتا ہے، تاکہ کسی فنکشن کو پروڈکشن میں تعینات کرنے سے پہلے، آپ نہ صرف تحریری کوڈ کو چیک کر سکیں، بلکہ ضروری تبدیلیاں بھی کر سکیں۔
قواعد کے افعال کے علاوہ، ہم نے افزودگی کے افعال کا استعمال کرتے ہوئے سورس ڈیٹا کو بتدریج افزودہ کرنے کی صلاحیت کو بھی نافذ کیا، جس کا کوڈ اسکرپٹ بھی تھا جس میں ڈیٹا گودام میں جانا، فریق ثالث کی خدمات کو کال کرنا اور ابتدائی حساب کتاب کرنا ممکن تھا۔ . اپنے حل کو ظاہر کرنے کے لیے، ہم نے درخواست چھوڑنے والے کلائنٹ کی رقم کا حساب لگایا اور تیسرے فریق کی REST سروس کا استعمال کرتے ہوئے اپنے موبائل آپریٹر کا تعین کیا۔
پلیٹ فارم کا بیک اینڈ جاوا میں لکھا گیا تھا اور اسپرنگ بوٹ ایپلی کیشن کے طور پر لاگو کیا گیا تھا۔ ہم نے ابتدائی طور پر ایڈمن ڈیٹا کو ذخیرہ کرنے کے لیے پوسٹگریس کو استعمال کرنے کا منصوبہ بنایا، لیکن ہیکاتھون کے حصے کے طور پر، ہم نے وقت بچانے کے لیے خود کو ایک سادہ H2 تک محدود رکھنے کا فیصلہ کیا۔ بیک اینڈ پر، Bitbucket کے ساتھ انضمام کو استفسار کی افزودگی کے فنکشنز اور رول اسکرپٹس کے ورژن کے لیے لاگو کیا گیا تھا۔ ریموٹ گٹ ریپوزٹریز کے ساتھ انضمام کے لیے، ہم نے استعمال کیا۔ ، جو CLI کمانڈز پر ایک قسم کا ریپر ہے، جو آپ کو آسان سافٹ ویئر انٹرفیس کا استعمال کرتے ہوئے کسی بھی گٹ ہدایات پر عمل کرنے کی اجازت دیتا ہے۔ لہذا ہمارے پاس افزودگی کے افعال اور قواعد کے لئے دو الگ الگ ذخیرے تھے، اور تمام اسکرپٹ کو ڈائریکٹریز میں تقسیم کیا گیا تھا۔ UI کے ذریعے ریپوزٹری کی صوابدیدی شاخ کے اسکرپٹ کی تازہ ترین کمٹ کو منتخب کرنا ممکن تھا۔ ایڈمن پینل کے ذریعے کوڈ میں تبدیلی کرتے وقت، تبدیل شدہ کوڈ کے کمٹ ریموٹ ریپوزٹریز میں بنائے گئے تھے۔
اپنے خیال کو عملی جامہ پہنانے کے لیے ہمیں مناسب انفراسٹرکچر کی ضرورت تھی۔ ہم نے اپنے Kubernetes کلسٹر کو کلاؤڈ میں تعینات کرنے کا فیصلہ کیا۔ ہمارا انتخاب گوگل کلاؤڈ پلیٹ فارم تھا۔ Fission سرور لیس فریم ورک Kubernetes کلسٹر پر نصب کیا گیا تھا، جسے ہم نے Gcloud میں تعینات کیا تھا۔ ابتدائی طور پر، سورس ڈیٹا کی افزودگی سروس کو k8s کلسٹر کے اندر ایک Pod میں لپیٹے ہوئے ایک علیحدہ جاوا ایپلیکیشن کے طور پر لاگو کیا گیا تھا۔ لیکن ہیکاتھون کے وسط میں ہمارے پروجیکٹ کے ابتدائی مظاہرے کے بعد، ہمیں سفارش کی گئی کہ افزودگی سروس کو مزید لچکدار بنانے کا موقع فراہم کیا جائے تاکہ آنے والی ایپلی کیشنز کے خام ڈیٹا کو کس طرح بہتر بنایا جائے۔ اور ہمارے پاس اس کے علاوہ کوئی چارہ نہیں تھا کہ افزودگی کی خدمت کو بھی بے سرور بنا دیں۔
Fission کے ساتھ کام کرنے کے لیے، ہم نے Fission CLI کا استعمال کیا، جسے Kubernetes CLI کے اوپر انسٹال ہونا چاہیے۔ k8s کلسٹر میں فنکشنز کی تعیناتی بہت آسان ہے؛ اگر کلسٹر سے باہر رسائی کی ضرورت ہو تو آنے والی ٹریفک کو اجازت دینے کے لیے آپ کو صرف ایک اندرونی راستہ تفویض کرنے اور فنکشن میں داخل ہونے کی ضرورت ہے۔ ایک فنکشن کو تعینات کرنے میں عام طور پر 10 سیکنڈ سے زیادہ وقت نہیں لگتا ہے۔
منصوبے کی حتمی پیشکش اور خلاصہ
یہ ظاہر کرنے کے لیے کہ ہمارا سسٹم کیسے کام کرتا ہے، ہم نے ریموٹ سرور پر ایک سادہ فارم رکھا ہے جہاں آپ بینک کی مصنوعات میں سے کسی ایک کے لیے درخواست جمع کرا سکتے ہیں۔ درخواست کرنے کے لیے، آپ کو اپنے ابتدائی نام، تاریخ پیدائش اور فون نمبر درج کرنا تھا۔
کلائنٹ فارم سے ڈیٹا کنٹرولر کے پاس گیا، جس نے بیک وقت تمام دستیاب قوانین کے لیے درخواستیں بھیجی، پہلے مخصوص شرائط کے مطابق ڈیٹا کو افزودہ کیا، اور انہیں مشترکہ اسٹوریج میں محفوظ کیا۔ مجموعی طور پر، ہم نے تین فنکشنز تعینات کیے ہیں جو آنے والی ایپلیکیشنز اور 4 ڈیٹا افزودگی کی خدمات پر فیصلے کرتے ہیں۔ درخواست جمع کرانے کے بعد، مؤکل کو ہمارا فیصلہ موصول ہوا:
انکار یا منظوری کے علاوہ، کلائنٹ کو دیگر پروڈکٹس کی ایک فہرست بھی موصول ہوئی، درخواستیں جن کے لیے ہم نے متوازی طور پر بھیجا۔ اس طرح ہم نے اپنے پلیٹ فارم میں کراس سیل کے امکان کو ظاہر کیا۔
کل 3 فرضی بینک پروڈکٹس دستیاب تھے:
- کریڈٹ
- کھلونا
- رہن۔
مظاہرے کے دوران، ہم نے ہر سروس کے لیے تیار کردہ فنکشنز اور افزودگی اسکرپٹس کو تعینات کیا۔
ہر اصول کو ان پٹ ڈیٹا کا اپنا سیٹ درکار ہوتا ہے۔ لہذا، رہن کو منظور کرنے کے لیے، ہم نے کلائنٹ کی رقم کا حساب لگایا اور اسے قمری کیلنڈر کی منطق سے جوڑا۔ ایک کھلونا کو منظور کرنے کے لیے، ہم نے چیک کیا کہ کلائنٹ بالغ ہونے کی عمر کو پہنچ چکا ہے، اور قرض جاری کرنے کے لیے، ہم نے سیلولر آپریٹر کا تعین کرنے کے لیے ایک بیرونی اوپن سروس کو درخواست بھیجی، اور اس پر فیصلہ کیا گیا۔
ہم نے اپنے مظاہرے کو دلچسپ اور انٹرایکٹو بنانے کی کوشش کی، موجود ہر شخص ہمارے فارم پر جا سکتا ہے اور ان کے لیے ہماری افسانوی خدمات کی دستیابی کی جانچ کر سکتا ہے۔ اور پریزنٹیشن کے بالکل آخر میں، ہم نے موصول ہونے والی درخواستوں کے تجزیات کا مظاہرہ کیا، جس سے پتہ چلتا ہے کہ کتنے لوگوں نے ہماری سروس کا استعمال کیا، منظوریوں کی تعداد، اور انکار۔
آن لائن تجزیات جمع کرنے کے لیے، ہم نے ایک اوپن سورس BI ٹول بھی تعینات کیا۔ اور اسے ہمارے اسٹوریج یونٹ تک پہنچا دیا۔ میٹا بیس آپ کو اس ڈیٹا پر تجزیات کے ساتھ اسکرین بنانے کی اجازت دیتا ہے جس میں ہماری دلچسپی ہے؛ آپ کو صرف ڈیٹا بیس سے کنکشن رجسٹر کرنے کی ضرورت ہے، ٹیبلز کو منتخب کرنے کی ضرورت ہے (ہمارے معاملے میں، ڈیٹا اکٹھا کرنا، چونکہ ہم نے MongoDB استعمال کیا ہے)، اور ہمارے لیے دلچسپی کے شعبوں کی وضاحت کریں۔ .
نتیجے کے طور پر، ہمیں فیصلہ سازی کے پلیٹ فارم کا ایک اچھا پروٹو ٹائپ ملا، اور مظاہرے کے دوران، ہر سننے والا ذاتی طور پر اس کی کارکردگی کو چیک کر سکتا ہے۔ ایک دلچسپ حل، ایک تیار شدہ پروٹو ٹائپ اور ایک کامیاب مظاہرے نے ہمیں دوسری ٹیموں کے مضبوط مقابلے کے باوجود جیتنے کی اجازت دی۔ مجھے یقین ہے کہ ہر ٹیم کے پروجیکٹ پر ایک دلچسپ مضمون بھی لکھا جا سکتا ہے۔
ماخذ: www.habr.com