ប្រវត្តិនៃស្ថាបត្យកម្ម Dodo IS: ផ្លូវ Back Office

Habr កំពុងផ្លាស់ប្តូរពិភពលោក។ យើង​បាន​សរសេរ​ប្លុក​ជាង​មួយ​ឆ្នាំ​ហើយ។ ប្រហែលប្រាំមួយខែកន្លងទៅនេះ យើងបានទទួលនូវមតិរិះគន់ដ៏ឡូយឆាយពីអ្នកស្រុក Khabrovsk៖ “Dodo អ្នកនិយាយគ្រប់ទីកន្លែងថាអ្នកមានប្រព័ន្ធផ្ទាល់ខ្លួនរបស់អ្នក។ តើនេះជាប្រព័ន្ធបែបណា? ហើយហេតុអ្វីបានជាខ្សែសង្វាក់ភីហ្សាត្រូវការវា?

យើង​អង្គុយ​គិត ហើយ​ដឹង​ថា​អ្នក​ត្រូវ។ យើងកំពុងព្យាយាមពន្យល់អ្វីគ្រប់យ៉ាងដោយប្រើម្រាមដៃរបស់យើង ប៉ុន្តែវាចេញមកជាបំណែករហែក ហើយមិនមានការពិពណ៌នាពេញលេញអំពីប្រព័ន្ធនៅកន្លែងណានោះទេ។ ដូច្នេះបានចាប់ផ្តើមដំណើរដ៏វែងឆ្ងាយនៃការប្រមូលព័ត៌មាន ស្វែងរកអ្នកនិពន្ធ និងសរសេរអត្ថបទជាបន្តបន្ទាប់អំពី Dodo IS ។ តោះ​ទៅ!

ការទទួលស្គាល់៖ អរគុណសម្រាប់ការចែករំលែកមតិរបស់អ្នកជាមួយពួកយើង។ សូមអរគុណដល់គាត់ ទីបំផុតយើងបានពណ៌នាអំពីប្រព័ន្ធ ចងក្រងប្រព័ន្ធបច្ចេកវិទ្យា ហើយនឹងបង្ហាញការពិពណ៌នាដ៏ធំនៃដំណើរការរបស់យើង។ បើគ្មានអ្នកទេ យើងនឹងអង្គុយបែបនេះរយៈពេល 5 ឆ្នាំទៀត។

ស៊េរីនៃអត្ថបទ "តើ Dodo IS ជាអ្វី?" ប្រាប់អំពី៖

1. Monolith ដំបូងនៅ Dodo IS (2011-2015) ។ (កំពុង​ដំណើរការ...)
2. ផ្លូវ Backoffice: មូលដ្ឋានដាច់ដោយឡែក និងឡានក្រុង។ (អ្នកនៅទីនេះ)
3. ផ្លូវចំហៀងអតិថិជន៖ facade ពីលើមូលដ្ឋាន (2016-2017) ។ (កំពុង​ដំណើរការ…)
4. ប្រវត្តិនៃសេវាកម្មមីក្រូពិត។ (2018-2019)។ (កំពុង​ដំណើរការ...)
5. បានបញ្ចប់ sawing នៃ monolith និងស្ថេរភាពនៃស្ថាបត្យកម្ម។ (កំពុង​ដំណើរការ...)

ប្រសិនបើអ្នកចាប់អារម្មណ៍ក្នុងការរៀនអ្វីផ្សេងទៀតសូមសរសេរនៅក្នុងមតិយោបល់។

យោបល់លើការពិពណ៌នាតាមកាលប្បវត្តិពីអ្នកនិពន្ធ
ខ្ញុំតែងតែរៀបចំកិច្ចប្រជុំសម្រាប់បុគ្គលិកថ្មីលើប្រធានបទ "ស្ថាបត្យកម្មប្រព័ន្ធ"។ យើងហៅវាថា "Intro to Dodo IS Architecture" ហើយវាគឺជាផ្នែកមួយនៃដំណើរការចាប់ផ្តើមសម្រាប់អ្នកអភិវឌ្ឍន៍ថ្មី។ ដោយនិយាយអំពីទម្រង់មួយ ឬទម្រង់ផ្សេងទៀតអំពីស្ថាបត្យកម្មរបស់យើង អំពីលក្ខណៈពិសេសរបស់វា ខ្ញុំបានបង្កើតវិធីសាស្រ្តប្រវត្តិសាស្ត្រជាក់លាក់មួយចំពោះការពិពណ៌នា។

ជាប្រពៃណី យើងមើលទៅលើប្រព័ន្ធជាសំណុំនៃសមាសធាតុ (បច្ចេកទេស ឬកម្រិតខ្ពស់) ម៉ូឌុលអាជីវកម្មដែលមានអន្តរកម្មជាមួយគ្នា ដើម្បីសម្រេចបាននូវគោលដៅមួយចំនួន។ ហើយខណៈពេលដែលទិដ្ឋភាពបែបនេះគឺសមហេតុផលសម្រាប់ការរចនា វាមិនសមរម្យទាំងស្រុងសម្រាប់ការពិពណ៌នា និងការយល់ដឹងនោះទេ។ មានហេតុផលជាច្រើន៖

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

ក្នុងឆ្នាំ 2011 ស្ថាបត្យកម្ម Dodo IS មើលទៅដូចនេះ:

នៅឆ្នាំ 2020 វាកាន់តែស្មុគស្មាញបន្តិច ហើយក្លាយជាដូចនេះ៖

តើ​ការ​វិវត្តន៍​នេះ​កើត​ឡើង​ដោយ​របៀប​ណា? ហេតុអ្វីបានជាផ្នែកផ្សេងៗនៃប្រព័ន្ធត្រូវការ? តើការសម្រេចចិត្តខាងស្ថាបត្យកម្មអ្វីខ្លះត្រូវបានធ្វើឡើង ហើយហេតុអ្វី? ចូរយើងស្វែងយល់នៅក្នុងស៊េរីនៃអត្ថបទនេះ។

បញ្ហាដំបូងនៃឆ្នាំ 2016: ហេតុអ្វីបានជាសេវាកម្មគួរចាកចេញពី monolith?

អត្ថបទដំបូងនៅក្នុងស៊េរីនឹងនិយាយអំពីសេវាកម្មដែលដំបូងគេដែលបំបែកចេញពី monolith ។ ដើម្បីដាក់ឱ្យអ្នកចូលទៅក្នុងបរិបទ ខ្ញុំនឹងប្រាប់អ្នកពីបញ្ហាដែលយើងមាននៅក្នុងប្រព័ន្ធនៅដើមឆ្នាំ 2016 ដែលយើងត្រូវដោះស្រាយជាមួយនឹងការបំបែកសេវាកម្ម។

មូលដ្ឋានទិន្នន័យ MySql តែមួយដែលកម្មវិធីទាំងអស់ដែលមាននៅពេលនោះនៅក្នុង Dodo IS បានសរសេរកំណត់ត្រារបស់ពួកគេ។ ផលវិបាកគឺ៖

• បន្ទុកធ្ងន់ (ជាមួយ 85% នៃសំណើត្រូវបានអាន) ។
• មូលដ្ឋានបានរីកចម្រើន។ ដោយសារតែនេះ ការចំណាយ និងការគាំទ្របានក្លាយជាបញ្ហា។
• ចំណុចតែមួយនៃការបរាជ័យ។ ប្រសិនបើកម្មវិធីមួយសរសេរទៅមូលដ្ឋានទិន្នន័យភ្លាមៗបានចាប់ផ្តើមធ្វើដូច្នេះកាន់តែសកម្ម នោះកម្មវិធីផ្សេងទៀតមានអារម្មណ៍ថាមានផលប៉ះពាល់។
• អប្រសិទ្ធភាពក្នុងការផ្ទុក និងសំណួរ។ ជាញឹកញាប់ទិន្នន័យត្រូវបានរក្សាទុកក្នុងរចនាសម្ព័ន្ធមួយចំនួនដែលងាយស្រួលសម្រាប់សេណារីយ៉ូមួយចំនួន ប៉ុន្តែមិនមែនសម្រាប់អ្នកដទៃនោះទេ។ សន្ទស្សន៍បង្កើនល្បឿនប្រតិបត្តិការមួយចំនួន ប៉ុន្តែអាចបន្ថយល្បឿនផ្សេងទៀត។
• បញ្ហាមួយចំនួនត្រូវបានដោះស្រាយដោយឃ្លាំងសម្ងាត់ដែលបានបង្កើតយ៉ាងឆាប់រហ័ស និងការចម្លងទៅកាន់មូលដ្ឋានទិន្នន័យ (នេះនឹងត្រូវបានពិភាក្សានៅក្នុងអត្ថបទដាច់ដោយឡែកមួយ) ប៉ុន្តែពួកគេគ្រាន់តែអនុញ្ញាតឱ្យយើងទទួលបានពេលវេលា និងមិនបានដោះស្រាយបញ្ហាជាមូលដ្ឋាន។

បញ្ហាគឺវត្តមានរបស់ monolith ខ្លួនឯង. ផលវិបាកគឺ៖

• ការចេញផ្សាយពិសេស និងកម្រ។
• ការលំបាកគឺនៅក្នុងការអភិវឌ្ឍន៍រួមគ្នារបស់មនុស្សមួយចំនួនធំ។
• អសមត្ថភាពក្នុងការណែនាំបច្ចេកវិទ្យាថ្មី ក្របខ័ណ្ឌថ្មី និងបណ្ណាល័យ។

បញ្ហាជាមួយមូលដ្ឋាននិង monolith ត្រូវបានពិពណ៌នាជាច្រើនដងឧទាហរណ៍នៅក្នុងបរិបទនៃការគាំងនៅដើមឆ្នាំ 2018 (ធ្វើដូច Munch ឬពាក្យពីរបីអំពីបំណុលបច្ចេកទេស, ថ្ងៃ Dodo IS ឈប់។ ស្គ្រីបអសមកាល и រឿងរ៉ាវរបស់បក្សី Dodo មកពីគ្រួសារ Phoenix ។ ការដួលរលំដ៏អស្ចារ្យនៃ Dodo IS) ដូច្នេះខ្ញុំនឹងមិនរស់នៅច្រើនពេកទេ។ ខ្ញុំគ្រាន់តែនិយាយថាយើងចង់ផ្តល់នូវភាពបត់បែនបន្ថែមទៀតនៅពេលបង្កើតសេវាកម្ម។ ជាដំបូង បញ្ហានេះទាក់ទងនឹងអ្នកដែលផ្ទុកច្រើនបំផុត និងជា root នៅក្នុងប្រព័ន្ធទាំងមូល - Auth and Tracker ។

ផ្លូវការិយាល័យខាងក្រោយ៖ មូលដ្ឋានដាច់ដោយឡែក និងឡានក្រុង

ការរុករកជំពូក

1. គ្រោងការណ៍នៃ monolith 2016
2. យើង​ចាប់​ផ្តើ​ម​ដើម្បី​ដោះ​ចេញ monolith: ការ​បំបែក​នៃ Auth និង Tracker
   
3. តើ Auth ធ្វើអ្វី?
4. តើបន្ទុកមកពីណា?
5. កំពុង​ផ្ទុក​ឯកសារ​ផ្ទៀងផ្ទាត់
6. តើ Tracker ធ្វើអ្វី?
7. តើបន្ទុកមកពីណា?
8. កំពុងផ្ទុកកម្មវិធីតាមដាន

គ្រោងការណ៍នៃ monolith 2016

នេះគឺជាប្លុកសំខាន់ៗនៃ 2016 Dodo IS monolith ហើយនៅខាងក្រោមគឺជាការវិភាគនៃភារកិច្ចចម្បងរបស់ពួកគេ។

តុសាច់ប្រាក់ដឹកជញ្ជូន។ គណនេយ្យសម្រាប់អ្នកនាំសំបុត្រ ការចេញការបញ្ជាទិញទៅកាន់អ្នកនាំសំបុត្រ។
មជ្ឈមណ្ឌលទំនាក់ទំនង. ការទទួលយកការបញ្ជាទិញតាមរយៈប្រតិបត្តិករ។
តំបន់បណ្តាញ. គេហទំព័ររបស់យើង (dodopizza.ru, dodopizza.co.uk, dodopizza.by ជាដើម)។
អាត់។. ការផ្តល់សិទ្ធិ និងសេវាផ្ទៀងផ្ទាត់សម្រាប់ការិយាល័យខាងក្រោយ។
កម្មវិធីតាមដាន. កម្មវិធីតាមដានការបញ្ជាទិញផ្ទះបាយ។ សេវាកម្មសម្រាប់សម្គាល់ស្ថានភាពត្រៀមខ្លួននៅពេលរៀបចំការបញ្ជាទិញ។
តុប្រាក់ភោជនីយដ្ឋាន. ទទួលការបញ្ជាទិញនៅក្នុងភោជនីយដ្ឋាន ចំណុចប្រទាក់អ្នកគិតលុយ។
ការនាំចេញ. ការផ្ទុកឡើងរបាយការណ៍ក្នុង 1C សម្រាប់គណនេយ្យ។
ការជូនដំណឹង និងវិក្កយបត្រ. ការបញ្ជាដោយសំឡេងនៅក្នុងផ្ទះបាយ (ឧទាហរណ៍ "ភីហ្សាថ្មីបានមកដល់ហើយ") + ការបោះពុម្ពវិក្កយបត្រសម្រាប់អ្នកនាំសំបុត្រ។
អ្នកគ្រប់គ្រងប្តូរ. ចំណុចប្រទាក់សម្រាប់ការងាររបស់អ្នកគ្រប់គ្រងការផ្លាស់ប្តូរ: បញ្ជីនៃការបញ្ជាទិញ, តារាងផលិតភាព, នាំបុគ្គលិកទៅវេន។
អ្នកគ្រប់គ្រង​ការិយាល័យ. ចំណុចប្រទាក់សម្រាប់ការងាររបស់អ្នកទទួលសិទ្ធិ និងអ្នកគ្រប់គ្រង៖ ការទទួលបុគ្គលិក របាយការណ៍ស្តីពីការងាររបស់ភីហ្សា។
បន្ទះភោជនីយដ្ឋាន. ការបង្ហាញម៉ឺនុយនៅលើទូរទស្សន៍នៅក្នុងហាងភីហ្សា។
អ្នកគ្រប់គ្រង. ការកំណត់សម្រាប់ហាងភីហ្សាជាក់លាក់មួយ៖ ម៉ឺនុយ តម្លៃ គណនេយ្យ លេខកូដផ្សព្វផ្សាយ ការផ្សព្វផ្សាយ បដាសម្រាប់គេហទំព័រ។ល។
គណនីផ្ទាល់ខ្លួនរបស់និយោជិត. កាលវិភាគការងាររបស់បុគ្គលិក ព័ត៌មានអំពីបុគ្គលិក។
ក្រុមប្រឹក្សាលើកទឹកចិត្តផ្ទះបាយ. អេក្រង់ដាច់ដោយឡែកដែលព្យួរនៅក្នុងផ្ទះបាយ និងបង្ហាញល្បឿនរបស់អ្នកផលិតភីហ្សា។
ការ​ទំនាក់ទំនង. ការផ្ញើសារ និងអ៊ីមែល។
ការផ្ទុកឯកសារ. សេវាកម្មផ្ទាល់ខ្លួនសម្រាប់ការទទួលនិងចេញឯកសារឋិតិវន្ត។

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

យើង​ចាប់​ផ្តើ​ម​ដើម្បី​ដោះ​ចេញ monolith: ការ​បំបែក​នៃ Auth និង Tracker

សេវាកម្មសំខាន់ៗដែលបន្ទាប់មកសរសេរ និងអានពីមូលដ្ឋានទិន្នន័យច្រើនជាងអ្នកដទៃ៖

1. សិទ្ធិ។ ការផ្តល់សិទ្ធិ និងសេវាផ្ទៀងផ្ទាត់សម្រាប់ការិយាល័យខាងក្រោយ។
2. កម្មវិធីតាមដាន។ កម្មវិធីតាមដានការបញ្ជាទិញផ្ទះបាយ។ សេវាកម្មសម្រាប់សម្គាល់ស្ថានភាពត្រៀមខ្លួននៅពេលរៀបចំការបញ្ជាទិញ។

តើ Auth ធ្វើអ្វី?

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

ជាឧទាហរណ៍ យើងចង់បើកការបង្ហាញជាមួយនឹងស្ថានភាពនៃការបញ្ជាទិញដែលបានបញ្ចប់នៅលើទូរទស្សន៍ដែលព្យួរនៅក្នុងសាល។ បន្ទាប់មកយើងបើក auth.dodopizza.ru ជ្រើសរើស "ចូលជាឧបករណ៍" កូដលេចឡើងដែលអាចបញ្ចូលក្នុងទំព័រពិសេសមួយនៅលើកុំព្យូទ័ររបស់អ្នកគ្រប់គ្រងការផ្លាស់ប្តូរ ដែលបង្ហាញពីប្រភេទឧបករណ៍ (ឧបករណ៍)។ ទូរទស្សន៍ខ្លួនវានឹងទៅកាន់ចំណុចប្រទាក់ដែលចង់បាននៃហាងភីហ្សារបស់វា ហើយចាប់ផ្តើមបង្ហាញឈ្មោះអតិថិជនដែលការបញ្ជាទិញរួចរាល់នៅទីនោះ។

តើបន្ទុកមកពីណា?

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

ឧបករណ៍នីមួយៗធ្វើដូចគ្នាតែជាមួយតារាងឧបករណ៍ ដោយពិនិត្យមើលតួនាទី និងការចូលប្រើប្រាស់របស់វា។ សំណើមួយចំនួនធំទៅកាន់មូលដ្ឋានទិន្នន័យមេនាំឱ្យការផ្ទុករបស់វា និងការខ្ជះខ្ជាយធនធានមូលដ្ឋានទិន្នន័យទូទៅលើប្រតិបត្តិការទាំងនេះ។

កំពុង​ផ្ទុក​ឯកសារ​ផ្ទៀងផ្ទាត់

Auth មានដែនដាច់ស្រយាល ពោលគឺទិន្នន័យអំពីអ្នកប្រើប្រាស់ ការចូល ឬឧបករណ៍ចូលក្នុងសេវាកម្ម (បច្ចុប្បន្ននាពេលអនាគត) ហើយនៅតែមាននៅទីនោះ។ ប្រសិនបើនរណាម្នាក់ត្រូវការពួកគេ គាត់នឹងចូលទៅកាន់សេវាកម្មនេះសម្រាប់ទិន្នន័យ។

WAS លំហូរការងារដំបូងគឺដូចនេះ៖

ខ្ញុំចង់ពន្យល់បន្តិចអំពីរបៀបដែលវាដំណើរការ៖

1. សំណើខាងក្រៅមកដល់ផ្នែកខាងក្រោយ (Asp.Net MVC នៅទីនោះ) ដោយនាំយកមកជាមួយវានូវខូគីសម័យ ដែលត្រូវបានប្រើដើម្បីទទួលបានទិន្នន័យសម័យពី Redis(1)។ វាមានព័ត៌មានអំពីការចូលប្រើ ហើយបន្ទាប់មកការចូលប្រើឧបករណ៍បញ្ជាបើក (3,4) ឬអត់។
2. ប្រសិនបើមិនមានការចូលប្រើទេ អ្នកត្រូវឆ្លងកាត់នីតិវិធីអនុញ្ញាត។ នៅទីនេះ ដើម្បីភាពសាមញ្ញ វាត្រូវបានបង្ហាញជាផ្នែកនៃផ្លូវនៅក្នុងគុណលក្ខណៈដូចគ្នា ទោះបីជានេះជាការផ្លាស់ប្តូរទៅកាន់ទំព័រចូលក៏ដោយ។ ក្នុងករណីមានសេណារីយ៉ូវិជ្ជមាន យើងនឹងទទួលបានវគ្គដែលបានបំពេញត្រឹមត្រូវ ហើយចូលទៅកាន់ Backoffice Controller។
3. ប្រសិនបើមានទិន្នន័យ នោះអ្នកត្រូវពិនិត្យមើលវាសម្រាប់ភាពពាក់ព័ន្ធនៅក្នុងមូលដ្ឋានទិន្នន័យអ្នកប្រើប្រាស់។ តើ​តួនាទី​របស់​គាត់​បាន​ផ្លាស់​ប្តូរ​ហើយ​ឬ​នៅ​? ក្នុងករណីនេះ បន្ទាប់ពីទទួលបានវគ្គ (1) អ្នកត្រូវចូលទៅកាន់មូលដ្ឋានទិន្នន័យដោយផ្ទាល់ ហើយពិនិត្យមើលការចូលប្រើប្រាស់របស់អ្នកប្រើប្រាស់ដោយប្រើស្រទាប់តក្កវិជ្ជាការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ (2)។ បន្ទាប់មកចូលទៅកាន់ទំព័រចូល ឬទៅកាន់ឧបករណ៍បញ្ជា។ នេះគឺជាប្រព័ន្ធសាមញ្ញ ប៉ុន្តែមិនមែនស្តង់ដារទាំងស្រុងនោះទេ។
4. ប្រសិនបើនីតិវិធីទាំងអស់ត្រូវបានបញ្ចប់ នោះយើងរំលងបន្ថែមទៀតនៅក្នុងតក្កវិជ្ជានៅក្នុងឧបករណ៍បញ្ជា និងវិធីសាស្រ្ត។

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

បានក្លាយជា។ នោះហើយជាអ្វីដែលពួកគេបានធ្វើ៖

វិធីសាស្រ្តនេះមានបញ្ហាមួយចំនួន។ ឧទាហរណ៍ ការហៅវិធីសាស្ត្រមួយនៅខាងក្នុងដំណើរការគឺមិនដូចគ្នានឹងការហៅសេវាខាងក្រៅតាមរយៈ http នោះទេ។ ភាពយឺតយ៉ាវ ភាពជឿជាក់ ការគាំទ្រ និងតម្លាភាពនៃប្រតិបត្តិការគឺខុសគ្នាទាំងស្រុង។ Andrey Morevsky បាននិយាយលម្អិតអំពីបញ្ហាទាំងនេះនៅក្នុងរបាយការណ៍របស់គាត់។ "50 ស្រមោលនៃសេវាកម្មមីក្រូ".

សេវាកម្មផ្ទៀងផ្ទាត់ និងជាមួយវា សេវាឧបករណ៍ត្រូវបានប្រើសម្រាប់ការិយាល័យខាងក្រោយ ពោលគឺសម្រាប់សេវាកម្ម និងចំណុចប្រទាក់ដែលប្រើក្នុងផលិតកម្ម។ ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវសម្រាប់សេវាកម្មអតិថិជន (ដូចជាគេហទំព័រ ឬកម្មវិធីទូរស័ព្ទ) កើតឡើងដោយឡែកពីគ្នាដោយមិនប្រើការផ្ទៀងផ្ទាត់។ ការបំបែកបានចំណាយពេលប្រហែលមួយឆ្នាំ ហើយឥឡូវនេះយើងកំពុងធ្វើការម្តងទៀតលើប្រធានបទនេះ ដោយផ្ទេរប្រព័ន្ធទៅសេវាកម្មផ្ទៀងផ្ទាត់ថ្មី (ជាមួយពិធីការស្តង់ដារ)។

ហេតុអ្វីការបែកគ្នាយូរម្ល៉េះ?
មាន​បញ្ហា​ជា​ច្រើន​នៅ​តាម​ផ្លូវ​ដែល​ធ្វើ​ឲ្យ​យើង​ថយ​ចុះ៖

1. យើងចង់ផ្ទេរទិន្នន័យអំពីអ្នកប្រើប្រាស់ ឧបករណ៍ និងការផ្ទៀងផ្ទាត់ពីមូលដ្ឋានទិន្នន័យរបស់ប្រទេសទៅជាមួយ។ ដើម្បីធ្វើដូច្នេះ យើងត្រូវផ្ទេរតារាង និងការប្រើប្រាស់ទាំងអស់ពី int identifier ទៅកាន់ UUId identifier សកល (ថ្មីៗនេះ យើងបានធ្វើការកូដនេះឡើងវិញ Roman Bukin "Uuid - រឿងធំនៃរចនាសម្ព័ន្ធតូចមួយ" និងគម្រោងប្រភពបើកចំហ បុព្វកាល) ការរក្សាទុកទិន្នន័យអ្នកប្រើប្រាស់ (ចាប់តាំងពីនេះជាព័ត៌មានផ្ទាល់ខ្លួន) មានដែនកំណត់របស់វា ហើយសម្រាប់ប្រទេសមួយចំនួន ចាំបាច់ត្រូវរក្សាទុកវាដោយឡែកពីគ្នា។ ប៉ុន្តែត្រូវតែមានលេខសម្គាល់អ្នកប្រើប្រាស់សកល។
2. តារាងជាច្រើននៅក្នុងមូលដ្ឋានទិន្នន័យមានព័ត៌មានសវនកម្មអំពីអ្នកប្រើប្រាស់ដែលធ្វើប្រតិបត្តិការ។ នេះតម្រូវឱ្យមានយន្តការបន្ថែម ដើម្បីធានាបាននូវភាពស៊ីសង្វាក់គ្នា។
3. បន្ទាប់ពីការបង្កើតសេវាកម្ម API មានរយៈពេលយូរនិងបន្តិចម្តង ៗ នៃការផ្ទេរទៅប្រព័ន្ធមួយផ្សេងទៀត។ ឧបករណ៍ប្តូរត្រូវតែកើតឡើងយ៉ាងរលូនសម្រាប់អ្នកប្រើប្រាស់ និងត្រូវការការងារដោយដៃ។

គ្រោងការណ៍សម្រាប់ការចុះឈ្មោះឧបករណ៍នៅក្នុងហាងភីហ្សា៖

ស្ថាបត្យកម្មទូទៅបន្ទាប់ពីការបំបែកសេវាផ្ទៀងផ្ទាត់ និងឧបករណ៍៖

ការកត់សម្គាល់. សម្រាប់ឆ្នាំ 2020 យើងកំពុងធ្វើការលើកំណែថ្មីនៃ Auth ដែលផ្អែកលើស្តង់ដារការអនុញ្ញាត OAuth 2.0 ។ ស្ដង់ដារនេះពិតជាស្មុគស្មាញ ប៉ុន្តែមានប្រយោជន៍សម្រាប់ការបង្កើតសេវាកម្មផ្ទៀងផ្ទាត់ពីចុងដល់ចប់។ នៅក្នុងអត្ថបទ "Subtleties នៃការអនុញ្ញាត៖ ទិដ្ឋភាពទូទៅនៃបច្ចេកវិទ្យា OAuth 2.0» យើង Alexey Chernyaev បានព្យាយាមនិយាយអំពីស្តង់ដារយ៉ាងសាមញ្ញ និងច្បាស់លាស់តាមដែលអាចធ្វើទៅបាន ដើម្បីឱ្យអ្នកសន្សំពេលវេលាលើការសិក្សាវា។

តើ Tracker ធ្វើអ្វី?

ឥឡូវនេះអំពីទីពីរនៃសេវាកម្មដែលបានផ្ទុក។ កម្មវិធីតាមដានមានតួនាទីពីរ៖

• ម៉្យាងវិញទៀត ភារកិច្ចរបស់វាគឺដើម្បីបង្ហាញបុគ្គលិកនៅក្នុងផ្ទះបាយនូវអ្វីដែលការបញ្ជាទិញកំពុងដំណើរការ តើផលិតផលអ្វីដែលត្រូវរៀបចំឥឡូវនេះ។
• ម៉្យាងទៀតធ្វើឌីជីថលដំណើរការទាំងអស់នៅក្នុងផ្ទះបាយ។

នៅពេលដែលផលិតផលថ្មី (ឧទាហរណ៍ ភីហ្សា) លេចឡើងក្នុងការបញ្ជាទិញ វាទៅស្ថានីយតាមដាន "រមៀល" ។ នៅស្ថានីយ៍នេះមានអ្នកផលិតភីហ្សាដែលយកនំដែលមានទំហំដែលត្រូវការ ហើយរមៀលវាចេញ បន្ទាប់មកគាត់បានសម្គាល់លើថេប្លេតកម្មវិធីតាមដានថាគាត់បានបំពេញភារកិច្ចរបស់គាត់ ហើយបញ្ជូនមូលដ្ឋានម្សៅដែលរមៀលចេញទៅស្ថានីយបន្ទាប់ - "ការបំពេញ" .

នៅទីនោះ អ្នកផលិតភីហ្សាបន្ទាប់ដាក់លើភីហ្សា បន្ទាប់មកសម្គាល់លើថេប្លេតថាគាត់បានបញ្ចប់កិច្ចការរបស់គាត់ ហើយដាក់ភីហ្សានៅក្នុងឡ (នេះក៏ជាស្ថានីយ៍ដាច់ដោយឡែកដែលចាំបាច់ត្រូវសម្គាល់នៅលើកុំព្យូទ័របន្ទះ)។ ប្រព័ន្ធបែបនេះមានវត្តមានតាំងពីដើមដំបូងនៅ Dodo និងតាំងពីដើមដំបូងនៃ Dodo IS ។ វាអនុញ្ញាតឱ្យអ្នកតាមដានយ៉ាងពេញលេញ និងធ្វើឌីជីថលប្រតិបត្តិការទាំងអស់។ លើសពីនេះ កម្មវិធីតាមដានណែនាំពីរបៀបរៀបចំផលិតផលជាក់លាក់មួយ អនុវត្តប្រភេទផលិតផលនីមួយៗតាមគ្រោងការណ៍ផលិតរបស់វា រក្សាទុកពេលវេលាចម្អិនអាហារល្អបំផុតសម្រាប់ផលិតផល និងតាមដានប្រតិបត្តិការទាំងអស់នៅលើផលិតផល។

នេះគឺជាអ្វីដែលអេក្រង់កុំព្យូទ័របន្ទះមើលទៅដូចនៅស្ថានីយ៍តាមដាន Raskatka។

តើបន្ទុកមកពីណា?

ភីហ្សានីមួយៗមានប្រហែលប្រាំគ្រាប់ដែលមានកម្មវិធីតាមដាន។ នៅឆ្នាំ 2016 យើងមានភីហ្សាជាង 100 (ហើយឥឡូវនេះមានច្រើនជាង 600) ។ ថេប្លេតនីមួយៗធ្វើការស្នើសុំទៅកាន់ផ្នែកខាងក្រោយរៀងរាល់ 10 វិនាទី ហើយប្រមូលទិន្នន័យពីតារាងបញ្ជាទិញ (ភ្ជាប់ជាមួយអតិថិជន និងអាសយដ្ឋាន) សមាសភាពនៃការបញ្ជាទិញ (តំណភ្ជាប់ជាមួយផលិតផល និងការចង្អុលបង្ហាញបរិមាណ) និងតារាងលើកទឹកចិត្ត (វាតាមដាន ពេលវេលានៃការចុច) ។ នៅពេលដែលក្រុមហ៊ុនផលិតភីហ្សាចុចលើផលិតផលនៅលើកម្មវិធីតាមដាន កំណត់ត្រានៅក្នុងតារាងទាំងអស់នេះត្រូវបានធ្វើបច្ចុប្បន្នភាព។ តារាងបញ្ជាទិញគឺទូទៅ វាក្នុងពេលដំណាលគ្នាមានសិលាចារឹកនៅពេលទទួលយកការបញ្ជាទិញ ការធ្វើបច្ចុប្បន្នភាពពីផ្នែកផ្សេងទៀតនៃប្រព័ន្ធ និងការអានជាច្រើនឧទាហរណ៍នៅលើទូរទស្សន៍ដែលព្យួរក្នុងហាងភីហ្សា និងបង្ហាញការបញ្ជាទិញដែលត្រៀមរួចជាស្រេចដល់អតិថិជន។

ក្នុងអំឡុងពេលនៃការតស៊ូជាមួយបន្ទុក នៅពេលដែលអ្វីៗគ្រប់យ៉ាង និងមនុស្សគ្រប់រូបត្រូវបានផ្ទុកក្នុងឃ្លាំងសម្ងាត់ និងផ្ទេរទៅការចម្លងនៃមូលដ្ឋានទិន្នន័យអសមកាល ប្រតិបត្តិការទាំងនេះជាមួយកម្មវិធីតាមដានបន្តទៅមូលដ្ឋានទិន្នន័យមេ។ មិនគួរមានការយឺតយ៉ាវនៅទីនេះទេ ទិន្នន័យត្រូវតែទាន់សម័យ មិនសមកាលកម្មមិនអាចទទួលយកបានទេ។

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

WAS ដំបូងស្ថាបត្យកម្មគឺដូចនេះ:

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

កំពុងផ្ទុកកម្មវិធីតាមដាន

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

យើងទទួលយកការបញ្ជាទិញនៅភោជនីយដ្ឋាន Checkout (នេះគឺជាសេវាកម្ម) វាត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យនៅក្នុងស្ថានភាព "ទទួលយក" ។ បន្ទាប់ពីនោះ វាគួរតែទៅកាន់កម្មវិធីតាមដាន ដែលវានឹងផ្លាស់ប្តូរស្ថានភាពរបស់វាច្រើនដងទៀត៖ ពី "ផ្ទះបាយ" ទៅ "ខ្ចប់"។ ក្នុងករណីនេះ ឥទ្ធិពលខាងក្រៅមួយចំនួនពី Cashier ឬចំណុចប្រទាក់កម្មវិធីគ្រប់គ្រងការផ្លាស់ប្តូរអាចកើតឡើងជាមួយនឹងការបញ្ជាទិញ។ ខ្ញុំនឹងផ្តល់ស្ថានភាពការបញ្ជាទិញជាមួយនឹងការពិពណ៌នារបស់ពួកគេនៅក្នុងតារាង៖

គ្រោងការណ៍ផ្លាស់ប្តូរស្ថានភាពការបញ្ជាទិញមើលទៅដូចនេះ៖

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

1. យើងប្រមូលផ្តុំសកម្មភាពបញ្ជាទិញទាំងអស់នៅក្នុងសេវាកម្មតែមួយ។ ក្នុងករណីរបស់យើង ជម្រើសនេះទាមទារសេវាកម្មច្រើនពេកដើម្បីដំណើរការការបញ្ជាទិញ។ បើ​យើង​ឈប់​នៅ​ទី​នោះ យើង​នឹង​ត្រូវ​បញ្ចប់​ដោយ​មនោរម្យ​ទីពីរ។ យើង​នឹង​មិន​បាន​ដោះស្រាយ​បញ្ហា​នោះ​ទេ។
2. ប្រព័ន្ធមួយធ្វើការហៅទៅមួយទៀត។ ជម្រើសទីពីរគឺគួរឱ្យចាប់អារម្មណ៍ជាង។ ប៉ុន្តែជាមួយវា ការហៅទូរសព្ទអាចធ្វើទៅបាន (ការបរាជ័យជាបណ្តើរៗ) ការតភ្ជាប់នៃសមាសធាតុគឺខ្ពស់ជាងហើយវាកាន់តែពិបាកក្នុងការគ្រប់គ្រង។
3. យើងរៀបចំព្រឹត្តិការណ៍ ហើយសេវាកម្មនីមួយៗផ្លាស់ប្តូរជាមួយអ្នកផ្សេងទៀតតាមរយៈព្រឹត្តិការណ៍ទាំងនេះ។ ជាលទ្ធផលជម្រើសទីបីត្រូវបានជ្រើសរើសដោយយោងទៅតាមសេវាកម្មទាំងអស់ចាប់ផ្តើមផ្លាស់ប្តូរព្រឹត្តិការណ៍ជាមួយគ្នា។

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

នៅពេលនោះ យើងមាន RabbitMQ នៅក្នុងជង់រួចហើយ ដូច្នេះការសម្រេចចិត្តចុងក្រោយក្នុងការប្រើប្រាស់វាជាឈ្មួញកណ្តាលសារ។ ដ្យាក្រាមបង្ហាញពីការផ្លាស់ប្តូរនៃការបញ្ជាទិញពីអ្នកគិតលុយភោជនីយដ្ឋានតាមរយៈកម្មវិធីតាមដាន ដែលជាកន្លែងដែលវាផ្លាស់ប្តូរស្ថានភាពរបស់វា និងការបង្ហាញរបស់វានៅលើចំណុចប្រទាក់ការបញ្ជាទិញរបស់អ្នកគ្រប់គ្រង។ បានក្លាយជា:

តម្រៀបតាមលំដាប់លំដោយ
ផ្លូវបញ្ជាទិញចាប់ផ្តើមពីសេវាកម្មប្រភពបញ្ជាទិញមួយ។ នេះជាអ្នកគិតលុយភោជនីយដ្ឋាន៖

1. ការបញ្ជាទិញគឺរួចរាល់ទាំងស្រុងនៅ Checkout ហើយវាដល់ពេលដែលត្រូវផ្ញើវាទៅអ្នកតាមដាន។ ព្រឹត្តិការណ៍ដែលអ្នកតាមដានត្រូវបានជាវត្រូវបានបោះចោល។
2. កម្មវិធីតាមដាន ទទួលយកការបញ្ជាទិញ រក្សាទុកវានៅក្នុងមូលដ្ឋានទិន្នន័យផ្ទាល់ខ្លួនរបស់វា បង្កើតព្រឹត្តិការណ៍ "បញ្ជាទិញបានទទួលយកដោយអ្នកតាមដាន" ហើយផ្ញើវាទៅ RMQ ។
3. អ្នកដោះស្រាយជាច្រើនបានជាវរថយន្តក្រុងព្រឹត្តិការណ៍ផ្ទាល់ខ្លួនរួចហើយ។ សម្រាប់យើង មួយដែលធ្វើសមកាលកម្មជាមួយមូលដ្ឋានទិន្នន័យ monolithic គឺមានសារៈសំខាន់។
4. អ្នកដោះស្រាយទទួលបានព្រឹត្តិការណ៍ ជ្រើសរើសទិន្នន័យដែលមានសារៈសំខាន់សម្រាប់វាពីវា៖ ក្នុងករណីរបស់យើង នេះគឺជាស្ថានភាពការបញ្ជាទិញ "បានទទួលយកដោយអ្នកតាមដាន" និងធ្វើបច្ចុប្បន្នភាពអង្គភាពបញ្ជាទិញរបស់វានៅក្នុងមូលដ្ឋានទិន្នន័យចម្បង។

ប្រសិនបើនរណាម្នាក់ត្រូវការការបញ្ជាទិញជាពិសេសពីតារាងបញ្ជាទិញ monolithic នោះពួកគេអាចអានវាពីទីនោះផងដែរ។ ឧទាហរណ៍ នេះជាអ្វីដែល Orders interface នៅក្នុង Shift Manager ត្រូវការ៖

សេវាកម្មផ្សេងទៀតទាំងអស់ក៏អាចជាវព្រឹត្តិការណ៍បញ្ជាពីកម្មវិធីតាមដានផងដែរ ដើម្បីប្រើប្រាស់វាសម្រាប់ខ្លួនគេ។

ប្រសិនបើបន្ទាប់ពីពេលខ្លះការបញ្ជាទិញត្រូវបានយកទៅផលិត ស្ថានភាពរបស់វាផ្លាស់ប្តូរដំបូងនៅក្នុងមូលដ្ឋានទិន្នន័យរបស់វា (មូលដ្ឋានទិន្នន័យតាមដាន) ហើយបន្ទាប់មកព្រឹត្តិការណ៍ "OrderInWork" ត្រូវបានបង្កើតភ្លាមៗ។ វាក៏ចូលទៅក្នុង RMQ ផងដែរពីកន្លែងដែលវាត្រូវបានធ្វើសមកាលកម្មនៅក្នុងមូលដ្ឋានទិន្នន័យ monolithic និងត្រូវបានបញ្ជូនទៅសេវាកម្មផ្សេងទៀត។ វាអាចមានបញ្ហាផ្សេងៗនៅតាមផ្លូវនេះ ព័ត៌មានលម្អិតបន្ថែមអំពីពួកវាអាចរកបាននៅក្នុងរបាយការណ៍របស់ Zhenya Peshkov អំពីព័ត៌មានលម្អិតនៃការអនុវត្តនៃភាពស៊ីសង្វាក់គ្នាជាយថាហេតុនៅក្នុងកម្មវិធីតាមដាន.

ស្ថាបត្យកម្មចុងក្រោយបន្ទាប់ពីការផ្លាស់ប្តូរនៅក្នុង Auth និង Tracker

សង្ខេប: ដំបូង​ឡើយ ខ្ញុំ​មាន​គំនិត​ក្នុង​ការ​វេចខ្ចប់​ប្រវត្តិ​ប្រាំបួន​ឆ្នាំ​នៃ​ប្រព័ន្ធ Dodo IS ទៅ​ក្នុង​អត្ថបទ​មួយ។ ខ្ញុំ​ចង់​និយាយ​យ៉ាង​ឆាប់​រហ័ស​អំពី​ដំណាក់កាល​នៃ​ការ​វិវត្តន៍។ ទោះជាយ៉ាងណាក៏ដោយ ដោយបានអង្គុយសិក្សាសម្ភារៈ ខ្ញុំបានដឹងថាអ្វីៗគឺស្មុគស្មាញ និងគួរឱ្យចាប់អារម្មណ៍ជាងវាទៅទៀត។

ដោយឆ្លុះបញ្ចាំងពីអត្ថប្រយោជន៍ (ឬកង្វះរបស់វា) នៃសម្ភារៈបែបនេះ ខ្ញុំបានសន្និដ្ឋានថា ការអភិវឌ្ឍន៍ជាបន្តមិនអាចទៅរួចទេ ប្រសិនបើគ្មានការរៀបរាប់ព្រឹត្តិការណ៍ពេញលេញ ការរំលឹកឡើងវិញលម្អិត និងការវិភាគលើការសម្រេចចិត្តពីមុនរបស់នរណាម្នាក់។

ខ្ញុំសង្ឃឹមថាអ្នកបានរកឃើញថាវាមានប្រយោជន៍ និងគួរឱ្យចាប់អារម្មណ៍ក្នុងការស្វែងយល់អំពីដំណើររបស់យើង។ ឥឡូវនេះខ្ញុំប្រឈមមុខនឹងជម្រើសនៃផ្នែកណាមួយនៃប្រព័ន្ធ Dodo IS ដើម្បីពិពណ៌នានៅក្នុងអត្ថបទបន្ទាប់៖ សរសេរនៅក្នុងមតិយោបល់ឬការបោះឆ្នោត។

មានតែអ្នកប្រើប្រាស់ដែលបានចុះឈ្មោះប៉ុណ្ណោះដែលអាចចូលរួមក្នុងការស្ទង់មតិនេះ។ ចូលសូម។

តើផ្នែកមួយណានៃ Dodo IS ដែលអ្នកចង់ស្វែងយល់នៅក្នុងអត្ថបទបន្ទាប់?

• 24,1%ដើមមនោរម្យនៅ Dodo IS (២០១១-២០១៥) ១៤

• 24,1%បញ្ហាដំបូង និងដំណោះស្រាយរបស់ពួកគេ (2015-2016) 14

• 20,7%ផ្លូវនៃផ្នែកអតិថិជន៖ facade ខាងលើមូលដ្ឋាន (2016-2017)12

• 36,2%ប្រវត្តិនៃសេវាមីក្រូពិតប្រាកដ (2018-2019) 21

• 44,8%បានបញ្ចប់ការកាត់ monolith និងស្ថេរភាពនៃស្ថាបត្យកម្ម26

• 29,3%អំពីផែនការបន្ថែមសម្រាប់ការអភិវឌ្ឍន៍ប្រព័ន្ធ ១៧

• 19,0%ខ្ញុំ​មិន​ចង់​ដឹង​អ្វី​ទាំងអស់​អំពី Dodo IS11

អ្នកប្រើប្រាស់ 58 នាក់បានបោះឆ្នោត។ អ្នកប្រើប្រាស់ ១៤ នាក់ត្រូវបានហាមឃាត់។

ប្រភព: www.habr.com