گذريل سال جي شروعات، اسان جي ڪمپني هيڪاٿون منظم ڪرڻ شروع ڪيو. پهريون اهڙو مقابلو ڏاڍو ڪامياب ٿيو، جنهن ۾ اسان ان بابت لکيو . ٻيو هيڪاٿون فيبروري 2019 ۾ ٿي ويو ۽ گهٽ ڪامياب نه هو. بعد ۾ منعقد ڪرڻ جي مقصدن جي باري ۾ ايترو گهڻو اڳ نه آرگنائيزر
شرڪت ڪندڙن کي ان جي عمل درآمد لاءِ ٽيڪنالاجي اسٽيڪ چونڊڻ ۾ مڪمل آزادي سان بلڪه دلچسپ ڪم ڏنو ويو. اهو ضروري هو ته هڪ فيصلي سازي پليٽ فارم کي لاڳو ڪرڻ لاء آسان ترتيب ڏيڻ لاء ڪسٽمر اسڪورنگ جي ڪارڪردگي لاء جيڪي ايپليڪيشنن جي تيز وهڪري سان ڪم ڪري سگھن ٿيون، ڳري بوجھ کي برداشت ڪري سگھن ٿيون، ۽ سسٽم پاڻ کي آسانيء سان اسڪيلبل هو.
اهو ڪم غير معمولي آهي ۽ ڪيترن ئي طريقن سان حل ڪري سگهجي ٿو، جيئن اسان شرڪت ڪندڙن جي منصوبن جي آخري نمائش جي مظاهري دوران قائل هئاسين. هيڪاٿون ۾ 6 ماڻهن جون 5 ٽيمون هيون، سڀني شرڪت ڪندڙن وٽ سٺا پراجيڪٽ هئا، پر اسان جو پليٽ فارم تمام گهڻو مقابلو ڪندڙ ثابت ٿيو. اسان وٽ هڪ تمام دلچسپ منصوبو آهي، جنهن بابت آئون هن مضمون ۾ ڳالهائڻ چاهيندس.
اسان جو حل ھڪڙو پليٽ فارم آھي جنھن تي ٻڌل آھي سرور بيس آرڪيٽيڪچر اندر ڪبرنيٽس، جيڪو وقت گھٽائي ٿو اھو وٺي ٿو نون فيچرز کي پيداوار ۾ آڻڻ لاءِ. اهو تجزيه نگارن کي اجازت ڏئي ٿو ته انهن لاءِ آسان ماحول ۾ ڪوڊ لکڻ ۽ ان کي انجنيئرن ۽ ڊولپرز جي شموليت کان سواءِ پيداوار ۾ لڳايو.
ڇا اسڪورنگ آهي
Tinkoff.ru، ڪيترن ئي جديد ڪمپنين وانگر، ڪسٽمر اسڪورنگ آهي. اسڪورنگ هڪ ڪسٽمر تشخيصي نظام آهي جيڪو ڊيٽا جي تجزيي جي شمارياتي طريقن تي ٻڌل آهي.
مثال طور، هڪ گراهڪ اسان ڏانهن موٽندو آهي هڪ درخواست سان هن کي قرض جاري ڪرڻ، يا اسان سان هڪ انفرادي ڪاروباري اڪائونٽ کوليو. جيڪڏهن اسان هن کي قرض جاري ڪرڻ جي رٿابندي ڪريون ٿا، ته پوء اسان کي هن جي سولائيشن جو جائزو وٺڻ جي ضرورت آهي، ۽ جيڪڏهن اڪائونٽ هڪ انفرادي ڪاروباري آهي، ته پوء اسان کي پڪ ڪرڻ گهرجي ته گراهڪ فراڊ ٽرانزيڪشن نه ڪندو.
اهڙا فيصلا ڪرڻ جو بنياد رياضياتي ماڊل آهن جيڪي پاڻ ايپليڪيشن مان ڊيٽا ۽ اسان جي اسٽوريج مان ڊيٽا ٻنهي جو تجزيو ڪن ٿا. اسڪور ڪرڻ کان علاوه، ساڳيا شمارياتي طريقا پڻ استعمال ڪري سگھجن ٿا انفرادي سفارشون پيدا ڪرڻ جي خدمت ۾ اسان جي گراهڪن لاءِ نئين پروڊڪٽس لاءِ.
اهڙي تشخيص جو طريقو مختلف قسم جي ان پٽ ڊيٽا کي قبول ڪري سگهي ٿو. ۽ ڪجهه نقطي تي اسان ان پٽ ۾ هڪ نئون پيٽرولر شامل ڪري سگهون ٿا، جيڪو تاريخي ڊيٽا تي تجزيو جي نتيجن جي بنياد تي، خدمت استعمال ڪرڻ جي تبادلي جي شرح کي وڌائيندو.
اسان وٽ گراهڪ جي لاڳاپن بابت ڊيٽا جي دولت آهي، ۽ هن معلومات جو حجم مسلسل وڌي رهيو آهي. ڪم ڪرڻ لاءِ اسڪور ڪرڻ لاءِ، ڊيٽا پروسيسنگ لاءِ ضابطن (يا رياضياتي ماڊلز) جي به ضرورت هوندي آهي جيڪي توهان کي جلدي فيصلو ڪرڻ جي اجازت ڏين ٿا ته ڪنهن کي درخواست منظور ڪرڻي آهي، ڪنهن کي رد ڪرڻي آهي، ۽ ڪير ڪجهه وڌيڪ پروڊڪٽس پيش ڪري ٿو، انهن جي امڪاني دلچسپي جو اندازو لڳائيندي.
هٿ ۾ ڪم لاء، اسان اڳ ۾ ئي هڪ خاص فيصلو سازي سسٽم استعمال ڪندا آهيون ، جيڪو، تجزيه نگارن، ٽيڪنالاجيسٽن ۽ ڊولپرز پاران مقرر ڪيل قاعدن جي بنياد تي، فيصلو ڪري ٿو ته ڇا ڪلائنٽ کي ڪنهن خاص بينڪنگ پراڊڪٽ کي منظور يا رد ڪرڻ.
مارڪيٽ تي ڪيترائي تيار ڪيل حل آھن، ٻئي اسڪورنگ ماڊل ۽ فيصلا ڪرڻ وارا نظام پاڻ ۾. اسان انهن مان هڪ سسٽم استعمال ڪندا آهيون اسان جي ڪمپني ۾. پر ڪاروبار وڌي رهيو آهي، متنوع ٿي رهيو آهي، ٻنهي گراهڪن جو تعداد ۽ پيش ڪيل پراڊڪٽس جو تعداد وڌي رهيو آهي، ۽ ان سان گڏ، خيال پيدا ٿي رهيا آهن ته موجوده فيصلي سازي جي عمل کي ڪيئن بهتر بڻائي سگهجي. يقيناً موجوده نظام سان ڪم ڪندڙ ماڻهن وٽ ڪيترائي خيال آهن ته ان کي ڪيئن آسان، بهتر، وڌيڪ آسان بڻايو وڃي، پر ڪڏهن ڪڏهن ٻاهران آيل خيال ڪارآمد هوندا آهن. نيو هيڪاٿون منظم ڪيو ويو هو آواز خيالن کي گڏ ڪرڻ جي مقصد سان.
ڪم
هيڪٿون 23 فيبروري تي منعقد ڪئي وئي. شرڪت ڪندڙن کي جنگي ڪم جي آڇ ڪئي وئي: فيصلي سازي واري نظام کي ترقي ڪرڻ لاء جيڪو ڪيترن ئي شرطن کي پورا ڪرڻو پوندو.
اسان کي ٻڌايو ويو ته موجوده سسٽم ڪيئن ڪم ڪري ٿو ۽ ان جي آپريشن دوران ڪهڙيون مشڪلاتون پيدا ٿين ٿيون، انهي سان گڏ ترقي يافته پليٽ فارم کي ڪهڙا ڪاروباري مقصد حاصل ڪرڻ گهرجن. سسٽم کي لازمي طور تي ضابطن کي ترقي ڪرڻ لاءِ مارڪيٽ لاءِ تيز وقت هجڻ گهرجي ته جيئن تجزيه نگارن جو ڪم ڪندڙ ڪوڊ جلد کان جلد پيداوار ۾ اچي. ۽ ايپليڪيشنن جي ايندڙ وهڪري لاء، فيصلو ڪرڻ جو وقت گهٽ ۾ گهٽ هجڻ گهرجي. انهي سان گڏ، ترقي يافته سسٽم کي لازمي طور تي ڪراس-وڪرو صلاحيتون هجڻ گهرجن ته جيئن ڪلائنٽ کي ٻين ڪمپني جي شين کي خريد ڪرڻ جو موقعو ڏيو جيڪڏهن اهي اسان جي طرفان منظور ٿيل آهن ۽ ڪلائنٽ کان امڪاني دلچسپي آهي.
اهو واضح آهي ته اهو ناممڪن آهي ته هڪ تيار ٿيڻ لاء تيار ڪيل پروجيڪٽ رات ۾ لکڻ لاء جيڪو يقيني طور تي پيداوار ۾ وڃي، ۽ اهو سڄو سسٽم ڍڪڻ ڪافي ڏکيو آهي، تنهنڪري اسان کي گهٽ ۾ گهٽ ان جو حصو لاڳو ڪرڻ لاء چيو ويو آهي. ڪيتريون ئي گهرجون قائم ڪيون ويون آهن ته پروٽوٽائپ کي پورو ڪرڻ گهرجي. اهو ممڪن هو ته ٻنهي جي ڪوشش ڪئي وڃي ته انهن جي مڪمل ضرورتن کي پورو ڪرڻ، ۽ پليٽ فارم جي انفرادي حصن تي تفصيل سان ڪم ڪرڻ لاء ترقي ڪئي پئي وڃي.
ٽيڪنالاجي جي طور تي، سڀني شرڪت ڪندڙن کي پسند جي مڪمل آزادي ڏني وئي. ڪنهن به تصور ۽ ٽيڪنالاجي کي استعمال ڪرڻ ممڪن هو: ڊيٽا اسٽريمنگ، مشين لرننگ، ايونٽ سورسنگ، وڏي ڊيٽا ۽ ٻيا.
اسان جو حل
ٿورڙي دماغي طوفان کان پوء، اسان فيصلو ڪيو ته هڪ FaaS حل ڪم مڪمل ڪرڻ لاء مثالي هوندو.
هن حل لاءِ، اهو ضروري هو ته هڪ مناسب سرور بي ترتيب فريم ورڪ ڳولهڻ لاءِ جيڪو فيصلو سازي جي نظام جي ضابطن کي لاڳو ڪرڻ لاءِ تيار ڪيو پيو وڃي. جتان Tinkoff فعال طور تي انفراسٽرڪچر مينيجمينٽ لاءِ ڪبرنيٽس استعمال ڪري ٿو، اسان ان جي بنياد تي ڪيترن ئي تيار ڪيل حلن تي غور ڪيو؛ مان توھان کي بعد ۾ ان بابت وڌيڪ ٻڌائيندس.
سڀ کان وڌيڪ مؤثر حل ڳولڻ لاء، اسان ان جي استعمال ڪندڙن جي اکين جي ذريعي ترقي يافته پيداوار کي ڏٺو. اسان جي سسٽم جا بنيادي استعمال ڪندڙ تجزيه نگار آهن جيڪي حڪمراني جي ترقي ۾ شامل آهن. ضابطن کي لازمي طور تي سرور تي لڳايو وڃي ٿو، يا، جيئن اسان جي صورت ۾، بادل ۾ ترتيب ڏنل، ايندڙ فيصلي لاءِ. هڪ تجزيه نگار جي نقطه نظر کان، ڪم فلو هن طرح نظر اچي ٿو:
- تجزيه نگار گودام مان ڊيٽا جي بنياد تي اسڪرپٽ، قاعدو، يا ايم ايل ماڊل لکي ٿو. hackathon جي حصي جي طور تي، اسان Mongodb استعمال ڪرڻ جو فيصلو ڪيو، پر ڊيٽا اسٽوريج سسٽم جو انتخاب هتي اهم ناهي.
- تاريخي ڊيٽا تي ترقي يافته ضابطن کي جانچڻ کان پوء، تجزيه نگار پنهنجو ڪوڊ ايڊمن پينل تي اپ لوڊ ڪري ٿو.
- ورزننگ کي يقيني بڻائڻ لاءِ، سڀ ڪوڊ ويندا Git repositories ڏانهن.
- ايڊمن پينل جي ذريعي اهو ممڪن ٿيندو ته ڪوڊ کي ڪلائوڊ ۾ هڪ الڳ فنڪشنل سرور لیس ماڊل طور ترتيب ڏيو.
گراهڪن کان ابتدائي ڊيٽا کي گودام مان ڊيٽا سان گڏ ابتدائي درخواست کي بهتر ڪرڻ لاء ٺهيل هڪ خاص افزودگي سروس ذريعي گذرڻ گهرجي. اهو ضروري هو ته هن خدمت کي اهڙي طريقي سان لاڳو ڪيو وڃي ته اها هڪ واحد ذخيرو سان ڪم ڪندي (جنهن مان تجزيه نگار ڊيٽا وٺندو آهي جڏهن ضابطن کي ترقي ڪندي) هڪ متحد ڊيٽا جي جوڙجڪ کي برقرار رکڻ لاء.
ايستائين جو هيڪاٿون کان اڳ، اسان فيصلو ڪيو سرور بيس فريم ورڪ تي جيڪو اسان استعمال ڪنداسين. اڄ مارڪيٽ تي ڪافي ٽيڪنالاجيون آھن جيڪي ھن طريقي کي لاڳو ڪن ٿيون. ڪبرنيٽس آرڪيٽيڪچر ۾ سڀ کان وڌيڪ مشهور حل آهن فيشن، اوپن FaaS ۽ Kubeless. اتي به آهن .
سڀني نفعو ۽ نقصان جي وزن کان پوء، اسان چونڊيو . هي سرور بغير فريم ورڪ کي منظم ڪرڻ ۽ ڪم جي ضرورتن کي پورو ڪرڻ بلڪل آسان آهي.
فِشن سان ڪم ڪرڻ لاءِ، توهان کي ٻه بنيادي مفهوم سمجهڻ جي ضرورت آهي: فنڪشن ۽ ماحول. فنڪشن ڪوڊ جو ھڪڙو ٽڪرو آھي جيڪو ھڪڙي ٻوليءَ ۾ لکيل آھي جنھن لاءِ فيشن ماحول آھي. Python، JS، Go، JVM ۽ ٻيون ڪيتريون ئي مشهور ٻوليون ۽ ٽيڪنالاجيون شامل آھن.
Fission ڪيترن ئي فائلن ۾ ورهايل فنڪشن کي انجام ڏيڻ جي قابل پڻ آهي، اڳ ۾ پيڪيج ٿيل آرڪائيو ۾. ڪبرنيٽس ڪلستر ۾ فيشن جي آپريشن کي خاص پوڊز جي ذريعي يقيني بڻايو وڃي ٿو، جيڪي خود فريم ورڪ پاران منظم ڪيا ويا آهن. ڪلستر پوڊس سان لهه وچڙ ڪرڻ لاءِ، هر فنڪشن کي پنهنجو رستو مقرر ڪيو وڃي، ۽ جنهن ۾ توهان پاس ڪري سگهو ٿا GET پيرا ميٽرز يا پوسٽ جي درخواست جي صورت ۾ جسم جي درخواست.
نتيجي طور، اسان هڪ حل حاصل ڪرڻ جي منصوبابندي ڪئي جيڪا تجزيه نگارن کي انجنيئرن ۽ ڊولپرز جي شموليت کان سواءِ ترقي يافته قاعدي اسڪرپٽ کي ترتيب ڏيڻ جي اجازت ڏئي ٿي. بيان ڪيل طريقي سان ڊولپرز جي ضرورت کي به ختم ڪري ٿو تجزيه نگار ڪوڊ کي ٻي ٻولي ۾ ٻيهر لکڻ لاءِ. مثال طور، موجوده فيصلي سازي واري نظام لاءِ جيڪو اسان استعمال ڪريون ٿا، اسان کي انتهائي خاص ٽيڪنالاجيز ۽ ٻولين ۾ قاعدا لکڻا پوندا، جن جو دائرو انتهائي محدود آهي، ۽ ايپليڪيشن سرور تي پڻ مضبوط انحصار آهي، ڇاڪاڻ ته بئنڪ جا سمورا مسودا ضابطا هڪ ئي ماحول ۾ رکيل آهن. نتيجي طور، نئين ضابطن کي ترتيب ڏيڻ لاء اهو ضروري آهي ته سڄي سسٽم کي ڇڏڻ ضروري آهي.
اسان جي تجويز ڪيل حل ۾، ضابطن کي جاري ڪرڻ جي ڪا ضرورت ناهي؛ ڪوڊ کي آساني سان ترتيب ڏئي سگهجي ٿو بٽڻ جي ڪلڪ تي. گڏوگڏ، انفراسٹرڪچر مينيجمينٽ Kubernetes ۾ توهان کي لوڊ ۽ اسڪيلنگ بابت سوچڻ جي اجازت ڏئي ٿي؛ اهڙيون مسئلا دٻي کان ٻاهر حل ڪيا ويا آهن. ۽ هڪ واحد ڊيٽا گودام جو استعمال تاريخي ڊيٽا سان حقيقي وقت جي ڊيٽا کي موازنہ ڪرڻ جي ضرورت کي ختم ڪري ٿو، جيڪو تجزيه نگار جي ڪم کي آسان بڻائي ٿو.
جيڪو اسان حاصل ڪيو
جيئن ته اسان هيڪاٿون وٽ هڪ تيار ٿيل حل (اسان جي تصورن ۾) سان گڏ آيا آهيون، اسان کي اهو ڪرڻو هو ته اسان جي سڀني سوچن کي ڪوڊ جي لائنن ۾ تبديل ڪيو وڃي.
ڪنهن به هيڪٿون ۾ ڪاميابي جي ڪنجي تياري ۽ هڪ سٺو لکيل منصوبو آهي. تنهن ڪري، پهرين شيء جيڪا اسان ڪئي هئي اهو فيصلو ڪيو ويو ته اسان جي سسٽم آرڪيٽيڪچر ڪهڙي ماڊلز تي مشتمل هوندي ۽ ڪهڙي ٽيڪنالاجيون استعمال ڪنداسين.
اسان جي منصوبي جي فن تعمير هن ريت هئي:
هي ڊراگرام ڏيکاري ٿو ٻه داخلا پوائنٽون، تجزيه نگار (اسان جي سسٽم جو مکيه صارف) ۽ ڪلائنٽ.
ڪم جو عمل هن طرح ٺهيل آهي. تجزيه نگار پنهنجي ماڊل لاءِ هڪ قاعدي فنڪشن ۽ ڊيٽا جي افزودگي واري فنڪشن کي ترقي ڪري ٿو، هن جو ڪوڊ Git مخزن ۾ محفوظ ڪري ٿو، ۽ پنهنجي ماڊل کي ايڊمنسٽريٽر ايپليڪيشن ذريعي ڪلائوڊ تي ترتيب ڏئي ٿو. اچو ته غور ڪيو ته ڪيئن مقرر ڪيل فنڪشن کي سڏيو ويندو ۽ گراهڪن کان ايندڙ درخواستن تي فيصلو ڪيو وڃي:
- ڪلائنٽ ويب سائيٽ تي هڪ فارم ڀريندو آهي ۽ هن جي درخواست موڪليندو آهي ڪنٽرولر ڏانهن. هڪ درخواست جنهن تي فيصلو ڪرڻ جي ضرورت آهي سسٽم ان پٽ تي اچي ٿو ۽ ڊيٽابيس ۾ ان جي اصل شڪل ۾ رڪارڊ ڪيو ويو آهي.
- اڳيون، خام درخواست موڪلي وئي آهي افزودگي لاء، جيڪڏهن ضروري هجي. توھان ابتدائي درخواست کي ڊيٽا سان گڏ ڪري سگھو ٿا ٻئي خارجي خدمتن ۽ اسٽوريج مان. نتيجي ۾ مليل سوال پڻ ڊيٽابيس ۾ محفوظ ٿيل آهي.
- تجزيه نگار فنڪشن شروع ڪيو ويو آهي، جيڪو ان پٽ جي طور تي هڪ بهتر سوال وٺندو آهي ۽ هڪ حل پيدا ڪري ٿو، جيڪو پڻ اسٽوريج ڏانهن لکيو ويو آهي.
اسان فيصلو ڪيو ته MongoDB کي اسان جي سسٽم ۾ اسٽوريج جي طور تي استعمال ڪيو وڃي JSON دستاويزن جي صورت ۾ ڊيٽا جي دستاويز تي مبني اسٽوريج جي ڪري، ڇاڪاڻ ته واڌاري جون خدمتون، بشمول اصل درخواست، REST ڪنٽرولرز ذريعي سمورو ڊيٽا گڏ ڪيو.
تنهن ڪري، اسان وٽ پليٽ فارم تي عمل ڪرڻ لاء XNUMX ڪلاڪ هئا. اسان ڪردارن کي ڪاميابيءَ سان ورهايو؛ هر ٽيم ميمبر کي اسان جي پروجيڪٽ ۾ ذميواري جو پنهنجو علائقو هو:
- تجزيه نگار جي ڪم لاءِ فرنٽ-اينڊ ايڊمن پينل، جنهن ذريعي هو لکت واري اسڪرپٽ جي ورزن ڪنٽرول سسٽم مان قاعدا ڊائون لوڊ ڪري سگهي ٿو، ان پٽ ڊيٽا کي بهتر ڪرڻ لاءِ آپشنز کي منتخب ڪري سگهي ٿو ۽ آن لائن قاعدي اسڪرپٽ کي ايڊٽ ڪري سگهي ٿو.
- Backend منتظم، بشمول REST API اڳيان ۽ VCS سان انضمام.
- گوگل ڪلائوڊ ۾ انفراسٽرڪچر قائم ڪرڻ ۽ ماخذ ڊيٽا کي بهتر ڪرڻ لاءِ هڪ خدمت تيار ڪرڻ.
- قاعدن جي بعد ۾ ترتيب ڏيڻ لاءِ سرور بي ترتيب فريم ورڪ سان منتظم ايپليڪيشن کي ضم ڪرڻ لاءِ هڪ ماڊل.
- سموري سسٽم جي ڪارڪردگي کي جانچڻ لاءِ ضابطن جا اسڪرپٽ ۽ ايندڙ ايپليڪيشنن تي اينالائيٽڪس جو مجموعو (فيصلا ڪيا ويا) حتمي مظاهري لاءِ.
حڪم ڏيڻ شروع ڪريو.
بينڪنگ UI کٽ استعمال ڪندي اسان جو فرنٽ اينڊ انگولر 7 ۾ لکيل هو. منتظم پينل جو آخري نسخو هن طرح نظر آيو:
ٿوري وقت کان وٺي، اسان صرف اهم ڪارڪردگي کي لاڳو ڪرڻ جي ڪوشش ڪئي. ڪبرنيٽس ڪلستر ۾ هڪ فنڪشن کي ترتيب ڏيڻ لاء، اهو ضروري هو ته هڪ واقعو چونڊيو (هڪ خدمت جنهن لاء هڪ قاعدو بادل ۾ مقرر ڪيو وڃي) ۽ فنڪشن جو ڪوڊ جيڪو فيصلو ڪرڻ واري منطق کي لاڳو ڪري ٿو. چونڊيل خدمت لاءِ قاعدي جي هر مقرري لاءِ، اسان هن واقعي جو هڪ لاگ لکيو. منتظم پينل ۾ توهان سڀني واقعن جا لاگ ڏسي سگهو ٿا.
سڀ فنڪشن ڪوڊ ريموٽ Git مخزن ۾ محفوظ ڪيو ويو، جيڪو پڻ منتظم پينل ۾ مقرر ڪيو ويو. ڪوڊ کي ورجائڻ لاءِ، سڀ افعال مخزن جي مختلف شاخن ۾ محفوظ ڪيا ويا. ايڊمن پينل لکت واري اسڪرپٽ ۾ ايڊجسٽمينٽ ڪرڻ جي صلاحيت پڻ فراهم ڪري ٿو، انهي ڪري ته ڪنهن فنڪشن کي پروڊڪشن ۾ لڳائڻ کان اڳ، توهان نه صرف لکيل ڪوڊ چيڪ ڪري سگهو ٿا، پر ضروري تبديليون پڻ ڪري سگهو ٿا.
ضابطن جي ڪمن کان علاوه، اسان انريچمينٽ افعال کي استعمال ڪندي ذريعن جي ڊيٽا کي تدريجي طور تي بهتر ڪرڻ جي صلاحيت کي پڻ لاڳو ڪيو، جنهن جو ڪوڊ پڻ اسڪرپٽ هو جنهن ۾ ڊيٽا گودام ڏانهن وڃڻ، ٽئين پارٽي جي خدمتن کي ڪال ڪرڻ ۽ ابتدائي حساب ڪتاب ڪرڻ ممڪن هو. . اسان جي حل کي ظاهر ڪرڻ لاء، اسان ڪلائنٽ جي رقم جي نشاني جو حساب ڪيو جنهن درخواست کي ڇڏي ڏنو ۽ پنهنجي موبائل آپريٽر کي ٽئين پارٽي REST سروس استعمال ڪندي طئي ڪيو.
پليٽ فارم جو پسمنظر جاوا ۾ لکيو ويو ۽ هڪ اسپرنگ بوٽ ايپليڪيشن جي طور تي لاڳو ڪيو ويو. اسان شروعاتي طور تي انتظامي ڊيٽا کي ذخيرو ڪرڻ لاء پوسٽ گريس استعمال ڪرڻ جي منصوبابندي ڪئي، پر، هيڪاٿون جي حصي جي طور تي، اسان وقت بچائڻ لاء پاڻ کي هڪ سادي H2 تائين محدود ڪرڻ جو فيصلو ڪيو. پس منظر تي، Bitbucket سان انضمام لاڳو ڪيو ويو نسخي جي سوالن جي افزائش افعال ۽ قاعدي اسڪرپٽ. ريموٽ Git مخزن سان انضمام لاءِ، اسان استعمال ڪيو ، جيڪو CLI حڪمن تي هڪ قسم جو لفافي آهي، جيڪو توهان کي آسان سافٽ ويئر انٽرفيس استعمال ڪندي ڪنهن به گٽ هدايتن تي عمل ڪرڻ جي اجازت ڏئي ٿو. تنهنڪري اسان وٽ افزودگي جي ڪمن ۽ ضابطن لاءِ ٻه الڳ مخزن هئا، ۽ سڀئي اسڪرپٽ ڊائريڪٽرن ۾ ورهايل هئا. UI ذريعي اهو ممڪن هو ته مخزن جي هڪ خودمختيار شاخ جي اسڪرپٽ جي تازي ڪمٽ کي چونڊيو. جڏهن ايڊمن پينل ذريعي ڪوڊ ۾ تبديليون ڪيون، تبديل ٿيل ڪوڊ جا ڪمٽ ريموٽ ريپوزٽريز ۾ ٺاهيا ويا.
اسان جي خيال کي لاڳو ڪرڻ لاء، اسان کي مناسب زيربنا جي ضرورت آهي. اسان ڪلائوڊ ۾ اسان جي ڪبرنيٽس ڪلستر کي ترتيب ڏيڻ جو فيصلو ڪيو. اسان جي پسند هئي گوگل ڪلائوڊ پليٽ فارم. فيشن سرور بيس فريم ورڪ ڪبرنيٽس ڪلستر تي نصب ڪيو ويو، جيڪو اسان Gcloud ۾ لڳايو. شروعات ۾، ماخذ ڊيٽا جي واڌاري جي خدمت لاڳو ڪئي وئي هڪ الڳ جاوا ايپليڪيشن جي طور تي هڪ پوڊ ۾ ويڙهيل k8s ڪلستر جي اندر. پر هيڪاٿون جي وچ ۾ اسان جي پروجيڪٽ جي ابتدائي نمائش کان پوءِ، اسان کي سفارش ڪئي وئي ته افزودگي سروس کي وڌيڪ لچڪدار بڻائڻ جو موقعو فراهم ڪيو وڃي ته ايندڙ ايپليڪيشنن جي خام ڊيٽا کي ڪيئن بهتر بڻايو وڃي. ۽ اسان وٽ ڪو به رستو نه هو سواءِ افزودگي جي خدمت کي به سرور کان سواءِ.
فِشن سان ڪم ڪرڻ لاءِ، اسان فِشن CLI استعمال ڪيو، جيڪو لازمي طور تي Kubernetes CLI جي مٿان نصب ڪيو وڃي. k8s ڪلستر ۾ افعال کي ترتيب ڏيڻ بلڪل سادو آهي؛ توهان کي صرف هڪ اندروني رستو تفويض ڪرڻ جي ضرورت آهي ۽ ايندڙ ٽرئفڪ کي اجازت ڏيڻ لاءِ فنڪشن ۾ داخل ٿيڻ جي ضرورت آهي جيڪڏهن ڪلستر کان ٻاهر رسائي گهربل هجي. ھڪڙي فنڪشن کي ترتيب ڏيڻ عام طور تي 10 سيڪنڊن کان وڌيڪ نه وٺندو آھي.
منصوبي جي آخري پريزنٽيشن ۽ اختصار
اهو ڏيکارڻ لاءِ ته اسان جو سسٽم ڪيئن ڪم ڪري ٿو، اسان هڪ سادي فارم رکي ڇڏيو آهي ريموٽ سرور تي جتي توهان بينڪ جي پروڊڪٽس مان هڪ لاءِ درخواست جمع ڪرائي سگهو ٿا. درخواست ڪرڻ لاءِ، توھان کي پنھنجو شروعاتي، ڄمڻ جي تاريخ ۽ فون نمبر داخل ڪرڻو پوندو.
ڪلائنٽ فارم مان ڊيٽا ڪنٽرولر ڏانهن ويو، جيڪو هڪ ئي وقت سڀني دستياب ضابطن لاءِ درخواستون موڪليندو هو، اڳ ۾ ڄاڻايل شرطن جي مطابق ڊيٽا کي بهتر ڪيو، ۽ انهن کي عام اسٽوريج ۾ محفوظ ڪيو. مجموعي طور تي، اسان ٽن ڪمن کي ترتيب ڏنو آهي جيڪي ايندڙ ايپليڪيشنن ۽ 4 ڊيٽا جي واڌاري جي خدمتن تي فيصلا ڪن ٿا. درخواست جمع ڪرڻ کان پوء، ڪلائنٽ اسان جو فيصلو حاصل ڪيو:
انڪار يا منظوري جي اضافي ۾، ڪلائنٽ ٻين شين جي هڪ فهرست پڻ حاصل ڪئي، درخواستون جن لاءِ اسان متوازي طور تي موڪليو. اهو ڪيئن آهي اسان اسان جي پليٽ فارم ۾ ڪراس وڪرو جي امڪان جو مظاهرو ڪيو.
مجموعي طور تي 3 جعلي بينڪ پراڊڪٽس موجود هئا:
- ڪريڊٽ.
- رانديون
- گروي رکڻ.
مظاهري دوران، اسان هر خدمت لاءِ تيار ڪيل افعال ۽ افزودگي اسڪرپٽ ترتيب ڏنيون.
هر قاعدي کي ان پٽ ڊيٽا جي پنهنجي سيٽ جي ضرورت آهي. تنهن ڪري، گروي کي منظور ڪرڻ لاء، اسان ڪلائنٽ جي زڪوڪ نشاني کي ڳڻيو ۽ ان کي قمري ڪئلينڊر جي منطق سان ڳنڍيو. هڪ رانديڪن کي منظور ڪرڻ لاء، اسان چيڪ ڪيو ته ڪلائنٽ اڪثريت جي عمر تائين پهچي چڪو آهي، ۽ قرض جاري ڪرڻ لاء، اسان هڪ درخواست موڪلي هڪ ٻاهرين اوپن سروس کي سيلولر آپريٽر جو تعين ڪرڻ لاء، ۽ ان تي فيصلو ڪيو ويو.
اسان ڪوشش ڪئي ته اسان جي مظاھري کي دلچسپ ۽ انٽرايڪٽو بڻايو وڃي، موجود ھر ڪو اسان جي فارم تي وڃي سگھي ٿو ۽ انھن لاءِ اسان جي افسانوي خدمتن جي دستيابي کي چيڪ ڪري سگھي ٿو. ۽ پريزنٽيشن جي بلڪل آخر ۾، اسان وصول ڪيل ايپليڪيشنن جي تجزيي جو مظاهرو ڪيو، جنهن ۾ ڏيکاريو ويو ته ڪيترا ماڻهو اسان جي خدمت، منظورين جو تعداد، ۽ انڪار ڪيو.
آن لائن تجزياتي گڏ ڪرڻ لاءِ، اسان اضافي طور تي هڪ اوپن سورس BI ٽول لڳايو ۽ ان کي اسان جي اسٽوريج يونٽ ڏانهن ڇڪايو. ميٽابيس توهان کي اجازت ڏئي ٿو اسڪرين ٺاهڻ جي تجزيي سان گڏ ان ڊيٽا تي جيڪا اسان جي دلچسپي آهي؛ توهان کي صرف ڊيٽابيس سان ڪنيڪشن رجسٽر ڪرڻ جي ضرورت آهي، ٽيبل چونڊيو (اسان جي صورت ۾، ڊيٽا گڏ ڪرڻ، جڏهن ته اسان مونگو ڊي بي استعمال ڪيو آهي)، ۽ اسان جي دلچسپي جا شعبا بيان ڪريو. .
نتيجي طور، اسان کي فيصلو ڪرڻ واري پليٽ فارم جو هڪ سٺو پروٽوٽائپ مليو، ۽ مظاهري دوران، هر ٻڌندڙ ذاتي طور تي ان جي ڪارڪردگي کي جانچي سگهي ٿو. هڪ دلچسپ حل، هڪ مڪمل پروٽوٽائپ ۽ هڪ ڪامياب مظاهري اسان کي فتح ڪرڻ جي اجازت ڏني، ٻين ٽيمن جي مضبوط مقابلي جي باوجود. مون کي پڪ آهي ته هر ٽيم جي منصوبي تي هڪ دلچسپ مضمون پڻ لکي سگهجي ٿو.
جو ذريعو: www.habr.com