අන්තර්ජාල වෙළඳ ප්රචාරණ ක්ෂේත්‍රය හැකිතාක් තාක්‍ෂණිකව දියුණු සහ ස්වයංක්රීය විය යුතු බව පෙනේ. ඇත්ත වශයෙන්ම, Yandex, Mail.Ru, Google සහ Facebook වැනි ඔවුන්ගේ ක්ෂේත්රයේ එවැනි දැවැන්තයන් සහ විශේෂඥයින් එහි වැඩ කරන බැවිනි. එහෙත්, එය සිදු වූ පරිදි, පරිපූර්ණත්වයට සීමාවක් නොමැති අතර සෑම විටම ස්වයංක්රීය කිරීමට යමක් තිබේ.
සන්නිවේදන කණ්ඩායම Dentsu Aegis ජාලය රුසියාව ඩිජිටල් වෙළඳ ප්රචාරණ වෙළඳපොලේ විශාලතම ක්‍රීඩකයා වන අතර එහි ව්‍යාපාරික ක්‍රියාවලීන් ප්‍රශස්ත කිරීමට සහ ස්වයංක්රීය කිරීමට උත්සාහ කරමින් තාක්‍ෂණය සඳහා ක්‍රියාකාරීව ආයෝජනය කරයි. මාර්ගගත වෙළඳ ප්රචාරණ වෙළඳපොලේ නොවිසඳුණු එක් ගැටළුවක් වන්නේ විවිධ අන්තර්ජාල වේදිකා වලින් වෙළඳ ප්රචාරණ ව්‍යාපාර පිළිබඳ සංඛ්‍යාලේඛන එකතු කිරීමේ කාර්යය බවට පත්ව ඇත. මෙම ගැටලුවට විසඳුම අවසානයේ නිෂ්පාදනයක් නිර්මාණය කිරීමට හේතු විය D1.ඩිජිටල් (දිවාන් ලෙස කියවන්න), අපට කතා කිරීමට අවශ්ය සංවර්ධනය.
ඇයි?
1. ව්‍යාපෘතිය ආරම්භ කරන අවස්ථාවේ දී, වෙළඳ ප්රචාරණ ව්‍යාපාර පිළිබඳ සංඛ්‍යාලේඛන එකතු කිරීම ස්වයංක්රීය කිරීමේ ගැටලුව විසඳන එක නිමි භාණ්ඩයක් වෙළඳපොලේ නොතිබුණි. මෙයින් අදහස් කරන්නේ අප හැර වෙන කිසිවෙකු අපගේ අවශ්‍යතා සපුරාලන්නේ නැති බවයි.
Improvado, Roistat, Supermetrics, SegmentStream වැනි සේවාවන් වේදිකා, සමාජ ජාල සහ Google Analitycs සමඟ ඒකාබද්ධ කිරීම ලබා දෙන අතර, පහසු විශ්ලේෂණ සහ වෙළඳ ප්රචාරණ ව්‍යාපාර පාලනය කිරීම සඳහා විශ්ලේෂණාත්මක උපකරණ පුවරු තැනීමට ද හැකි වේ. අපි අපගේ නිෂ්පාදනය සංවර්ධනය කිරීම ආරම්භ කිරීමට පෙර, අපි වෙබ් අඩවි වලින් දත්ත රැස් කිරීමට මෙම පද්ධති සමහරක් භාවිතා කිරීමට උත්සාහ කළෙමු, නමුත්, අවාසනාවකට, ඒවාට අපගේ ගැටළු විසඳීමට නොහැකි විය.
ප්රධාන ගැටලුව වූයේ පරීක්ෂා කරන ලද නිෂ්පාදන දත්ත මූලාශ්ර මත පදනම්ව, වෙබ් අඩවිය අනුව ස්ථානගත කිරීමේ සංඛ්‍යාලේඛන ප්‍රදර්ශනය කිරීම සහ ප්රචාරණ ව්‍යාපාර පිළිබඳ සංඛ්‍යාලේඛන එකතු කිරීමේ හැකියාව ලබා නොදීමයි. මෙම ප්‍රවේශය අපට විවිධ අඩවි වලින් සංඛ්‍යාලේඛන එක තැනක දැකීමට සහ සමස්තයක් ලෙස ව්‍යාපාරයේ තත්වය විශ්ලේෂණය කිරීමට ඉඩ දුන්නේ නැත.
තවත් සාධකයක් වූයේ ආරම්භක අදියරේදී නිෂ්පාදන බටහිර වෙළෙඳපොළ ඉලක්ක කරගත් අතර රුසියානු වෙබ් අඩවි සමඟ ඒකාබද්ධ වීමට සහාය නොදැක්වීමයි. ඒකාබද්ධ කිරීම ක්රියාත්මක කරන ලද වෙබ් අඩවි සඳහා, අවශ්ය සියලුම ප්‍රමිතික සෑම විටම ප්‍රමාණවත් විස්තර සහිතව බාගත කර නොමැති අතර, ඒකාබද්ධ කිරීම සැමවිටම පහසු සහ විනිවිද පෙනෙන නොවීය, විශේෂයෙන් පද්ධති අතුරුමුහුණතෙහි නොමැති දෙයක් ලබා ගැනීමට අවශ්ය වූ විට.
පොදුවේ ගත් කල, අපි තෙවන පාර්ශවීය නිෂ්පාදන වලට අනුවර්තනය නොවීමට තීරණය කළ නමුත් අපගේම සංවර්ධනය කිරීමට පටන් ගත්තෙමු.
2. සබැඳි වෙළඳ ප්රචාරණ වෙළඳපොල වසරින් වසර වර්ධනය වන අතර, 2018 දී වෙළඳ ප්රචාරණ අයවැය අනුව, එය සම්ප්‍රදායිකව විශාලතම රූපවාහිනී වෙළඳ ප්රචාරණ වෙළඳපොළ අභිබවා ගියේය. එබැවින් පරිමාණයක් තිබේ.
3. රූපවාහිනී වෙළඳ ප්රචාරණ වෙළඳපොළ මෙන් නොව, වාණිජ වෙළඳ ප්රචාරණ අලෙවිය ඒකාධිකාරී වන අතර, ඔවුන්ගේම වෙළඳ දැන්වීම් ගිණුම් සමඟ අන්තර්ජාලයේ ක්රියාත්මක වන විවිධ ප්‍රමාණයේ වෙළඳ ප්රචාරණ තොගයේ තනි හිමිකරුවන් විශාල ප්‍රමාණයක් ඇත. වෙළඳ ප්රචාරණ ව්‍යාපාරයක්, රීතියක් ලෙස, එකවර අඩවි කිහිපයක ක්රියාත්මක වන බැවින්, වෙළඳ ප්රචාරණ ව්‍යාපාරයේ තත්වය අවබෝධ කර ගැනීම සඳහා, සියලුම වෙබ් අඩවි වලින් වාර්තා එකතු කර ඒවා සම්පූර්ණ පින්තූරය පෙන්වන එක් විශාල වාර්තාවකට ඒකාබද්ධ කිරීම අවශ්ය වේ. මෙයින් අදහස් වන්නේ ප්රශස්තකරණය සඳහා විභවයක් ඇති බවයි.
4. අන්තර්ජාලයේ වෙළඳ දැන්වීම් ඉන්වෙන්ටරි හිමිකරුවන්ට දැනටමත් සංඛ්‍යාලේඛන එකතු කිරීම සහ ඒවා වෙළඳ ප්රචාරණ ගිණුම්වල ප්‍රදර්ශනය කිරීම සඳහා යටිතල පහසුකම් ඇති බව අපට පෙනුන අතර, මෙම දත්ත සඳහා API එකක් ලබා දීමට ඔවුන්ට හැකි වනු ඇත. මෙයින් අදහස් කරන්නේ එය ක්රියාත්මක කිරීමට තාක්ෂණික වශයෙන් හැකි බවයි. එය එතරම් සරල නොවන බව අපි වහාම කියමු.
පොදුවේ ගත් කල, ව්‍යාපෘතිය ක්රියාත්මක කිරීම සඳහා අවශ්ය සියලුම පූර්වාවශ්‍යතා අපට පැහැදිලි වූ අතර, අපි ව්‍යාපෘතිය ජීවයට ගෙන ඒමට දිව ගියෙමු ...
මහා සැලැස්ම
ආරම්භ කිරීම සඳහා, අපි පරමාදර්ශී පද්ධතියක් පිළිබඳ දර්ශනයක් සකස් කළෙමු:
- 1C ආයතනික පද්ධතියෙන් වෙළඳ ප්රචාරණ ව්‍යාපාර ඒවායේ නම්, කාල සීමාවන්, අයවැය සහ විවිධ වේදිකාවල ස්ථානගත කිරීම් සමඟ ස්වයංක්‍රීයව එයට පැටවිය යුතුය.
- වෙළඳ ප්රචාරණ ව්‍යාපාරයක් තුළ එක් එක් ස්ථානගත කිරීම් සඳහා, හැකි සෑම සංඛ්‍යාලේඛනයක්ම ස්ථානගත කිරීම සිදුවන අඩවිවලින් ස්වයංක්‍රීයව බාගත කළ යුතුය, එනම් හැඟීම් ගණන, ක්ලික් කිරීම්, බැලීම් යනාදිය.
- Adriver, Weborama, DCM යනාදී ඊනියා දැන්වීම් පද්ධති මගින් තුන්වන පාර්ශ්ව නිරීක්ෂණ භාවිතයෙන් සමහර වෙළඳ ප්රචාරණ ව්‍යාපාර නිරීක්ෂණය කරනු ලැබේ. රුසියාවේ කාර්මික අන්තර්ජාල මීටරයක් ද ඇත - Mediascope සමාගම. අපගේ සැලැස්මට අනුව, ස්වාධීන සහ කාර්මික අධීක්ෂණ දත්ත ද අනුරූප වෙළඳ ප්රචාරණ ව්‍යාපාරවලට ස්වයංක්‍රීයව පැටවිය යුතුය.
- අන්තර්ජාලයේ බොහෝ වෙළඳ ප්රචාරණ ව්‍යාපාර ඉලක්ක කර ඇත්තේ Google Analytics භාවිතයෙන් ලුහුබඳිනු ලබන ඇතැම් ඉලක්ක ක්‍රියා (මිලදී ගැනීම, ඇමතීම, පරීක්ෂණ ධාවකයක් සඳහා ලියාපදිංචි වීම යනාදිය) ඉලක්ක කර ඇති අතර, ව්‍යාපාරයේ තත්ත්වය අවබෝධ කර ගැනීම සඳහා ද වැදගත් වන සංඛ්‍යාලේඛන සහ අපගේ මෙවලමට පැටවිය යුතුය.
පලවෙනි මගුල තමයි ගුලි
මෘදුකාංග සංවර්ධනයේ නම්‍යශීලී මූලධර්ම සඳහා අපගේ කැපවීම සැලකිල්ලට ගෙන (කඩිසර, සියල්ල), අපි පළමුව MVP එකක් සංවර්ධනය කර පසුව අපේක්ෂිත ඉලක්කය වෙත පුනරාවර්තන ලෙස ගමන් කිරීමට තීරණය කළෙමු.
අපි අපේ නිෂ්පාදනය මත පදනම්ව MVP ගොඩනැගීමට තීරණය කළා DANBo (Dentsu Aegis ජාල මණ්ඩලය), එය අපගේ ගනුදෙනුකරුවන්ගේ ප්රචාරණ ව්‍යාපාර පිළිබඳ සාමාන්‍ය තොරතුරු සහිත වෙබ් යෙදුමකි.
MVP සඳහා, ව්‍යාපෘතිය ක්රියාත්මක කිරීම සම්බන්ධයෙන් හැකි තරම් සරල කරන ලදී. අපි ඒකාබද්ධ කිරීම සඳහා සීමිත වේදිකා ලැයිස්තුවක් තෝරාගෙන ඇත. මේවා Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB වැනි ප්රධාන වේදිකා සහ ප්රධාන දැන්වීම් පද්ධති වන Adriver සහ Weborama විය.
API හරහා අඩවි වල සංඛ්‍යාලේඛන වෙත ප්‍රවේශ වීමට, අපි තනි ගිණුමක් භාවිතා කළෙමු. වෙළඳ ප්රචාරණ ව්‍යාපාරයක ස්වයංක්රීය සංඛ්‍යාලේඛන එකතුවක් භාවිතා කිරීමට අවශ්ය සේවාදායක කණ්ඩායම් කළමනාකරුවෙකුට ප්‍රථමයෙන් අඩවිවල අවශ්ය වෙළඳ ප්රචාරණ ව්‍යාපාර සඳහා ප්‍රවේශය වේදිකා ගිණුමට පැවරීමට සිදු විය.
ඊළඟට පද්ධති පරිශීලකයා DANBo එක්සෙල් පද්ධතියට කිසියම් ආකෘතියක ගොනුවක් උඩුගත කිරීමට සිදු වූ අතර, එහි ස්ථානගත කිරීම (ප්රචාරණ ව්‍යාපාරය, වේදිකාව, ආකෘතිය, ස්ථානගත කිරීමේ කාල සීමාව, සැලසුම් කළ දර්ශක, අයවැය, ආදිය) සහ අදාළ වෙළඳ ප්රචාරණ ව්යාපාරවල හඳුනාගැනීම් පිළිබඳ සියලු තොරතුරු අඩංගු විය. දැන්වීම් පද්ධතිවල අඩවි සහ කවුන්ටර.
එය පෙනුනේ, අවංකවම, භයානක ය:
බාගත කළ දත්ත දත්ත සමුදායක් තුළ සුරකින ලද අතර, පසුව වෙනම සේවාවන් ඔවුන්ගෙන් අඩවිවල ප්‍රචාරක හඳුනාගැනීම් එකතු කර ඒවා පිළිබඳ සංඛ්‍යාලේඛන බාගත කළහ.
සෑම වෙබ් අඩවියක් සඳහාම, වෙනම windows සේවාවක් ලියා ඇති අතර, එය දිනකට වරක් වෙබ් අඩවියේ API හි එක් සේවා ගිණුමක් යටතේ ගොස් නිශ්චිත ප්‍රචාරක හැඳුනුම්පත් සඳහා සංඛ්‍යාලේඛන බාගත කර ඇත. දැන්වීම් පද්ධති සම්බන්ධයෙන්ද එයම සිදු විය.
බාගත කළ දත්ත කුඩා අභිරුචි උපකරණ පුවරුවක ආකාරයෙන් අතුරු මුහුණතෙහි දර්ශනය විය:
අප සඳහා අනපේක්ෂිත ලෙස, MVP වැඩ කිරීමට පටන් ගත් අතර අන්තර්ජාලයේ වෙළඳ ප්රචාරණ ව්‍යාපාර පිළිබඳ වත්මන් සංඛ්‍යාලේඛන බාගත කිරීම ආරම්භ කළේය. අපි සේවාදායකයන් කිහිප දෙනෙකු මත පද්ධතිය ක්රියාත්මක කළෙමු, නමුත් පරිමාණය කිරීමට උත්සාහ කරන විට, අපට බරපතල ගැටළු ඇති විය:
- ප්රධාන ගැටළුව වූයේ පද්ධතියට පැටවීම සඳහා දත්ත සකස් කිරීමේ සංකීර්ණත්වයයි. එසේම, ස්ථානගත කිරීමේ දත්ත පැටවීමට පෙර දැඩි ස්ථාවර ආකෘතියකට පරිවර්තනය කිරීමට සිදු විය. බාගැනීම් ගොනුවේ විවිධ අඩවි වලින් ආයතන හඳුනාගැනීම් ඇතුළත් කිරීම අවශ්ය විය. තාක්‍ෂණිකව නුපුහුණු පරිශීලකයින්ට වෙබ් අඩවියේ මෙම හඳුනාගැනීම් සොයාගත හැක්කේ කොතැනින්ද සහ ඒවා ගොනුවේ ඇතුළත් කළ යුත්තේ කොතැනද යන්න පැහැදිලි කිරීම ඉතා අපහසු බව අපි මුහුණ දී සිටිමු. දෙපාර්තමේන්තු වල සේවක සංඛ්‍යාව අඩවිවල ව්‍යාපාර පවත්වාගෙන යාම සහ පිරිවැටුම සැලකිල්ලට ගත් විට, මෙය අපගේ පැත්තෙන් විශාල සහයෝගයක් ලබා දීමට හේතු වූ අතර එය අප කිසිසේත්ම සතුටු නොවීය.
- තවත් ගැටළුවක් වූයේ සියලුම වෙළඳ ප්රචාරණ වේදිකාවල වෙනත් ගිණුම් වෙත ප්රචාරණ ව්‍යාපාර සඳහා ප්‍රවේශය පැවරීමේ යාන්ත්‍රණයක් නොතිබීමයි. නමුත් නියෝජිත යාන්ත්‍රණයක් පැවතියද, සියළුම දැන්වීම්කරුවන් තෙවන පාර්ශ්ව ගිණුම් වෙත තම ප්රචාරණ කටයුතු සඳහා ප්‍රවේශය ලබා දීමට කැමති වූයේ නැත.
- වැදගත් සාධකයක් වූයේ ඔවුන් දැනටමත් අපගේ 1C ගිණුම්කරණ පද්ධතියට ඇතුළත් කර ඇති සියලුම සැලසුම්ගත දර්ශක සහ ස්ථානගත කිරීම් විස්තර ඔවුන් නැවත ඇතුළත් කළ යුතු බවට පරිශීලකයින් අතර ඇති වූ කෝපයයි. DANBo.
ස්ථානගත කිරීම පිළිබඳ මූලික තොරතුරු මූලාශ්රය අපගේ 1C පද්ධතිය විය යුතු බවට මෙය අපට අදහසක් ලබා දුන්නේය, සියලු දත්ත නිවැරදිව හා නියමිත වේලාවට ඇතුළත් කරනු ලැබේ (මෙහි කාරණය වන්නේ 1C දත්ත මත පදනම්ව ඉන්වොයිසි ජනනය වන බැවින් 1C වෙත දත්ත නිවැරදිව ඇතුළත් කිරීමයි. KPI සෑම කෙනෙකුටම ප්‍රමුඛතාවයකි). ක්‍රමයේ නව සංකල්පයක් බිහිවූයේ මෙලෙසිනි...
සංකල්පය
අප විසින් සිදු කිරීමට තීරණය කළ පළමු දෙය නම් අන්තර්ජාලයේ ප්රචාරණ ව්‍යාපාර පිළිබඳ සංඛ්‍යාලේඛන එකතු කිරීමේ පද්ධතිය වෙනම නිෂ්පාදනයක් ලෙස වෙන් කිරීමයි - D1.ඩිජිටල්.
නව සංකල්පය තුළ, අපි පැටවීමට තීරණය කළා D1.ඩිජිටල් 1C සිට ඒවා තුළ ප්රචාරණ ව්‍යාපාර සහ ස්ථානගත කිරීම් පිළිබඳ තොරතුරු, පසුව මෙම ස්ථානගත කිරීම් වෙත අඩවි සහ AdServing පද්ධති වෙතින් සංඛ්‍යාලේඛන ලබා ගන්න. මෙය පරිශීලකයින් සඳහා ජීවිතය සැලකිය යුතු ලෙස සරල කිරීමට (සහ, සුපුරුදු පරිදි, සංවර්ධකයින්ට වැඩි වැඩ එකතු කිරීමට) සහ ආධාරක ප්රමාණය අඩු කිරීමට නියමිත විය.
අප මුහුණ දුන් පළමු ගැටළුව ආයතනික ස්වභාවයක් වූ අතර එය 1C සිට ප්රචාරණ සහ ස්ථානගත කිරීම් සමඟ විවිධ පද්ධතිවල ආයතන සංසන්දනය කළ හැකි යතුරක් හෝ ලකුණක් අපට සොයාගත නොහැකි වීම හා සම්බන්ධ විය. කාරණය නම් අපගේ සමාගමෙහි ක්‍රියාවලිය සැලසුම් කර ඇත්තේ විවිධ පුද්ගලයින් (මාධ්‍ය සැලසුම්කරුවන්, මිලදී ගැනීම් ආදිය) විවිධ පද්ධතිවලට ප්රචාරණ ව්‍යාපාර ඇතුළත් වන ආකාරයට ය.
මෙම ගැටළුව විසඳීම සඳහා, විවිධ පද්ධතිවල ඇති ආයතන එකට සම්බන්ධ කරන සහ බාගත කළ දත්ත කට්ටලවල තරමක් පහසුවෙන් සහ අනන්‍ය ලෙස හඳුනාගත හැකි අද්විතීය හැෂ් යතුරක් වන DANBoID සොයා ගැනීමට අපට සිදු විය. මෙම හැඳුනුම්කාරකය එක් එක් ස්ථානගත කිරීම් සඳහා අභ්‍යන්තර 1C පද්ධතිය තුළ ජනනය කර ඇති අතර සියලුම අඩවිවල සහ සියලුම AdServing පද්ධතිවල ප්රචාරණ, ස්ථානගත කිරීම් සහ කවුන්ටර වෙත මාරු කරනු ලැබේ. සියලුම ස්ථානගත කිරීම් සඳහා DANBoID තැබීමේ පුරුද්ද ක්රියාත්මක කිරීමට යම් කාලයක් ගත වූ නමුත් අපි එය කිරීමට සමත් විය :)
එවිට අපි සොයාගත්තා සෑම වෙබ් අඩවියකම ස්වයංක්‍රීයව සංඛ්‍යාලේඛන එකතු කිරීම සඳහා API එකක් නොමැති බවත්, API ඇති ඒවා පවා අවශ්ය සියලුම දත්ත ලබා නොදෙන බවත්.
මෙම අදියරේදී, අපි ඒකාබද්ධ කිරීම සඳහා වේදිකා ලැයිස්තුව සැලකිය යුතු ලෙස අඩු කිරීමට සහ වෙළඳ ප්රචාරණ ව්යාපාරවල අතිමහත් බහුතරයකට සම්බන්ධ වන ප්රධාන වේදිකාවන් කෙරෙහි අවධානය යොමු කිරීමට තීරණය කළෙමු. මෙම ලැයිස්තුවට වෙළඳ ප්රචාරණ වෙළඳපොලේ (Google, Yandex, Mail.ru), සමාජ ජාල (VK, Facebook, Twitter), ප්රධාන AdServing සහ විශ්ලේෂණ පද්ධති (DCM, Adriver, Weborama, Google Analytics) සහ වෙනත් වේදිකා වල විශාලතම ක්‍රීඩකයින් ඇතුළත් වේ.
අප තෝරාගත් අඩවිවලින් බහුතරයක අපට අවශ්ය ප්‍රමිතික සපයන API එකක් තිබුණි. API නොමැති හෝ එහි අවශ්ය දත්ත නොමැති අවස්ථාවලදී, දත්ත පූරණය කිරීම සඳහා අපි අපගේ කාර්යාල විද්‍යුත් තැපෑලට දිනපතා එවන වාර්තා භාවිතා කළෙමු (සමහර පද්ධතිවල එවැනි වාර්තා වින්‍යාස කිරීමට හැකි වේ, අනෙක් ඒවා එවැනි වාර්තා සංවර්ධනය කිරීමට අපි එකඟ විය. අපි වෙනුවෙන්).
විවිධ අඩවි වලින් දත්ත විශ්ලේෂණය කිරීමේදී, විවිධ පද්ධතිවල ආයතනවල ධුරාවලිය සමාන නොවන බව අපට පෙනී ගියේය. එපමණක් නොව, විවිධ පද්ධති වලින් විවිධ විස්තර වලින් තොරතුරු බාගත කිරීම අවශ්ය වේ.
මෙම ගැටළුව විසඳීම සඳහා SubDANBoID සංකල්පය සංවර්ධනය කරන ලදී. SubDANBoID අදහස තරමක් සරල ය, අපි වෙබ් අඩවියේ ප්රචාරණ ව්‍යාපාරයේ ප්රධාන ආයතනය ජනනය කරන ලද DANBoID සමඟ සලකුණු කරමු, සහ අපි සියලුම කැදලි ආයතන අද්විතීය අඩවි හඳුනාගැනීම් සමඟ උඩුගත කර DANBoID මූලධර්මය + පළමු මට්ටමේ හඳුනාගැනීම අනුව SubDANBoID සාදන්නෙමු. nested entity + දෙවන මට්ටමේ කැදැලි ආයතනයේ හඳුනාගැනීම +... මෙම ප්‍රවේශය අපට විවිධ පද්ධතිවල වෙළඳ ප්රචාරණ ව්‍යාපාර සම්බන්ධ කිරීමට සහ ඒවා පිළිබඳ සවිස්තරාත්මක සංඛ්‍යාලේඛන බාගත කිරීමට ඉඩ ලබා දුන්නේය.
විවිධ වේදිකාවල ප්‍රචාරක ව්‍යාපාරවලට ප්‍රවේශ වීමේ ගැටලුව ද අපට විසඳා ගැනීමට සිදු විය. අප ඉහත ලියා ඇති පරිදි, වෙනම තාක්ෂණික ගිණුමකට ව්‍යාපාරයකට ප්‍රවේශය පැවරීමේ යාන්ත්‍රණය සැමවිටම අදාළ නොවේ. එබැවින්, මෙම ටෝකන යාවත්කාලීන කිරීම සඳහා ටෝකන සහ යාන්ත්‍රණ භාවිතා කරමින් OAuth හරහා ස්වයංක්රීය අවසරය සඳහා යටිතල පහසුකම් සංවර්ධනය කිරීමට අපට සිදු විය.
පසුව ලිපියේ අපි විසඳුමේ ගෘහ නිර්මාණ ශිල්පය සහ ක්රියාත්මක කිරීමේ තාක්ෂණික විස්තර වඩාත් විස්තරාත්මකව විස්තර කිරීමට උත්සාහ කරමු.
විසඳුම් ගෘහ නිර්මාණ ශිල්පය 1.0
නව නිෂ්පාදනයක් ක්රියාත්මක කිරීම ආරම්භ කරන විට, නව වෙබ් අඩවි සම්බන්ධ කිරීමේ හැකියාව වහාම ලබා දිය යුතු බව අපි තේරුම් ගත්තෙමු, එබැවින් අපි ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පයේ මාවත අනුගමනය කිරීමට තීරණය කළෙමු.
ගෘහ නිර්මාණ ශිල්පය සැලසුම් කිරීමේදී, අපි සියලුම බාහිර පද්ධති සඳහා සම්බන්ධක - 1C, වෙළඳ ප්රචාරණ වේදිකා සහ ප්රචාරණ පද්ධති - වෙනම සේවා වලට වෙන් කළෙමු.
ප්රධාන අදහස නම්, වෙබ් අඩවි වලට ඇති සියලුම සම්බන්ධක වලට එකම API ඇති අතර එය අපට පහසු අතුරු මුහුණතක් වෙත Site API ගෙන එන ඇඩප්ටර වේ.
අපගේ නිෂ්පාදනයේ මධ්‍යයේ වෙබ් යෙදුමක් ඇත, එය පහසුවෙන් සේවාවලට විසුරුවා හැරිය හැකි ආකාරයෙන් නිර්මාණය කර ඇති ඒකලිතයකි. බාගත කළ දත්ත සැකසීම, විවිධ පද්ධති වලින් සංඛ්‍යාලේඛන එකතු කිරීම සහ ඒවා පද්ධති පරිශීලකයින්ට ඉදිරිපත් කිරීම සඳහා මෙම යෙදුම වගකිව යුතුය.
සම්බන්ධක සහ වෙබ් යෙදුම අතර සන්නිවේදනය කිරීමට, අපට අතිරේක සේවාවක් නිර්මාණය කිරීමට සිදු විය, එය අපි Connector Proxy ලෙස හැඳින්වුවෙමු. එය Service Discovery සහ Task Scheduler හි කාර්යයන් ඉටු කරයි. මෙම සේවාව සෑම රාත්‍රියකම එක් එක් සම්බන්ධකය සඳහා දත්ත රැස් කිරීමේ කාර්යයන් ක්රියාත්මක කරයි. පණිවුඩ තැරැව්කරුවකු සම්බන්ධ කිරීමට වඩා සේවා ස්ථරයක් ලිවීම පහසු වූ අතර, හැකි ඉක්මනින් ප්රතිඵලය ලබා ගැනීම අපට වැදගත් විය.
සංවර්ධනයේ සරල බව සහ වේගය සඳහා, සියලුම සේවාවන් Web API බවට පත් කිරීමට ද අපි තීරණය කළෙමු. මෙමගින් සංකල්ප පිළිබඳ සාක්ෂියක් ඉක්මනින් එකලස් කිරීමට සහ සම්පූර්ණ සැලසුම ක්රියාත්මක වන බව තහවුරු කිරීමට හැකි විය.
වෙනම, තරමක් සංකීර්ණ කාර්යයක් වූයේ විවිධ ගිණුම් වලින් දත්ත රැස් කිරීමට ප්‍රවේශය සැකසීමයි, එය අප තීරණය කළ පරිදි, වෙබ් අතුරු මුහුණත හරහා පරිශීලකයින් විසින් සිදු කළ යුතුය. එය වෙනම පියවර දෙකකින් සමන්විත වේ: පළමුව, පරිශීලකයා OAuth හරහා ගිණුමට ප්‍රවේශ වීමට ටෝකනයක් එක් කරයි, පසුව විශේෂිත ගිණුමකින් සේවාදායකයා සඳහා දත්ත එකතු කිරීම වින්‍යාස කරයි. OAuth හරහා ටෝකනයක් ලබා ගැනීම අවශ්ය වන්නේ, අප දැනටමත් ලියා ඇති පරිදි, වෙබ් අඩවියේ අපේක්ෂිත ගිණුමට ප්‍රවේශය පැවරීමට සැමවිටම නොහැකි බැවිනි.
අඩවි වලින් ගිණුමක් තෝරා ගැනීම සඳහා විශ්වීය යාන්ත්‍රණයක් නිර්මාණය කිරීම සඳහා, අපට JSON Schema නැවත ලබා දෙන සම්බන්ධක API වෙත ක්‍රමයක් එක් කිරීමට සිදු විය, එය වෙනස් කරන ලද JSONEditor සංරචකයක් භාවිතයෙන් පෝරමයකට විදහා දක්වයි. මේ ආකාරයෙන්, පරිශීලකයින්ට දත්ත බාගත කළ යුතු ගිණුම් තෝරා ගැනීමට හැකි විය.
අඩවිවල පවතින ඉල්ලීම් සීමාවන්ට අනුකූල වීමට, අපි එක් ටෝකනයක් තුළ සැකසුම් සඳහා ඉල්ලීම් ඒකාබද්ධ කරමු, නමුත් අපට සමාන්තරව විවිධ ටෝකන සැකසීමට හැකිය.
අපි MongoDB වෙබ් යෙදුම් සහ සම්බන්ධක යන දෙකම සඳහා පටවන ලද දත්ත සඳහා ගබඩාවක් ලෙස තෝරා ගත්තෙමු, එමඟින් සෑම දිනකම යෙදුමේ වස්තු ආකෘතිය වෙනස් වන විට, සංවර්ධනයේ ආරම්භක අදියරේදී දත්ත ව්‍යුහය ගැන ඕනෑවට වඩා කරදර නොවීමට අපට ඉඩ සලසයි.
MongoDB හි සියලුම දත්ත හොඳින් නොගැලපෙන බව අපි ඉක්මනින්ම සොයා ගත්තෙමු, උදාහරණයක් ලෙස, දෛනික සංඛ්‍යාලේඛන සම්බන්ධක දත්ත ගබඩාවක ගබඩා කිරීම වඩාත් පහසු වේ. එබැවින්, සම්බන්ධක දත්ත සමුදායක් සඳහා දත්ත ව්‍යුහය වඩාත් සුදුසු සම්බන්ධක සඳහා, අපි PostgreSQL හෝ MS SQL සේවාදායකය ගබඩාව ලෙස භාවිතා කිරීමට පටන් ගත්තෙමු.
තෝරාගත් ගෘහ නිර්මාණ ශිල්පය සහ තාක්ෂණයන් සාපේක්ෂව ඉක්මනින් D1.Digital නිෂ්පාදනය ගොඩනැගීමට සහ දියත් කිරීමට අපට ඉඩ සලසයි. නිෂ්පාදන සංවර්ධනයේ වසර දෙකක කාලයක් තුළ, අපි අඩවි වලට සම්බන්ධක 23 ක් සංවර්ධනය කළෙමු, තෙවන පාර්ශවීය API සමඟ වැඩ කිරීමේ අගනා අත්දැකීම් ලබා ගත්තෙමු, විවිධ අඩවි වල අන්තරායන් වළක්වා ගැනීමට ඉගෙන ගත් අතර, ඒ සෑම එකක්ම තමන්ගේම වූ අතර, අවම වශයෙන් 3 API සංවර්ධනයට දායක විය. අඩවි, ප්රචාරණ 15කට ආසන්න ප්‍රමාණයක සහ ස්ථානගත කිරීම් 000කට වැඩි ප්‍රමාණයක තොරතුරු ස්වයංක්‍රීයව බාගත කර, නිෂ්පාදනයේ ක්‍රියාකාරිත්වය පිළිබඳ පරිශීලකයින්ගෙන් බොහෝ ප්‍රතිපෝෂණ එකතු කර, මෙම ප්‍රතිපෝෂණය මත පදනම්ව නිෂ්පාදනයේ ප්රධාන ක්‍රියාවලිය කිහිප වතාවක් වෙනස් කිරීමට සමත් විය.
විසඳුම් ගෘහ නිර්මාණ ශිල්පය 2.0
සංවර්ධනය ආරම්භ කර වසර දෙකක් ගත වී ඇත D1.ඩිජිටල්. පද්ධතියේ බර නිරන්තරයෙන් වැඩිවීම සහ වැඩි වැඩියෙන් නව දත්ත මූලාශ්ර මතුවීම, පවතින විසඳුම් ගෘහ නිර්මාණ ශිල්පයේ ගැටළු ක්රමයෙන් අනාවරණය විය.
පළමු ගැටළුව අඩවි වලින් බාගත කර ඇති දත්ත ප්රමාණය හා සම්බන්ධ වේ. විශාලතම වෙබ් අඩවි වලින් අවශ්ය සියලුම දත්ත එකතු කිරීම සහ යාවත්කාලීන කිරීම සඳහා වැඩි කාලයක් ගත වීමට පටන් ගත් බවට අපට මුහුණ දීමට සිදු විය. උදාහරණයක් ලෙස, අපි බොහෝ ස්ථානගත කිරීම් සඳහා සංඛ්‍යාලේඛන නිරීක්ෂණය කරන AdRiver දැන්වීම් පද්ධතියෙන් දත්ත රැස් කිරීමට පැය 12ක් පමණ ගත වේ.
මෙම ගැටළුව විසඳීම සඳහා, අපි වෙබ් අඩවි වලින් දත්ත බාගත කිරීම සඳහා සියලු වර්ගවල වාර්තා භාවිතා කිරීමට පටන් ගත්තෙමු, අපි ඔවුන්ගේ API අඩවි සමඟ එක්ව සංවර්ධනය කිරීමට උත්සාහ කරමු, එවිට එහි ක්‍රියාකාරිත්වයේ වේගය අපගේ අවශ්‍යතා සපුරාලන අතර දත්ත බාගත කිරීම හැකිතාක් දුරට සමාන්තර කරන්න.
තවත් ගැටළුවක් බාගත කළ දත්ත සැකසීමට සම්බන්ධ වේ. දැන්, නව ස්ථානගත කිරීමේ සංඛ්‍යාලේඛන පැමිණි විට, ප්‍රමිතික නැවත ගණනය කිරීමේ බහු-අදියර ක්‍රියාවලියක් දියත් කෙරේ, එයට අමු දත්ත පූරණය කිරීම, එක් එක් වෙබ් අඩවිය සඳහා එකතු කළ ප්‍රමිතික ගණනය කිරීම, විවිධ ප්‍රභවයන්ගෙන් දත්ත එකිනෙකා සමඟ සංසන්දනය කිරීම සහ ව්‍යාපාරය සඳහා සාරාංශ ප්‍රමිතික ගණනය කිරීම ඇතුළත් වේ. මෙය සියලු ගණනය කිරීම් සිදු කරන වෙබ් යෙදුම මත විශාල බරක් ඇති කරයි. කිහිප වතාවක්ම, නැවත ගණනය කිරීමේ ක්රියාවලියේදී, යෙදුම සේවාදායකයේ සියලුම මතකය පරිභෝජනය කරයි, 10-15 GB පමණ වන අතර, පද්ධතිය සමඟ පරිශීලකයින්ගේ වැඩ කටයුතු සඳහා වඩාත්ම අහිතකර බලපෑමක් ඇති විය.
නිෂ්පාදනයේ තවදුරටත් සංවර්ධනය සඳහා හඳුනාගත් ගැටළු සහ අභිලාෂකාමී සැලසුම් යෙදුම් ගෘහ නිර්මාණ ශිල්පය නැවත සලකා බැලීමේ අවශ්‍යතාවයට හේතු විය.
අපි සම්බන්ධක සමඟ ආරම්භ කළා.
සියලුම සම්බන්ධක එකම ආකෘතියට අනුව ක්‍රියා කරන බව අපි දුටුවෙමු, එබැවින් අපි සම්බන්ධකයක් නිර්මාණය කිරීම සඳහා නල මාර්ග රාමුවක් ගොඩනඟා ඇත්තේ ඔබට පියවරවල තර්කනය පමණක් වැඩසටහන්ගත කළ යුතුය, ඉතිරිය විශ්වීය විය. සමහර සම්බන්ධකයක් වැඩිදියුණු කිරීමට අවශ්ය නම්, සම්බන්ධකය වැඩිදියුණු කරන අවස්ථාවේදීම අපි එය වහාම නව රාමුවකට මාරු කරමු.
ඒ සමගම, අපි Docker සහ Kubernetes වෙත සම්බන්ධක යෙදවීමට පටන් ගත්තෙමු.
අපි සෑහෙන කාලයක් Kubernetes වෙත යාමට සැලසුම් කළෙමු, CI/CD සැකසුම් අත්හදා බැලුවෙමු, නමුත් චලනය වීමට පටන් ගත්තේ දෝෂයක් හේතුවෙන් එක් සම්බන්ධකයක් සේවාදායකයේ 20 GB වඩා වැඩි මතකයක් අනුභව කිරීමට පටන් ගත් විට පමණි, ප්‍රායෝගිකව අනෙකුත් ක්‍රියාවලීන් විනාශ කරයි. . විමර්ශනය අතරතුර, සම්බන්ධකය Kubernetes පොකුරකට ගෙන යන ලද අතර, දෝෂය නිවැරදි කිරීමෙන් පසුව පවා එය අවසානයේ පැවතියේය.
Kubernetes පහසු බව ඉතා ඉක්මනින් අපට වැටහුණු අතර, මාස හයක් ඇතුළත අපි වැඩිම සම්පත් පරිභෝජනය කරන සම්බන්ධක 7ක් සහ Connectors Proxy නිෂ්පාදන පොකුරට මාරු කළෙමු.
සම්බන්ධක අනුගමනය කරමින්, අපි ඉතිරි යෙදුමේ ගෘහ නිර්මාණ ශිල්පය වෙනස් කිරීමට තීරණය කළෙමු.
ප්රධාන ගැටළුව වූයේ දත්ත සම්බන්ධක සිට ප්‍රොක්සි වෙත විශාල කණ්ඩායම් වශයෙන් පැමිණ පසුව DANBoID වෙත පහර දී සැකසීම සඳහා මධ්‍යම වෙබ් යෙදුම වෙත යැවීමයි. ප්‍රමිතික නැවත ගණනය කිරීම් විශාල සංඛ්‍යාවක් හේතුවෙන්, යෙදුම මත විශාල බරක් පවතී.
පුද්ගලික දත්ත එකතු කිරීමේ කාර්යයේ තත්ත්වය නිරීක්ෂණය කිරීම සහ මධ්‍යම වෙබ් යෙදුමකට සම්බන්ධක තුළ සිදුවන දෝෂ වාර්තා කිරීම ද තරමක් අපහසු බව ඔප්පු විය, එවිට පරිශීලකයින්ට සිදුවන්නේ කුමක්ද සහ දත්ත රැස් නොකරන්නේ මන්දැයි දැක ගත හැකිය.
මෙම ගැටළු විසඳීම සඳහා අපි ගෘහ නිර්මාණ ශිල්පය 2.0 සංවර්ධනය කළෙමු.
ගෘහ නිර්මාණ ශිල්පයේ නව අනුවාදය අතර ඇති ප්රධාන වෙනස නම් Web API වෙනුවට අපි RabbitMQ සහ MassTransit පුස්තකාලය සේවා අතර පණිවිඩ හුවමාරු කර ගැනීමයි. මෙය සිදු කිරීම සඳහා, අපට Connectors Proxy සම්පූර්ණයෙන්ම පාහේ නැවත ලිවීමට සිදු විය, එය Connectors Hub බවට පත් කරයි. සේවාවේ ප්රධාන කාර්යභාරය තවදුරටත් සම්බන්ධක වෙත සහ පසුපසට ඉල්ලීම් යොමු කිරීම නොව, සම්බන්ධක වලින් ප්‍රමිතික එකතු කිරීම කළමනාකරණය කිරීම නිසා නම වෙනස් කරන ලදී.
මධ්‍යම වෙබ් යෙදුමෙන්, අපි වෙබ් අඩවි වලින් ස්ථානගත කිරීම් සහ සංඛ්‍යාලේඛන පිළිබඳ තොරතුරු වෙනම සේවාවලට වෙන් කළ අතර එමඟින් අනවශ්‍ය නැවත ගණනය කිරීම් ඉවත් කර ස්ථානගත කිරීමේ මට්ටමින් දැනටමත් ගණනය කර එකතු කරන ලද සංඛ්‍යාලේඛන පමණක් ගබඩා කිරීමට හැකි විය. අපි අමු දත්ත මත පදනම්ව මූලික සංඛ්‍යාලේඛන ගණනය කිරීම සඳහා තර්කනය නැවත ලියා ප්‍රශස්ත කළෙමු.
ඒ අතරම, විසඳුම පරිමාණයට පහසු කිරීමට සහ කළමනාකරණය කිරීමට වඩාත් පහසු කිරීමට අපි සියලු සේවා සහ යෙදුම් ඩොකර් සහ කුබර්නෙට්ස් වෙත සංක්‍රමණය කරන්නෙමු.
අපි දැන් කොහෙද
සාධනය-සංකල්ප ගෘහ නිර්මාණ ශිල්පය 2.0 නිෂ්පාදනය D1.ඩිජිටල් සීමිත සම්බන්ධක කට්ටලයක් සහිත පරීක්ෂණ පරිසරයක සූදානම් සහ වැඩ කිරීම. කිරීමට ඉතිරිව ඇත්තේ තවත් සම්බන්ධක 20ක් නව වේදිකාවකට නැවත ලිවීම, දත්ත නිවැරදිව පටවා ඇති බවත්, සියලු ප්‍රමිතික නිවැරදිව ගණනය කර ඇති බවත් පරීක්ෂා කර සම්පූර්ණ සැලසුම නිෂ්පාදනයට පෙරළීමයි.
ඇත්ත වශයෙන්ම, මෙම ක්‍රියාවලිය ක්‍රමක්‍රමයෙන් සිදුවනු ඇති අතර සෑම දෙයක්ම ක්‍රියාත්මකව තබා ගැනීමට අපට පැරණි API සමඟ පසුගාමී ගැළපුම අත්හැරීමට සිදුවනු ඇත.
අපගේ ක්ෂණික සැලසුම්වලට නව සම්බන්ධක සංවර්ධනය, නව පද්ධති සමඟ ඒකාබද්ධ කිරීම සහ සම්බන්ධිත අඩවි සහ දැන්වීම් පද්ධති වෙතින් බාගත කළ දත්ත කට්ටලයට අමතර ප්‍රමිතික එකතු කිරීම ඇතුළත් වේ.
මධ්‍යම වෙබ් යෙදුම ඇතුළුව සියලුම යෙදුම් Docker සහ Kubernetes වෙත මාරු කිරීමටද අපි සැලසුම් කරමු. නව ගෘහ නිර්මාණ ශිල්පය සමඟ ඒකාබද්ධව, මෙය පරිභෝජනය කරන සම්පත් යෙදවීම, අධීක්ෂණය සහ පාලනය සැලකිය යුතු ලෙස සරල කරනු ඇත.
තවත් අදහසක් නම් දැනට MongoDB හි ගබඩා කර ඇති සංඛ්‍යාලේඛන ගබඩා කිරීම සඳහා දත්ත සමුදාය තේරීම අත්හදා බැලීමයි. අපි දැනටමත් නව සම්බන්ධක කිහිපයක් SQL දත්ත සමුදායන් වෙත මාරු කර ඇත, නමුත් එහි වෙනස බොහෝ දුරට නොපෙනෙන අතර, අත්තනෝමතික කාල පරිච්ඡේදයක් සඳහා ඉල්ලා සිටිය හැකි දිනෙන් දින එකතු කරන ලද සංඛ්‍යාලේඛන සඳහා, ලාභය තරමක් බරපතල විය හැකිය.
පොදුවේ ගත් කල, සැලසුම් විශිෂ්ටයි, අපි ඉදිරියට යමු :)
ලිපියේ කතුවරුන් R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), මිහායිල් කොට්සික් ()
මූලාශ්රය: www.habr.com