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

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

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

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

В ពេលមុន យើងបានដោះស្រាយជាមួយ monolith ហើយឈានដល់ការសន្និដ្ឋានថា monolith មានបញ្ហាមួយចំនួន: ទំហំ, ការតភ្ជាប់, ការដាក់ពង្រាយ, ការធ្វើមាត្រដ្ឋាន, ភាពជឿជាក់និងភាពរឹង។

លើកនេះខ្ញុំស្នើឱ្យនិយាយអំពីលទ្ធភាពនៃការរៀបចំប្រព័ន្ធជាសំណុំនៃម៉ូឌុល/បណ្ណាល័យ (ស្ថាបត្យកម្មតម្រង់ទិសសមាសភាគ) ឬសេវាកម្ម (ស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្ម) ។

រចនាសម្ព័ន្ធតម្រង់ទិស

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

ជាមួយនឹងការប្រើប្រាស់សមាសធាតុឱ្យបានត្រឹមត្រូវបញ្ហានៃ "បាល់ធំនៃកខ្វក់" (ទំហំធំ + ការភ្ជាប់ខ្ពស់) ត្រូវបានដោះស្រាយហើយសមាសធាតុខ្លួនឯងអាចជាអង្គភាពដំឡើង (ម៉ូឌុលបណ្ណាល័យ) និងអង្គភាពដាក់ពង្រាយ (សេវាកម្ម) ។ ឯកតាដាក់ពង្រាយមិនតែងតែត្រូវបានគូសផែនទីទៅនឹងដំណើរការដែលកំពុងដំណើរការនោះទេ៖ ឧទាហរណ៍ កម្មវិធីគេហទំព័រ និងមូលដ្ឋានទិន្នន័យត្រូវបានដាក់ពង្រាយជាមួយគ្នា។

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

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

monolith "ឧត្តមគតិ" គឺជាសំណុំនៃម៉ូឌុលបំបែកដោយឡូជីខល ដែលនីមួយៗមើលទៅក្នុងមូលដ្ឋានទិន្នន័យផ្ទាល់ខ្លួនរបស់វា។

ស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្ម

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

ស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្ម (SOA = ស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្ម) ដោះស្រាយបញ្ហាដែលបានកំណត់អត្តសញ្ញាណទាំងអស់នៃ monolith: សេវាកម្មតែមួយគត់ត្រូវបានប៉ះពាល់នៅពេលដែលមានការផ្លាស់ប្តូរកើតឡើង ហើយ API ដែលបានកំណត់យ៉ាងល្អគាំទ្រការវេចខ្ចប់ដ៏ល្អនៃសមាសធាតុ។

ប៉ុន្តែមិនមែនអ្វីៗទាំងអស់រលូនទេ៖ SOA បង្កើតបញ្ហាថ្មី។ ការហៅទូរសព្ទពីចម្ងាយមានតម្លៃថ្លៃជាងការហៅទូរសព្ទក្នុងស្រុក ហើយការចែកចាយឡើងវិញនូវទំនួលខុសត្រូវរវាងសមាសធាតុបានក្លាយទៅជាថ្លៃជាងយ៉ាងខ្លាំង។

ដោយវិធីនេះ លទ្ធភាពនៃការដាក់ពង្រាយឯករាជ្យគឺជាលក្ខណៈសំខាន់នៃសេវាកម្ម។ ប្រសិនបើសេវាកម្មត្រូវតែដាក់ពង្រាយរួមគ្នា ឬលើសពីនេះទៅទៀត ក្នុងលំដាប់ជាក់លាក់មួយ នោះប្រព័ន្ធមិនអាចចាត់ទុកថាជាសេវាតម្រង់ទិសបានទេ។ ក្នុងករណីនេះពួកគេនិយាយអំពី monolith ចែកចាយ (ចាត់ទុកថាជាគំរូប្រឆាំងមិនត្រឹមតែពីទស្សនៈនៃ SOA ប៉ុណ្ណោះទេប៉ុន្តែក៏មកពីទស្សនៈនៃស្ថាបត្យកម្មមីក្រូសេវាកម្មផងដែរ) ។

ស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្មត្រូវបានគាំទ្រយ៉ាងល្អដោយសហគមន៍ស្ថាបត្យកម្ម និងអ្នកលក់។ នេះបង្កប់ន័យវត្តមាននៃវគ្គសិក្សា និងវិញ្ញាបនប័ត្រជាច្រើន លំនាំដែលបានអភិវឌ្ឍយ៉ាងល្អ។ ជាឧទាហរណ៍ ឡានក្រុងសេវាកម្មសហគ្រាសល្បីឈ្មោះ (ESB = ឡានក្រុងសេវាសហគ្រាស)។ ក្នុងពេលជាមួយគ្នានេះ ESB គឺជាឥវ៉ាន់ពីអ្នកលក់ វាមិនចាំបាច់ប្រើនៅក្នុង SOA ទេ។

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

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

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

ប្រភព: www.habr.com