របៀបដោះស្រាយភាពស្មុគស្មាញនៅពេលរចនាប្រព័ន្ធកម្មវិធី

តើវានិយាយអំពីអ្វី? ជារៀងរាល់ថ្ងៃ រាល់ពេលក្នុងអាជីពវិស្វកររបស់យើង យើងជួបប្រទះនឹងបញ្ហាផ្សេងៗគ្នាជាច្រើននៃភាពស្មុគស្មាញ និងស្ថានភាពផ្សេងៗ ដែលយើងត្រូវធ្វើការសម្រេចចិត្ត ឬពន្យារពេលដោយសារតែខ្វះទិន្នន័យ។ នៅពេលណាដែលយើងបង្កើតសេវាកម្មថ្មី សាងសង់ហេដ្ឋារចនាសម្ព័ន្ធ ឬសូម្បីតែបង្កើតដំណើរការអភិវឌ្ឍន៍ យើងប៉ះពិភពលោកដ៏ធំនៃបញ្ហាប្រឈមផ្សេងៗ។ វាជាបញ្ហាប្រឈម ហើយប្រហែលជាមិនអាចទៅរួចនោះទេ ក្នុងការរាយបញ្ជីបញ្ហាទាំងអស់។ អ្នកនឹងជួបប្រទះបញ្ហាមួយចំនួននេះលុះត្រាតែអ្នកធ្វើការក្នុងផ្នែកជាក់លាក់មួយ។ ម៉្យាងវិញទៀត មានរឿងជាច្រើនដែលយើងទាំងអស់គ្នាត្រូវតែយល់ពីរបៀបដោះស្រាយ ព្រោះវាមានសារៈសំខាន់ណាស់សម្រាប់ការបង្កើតប្រព័ន្ធព័ត៌មានវិទ្យា។ ជាមួយនឹងប្រូបាប៊ីលីតេខ្ពស់ អ្នកនឹងជួបពួកគេនៅក្នុងគម្រោងទាំងអស់។ នៅក្នុងអត្ថបទនេះ ខ្ញុំនឹងចែករំលែកបទពិសោធន៍របស់ខ្ញុំជាមួយនឹងបញ្ហាមួយចំនួនដែលខ្ញុំបានជួបប្រទះក្នុងពេលបង្កើតកម្មវិធីកម្មវិធី។ តើអ្វីទៅជាការព្រួយបារម្ភនៃការកាត់? បើយើងមើលទៅក្នុង Wikipedia យើងនឹងឃើញនិយមន័យដូចខាងក្រោម នៅក្នុងការអភិវឌ្ឍន៍ផ្នែកទន់ដែលផ្តោតលើទិដ្ឋភាព កង្វល់នៃការកាត់ជាទិដ្ឋភាពនៃកម្មវិធីដែលប៉ះពាល់ដល់ម៉ូឌុលជាច្រើន ដោយមិនមានលទ្ធភាពនៃការដាក់បញ្ចូលក្នុងពួកវាណាមួយឡើយ។ កង្វល់ទាំងនេះច្រើនតែមិនអាចរំលាយបានយ៉ាងស្អាតពីប្រព័ន្ធដែលនៅសល់ទាំងក្នុងការរចនា និងការអនុវត្ត ហើយអាចបណ្តាលឱ្យមានការខ្ចាត់ខ្ចាយ (ការចម្លងកូដ) ការច្របូកច្របល់ (ភាពអាស្រ័យយ៉ាងសំខាន់រវាងប្រព័ន្ធ) ឬទាំងពីរ។ វាពិពណ៌នាយ៉ាងខ្លាំងថាវាជាអ្វី ប៉ុន្តែខ្ញុំចង់ពង្រីក និងសម្រួលវាបន្តិចបន្តួច៖ គឺជាគំនិត ឬធាតុផ្សំនៃប្រព័ន្ធ/អង្គការដែលប៉ះពាល់ដល់ (ឬ 'កាត់ផ្តាច់') ផ្នែកជាច្រើនទៀត។ ការព្រួយបារម្ភអំពីការកាត់ផ្តាច់ ឧទាហរណ៍ដ៏ល្អបំផុតនៃការព្រួយបារម្ភបែបនេះគឺ ស្ថាបត្យកម្មប្រព័ន្ធ ការកត់ត្រា សុវត្ថិភាព ការគ្រប់គ្រងប្រតិបត្តិការ ទូរគមនាគមន៍ ការរចនាមូលដ្ឋានទិន្នន័យ និងនៅមានជាច្រើនទៀត។ យើងនឹងរៀបរាប់លម្អិតអំពីពួកវាជាច្រើននៅពេលក្រោយនៅក្នុងអត្ថបទនេះ។ នៅលើកម្រិតកូដ ការព្រួយបារម្ភអំពីការកាត់តគ្នាជាញឹកញាប់ត្រូវបានអនុវត្តដោយប្រើបច្ចេកទេសដូចជា ដែលការព្រួយបារម្ភទាំងនេះត្រូវបានកែប្រែទៅជាសមាសធាតុដាច់ដោយឡែកដែលអាចត្រូវបានអនុវត្តពេញកម្មវិធី។ នេះរក្សាតក្កវិជ្ជាអាជីវកម្មដាច់ដោយឡែកពីកង្វល់ទាំងនេះ ដែលធ្វើឲ្យកូដអាចអានបាន និងរក្សាបានកាន់តែច្រើន។ Aspect-Oriented Programming (AOP) ចំណាត់ថ្នាក់នៃទិដ្ឋភាព មានវិធីជាច្រើនដែលអាចធ្វើទៅបានអំពីរបៀបចាត់ថ្នាក់ទិដ្ឋភាពដោយបែងចែកពួកវាជាមួយនឹងលក្ខណៈសម្បត្តិផ្សេងៗគ្នាដូចជា វិសាលភាព ទំហំ មុខងារ សារៈសំខាន់ គោលដៅ និងផ្សេងៗទៀត ប៉ុន្តែនៅក្នុងអត្ថបទនេះ ខ្ញុំនឹងប្រើការចាត់ថ្នាក់វិសាលភាពសាមញ្ញមួយ។ តាមរយៈនេះ ខ្ញុំមានន័យថាកន្លែងដែលទិដ្ឋភាពជាក់លាក់នេះត្រូវបានដឹកនាំ ថាតើវាជាអង្គការទាំងមូល ប្រព័ន្ធជាក់លាក់ ឬធាតុជាក់លាក់នៃប្រព័ន្ធនោះ។ ដូច្នេះ ខ្ញុំនឹងបែងចែកទិដ្ឋភាពទៅជា និង ។ Macro Micro តាមទិដ្ឋភាព ខ្ញុំចង់សំដៅលើការពិចារណាជាចម្បងដែលយើងធ្វើតាមសម្រាប់ប្រព័ន្ធទាំងមូល ដូចជាស្ថាបត្យកម្មប្រព័ន្ធដែលបានជ្រើសរើស និងការរចនារបស់វា (monolithic, microservices, ស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្ម) ជង់បច្ចេកវិទ្យា រចនាសម្ព័ន្ធស្ថាប័នជាដើម។ ទិដ្ឋភាព គឺទាក់ទងជាចម្បងទៅនឹងយុទ្ធសាស្ត្រ និងកម្រិតខ្ពស់។ ការសម្រេចចិត្ត។ ម៉ាក្រូ ម៉ាក្រូ ក្នុងពេលនេះ ទិដ្ឋភាព គឺកាន់តែខិតទៅជិតកម្រិតកូដ និងការអភិវឌ្ឍន៍។ ឧទាហរណ៍ ក្របខ័ណ្ឌមួយណាដែលត្រូវបានប្រើសម្រាប់អន្តរកម្មជាមួយមូលដ្ឋានទិន្នន័យ រចនាសម្ព័ន្ធគម្រោងនៃថត និងថ្នាក់ ឬសូម្បីតែគំរូរចនាវត្ថុជាក់លាក់។ មីក្រូ ទោះបីជាការចាត់ថ្នាក់នេះមិនសមស្របក៏ដោយ វាជួយរៀបចំរចនាសម្ព័ន្ធការយល់ដឹងអំពីបញ្ហាដែលអាចកើតមាន និងសារៈសំខាន់ និងផលប៉ះពាល់នៃដំណោះស្រាយដែលយើងអនុវត្តចំពោះពួកគេ។ នៅក្នុងអត្ថបទនេះ ការផ្តោតសំខាន់របស់ខ្ញុំនឹងផ្តោតលើទិដ្ឋភាពម៉ាក្រូ។ ទិដ្ឋភាពម៉ាក្រូ រចនាសម្ព័ន្ធអង្គការ នៅពេលដែលខ្ញុំទើបតែចាប់ផ្តើមរៀនអំពីស្ថាបត្យកម្មកម្មវិធី ខ្ញុំបានអានអត្ថបទគួរឱ្យចាប់អារម្មណ៍ជាច្រើនអំពីច្បាប់របស់ Conway និងឥទ្ធិពលរបស់វាទៅលើរចនាសម្ព័ន្ធស្ថាប័ន។ ជាពិសេស ។ ដូច្នេះ ច្បាប់នេះចែងដូច្នេះ មួយនេះ អង្គការណាក៏ដោយដែលរចនាប្រព័ន្ធ (កំណត់យ៉ាងទូលំទូលាយ) នឹងបង្កើតការរចនាដែលរចនាសម្ព័ន្ធរបស់វាជាច្បាប់ចម្លងនៃរចនាសម្ព័ន្ធទំនាក់ទំនងរបស់អង្គការ។ ខ្ញុំតែងតែជឿថា គំនិតនេះគឺពិតជាសកល និងតំណាងឱ្យច្បាប់មាស។ បន្ទាប់មកខ្ញុំចាប់ផ្តើមរៀនវិធីសាស្រ្ត Domain-Driven Design (DDD) របស់ Eric Evans សម្រាប់ប្រព័ន្ធគំរូ។ Eric Evans សង្កត់ធ្ងន់លើសារៈសំខាន់នៃការកំណត់បរិបទដែលមានព្រំដែន។ គោលគំនិតនេះពាក់ព័ន្ធនឹងការបែងចែកគំរូដែនស្មុគស្មាញទៅជាផ្នែកតូចៗដែលអាចគ្រប់គ្រងបានកាន់តែច្រើន ដែលនីមួយៗមានសំណុំចំណេះដឹងមានកម្រិតផ្ទាល់ខ្លួន។ វិធីសាស្រ្តនេះជួយក្នុងការទំនាក់ទំនងជាក្រុមប្រកបដោយប្រសិទ្ធភាព ដោយសារវាកាត់បន្ថយតម្រូវការសម្រាប់ចំណេះដឹងទូលំទូលាយនៃដែនទាំងមូល និងកាត់បន្ថយការប្តូរបរិបទ ដូច្នេះហើយធ្វើឱ្យការសន្ទនាកាន់តែមានប្រសិទ្ធភាព។ ការប្តូរបរិបទគឺជារឿងដ៏អាក្រក់បំផុត និងប្រើប្រាស់ធនធានច្រើនបំផុតមិនធ្លាប់មាន។ សូម្បីតែកុំព្យូទ័រក៏កំពុងតស៊ូជាមួយវាដែរ។ ទោះបីជាវាមិនទំនងដើម្បីសម្រេចបាននូវអវត្តមានពេញលេញនៃការប្តូរបរិបទក៏ដោយ ខ្ញុំគិតថានោះជាអ្វីដែលយើងគួរតែខិតខំ។ ត្រលប់ទៅច្បាប់របស់ Conway ខ្ញុំបានរកឃើញបញ្ហាជាច្រើនជាមួយវា។ ដែលខ្ញុំបានជួបប្រទះជាមួយនឹងច្បាប់របស់ Conway ដែលបង្ហាញថាការរចនាប្រព័ន្ធឆ្លុះបញ្ចាំងពីរចនាសម្ព័ន្ធស្ថាប័ន គឺជាសក្តានុពលសម្រាប់បង្កើតបរិបទដែលស្មុគស្មាញ និងទូលំទូលាយ។ ភាពស្មុគស្មាញនេះកើតឡើងនៅពេលដែលរចនាសម្ព័ន្ធអង្គការមិនត្រូវបានតម្រឹមជាមួយព្រំដែនដែន ដែលនាំទៅដល់បរិបទដែលមានព្រំដែនដែលពឹងផ្អែកខ្លាំង និងផ្ទុកដោយព័ត៌មាន។ វានាំទៅរកការផ្លាស់ប្តូរបរិបទញឹកញាប់សម្រាប់ក្រុមអភិវឌ្ឍន៍។ បញ្ហាដំបូង គឺថាវាក្យស័ព្ទរបស់អង្គការបានលេចធ្លាយដល់កម្រិតកូដ។ នៅពេលដែលរចនាសម្ព័ន្ធអង្គការផ្លាស់ប្តូរ វាត្រូវការការកែប្រែមូលដ្ឋានកូដ ដោយប្រើប្រាស់ធនធានដ៏មានតម្លៃ។ បញ្ហាមួយទៀត ដូច្នេះ ការធ្វើតាម ជួយបង្កើតប្រព័ន្ធ និងអង្គការដែលលើកទឹកចិត្តដល់ស្ថាបត្យកម្មកម្មវិធីដែលចង់បាន។ ទោះជាយ៉ាងណាក៏ដោយ វាគួរអោយកត់សំគាល់ក្នុងការនិយាយថាវិធីសាស្រ្តនេះនឹងមិនដំណើរការល្អនៅក្នុងស្ថាបត្យកម្ម និងរចនាសម្ព័ន្ធដែលបានបង្កើតរួចហើយនោះទេ ចាប់តាំងពីការផ្លាស់ប្តូរនៅដំណាក់កាលនេះត្រូវបានអូសបន្លាយ ប៉ុន្តែវាមានប្រសិទ្ធភាពពិសេសក្នុងការចាប់ផ្តើមអាជីវកម្ម ដោយសារពួកគេឆាប់ណែនាំការផ្លាស់ប្តូរណាមួយ។ Inverse Conway Maneuver បាល់ដ៏ធំនៃភក់ លំនាំនេះ ឬ "ការប្រឆាំងលំនាំ" ជំរុញការកសាងប្រព័ន្ធដោយគ្មានស្ថាបត្យកម្ម។ មិនមានច្បាប់ គ្មានព្រំដែន និងគ្មានយុទ្ធសាស្ត្រ អំពីរបៀបគ្រប់គ្រងភាពស្មុគស្មាញដែលជៀសមិនរួច។ ភាពស្មុគស្មាញគឺជាសត្រូវដ៏សាហាវបំផុតក្នុងដំណើរនៃការកសាងប្រព័ន្ធសូហ្វវែរ។ ដើម្បីជៀសវាងការបង្កើតប្រព័ន្ធបែបនេះ យើងត្រូវអនុវត្តតាមច្បាប់ និងឧបសគ្គជាក់លាក់។ ស្ថាបត្យកម្មប្រព័ន្ធ មាននិយមន័យជាច្រើនសម្រាប់ស្ថាបត្យកម្មកម្មវិធី។ ខ្ញុំចូលចិត្តពួកគេជាច្រើន ដោយសារពួកគេគ្របដណ្តប់លើទិដ្ឋភាពផ្សេងៗរបស់វា។ ទោះយ៉ាងណាក៏ដោយ ដើម្បីអាចវែកញែកអំពីស្ថាបត្យកម្ម យើងត្រូវការជាធម្មជាតិដើម្បីបង្កើតពួកវាខ្លះនៅក្នុងគំនិតរបស់យើង។ ហើយវាគួរអោយកត់សំគាល់ក្នុងការនិយាយថានិយមន័យនេះអាចវិវត្ត។ ដូច្នេះ យ៉ាងហោចណាស់សម្រាប់ពេលនេះ ខ្ញុំមានការពិពណ៌នាដូចខាងក្រោមសម្រាប់ខ្លួនខ្ញុំ។ គឺនិយាយអំពីការសម្រេចចិត្ត និងជម្រើសដែលអ្នកធ្វើជារៀងរាល់ថ្ងៃ ដែលប៉ះពាល់ដល់ប្រព័ន្ធដែលបានសាងសង់។ ស្ថាបត្យកម្មសូហ្វវែរ ដើម្បីធ្វើការសម្រេចចិត្តអ្នកត្រូវមាននៅក្នុងគោលការណ៍ និងគំរូ "កាបូប" របស់អ្នកសម្រាប់ការដោះស្រាយបញ្ហាដែលកើតឡើង វាក៏ចាំបាច់ផងដែរក្នុងការបញ្ជាក់ថាការយល់ដឹងអំពីតម្រូវការគឺជាគន្លឹះក្នុងការកសាងនូវអ្វីដែលអាជីវកម្មត្រូវការ។ ទោះជាយ៉ាងណាក៏ដោយ ពេលខ្លះតម្រូវការមិនមានតម្លាភាព ឬសូម្បីតែមិនបានកំណត់ក៏ដោយ ក្នុងករណីនេះ វាជាការប្រសើរក្នុងការរង់ចាំដើម្បីទទួលបានការបញ្ជាក់បន្ថែម ឬពឹងផ្អែកលើបទពិសោធន៍របស់អ្នក និងជឿជាក់លើវិចារណញាណរបស់អ្នក។ ប៉ុន្តែយ៉ាងណាក៏ដោយ អ្នកមិនអាចធ្វើការសម្រេចចិត្តបានត្រឹមត្រូវទេ ប្រសិនបើអ្នកមិនមានគោលការណ៍ និងគំរូដែលត្រូវពឹងផ្អែកលើ។ នោះហើយជាកន្លែងដែលខ្ញុំមកដល់និយមន័យនៃ រចនាប័ទ្មស្ថាបត្យកម្មកម្មវិធី។ គឺជាសំណុំនៃគោលការណ៍និងលំនាំដែលកំណត់ពីរបៀបបង្កើតកម្មវិធី។ រចនាប័ទ្មស្ថាបត្យកម្មសូហ្វវែរ មានរចនាប័ទ្មស្ថាបត្យកម្មផ្សេងៗគ្នាជាច្រើនដែលផ្តោតលើផ្នែកផ្សេងៗនៃស្ថាបត្យកម្មដែលបានគ្រោងទុក ហើយការអនុវត្តច្រើនក្នុងពេលតែមួយគឺជាស្ថានភាពធម្មតា។ ឧទាហរណ៍ដូចជា៖ ស្ថាបត្យកម្ម Monolithic ការរចនាដែលជំរុញដោយដែន ផ្អែកលើសមាសធាតុ សេវាមីក្រូ បំពង់និងតម្រង ជំរុញដោយព្រឹត្តិការណ៍ មីក្រូខឺណែល។ តម្រង់ទិសសេវាកម្ម ហើយដូច្នេះនៅលើ… ជាការពិតណាស់ ពួកគេមានគុណសម្បត្តិ និងគុណវិបត្តិរបស់ពួកគេ ប៉ុន្តែអ្វីដែលសំខាន់បំផុតដែលខ្ញុំបានរៀននោះគឺថា ស្ថាបត្យកម្មមានការវិវត្តន៍បន្តិចម្តងៗ ខណៈពេលដែលអាស្រ័យលើបញ្ហាជាក់ស្តែង។ ការចាប់ផ្តើមជាមួយស្ថាបត្យកម្ម monolithic គឺជាជម្រើសដ៏ល្អសម្រាប់កាត់បន្ថយភាពស្មុគស្មាញក្នុងប្រតិបត្តិការ ទំនងជាស្ថាបត្យកម្មនេះនឹងសមនឹងតម្រូវការរបស់អ្នក សូម្បីតែបន្ទាប់ពីឈានដល់ដំណាក់កាល Product-market Fit (PMI) នៃការសាងសង់ផលិតផលក៏ដោយ។ តាមមាត្រដ្ឋាន អ្នកអាចពិចារណាឆ្ពោះទៅរកវិធីសាស្រ្តដែលជំរុញដោយព្រឹត្តិការណ៍ និងសេវាកម្មខ្នាតតូចសម្រាប់ការសម្រេចបាននូវការដាក់ឱ្យប្រើប្រាស់ដោយឯករាជ្យ បរិយាកាសជង់បច្ចេកវិទ្យាមិនដូចគ្នា និងស្ថាបត្យកម្មដែលរួមបញ្ចូលគ្នាតិចជាង (និងមិនសូវមានតម្លាភាពក្នុងពេលដំណាលគ្នានេះ ដោយសារធម្មជាតិនៃវិធីសាស្រ្តដែលជំរុញដោយព្រឹត្តិការណ៍ និង pub-sub ប្រសិនបើ ទាំងនេះត្រូវបានអនុម័ត) ។ ភាពសាមញ្ញ និងប្រសិទ្ធភាពមានភាពជិតស្និទ្ធ និងមានឥទ្ធិពលខ្លាំងលើគ្នាទៅវិញទៅមក។ ជាធម្មតា ស្ថាបត្យកម្មដ៏ស្មុគស្មាញប៉ះពាល់ដល់ល្បឿននៃការអភិវឌ្ឍន៍នៃមុខងារថ្មីៗ ការគាំទ្រ និងថែរក្សាវត្ថុដែលមានស្រាប់ និងការប្រកួតប្រជែងការវិវត្តន៍ធម្មជាតិរបស់ប្រព័ន្ធ។ ទោះជាយ៉ាងណាក៏ដោយ ប្រព័ន្ធស្មុគ្រស្មាញច្រើនតែត្រូវការស្ថាបត្យកម្មស្មុគស្មាញ និងទូលំទូលាយ ដែលជៀសមិនរួច។ ត្រឹមត្រូវហើយ នេះគឺជាប្រធានបទដ៏ធំទូលាយមួយ ហើយមានគំនិតល្អៗជាច្រើនអំពីរបៀបរៀបចំរចនាសម្ព័ន្ធ និងបង្កើតប្រព័ន្ធសម្រាប់ការវិវត្តន៍ធម្មជាតិ។ ដោយផ្អែកលើបទពិសោធន៍របស់ខ្ញុំ ខ្ញុំបានអនុវត្តវិធីសាស្រ្តដូចខាងក្រោមៈ ស្ទើរតែតែងតែចាប់ផ្តើមជាមួយនឹងរចនាប័ទ្មស្ថាបត្យកម្ម monolithic ចាប់តាំងពីវាលុបបំបាត់បញ្ហាភាគច្រើនដែលកើតឡើងដោយសារតែធម្មជាតិនៃប្រព័ន្ធចែកចាយ។ វាក៏សមហេតុផលផងដែរក្នុងការធ្វើតាមម៉ូណូលីតដើម្បីផ្តោតលើធាតុផ្សំនៃការសាងសង់ដែលមានព្រំដែនច្បាស់លាស់។ ការអនុវត្តវិធីសាស្រ្តផ្អែកលើសមាសធាតុអាចជួយឱ្យពួកគេប្រាស្រ័យទាក់ទងគ្នាដោយប្រើព្រឹត្តិការណ៍ ប៉ុន្តែការហៅដោយផ្ទាល់ (ហៅកាត់ថា RPC) ធ្វើឱ្យអ្វីៗមានភាពសាមញ្ញនៅពេលចាប់ផ្តើម។ ទោះជាយ៉ាងណាក៏ដោយ វាមានសារៈសំខាន់ណាស់ក្នុងការតាមដានភាពអាស្រ័យរវាងសមាសធាតុ ព្រោះប្រសិនបើសមាសធាតុ A ដឹងច្រើនអំពីសមាសធាតុ B ប្រហែលជាវាសមហេតុផលក្នុងការបញ្ចូលពួកវាទៅក្នុងមួយ។ នៅពេលអ្នកខិតទៅជិតស្ថានភាពនៅពេលដែលអ្នកត្រូវការធ្វើមាត្រដ្ឋានការអភិវឌ្ឍន៍ និងប្រព័ន្ធរបស់អ្នក អ្នកអាចពិចារណាធ្វើតាមគំរូ ដើម្បីទាញយកសមាសធាតុបន្តិចម្តងៗដែលចាំបាច់ត្រូវដាក់ពង្រាយដោយឯករាជ្យ ឬសូម្បីតែធ្វើមាត្រដ្ឋានជាមួយនឹងតម្រូវការជាក់លាក់។ Stangler ឥឡូវនេះ ប្រសិនបើអ្នកមានចក្ខុវិស័យច្បាស់លាស់អំពីអនាគត ដែលជាសំណាងមិនគួរឱ្យជឿ អ្នកអាចសម្រេចចិត្តលើស្ថាបត្យកម្មដែលចង់បាន។ នៅពេលនេះ អ្នកអាចសម្រេចចិត្តលើការផ្លាស់ប្តូរឆ្ពោះទៅរកស្ថាបត្យកម្មខ្នាតតូចដោយអនុវត្តវិធីសាស្រ្ត Orchestration និង Choreography ដោយបញ្ចូលគំរូ CQRS សម្រាប់ប្រតិបត្តិការសរសេរ និងអានខ្នាតឯករាជ្យ ឬសូម្បីតែសម្រេចចិត្តបិទជាមួយស្ថាបត្យកម្ម monolithic ប្រសិនបើវាសមនឹងតម្រូវការរបស់អ្នក។ វាក៏សំខាន់ផងដែរក្នុងការយល់ដឹងអំពីលេខ និងរង្វាស់ដូចជា (អ្នកប្រើប្រាស់សកម្មប្រចាំថ្ងៃ), (អ្នកប្រើប្រាស់សកម្មប្រចាំខែ), (សំណើក្នុងមួយវិនាទី) និង (ប្រតិបត្តិការក្នុងមួយវិនាទី) ព្រោះវាអាចជួយអ្នកក្នុងការធ្វើជម្រើស ដោយសារស្ថាបត្យកម្មសម្រាប់ អ្នកប្រើប្រាស់សកម្ម 100 និងអ្នកប្រើប្រាស់សកម្ម 100 លាននាក់គឺខុសគ្នា។ DAU MAU RPC TPC ជាកំណត់សម្គាល់ចុងក្រោយ ខ្ញុំចង់និយាយថាស្ថាបត្យកម្មមានផលប៉ះពាល់យ៉ាងសំខាន់ទៅលើភាពជោគជ័យរបស់ផលិតផល។ ស្ថាបត្យកម្មដែលបានរចនាមិនល្អសម្រាប់ផលិតផលគឺត្រូវបានទាមទារក្នុងការធ្វើមាត្រដ្ឋាន ដែលទំនងជានាំទៅរកការបរាជ័យ ដោយសារអតិថិជននឹងមិនរង់ចាំខណៈពេលដែលអ្នកធ្វើមាត្រដ្ឋានប្រព័ន្ធ ពួកគេនឹងជ្រើសរើសដៃគូប្រកួតប្រជែង ដូច្នេះយើងត្រូវតែនាំមុខគេក្នុងការធ្វើមាត្រដ្ឋានសក្តានុពល។ ម៉្យាងវិញទៀត ការដែលមានប្រព័ន្ធស្មុគ្រស្មាញ និងធ្វើមាត្រដ្ឋានរួចហើយ ដោយគ្មានអតិថិជន ឬគម្រោងដើម្បីទទួលបានពួកវាច្រើន នឹងធ្វើឱ្យអ្នកចំណាយប្រាក់លើអាជីវកម្មរបស់អ្នកដោយឥតប្រយោជន៍។ ទោះបីជាខ្ញុំទទួលស្គាល់ថា ពេលខ្លះវាមិនអាចជាវិធីសាស្រ្តគ្មានខ្លាញ់ក៏ដោយ គំនិតនេះគឺដើម្បីឱ្យមានប្រព័ន្ធដែលអាចធ្វើមាត្រដ្ឋានបាន ប៉ុន្តែមិនទាន់មានមាត្រដ្ឋានទេ។ ការជ្រើសរើសជង់បច្ចេកវិទ្យា ការជ្រើសរើសជង់បច្ចេកវិទ្យាក៏ជាការសម្រេចចិត្តកម្រិតម៉ាក្រូផងដែរ ព្រោះវាមានឥទ្ធិពលលើការជួល ទស្សនវិស័យការវិវត្តន៍តាមធម្មជាតិរបស់ប្រព័ន្ធ ភាពអាចធ្វើមាត្រដ្ឋាន និងដំណើរការប្រព័ន្ធ។ នេះគឺជាបញ្ជីនៃការពិចារណាជាមូលដ្ឋានសម្រាប់ការជ្រើសរើសជង់បច្ចេកវិទ្យា៖ ជាឧទាហរណ៍ កម្មវិធីបណ្ដាញសាមញ្ញមួយអាចត្រូវបានបង្កើតជាមួយនឹងក្របខ័ណ្ឌ Blazor ប្រសិនបើអ្នកអភិវឌ្ឍន៍របស់អ្នកមានបទពិសោធន៍ជាមួយវា ប៉ុន្តែដោយសារតែភាពចាស់ទុំនៃ WebAssembly ការជ្រើសរើស React និង Typescript សម្រាប់ភាពជោគជ័យរយៈពេលវែងអាចជាការសម្រេចចិត្តប្រសើរជាងមុន។ តម្រូវការគម្រោង និងភាពស្មុគស្មាញ។ ប្រសិនបើអ្នករំពឹងថានឹងទទួលបានបរិមាណចរាចរណ៍ច្រើន ការជ្រើសរើស ASP.NET Core លើ Django អាចជាជម្រើសដ៏ឆ្លាតវៃមួយ ដោយសារដំណើរការដ៏ប្រសើររបស់វាក្នុងការដោះស្រាយសំណើស្របគ្នា។ ទោះជាយ៉ាងណាក៏ដោយ ការសម្រេចចិត្តនេះអាស្រ័យលើទំហំចរាចរណ៍ដែលអ្នករំពឹងទុក។ ប្រសិនបើអ្នកត្រូវគ្រប់គ្រងសំណើរាប់ពាន់លានដែលមានសក្តានុពលជាមួយនឹងភាពយឺតយ៉ាវទាប វត្តមាននៃការប្រមូលសំរាមអាចជាបញ្ហាប្រឈមមួយ។ ការធ្វើមាត្រដ្ឋាន និងតម្រូវការការអនុវត្ត។ ក្នុងករណីភាគច្រើន ទាំងនេះគឺជាកត្តាដែលយើងត្រូវយកចិត្តទុកដាក់។ ពេលវេលាដើម្បីទីផ្សារ ការចំណាយលើការថែទាំ និងស្ថេរភាពនៃការជួលជំរុញឱ្យតម្រូវការអាជីវកម្មរបស់អ្នកដោយគ្មានឧបសគ្គ។ ការជួល ពេលវេលាអភិវឌ្ឍន៍ និងការចំណាយ។ សំណុំជំនាញនៃក្រុមអភិវឌ្ឍន៍របស់អ្នកគឺជាកត្តាសំខាន់។ ជាទូទៅវាមានប្រសិទ្ធភាពជាងក្នុងការប្រើប្រាស់បច្ចេកវិទ្យាដែលក្រុមរបស់អ្នកធ្លាប់ស្គាល់រួចមកហើយ លុះត្រាតែមានហេតុផលរឹងមាំក្នុងការវិនិយោគក្នុងការរៀនជង់ថ្មី។ ជំនាញក្រុម និងធនធាន។ សហគមន៍រឹងមាំ និងប្រព័ន្ធអេកូឡូស៊ីដ៏សម្បូរបែបនៃបណ្ណាល័យ និងឧបករណ៍អាចជួយសម្រួលដល់ដំណើរការអភិវឌ្ឍន៍បានយ៉ាងច្រើន។ បច្ចេកវិទ្យាពេញនិយមជាញឹកញាប់មានការគាំទ្រសហគមន៍កាន់តែប្រសើរ ដែលអាចមានតម្លៃមិនអាចកាត់ថ្លៃបានសម្រាប់ការដោះស្រាយបញ្ហា និងការស្វែងរកធនធាន។ ដូចនេះ អ្នកអាចសន្សំធនធាន និងផ្តោតលើផលិតផលជាចម្បង។ ភាពចាស់ទុំ។ ពិចារណាអំពីលទ្ធភាពជោគជ័យយូរអង្វែងនៃបច្ចេកវិទ្យា។ បច្ចេកវិទ្យាដែលត្រូវបានទទួលយក និងគាំទ្រយ៉ាងទូលំទូលាយ ទំនងជាមិនសូវជាលែងប្រើនោះទេ ហើយជាទូទៅទទួលបានការអាប់ដេត និងការកែលម្អជាប្រចាំ។ ការថែទាំ និងការគាំទ្ររយៈពេលវែង។ តើការមានបណ្តុំបច្ចេកវិទ្យាច្រើនអាចប៉ះពាល់ដល់កំណើនអាជីវកម្មយ៉ាងដូចម្ដេច? តាមទស្សនៈមួយ ការណែនាំជង់មួយបន្ថែមទៀតអាចបង្កើនការជួលរបស់អ្នក ប៉ុន្តែម្យ៉ាងវិញទៀត វានាំមកនូវការចំណាយលើការថែទាំបន្ថែម ចាប់តាំងពីអ្នកត្រូវការដើម្បីគាំទ្រជង់ទាំងពីរ។ ដូច្នេះ ដូចដែលខ្ញុំបាននិយាយពីមុនមក តាមទស្សនៈរបស់ខ្ញុំ មានតែតម្រូវការបន្ថែមប៉ុណ្ណោះដែលគួរតែជាអាគុយម៉ង់សម្រាប់ការបញ្ចូលជង់បច្ចេកវិទ្យាបន្ថែមទៀត។ ប៉ុន្តែតើអ្វីទៅជាគោលការណ៍នៃការជ្រើសរើសឧបករណ៍ដ៏ល្អបំផុតសម្រាប់បញ្ហាជាក់លាក់មួយ? ពេលខ្លះអ្នកមិនមានជម្រើសផ្សេងក្រៅពីនាំយកឧបករណ៍ថ្មីដើម្បីដោះស្រាយបញ្ហាជាក់លាក់មួយដោយផ្អែកលើការពិចារណាដូចគ្នាដែលបានរៀបរាប់ខាងលើ ក្នុងករណីបែបនេះ វាសមហេតុផលក្នុងការជ្រើសរើសដំណោះស្រាយដ៏ល្អបំផុត។ ការបង្កើតប្រព័ន្ធដោយគ្មានការភ្ជាប់ខ្ពស់ទៅនឹងបច្ចេកវិទ្យាជាក់លាក់អាចជាបញ្ហាប្រឈមមួយ។ ទោះយ៉ាងណាក៏ដោយ វាមានប្រយោជន៍ក្នុងការខិតខំសម្រាប់លក្ខខណ្ឌដែលប្រព័ន្ធមិនជាប់នឹងបច្ចេកវិទ្យា ហើយវានឹងមិនស្លាប់ទេ ប្រសិនបើថ្ងៃស្អែក ក្របខ័ណ្ឌ ឬឧបករណ៍ជាក់លាក់មួយក្លាយជាងាយរងគ្រោះ ឬសូម្បីតែត្រូវបានបដិសេធ។ ការពិចារណាសំខាន់មួយទៀតគឺទាក់ទងនឹងភាពអាស្រ័យកម្មវិធីប្រភពបើកចំហ និងកម្មសិទ្ធិ។ កម្មវិធីដែលមានកម្មសិទ្ធិផ្តល់ឱ្យអ្នកនូវភាពបត់បែនតិច និងលទ្ធភាពក្នុងការប្ដូរតាមបំណង។ ទោះជាយ៉ាងណាក៏ដោយ កត្តាគ្រោះថ្នាក់បំផុតគឺការចាក់សោរបស់អ្នកលក់ ដែលជាកន្លែងដែលអ្នកពឹងផ្អែកលើផលិតផលរបស់អ្នកលក់ តម្លៃ លក្ខខណ្ឌ និងផែនទីបង្ហាញផ្លូវ។ នេះអាចជាហានិភ័យ ប្រសិនបើអ្នកលក់ផ្លាស់ប្តូរទិសដៅ បង្កើនតម្លៃ ឬបញ្ឈប់ផលិតផល។ ការលុបបំបាត់ចំណុចតែមួយនៃភាពបរាជ័យនៅគ្រប់កម្រិតគឺជាគន្លឹះក្នុងការកសាងប្រព័ន្ធដែលអាចទុកចិត្តបានសម្រាប់ការរីកចម្រើន។ កម្មវិធីប្រភពបើកចំហកាត់បន្ថយហានិភ័យនេះ ដោយសារអង្គភាពតែមួយមិនអាចគ្រប់គ្រងវាបាន។ ចំណុចបរាជ័យតែមួយ (SPOF) ចំណុចមួយនៃការបរាជ័យ (SPOF) សំដៅទៅលើផ្នែកណាមួយនៃប្រព័ន្ធដែលប្រសិនបើវាបរាជ័យនឹងធ្វើឱ្យប្រព័ន្ធទាំងមូលឈប់ដំណើរការ។ ការលុបបំបាត់ SPOFs នៅគ្រប់កម្រិតគឺមានសារៈសំខាន់សម្រាប់ប្រព័ន្ធណាមួយដែលទាមទារភាពអាចរកបានខ្ពស់។ អ្វីៗទាំងអស់ រួមទាំងចំណេះដឹង បុគ្គលិក សមាសធាតុប្រព័ន្ធ អ្នកផ្តល់សេវាពពក និងខ្សែអ៊ីនធឺណិតអាចបរាជ័យ។ មានបច្ចេកទេសជាមូលដ្ឋានមួយចំនួនដែលយើងអាចអនុវត្តដើម្បីលុបបំបាត់ចំណុចបរាជ័យតែមួយ៖ អនុវត្តការលែងត្រូវការតទៅទៀតសម្រាប់សមាសធាតុសំខាន់ៗ។ នេះមានន័យថាមានសមាសធាតុបម្រុងទុកដែលអាចគ្រប់គ្រងបាន ប្រសិនបើសមាសភាគចម្បងបរាជ័យ។ ការលែងត្រូវការតទៅទៀតអាចត្រូវបានអនុវត្តលើស្រទាប់ផ្សេងៗនៃប្រព័ន្ធ រួមទាំងផ្នែករឹង (ម៉ាស៊ីនមេ ថាស) បណ្តាញ (តំណភ្ជាប់ កុងតាក់) និងកម្មវិធី (មូលដ្ឋានទិន្នន័យ ម៉ាស៊ីនមេកម្មវិធី)។ ប្រសិនបើអ្នកកំពុងបង្ហោះអ្វីគ្រប់យ៉ាងនៅក្នុង Cloud Provider មួយ ហើយថែមទាំងមានការបម្រុងទុកនៅទីនោះ សូមពិចារណាបង្កើតការបម្រុងទុកបន្ថែមជាទៀងទាត់នៅក្នុងមួយផ្សេងទៀត ដើម្បីកាត់បន្ថយការចំណាយរបស់អ្នកដែលបាត់បង់ក្នុងករណីមានគ្រោះមហន្តរាយ។ លែងត្រូវការតទៅទៀត។ ចែកចាយប្រព័ន្ធរបស់អ្នកនៅលើទីតាំងជាក់ស្តែងជាច្រើន ដូចជាមជ្ឈមណ្ឌលទិន្នន័យ ឬតំបន់ពពក។ វិធីសាស្រ្តនេះការពារប្រព័ន្ធរបស់អ្នកប្រឆាំងនឹងការបរាជ័យជាក់លាក់នៃទីតាំង ដូចជាការដាច់ចរន្តអគ្គិសនី ឬគ្រោះមហន្តរាយធម្មជាតិជាដើម។ មជ្ឈមណ្ឌលទិន្នន័យ។ អនុវត្តវិធីសាស្រ្តបរាជ័យសម្រាប់សមាសធាតុទាំងអស់របស់អ្នក (DNS, CDN, Load balancers, Kubernetes, API Gateways និង Databases)។ ដោយសារបញ្ហាអាចកើតឡើងដោយមិននឹកស្មានដល់ វាជារឿងសំខាន់ក្នុងការមានផែនការបម្រុងទុកដើម្បីជំនួសសមាសធាតុណាមួយដោយក្លូនរបស់វាតាមតម្រូវការយ៉ាងឆាប់រហ័ស។ អ្នកបរាជ័យ។ ត្រូវប្រាកដថាសេវាកម្មរបស់អ្នកត្រូវបានបង្កើតឡើងដើម្បីឱ្យមានមាត្រដ្ឋានផ្ដេក និងអាចរកបានខ្ពស់តាំងពីដំបូងដោយប្រកាន់ខ្ជាប់នូវគោលការណ៍ដូចខាងក្រោមៈ សេវាកម្មដែលអាចរកបានខ្ពស់។ អនុវត្តសេវាកម្មគ្មានរដ្ឋ និងជៀសវាងការរក្សាទុកវគ្គអ្នកប្រើប្រាស់នៅក្នុងឃ្លាំងសម្ងាត់ក្នុងអង្គចងចាំ។ ជំនួសមកវិញ ប្រើប្រព័ន្ធឃ្លាំងសម្ងាត់ដែលបានចែកចាយ ដូចជា Redis ជាដើម។ ជៀសវាងការពឹងផ្អែកលើលំដាប់លំដោយនៃការប្រើប្រាស់សារនៅពេលបង្កើតតក្កវិជ្ជា។ កាត់បន្ថយការផ្លាស់ប្តូរបំបែក ដើម្បីការពារអ្នកប្រើប្រាស់ API ដែលរំខាន។ នៅកន្លែងដែលអាចធ្វើទៅបាន សូមជ្រើសរើសការផ្លាស់ប្តូរដែលត្រូវគ្នានឹងថយក្រោយ។ សូមពិចារណាផងដែរអំពីការចំណាយចាប់តាំងពីពេលខ្លះ ការអនុវត្តការផ្លាស់ប្តូរបំបែកអាចមានតម្លៃកាន់តែមានប្រសិទ្ធភាព។ បញ្ចូលការអនុវត្តការធ្វើចំណាកស្រុកទៅក្នុងបំពង់ដាក់ពង្រាយ។ បង្កើតយុទ្ធសាស្រ្តសម្រាប់ដោះស្រាយសំណើស្របគ្នា។ អនុវត្តការរកឃើញ ការត្រួតពិនិត្យ និងការកត់ត្រាសេវាកម្ម ដើម្បីបង្កើនភាពជឿជាក់ និងការសង្កេត។ អភិវឌ្ឍតក្កវិជ្ជាអាជីវកម្មឱ្យមានភាពរឹងមាំ ដោយទទួលស្គាល់ថាការបរាជ័យបណ្តាញគឺជៀសមិនរួច។ ពិនិត្យជាប្រចាំ និងកាត់បន្ថយភាពអាស្រ័យខាងក្រៅ។ ភាពអាស្រ័យខាងក្រៅនីមួយៗអាចណែនាំ SPOFs ដ៏មានសក្តានុពល ដូច្នេះវាចាំបាច់ណាស់ក្នុងការយល់ដឹង និងកាត់បន្ថយហានិភ័យទាំងនេះ។ ការពិនិត្យមើលភាពអាស្រ័យ។ កុំភ្លេចអំពីសារៈសំខាន់នៃការផ្សព្វផ្សាយចំណេះដឹងនៅក្នុងអង្គភាពរបស់អ្នក។ មនុស្សមិនអាចទាយទុកជាមុនបាន ហើយការពឹងផ្អែកលើបុគ្គលតែម្នាក់គឺមានគ្រោះថ្នាក់។ លើកទឹកចិត្តសមាជិកក្រុមឱ្យធ្វើឌីជីថលចំណេះដឹងរបស់ពួកគេតាមរយៈឯកសារ។ ទោះយ៉ាងណាក៏ដោយ ត្រូវចាំថា ឯកសារលើសកំណត់។ ប្រើប្រាស់ឧបករណ៍ AI ផ្សេងៗដើម្បីសម្រួលដំណើរការនេះ។ ចែករំលែកចំណេះដឹងជាប្រចាំ។ សេចក្តីសន្និដ្ឋាន នៅក្នុងអត្ថបទនេះ យើងបានគ្របដណ្តប់ទិដ្ឋភាព សំខាន់ៗមួយចំនួន និងរបៀបដែលយើងអាចដោះស្រាយជាមួយនឹងភាពស្មុគស្មាញរបស់វា។ ម៉ាក្រូ សូមអរគុណសម្រាប់ការអាន! ជួបគ្នាពេលក្រោយ!