"منهنجي بوٽن ۾ هلڻ" - انتظار ڪريو، ڇا اهي نشان لڳل آهن؟

2019 کان وٺي، روس وٽ لازمي ليبلنگ تي قانون آهي. قانون سامان جي سڀني گروهن تي لاڳو نٿو ٿئي، ۽ پراڊڪٽ گروپن لاءِ لازمي ليبلنگ جي قوت ۾ داخل ٿيڻ جون تاريخون مختلف آهن. تمباکو، بوٽ ۽ دوائون سڀ کان پهريان لازمي ليبلنگ جي تابع هونديون؛ ٻيون شيون بعد ۾ شامل ڪيون وينديون، مثال طور، عطر، ڪپڙي ۽ کير. هن قانون سازي جي جدت نئين آئي ٽي حلن جي ترقي جي ترغيب ڏني جيڪا هڪ پراڊڪٽ جي پوري زندگي جي زنجير کي ٽريڪ ڪرڻ ممڪن بڻائي ٿي پيداوار کان وٺي آخري صارف طرفان خريد ڪرڻ تائين، پروسيس ۾ سڀني شرڪت ڪندڙن لاءِ: ٻئي رياست پاڻ ۽ سڀئي تنظيمون جيڪي سامان وڪرو ڪنديون آهن. لازمي ليبلنگ.

X5 ۾، سسٽم جيڪو ليبل ٿيل سامان کي ٽريڪ ڪندو ۽ رياست ۽ سپلائرز سان ڊيٽا مٽائي "مارڪس" سڏيو ويندو آهي. اچو ته توهان کي ٻڌايان ته ڪيئن ۽ ڪنهن ان کي ترقي ڪئي، ان جي ٽيڪنالاجي اسٽيڪ ڇا آهي، ۽ ڇو اسان وٽ ڪجهه آهي جنهن تي فخر ڪجي.

حقيقي هاء لوڊ

"مارڪس" ڪيترن ئي مسئلن کي حل ڪري ٿو، بنيادي طور تي X5 انفارميشن سسٽم ۽ رياستي انفارميشن سسٽم جي وچ ۾ انضمام رابطي آهي ليبل ٿيل مصنوعات (GIS MP) ليبل ٿيل مصنوعات جي حرڪت کي ٽريڪ ڪرڻ لاء. پليٽ فارم اسان پاران وصول ڪيل سڀني ليبلنگ ڪوڊز کي پڻ محفوظ ڪري ٿو ۽ انهن ڪوڊس جي هر شئي جي حرڪت جي پوري تاريخ، ۽ ليبل ٿيل شين جي ٻيهر درجه بندي کي ختم ڪرڻ ۾ مدد ڪري ٿي. تمباکو جي شين جو مثال استعمال ڪندي، جيڪي ليبل ٿيل سامان جي پهرين گروپن ۾ شامل ڪيا ويا آهن، سگريٽ جي صرف هڪ ٽرڪ ۾ اٽڪل 600 پيڪ شامل آهن، جن مان هر هڪ جو پنهنجو منفرد ڪوڊ آهي. ۽ اسان جي سسٽم جو ڪم گودامن ۽ اسٽورن جي وچ ۾ هر اهڙي پيڪ جي تحريڪن جي قانونيت کي ٽريڪ ڪرڻ ۽ تصديق ڪرڻ آهي، ۽ آخرڪار انهن جي وڪرو جي قبوليت جي تصديق ڪري ٿو آخري خريد ڪندڙ کي. ۽ اسان اٽڪل 000 نقد ٽرانزيڪشن في ڪلاڪ رڪارڊ ڪندا آهيون، ۽ اسان کي اهو به رڪارڊ ڪرڻو پوندو ته هر هڪ اهڙي پيڪ اسٽور ۾ ڪيئن پهتو. اهڙيءَ طرح، شين جي وچ ۾ سڀني تحريڪن کي نظر ۾ رکندي، اسان کي هر سال ڏهن بلين رڪارڊ جي توقع آهي.

ٽيم ايم

ان حقيقت جي باوجود ته مارڪس کي X5 جي اندر هڪ پروجيڪٽ سمجهيو ويندو آهي، اهو هڪ پراڊڪٽ جي طريقي سان استعمال ڪيو پيو وڃي. ٽيم اسڪرم جي مطابق ڪم ڪري ٿي. پروجيڪٽ گذريل اونهاري شروع ڪيو، پر پهرين نتيجا صرف آڪٽوبر ۾ آيا - اسان جي پنهنجي ٽيم مڪمل طور تي گڏ ڪئي وئي، سسٽم جي تعميراتي ترقي ڪئي وئي ۽ سامان خريد ڪيو ويو. ھاڻي ٽيم وٽ 16 ماڻھو آھن، جن مان ڇهه پسمانده ۽ فرنٽ اينڊ ڊولپمينٽ ۾ شامل آھن، جن مان ٽي نظام جي تجزيي ۾ شامل آھن. ڇهه وڌيڪ ماڻهو دستي، لوڊ، خودڪار جاچ، ۽ پيداوار جي سار سنڀال ۾ شامل آهن. اضافي طور تي، اسان وٽ هڪ SRE ماهر آهي.

نه رڳو ڊولپر اسان جي ٽيم ۾ ڪوڊ لکندا آهن؛ لڳ ڀڳ سڀئي ماڻهو ڄاڻن ٿا ته پروگرام ڪيئن ڪجي ۽ آٽو ٽيسٽ، لوڊ اسڪرپٽ ۽ آٽوميشن اسڪرپٽ ڪيئن لکجن. اسان ان تي خاص ڌيان ڏيون ٿا، ڇو ته پراڊڪٽ سپورٽ لاءِ اعليٰ سطح جي آٽوميشن جي ضرورت آهي. اسان ھميشه ڪوشش ڪندا آھيون انھن ساٿين کي صلاح ڏيو ۽ مدد ڏيون جن اڳ ۾ پروگرام نه ڪيو آھي، ۽ انھن کي ڪم ڪرڻ لاءِ ڪجھ ننڍا ڪم ڏيو.

ڪرونا وائرس جي وبائي مرض جي ڪري، اسان پوري ٽيم کي ريموٽ ڪم تي منتقل ڪيو؛ ڊولپمينٽ مئنيجمينٽ لاءِ سمورن اوزارن جي دستيابي، جيرا ۽ گيٽ ليب ۾ تعمير ٿيل ورڪ فلو ان مرحلي کي آساني سان پار ڪرڻ ممڪن بڻائي ڇڏيو. دور دراز خرچ ڪيل مھينا ڏيکاريا ويا ته ٽيم جي پيداوار جي نتيجي ۾ نقصان نه ٿيو؛ ڪيترن ئي لاء، ڪم تي آرام وڌي ويو، صرف غائب شيء لائيو مواصلات هئي.

دور دراز ٽيم جي گڏجاڻي

دور دراز ڪم دوران ملاقاتون

حل جي ٽيڪنالاجي اسٽيڪ

X5 لاءِ معياري مخزن ۽ CI/CD اوزار آهي GitLab. اسان ان کي استعمال ڪريون ٿا ڪوڊ اسٽوريج، لڳاتار ٽيسٽنگ، ۽ ڊيپلائيزيشن لاءِ ٽيسٽ ۽ پروڊڪشن سرور. اسان ڪوڊ جي نظرثاني جي مشق پڻ استعمال ڪندا آهيون، جڏهن گهٽ ۾ گهٽ 2 ساٿين کي ضرورت آهي ته ڊولپر طرفان ڪوڊ ۾ ڪيل تبديلين کي منظور ڪيو وڃي. Static code analyzers SonarQube ۽ JaCoCo اسان جي ڪوڊ کي صاف رکڻ ۽ يونٽ ٽيسٽ ڪوريج جي گهربل سطح کي يقيني بڻائڻ ۾ مدد ڪن ٿا. ڪوڊ ۾ سڀني تبديلين کي انهن چيڪن ذريعي وڃڻ گهرجي. سڀئي ٽيسٽ اسڪرپٽ جيڪي دستي طور تي هلائي رهيا آهن بعد ۾ خودڪار آهن.

"مارڪس" پاران ڪاروباري عملن جي ڪامياب عمل لاءِ، اسان کي ڪيترن ئي ٽيڪنيڪي مسئلن کي حل ڪرڻو پيو، هر هڪ جي ترتيب ۾.

ٽاسڪ 1. سسٽم جي افقي اسڪيبلٽي جي ضرورت

هن مسئلي کي حل ڪرڻ لاء، اسان هڪ microservice انداز کي فن تعمير لاء چونڊيو آهي. ساڳئي وقت، خدمتن جي ذميواري جي علائقن کي سمجهڻ تمام ضروري هو. اسان انهن کي ڪاروباري عملن ۾ ورهائڻ جي ڪوشش ڪئي، عملن جي تفصيلن کي مدنظر رکندي. مثال طور، گودام ۾ قبوليت تمام گهڻو نه آهي، پر تمام وڏي پيماني تي آپريشن، جنهن دوران اهو ضروري آهي ته رياست جي ريگيوليٽر کان معلومات حاصل ڪرڻ لاء سامان جي يونٽن بابت معلومات، جنهن جو تعداد هڪ ترسيل ۾ 600000 تائين پهچي ٿو. ، گودام ۾ ھن پراڊڪٽ کي قبول ڪرڻ جي قابليت جي جانچ ڪريو ۽ گودام آٽوميشن سسٽم لاءِ تمام ضروري معلومات واپس ڪريو. پر گودامن مان ترسيل تمام گهڻي شدت آهي، پر ساڳئي وقت ڊيٽا جي ننڍي مقدار سان هلندي آهي.

اسان سڀني خدمتن کي رياستي بنيادن تي لاڳو ڪريون ٿا ۽ اندروني عملن کي مرحلن ۾ ورهائڻ جي ڪوشش به ڪريون ٿا، جنهن کي اسان Kafka Self-topics سڏين ٿا، استعمال ڪري. اهو آهي جڏهن هڪ microservice پاڻ ڏانهن هڪ پيغام موڪلي ٿو، جيڪو توهان کي وڌيڪ وسيلن جي شدت واري عملن تي لوڊ توازن ڪرڻ جي اجازت ڏئي ٿو ۽ پيداوار جي سار سنڀال کي آسان بڻائي ٿو، پر ان کان پوء وڌيڪ.

اسان فيصلو ڪيو ته الڳ الڳ ماڊيولز کي خارجي نظام سان رابطي لاءِ الڳ خدمتن ۾. اهو ممڪن بڻائي ٿو ته بار بار تبديل ٿيندڙ APIs جي خارجي سسٽم جي مسئلي کي حل ڪرڻ، عملي طور تي ڪاروباري ڪارڪردگي سان خدمتن تي ڪو به اثر نه آهي.

سڀئي مائيڪرو سروسز هڪ OpenShift ڪلسٽر ۾ ترتيب ڏنيون ويون آهن، جيڪو حل ڪري ٿو ٻنهي مسئلن کي ماپڻ جو هر مائڪرو سروس ۽ اسان کي اجازت ڏئي ٿو ته ٽئين پارٽي سروس دريافت جا اوزار استعمال نه ڪريون.

ٽاسڪ 2. پليٽ فارم سروسز جي وچ ۾ وڏي لوڊ ۽ تمام گهڻي ڊيٽا مٽائڻ کي برقرار رکڻ جي ضرورت آهي: پروجيڪٽ جي شروعات واري مرحلي ۾ اڪيلو، اٽڪل 600 آپريشن في سيڪنڊ ڪيا ويا آهن. اسان اميد رکون ٿا ته هي قيمت 5000 ops/sec تائين وڌي ويندي جيئن پرچون دڪان اسان جي پليٽ فارم سان ڳنڍيندا آهن.

اهو مسئلو حل ڪيو ويو ڪافڪا ڪلستر کي ترتيب ڏيڻ ۽ تقريبن مڪمل طور تي پليٽ فارم جي مائڪرو سروسز جي وچ ۾ هم وقت ساز رابطي کي ڇڏي ڏيڻ. اهو ضروري آهي ته سسٽم جي گهرج جي هڪ تمام محتاط تجزيي جي ضرورت آهي، ڇاڪاڻ ته نه سڀئي آپريشن غير مطابقت پذير ٿي سگهن ٿيون. ساڳئي وقت، اسان صرف بروکر ذريعي واقعن کي منتقل نه ڪندا آهيون، پر پيغام ۾ سڀني گهربل ڪاروباري معلومات پڻ منتقل ڪندا آهيون. اهڙيء طرح، پيغام جي سائيز ڪيترن ئي سئو kilobytes تائين پهچي سگهي ٿو. ڪافڪا ۾ پيغام جي سائيز جي حد اسان کي پيغام جي سائيز جي صحيح اڳڪٿي ڪرڻ جي ضرورت آهي، ۽ جيڪڏهن ضروري هجي ته، اسين انهن کي ورهائي سگهون ٿا، پر تقسيم منطقي آهي، ڪاروباري عملن سان لاڳاپيل آهي.
مثال طور، اسان سامان کي ورهائيندا آهيون جيڪي ڪار ۾ اچن ٿا باڪس ۾. هم وقت سازي جي عملن لاء، الڳ microservices مختص ڪيا ويا آهن ۽ مڪمل لوڊ جاچ ڪئي ويندي آهي. ڪافڪا کي استعمال ڪندي اسان کي هڪ ٻيو چئلينج پيش ڪيو آهي - اسان جي سروس جي آپريشن کي جانچڻ سان ڪافڪا جي انضمام کي نظر ۾ رکندي اسان جي سڀني يونٽ ٽيسٽ کي هم وقت سازي ڪري ٿي. اسان ايمبيڊڊ ڪافڪا بروکر استعمال ڪندي اسان جي پنهنجي يوٽيلٽي طريقن کي لکڻ سان اهو مسئلو حل ڪيو. اهو انفرادي طريقن لاءِ يونٽ ٽيسٽ لکڻ جي ضرورت کي ختم نٿو ڪري، پر اسان ڪافڪا کي استعمال ڪندي پيچيده ڪيسن کي جانچڻ کي ترجيح ڏيون ٿا.

لاگز کي ٽريڪ ڪرڻ تي تمام گهڻو ڌيان ڏنو ويو ته جيئن انهن جي TraceId وڃائجي نه وڃي جڏهن خدمتن جي آپريشن دوران يا ڪافڪا بيچ سان ڪم ڪرڻ دوران استثنا ٿين ٿا. ۽ جيڪڏهن پهرين سان ڪو خاص مسئلا نه هئا، ته پوءِ ٻئي صورت ۾ اسان کي مجبور ڪيو وڃي ٿو لاگ ان ڪريون سڀئي TraceIds جيڪي بيچ سان آيا آهن ۽ ٽريڪنگ جاري رکڻ لاءِ هڪ کي چونڊيو. پوءِ، جڏهن اصل TraceId ذريعي ڳولهيندي، صارف آساني سان ڳولي سگهندو جنهن سان ٽريڪنگ جاري رهي.

ٽاسڪ 3. ڊيٽا جي وڏي مقدار کي ذخيرو ڪرڻ جي ضرورت آهي: صرف تمباکو لاءِ هر سال 1 بلين کان وڌيڪ ليبل X5 تي اچن ٿا. انهن کي مسلسل ۽ تيز رسائي جي ضرورت آهي. مجموعي طور تي، سسٽم کي انهن ليبل ٿيل سامان جي تحريڪ جي تاريخ جي تقريبا 10 بلين رڪارڊ تي عمل ڪرڻ گهرجي.

ٽيون مسئلو حل ڪرڻ لاءِ، NoSQL ڊيٽابيس MongoDB چونڊيو ويو. اسان 5 نوڊس جو شارڊ ٺاھيو آھي ۽ ھر نوڊ وٽ 3 سرورن جو ريپليڪا سيٽ آھي. هي توهان کي سسٽم کي افقي طور تي ماپڻ جي اجازت ڏئي ٿو، ڪلستر ۾ نوان سرور شامل ڪرڻ، ۽ ان جي غلطي رواداري کي يقيني بڻائي. هتي اسان کي هڪ ٻيو مسئلو پيش آيو - مونگو ڪلستر ۾ ٽرانزيڪشن کي يقيني بڻائڻ، افقي طور تي اسڪيلبل مائڪرو سروسز جي استعمال کي مدنظر رکندي. مثال طور، اسان جي سسٽم جي ڪمن مان هڪ آهي ساڳيا ليبلنگ ڪوڊس سان پروڊڪٽس کي ٻيهر وڪڻڻ جي ڪوششن جي نشاندهي ڪرڻ. هتي، اوورليز غلط اسڪين يا ڪيشيئرز جي غلط آپريشن سان ظاهر ٿين ٿيون. اسان ڏٺا ته اهڙيون نقلون ٿي سگهن ٿيون ٻنهي ۾ هڪ ڪافڪا بيچ جي اندر پروسيس ڪئي پئي وڃي، ۽ ٻن بيچن اندر متوازي عمل ۾. اهڙيءَ طرح، ڊيٽابيس جي پڇا ڳاڇا ڪندي نقلن جي چڪاس ڪرڻ ڪجهه به نه ڏنو. هر هڪ microservice لاءِ، اسان هن سروس جي ڪاروباري منطق جي بنياد تي الڳ الڳ مسئلو حل ڪيو. مثال طور، چيڪن لاءِ، اسان بيچ اندر چيڪ شامل ڪيو ۽ ڊبليڪيٽس جي ظاهر ٿيڻ لاءِ الڳ پروسيسنگ داخل ڪيو.

انهي ڳالهه کي يقيني بڻائڻ لاءِ ته صارفن جو ڪم تاريخ جي عملن سان ڪنهن به طرح تمام اهم شيءِ تي اثر انداز نٿو ٿئي - اسان جي ڪاروباري عملن جي ڪارڪردگيءَ تي، اسان سڀني تاريخي ڊيٽا کي هڪ الڳ ڊيٽابيس سان الڳ خدمت ۾ ورهايو آهي، جيڪا پڻ ڪافڪا ذريعي معلومات حاصل ڪري ٿي. . هن طريقي سان، صارفين هڪ الڳ ٿيل خدمت سان ڪم ڪن ٿيون انهن خدمتن کي متاثر ڪرڻ کان سواءِ جيڪي ڊيٽا تي عمل ڪن ٿيون جاري عملن لاءِ.

ٽاسڪ 4: قطار ٻيهر پروسيسنگ ۽ نگراني:

ورهايل سسٽم ۾، مسئلا ۽ غلطيون ناگزير طور تي ڊيٽابيس، قطار، ۽ خارجي ڊيٽا ذريعن جي دستيابي ۾ پيدا ٿين ٿيون. مارڪس جي صورت ۾، اهڙين غلطين جو ذريعو خارجي نظام سان انضمام آهي. اهو هڪ حل ڳولڻ ضروري هو جيڪو ڪجهه مخصوص وقت ختم ٿيڻ سان غلط جوابن جي بار بار درخواستن جي اجازت ڏئي، پر ساڳئي وقت مکيه قطار ۾ ڪامياب درخواستن جي پروسيسنگ کي نه روڪيو. هن مقصد لاء، نام نهاد "موضوع جي بنياد تي ٻيهر ڪوشش" تصور چونڊيو ويو. هر مکيه موضوع لاءِ، هڪ يا وڌيڪ ٻيهر ڪوشش ڪرڻ وارا موضوع ٺاهيا ويندا آهن جن تي غلط پيغام موڪليا ويندا آهن ۽ ساڳئي وقت مکيه موضوع کان پيغامن جي پروسيسنگ ۾ دير کي ختم ڪيو ويندو آهي. رابطي جو منصوبو -

اهڙي منصوبي کي لاڳو ڪرڻ لاء، اسان کي هيٺين ضرورت آهي: هن حل کي بهار سان گڏ ڪرڻ ۽ ڪوڊ جي نقل کان بچڻ لاء. ويب کي سرفنگ ڪرڻ دوران، اسان وٽ ساڳيو حل آيو جنهن جي بنياد تي Spring BeanPostProccessor، پر اهو اسان لاءِ غير ضروري طور تي بوجھل لڳي رهيو هو. اسان جي ٽيم ھڪڙو آسان حل ٺاھيو آھي جيڪو اسان کي صارفين ٺاهڻ لاءِ بهار جي چڪر ۾ ضم ڪرڻ جي اجازت ڏئي ٿو ۽ اضافي طور تي صارفين کي ٻيهر ڪوشش ڪرڻ جي ڪوشش ڪري ٿو. اسان بهار ٽيم کي اسان جي حل جو هڪ پروٽوٽائپ پيش ڪيو، توهان ان کي ڏسي سگهو ٿا هتي. ٻيهر ڪوشش ڪندڙ صارفين جو تعداد ۽ هر صارف لاءِ ڪوششن جو تعداد پيرا ميٽرز ذريعي ترتيب ڏنو ويو آهي، ڪاروباري عمل جي ضرورتن تي منحصر آهي، ۽ هر شيءِ ڪم ڪرڻ لاءِ، جيڪا رهي ٿي اها تشريح شامل ڪرڻ آهي org.springframework.kafka.annotation.KafkaListener ، جيڪو سڀني اسپرنگ ڊولپرز کان واقف آهي.

جيڪڏهن پيغام تي عمل نه ٿي سگهيو ته سڀني ڪوششن جي ڪوشش کان پوء، اهو DLT (ميل خط موضوع) ڏانهن وڃي ٿو Spring DeadLetterPublishingRecoverer استعمال ڪندي. حمايت جي درخواست تي، اسان هن ڪارڪردگي کي وڌايو ۽ هڪ الڳ سروس ٺاهي جيڪا توهان کي ڊي ايل ٽي، اسٽيڪ ٽريڪ، ٽريس آئي ڊي ۽ انهن بابت ٻي مفيد معلومات ۾ شامل پيغامن کي ڏسڻ جي اجازت ڏئي ٿي. ان کان علاوه، سڀني ڊي ايل ٽي عنوانن تي نگراني ۽ الرٽ شامل ڪيا ويا، ۽ هاڻي، حقيقت ۾، ڊي ايل ٽي موضوع ۾ هڪ پيغام جو ظاهر ٿيڻ هڪ خرابي جو تجزيو ۽ حل ڪرڻ جو هڪ سبب آهي. اهو تمام آسان آهي - موضوع جي نالي سان، اسان فوري طور تي سمجھندا آهيون ته پروسيس جي ڪهڙي مرحلي ۾ مسئلو پيدا ٿيو، جيڪو خاص طور تي ان جي بنيادي سبب جي ڳولا کي تيز ڪري ٿو.

تازو، اسان هڪ انٽرفيس تي عمل ڪيو آهي جيڪو اسان کي انهن جي سببن کي ختم ڪرڻ کان پوء اسان جي حمايت استعمال ڪندي پيغامن کي ٻيهر موڪلڻ جي اجازت ڏئي ٿو (مثال طور، خارجي سسٽم جي ڪارڪردگي کي بحال ڪرڻ) ۽ يقينا، تجزيو لاء لاڳاپيل خرابي قائم ڪرڻ. هي اهو آهي جتي اسان جا خود موضوع هٿ ۾ اچن ٿا: هڪ ڊگهي پروسيسنگ چين کي ٻيهر شروع نه ڪرڻ لاء، توهان ان کي گهربل قدم کان ٻيهر شروع ڪري سگهو ٿا.

پليٽ فارم آپريشن

پليٽ فارم اڳ ۾ ئي پيداواري عمل ۾ آهي، هر روز اسان ترسيل ۽ ترسيل ڪندا آهيون، نوان ورهائڻ وارا مرڪز ۽ اسٽور ڳنڍيندا آهيون. پائلٽ جي حصي جي طور تي، سسٽم ڪم ڪري ٿو "تمباکو" ۽ "جوتا" پيداوار گروپن سان.

اسان جي پوري ٽيم پائلٽ هلائڻ ۾ حصو وٺي ٿي، اڀرندڙ مسئلن جو تجزيو ڪري ٿي ۽ اسان جي پراڊڪٽ کي بهتر بنائڻ لاءِ تجويزون ڏئي ٿي، لاگز کي بهتر ڪرڻ کان وٺي عمل کي تبديل ڪرڻ تائين.

اسان جي غلطين کي ٻيهر نه ڏيڻ لاء، پائلٽ دوران مليا سڀئي ڪيس خودڪار ٽيسٽ ۾ ظاهر ٿيندا آهن. آٽو ٽيسٽ ۽ يونٽ ٽيسٽ جي وڏي تعداد جي موجودگي توهان کي ريگريشن ٽيسٽ ڪرڻ جي اجازت ڏئي ٿي ۽ ڪجهه ڪلاڪن اندر لفظي طور تي هاٽ فڪس انسٽال ڪريو.

هاڻي اسان اسان جي پليٽ فارم کي ترقي ۽ بهتر ڪرڻ جاري رکون ٿا، ۽ مسلسل نئين چئلينج کي منهن ڏيڻ. جيڪڏهن توهان دلچسپي رکو ٿا، اسان هيٺ ڏنل مضمونن ۾ اسان جي حل بابت ڳالهائينداسين.

جو ذريعو: www.habr.com