اهو لڳي ٿو ته آن لائن اشتهارن جي فيلڊ کي ممڪن طور تي ٽيڪنالاجي طور تي ترقي يافته ۽ خودڪار ٿيڻ گهرجي. يقينن، ڇاڪاڻ ته اهڙا ديو ۽ ماهر پنهنجي فيلڊ ۾ Yandex، Mail.Ru، گوگل ۽ فيسبوڪ ڪم ڪري رهيا آهن. پر، جيئن اهو نڪتو، تڪميل جي ڪا حد ناهي ۽ هميشه خودڪار ڪرڻ لاء ڪجهه آهي.
ڪميونيڪيشن گروپ Dentsu Aegis نيٽورڪ روس ڊجيٽل اشتهارسازي مارڪيٽ ۾ سڀ کان وڏو پليئر آهي ۽ ٽيڪنالاجي ۾ فعال طور تي سيڙپڪاري ڪري رهيو آهي، پنهنجي ڪاروباري عمل کي بهتر ۽ خودڪار ڪرڻ جي ڪوشش ڪري رهيو آهي. آن لائن اشتهارن جي مارڪيٽ جي حل ٿيل مسئلن مان هڪ آهي مختلف انٽرنيٽ پليٽ فارمن تان اشتهارن جي مهمن تي انگ اکر گڏ ڪرڻ جو ڪم. هن مسئلي جو حل آخرڪار هڪ پيداوار جي پيداوار جي نتيجي ۾ ڊي 1. ڊجيٽل (DiVan جي طور تي پڙهو)، جنهن جي ترقي بابت اسان ڳالهائڻ چاهيون ٿا.
ڇو؟
1. منصوبي جي شروعات جي وقت، مارڪيٽ تي ھڪڙو تيار ٿيل پراڊڪٽ موجود نه ھو، جيڪو اشتھاراتي مهمن تي انگ اکر گڏ ڪرڻ کي خودڪار ڪرڻ جو مسئلو حل ڪري. مطلب ته اسان کان سواءِ ٻيو ڪو به اسان جي ضرورتن کي پورو نه ڪندو.
خدمتون جهڙوڪ Improvado، Roistat، Supermetrics، SegmentStream پليٽ فارمن، سماجي نيٽ ورڪن ۽ گوگل اينالائيٽڪس سان انضمام پيش ڪن ٿيون، ۽ ان کي پڻ ممڪن بڻائين ٿيون تجزياتي ڊيش بورڊ ٺاهڻ لاءِ آسان تجزيو ۽ اشتهارن جي مهمن جي ڪنٽرول لاءِ. ان کان اڳ جو اسان اسان جي پيداوار کي ترقي ڪرڻ شروع ڪيو، اسان انهن مان ڪجھ سسٽم کي سائيٽن مان ڊيٽا گڏ ڪرڻ لاء استعمال ڪرڻ جي ڪوشش ڪئي، پر، بدقسمتي سان، اهي اسان جا مسئلا حل نه ڪري سگهيا.
بنيادي مسئلو اهو هو ته آزمائشي پراڊڪٽس ڊيٽا جي ذريعن تي ڀاڙين ٿا، سائيٽ جي ترتيب جي انگن اکرن کي ڏيکاري ٿو، ۽ اشتهارن جي مهمن تي مجموعي انگ اکر ڏيڻ جي صلاحيت نه ڏني وئي. اهو طريقو اسان کي مختلف سائيٽن مان انگ اکر ڏسڻ جي اجازت نه ڏني ۽ مجموعي طور تي مهم جي حالت جو تجزيو ڪيو.
هڪ ٻيو عنصر اهو هو ته شروعاتي مرحلن ۾ مصنوعات جو مقصد مغربي مارڪيٽ هو ۽ روسي سائيٽن سان انضمام جي حمايت نه ڪئي. ۽ انهن سائيٽن لاءِ جن سان انضمام تي عمل ڪيو ويو، سڀئي ضروري ميٽرڪ هميشه ڪافي تفصيل سان ڊائون لوڊ نه ڪيا ويا، ۽ انضمام هميشه آسان ۽ شفاف نه هو، خاص طور تي جڏهن اهو ڪجهه حاصل ڪرڻ ضروري هو جيڪو سسٽم انٽرفيس ۾ نه آهي.
عام طور تي، اسان ٽئين پارٽي جي شين کي اپنائڻ جو فيصلو نه ڪيو، پر پنهنجو پاڻ کي ترقي ڪرڻ شروع ڪيو ...
2. آن لائن اشتهارن جي مارڪيٽ سال کان سال وڌي رهي آهي، ۽ 2018 ۾، اشتهارن جي بجيٽ جي لحاظ کان، هن روايتي طور تي سڀ کان وڏي ٽي وي اشتهارن جي مارڪيٽ کي ختم ڪري ڇڏيو. تنهنڪري اتي هڪ پيمانو آهي.
3. ٽي وي اشتهارن جي مارڪيٽ جي برعڪس، جتي ڪمرشل اشتهارن جي وڪري تي اجارداري آهي، اتي ڪيترائي انفرادي مالڪ آهن جيڪي مختلف سائزن جي اشتهارن جي فهرستن جا مالڪ آهن جيڪي انٽرنيٽ تي پنهنجن اشتهارن جي اڪائونٽن سان ڪم ڪري رهيا آهن. جيئن ته هڪ اشتهاري مهم، ضابطي جي طور تي، هڪ ئي وقت تي ڪيترن ئي سائيٽن تي هلندو آهي، اشتهارن جي مهم جي حالت کي سمجهڻ لاء، ضروري آهي ته سڀني سائيٽن کان رپورٽون گڏ ڪرڻ ۽ انهن کي هڪ وڏي رپورٽ ۾ گڏ ڪرڻ لاء، جيڪا سڄي تصوير ڏيکاريندي. ان جو مطلب آهي اصلاح جي صلاحيت آهي.
4. اهو اسان کي لڳي ٿو ته انٽرنيٽ تي اشتهارن جي فهرستن جي مالڪن وٽ اڳ ۾ ئي انفراسٽرڪچر آهي انگ اکر گڏ ڪرڻ ۽ انهن کي اشتهارن جي اڪائونٽن ۾ ڏيکاري ٿو، ۽ اهي هن ڊيٽا لاء API مهيا ڪرڻ جي قابل هوندا. ان جو مطلب اهو آهي ته ٽيڪنالاجي طور تي ممڪن آهي ته ان کي لاڳو ڪرڻ. اچو ته فوري طور تي چئو ته اهو ايترو سادو نه ٿيو.
عام طور تي، منصوبي تي عمل ڪرڻ لاء سڀئي شرطون اسان لاء واضح هئا، ۽ اسان منصوبي کي زندگي ڏيڻ لاء ڊوڙندا هئاسين ...
عظيم منصوبو
شروع ڪرڻ سان، اسان هڪ مثالي نظام جو خواب ٺاهيو:
- 1C ڪارپوريٽ سسٽم مان اشتهارن جي مهمن کي پاڻمرادو لوڊ ڪيو وڃي ان ۾ مختلف پليٽ فارمن تي انهن جي نالن، مدي، بجيٽ ۽ مقررين سان.
- اشتهاري مهم ۾ هر جڳهه لاءِ، سڀئي ممڪن انگ اکر انهن سائيٽن تان پاڻمرادو ڊائون لوڊ ڪيا وڃن جتي پليسمينٽ ٿي رهي آهي، جهڙوڪ نقوش جو تعداد، ڪلڪس، ڏسڻ وغيره.
- ڪجهه اشتهاري مهمن کي ٽئين پارٽي مانيٽرنگ استعمال ڪندي ٽريڪ ڪيو ويندو آهي نام نهاد اشتهار ڏيڻ وارو نظام جهڙوڪ Adriver، Weborama، DCM وغيره. روس ۾ هڪ صنعتي انٽرنيٽ ميٽر پڻ آهي - ميڊياسڪوپ ڪمپني. اسان جي منصوبي جي مطابق، آزاد ۽ صنعتي مانيٽرنگ مان ڊيٽا پڻ خودڪار طور تي لاڳاپيل اشتهارن جي مهمن ۾ لوڊ ٿيڻ گهرجي.
- انٽرنيٽ تي اڪثر اشتهارن جي مهمن جو مقصد مخصوص ٽارگيٽ ڪارناما (خريداري، ڪال، سائن اپ ٽيسٽ ڊرائيو وغيره) تي هوندو آهي، جيڪي گوگل اينالائيٽڪس استعمال ڪندي ٽريڪ ڪيون وينديون آهن، ۽ انگ اکر جيڪي مهم جي صورتحال کي سمجهڻ لاءِ پڻ اهم آهن ۽ اسان جي اوزار ۾ لوڊ ٿيڻ گهرجي.
پهرين لات شيء آهي lumpy
سافٽ ويئر ڊولپمينٽ جي لچڪدار اصولن (چست، سڀ شيون) لاءِ اسان جي وابستگي کي نظر ۾ رکندي، اسان فيصلو ڪيو ته پھريائين ھڪ MVP ٺاھيو ۽ ان کان پوءِ مطلوب مقصد ڏانھن ھلڻ جو ارادو ڪيو.
اسان فيصلو ڪيو ايم وي پي جي بنياد تي اسان جي پيداوار جي بنياد تي DANBo (Dentsu Aegis نيٽورڪ بورڊ)، جيڪو اسان جي گراهڪن جي اشتهارن جي مهمن تي عام معلومات سان گڏ هڪ ويب ايپليڪيشن آهي.
MVP لاء، منصوبي تي عمل ڪرڻ جي لحاظ کان ممڪن حد تائين آسان ڪيو ويو. اسان انضمام لاءِ پليٽ فارمن جي هڪ محدود فهرست چونڊيو آهي. اهي مکيه پليٽ فارم هئا، جهڙوڪ Yandex.Direct، Yandex.Display، RB.Mail، MyTarget، Adwords، DBM، VK، FB، ۽ مکيه اشتهار ڏيڻ وارو نظام Adriver ۽ Weborama.
API ذريعي سائيٽن تي انگن اکرن تائين رسائي حاصل ڪرڻ لاء، اسان هڪ واحد اڪائونٽ استعمال ڪيو. هڪ ڪلائنٽ گروپ مئنيجر جيڪو استعمال ڪرڻ چاهيندو هو خودڪار طريقي سان انگن اکرن جو مجموعو هڪ اشتهاري مهم تي پهريون ڀيرو پليٽ فارم اڪائونٽ تي سائيٽن تي ضروري اشتهارن جي مهمن تائين رسائي فراهم ڪرڻ لاء.
اڳيون سسٽم استعمال ڪندڙ آهي ڊانبو ايڪسل سسٽم ۾ هڪ خاص فارميٽ جي فائل اپلوڊ ڪرڻي هئي، جنهن ۾ پليسمينٽ (اشتهاري مهم، پليٽ فارم، فارميٽ، جڳهه جي مدت، منصوبابندي ڪيل اشارا، بجيٽ، وغيره) ۽ لاڳاپيل اشتهارن جي مهمن جي سڃاڻپ ڪندڙ جي باري ۾ سموري معلومات شامل هئي. سائيٽون ۽ ڳڻپيوڪر adserving سسٽم ۾.
اهو ڏسڻ ۾، واضح طور تي، خوفناڪ:
ڊائون لوڊ ڪيل ڊيٽا کي ڊيٽابيس ۾ محفوظ ڪيو ويو، ۽ پوءِ الڳ خدمتون گڏ ڪيون ويون مهم جي سڃاڻپ ڪندڙ انهن سائيٽن تي ۽ انهن تي ڊائون لوڊ ڪيل انگ اکر.
هر سائيٽ لاءِ، هڪ الڳ ونڊوز سروس لکيل هئي، جيڪا ڏينهن ۾ هڪ ڀيرو سائيٽ جي API ۾ هڪ سروس اڪائونٽ جي تحت ٿيندي هئي ۽ مخصوص مهم جي ID لاءِ شماريات ڊائون لوڊ ڪئي ويندي هئي. ساڳيو ئي شيءِ اشتهار ڏيڻ واري نظام سان ٿيو.
ڊائون لوڊ ڪيل ڊيٽا انٽرفيس تي هڪ ننڍڙي ڪسٽم ڊيش بورڊ جي صورت ۾ ڏيکاريل هئي:
اوچتو اسان لاء، ايم وي پي ڪم ڪرڻ شروع ڪيو ۽ انٽرنيٽ تي اشتهارن جي مهمن تي موجوده انگ اکر ڊائون لوڊ ڪرڻ شروع ڪيو. اسان ڪيترن ئي گراهڪن تي سسٽم لاڳو ڪيو، پر جڏهن ماپ ڪرڻ جي ڪوشش ڪئي، اسان کي سنگين مسئلن جو سامنا ڪيو:
- بنيادي مسئلو سسٽم ۾ لوڊ ڪرڻ لاء ڊيٽا تيار ڪرڻ جي پيچيدگي هئي. انهي سان گڏ، جڳهه جي ڊيٽا کي لوڊ ڪرڻ کان پهريان سختي سان مقرر ٿيل فارميٽ ۾ تبديل ڪيو وڃي. اهو ضروري هو ته ڊائون لوڊ فائل ۾ مختلف سائيٽن جي سڃاڻپ ڪندڙ ادارن کي شامل ڪيو وڃي. اسان کي ان حقيقت سان منهن ڏيڻو پوي ٿو ته ٽيڪنيڪل طور تي غير تربيت يافته استعمال ڪندڙن لاءِ اهو بيان ڪرڻ تمام ڏکيو آهي ته اهي سڃاڻپ ڪندڙ سائيٽ تي ڪٿي ڳولين ۽ ڪٿي فائل ۾ داخل ٿيڻ گهرجن. سائيٽن تي مهم هلائيندڙ ڊپارٽمنٽ ۾ ملازمن جي تعداد ۽ ٽرن اوور کي نظر ۾ رکندي، ان جي نتيجي ۾ اسان جي طرف هڪ وڏي رقم جي مدد ڪئي وئي، جنهن مان اسان بلڪل خوش نه هئاسين.
- هڪ ٻيو مسئلو اهو هو ته سڀني اشتهارن جي پليٽ فارمن وٽ ميکانيزم موجود نه هئا اشتهاري مهمن تائين رسائي ٻين اڪائونٽن تائين پهچائڻ لاءِ. پر ايستائين جو هڪ وفد جي ميکانيزم موجود هئي، نه سڀئي اشتهار ڏيڻ وارا رضامند هئا ته انهن جي مهمن تائين رسائي ٽئين پارٽي جي اڪائونٽن تائين.
- هڪ اهم عنصر اهو ناراضگي هو جيڪو صارفين جي وچ ۾ هن حقيقت جي ڪري پيدا ٿيو ته سڀئي منصوبابندي ڪيل اشارا ۽ جڳهه جي تفصيل جيڪي اهي پهريان ئي اسان جي 1C اڪائونٽنگ سسٽم ۾ داخل ٿين ٿا، انهن کي ٻيهر داخل ٿيڻ گهرجي. ڊانبو.
هن اسان کي اهو خيال ڏنو ته جڳهه بابت معلومات جو بنيادي ذريعو اسان جو 1C سسٽم هجڻ گهرجي، جنهن ۾ سمورو ڊيٽا صحيح ۽ وقت تي داخل ڪيو وڃي (هتي نقطو اهو آهي ته انوائسز 1C ڊيٽا جي بنياد تي ٺاهيا ويا آهن، تنهنڪري ڊيٽا جي صحيح داخلا 1C ۾ هر ڪنهن لاءِ ترجيح آهي KPI). اهڙيءَ طرح نظام جو هڪ نئون تصور اڀري آيو...
تصور
پهرين شيء جيڪو اسان ڪرڻ جو فيصلو ڪيو هو ته انٽرنيٽ تي اشتهارن جي مهمن تي انگ اکر گڏ ڪرڻ لاء سسٽم کي الڳ الڳ پيداوار ۾. ڊي 1. ڊجيٽل.
نئين تصور ۾، اسان ۾ لوڊ ڪرڻ جو فيصلو ڪيو ڊي 1. ڊجيٽل 1C کان انهن جي اندر اشتهارن جي مهمن ۽ جڳهه تي معلومات، ۽ پوء انهن سائيٽن ۽ AdServing سسٽم مان انگ اکر ڪڍو انهن هنڌن تي. اهو سمجهيو ويو ته صارفين لاء زندگي کي خاص طور تي آسان بڻائي (۽، عام طور تي، ڊولپرز لاء وڌيڪ ڪم شامل ڪريو) ۽ مدد جي مقدار کي گھٽائڻ.
پهريون مسئلو جيڪو اسان کي سامهون آيو اهو هڪ تنظيمي نوعيت جو هو ۽ اهو حقيقت سان لاڳاپيل هو ته اسان هڪ اهم يا نشاني نه ڳولي سگهيا آهيون جنهن جي ذريعي اسان مختلف سسٽم جي ادارن کي 1C کان مهمن ۽ مقررين سان مقابلو ڪري سگهون ٿا. حقيقت اها آهي ته اسان جي ڪمپني ۾ پروسيس اهڙي طرح ٺهيل آهي ته اشتهارن جي مهمات مختلف سسٽم ۾ داخل ڪيا ويا آهن مختلف ماڻهن (ميڊيا پلانر، خريداري، وغيره).
هن مسئلي کي حل ڪرڻ لاءِ، اسان کي هڪ منفرد هيش ڪيل ڪيئي ايجاد ڪرڻي هئي، DANBoID، جيڪا مختلف سسٽم ۾ موجود ادارن کي پاڻ ۾ ڳنڍيندي، ۽ اها ڊائون لوڊ ٿيل ڊيٽا سيٽن ۾ بلڪل آساني سان ۽ منفرد طور سڃاڻپ ٿي سگهي ٿي. هي سڃاڻپ ڪندڙ اندروني 1C سسٽم ۾ هر فرد جي مقرري لاءِ ٺاهيل آهي ۽ سڀني سائيٽن تي ۽ سڀني AdServing سسٽم ۾ مهمن، پليسمينٽس ۽ ڳڻپيندڙن ڏانهن منتقل ڪيو ويندو آهي. سڀني هنڌن تي DANBoID لڳائڻ جي مشق کي لاڳو ڪرڻ ۾ ڪجهه وقت لڳو، پر اسان اهو ڪرڻ ۾ ڪامياب ٿي ويا آهيون :)
پوءِ اسان کي معلوم ٿيو ته سڀني سائيٽن وٽ API نه آهي پاڻمرادو انگ اکر گڏ ڪرڻ لاءِ، ۽ ايستائين جن وٽ API آهي، اهو سڀ ضروري ڊيٽا واپس نه ٿو ڪري.
هن اسٽيج تي، اسان انضمام لاءِ پليٽ فارمن جي فهرست کي خاص طور تي گهٽائڻ ۽ مکيه پليٽ فارمن تي ڌيان ڏيڻ جو فيصلو ڪيو آهي جيڪي وڏي اڪثريت جي اشتهاري مهمن ۾ شامل آهن. ھن لسٽ ۾ شامل آھن سڀ کان وڏو رانديگر اشتهارن جي مارڪيٽ ۾ (گوگل، Yandex، Mail.ru)، سماجي نيٽ ورڪ (VK، Facebook، Twitter)، وڏيون AdServing ۽ تجزياتي سسٽم (DCM، Adriver، Weborama، Google Analytics) ۽ ٻيا پليٽ فارم.
اسان جي چونڊيل سائيٽن جي اڪثريت هڪ API هئي جيڪا اسان کي گهربل ميٽرڪس مهيا ڪري ٿي. انهن حالتن ۾ جتي ڪو به API نه هو يا ان ۾ ضروري ڊيٽا شامل نه هجي، اسان اهي رپورٽون استعمال ڪيون جيڪي روزانه اسان جي آفيس جي اي ميل تي ڊيٽا لوڊ ڪرڻ لاءِ موڪليون وينديون هيون (ڪجهه سسٽم ۾ اهڙين رپورٽن کي ترتيب ڏيڻ ممڪن آهي، ٻين ۾ اسان ان تي اتفاق ڪيو آهي. اسان لاء اهڙيون رپورٽون).
جڏهن مختلف سائيٽن جي ڊيٽا جو تجزيو ڪيو، اسان اهو معلوم ڪيو ته ادارن جو درجو مختلف سسٽم ۾ ساڳيو ناهي. ان کان علاوه، معلومات کي مختلف سسٽم کان مختلف تفصيل سان ڊائون لوڊ ڪرڻ جي ضرورت آهي.
هن مسئلي کي حل ڪرڻ لاء، SubDANBoID تصور ترقي ڪئي وئي. SubDANBoID جو خيال بلڪل سادو آهي، اسان سائيٽ تي مهم جي مکيه اداري کي ٺاهيل DANBoID سان نشان لڳايو، ۽ اسان سڀني nested ادارن کي منفرد سائيٽ جي سڃاڻپ ڪندڙ سان اپلوڊ ڪريون ٿا ۽ DANBoID اصول + پهرين سطح جي سڃاڻپ ڪندڙ جي مطابق SubDANBoID ٺاهيون ٿا. nested entity + ٻئي سطح جي سڃاڻپ ڪندڙ nested entity +... هن طريقي سان اسان کي مختلف سسٽم ۾ اشتهاري مهم کي ڳنڍڻ ۽ انهن تي تفصيلي انگ اکر ڊائون لوڊ ڪرڻ جي اجازت ڏني وئي.
اسان کي مختلف پليٽ فارمن تي مهم تائين رسائي جو مسئلو پڻ حل ڪرڻو هو. جيئن اسان مٿي لکيو آهي، هڪ الڳ ٽيڪنيڪل اڪائونٽ تائين مهم تائين رسائي جي نمائندي جو ميکانيزم هميشه لاڳو ناهي. تنهن ڪري، اسان کي انهن ٽوڪن کي اپڊيٽ ڪرڻ لاءِ ٽوڪن ۽ ميڪانيزم استعمال ڪندي OAuth ذريعي خودڪار اختيار ڪرڻ لاءِ هڪ انفراسٽرڪچر تيار ڪرڻو هو.
بعد ۾ مضمون ۾ اسان کي وڌيڪ تفصيل سان حل جي فن تعمير ۽ عمل درآمد جي فني تفصيل بيان ڪرڻ جي ڪوشش ڪئي ويندي.
حل فن تعمير 1.0
جڏهن هڪ نئين پراڊڪٽ جي عمل کي شروع ڪندي، اسان سمجھيو ته اسان کي فوري طور تي نئين سائيٽن کي ڳنڍڻ جو امڪان مهيا ڪرڻ جي ضرورت آهي، تنهنڪري اسان مائڪرو سروس آرڪيٽيڪچر جي رستي تي عمل ڪرڻ جو فيصلو ڪيو.
آرڪيٽيڪچر کي ڊزائين ڪرڻ وقت، اسان سڀني خارجي نظامن - 1C، اشتهارن جي پليٽ فارمن ۽ اشتهار ڏيڻ وارو نظام - الڳ الڳ خدمتن ۾ ڪنيڪٽرن کي الڳ ڪيو.
مکيه خيال اهو آهي ته سائيٽن سان سڀني ڪنيڪٽرن وٽ ساڳيو API آهي ۽ اهي اڊاپٽر آهن جيڪي سائيٽ API کي اسان لاءِ آسان انٽرفيس تي آڻين ٿا.
اسان جي پراڊڪٽ جي مرڪز ۾ هڪ ويب ايپليڪيشن آهي، جيڪا هڪ واحد آهي جيڪا اهڙي طرح ٺهيل آهي ته اها آساني سان خدمتن ۾ ڌار ٿي سگهي ٿي. هي ايپليڪيشن ڊائون لوڊ ڪيل ڊيٽا کي پروسيس ڪرڻ، مختلف سسٽم مان انگ اکر گڏ ڪرڻ ۽ انهن کي سسٽم استعمال ڪندڙن کي پيش ڪرڻ جي ذميوار آهي.
ڪنيڪٽرز ۽ ويب ايپليڪيشن جي وچ ۾ رابطو ڪرڻ لاءِ، اسان کي هڪ اضافي سروس ٺاهڻي هئي، جنهن کي اسان Connector Proxy سڏين ٿا. اهو سروس دريافت ۽ ٽاسڪ شيڊيولر جي ڪم کي انجام ڏئي ٿو. هي خدمت هر رات هر ڪنيڪٽر لاءِ ڊيٽا گڏ ڪرڻ جا ڪم هلائيندي آهي. هڪ سروس پرت لکڻ هڪ پيغام بروکر سان ڳنڍڻ کان وڌيڪ آسان هو، ۽ اسان لاء اهو ضروري هو ته نتيجو جلدي ممڪن طور تي حاصل ڪرڻ لاء.
سادگي ۽ ترقي جي رفتار لاءِ، اسان اهو به فيصلو ڪيو ته سڀئي خدمتون ويب APIs هونديون. هن اهو ممڪن ڪيو ته جلدي هڪ ثبوت جي تصور کي گڏ ڪرڻ ۽ تصديق ڪريو ته سڄو ڊزائن ڪم ڪري ٿو.
هڪ الڳ، بلڪه پيچيده ڪم مختلف اڪائونٽن مان ڊيٽا گڏ ڪرڻ لاءِ پهچ کي ترتيب ڏيڻ هو، جيڪو، جيئن اسان فيصلو ڪيو، استعمال ڪندڙن کي ويب انٽرفيس ذريعي ڪيو وڃي. اهو ٻن الڳ قدمن تي مشتمل آهي: پهريون، صارف OAuth ذريعي اڪائونٽ تائين رسائي لاءِ هڪ ٽوڪن شامل ڪري ٿو، ۽ پوءِ هڪ مخصوص اڪائونٽ مان ڪلائنٽ لاءِ ڊيٽا گڏ ڪرڻ کي ترتيب ڏئي ٿو. OAuth ذريعي هڪ ٽوڪن حاصل ڪرڻ ضروري آهي، ڇاڪاڻ ته، جيئن اسان اڳ ۾ ئي لکيو آهي، اهو هميشه ممڪن ناهي ته سائيٽ تي گهربل اڪائونٽ تائين رسائي فراهم ڪرڻ لاء.
سائيٽن مان اڪائونٽ چونڊڻ لاءِ هڪ آفاقي ميکانيزم ٺاهڻ لاءِ، اسان کي ڪنيڪٽر API ۾ هڪ طريقو شامل ڪرڻو هو جيڪو واپس ڪري ٿو JSON اسڪيما، جيڪو تبديل ٿيل JSONEditor جزو استعمال ڪندي فارم ۾ پيش ڪيو ويو آهي. هن طريقي سان، صارف انهن اڪائونٽن کي چونڊڻ جي قابل هئا جن مان ڊيٽا ڊائون لوڊ ڪرڻ لاء.
سائيٽن تي موجود درخواست جي حدن جي تعميل ڪرڻ لاءِ، اسان ھڪڙي ٽوڪن جي اندر سيٽنگن لاءِ درخواستن کي گڏ ڪريون ٿا، پر اسين متوازي طور تي مختلف ٽوڪن تي عمل ڪري سگھون ٿا.
اسان مونگو ڊي بي کي چونڊيو اسٽوريج جي طور تي لوڊ ٿيل ڊيٽا لاءِ ويب ايپليڪيشن ۽ ڪنيڪٽر ٻنهي لاءِ، جنهن اسان کي اجازت ڏني ته ترقيءَ جي شروعاتي مرحلن تي ڊيٽا جي ڍانچي جي باري ۾ تمام گهڻو پريشان نه ٿئي، جڏهن ايپليڪيشن جو اعتراض ماڊل هر ٻئي ڏينهن تبديل ٿئي ٿو.
اسان جلد ئي معلوم ڪيو ته سڀئي ڊيٽا مونگو ڊي بي ۾ چڱي ريت نه ٺهندا آهن ۽ مثال طور، روزاني انگن اکرن کي لاڳاپيل ڊيٽابيس ۾ ذخيرو ڪرڻ وڌيڪ آسان آهي. تنهن ڪري، ڪنيڪٽرن لاءِ جن جي ڊيٽا جو ڍانچو هڪ تعلقي ڊيٽابيس لاءِ وڌيڪ موزون آهي، اسان PostgreSQL يا MS SQL سرور کي اسٽوريج طور استعمال ڪرڻ شروع ڪيو.
چونڊيل فن تعمير ۽ ٽيڪنالاجيون اسان کي D1.Digital پراڊڪٽ کي نسبتا جلدي ٺاهڻ ۽ لانچ ڪرڻ جي اجازت ڏني. پراڊڪٽ ڊولپمينٽ جي ٻن سالن ۾، اسان سائيٽن تي 23 ڪنيڪٽر ڊولپ ڪيا، ٽئين پارٽي APIs سان ڪم ڪرڻ جو انمول تجربو حاصل ڪيو، مختلف سائيٽن جي نقصانن کان بچڻ لاءِ سکيو، جن مان ھر ھڪ کي پنھنجو ھو، گھٽ ۾ گھٽ 3 جي API جي ترقي ۾ حصو ورتو. سائيٽون، لڳ ڀڳ 15 مهمن تي خودڪار طريقي سان معلومات ڊائون لوڊ ڪئي ۽ 000 کان وڌيڪ جڳھن لاءِ، پراڊڪٽ جي آپريشن تي صارفين کان تمام گھڻو موٽ گڏ ڪيو ۽ ھن راءِ جي بنياد تي، پراڊڪٽ جي مکيه عمل کي ڪيترائي ڀيرا تبديل ڪرڻ ۾ مدد ڪئي.
حل فن تعمير 2.0
ترقي جي شروعات کان ٻه سال گذري ويا آهن ڊي 1. ڊجيٽل. سسٽم تي لوڊ ۾ مسلسل اضافو ۽ وڌيڪ ۽ وڌيڪ نئين ڊيٽا ذريعن جي ابتڙ، تدريجي طور تي موجوده حل جي فن تعمير ۾ مسئلا ظاهر ڪيو.
پهريون مسئلو سائيٽن تان ڊائون لوڊ ڪيل ڊيٽا جي مقدار سان لاڳاپيل آهي. اسان کي هن حقيقت سان منهن ڏيڻو پيو ته سڀ کان وڏي سائيٽن کان تمام ضروري ڊيٽا گڏ ڪرڻ ۽ تازه ڪاري ڪرڻ تمام گهڻو وقت وٺڻ شروع ڪيو. مثال طور، AdRiver adserving سسٽم مان ڊيٽا گڏ ڪرڻ، جنهن سان اسين اڪثر هنڌن جي انگن اکرن کي ٽريڪ ڪندا آهيون، اٽڪل 12 ڪلاڪ لڳن ٿا.
هن مسئلي کي حل ڪرڻ لاءِ، اسان سائيٽن تان ڊيٽا ڊائون لوڊ ڪرڻ لاءِ هر قسم جون رپورٽون استعمال ڪرڻ شروع ڪيون، اسان ڪوشش ڪري رهيا آهيون ته انهن جي API کي سائيٽن سان گڏ ٺاهيو ته جيئن ان جي آپريشن جي رفتار اسان جي ضرورتن کي پورو ڪري، ۽ جيترو ٿي سگهي ڊيٽا ڊائون لوڊ کي متوازي ڪري.
ٻيو مسئلو ڊائون لوڊ ٿيل ڊيٽا جي پروسيسنگ سان لاڳاپيل آهي. ھاڻي، جڏھن نوان جڳھ جا انگ اکر ايندا آھن، ميٽرڪ جي ٻيهر ڳڻپ جو ھڪ گھڻن مرحلن وارو عمل شروع ڪيو ويندو آھي، جنھن ۾ خام ڊيٽا کي لوڊ ڪرڻ، ھر سائيٽ لاءِ مجموعي ميٽرڪ کي ڳڻڻ، مختلف ذريعن مان ڊيٽا کي ھڪ ٻئي سان ڀيٽڻ، ۽ مهم لاءِ سمري ميٽرڪس جي ڳڻپ شامل آھي. اهو ويب ايپليڪيشن تي تمام گهڻو لوڊ ڪري ٿو جيڪو سڀ حساب ڪري ٿو. ڪيترائي ڀيرا، ٻيهر ڳڻپ جي عمل دوران، ايپليڪيشن 10-15 GB جي باري ۾، سرور تي سموري ميموري کي استعمال ڪيو، جيڪو سسٽم سان استعمال ڪندڙن جي ڪم تي تمام گهڻو نقصانڪار اثر پيو.
پراڊڪٽ جي وڌيڪ ترقي لاءِ سڃاڻپ ٿيل مسئلا ۽ امڪاني منصوبا اسان کي ايپليڪيشن آرڪيٽيڪچر تي ٻيهر غور ڪرڻ جي ضرورت ڏانهن راغب ڪيو.
اسان connectors سان شروع ڪيو.
اسان ڏٺو ته سڀئي ڪنيڪٽر هڪ ئي ماڊل مطابق ڪم ڪن ٿا، تنهنڪري اسان هڪ پائپ لائن فريم ورڪ ٺاهيو جنهن ۾ هڪ ڪنيڪٽر ٺاهڻ لاءِ توهان کي صرف مرحلن جي منطق کي پروگرام ڪرڻو هو، باقي آفاقي هو. جيڪڏهن ڪجهه ڪنيڪٽر کي سڌارڻ جي ضرورت آهي، ته پوء اسان ان کي فوري طور تي هڪ نئين فريم ورڪ ڏانهن منتقل ڪريون ٿا ساڳئي وقت جڏهن ڪنيڪٽر بهتر ٿي رهيو آهي.
ساڳئي وقت، اسان ڊاکر ۽ ڪبرنيٽس ڏانهن ڪنيڪٽرن کي ترتيب ڏيڻ شروع ڪيو.
اسان ڪافي عرصي تائين ڪبرنيٽس ڏانهن منتقل ٿيڻ جي منصوبابندي ڪئي، CI/CD سيٽنگن سان تجربا ڪيا، پر صرف ان وقت هلڻ شروع ڪيو جڏهن هڪ ڪنيڪٽر، هڪ غلطي جي ڪري، سرور تي 20 GB کان وڌيڪ ميموري کائڻ شروع ڪيو، عملي طور تي ٻين عملن کي قتل ڪري ڇڏيو. . تحقيق دوران، ڪنيڪٽر کي Kubernetes ڪلستر ڏانهن منتقل ڪيو ويو، جتي اهو آخرڪار رهي، جيتوڻيڪ غلطي کي طئي ڪرڻ کان پوء.
تمام جلدي اسان محسوس ڪيو ته ڪبرنيٽس آسان هو، ۽ ڇهن مهينن اندر اسان 7 ڪنيڪٽر ۽ ڪنيڪٽر پراکسي کي منتقل ڪيو، جيڪي سڀ کان وڌيڪ وسيلا استعمال ڪن ٿا، پيداوار جي ڪلستر ڏانهن.
رابطن جي پٺيان، اسان باقي ايپليڪيشن جي فن تعمير کي تبديل ڪرڻ جو فيصلو ڪيو.
مکيه مسئلو اهو هو ته ڊيٽا ڪنيڪٽرن کان پروڪسز تائين وڏي بيچ ۾ اچي ٿي، ۽ پوءِ DANBoID کي ماريو وڃي ٿو ۽ پروسيسنگ لاءِ مرڪزي ويب ايپليڪيشن ڏانهن موڪليو وڃي ٿو. ميٽرڪ جي حساب سان وڏي تعداد جي ڪري، ايپليڪيشن تي وڏو لوڊ آهي.
اهو پڻ ڪافي ڏکيو ثابت ٿيو انفرادي ڊيٽا گڏ ڪرڻ جي نوڪرين جي صورتحال کي مانيٽر ڪرڻ ۽ هڪ مرڪزي ويب ايپليڪيشن سان ڪنيڪٽرن جي اندر واقع ٿيندڙ غلطين جي رپورٽ ڪرڻ ته جيئن صارف ڏسي سگهن ته ڇا ٿي رهيو آهي ۽ ڇو ڊيٽا گڏ نه ٿي رهي آهي.
انهن مسئلن کي حل ڪرڻ لاءِ، اسان ترقي ڪئي آرڪيٽيڪچر 2.0.
آرڪيٽيڪچر جي نئين ورزن جي وچ ۾ بنيادي فرق اهو آهي ته ويب API جي بدران، اسان استعمال ڪندا آهيون RabbitMQ ۽ MassTransit لائبريري خدمتن جي وچ ۾ پيغامن جي بدلي لاءِ. هن کي ڪرڻ لاء، اسان کي تقريبا مڪمل طور تي Connectors Proxy کي ٻيهر لکڻو پوندو، ان کي ڪنيڪٽر هب ٺاهڻ. نالو تبديل ڪيو ويو ڇاڪاڻ ته خدمت جو بنيادي ڪردار هاڻي ڪنيڪٽرن ۽ پوئتي ڏانهن درخواستن کي اڳتي وڌائڻ ۾ نه آهي، پر ڪنيڪٽرن مان ميٽرڪس جي گڏ ڪرڻ کي منظم ڪرڻ ۾.
مرڪزي ويب ايپليڪيشن کان، اسان سائيٽن جي جڳھن ۽ انگن اکرن بابت معلومات کي الڳ الڳ خدمتن ۾ الڳ ڪيو، جنھن ان کي ممڪن بڻايو غير ضروري حسابن کان نجات حاصل ڪرڻ ۽ صرف اڳ ۾ ئي حساب ڪيل ۽ مجموعي انگن اکرن کي جڳھ جي سطح تي ذخيرو ڪرڻ. اسان خام ڊيٽا جي بنياد تي بنيادي انگ اکر ڳڻڻ لاءِ منطق کي ٻيهر لکيو ۽ بهتر ڪيو.
ساڳئي وقت، اسان سڀني خدمتن ۽ ايپليڪيشنن کي Docker ۽ Kubernetes ڏانهن لڏپلاڻ ڪري رهيا آهيون ته جيئن حل کي پيماني تي آسان ۽ منظم ڪرڻ لاء وڌيڪ آسان بڻائي سگهجي.
اسان هاڻي ڪٿي آهيون
ثبوت جو تصور فن تعمير 2.0 پراڊڪٽ ڊي 1. ڊجيٽل تيار ۽ آزمائشي ماحول ۾ ڪم ڪندڙ ڪنيڪٽرن جي محدود سيٽ سان. اهو سڀ ڪجهه ڪرڻ لاءِ ڇڏي ويو آهي هڪ ٻئي 20 ڪنيڪٽرن کي نئين پليٽ فارم تي ٻيهر لکڻ لاءِ، جانچ ڪريو ته ڊيٽا صحيح طريقي سان لوڊ ڪئي وئي آهي ۽ سڀ ميٽرڪ صحيح حساب سان ڪيا ويا آهن، ۽ پوري ڊيزائن کي پيداوار ۾ رول آئوٽ ڪيو.
حقيقت ۾، اهو عمل بتدريج ٿيندو ۽ اسان کي پراڻن APIs سان پسمانده مطابقت ڇڏڻو پوندو هر شي کي ڪم ڪرڻ لاءِ.
اسان جي فوري منصوبن ۾ نون ڪنيڪٽرن جي ترقي، نون سسٽم سان انضمام ۽ ڳنڍيل سائيٽن تان ڊائون لوڊ ڪيل ڊيٽا جي سيٽ ۾ اضافي ميٽرڪس شامل ڪرڻ ۽ اشتهار ڏيڻ واري سسٽم شامل آهن.
اسان سڀني ايپليڪيشنن کي منتقل ڪرڻ جو منصوبو پڻ ڪريون ٿا، بشمول مرڪزي ويب ايپليڪيشن، Docker ۽ Kubernetes ڏانهن. نئين فن تعمير سان گڏ، هي خاص طور تي استعمال ٿيل وسيلن جي ترتيب، نگراني ۽ ڪنٽرول کي آسان بڻائي ڇڏيندو.
هڪ ٻيو خيال اهو آهي ته استعمال ڪرڻ لاءِ ڊيٽابيس جي چونڊ سان شماريات کي محفوظ ڪرڻ لاءِ، جيڪو هن وقت MongoDB ۾ محفوظ ٿيل آهي. اسان اڳ ۾ ئي ڪيترن ئي نوان ڪنيڪٽرن کي SQL ڊيٽابيس ۾ منتقل ڪيو آهي، پر اتي اهو فرق لڳ ڀڳ اڻڄاتل آهي، ۽ مجموعي انگن اکرن لاءِ، جيڪو هڪ صوابديدي مدت لاءِ درخواست ڪري سگهجي ٿو، فائدو ڪافي سنجيده ٿي سگهي ٿو.
عام طور تي، منصوبا عظيم آهن، اچو ته اڳتي وڌون :)
مضمون جا ليکڪ R&D Dentsu Aegis Network روس: Georgy Ostapenko (ميخائل ڪوٽسڪ ()
جو ذريعو: www.habr.com