របៀបដែលយើងប្រមូលទិន្នន័យលើយុទ្ធនាការផ្សាយពាណិជ្ជកម្មពីគេហទំព័រអនឡាញ (ផ្លូវបន្លាទៅកាន់ផលិតផល)

វាហាក់បីដូចជាវិស័យនៃការផ្សាយពាណិជ្ជកម្មតាមអ៊ីនធឺណិតគួរតែមានភាពជឿនលឿនតាមបច្ចេកវិទ្យា និងស្វ័យប្រវត្តិតាមដែលអាចធ្វើទៅបាន។ ជាការពិតណាស់ ដោយសារតែក្រុមហ៊ុនយក្ស និងអ្នកជំនាញក្នុងវិស័យរបស់ពួកគេដូចជា Yandex, Mail.Ru, Google និង Facebook ធ្វើការនៅទីនោះ។ ប៉ុន្តែដូចដែលវាបានប្រែក្លាយ វាមិនមានដែនកំណត់ចំពោះភាពល្អឥតខ្ចោះនោះទេ ហើយតែងតែមានអ្វីមួយដែលត្រូវធ្វើដោយស្វ័យប្រវត្តិ។

ប្រភព

ក្រុមទំនាក់ទំនង បណ្តាញ Dentsu Aegis ប្រទេសរុស្ស៊ី គឺជាអ្នកលេងដ៏ធំបំផុតនៅក្នុងទីផ្សារផ្សាយពាណិជ្ជកម្មឌីជីថល ហើយកំពុងវិនិយោគយ៉ាងសកម្មនៅក្នុងបច្ចេកវិទ្យា ដោយព្យាយាមបង្កើនប្រសិទ្ធភាព និងស្វ័យប្រវត្តិកម្មដំណើរការអាជីវកម្មរបស់ខ្លួន។ បញ្ហាមួយក្នុងចំណោមបញ្ហាដែលមិនអាចដោះស្រាយបាននៃទីផ្សារផ្សាយពាណិជ្ជកម្មតាមអ៊ីនធឺណិតបានក្លាយជាភារកិច្ចប្រមូលស្ថិតិលើយុទ្ធនាការផ្សាយពាណិជ្ជកម្មពីវេទិកាអ៊ីនធឺណិតផ្សេងៗគ្នា។ ដំណោះ​ស្រាយ​ចំពោះ​បញ្ហា​នេះ​ជា​លទ្ធផល​នៅ​ទី​បំផុត​ក្នុង​ការ​បង្កើត​ផលិតផល D1.ឌីជីថល (អានថា ឌីវ៉ាន់) ការអភិវឌ្ឍន៍ដែលយើងចង់និយាយអំពី។

ហេតុអ្វី?

1. នៅពេលចាប់ផ្តើមនៃគម្រោងនេះ មិនមានផលិតផលដែលត្រៀមរួចជាស្រេចនៅលើទីផ្សារទេ ដែលដោះស្រាយបញ្ហានៃការប្រមូលស្ថិតិដោយស្វ័យប្រវត្តិលើយុទ្ធនាការផ្សាយពាណិជ្ជកម្ម។ នេះមានន័យថាគ្មាននរណាម្នាក់ក្រៅពីខ្លួនយើងទេដែលនឹងបំពេញតម្រូវការរបស់យើង។

សេវាកម្មដូចជា Improvado, Roistat, Supermetrics, SegmentStream ផ្តល់ជូននូវការរួមបញ្ចូលជាមួយវេទិកា បណ្តាញសង្គម និង Google Analitycs ហើយវាក៏ធ្វើឱ្យវាអាចបង្កើតផ្ទាំងគ្រប់គ្រងវិភាគសម្រាប់ការវិភាគងាយស្រួល និងការគ្រប់គ្រងយុទ្ធនាការផ្សាយពាណិជ្ជកម្មផងដែរ។ មុនពេលយើងចាប់ផ្តើមបង្កើតផលិតផលរបស់យើង យើងបានព្យាយាមប្រើប្រព័ន្ធមួយចំនួនដើម្បីប្រមូលទិន្នន័យពីគេហទំព័រ ប៉ុន្តែជាអកុសល ពួកគេមិនអាចដោះស្រាយបញ្ហារបស់យើងបានទេ។

បញ្ហាចម្បងគឺថាផលិតផលដែលបានសាកល្បងពឹងផ្អែកលើប្រភពទិន្នន័យ ការបង្ហាញស្ថិតិទីតាំងតាមគេហទំព័រ និងមិនផ្តល់នូវសមត្ថភាពក្នុងការប្រមូលផ្តុំស្ថិតិលើយុទ្ធនាការផ្សាយពាណិជ្ជកម្ម។ វិធីសាស្រ្តនេះមិនអនុញ្ញាតឱ្យយើងមើលឃើញស្ថិតិពីគេហទំព័រផ្សេងៗគ្នានៅកន្លែងតែមួយ និងវិភាគស្ថានភាពនៃយុទ្ធនាការទាំងមូលនោះទេ។

កត្តាមួយទៀតគឺថានៅដំណាក់កាលដំបូងផលិតផលត្រូវបានតម្រង់ទៅទីផ្សារលោកខាងលិច ហើយមិនគាំទ្រការរួមបញ្ចូលជាមួយគេហទំព័ររុស្ស៊ីទេ។ ហើយសម្រាប់គេហទំព័រទាំងនោះដែលការរួមបញ្ចូលត្រូវបានអនុវត្ត រាល់រង្វាស់ចាំបាច់ទាំងអស់មិនតែងតែត្រូវបានទាញយកដោយមានព័ត៌មានលម្អិតគ្រប់គ្រាន់ទេ ហើយការរួមបញ្ចូលមិនតែងតែងាយស្រួល និងមានតម្លាភាព ជាពិសេសនៅពេលដែលវាចាំបាច់ដើម្បីទទួលបានអ្វីមួយដែលមិនមាននៅក្នុងចំណុចប្រទាក់ប្រព័ន្ធ។
ជាទូទៅ យើងបានសម្រេចចិត្តមិនសម្របខ្លួនទៅនឹងផលិតផលភាគីទីបី ប៉ុន្តែបានចាប់ផ្តើមអភិវឌ្ឍខ្លួនយើង...

2. ទីផ្សារផ្សាយពាណិជ្ជកម្មតាមអ៊ីនធឺណិតកំពុងកើនឡើងពីមួយឆ្នាំទៅមួយឆ្នាំ ហើយនៅឆ្នាំ 2018 បើនិយាយពីថវិកាផ្សាយពាណិជ្ជកម្ម វាវ៉ាដាច់ទីផ្សារផ្សាយពាណិជ្ជកម្មតាមទូរទស្សន៍ធំជាងគេតាមប្រពៃណី។ ដូច្នេះមានមាត្រដ្ឋាន.

3. មិនដូចទីផ្សារផ្សាយពាណិជ្ជកម្មតាមទូរទស្សន៍ ដែលការលក់ការផ្សាយពាណិជ្ជកម្មត្រូវបានផ្តាច់មុខ មានម្ចាស់ជាច្រើននៃសារពើភ័ណ្ឌផ្សាយពាណិជ្ជកម្មដែលមានទំហំផ្សេងៗដំណើរការលើអ៊ីនធឺណិតជាមួយនឹងគណនីផ្សាយពាណិជ្ជកម្មផ្ទាល់ខ្លួនរបស់ពួកគេ។ ដោយសារយុទ្ធនាការផ្សាយពាណិជ្ជកម្ម ជាក្បួនដំណើរការលើគេហទំព័រជាច្រើនក្នុងពេលតែមួយ ដើម្បីយល់ពីស្ថានភាពនៃយុទ្ធនាការផ្សាយពាណិជ្ជកម្ម ចាំបាច់ត្រូវប្រមូលរបាយការណ៍ពីគេហទំព័រទាំងអស់ ហើយបញ្ចូលវាទៅក្នុងរបាយការណ៍ដ៏ធំមួយដែលនឹងបង្ហាញរូបភាពទាំងមូល។ នេះមានន័យថាមានសក្តានុពលសម្រាប់ការបង្កើនប្រសិទ្ធភាព។

4. វាហាក់ដូចជាពួកយើងថាម្ចាស់សារពើភ័ណ្ឌផ្សាយពាណិជ្ជកម្មនៅលើអ៊ីនធឺណិតមានហេដ្ឋារចនាសម្ព័ន្ធសម្រាប់ការប្រមូលស្ថិតិ និងបង្ហាញពួកវានៅក្នុងគណនីផ្សាយពាណិជ្ជកម្មរួចហើយ ហើយពួកគេនឹងអាចផ្តល់ API សម្រាប់ទិន្នន័យនេះ។ នេះមានន័យថាវាអាចធ្វើទៅបានតាមបច្ចេកទេសដើម្បីអនុវត្តវា។ ចូរនិយាយភ្លាមៗថាវាមិនសាមញ្ញទេ។

ជាទូទៅ រាល់តម្រូវការជាមុនសម្រាប់ការអនុវត្តគម្រោងគឺជាក់ស្តែងសម្រាប់យើង ហើយយើងបានរត់ដើម្បីនាំយកគម្រោងនេះទៅជាជីវិត...

ផែនការធំ

ដើម្បីចាប់ផ្តើមជាមួយ យើងបានបង្កើតចក្ខុវិស័យនៃប្រព័ន្ធឧត្តមគតិមួយ៖

• យុទ្ធនាការផ្សាយពាណិជ្ជកម្មពីប្រព័ន្ធសាជីវកម្ម 1C គួរតែត្រូវបានផ្ទុកដោយស្វ័យប្រវត្តិទៅក្នុងវាជាមួយនឹងឈ្មោះ អំឡុងពេល ថវិកា និងកន្លែងដាក់នៅលើវេទិកាផ្សេងៗ។
• សម្រាប់ការដាក់នីមួយៗនៅក្នុងយុទ្ធនាការផ្សាយពាណិជ្ជកម្ម ស្ថិតិដែលអាចធ្វើបានទាំងអស់គួរតែត្រូវបានទាញយកដោយស្វ័យប្រវត្តិពីគេហទំព័រដែលការដាក់កំពុងប្រព្រឹត្តទៅ ដូចជាចំនួននៃការចាប់អារម្មណ៍ ការចុច ការមើលជាដើម។
• យុទ្ធនាការផ្សាយពាណិជ្ជកម្មមួយចំនួនត្រូវបានតាមដានដោយប្រើការត្រួតពិនិត្យភាគីទីបីដោយអ្វីដែលគេហៅថាប្រព័ន្ធ adserving ដូចជា Adriver, Weborama, DCM ជាដើម។ វាក៏មានឧបករណ៍វាស់អ៊ីនធឺណិតឧស្សាហកម្មនៅក្នុងប្រទេសរុស្ស៊ីផងដែរ - ក្រុមហ៊ុន Mediascope ។ យោងតាមផែនការរបស់យើង ទិន្នន័យពីការត្រួតពិនិត្យឯករាជ្យ និងឧស្សាហកម្មក៏គួរតែត្រូវបានផ្ទុកដោយស្វ័យប្រវត្តិទៅក្នុងយុទ្ធនាការផ្សាយពាណិជ្ជកម្មដែលត្រូវគ្នា។
• យុទ្ធនាការផ្សាយពាណិជ្ជកម្មភាគច្រើននៅលើអ៊ីនធឺណិតគឺសំដៅលើសកម្មភាពគោលដៅជាក់លាក់ (ការទិញ ការហៅទូរសព្ទ ចុះឈ្មោះសម្រាប់ដ្រាយសាកល្បង។ គួរតែត្រូវបានបញ្ចូលទៅក្នុងឧបករណ៍របស់យើង។

រឿងចំអកដំបូងគឺដុំពក

ដោយមានការប្តេជ្ញាចិត្តរបស់យើងចំពោះគោលការណ៍ដែលអាចបត់បែនបាននៃការអភិវឌ្ឍន៍កម្មវិធី (រហ័សរហួន អ្វីៗទាំងអស់) យើងបានសម្រេចចិត្តបង្កើត MVP ជាមុនសិន ហើយបន្ទាប់មកបន្តឆ្ពោះទៅរកគោលដៅដែលបានគ្រោងទុកម្តងហើយម្តងទៀត។
យើងបានសម្រេចចិត្តបង្កើត MVP ដោយផ្អែកលើផលិតផលរបស់យើង។ DANBo (ក្រុមប្រឹក្សាបណ្តាញ Dentsu Aegis)ដែលជាកម្មវិធីគេហទំព័រដែលមានព័ត៌មានទូទៅអំពីយុទ្ធនាការផ្សាយពាណិជ្ជកម្មរបស់អតិថិជនរបស់យើង។

សម្រាប់ MVP គម្រោងនេះត្រូវបានធ្វើឱ្យសាមញ្ញតាមដែលអាចធ្វើទៅបានក្នុងលក្ខខណ្ឌនៃការអនុវត្ត។ យើងបានជ្រើសរើសបញ្ជីវេទិកាដែលមានកំណត់សម្រាប់ការរួមបញ្ចូល។ ទាំងនេះគឺជាវេទិកាសំខាន់ៗដូចជា Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB និងប្រព័ន្ធផ្សព្វផ្សាយសំខាន់ៗ Adriver និង Weborama ។

ដើម្បីចូលប្រើស្ថិតិនៅលើគេហទំព័រតាមរយៈ API យើងបានប្រើគណនីតែមួយ។ អ្នកគ្រប់គ្រងក្រុមអតិថិជនដែលចង់ប្រើការប្រមូលស្ថិតិដោយស្វ័យប្រវត្តិនៅលើយុទ្ធនាការផ្សាយពាណិជ្ជកម្មត្រូវតែផ្ទេរសិទ្ធិចូលប្រើយុទ្ធនាការផ្សាយពាណិជ្ជកម្មចាំបាច់នៅលើគេហទំព័រទៅកាន់គណនីវេទិកាជាមុនសិន។

បន្ទាប់គឺអ្នកប្រើប្រាស់ប្រព័ន្ធ ដាន់បូ ត្រូវតែផ្ទុកឡើងឯកសារនៃទ្រង់ទ្រាយជាក់លាក់មួយទៅក្នុងប្រព័ន្ធ Excel ដែលមានព័ត៌មានទាំងអស់អំពីការដាក់ (យុទ្ធនាការផ្សាយពាណិជ្ជកម្ម វេទិកា ទ្រង់ទ្រាយ រយៈពេលដាក់ សូចនាករដែលបានគ្រោងទុក ថវិកា។ល។) និងការកំណត់អត្តសញ្ញាណនៃយុទ្ធនាការផ្សាយពាណិជ្ជកម្មដែលត្រូវគ្នានៅលើ គេហទំព័រ និងបញ្ជរនៅក្នុងប្រព័ន្ធផ្សព្វផ្សាយ។

វាមើលទៅដោយត្រង់ទៅគួរឱ្យភ័យខ្លាច:

ទិន្នន័យដែលបានទាញយកត្រូវបានរក្សាទុកទៅក្នុងមូលដ្ឋានទិន្នន័យ ហើយបន្ទាប់មកសេវាកម្មដាច់ដោយឡែកបានប្រមូលអ្នកកំណត់អត្តសញ្ញាណយុទ្ធនាការនៅលើគេហទំព័រពីពួកគេ និងបានទាញយកស្ថិតិនៅលើពួកវា។

សម្រាប់គេហទំព័រនីមួយៗ សេវាកម្ម windows ដាច់ដោយឡែកមួយត្រូវបានសរសេរ ដែលមួយថ្ងៃបានទៅក្រោមគណនីសេវាកម្មមួយនៅក្នុង API របស់គេហទំព័រ និងបានទាញយកស្ថិតិសម្រាប់លេខសម្គាល់យុទ្ធនាការដែលបានបញ្ជាក់។ រឿងដដែលនេះបានកើតឡើងជាមួយប្រព័ន្ធផ្សព្វផ្សាយ។

ទិន្នន័យដែលបានទាញយកត្រូវបានបង្ហាញនៅលើចំណុចប្រទាក់ក្នុងទម្រង់ជាផ្ទាំងគ្រប់គ្រងផ្ទាល់ខ្លួនតូចមួយ៖

ដោយមិននឹកស្មានដល់សម្រាប់ពួកយើង MVP បានចាប់ផ្តើមធ្វើការ ហើយចាប់ផ្តើមទាញយកស្ថិតិបច្ចុប្បន្នលើយុទ្ធនាការផ្សាយពាណិជ្ជកម្មនៅលើអ៊ីនធឺណិត។ យើងបានអនុវត្តប្រព័ន្ធនេះលើអតិថិជនជាច្រើន ប៉ុន្តែនៅពេលព្យាយាមធ្វើមាត្រដ្ឋាន យើងជួបប្រទះបញ្ហាធ្ងន់ធ្ងរ៖

• បញ្ហាចម្បងគឺភាពស្មុគស្មាញនៃការរៀបចំទិន្នន័យសម្រាប់ការផ្ទុកទៅក្នុងប្រព័ន្ធ។ ដូចគ្នានេះផងដែរ ទិន្នន័យនៃការដាក់ត្រូវតែត្រូវបានបំប្លែងទៅជាទម្រង់ថេរយ៉ាងតឹងរឹង មុនពេលផ្ទុក។ វាចាំបាច់ក្នុងការរួមបញ្ចូលឧបករណ៍កំណត់អត្តសញ្ញាណពីគេហទំព័រផ្សេងៗគ្នានៅក្នុងឯកសារទាញយក។ យើងប្រឈមមុខនឹងការពិតដែលថាវាពិតជាលំបាកណាស់សម្រាប់អ្នកប្រើប្រាស់ដែលមិនបានបណ្តុះបណ្តាលបច្ចេកទេសដើម្បីពន្យល់ពីកន្លែងដែលត្រូវស្វែងរកអត្តសញ្ញាណទាំងនេះនៅលើគេហទំព័រ និងកន្លែងដែលនៅក្នុងឯកសារដែលពួកគេត្រូវបញ្ចូល។ ដោយពិចារណាលើចំនួនបុគ្គលិកនៅក្នុងនាយកដ្ឋានដែលកំពុងដំណើរការយុទ្ធនាការនៅលើគេហទំព័រ និងការផ្លាស់ប្តូរ នេះបណ្តាលឱ្យមានការគាំទ្រយ៉ាងច្រើនពីខាងយើង ដែលពួកយើងពិតជាមិនសប្បាយចិត្តជាមួយនោះទេ។
• បញ្ហាមួយទៀតគឺថាមិនមែនគ្រប់វេទិកាផ្សាយពាណិជ្ជកម្មទាំងអស់មានយន្តការសម្រាប់ផ្ទេរសិទ្ធិចូលដំណើរការយុទ្ធនាការផ្សាយពាណិជ្ជកម្មទៅគណនីផ្សេងទៀតទេ។ ប៉ុន្តែទោះបីជាយន្តការគណៈប្រតិភូមានក៏ដោយ មិនមែនអ្នកផ្សាយពាណិជ្ជកម្មទាំងអស់មានឆន្ទៈក្នុងការផ្តល់សិទ្ធិចូលដំណើរការយុទ្ធនាការរបស់ពួកគេទៅកាន់គណនីភាគីទីបីនោះទេ។
• កត្តាសំខាន់មួយគឺការខឹងសម្បារដែលបានកើតឡើងក្នុងចំណោមអ្នកប្រើប្រាស់ដោយការពិតដែលថារាល់សូចនាករដែលបានគ្រោងទុក និងព័ត៌មានលម្អិតអំពីទីកន្លែងដែលពួកគេបញ្ចូលទៅក្នុងប្រព័ន្ធគណនេយ្យ 1C របស់យើងរួចហើយ ពួកគេត្រូវតែបញ្ចូលទៅក្នុង ដាន់បូ.

នេះបានផ្តល់ឱ្យយើងនូវគំនិតថាប្រភពចម្បងនៃព័ត៌មានអំពីការដាក់គួរតែជាប្រព័ន្ធ 1C របស់យើង ដែលទិន្នន័យទាំងអស់ត្រូវបានបញ្ចូលយ៉ាងត្រឹមត្រូវ និងទាន់ពេលវេលា (ចំណុចនៅទីនេះគឺថាវិក័យប័ត្រត្រូវបានបង្កើតដោយផ្អែកលើទិន្នន័យ 1C ដូច្នេះការបញ្ចូលទិន្នន័យត្រឹមត្រូវទៅក្នុង 1C គឺជាអាទិភាពសម្រាប់មនុស្សគ្រប់គ្នា KPI) ។ នេះជារបៀបដែលគំនិតថ្មីនៃប្រព័ន្ធបានលេចចេញ ...

គំនិត

រឿងដំបូងដែលយើងសម្រេចចិត្តធ្វើគឺបំបែកប្រព័ន្ធសម្រាប់ការប្រមូលស្ថិតិនៃយុទ្ធនាការផ្សាយពាណិជ្ជកម្មនៅលើអ៊ីនធឺណិតទៅជាផលិតផលដាច់ដោយឡែកមួយ - D1.ឌីជីថល.

នៅក្នុងគំនិតថ្មី យើងបានសម្រេចចិត្តបញ្ចូលទៅក្នុង D1.ឌីជីថល ព័ត៌មានស្តីពីយុទ្ធនាការផ្សាយពាណិជ្ជកម្ម និងទីកន្លែងនៅក្នុងពួកគេពី 1C ហើយបន្ទាប់មកទាញស្ថិតិពីគេហទំព័រ និងប្រព័ន្ធសេវាផ្សាយពាណិជ្ជកម្មទៅកាន់កន្លែងទាំងនេះ។ នេះ​ត្រូវ​បាន​គេ​សន្មត់​ថា​ជួយ​សម្រួល​ដល់​ជីវិត​អ្នក​ប្រើ​យ៉ាង​សំខាន់ (ហើយ​ដូច​ជា​ធម្មតា បន្ថែម​ការងារ​បន្ថែម​ទៀត​ដល់​អ្នក​អភិវឌ្ឍន៍) និង​កាត់​បន្ថយ​ចំនួន​នៃ​ការ​គាំទ្រ។

បញ្ហាដំបូងដែលយើងជួបប្រទះគឺមានលក្ខណៈស្ថាប័ន ហើយទាក់ទងនឹងការពិតដែលថាយើងមិនអាចស្វែងរកគន្លឹះ ឬសញ្ញាដែលយើងអាចប្រៀបធៀបអង្គភាពពីប្រព័ន្ធផ្សេងៗជាមួយនឹងយុទ្ធនាការ និងទីកន្លែងពី 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 ដែលបានបង្កើត ហើយយើងផ្ទុកឡើងនូវអង្គភាពដែលជាប់ពាក់ព័ន្ធទាំងអស់ជាមួយនឹងការកំណត់អត្តសញ្ញាណគេហទំព័រតែមួយគត់ និងទម្រង់ SubDANBoID យោងតាមគោលការណ៍ DANBoID + ការកំណត់អត្តសញ្ញាណនៃកម្រិតទីមួយ។ nested entity + identifier of the second nested entity +... វិធីសាស្រ្តនេះបានអនុញ្ញាតឱ្យយើងភ្ជាប់យុទ្ធនាការផ្សាយពាណិជ្ជកម្មនៅក្នុងប្រព័ន្ធផ្សេងៗគ្នា និងទាញយកស្ថិតិលម្អិតលើពួកវា។

យើងក៏ត្រូវដោះស្រាយបញ្ហានៃការចូលប្រើយុទ្ធនាការនៅលើវេទិកាផ្សេងៗផងដែរ។ ដូចដែលយើងបានសរសេរខាងលើ យន្តការនៃការផ្ទេរសិទ្ធិចូលប្រើយុទ្ធនាការទៅគណនីបច្ចេកទេសដាច់ដោយឡែកគឺមិនតែងតែអាចអនុវត្តបានទេ។ ដូច្នេះហើយ យើងត្រូវអភិវឌ្ឍហេដ្ឋារចនាសម្ព័ន្ធសម្រាប់ការអនុញ្ញាតដោយស្វ័យប្រវត្តិតាមរយៈ OAuth ដោយប្រើថូខឹន និងយន្តការសម្រាប់ធ្វើបច្ចុប្បន្នភាពថូខឹនទាំងនេះ។

ក្រោយមកនៅក្នុងអត្ថបទយើងនឹងព្យាយាមពិពណ៌នាលម្អិតបន្ថែមទៀតអំពីស្ថាបត្យកម្មនៃដំណោះស្រាយនិងព័ត៌មានលម្អិតបច្ចេកទេសនៃការអនុវត្ត។

ដំណោះស្រាយស្ថាបត្យកម្ម 1.0

នៅពេលចាប់ផ្តើមអនុវត្តផលិតផលថ្មី យើងយល់ថាយើងត្រូវការជាបន្ទាន់ដើម្បីផ្តល់លទ្ធភាពនៃការតភ្ជាប់គេហទំព័រថ្មី ដូច្នេះហើយយើងបានសម្រេចចិត្តដើរតាមគន្លងនៃស្ថាបត្យកម្មមីក្រូសេវាកម្ម។

នៅពេលរចនាស្ថាបត្យកម្ម យើងបានបំបែកឧបករណ៍ភ្ជាប់ទៅប្រព័ន្ធខាងក្រៅទាំងអស់ - 1C វេទិកាផ្សាយពាណិជ្ជកម្ម និងប្រព័ន្ធផ្សព្វផ្សាយ - ទៅជាសេវាកម្មដាច់ដោយឡែក។
គំនិតចម្បងគឺថាឧបករណ៍ភ្ជាប់ទៅគេហទំព័រទាំងអស់មាន API ដូចគ្នា និងជាអាដាប់ទ័រដែលនាំ API គេហទំព័រទៅជាចំណុចប្រទាក់ងាយស្រួលសម្រាប់យើង។

នៅចំកណ្តាលនៃផលិតផលរបស់យើងគឺជាកម្មវិធីបណ្តាញដែលជា monolith ដែលត្រូវបានរចនាឡើងតាមរបៀបដែលវាអាចត្រូវបានផ្តាច់ចូលទៅក្នុងសេវាកម្មយ៉ាងងាយស្រួល។ កម្មវិធីនេះទទួលខុសត្រូវចំពោះដំណើរការទិន្នន័យដែលបានទាញយក ប្រមូលស្ថិតិពីប្រព័ន្ធផ្សេងៗ និងបង្ហាញពួកវាដល់អ្នកប្រើប្រាស់ប្រព័ន្ធ។

ដើម្បីទំនាក់ទំនងរវាងឧបករណ៍ភ្ជាប់ និងកម្មវិធីបណ្តាញ យើងត្រូវបង្កើតសេវាកម្មបន្ថែម ដែលយើងហៅថា Connector Proxy ។ វាដំណើរការមុខងាររបស់ Service Discovery និង Task Scheduler។ សេវាកម្មនេះដំណើរការភារកិច្ចប្រមូលទិន្នន័យសម្រាប់ឧបករណ៍ភ្ជាប់នីមួយៗជារៀងរាល់យប់។ ការសរសេរស្រទាប់សេវាកម្មគឺងាយស្រួលជាងការភ្ជាប់ឈ្មួញកណ្តាលសារ ហើយសម្រាប់ពួកយើងវាមានសារៈសំខាន់ណាស់ក្នុងការទទួលបានលទ្ធផលឱ្យបានលឿនតាមដែលអាចធ្វើទៅបាន។

សម្រាប់ភាពសាមញ្ញ និងល្បឿននៃការអភិវឌ្ឍន៍ យើងក៏បានសម្រេចចិត្តថាសេវាកម្មទាំងអស់នឹងក្លាយជា Web APIs។ នេះធ្វើឱ្យវាអាចធ្វើទៅបានដើម្បីប្រមូលផ្តុំភស្តុតាងនៃគំនិតយ៉ាងឆាប់រហ័ស និងផ្ទៀងផ្ទាត់ថាការរចនាទាំងមូលដំណើរការ។

កិច្ចការដ៏ស្មុគស្មាញដាច់ដោយឡែកមួយគឺការរៀបចំការចូលប្រើដើម្បីប្រមូលទិន្នន័យពីគណនីផ្សេងៗគ្នា ដែលដូចដែលយើងបានសម្រេចចិត្ត គួរតែត្រូវបានអនុវត្តដោយអ្នកប្រើប្រាស់តាមរយៈចំណុចប្រទាក់គេហទំព័រ។ វាមានជំហានពីរដាច់ដោយឡែកពីគ្នា៖ ដំបូង អ្នកប្រើប្រាស់បន្ថែមសញ្ញាសម្ងាត់ដើម្បីចូលប្រើគណនីតាមរយៈ OAuth ហើយបន្ទាប់មកកំណត់រចនាសម្ព័ន្ធការប្រមូលទិន្នន័យសម្រាប់អតិថិជនពីគណនីជាក់លាក់មួយ។ ការទទួលបានសញ្ញាសម្ងាត់តាមរយៈ OAuth គឺចាំបាច់ ពីព្រោះ ដូចដែលយើងបានសរសេររួចមកហើយ វាមិនតែងតែអាចធ្វើប្រតិភូកម្មការចូលប្រើគណនីដែលចង់បាននៅលើគេហទំព័រនោះទេ។

ដើម្បីបង្កើតយន្តការសកលសម្រាប់ការជ្រើសរើសគណនីពីគេហទំព័រ យើងត្រូវបន្ថែមវិធីសាស្ត្រមួយទៅ API ឧបករណ៍ភ្ជាប់ដែលត្រឡប់ JSON Schema ដែលត្រូវបានបង្ហាញជាទម្រង់ដោយប្រើសមាសធាតុ JSONEditor ដែលបានកែប្រែ។ វិធីនេះ អ្នកប្រើប្រាស់អាចជ្រើសរើសគណនីដែលត្រូវទាញយកទិន្នន័យ។

ដើម្បីអនុលោមតាមដែនកំណត់សំណើដែលមាននៅលើគេហទំព័រ យើងរួមបញ្ចូលគ្នានូវសំណើសម្រាប់ការកំណត់នៅក្នុងនិមិត្តសញ្ញាតែមួយ ប៉ុន្តែយើងអាចដំណើរការនិមិត្តសញ្ញាផ្សេងគ្នាស្របគ្នា។

យើងបានជ្រើសរើស MongoDB ជាឃ្លាំងផ្ទុកទិន្នន័យសម្រាប់ទាំងកម្មវិធីបណ្តាញ និងឧបករណ៍ភ្ជាប់ ដែលអនុញ្ញាតឱ្យយើងមិនព្រួយបារម្ភច្រើនពេកអំពីរចនាសម្ព័ន្ធទិន្នន័យនៅដំណាក់កាលដំបូងនៃការអភិវឌ្ឍន៍ នៅពេលដែលគំរូវត្ថុនៃកម្មវិធីផ្លាស់ប្តូរជារៀងរាល់ថ្ងៃផ្សេងទៀត។

មិនយូរប៉ុន្មានយើងបានរកឃើញថាមិនមែនទិន្នន័យទាំងអស់សមនឹងល្អនៅក្នុង MongoDB ទេ ហើយឧទាហរណ៍ វាកាន់តែងាយស្រួលក្នុងការរក្សាទុកស្ថិតិប្រចាំថ្ងៃនៅក្នុងមូលដ្ឋានទិន្នន័យទំនាក់ទំនង។ ដូច្នេះ សម្រាប់ឧបករណ៍ភ្ជាប់ដែលរចនាសម្ព័ន្ធទិន្នន័យមានលក្ខណៈសមរម្យជាងសម្រាប់មូលដ្ឋានទិន្នន័យទំនាក់ទំនង យើងបានចាប់ផ្តើមប្រើ PostgreSQL ឬ MS SQL Server ជាកន្លែងផ្ទុក។

ស្ថាបត្យកម្ម និងបច្ចេកវិទ្យាដែលបានជ្រើសរើសបានអនុញ្ញាតឱ្យយើងបង្កើត និងបើកដំណើរការផលិតផល D1.Digital យ៉ាងឆាប់រហ័ស។ ក្នុងរយៈពេលពីរឆ្នាំនៃការអភិវឌ្ឍន៍ផលិតផល យើងបានបង្កើតឧបករណ៍ភ្ជាប់ 23 ទៅកាន់គេហទំព័រ ទទួលបានបទពិសោធន៍ដ៏មានតម្លៃក្នុងការធ្វើការជាមួយ APIs ភាគីទីបី រៀនដើម្បីជៀសវាងពីភាពលំបាកនៃគេហទំព័រផ្សេងៗគ្នា ដែលនីមួយៗមានផ្ទាល់ខ្លួន រួមចំណែកដល់ការអភិវឌ្ឍន៍ API យ៉ាងហោចណាស់ 3 គេហទំព័រដែលបានទាញយកព័ត៌មានដោយស្វ័យប្រវត្តិនៅលើយុទ្ធនាការជិត 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 ។ ឈ្មោះនេះត្រូវបានផ្លាស់ប្តូរដោយសារតែតួនាទីសំខាន់នៃសេវាកម្មនេះលែងមាននៅក្នុងការបញ្ជូនបន្តទៅឧបករណ៍ភ្ជាប់ និងត្រឡប់មកវិញ ប៉ុន្តែនៅក្នុងការគ្រប់គ្រងការប្រមូលផ្តុំម៉ែត្រពីឧបករណ៍ភ្ជាប់។

ពីកម្មវិធីបណ្តាញកណ្តាល យើងបានបំបែកព័ត៌មានអំពីទីកន្លែង និងស្ថិតិពីគេហទំព័រទៅជាសេវាកម្មដាច់ដោយឡែក ដែលធ្វើឱ្យវាអាចធ្វើទៅបានដើម្បីកម្ចាត់ការគណនាឡើងវិញដែលមិនចាំបាច់ ហើយរក្សាទុកតែស្ថិតិដែលបានគណនា និងប្រមូលផ្តុំរួចហើយនៅកម្រិតដាក់។ យើងក៏បានសរសេរឡើងវិញ និងធ្វើឲ្យប្រសើរឡើងនូវតក្កវិជ្ជាសម្រាប់ការគណនាស្ថិតិជាមូលដ្ឋានដោយផ្អែកលើទិន្នន័យឆៅ។

ក្នុងពេលជាមួយគ្នានេះ យើងកំពុងផ្ទេរសេវាកម្ម និងកម្មវិធីទាំងអស់ទៅកាន់ Docker និង Kubernetes ដើម្បីធ្វើឱ្យដំណោះស្រាយកាន់តែងាយស្រួលក្នុងការធ្វើមាត្រដ្ឋាន និងកាន់តែងាយស្រួលក្នុងការគ្រប់គ្រង។

តើយើងនៅឯណាឥឡូវនេះ

ស្ថាបត្យកម្មភស្តុតាងនៃគំនិត 2.0 ផលិតផល D1.ឌីជីថល រួចរាល់ និងធ្វើការក្នុងបរិយាកាសសាកល្បងជាមួយនឹងឧបករណ៍ភ្ជាប់ដែលមានកំណត់។ អ្វីដែលនៅសេសសល់គឺត្រូវសរសេរឧបករណ៍ភ្ជាប់ 20 ផ្សេងទៀតទៅកាន់វេទិកាថ្មី សាកល្បងថាទិន្នន័យត្រូវបានផ្ទុកត្រឹមត្រូវ ហើយម៉ែត្រទាំងអស់ត្រូវបានគណនាយ៉ាងត្រឹមត្រូវ ហើយបញ្ចូលការរចនាទាំងមូលទៅក្នុងផលិតកម្ម។

ជាការពិត ដំណើរការនេះនឹងកើតឡើងបន្តិចម្តងៗ ហើយយើងនឹងត្រូវចាកចេញពីភាពឆបគ្នាថយក្រោយជាមួយ APIs ចាស់ ដើម្បីរក្សាអ្វីៗគ្រប់យ៉ាងឱ្យដំណើរការ។

ផែនការភ្លាមៗរបស់យើងរួមមានការអភិវឌ្ឍន៍ឧបករណ៍ភ្ជាប់ថ្មី ការរួមបញ្ចូលជាមួយប្រព័ន្ធថ្មី និងការបន្ថែមរង្វាស់បន្ថែមទៅក្នុងសំណុំទិន្នន័យដែលបានទាញយកពីគេហទំព័រដែលបានភ្ជាប់ និងប្រព័ន្ធផ្សព្វផ្សាយ។

យើងក៏មានគម្រោងផ្ទេរកម្មវិធីទាំងអស់ រួមទាំងកម្មវិធីបណ្តាញកណ្តាលទៅ Docker និង Kubernetes ផងដែរ។ គួបផ្សំជាមួយស្ថាបត្យកម្មថ្មី នេះនឹងសម្រួលដល់ការដាក់ពង្រាយ ការត្រួតពិនិត្យ និងការគ្រប់គ្រងធនធានដែលបានប្រើប្រាស់យ៉ាងងាយស្រួល។

គំនិតមួយទៀតគឺដើម្បីពិសោធន៍ជាមួយជម្រើសនៃមូលដ្ឋានទិន្នន័យសម្រាប់ការរក្សាទុកស្ថិតិដែលបច្ចុប្បន្នត្រូវបានរក្សាទុកនៅក្នុង MongoDB ។ យើងបានផ្ទេរឧបករណ៍ភ្ជាប់ថ្មីជាច្រើនទៅមូលដ្ឋានទិន្នន័យ SQL រួចហើយ ប៉ុន្តែនៅទីនោះ ភាពខុសគ្នាគឺស្ទើរតែមិនអាចកត់សម្គាល់បាន ហើយសម្រាប់ស្ថិតិសរុបតាមថ្ងៃ ដែលអាចត្រូវបានស្នើសុំសម្រាប់រយៈពេលបំពាន ការទទួលបានអាចធ្ងន់ធ្ងរណាស់។

ជាទូទៅផែនការគឺអស្ចារ្យ, តោះបន្តទៅមុខ :)

អ្នកនិពន្ធអត្ថបទ R&D Dentsu Aegis Network Russia: Georgy Ostapenko (shmiigaa), Mikhail Kotsik (hitexx)

ប្រភព: www.habr.com