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

ជំរាបសួរ, habr ។ ការចុះឈ្មោះសម្រាប់វគ្គសិក្សាថ្មីគឺបើកឥឡូវនេះនៅ OTUS "ស្ថាបត្យករផ្នែកទន់". នៅមុនថ្ងៃនៃការចាប់ផ្តើមវគ្គសិក្សា ខ្ញុំចង់ចែករំលែកជាមួយអ្នកនូវអត្ថបទដើមរបស់ខ្ញុំ។

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

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

បន្តិចនៃប្រវត្តិសាស្រ្ត

ប្រសិនបើអ្នកព្យាយាមសួរអ្នកអភិវឌ្ឍន៍ថា "ហេតុអ្វីបានជាយើងត្រូវការសេវាកម្មមីក្រូ?" អ្នកនឹងទទួលបានចម្លើយផ្សេងៗគ្នា។ អ្នកនឹងឮថាសេវាមីក្រូកែលំអលទ្ធភាពធ្វើមាត្រដ្ឋាន ធ្វើឱ្យកូដកាន់តែងាយស្រួលយល់ កែលម្អការអត់ធ្មត់កំហុស ហើយពេលខ្លះអ្នកនឹងឮថាពួកគេអនុញ្ញាតឱ្យអ្នក "សម្អាតកូដរបស់អ្នក" ។ សូមក្រឡេកមើលប្រវត្តិសាស្រ្តដើម្បីយល់ពីគោលបំណងនៅពីក្រោយការលេចចេញនៃសេវាកម្មមីក្រូ។

សរុបមក សេវាមីក្រូនៅក្នុងការយល់ដឹងរបស់យើងបានកើតមានឡើងដូចខាងក្រោម៖ ក្នុងឆ្នាំ 2011 លោក James Lewis បានធ្វើការវិភាគលើការងាររបស់ក្រុមហ៊ុនផ្សេងៗបានទាក់ទាញការយកចិត្តទុកដាក់ចំពោះការលេចចេញនូវគំរូ "មីក្រូកម្មវិធី" ថ្មី ដែលធ្វើអោយ SOA ប្រសើរឡើងក្នុងលក្ខខណ្ឌនៃការពន្លឿនការដាក់ឱ្យប្រើប្រាស់។ សេវាកម្ម។ បន្តិចក្រោយមក ក្នុងឆ្នាំ 2012 នៅឯកិច្ចប្រជុំកំពូលស្ថាបត្យកម្ម គំរូនេះត្រូវបានប្តូរឈ្មោះទៅជាសេវាកម្មមីក្រូ។ ដូច្នេះ គោលដៅដំបូងនៃការណែនាំអំពីសេវាកម្មមីក្រូគឺដើម្បីកែលម្អភាពល្បីល្បាញ ពេលវេលាទៅទីផ្សារ.

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

ទោះបីជាទាំងអស់ខាងលើក៏ដោយ អ្នកអភិវឌ្ឍន៍មួយចំនួនតូចនៅតែអាចកំណត់គោលគំនិតនៃ "សេវាមីក្រូ" បាន។ ប៉ុន្តែយើងនឹងនិយាយអំពីរឿងនេះនៅពេលក្រោយ ...

មនោរម្យ

រចនាប័ទ្មស្ថាបត្យកម្មដែលផ្ទុយពីសេវាកម្មមីក្រូគឺ monolith (ឬទាំងអស់ក្នុងមួយ) ។ វាប្រហែលជាមិនសមហេតុផលទេក្នុងការប្រាប់ពីអ្វីដែលជា monolith ដូច្នេះខ្ញុំនឹងរាយបញ្ជីភ្លាមៗនូវគុណវិបត្តិនៃរចនាប័ទ្មស្ថាបត្យកម្មនេះ ដែលបានចាប់ផ្តើមការអភិវឌ្ឍបន្ថែមទៀតនៃរចនាប័ទ្មស្ថាបត្យកម្ម៖ ទំហំ ការតភ្ជាប់ ការដាក់ពង្រាយ មាត្រដ្ឋាន ភាពជឿជាក់ និងភាពរឹង។ ខាងក្រោម​នេះ​ខ្ញុំ​ស្នើ​ឲ្យ​ពិនិត្យ​មើល​ចំណុច​ខ្វះខាត​នីមួយៗ​ដោយ​ឡែក​ពី​គ្នា។

ទំហំ

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

ទំនាក់ទំនង

Monolith គឺជា "បាល់ដ៏ធំនៃភក់" ការផ្លាស់ប្តូរដែលអាចនាំឱ្យមានផលវិបាកដែលមិនអាចទាយទុកជាមុនបាន។ តាមរយៈការធ្វើការផ្លាស់ប្តូរនៅកន្លែងមួយ អ្នកអាចធ្វើឱ្យខូច monolith នៅក្នុងកន្លែងផ្សេងទៀត (ដូចគ្នា "អ្នកបានកោសត្រចៀករបស់អ្នក *@ ធ្លាក់ចេញ") ។ នេះគឺដោយសារតែការពិតដែលថាសមាសធាតុនៅក្នុង monolith មានទំនាក់ទំនងស្មុគ្រស្មាញខ្លាំងហើយសំខាន់បំផុតគឺទំនាក់ទំនងមិនច្បាស់។

ការដាក់ពង្រាយ

ការដាក់ពង្រាយ monolith ដោយសារតែទំនាក់ទំនងស្មុគ្រស្មាញរវាងសមាសធាតុរបស់វាគឺជាដំណើរការដ៏យូរជាមួយនឹងពិធីផ្ទាល់ខ្លួនរបស់វា។ ពិធីបែបនេះជាធម្មតាមិនមានលក្ខណៈស្តង់ដារទាំងស្រុងទេ ហើយត្រូវបានឆ្លងកាត់ "ដោយផ្ទាល់មាត់"។

លទ្ធភាពធ្វើមាត្រដ្ឋាន

ម៉ូឌុល Monolith អាច​មាន​តម្រូវការ​ធនធាន​មិន​ស្របគ្នា ដែល​ទាមទារ​ឱ្យ​មាន​ការ​សម្រុះសម្រួល​ក្នុង​លក្ខខណ្ឌ​នៃ​ផ្នែក​រឹង។ ស្រមៃថាអ្នកមានម៉ូណូលីតដែលមានសេវាកម្ម A និង B ។ សេវាកម្ម A កំពុងទាមទារលើទំហំថាសរឹង ហើយសេវាកម្ម B ទាមទារលើ RAM ។ ក្នុងករណីនេះ ទាំងម៉ាស៊ីនដែលដំឡើង monolith ត្រូវតែគាំទ្រតម្រូវការនៃសេវាកម្មទាំងពីរ ឬអ្នកនឹងត្រូវបិទសេវាកម្មណាមួយដោយសិប្បនិម្មិត។

ឧទាហរណ៍មួយទៀត (បុរាណជាង)៖ សេវាកម្ម A គឺពេញនិយមជាងសេវាកម្ម B ដូច្នេះអ្នកចង់ឱ្យសេវាកម្ម A 100 និង 10 សេវាកម្ម B។ ជាថ្មីម្តងទៀត ជម្រើសពីរ៖ ទាំងយើងដាក់ពង្រាយ 100 ពេញលក្ខណៈ ឬនៅលើមួយចំនួនទៀត។ សេវាកម្ម B នឹងត្រូវបិទដោយដៃ។

ភាពជឿជាក់

ដោយសារសេវាកម្មទាំងអស់មានទីតាំងនៅជាមួយគ្នា ប្រសិនបើ monolith ធ្លាក់ចុះ នោះសេវាកម្មទាំងអស់នឹងធ្លាក់ចុះក្នុងពេលតែមួយ។ តាមពិត នេះប្រហែលជាមិនអាក្រក់ទេ យ៉ាងហោចណាស់វានឹងមិនមានការបរាជ័យផ្នែកណាមួយនៅក្នុងប្រព័ន្ធចែកចាយនោះទេ ប៉ុន្តែម្យ៉ាងវិញទៀត ដោយសារបញ្ហានៅក្នុងមុខងារដែលប្រើប្រាស់ដោយអ្នកប្រើប្រាស់ 0.001% អ្នកអាចបាត់បង់អ្នកប្រើប្រាស់ទាំងអស់។ នៃប្រព័ន្ធរបស់អ្នក។

និចលភាព

ដោយសារតែទំហំនៃ monolith វាពិបាកក្នុងការប្តូរទៅបច្ចេកវិទ្យាថ្មី។ ជាលទ្ធផល ការរក្សាមនុស្សចាស់ដដែលនោះ គឺជាកិច្ចការដាច់ដោយឡែក។ ជង់បច្ចេកវិទ្យាដែលត្រូវបានជ្រើសរើសនៅពេលចាប់ផ្តើមគម្រោងអាចក្លាយជាប្លុកដែលរារាំងដល់ការអភិវឌ្ឍន៍ផលិតផល។

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

លើកក្រោយ យើងនឹងនិយាយអំពីរបៀបដែលមនុស្សបានព្យាយាមដោះស្រាយបញ្ហាទាំងនេះដោយការផ្លាស់ប្តូរទៅសមាសភាគ និង SOA ។

អាន​បន្ថែម:

• ហេតុអ្វីបានជា SQL Server មិនធានាក្នុងការតម្រៀបលទ្ធផលដោយគ្មានការបញ្ជាទិញដោយ
• ស្ថាបត្យកម្មសម្រាប់អ្នកអភិវឌ្ឍន៍ និងអ្នកគ្រប់គ្រង៖ អ្នកណាត្រូវការជំនាញអ្វី?

ប្រភព: www.habr.com