យុទ្ធសាស្ត្រធន់នឹងពិភពលោកពិតប្រាកដសម្រាប់គម្រោង Fintech

ភាពធន់នៅក្នុងកម្មវិធី សំដៅលើសមត្ថភាពរបស់កម្មវិធីដើម្បីបន្តដំណើរការដោយរលូន និងអាចទុកចិត្តបាន ទោះបីជាប្រឈមមុខនឹងបញ្ហាដែលមិនបានរំពឹងទុក ឬបរាជ័យក៏ដោយ។ នៅក្នុងគម្រោង Fintech ភាពធន់គឺមានសារៈសំខាន់ជាពិសេសដោយសារហេតុផលមួយចំនួន។ ទីមួយ ក្រុមហ៊ុនត្រូវមានកាតព្វកិច្ចបំពេញតាមតម្រូវការបទប្បញ្ញត្តិ ហើយនិយតករហិរញ្ញវត្ថុសង្កត់ធ្ងន់លើភាពធន់នៃប្រតិបត្តិការដើម្បីរក្សាស្ថិរភាពនៅក្នុងប្រព័ន្ធ។ ជាងនេះទៅទៀត ការរីកសាយភាយនៃឧបករណ៍ឌីជីថល និងការពឹងផ្អែកលើអ្នកផ្តល់សេវាភាគីទីបីបង្ហាញពីអាជីវកម្ម Fintech ទៅនឹងការគំរាមកំហែងផ្នែកសុវត្ថិភាព។ ភាពធន់ក៏ជួយកាត់បន្ថយហានិភ័យនៃការដាច់ចរន្តដែលបណ្តាលមកពីកត្តាផ្សេងៗដូចជាការគំរាមកំហែងតាមអ៊ីនធឺណិត ជំងឺរាតត្បាត ឬព្រឹត្តិការណ៍ភូមិសាស្ត្រនយោបាយ ការការពារប្រតិបត្តិការអាជីវកម្មស្នូល និងទ្រព្យសម្បត្តិសំខាន់ៗ។ តាមរយៈគំរូនៃភាពធន់ យើងយល់អំពីសំណុំនៃការអនុវត្ត និងយុទ្ធសាស្រ្តដ៏ល្អបំផុតដែលបានរចនាឡើងដើម្បីធានាថាកម្មវិធីអាចទប់ទល់នឹងការរំខាន និងរក្សាប្រតិបត្តិការរបស់វា។ គំរូទាំងនេះដើរតួនាទីដូចជាសំណាញ់សុវត្ថិភាព ផ្តល់យន្តការដើម្បីដោះស្រាយកំហុស គ្រប់គ្រងការផ្ទុក និងងើបឡើងវិញពីការបរាជ័យ ដោយហេតុនេះធានាថាកម្មវិធីនៅតែរឹងមាំ និងអាចទុកចិត្តបានក្រោមលក្ខខណ្ឌមិនល្អ។ យុទ្ធសាស្រ្តធន់ទ្រាំទូទៅបំផុតរួមមាន bulkhead, cache, fallback, retry, និង circuit breaker។ នៅក្នុងអត្ថបទនេះ ខ្ញុំនឹងពិភាក្សាពួកគេឱ្យកាន់តែលម្អិត ជាមួយនឹងឧទាហរណ៍នៃបញ្ហាដែលពួកគេអាចជួយដោះស្រាយបាន។ Bulkhead ចូរយើងពិនិត្យមើលការកំណត់ខាងលើ។ យើងមានកម្មវិធីធម្មតាមួយដែលមាន backend ជាច្រើននៅពីក្រោយយើងដើម្បីទទួលបានទិន្នន័យខ្លះពី។ មានម៉ាស៊ីនភ្ញៀវ HTTP ជាច្រើនបានភ្ជាប់ទៅផ្នែកខាងក្រោយទាំងនេះ។ វាប្រែថាពួកគេទាំងអស់ចែករំលែកក្រុមតភ្ជាប់ដូចគ្នា! និងធនធានផ្សេងទៀតដូចជា CPU និង RAM ។ តើនឹងមានអ្វីកើតឡើង ប្រសិនបើ backends ណាមួយជួបប្រទះបញ្ហាមួយចំនួនដែលបណ្តាលឱ្យមានភាពយឺតយ៉ាវនៃសំណើខ្ពស់? ដោយសារតែពេលវេលាឆ្លើយតបខ្ពស់ បណ្តុំនៃការតភ្ជាប់ទាំងមូលនឹងត្រូវបានកាន់កាប់ទាំងស្រុងដោយសំណើរង់ចាំការឆ្លើយតបពី backend1 ។ ជាលទ្ធផល សំណើដែលមានបំណងសម្រាប់ backend2 និង backend3 ដែលមានសុខភាពល្អនឹងមិនអាចបន្តបានទេ ដោយសារអាងអស់ហើយ។ នេះមានន័យថាការបរាជ័យនៅក្នុងផ្នែកខាងក្រោយរបស់យើងអាចបណ្តាលឱ្យមានការបរាជ័យនៅទូទាំងកម្មវិធីទាំងមូល។ តាមឧត្ដមគតិ យើងចង់បានតែមុខងារដែលភ្ជាប់ជាមួយកម្មវិធីខាងក្រោយដែលបរាជ័យ ដើម្បីជួបប្រទះការរិចរិល ខណៈកម្មវិធីដែលនៅសល់បន្តដំណើរការជាធម្មតា។ តើអ្វីជាគំរូ Bulkhead? ពាក្យ លំនាំ Bulkhead កើតចេញពីការកសាងកប៉ាល់ វាពាក់ព័ន្ធនឹងការបង្កើតផ្នែកដាច់ដោយឡែកជាច្រើននៅក្នុងកប៉ាល់មួយ។ ប្រសិនបើការលេចធ្លាយមួយកើតឡើងក្នុងបន្ទប់មួយ វានឹងបំពេញដោយទឹក ប៉ុន្តែបន្ទប់ផ្សេងទៀតនៅតែមិនមានផលប៉ះពាល់។ ភាពឯកោនេះរារាំងនាវាទាំងមូលពីការលិចដោយសារតែការបំពានតែមួយ។ តើយើងអាចប្រើគំរូ Bulkhead ដើម្បីដោះស្រាយបញ្ហានេះដោយរបៀបណា? គំរូ Bulkhead អាចត្រូវបានប្រើដើម្បីបំបែកប្រភេទផ្សេងៗនៃធនធាននៅក្នុងកម្មវិធី ដោយការពារការបរាជ័យក្នុងផ្នែកមួយពីការប៉ះពាល់ដល់ប្រព័ន្ធទាំងមូល។ នេះជារបៀបដែលយើងអាចអនុវត្តវាចំពោះបញ្ហារបស់យើង៖ Isolating Connection Pools យើងអាចបង្កើតក្រុមតភ្ជាប់ដាច់ដោយឡែកសម្រាប់ backend នីមួយៗ (backend1, backend2, backend3)។ នេះធានាថាប្រសិនបើ backend1 ជួបប្រទះពេលវេលាឆ្លើយតបខ្ពស់ ឬការបរាជ័យ នោះក្រុមការតភ្ជាប់របស់វានឹងត្រូវបានអស់ដោយឯករាជ្យ ដោយទុកឱ្យក្រុមភ្ជាប់សម្រាប់ backend2 និង backend3 មិនរងផលប៉ះពាល់។ ភាពឯកោនេះអនុញ្ញាតឱ្យផ្នែកខាងក្រោយដែលមានសុខភាពល្អបន្តដំណើរការសំណើជាធម្មតា។ ការកំណត់ធនធានសម្រាប់សកម្មភាពផ្ទៃខាងក្រោយ ដោយប្រើ Bulkheads យើងអាចបែងចែកធនធានជាក់លាក់សម្រាប់សកម្មភាពផ្ទៃខាងក្រោយ ដូចជាដំណើរការជាបាច់ ឬកិច្ចការដែលបានកំណត់ពេល។ វារារាំងសកម្មភាពទាំងនេះពីការប្រើប្រាស់ធនធានដែលត្រូវការសម្រាប់ប្រតិបត្តិការក្នុងពេលជាក់ស្តែង។ ឧទាហរណ៍ យើងអាចដាក់កម្រិតលើចំនួនខ្សែស្រឡាយ ឬការប្រើប្រាស់ CPU ដែលឧទ្ទិសដល់កិច្ចការផ្ទៃខាងក្រោយ ដោយធានាថាធនធានគ្រប់គ្រាន់នៅតែមានសម្រាប់ដោះស្រាយសំណើចូល។ ការកំណត់ការរឹតត្បិតលើសំណើចូល ក្បាលសំពោងក៏អាចត្រូវបានអនុវត្តដើម្បីកំណត់ចំនួនសំណើចូលមកកាន់ផ្នែកផ្សេងៗនៃកម្មវិធី។ ជាឧទាហរណ៍ យើងអាចកំណត់ដែនកំណត់អតិបរមាលើចំនួនសំណើដែលអាចត្រូវបានដំណើរការក្នុងពេលដំណាលគ្នាសម្រាប់សេវាកម្មខាងលើនីមួយៗ។ វារារាំងផ្នែកខាងក្រោយតែមួយពីការលើសលប់នៃប្រព័ន្ធ និងធានាថា backend ផ្សេងទៀតអាចបន្តដំណើរការបាន ទោះបីជាវាស្ថិតនៅក្រោមបន្ទុកធ្ងន់ក៏ដោយ។ ស៊ីកា ឧបមាថាប្រព័ន្ធ backend របស់យើងមានប្រូបាប៊ីលីតេទាបក្នុងការជួបប្រទះកំហុសរៀងៗខ្លួន។ ទោះយ៉ាងណាក៏ដោយ នៅពេលដែលប្រតិបត្តិការមួយពាក់ព័ន្ធនឹងការសាកសួរ backend ទាំងអស់នេះស្របគ្នា នីមួយៗអាចត្រឡប់កំហុសដោយឯករាជ្យ។ ដោយសារកំហុសទាំងនេះកើតឡើងដោយឯករាជ្យ ប្រូបាប៊ីលីតេទូទៅនៃកំហុសនៅក្នុងកម្មវិធីរបស់យើងគឺខ្ពស់ជាងប្រូបាប៊ីលីតេនៃកំហុសនៃកម្មវិធីខាងក្រោយតែមួយ។ ប្រូបាប៊ីលីតេនៃកំហុសរួមអាចត្រូវបានគណនាដោយប្រើរូបមន្ត P_total=1−(1−p)^n ដែល n ជាចំនួននៃប្រព័ន្ធខាងក្រោយ។ ឧទាហរណ៍ ប្រសិនបើយើងមាន backend ដប់ ដែលនីមួយៗមានប្រូបាប៊ីលីតេកំហុសនៃ p=0.001 (ដែលត្រូវគ្នានឹង SLA នៃ 99.9%) នោះប្រូបាប៊ីលីតេនៃកំហុសគឺ៖ P_total=1−(1−0.001)^10=0.009955 នេះមានន័យថា SLA រួមបញ្ចូលគ្នារបស់យើងធ្លាក់ចុះដល់ប្រហែល 99% ដែលបង្ហាញពីរបៀបដែលភាពជឿជាក់រួមថយចុះនៅពេលសួរ backends ច្រើនស្របគ្នា។ ដើម្បីកាត់បន្ថយបញ្ហានេះ យើងអាចអនុវត្តឃ្លាំងសម្ងាត់ក្នុងអង្គចងចាំ។ របៀបដែលយើងអាចដោះស្រាយវាជាមួយឃ្លាំងសម្ងាត់ក្នុងសតិ ឃ្លាំងសម្ងាត់ក្នុងអង្គចងចាំបម្រើជាអង្គចងចាំទិន្នន័យល្បឿនលឿន រក្សាទុកទិន្នន័យដែលបានចូលប្រើញឹកញាប់ និងលុបបំបាត់តម្រូវការក្នុងការទាញយកវាពីប្រភពដែលមានសក្តានុពលរាល់ពេល។ ដោយសារឃ្លាំងសម្ងាត់ដែលរក្សាទុកក្នុងអង្គចងចាំមានឱកាស 0% នៃកំហុសបើប្រៀបធៀបទៅនឹងការទាញយកទិន្នន័យនៅលើបណ្តាញ ពួកគេបង្កើនភាពជឿជាក់នៃកម្មវិធីរបស់យើង។ លើសពីនេះទៅទៀត ឃ្លាំងសម្ងាត់កាត់បន្ថយចរាចរណ៍បណ្តាញ កាត់បន្ថយឱកាសនៃកំហុស។ អាស្រ័យហេតុនេះ តាមរយៈការប្រើប្រាស់ឃ្លាំងសម្ងាត់ក្នុងអង្គចងចាំ យើងអាចសម្រេចបាននូវអត្រាកំហុសទាបជាងនៅក្នុងកម្មវិធីរបស់យើង បើប្រៀបធៀបទៅនឹងប្រព័ន្ធ backend របស់យើង។ លើសពីនេះទៀត ឃ្លាំងសម្ងាត់ក្នុងអង្គចងចាំផ្តល់នូវការទាញយកទិន្នន័យលឿនជាងការទៅយកតាមបណ្តាញ ដោយកាត់បន្ថយភាពយឺតនៃកម្មវិធី ដែលជាអត្ថប្រយោជន៍គួរឱ្យកត់សម្គាល់។ ឃ្លាំងសម្ងាត់ក្នុងអង្គចងចាំ៖ ឃ្លាំងសម្ងាត់ផ្ទាល់ខ្លួន សម្រាប់ទិន្នន័យផ្ទាល់ខ្លួន ដូចជាទម្រង់អ្នកប្រើប្រាស់ ឬការណែនាំ ការប្រើឃ្លាំងសម្ងាត់ក្នុងអង្គចងចាំក៏អាចមានប្រសិទ្ធភាពខ្ពស់ផងដែរ។ ប៉ុន្តែយើងត្រូវតែធានារាល់សំណើពីអ្នកប្រើប្រាស់ជាប្រចាំទៅកាន់កម្មវិធីដូចគ្នា ដើម្បីប្រើប្រាស់ទិន្នន័យដែលបានរក្សាទុកក្នុងឃ្លាំងសម្ងាត់សម្រាប់ពួកគេ ដែលតម្រូវឱ្យមានវគ្គជាប់ស្អិត។ ការអនុវត្តវគ្គស្អិតអាចជាបញ្ហាប្រឈម ប៉ុន្តែសម្រាប់សេណារីយ៉ូនេះ យើងមិនត្រូវការយន្តការស្មុគស្មាញទេ។ តុល្យភាពចរាចរណ៍តូចតាចគឺអាចទទួលយកបាន ដូច្នេះក្បួនដោះស្រាយតុល្យភាពបន្ទុកដែលមានស្ថេរភាពដូចជាការបំបែកជាប់គ្នានឹងគ្រប់គ្រាន់។ អ្វីដែលលើសពីនេះទៅទៀត នៅក្នុងករណីនៃការបរាជ័យថ្នាំង ការ hashing ជាប់លាប់ធានាថាមានតែអ្នកប្រើប្រាស់ដែលភ្ជាប់ជាមួយនឹងថ្នាំងដែលបរាជ័យប៉ុណ្ណោះដែលឆ្លងកាត់តុល្យភាពឡើងវិញ កាត់បន្ថយការរំខានដល់ប្រព័ន្ធ។ វិធីសាស្រ្តនេះជួយសម្រួលការគ្រប់គ្រងឃ្លាំងសម្ងាត់ផ្ទាល់ខ្លួន និងបង្កើនស្ថេរភាព និងដំណើរការទាំងមូលនៃកម្មវិធីរបស់យើង។ ឃ្លាំងសម្ងាត់ក្នុងអង្គចងចាំ៖ ការចម្លងទិន្នន័យមូលដ្ឋាន ប្រសិនបើទិន្នន័យដែលយើងចង់ទុកក្នុងឃ្លាំងសម្ងាត់មានសារៈសំខាន់ ហើយត្រូវបានប្រើប្រាស់ក្នុងរាល់សំណើដែលគ្រប់គ្រងដោយប្រព័ន្ធរបស់យើង ដូចជាគោលការណ៍ចូលប្រើ គម្រោងការជាវ ឬអង្គភាពសំខាន់ៗផ្សេងទៀតនៅក្នុងដែនរបស់យើង—ប្រភពនៃទិន្នន័យនេះអាចបង្កឱ្យមានការបរាជ័យយ៉ាងសំខាន់នៅក្នុងប្រព័ន្ធរបស់យើង។ ដើម្បីដោះស្រាយបញ្ហាប្រឈមនេះ វិធីសាស្រ្តមួយគឺការចម្លងទិន្នន័យនេះទាំងស្រុងដោយផ្ទាល់ទៅក្នុងការចងចាំនៃកម្មវិធីរបស់យើង។ នៅក្នុងសេណារីយ៉ូនេះ ប្រសិនបើបរិមាណនៃទិន្នន័យនៅក្នុងប្រភពអាចគ្រប់គ្រងបាន យើងអាចចាប់ផ្តើមដំណើរការដោយទាញយករូបថតនៃទិន្នន័យនេះនៅពេលចាប់ផ្តើមកម្មវិធីរបស់យើង។ ជាបន្តបន្ទាប់ យើងអាចទទួលបានព្រឹត្តិការណ៍អាប់ដេត ដើម្បីធានាថាទិន្នន័យក្នុងឃ្លាំងសម្ងាត់នៅតែធ្វើសមកាលកម្មជាមួយប្រភព។ តាមរយៈការទទួលយកវិធីសាស្រ្តនេះ យើងបង្កើនភាពជឿជាក់នៃការចូលប្រើទិន្នន័យសំខាន់នេះ ដោយសារការទាញយកនីមួយៗកើតឡើងដោយផ្ទាល់ពីអង្គចងចាំជាមួយនឹងប្រូបាប 0% ។ លើសពីនេះ ការទាញយកទិន្នន័យពីអង្គចងចាំគឺមានល្បឿនលឿនពិសេស ដោយហេតុនេះការបង្កើនប្រសិទ្ធភាពនៃការអនុវត្តកម្មវិធីរបស់យើង។ យុទ្ធសាស្រ្តនេះមានប្រសិទ្ធភាពកាត់បន្ថយហានិភ័យដែលទាក់ទងនឹងការពឹងផ្អែកលើប្រភពទិន្នន័យខាងក្រៅ ដោយធានាបាននូវការចូលប្រើប្រាស់បានត្រឹមត្រូវ និងអាចទុកចិត្តបានចំពោះព័ត៌មានសំខាន់ៗសម្រាប់ប្រតិបត្តិការកម្មវិធីរបស់យើង។ កំណត់រចនាសម្ព័ន្ធដែលអាចផ្ទុកឡើងវិញបាន។ ទោះជាយ៉ាងណាក៏ដោយ តម្រូវការទាញយកទិន្នន័យនៅពេលចាប់ផ្តើមកម្មវិធី ដោយហេតុនេះការពន្យារពេលដំណើរការចាប់ផ្តើម បំពានគោលការណ៍មួយនៃ 'កម្មវិធី 12-factor' ដែលតស៊ូមតិសម្រាប់ការចាប់ផ្តើមកម្មវិធីរហ័ស។ ប៉ុន្តែ យើងមិនចង់បាត់បង់អត្ថប្រយោជន៍នៃការប្រើប្រាស់ឃ្លាំងសម្ងាត់នោះទេ។ ដើម្បីដោះស្រាយបញ្ហានេះ អនុញ្ញាតឱ្យស្វែងរកដំណោះស្រាយដែលមានសក្តានុពល។ ការចាប់ផ្តើមលឿនគឺមានសារៈសំខាន់ជាពិសេសសម្រាប់វេទិកាដូចជា Kubernetes ដែលពឹងផ្អែកលើការផ្ទេរកម្មវិធីរហ័សទៅកាន់ថ្នាំងរូបវន្តផ្សេងៗ។ ជាសំណាងល្អ Kubernetes អាចគ្រប់គ្រងកម្មវិធីចាប់ផ្តើមយឺតដោយប្រើមុខងារដូចជាការស៊ើបអង្កេតពេលចាប់ផ្ដើម។ បញ្ហាប្រឈមមួយទៀតដែលយើងអាចប្រឈមមុខគឺការធ្វើបច្ចុប្បន្នភាពការកំណត់ខណៈពេលដែលកម្មវិធីកំពុងដំណើរការ។ ជាញឹកញាប់ ការកែតម្រូវពេលវេលាឃ្លាំងសម្ងាត់ ឬសំណើអស់ពេលគឺចាំបាច់ដើម្បីដោះស្រាយបញ្ហាផលិតកម្ម។ ទោះបីជាយើងអាចដាក់ពង្រាយឯកសារកំណត់រចនាសម្ព័ន្ធដែលបានធ្វើបច្ចុប្បន្នភាពយ៉ាងឆាប់រហ័សទៅកម្មវិធីរបស់យើងក៏ដោយ ការអនុវត្តការផ្លាស់ប្តូរទាំងនេះជាធម្មតាតម្រូវឱ្យមានការចាប់ផ្តើមឡើងវិញ។ ជាមួយនឹងការពន្យាពេលនៃការចាប់ផ្តើមកម្មវិធីនីមួយៗ ការចាប់ផ្ដើមឡើងវិញអាចពន្យាពេលយ៉ាងសំខាន់ក្នុងការដាក់ពង្រាយការជួសជុលដល់អ្នកប្រើប្រាស់របស់យើង។ ដើម្បីដោះស្រាយបញ្ហានេះ ដំណោះស្រាយមួយគឺរក្សាទុកការកំណត់រចនាសម្ព័ន្ធក្នុងអថេរស្របគ្នា ហើយមានខ្សែស្រឡាយផ្ទៃខាងក្រោយធ្វើបច្ចុប្បន្នភាពវាជាប្រចាំ។ ទោះយ៉ាងណាក៏ដោយ ប៉ារ៉ាម៉ែត្រមួយចំនួនដូចជាការអស់ពេលសំណើ HTTP អាចតម្រូវឱ្យចាប់ផ្តើម HTTP ឬអតិថិជនមូលដ្ឋានទិន្នន័យឡើងវិញ នៅពេលដែលការកំណត់រចនាសម្ព័ន្ធដែលត្រូវគ្នាផ្លាស់ប្តូរ ដែលបង្កឱ្យមានបញ្ហាប្រឈម។ ទោះជាយ៉ាងណាក៏ដោយ អតិថិជនមួយចំនួនដូចជាកម្មវិធីបញ្ជា Cassandra សម្រាប់ Java គាំទ្រការបញ្ចូលការកំណត់រចនាសម្ព័ន្ធឡើងវិញដោយស្វ័យប្រវត្តិ ដែលធ្វើអោយដំណើរការនេះកាន់តែងាយស្រួល។ ការអនុវត្តការកំណត់រចនាសម្ព័ន្ធដែលអាចផ្ទុកឡើងវិញបានអាចកាត់បន្ថយផលប៉ះពាល់អវិជ្ជមាននៃពេលវេលាចាប់ផ្តើមកម្មវិធីយូរ និងផ្តល់អត្ថប្រយោជន៍បន្ថែម ដូចជាការសម្រួលដល់ការអនុវត្តទង់មុខងារ។ វិធីសាស្រ្តនេះអាចឱ្យយើងរក្សាបាននូវភាពជឿជាក់ និងការឆ្លើយតបរបស់កម្មវិធី ខណៈពេលដែលការគ្រប់គ្រងការអាប់ដេតនៃការកំណត់រចនាសម្ព័ន្ធប្រកបដោយប្រសិទ្ធភាព។ ថយក្រោយ ឥឡូវនេះអនុញ្ញាតឱ្យយើងពិនិត្យមើលបញ្ហាមួយទៀត: នៅក្នុងប្រព័ន្ធរបស់យើង នៅពេលដែលសំណើរបស់អ្នកប្រើត្រូវបានទទួល និងដំណើរការដោយការផ្ញើសំណួរទៅកាន់ backend ឬ database ម្តងម្កាល ការឆ្លើយតបកំហុសត្រូវបានទទួលជំនួសឱ្យទិន្នន័យដែលរំពឹងទុក។ ជាបន្តបន្ទាប់ ប្រព័ន្ធរបស់យើងឆ្លើយតបទៅអ្នកប្រើប្រាស់ជាមួយនឹង 'error'។ ទោះយ៉ាងណាក៏ដោយ នៅក្នុងសេណារីយ៉ូជាច្រើន វាអាចជាការប្រសើរក្នុងការបង្ហាញទិន្នន័យដែលហួសសម័យបន្តិច រួមជាមួយនឹងសារដែលបង្ហាញថាមានការពន្យាពេលការធ្វើឱ្យទិន្នន័យឡើងវិញ ជាជាងការទុកឱ្យអ្នកប្រើប្រាស់នូវសារកំហុសពណ៌ក្រហមដ៏ធំ។ ដើម្បីដោះស្រាយបញ្ហានេះ និងកែលម្អឥរិយាបថរបស់ប្រព័ន្ធរបស់យើង យើងអាចអនុវត្តគំរូ Fallback ។ គំនិតនៅពីក្រោយគំរូនេះពាក់ព័ន្ធនឹងការមានប្រភពទិន្នន័យបន្ទាប់បន្សំ ដែលអាចផ្ទុកទិន្នន័យដែលមានគុណភាពទាប ឬភាពស្រស់បើប្រៀបធៀបទៅនឹងប្រភពចម្បង។ ប្រសិនបើប្រភពទិន្នន័យចម្បងមិនអាចប្រើបាន ឬត្រឡប់កំហុសមួយ ប្រព័ន្ធអាចត្រឡប់ទៅយកទិន្នន័យពីប្រភពបន្ទាប់បន្សំនេះវិញ ដោយធានាថាទម្រង់នៃព័ត៌មានមួយចំនួនត្រូវបានបង្ហាញដល់អ្នកប្រើប្រាស់ជំនួសឱ្យការបង្ហាញសារកំហុស។ ព្យាយាមម្តងទៀត ប្រសិនបើអ្នកក្រឡេកមើលរូបភាពខាងលើ អ្នកនឹងសម្គាល់ឃើញភាពស្រដៀងគ្នារវាងបញ្ហាដែលយើងកំពុងប្រឈមមុខនៅពេលនេះ និងបញ្ហាដែលយើងជួបប្រទះជាមួយឧទាហរណ៍ឃ្លាំងសម្ងាត់។ ដើម្បីដោះស្រាយវា យើងអាចពិចារណាអនុវត្តលំនាំដែលគេស្គាល់ថាព្យាយាមម្តងទៀត។ ជំនួសឱ្យការពឹងផ្អែកលើឃ្លាំងសម្ងាត់ ប្រព័ន្ធអាចត្រូវបានរចនាឡើងដើម្បីបញ្ជូនសំណើឡើងវិញដោយស្វ័យប្រវត្តិក្នុងករណីមានកំហុស។ គំរូនៃការព្យាយាមម្តងទៀតនេះផ្តល់នូវជម្រើសដ៏សាមញ្ញជាង និងអាចកាត់បន្ថយលទ្ធភាពនៃកំហុសនៅក្នុងកម្មវិធីរបស់យើង។ មិនដូចឃ្លាំងសម្ងាត់ ដែលជារឿយៗតម្រូវឱ្យមានយន្តការធ្វើឱ្យមានសុពលភាពនៃឃ្លាំងសម្ងាត់ស្មុគស្មាញ ដើម្បីដោះស្រាយការផ្លាស់ប្តូរទិន្នន័យ ការព្យាយាមស្នើសុំដែលបរាជ័យម្តងទៀតគឺមានភាពសាមញ្ញក្នុងការអនុវត្ត។ ដោយសារភាពមិនត្រឹមត្រូវនៃឃ្លាំងសម្ងាត់ត្រូវបានចាត់ទុកយ៉ាងទូលំទូលាយថាជាកិច្ចការដ៏លំបាកបំផុតមួយក្នុងវិស្វកម្មសូហ្វវែរ ការទទួលយកយុទ្ធសាស្រ្តព្យាយាមម្តងទៀតអាចសម្រួលការគ្រប់គ្រងកំហុស និងកែលម្អភាពធន់របស់ប្រព័ន្ធ។ ឧបករណ៍បំបែកសៀគ្វី ទោះជាយ៉ាងណាក៏ដោយ ការទទួលយកយុទ្ធសាស្រ្តព្យាយាមម្តងទៀតដោយមិនគិតពីផលវិបាកដែលអាចកើតមានអាចនាំឱ្យមានផលវិបាកបន្ថែមទៀត។ សូមស្រមៃគិតថាអ្នកគាំទ្រម្នាក់របស់យើងជួបប្រទះនឹងការបរាជ័យ។ ក្នុងស្ថានភាពបែបនេះ ការចាប់ផ្តើមព្យាយាមបន្តទៅផ្នែកខាងក្រោយដែលបរាជ័យអាចនាំឱ្យមានការកើនឡើងយ៉ាងខ្លាំងនូវបរិមាណចរាចរណ៍។ ការកើនឡើងភ្លាមៗនៃចរាចរណ៍នេះអាចគ្របដណ្ដប់លើផ្នែកខាងក្រោយ ដែលធ្វើអោយការបរាជ័យកាន់តែធ្ងន់ធ្ងរ និងអាចបណ្តាលឱ្យមានផលប៉ះពាល់លើប្រព័ន្ធ។ ដើម្បីទប់ទល់នឹងបញ្ហាប្រឈមនេះ វាជាការសំខាន់ក្នុងការបំពេញលំនាំការព្យាយាមម្ដងទៀតជាមួយនឹងគំរូឧបករណ៍បំបែកសៀគ្វី។ ឧបករណ៍បំលែងសៀគ្វីបម្រើជាយន្តការការពារដែលត្រួតពិនិត្យអត្រាកំហុសនៃសេវាកម្មចុះក្រោម។ នៅពេលដែលអត្រាកំហុសលើសពីកម្រិតកំណត់ដែលបានកំណត់ជាមុន ឧបករណ៍បំបែកសៀគ្វីរំខានសំណើទៅកាន់សេវាកម្មដែលរងផលប៉ះពាល់ក្នុងរយៈពេលជាក់លាក់មួយ។ ក្នុងអំឡុងពេលនេះ ប្រព័ន្ធបដិសេធមិនផ្ញើសំណើបន្ថែម ដើម្បីអនុញ្ញាតឱ្យពេលវេលាសេវាកម្មដែលបរាជ័យក្នុងការស្តារឡើងវិញ។ បន្ទាប់ពីចន្លោះពេលដែលបានកំណត់ ឧបករណ៍បំបែកសៀគ្វីដោយប្រុងប្រយ័ត្នអនុញ្ញាតឱ្យសំណើមួយចំនួនមានកំណត់ឆ្លងកាត់ ដោយផ្ទៀងផ្ទាត់ថាតើសេវាកម្មមានស្ថេរភាពឬអត់។ ប្រសិនបើសេវាកម្មបានងើបឡើងវិញ ចរាចរណ៍ធម្មតាត្រូវបានស្ដារឡើងវិញជាបណ្តើរៗ។ បើមិនដូច្នេះទេ សៀគ្វីនៅតែបើក ដោយបន្តរារាំងសំណើរហូតដល់សេវាចាប់ផ្តើមដំណើរការធម្មតា។ តាមរយៈការរួមបញ្ចូលគំរូឧបករណ៍បំប្លែងសៀគ្វីរួមជាមួយនឹងតក្កវិជ្ជាព្យាយាមម្តងទៀត យើងអាចគ្រប់គ្រងស្ថានការណ៍កំហុសប្រកបដោយប្រសិទ្ធភាព និងការពារការលើសទម្ងន់នៃប្រព័ន្ធកំឡុងពេលការបរាជ័យផ្នែកខាងក្រោយ។ រុំឡើង សរុបសេចក្តីមក តាមរយៈការអនុវត្តគំរូនៃភាពធន់ទាំងនេះ យើងអាចពង្រឹងកម្មវិធីរបស់យើងប្រឆាំងនឹងភាពអាសន្ន រក្សាភាពអាចរកបានខ្ពស់ និងផ្តល់បទពិសោធន៍គ្មានថ្នេរដល់អ្នកប្រើប្រាស់។ លើសពីនេះទៀត ខ្ញុំចង់បញ្ជាក់ថា telemetry គឺជាឧបករណ៍មួយផ្សេងទៀតដែលមិនគួរមើលរំលងនៅពេលផ្តល់ភាពធន់នឹងគម្រោង។ កំណត់ហេតុ និងរង្វាស់ល្អអាចបង្កើនគុណភាពនៃសេវាកម្មយ៉ាងសំខាន់ និងផ្តល់នូវការយល់ដឹងដ៏មានតម្លៃក្នុងការអនុវត្តរបស់ពួកគេ ដោយជួយធ្វើការសម្រេចចិត្តប្រកបដោយការយល់ដឹង ដើម្បីកែលម្អពួកវាបន្ថែមទៀត។