ការជ្រើសរើសរចនាប័ទ្មស្ថាបត្យកម្ម (ផ្នែកទី 3)

សួស្តី Habr ។ ថ្ងៃនេះខ្ញុំបន្តការបោះពុម្ពជាបន្តបន្ទាប់ដែលខ្ញុំបានសរសេរជាពិសេសសម្រាប់ការចាប់ផ្តើមនៃវគ្គសិក្សាថ្មីនេះ។ "ស្ថាបត្យករផ្នែកទន់".

សេចក្តីណែនាំ

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

កាលពីលើកមុន យើងបាននិយាយអំពីប្រភេទផ្សេងគ្នានៃ monoliths និងការប្រើប្រាស់សមាសធាតុដើម្បីបង្កើតពួកវា ទាំងផ្នែកសាងសង់ និងសមាសភាគដាក់ពង្រាយ។ យើងយល់ពីស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្ម។

ឥឡូវនេះយើងនឹងកំណត់លក្ខណៈសំខាន់នៃស្ថាបត្យកម្មមីក្រូសេវាកម្ម។

ទំនាក់ទំនងនៃស្ថាបត្យកម្ម

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

លក្ខណៈពិសេសនៃស្ថាបត្យកម្មមីក្រូសឺវីស

លក្ខណៈសំខាន់ៗនៃស្ថាបត្យកម្មមីក្រូសេវាកម្មគឺ៖

• រៀបចំជុំវិញសមត្ថភាពអាជីវកម្ម
• ផលិតផលមិនមែនជាគម្រោង
• ចំណុច​ចុង​ឆ្លាត និង​បំពង់​មិន​ស្អាត
• អភិបាលកិច្ចវិមជ្ឈការ
• ការគ្រប់គ្រងទិន្នន័យវិមជ្ឈការ
• ស្វ័យប្រវត្តិកម្មហេដ្ឋារចនាសម្ព័ន្ធ
• ការរចនាសម្រាប់ការបរាជ័យ
• ស្ថាបត្យកម្មជាមួយនឹងការអភិវឌ្ឍន៍វិវត្តន៍ (Evolutionary Design)

ចំណុចទី 1 មកពីស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្ម ពីព្រោះសេវាមីក្រូគឺជាករណីពិសេសនៃសេវាកម្ម។ ចំណុចផ្សេងទៀតសមនឹងទទួលបានការពិចារណាដាច់ដោយឡែក។

រៀបចំជុំវិញសមត្ថភាពអាជីវកម្ម

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

ប្រសិនបើយើងកំពុងនិយាយអំពី monoliths និង microservices នោះប្រសិនបើការអភិវឌ្ឍន៍ត្រូវបានរៀបចំដោយនាយកដ្ឋានមុខងារ (backend, frontend, database administrator) នោះយើងទទួលបាន monolith បុរាណ។

ដើម្បីទទួលបានសេវាខ្នាតតូច ក្រុមត្រូវតែរៀបចំដោយសមត្ថភាពអាជីវកម្ម (ការបញ្ជាទិញ ការដឹកជញ្ជូន ក្រុមកាតាឡុក)។ អង្គការនេះនឹងអនុញ្ញាតឱ្យក្រុមផ្តោតលើការកសាងផ្នែកជាក់លាក់នៃកម្មវិធី។

ផលិតផលមិនមែនជាគម្រោង

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

ចំណុច​ចុង​ឆ្លាត និង​បំពង់​មិន​ស្អាត

ស្ថាបត្យកម្ម SOA បានយកចិត្តទុកដាក់យ៉ាងខ្លាំងចំពោះបណ្តាញទំនាក់ទំនង ជាពិសេសរថយន្តក្រុងសេវាកម្មសហគ្រាស។ ដែលជារឿយៗនាំទៅដល់ Error Spaghetti Box នោះគឺភាពស្មុគស្មាញនៃ monolith ប្រែទៅជាភាពស្មុគស្មាញនៃការតភ្ជាប់រវាងសេវាកម្ម។ ស្ថាបត្យកម្ម Microservice ប្រើតែវិធីទំនាក់ទំនងសាមញ្ញប៉ុណ្ណោះ។

អភិបាលកិច្ចវិមជ្ឈការ

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

ការគ្រប់គ្រងទិន្នន័យវិមជ្ឈការ

វិធីសាស្រ្តស្តង់ដារ ដែលកម្មវិធីពឹងផ្អែកលើមូលដ្ឋានទិន្នន័យតែមួយ មិនអាចគិតគូរពីភាពជាក់លាក់នៃសេវាកម្មជាក់លាក់នីមួយៗបានទេ។ MSA ពាក់ព័ន្ធនឹងការគ្រប់គ្រងទិន្នន័យវិមជ្ឈការ រួមទាំងការប្រើប្រាស់បច្ចេកវិទ្យាផ្សេងៗ។

ស្វ័យប្រវត្តិកម្មហេដ្ឋារចនាសម្ព័ន្ធ

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

ការរចនាសម្រាប់ការបរាជ័យ

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

ស្ថាបត្យកម្មជាមួយនឹងការអភិវឌ្ឍន៍វិវត្តន៍ (Evolutionary Design)

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

សេចក្តីសន្និដ្ឋាន

បន្ទាប់ពីទាំងអស់ខាងលើ យើងអាចបង្កើតនូវអ្វីទៅជាសេវាកម្មមីក្រូ។ ស្ថាបត្យកម្ម Microservice គឺជាវិធីសាស្រ្តមួយក្នុងការអភិវឌ្ឍន៍កម្មវិធីតែមួយជាបណ្តុំនៃសេវាកម្មតូចៗ ដែលនីមួយៗដំណើរការក្នុងដំណើរការរបស់វាផ្ទាល់ និងអន្តរកម្មតាមរយៈយន្តការទម្ងន់ស្រាល ជាញឹកញាប់ HTTP resource APIs ។ សេវាកម្មទាំងនេះត្រូវបានបង្កើតឡើងនៅលើសមត្ថភាពអាជីវកម្ម និងអាចដាក់ឱ្យប្រើប្រាស់ដោយឯករាជ្យដោយប្រើប្រាស់ពេញលេញ
យន្តការដាក់ពង្រាយដោយស្វ័យប្រវត្តិ។ មានកម្រិតអប្បបរមានៃការគ្រប់គ្រងកណ្តាលនៃសេវាកម្មទាំងនេះ ដែលអាចត្រូវបានសរសេរជាភាសាសរសេរកម្មវិធីផ្សេងៗគ្នា និងប្រើប្រាស់បច្ចេកវិទ្យាផ្ទុកទិន្នន័យផ្សេងៗគ្នា។

អានផ្នែកទី 2

ប្រភព: www.habr.com