ការធ្វើអរូបីកម្មឧបករណ៍សម្រាប់ប្រព័ន្ធគ្រប់គ្រងគណនីច្រើន៖ ក្រុមវាលស្នូល 4

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

ការអនុវត្តដំបូងជាទូទៅត្រង់ខ្លាំង។ គណនី A ចង្អុលទៅ profile 001 គណនី B ចង្អុលទៅ profile 002 ហើយគណនី C ភ្ជាប់នឹង cloud phone មួយ។ បញ្ហាកើតឡើងនៅបីកន្លែង៖ ក្រុមប្រតិបត្តិការប្រាប់ថាម៉ាស៊ីនមួយខូច ហើយសួរថាអាចផ្លាស់គណនី A ទៅ cloud phone បានទេ ប៉ុន្តែចម្លើយគឺត្រូវកែ database ធ្វើដោយដៃ និងមានហានិភ័យ; ពេលភ្ជាប់ប្រភពឧបករណ៍ថ្មី ហើយសួរថាត្រូវបន្ថែមយ៉ាងដូចម្តេច ក៏ឃើញថាត្រូវ refactor ម៉ូឌុលគណនី; ឬចង់ឱ្យគណនីតែមួយប្រើ browser environment ពេលព្រឹក និង cloud phone ពេលរសៀលតាមពេលវេលា ដែលស្ទើរតែមិនអាចរៀបចំបានល្អ។

ស្ថានការណ៍ទាំងបីនេះមើលទៅមិនពាក់ព័ន្ធគ្នា ប៉ុន្តែមូលហេតុមានតែមួយ៖ account entity ត្រូវបានដាក់ព័ត៌មានដែលមិនមែនជារបស់វា។ ឧបករណ៍ដែលកំពុង login ឧបករណ៍ដែលធ្លាប់ប្រើ parameters នៃ fingerprint និងអាសយដ្ឋាន egress ត្រូវបានរក្សាទុកលើគណនីទាំងអស់។ ដូច្នេះ ការប្តូរឧបករណ៍ក្លាយជាការកែគណនី ហើយការផ្លាស់ប្តូរមួយប៉ះពាល់ដល់ប្រព័ន្ធទាំងមូល។

ធ្វើឱ្យឧបករណ៍ជាប្រភេទ object ដាច់ដោយឡែក

បន្ទាប់ពីបំបែក គណនី និងឧបករណ៍គួរមានទំនាក់ទំនង many-to-many។ គណនីមិនរក្សាទុក fingerprint ទេ ប៉ុន្តែកត់ត្រាតែថាបច្ចុប្បន្នភ្ជាប់នឹងឧបករណ៍ណា។ ការប្តូរឧបករណ៍គួរជា atomic operation ប្រវត្តិការភ្ជាប់គួររក្សាទុកក្នុងតារាងដាច់ដោយឡែក ហើយឧបករណ៍នីមួយៗគួរមាន identifier តែមួយគត់ ដែលជាអត្តសញ្ញាណតែមួយសម្រាប់ខាងក្រៅ និងអាចពិនិត្យស្ថានភាពបាន real time។

ការធ្វើបែបនេះមិនមែនដើម្បីឱ្យ model ស្អាតទេ។ វាកាត់បន្ថយចម្ងាយរវាងការកែតម្រូវដែលក្រុមប្រតិបត្តិការចង់ធ្វើ និងការកែ code ដែលក្រុមអភិវឌ្ឍត្រូវធ្វើ ហើយចម្ងាយនេះកើនតាមចំនួនឧបករណ៍។

ក្រុមវាល 4 ដែល abstraction layer ត្រូវកំណត់ឱ្យច្បាស់

Device abstraction ដែលអាចពង្រីកបាន ត្រូវឆ្លើយតែបួនចំណុចទៅខាងក្រៅ។

• Environment ID៖ តែមួយគត់ និងមានស្ថិរភាព។ ស្រទាប់ខាងលើគួរយោង environment តាម ID នេះប៉ុណ្ណោះ; លេខខាងក្នុង ឈ្មោះ container និង process ID មិនគួរបង្ហាញចេញក្រៅ
• Egress binding៖ environment នេះចេញតាម network egress ណា ហើយ time zone ភាសា និង DNS ដែលពាក់ព័ន្ធត្រូវបានកំណត់ជាសំណុំស្របគ្នាឬទេ។ បំបែក egress ជា abstraction ដាច់ដោយឡែកអាចប្តូរ egress ដោយមិនប្តូរ environment ខ្លួនវា
• Status៖ កំពុងបង្កើត, ត្រៀមចាប់ផ្តើម, កំពុងដំណើរការ, ត្រូវ task ប្រើ, មិនប្រក្រតី, រង់ចាំ reclaim។ បើគ្មាន status model នោះ pooling និង reclamation មិនអាចគ្រប់គ្រងបាន
• Lifecycle៖ អ្នកណា trigger ការបង្កើត ការចាប់ផ្តើម ការកាន់កាប់ ការដោះលែង និងការទាញយកមកវិញ; ត្រូវធ្វើអ្វីពេល task timeout; ហើយអ្នកណាសម្អាតពេល environment មានបញ្ហា

Status និង lifecycle ជាញឹកញាប់ត្រូវបានបញ្ចូលជាវាលតែមួយ។ វាជាវិធីងាយបំផុត ប៉ុន្តែក៏ថ្លៃបំផុតដែរ។ Status ឆ្លើយថា environment ឥឡូវនៅស្ថានភាពណា; lifecycle ឆ្លើយថាអ្នកណាអាចធ្វើសកម្មភាពបន្ទាប់។ នៅ production បញ្ហាពិតភាគច្រើនកើតពីចំណុចក្រោយ៖ task crash ហើយគ្មានអ្នកណា release environment ឬ environment នៅតែដំណើរការ តែត្រូវ reclaim ហើយទើបរកឃើញនៅពេល start លើកក្រោយថា egress បានផ្លាស់ប្តូរ។

Abstraction ខុស នឹងបង់ថ្លៃពេលពង្រីក

ពេលមាន environment ដប់ អាចមិនឃើញបញ្ហាអ្វីទេ។ ពេលឡើងដល់រាប់សិប ឬរាប់រយ បញ្ហានឹងផ្ទុះឡើងជាមួយគ្នា៖

• បន្ថែមប្រភេទឧបករណ៍ថ្មី ត្រូវកែម៉ូឌុលគណនី ធ្វើឱ្យ regression scope ពង្រីកពីស្រទាប់ឧបករណ៍ទៅស្រទាប់គណនី
• ប្តូរឧបករណ៍ត្រូវកែ database ដូច្នេះក្រុមប្រតិបត្តិការមិនហ៊ានប៉ះ ហើយប្រព័ន្ធបន្តិចម្តងៗក្លាយជារបស់ដែលមានតែ developer អាចថែទាំបាន
• បើគ្មានកំណត់ត្រា status និង occupancy environment ដែលនៅសល់ក្រោយ abnormal exit មិនត្រូវ reclaim ហើយ zombie environment នឹងកើនឡើង
• task, content និង automation នៅស្រទាប់ខាងលើត្រូវបានបង្កើតដោយសន្មតថាគណនី និងឧបករណ៍មានទំនាក់ទំនង one-to-one ដូច្នេះបើប្តូរសន្មតនេះ ត្រូវធ្វើខ្សែទាំងមូលឡើងវិញ

ឧបករណ៍ពីប្រភពផ្សេងៗមាន implementation ខុសគ្នាខ្លាំង។ Local browser environment និង cloud phone ប្រើ interface ខុសគ្នា។ តួនាទីរបស់ abstraction layer គឺដាក់ពួកវានៅក្រោយសំណុំ interface ដូចគ្នា។ ដើម្បីបន្ថែមប្រភេទឧបករណ៍ថ្មី គួរតែគ្រាន់តែបន្ថែម adapter ដែលអនុវត្ត start, stop និង status query ប៉ុណ្ណោះ ហើយ logic ស្រទាប់ខាងលើមិនត្រូវប្តូរ។ មានវិធីសាកល្បងសាមញ្ញមួយទៀត៖ ពេលបន្ថែមប្រភេទឧបករណ៍មួយ code ដែលត្រូវកែមានតែនៅក្នុង file មួយឬទេ?

នៅដំណាក់កាលដំបូង ធ្វើឱ្យតិចបំផុត

ពេល technical model ត្រូវបានកំណត់ ចំណុចប្រទាក់នឹងកាន់តែធម្មជាតិ។ រៀបចំ menu តាម business object ដោយបំបែកគណនី task និងឧបករណ៍ជាផ្នែកៗ មិនមែនតាម configuration, parameter និង log ទេ។ អ្វីដែលគួរមើលឃើញច្បាស់ជាងគេគឺ status និង exception ព្រោះអ្នកប្រើចង់ដឹងថាមានបញ្ហាឬអត់ មិនមែនចំនួន record ទេ។

ផ្នែកមុខងារ ដំណាក់កាលដំបូងមានតែបញ្ជីឧបករណ៍ ការបន្ថែមឧបករណ៍ និង task flow អប្បបរមាមួយដែលរត់ចប់ពីដើមដល់ចប់ គឺគ្រប់គ្រាន់។ កាត់ menu ឱ្យតិចតាមដែលអាចធ្វើបាន ធ្វើរឿងមួយឱ្យដំណើរការចប់សព្វគ្រប់សិន ហើយអ្វីដែលមិនចាំបាច់ ទុកពេលក្រោយ។

បើមិនចង់អនុវត្ត environment isolation ពីសូន្យ អាចប្រើសមត្ថភាពដែលមានស្រាប់។ PurpleMark ផ្តល់ independent environment និង egress binding គាំទ្រការបង្កើតជាបាច់តាមក្រុម និង status query។ ស្រទាប់ខាងលើត្រូវអនុវត្តតែ template, occupancy និង task scheduling ដើម្បីរក្សាកម្លាំងវិស្វកម្មឱ្យផ្តោតលើ business logic។

ភាពស្មុគស្មាញរបស់ប្រព័ន្ធគណនីច្រើន មិនដែលស្ថិតនៅលើចំនួនគណនីទេ ប៉ុន្តែនៅលើការគ្រប់គ្រង lifecycle របស់ឧបករណ៍។ ចាប់ផ្តើមដោយចាត់ទុកឧបករណ៍ជា resource ដែលមាន identity, egress, status និង lifecycle ដូច្នេះមុខងារស្រទាប់ខាងលើមិនត្រូវបានបំបែកហើយសាងសង់ឡើងវិញរាល់ពេលបន្ថែមអ្វីថ្មី។