Microservices - ការផ្ទុះរួមបញ្ចូលគ្នានៃកំណែ

សួស្តី ហាប! ខ្ញុំបង្ហាញការយកចិត្តទុកដាក់របស់អ្នក។ ការបកប្រែអត្ថបទរបស់អ្នកនិពន្ធ Microservices - ការផ្ទុះរួមគ្នានៃកំណែ.

នៅពេលដែលពិភពព័ត៌មានវិទ្យាកំពុងផ្លាស់ប្តូរបន្តិចម្តងៗឆ្ពោះទៅរកសេវាមីក្រូ និងឧបករណ៍ដូចជា Kubernetes បញ្ហាតែមួយគត់គឺកាន់តែគួរឱ្យកត់សម្គាល់។ បញ្ហា​នេះ - ការផ្ទុះរួមបញ្ចូលគ្នា កំណែ microservice ។ ទោះជាយ៉ាងណាក៏ដោយសហគមន៍ IT ជឿជាក់ថាស្ថានភាពបច្ចុប្បន្នគឺប្រសើរជាង "ឋាននរកអាស្រ័យ" ជំនាន់មុននៃបច្ចេកវិទ្យា។ ទោះយ៉ាងណាក៏ដោយ កំណែទម្រង់សេវាមីក្រូគឺជាបញ្ហាស្មុគស្មាញណាស់។ ភស្តុតាងមួយនៃរឿងនេះអាចជាអត្ថបទដូចជា «ប្រគល់​មនោរម្យ​របស់​ខ្ញុំ​មក​វិញ».

ប្រសិនបើអ្នកនៅតែមិនយល់ពីបញ្ហាដោយការអានអត្ថបទនេះខ្ញុំសូមពន្យល់។ ចូរនិយាយថាផលិតផលរបស់អ្នកមាន 10 microservices។ ឥឡូវនេះ សូមសន្មតថាកំណែថ្មី 1 ត្រូវបានចេញផ្សាយសម្រាប់សេវាមីក្រូទាំងនេះនីមួយៗ។ មានតែកំណែ 1 ប៉ុណ្ណោះ - ខ្ញុំសង្ឃឹមថាយើងទាំងអស់គ្នាអាចយល់ស្របថានេះគឺជាការពិតដ៏កម្រនិងមិនសំខាន់។ យ៉ាង​ណា​ក៏​ដោយ ឥឡូវ​សូម​មើល​ផលិតផល​របស់​យើង​មួយ​ទៀត។ ជាមួយនឹងកំណែថ្មីនៃសមាសភាគនីមួយៗ ឥឡូវនេះយើងមាន 2^10 - ឬ 1024 ការផ្លាស់ប្តូរពីរបៀបដែលផលិតផលរបស់យើងអាចត្រូវបានផ្សំ។

បើ​នៅ​តែ​មាន​ការ​យល់​ខុស​ខ្ញុំ​សូម​បំបែក​គណិតវិទ្យា​។ ដូច្នេះយើងមានសេវាមីក្រូចំនួន 10 ដែលនីមួយៗទទួលបានបច្ចុប្បន្នភាពមួយ។ នោះគឺយើងទទួលបានកំណែដែលអាចធ្វើទៅបានចំនួន 2 សម្រាប់សេវាមីក្រូនីមួយៗ (ទាំងចាស់ ឬថ្មី)។ ឥឡូវនេះ សម្រាប់សមាសធាតុផលិតផលនីមួយៗ យើងអាចប្រើកំណែទាំងពីរនេះ។ តាម​គណិតវិទ្យា វា​ដូច​គ្នា​នឹង​យើង​មាន​លេខ​គោល​ដប់​ខ្ទង់។ ឧទាហរណ៍ ឧបមាថា 10 គឺជាកំណែថ្មី ហើយ 1 គឺជាកំណែចាស់ - បន្ទាប់មកការផ្លាស់ប្តូរដែលអាចធ្វើបានអាចត្រូវបានតំណាងថាជា 0 - ដែលសមាសធាតុទី 1001000000 និងទី 1 ត្រូវបានអាប់ដេត ហើយធាតុផ្សេងទៀតទាំងអស់មិនមានទេ។ ពីគណិតវិទ្យា យើងដឹងថា លេខគោលពីរខ្ទង់ 4 ខ្ទង់ អាចមានតម្លៃ 10^2 ឬ 10។ នោះគឺយើងបានបញ្ជាក់ពីមាត្រដ្ឋាននៃចំនួនដែលយើងកំពុងដោះស្រាយ។

ចូរបន្តការវែកញែករបស់យើងបន្ថែមទៀត - តើនឹងមានអ្វីកើតឡើងប្រសិនបើយើងមានសេវាមីក្រូ 100 ហើយនីមួយៗមាន 10 កំណែដែលអាចធ្វើបាន? ស្ថានភាពទាំងមូលក្លាយទៅជាមិនសប្បាយចិត្ត - ឥឡូវនេះយើងមានការផ្លាស់ប្តូរ 10^100 - ដែលជាចំនួនដ៏ធំ។ ទោះជាយ៉ាងណាក៏ដោយ ខ្ញុំចូលចិត្តដាក់ស្លាកស្ថានភាពនេះតាមវិធីនេះ ពីព្រោះឥឡូវនេះយើងលែងលាក់បាំងពីពាក្យដូចជា "kubernetes" ទៀតហើយ ប៉ុន្តែត្រូវប្រឈមមុខនឹងបញ្ហាដូចដែលវាកើតឡើង។

ហេតុអ្វីបានជាខ្ញុំចាប់អារម្មណ៍ខ្លាំងចំពោះបញ្ហានេះ? មួយផ្នែកដោយសារតែកាលពីមុនបានធ្វើការនៅក្នុងពិភពនៃ NLP និង AI យើងបានពិភាក្សាអំពីបញ្ហានៃការផ្ទុះរួមបញ្ចូលគ្នាជាច្រើនប្រហែល 5-6 ឆ្នាំមុន។ ជំនួសឱ្យកំណែដែលយើងមានពាក្យនីមួយៗ ហើយជំនួសឱ្យផលិតផលយើងមានប្រយោគ និងកថាខណ្ឌ។ ហើយទោះបីជាបញ្ហារបស់ NLP និង AI នៅតែមិនអាចដោះស្រាយបានក៏ដោយ ក៏វាត្រូវតែទទួលស្គាល់ថាមានការរីកចម្រើនគួរឱ្យកត់សម្គាល់ក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ។ (តាមគំនិតរបស់ខ្ញុំ វឌ្ឍនភាពអាចធ្វើទៅបានоវានឹងប្រសើរជាងប្រសិនបើមនុស្សនៅក្នុងឧស្សាហកម្មនេះមិនសូវយកចិត្តទុកដាក់លើការរៀនម៉ាស៊ីន និងតិចនិចផ្សេងទៀតចំពោះបច្ចេកទេសផ្សេងទៀត - ប៉ុន្តែនេះគឺជាប្រធានបទរួចទៅហើយ)។

ចូរយើងត្រលប់ទៅពិភពនៃ DevOps និងសេវាកម្មមីក្រូ។ យើងកំពុងប្រឈមមុខនឹងបញ្ហាដ៏ធំមួយ ដោយបន្លំខ្លួនជាដំរីនៅក្នុង Kunstkamera ពីព្រោះអ្វីដែលខ្ញុំតែងតែឮគឺ "គ្រាន់តែយក kubernetes និងមួក ហើយអ្វីៗនឹងល្អ!" ប៉ុន្តែ​ទេ អ្វីៗ​នឹង​មិន​ល្អ​ឡើយ បើ​អ្វីៗ​នៅ​សល់​ដូច​ជា។ ជាងនេះទៅទៀត ដំណោះស្រាយវិភាគចំពោះបញ្ហានេះហាក់ដូចជាមិនអាចទទួលយកបានទេ ដោយសារភាពស្មុគស្មាញរបស់វា។ ដូចនៅក្នុង NLP ជាដំបូងយើងគួរតែដោះស្រាយបញ្ហានេះដោយបង្រួមវិសាលភាពស្វែងរក - ក្នុងករណីនេះដោយការលុបបំបាត់ការផ្លាស់ប្តូរហួសសម័យ។

រឿងមួយដែលអាចជួយបានគឺអ្វីមួយដែលខ្ញុំបានសរសេរកាលពីឆ្នាំមុន អំពីតម្រូវការដើម្បីរក្សាភាពខុសគ្នាអប្បបរមារវាងកំណែដែលបានបង្ហោះសម្រាប់អតិថិជន. វាក៏សំខាន់ផងដែរក្នុងការកត់សម្គាល់ថាដំណើរការ CI/CD ដែលបានរចនាយ៉ាងល្អជួយក្នុងការកាត់បន្ថយការប្រែប្រួលផ្សេងៗ។ ទោះយ៉ាងណាក៏ដោយ ស្ថានភាពបច្ចុប្បន្នជាមួយ CI/CD គឺមិនល្អគ្រប់គ្រាន់ក្នុងការដោះស្រាយបញ្ហានៃការប្តូរដោយគ្មានឧបករណ៍បន្ថែមសម្រាប់ផ្នែកគណនេយ្យ និងតាមដានទេ។

អ្វីដែលយើងត្រូវការគឺប្រព័ន្ធនៃការពិសោធន៍នៅដំណាក់កាលសមាហរណកម្ម ដែលយើងអាចកំណត់កត្តាហានិភ័យសម្រាប់សមាសធាតុនីមួយៗ ហើយក៏មានដំណើរការស្វ័យប្រវត្តិសម្រាប់ការធ្វើបច្ចុប្បន្នភាពសមាសធាតុផ្សេងៗ និងការធ្វើតេស្តដោយគ្មានអន្តរាគមន៍ពីប្រតិបត្តិករ - ដើម្បីមើលអ្វីដែលដំណើរការ និងអ្វីដែលមិនដំណើរការ។

ប្រព័ន្ធនៃការពិសោធន៍បែបនេះអាចមើលទៅដូចនេះ៖

1. អ្នកអភិវឌ្ឍន៍សរសេរការធ្វើតេស្ត (នេះគឺជាដំណាក់កាលសំខាន់ - ពីព្រោះបើមិនដូច្នេះទេយើងមិនមានលក្ខណៈវិនិច្ឆ័យវាយតម្លៃ - វាដូចជាការដាក់ស្លាកទិន្នន័យនៅក្នុងការរៀនម៉ាស៊ីន)។
2. សមាសធាតុនីមួយៗ (គម្រោង) ទទួលបានប្រព័ន្ធ CI ផ្ទាល់ខ្លួន - ដំណើរការនេះត្រូវបានអភិវឌ្ឍយ៉ាងល្អ ហើយបញ្ហានៃការបង្កើតប្រព័ន្ធ CI សម្រាប់សមាសភាគតែមួយត្រូវបានដោះស្រាយយ៉ាងទូលំទូលាយ។
3. "ប្រព័ន្ធសមាហរណកម្មឆ្លាតវៃ" ប្រមូលលទ្ធផលនៃប្រព័ន្ធ CI ផ្សេងៗ ហើយប្រមូលផ្តុំគម្រោងសមាសភាគទៅក្នុងផលិតផលចុងក្រោយ ដំណើរការសាកល្បង និងចុងក្រោយគណនាផ្លូវខ្លីបំផុតដើម្បីទទួលបានមុខងារផលិតផលដែលចង់បានដោយផ្អែកលើសមាសធាតុដែលមានស្រាប់ និងកត្តាហានិភ័យ។ ប្រសិនបើការអាប់ដេតមិនអាចធ្វើទៅបានទេ ប្រព័ន្ធនេះជូនដំណឹងដល់អ្នកអភិវឌ្ឍន៍អំពីសមាសធាតុដែលមានស្រាប់ និងមួយណាដែលបង្កបញ្ហា។ ជា​ថ្មី​ម្តង​ទៀត ប្រព័ន្ធ​តេស្ត​មាន​សារៈ​សំខាន់​នៅ​ទី​នេះ - ចាប់​តាំង​ពី​ប្រព័ន្ធ​រួម​បញ្ចូល​គ្នា​ប្រើ​ការ​ធ្វើ​តេស្ត​ជា​លក្ខណៈ​វិនិច្ឆ័យ​វាយ​តម្លៃ។
4. ប្រព័ន្ធ CD ដែលបន្ទាប់មកទទួលទិន្នន័យពីប្រព័ន្ធ Smart Integration System ហើយធ្វើបច្ចុប្បន្នភាពដោយផ្ទាល់។ ដំណាក់កាលនេះបញ្ចប់វដ្ត។

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

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

Microservices ធ្វើអោយស្ថានភាពប្រសើរឡើង ប៉ុន្តែបន្ទាប់មក ស្ថាបត្យកម្ម microservice ប្រឈមមុខនឹងបញ្ហានៃការផ្ទុះ combinatorial នៅដំណាក់កាលសមាហរណកម្ម។ បាទ/ចាស ជាទូទៅ យើងបានផ្លាស់ប្តូរបញ្ហាដូចគ្នាពីដំណាក់កាលអភិវឌ្ឍន៍ទៅដំណាក់កាលសមាហរណកម្ម។ ទោះយ៉ាងណាក៏ដោយ តាមគំនិតរបស់ខ្ញុំ វិធីសាស្ត្រមីក្រូសេវាកម្មនៅតែនាំទៅរកលទ្ធផលប្រសើរជាងមុន ហើយក្រុមសម្រេចបានលទ្ធផលលឿនជាងមុន (ប្រហែលជាភាគច្រើនដោយសារការកាត់បន្ថយទំហំនៃអង្គភាពអភិវឌ្ឍន៍ ឬ ទំហំបាច់) ទោះជាយ៉ាងណាក៏ដោយ ការផ្លាស់ប្តូរពី monolith ទៅ microservices មិនទាន់ធ្វើអោយដំណើរការបានប្រសើរឡើងនៅឡើយទេ - ការផ្ទុះរួមបញ្ចូលគ្នានៃ microservice versions គឺជាបញ្ហាដ៏ធំមួយ ហើយយើងមានសក្តានុពលជាច្រើនក្នុងការធ្វើអោយស្ថានភាពប្រសើរឡើងនៅពេលយើងដោះស្រាយវា។

ប្រភព: www.habr.com