វាហាក់ដូចជាថាកំពូលនៃការបំផ្លើសសម្រាប់សេវាមីក្រូគឺនៅពីក្រោយយើង។ យើងលែងអានប្រកាសជាច្រើនដងក្នុងមួយសប្តាហ៍ "របៀបដែលខ្ញុំផ្លាស់ទី monolith របស់ខ្ញុំទៅ 150 សេវាកម្ម" ។ ឥឡូវ​នេះ​ខ្ញុំ​ឮ​គំនិត​ធម្មតា​ច្រើន​ទៀត៖ «ខ្ញុំ​មិន​ស្អប់​មនោរម្យ​ទេ ខ្ញុំ​គ្រាន់​តែ​ខ្វល់​ពី​ប្រសិទ្ធភាព»។ យើងថែមទាំងបានសង្កេតឃើញការធ្វើចំណាកស្រុកជាច្រើន។ ពី microservices ត្រឡប់ទៅ monolith. នៅពេលផ្លាស់ប្តូរពីកម្មវិធីធំមួយទៅសេវាកម្មតូចជាងច្រើន អ្នកនឹងត្រូវដោះស្រាយបញ្ហាថ្មីៗជាច្រើន។ ចូរយើងរាយបញ្ជីពួកវាឱ្យបានខ្លីតាមដែលអាចធ្វើទៅបាន។

ការកំណត់៖ ពីគីមីវិទ្យាមូលដ្ឋានដល់មេកានិចកង់ទិច

ការដំឡើងមូលដ្ឋានទិន្នន័យ និងកម្មវិធីដែលមានដំណើរការផ្ទៃខាងក្រោយគឺជាដំណើរការដ៏សាមញ្ញមួយ។ ខ្ញុំបោះផ្សាយ readme នៅលើ Github ហើយជារឿយៗបន្ទាប់ពីមួយម៉ោង ពីរបីម៉ោង អ្វីៗដំណើរការបាន ហើយខ្ញុំចាប់ផ្តើមគម្រោងថ្មី។ ការបន្ថែម និងដំណើរការកូដ យ៉ាងហោចណាស់សម្រាប់បរិស្ថានដំបូង គឺធ្វើឡើងនៅថ្ងៃទីមួយ។ ប៉ុន្តែ​ប្រសិន​បើ​យើង​ចូល​ទៅ​ក្នុង​សេវា​មីក្រូ​ នោះ​ពេល​ចាប់​ផ្តើម​ដំបូង​ឡើង​ខ្ពស់​។ មែនហើយ ឥឡូវនេះយើងមាន Docker ជាមួយនឹងវង់ភ្លេង និងចង្កោមម៉ាស៊ីន K8 ប៉ុន្តែសម្រាប់អ្នកសរសេរកម្មវិធីថ្មីថ្មោង អ្វីៗទាំងអស់នេះគឺស្មុគស្មាញជាង។ សម្រាប់ក្មេងជំទង់ជាច្រើន នេះគឺជាបន្ទុកដែលពិតជាផលវិបាកដែលមិនចាំបាច់។

ប្រព័ន្ធមិនងាយយល់ទេ។

សូម​ផ្តោត​លើ​យុវជន​របស់​យើង​មួយ​ភ្លែត។ ជាមួយនឹងកម្មវិធី monolithic ប្រសិនបើកំហុសបានកើតឡើង វាងាយស្រួលក្នុងការតាមដានវា ហើយបន្តទៅការកែកំហុសភ្លាមៗ។ ឥឡូវនេះ យើងមានសេវាកម្មដែលកំពុងនិយាយទៅកាន់សេវាកម្មមួយផ្សេងទៀតដែលកំពុងតម្រង់ជួរអ្វីមួយនៅលើឡានក្រុងសារដែលកំពុងដំណើរការសេវាកម្មមួយផ្សេងទៀត ហើយបន្ទាប់មកមានកំហុសកើតឡើង។ យើងត្រូវដាក់បំណែកទាំងអស់នេះជាមួយគ្នា ដើម្បីដឹងថា សេវាកម្ម A កំពុងដំណើរការកំណែ 11 ហើយ Service E កំពុងរង់ចាំកំណែ 12 រួចហើយ។ វាខុសគ្នាខ្លាំងពីកំណត់ហេតុរួមស្តង់ដាររបស់ខ្ញុំ៖ ដោយត្រូវប្រើស្ថានីយអន្តរកម្ម/បំបាត់កំហុសដើម្បីដើរ។ តាមរយៈដំណើរការមួយជំហានម្តង ៗ ។ ការបំបាត់កំហុស និងការយល់ដឹងបានក្លាយទៅជាការលំបាកជាងមុន។

ប្រសិនបើវាមិនអាចត្រូវបានបំបាត់កំហុសទេ ប្រហែលជាយើងនឹងសាកល្បងពួកវា

ការធ្វើសមាហរណកម្មជាបន្តបន្ទាប់ និងការអភិវឌ្ឍន៍ជាបន្តបន្ទាប់ ឥឡូវនេះបានក្លាយជារឿងធម្មតា។ កម្មវិធីថ្មីភាគច្រើនដែលខ្ញុំឃើញបង្កើត និងដំណើរការការធ្វើតេស្តដោយស្វ័យប្រវត្តិជាមួយនឹងការចេញផ្សាយថ្មីនីមួយៗ ហើយតម្រូវឱ្យធ្វើតេស្ត និងពិនិត្យមុនពេលចុះឈ្មោះ។ ទាំងនេះគឺជាដំណើរការដ៏អស្ចារ្យដែលមិនគួរត្រូវបានបោះបង់ចោល ហើយបានក្លាយជាការផ្លាស់ប្តូរដ៏ធំមួយសម្រាប់ក្រុមហ៊ុនជាច្រើន។ ប៉ុន្តែឥឡូវនេះ ដើម្បីសាកល្បងសេវាកម្មពិតប្រាកដ ខ្ញុំត្រូវតែទាញយកកំណែពេញលេញនៃកម្មវិធីរបស់ខ្ញុំ។ ចងចាំវិស្វករថ្មីដែលមានចង្កោម K8 នៃសេវាកម្ម 150? ឥឡូវនេះ យើងនឹងបង្រៀនប្រព័ន្ធ CI របស់យើងពីរបៀបបង្កើតប្រព័ន្ធទាំងអស់នេះ ដើម្បីផ្ទៀងផ្ទាត់ថាអ្វីៗពិតជាដំណើរការ។ នេះប្រហែលជាការប្រឹងប្រែងខ្លាំងពេក ដូច្នេះយើងនឹងសាកល្បងផ្នែកនីមួយៗដោយឯកោ៖ ខ្ញុំជឿជាក់ថាលក្ខណៈពិសេសរបស់យើងគឺល្អគ្រប់គ្រាន់ APIs គឺស្អាត ហើយការបរាជ័យនៃសេវាកម្មគឺដាច់ដោយឡែក ហើយនឹងមិនប៉ះពាល់ដល់អ្នកដទៃទេ។

ការសម្របសម្រួលទាំងអស់មានហេតុផលល្អ។ មែនទេ?

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

ប៉ុន្តែខ្ញុំតែងតែចាប់អារម្មណ៍ក្នុងការរៀនអំពីស្ថាបត្យកម្មរបស់ពួកគេ។ តើ​ពួកគេ​ស្ថិត​នៅ​ដំណាក់កាល​ណា​នៃ​ការ​ផ្លាស់​ប្តូរ​ទៅ​មីក្រូ​សេវា? វាគួរឱ្យចាប់អារម្មណ៍ក្នុងការឃើញវិស្វករកាន់តែច្រើននិយាយថាពួកគេសប្បាយចិត្តជាមួយនឹងកម្មវិធី monolithic របស់ពួកគេ។ មនុស្សជាច្រើននឹងទទួលបានអត្ថប្រយោជន៍ពីសេវាមីក្រូ ហើយអត្ថប្រយោជន៍នឹងលើសពីភាពរដិបរដុបនៅក្នុងផ្លូវធ្វើចំណាកស្រុក។ ប៉ុន្តែដោយផ្ទាល់ សូមផ្តល់ឱ្យខ្ញុំនូវកម្មវិធី monolithic របស់ខ្ញុំ កន្លែងមួយនៅលើឆ្នេរ - ហើយខ្ញុំសប្បាយចិត្តទាំងស្រុង។

ប្រភព: www.habr.com