ហេហេ!

ដោយសារតែព្រឹត្តិការណ៍បច្ចុប្បន្នដោយសារមេរោគកូរ៉ូណា សេវាអ៊ីនធឺណិតមួយចំនួនបានចាប់ផ្តើមទទួលបានការកើនឡើង។ ឧទាហរណ៍, សង្វាក់លក់រាយមួយរបស់ចក្រភពអង់គ្លេសគ្រាន់តែបញ្ឈប់គេហទំព័របញ្ជាទិញតាមអ៊ីនធឺណិតរបស់ខ្លួន។ព្រោះមិនមានសមត្ថភាពគ្រប់គ្រាន់។ ហើយវាមិនតែងតែអាចធ្វើទៅបានដើម្បីបង្កើនល្បឿនម៉ាស៊ីនមេដោយគ្រាន់តែបន្ថែមឧបករណ៍ដែលមានថាមពលខ្លាំងជាងនេះទេ ប៉ុន្តែសំណើរបស់អតិថិជនត្រូវតែដំណើរការ (ឬពួកគេនឹងទៅរកដៃគូប្រកួតប្រជែង)។

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

ការធ្វើមាត្រដ្ឋានផ្ដេក

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

ឧទាហរណ៍ ខ្ញុំនឹងយកកន្លែងផ្ទុកឯកសារពពកអរូបី នោះគឺជា analogue មួយចំនួននៃ OwnCloud, OneDrive និងដូច្នេះនៅលើ។

រូបភាពស្តង់ដារនៃសៀគ្វីបែបនេះគឺនៅខាងក្រោមប៉ុន្តែវាគ្រាន់តែបង្ហាញពីភាពស្មុគស្មាញនៃប្រព័ន្ធ។ យ៉ាងណាមិញ យើងត្រូវធ្វើសមកាលកម្មសេវាកម្មខ្លះ។ តើមានអ្វីកើតឡើងប្រសិនបើអ្នកប្រើរក្សាទុកឯកសារពីកុំព្យូទ័របន្ទះហើយបន្ទាប់មកចង់មើលវាពីទូរស័ព្ទ?

ភាពខុសគ្នារវាងវិធីសាស្រ្ត៖ នៅក្នុងការធ្វើមាត្រដ្ឋានបញ្ឈរ យើងត្រៀមខ្លួនជាស្រេចដើម្បីបង្កើនថាមពលនៃថ្នាំង ហើយនៅក្នុងការធ្វើមាត្រដ្ឋានផ្តេក យើងត្រៀមខ្លួនបន្ថែមថ្នាំងថ្មីដើម្បីចែកចាយបន្ទុក។

CQRS

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

ប្រាក់រង្វាន់ដំបូងនៃវិធីសាស្រ្តនេះគឺសមត្ថភាពក្នុងការបំបែកការតភ្ជាប់ (ក្នុងន័យទូលំទូលាយនៃពាក្យ) ខណៈពេលដែលប្រតិបត្តិសំណើដ៏វែងមួយ។ ជាឧទាហរណ៍ ចូរយើងយកលំដាប់ស្ដង់ដារច្រើន ឬតិច៖

អតិថិជនបានផ្ញើសំណើទៅម៉ាស៊ីនមេ។
ម៉ាស៊ីនមេបានចាប់ផ្តើមដំណើរការរយៈពេលយូរ។
ម៉ាស៊ីនមេបានឆ្លើយតបទៅអតិថិជនជាមួយនឹងលទ្ធផល។

ចូរយើងស្រមៃថានៅក្នុងចំណុចទី 2 ការតភ្ជាប់ត្រូវបានខូច (ឬបណ្តាញបានភ្ជាប់ឡើងវិញ ឬអ្នកប្រើប្រាស់បានទៅទំព័រផ្សេងទៀតដោយបំបែកការតភ្ជាប់)។ ក្នុងករណីនេះ វានឹងពិបាកសម្រាប់ម៉ាស៊ីនមេក្នុងការផ្ញើការឆ្លើយតបទៅកាន់អ្នកប្រើប្រាស់ជាមួយនឹងព័ត៌មានអំពីអ្វីដែលពិតប្រាកដត្រូវបានដំណើរការ។ ដោយប្រើ CQRS លំដាប់នឹងខុសគ្នាបន្តិច៖

អតិថិជនបានជាវព័ត៌មានថ្មីៗ។
អតិថិជនបានផ្ញើសំណើទៅម៉ាស៊ីនមេ។
ម៉ាស៊ីនមេបានឆ្លើយតបថា "បានទទួលយកសំណើ" ។
ម៉ាស៊ីនមេបានឆ្លើយតបជាមួយនឹងលទ្ធផលតាមរយៈឆានែលពីចំណុច "1" ។

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

គួរឱ្យចាប់អារម្មណ៍ កូដសម្រាប់ដំណើរការសារចូលគឺដូចគ្នា (មិនមែន 100%) ទាំងសម្រាប់ព្រឹត្តិការណ៍ដែលត្រូវបានជះឥទ្ធិពលដោយអតិថិជនខ្លួនវា និងសម្រាប់ព្រឹត្តិការណ៍ផ្សេងទៀត រួមទាំងអ្នកដែលមកពីអតិថិជនផ្សេងទៀត។

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

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

ប្រភពព្រឹត្តិការណ៍

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

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

វាជាការសំខាន់ក្នុងការយល់ថាសម្រាប់មូលដ្ឋានទិន្នន័យបុរាណវាត្រូវបានគេប្រើជាញឹកញាប់ ភាពជាប់លាប់ខ្លាំងដែលជាកន្លែងដែលថ្នាំងនីមួយៗមានព័ត៌មានដូចគ្នា (ជារឿយៗវាត្រូវបានសម្រេចក្នុងករណីដែលប្រតិបត្តិការត្រូវបានចាត់ទុកថាត្រូវបានបង្កើតឡើងតែបន្ទាប់ពីម៉ាស៊ីនមេទីពីរឆ្លើយតប)។ មានការសម្រាកខ្លះនៅទីនេះ ដោយសារកម្រិតនៃភាពឯកោ ប៉ុន្តែគំនិតទូទៅនៅតែដដែល - អ្នកអាចរស់នៅក្នុងពិភពលោកដែលចុះសម្រុងគ្នាទាំងស្រុង។

ទោះយ៉ាងណាក៏ដោយ ចូរយើងត្រឡប់ទៅកិច្ចការដើមវិញ។ ប្រសិនបើផ្នែកនៃប្រព័ន្ធអាចត្រូវបានសាងសង់ជាមួយ ភាពស្ថិតស្ថេរជាយថាហេតុបន្ទាប់មកយើងអាចបង្កើតដ្យាក្រាមខាងក្រោម។

លក្ខណៈសំខាន់ៗនៃវិធីសាស្រ្តនេះ៖

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

ខ្ញុំសូមរំលឹកអ្នកថាយើងកំពុងពិចារណាករណីនៃការផ្ទុកឯកសារអនឡាញ។ ក្នុងករណីនេះ ប្រព័ន្ធនឹងមើលទៅដូចនេះ៖

វាមានសារៈសំខាន់ដែលថាសេវាកម្មនៅក្នុងដ្យាក្រាមមិនមានន័យថាម៉ាស៊ីនមេដាច់ដោយឡែកនោះទេ។ សូម្បីតែដំណើរការក៏អាចដូចគ្នាដែរ។ រឿងមួយទៀតគឺសំខាន់៖ តាមមនោគមវិជ្ជា រឿងទាំងនេះត្រូវបានបំបែកចេញតាមរបៀបដែលការធ្វើមាត្រដ្ឋានផ្ដេកអាចត្រូវបានអនុវត្តយ៉ាងងាយស្រួល។

ហើយសម្រាប់អ្នកប្រើពីរនាក់ ដ្យាក្រាមនឹងមើលទៅដូចនេះ (សេវាដែលមានបំណងសម្រាប់អ្នកប្រើផ្សេងគ្នាត្រូវបានបង្ហាញជាពណ៌ផ្សេងគ្នា)៖

ប្រាក់រង្វាន់ពីការរួមបញ្ចូលគ្នាបែបនេះ៖

សេវាកម្មដំណើរការព័ត៌មានត្រូវបានបំបែក។ ជួរក៏ត្រូវបានបំបែកផងដែរ។ ប្រសិនបើយើងត្រូវការបង្កើនដំណើរការប្រព័ន្ធ នោះយើងគ្រាន់តែត្រូវការបើកដំណើរការសេវាកម្មបន្ថែមនៅលើម៉ាស៊ីនមេបន្ថែមទៀត។
នៅពេលដែលយើងទទួលបានព័ត៌មានពីអ្នកប្រើប្រាស់ យើងមិនចាំបាច់រង់ចាំរហូតដល់ទិន្នន័យត្រូវបានរក្សាទុកទាំងស្រុងនោះទេ។ ផ្ទុយទៅវិញ យើងគ្រាន់តែត្រូវឆ្លើយថា "យល់ព្រម" ហើយបន្ទាប់មកចាប់ផ្តើមធ្វើការបន្តិចម្តងៗ។ ក្នុងពេលជាមួយគ្នានោះ ជួរនឹងឡើងដល់កំពូល ដោយហេតុថាការបន្ថែមវត្ថុថ្មីកើតឡើងយ៉ាងឆាប់រហ័ស ហើយអ្នកប្រើប្រាស់មិនចាំបាច់រង់ចាំការឆ្លងកាត់ពេញលេញនៃវដ្តទាំងមូលនោះទេ។
ជាឧទាហរណ៍ ខ្ញុំបានបន្ថែមសេវាកម្មដកស្ទួន ដែលព្យាយាមបញ្ចូលឯកសារដូចគ្នាបេះបិទ។ ប្រសិនបើវាដំណើរការរយៈពេលយូរក្នុង 1% នៃករណីនោះ អតិថិជននឹងពិបាកកត់សម្គាល់វា (សូមមើលខាងលើ) ដែលជាការបូកធំមួយ ដោយសារយើងលែងត្រូវការល្បឿន និងអាចទុកចិត្តបាន XNUMX% ទៀតហើយ។

ទោះយ៉ាងណាក៏ដោយ គុណវិបត្តិអាចមើលឃើញភ្លាមៗ៖

ប្រព័ន្ធរបស់យើងបានបាត់បង់ភាពស្ថិតស្ថេរដ៏តឹងរឹងរបស់វា។ នេះមានន័យថា ជាឧទាហរណ៍ ប្រសិនបើអ្នកជាវសេវាកម្មផ្សេងៗ នោះតាមទ្រឹស្តី អ្នកអាចទទួលបានស្ថានភាពផ្សេង (ចាប់តាំងពីសេវាមួយក្នុងចំណោមសេវាកម្មប្រហែលជាមិនមានពេលទទួលការជូនដំណឹងពីជួរខាងក្នុងទេ)។ ជាផលវិបាកមួយទៀត ប្រព័ន្ធឥឡូវនេះមិនមានពេលវេលាធម្មតាទេ។ នោះគឺវាមិនអាចទៅរួចទេ ជាឧទាហរណ៍ ដើម្បីតម្រៀបព្រឹត្តិការណ៍ទាំងអស់ដោយសាមញ្ញតាមពេលវេលាមកដល់ ចាប់តាំងពីម៉ោងរវាងម៉ាស៊ីនមេអាចនឹងមិនធ្វើសមកាលកម្ម (លើសពីនេះទៅទៀត ពេលវេលាដូចគ្នានៅលើម៉ាស៊ីនមេពីរគឺជាយូធូប)។
ឥឡូវនេះមិនមានព្រឹត្តិការណ៍ណាមួយអាចត្រូវបានវិលត្រឡប់មកវិញទេ (ដូចដែលអាចធ្វើបានជាមួយនឹងមូលដ្ឋានទិន្នន័យ)។ ជំនួសមកវិញ អ្នកត្រូវបន្ថែមព្រឹត្តិការណ៍ថ្មី − ព្រឹត្តិការណ៍សំណងដែលនឹងផ្លាស់ប្តូរស្ថានភាពចុងក្រោយទៅរដ្ឋដែលត្រូវការ។ ជាឧទាហរណ៍ពីតំបន់ស្រដៀងគ្នា៖ ដោយមិនចាំបាច់សរសេរប្រវត្តិឡើងវិញ (ដែលមិនល្អក្នុងករណីខ្លះ) អ្នកមិនអាចត្រលប់មកវិញនូវការសន្យានៅក្នុង git ប៉ុន្តែអ្នកអាចបង្កើតពិសេស rollback ប្តេជ្ញាដែលសំខាន់គ្រាន់តែត្រឡប់ស្ថានភាពចាស់។ ទោះយ៉ាងណាក៏ដោយ ទាំងការប្រព្រឹត្តខុស និងការវិលត្រឡប់មកវិញនឹងនៅតែមាននៅក្នុងប្រវត្តិសាស្ត្រ។
គ្រោងការណ៍ទិន្នន័យអាចផ្លាស់ប្តូរពីការចេញផ្សាយទៅជាការចេញផ្សាយ ប៉ុន្តែព្រឹត្តិការណ៍ចាស់ៗនឹងមិនអាចត្រូវបានធ្វើបច្ចុប្បន្នភាពទៅស្តង់ដារថ្មីទៀតទេ (ចាប់តាំងពីព្រឹត្តិការណ៍មិនអាចផ្លាស់ប្តូរជាគោលការណ៍)។

ដូចដែលអ្នកអាចមើលឃើញ ការរៀបចំព្រឹត្តិការណ៍ដំណើរការល្អជាមួយ CQRS ។ ជាងនេះទៅទៀត ការអនុវត្តប្រព័ន្ធជាមួយនឹងជួរដ៏មានប្រសិទ្ធភាព និងងាយស្រួល ប៉ុន្តែដោយគ្មានការបំបែកលំហូរទិន្នន័យគឺពិបាករួចទៅហើយ ព្រោះអ្នកនឹងត្រូវបន្ថែមចំណុចធ្វើសមកាលកម្មដែលនឹងបន្សាបឥទ្ធិពលវិជ្ជមានទាំងមូលនៃជួរ។ អនុវត្តវិធីសាស្រ្តទាំងពីរក្នុងពេលតែមួយ វាចាំបាច់ក្នុងការកែសម្រួលកូដកម្មវិធីបន្តិច។ ក្នុងករណីរបស់យើង ពេលផ្ញើឯកសារទៅម៉ាស៊ីនមេ ការឆ្លើយតបមកតែ "យល់ព្រម" ដែលមានន័យថា "ប្រតិបត្តិការបន្ថែមឯកសារត្រូវបានរក្សាទុក"។ ជាផ្លូវការ នេះមិនមានន័យថាទិន្នន័យមានរួចហើយនៅលើឧបករណ៍ផ្សេងទៀតទេ (ឧទាហរណ៍ សេវាដកស្ទួនអាចបង្កើតលិបិក្រមឡើងវិញ)។ ទោះយ៉ាងណាក៏ដោយ បន្ទាប់ពីពេលខ្លះ អតិថិជននឹងទទួលបានការជូនដំណឹងនៅក្នុងរចនាប័ទ្មនៃ "ឯកសារ X ត្រូវបានរក្សាទុក" ។

ជាលទ្ធផល:

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

ការឆ្លុះ

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

បំបែកឯកសារតាមប្រភេទ។ ឧទាហរណ៍ រូបភាព/វីដេអូ អាចត្រូវបានឌិកូដ ហើយទម្រង់ដែលមានប្រសិទ្ធភាពជាងអាចត្រូវបានជ្រើសរើស។
បែងចែកគណនីតាមប្រទេស។ ដោយសារតែច្បាប់ជាច្រើន នេះអាចនឹងត្រូវបានទាមទារ ប៉ុន្តែគ្រោងការណ៍ស្ថាបត្យកម្មនេះផ្តល់នូវឱកាសបែបនេះដោយស្វ័យប្រវត្តិ

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

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

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

ដូច្នេះ ការបន្តឧទាហរណ៍របស់យើងអំពីការផ្ទុកតាមអ៊ីនធឺណិតសម្រាប់ឯកសារ ស្ថាបត្យកម្មបែបនេះផ្តល់ឱ្យយើងនូវប្រាក់រង្វាន់មួយចំនួនរួចហើយ៖

យើងអាចផ្លាស់ទីវត្ថុទៅជិតអ្នកប្រើក្នុងរបៀបថាមវន្ត។ វិធីនេះអ្នកអាចកែលម្អគុណភាពនៃសេវាកម្ម។
យើងអាចរក្សាទុកទិន្នន័យមួយចំនួននៅក្នុងក្រុមហ៊ុន។ ឧទាហរណ៍ អ្នកប្រើប្រាស់សហគ្រាសជារឿយៗតម្រូវឱ្យផ្ទុកទិន្នន័យរបស់ពួកគេនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យដែលបានគ្រប់គ្រង (ដើម្បីជៀសវាងការលេចធ្លាយទិន្នន័យ)។ តាមរយៈ sharding យើងអាចគាំទ្រវាបានយ៉ាងងាយស្រួល។ ហើយកិច្ចការកាន់តែងាយស្រួលប្រសិនបើអតិថិជនមានពពកដែលត្រូវគ្នា (ឧទាហរណ៍ Azure រៀបចំដោយខ្លួនឯង។).
ហើយអ្វីដែលសំខាន់បំផុតនោះគឺយើងមិនត្រូវធ្វើបែបនេះទេ។ យ៉ាងណាមិញ ដើម្បីចាប់ផ្តើម យើងនឹងសប្បាយចិត្តជាមួយនឹងទំហំផ្ទុកមួយសម្រាប់គណនីទាំងអស់ (ដើម្បីចាប់ផ្តើមដំណើរការបានយ៉ាងឆាប់រហ័ស)។ ហើយលក្ខណៈពិសេសសំខាន់នៃប្រព័ន្ធនេះគឺថាទោះបីជាវាអាចពង្រីកបានក៏ដោយនៅដំណាក់កាលដំបូងវាគឺសាមញ្ញណាស់។ អ្នកគ្រាន់តែមិនចាំបាច់សរសេរកូដភ្លាមៗ ដែលដំណើរការជាមួយជួរឯករាជ្យរាប់លានដាច់ដោយឡែក។ល។ បើចាំបាច់ នេះអាចត្រូវបានធ្វើនៅពេលអនាគត។

ការបង្ហោះមាតិកាឋិតិវន្ត

ចំណុចនេះហាក់ដូចជាច្បាស់ណាស់ ប៉ុន្តែវានៅតែចាំបាច់សម្រាប់កម្មវិធីដែលផ្ទុកច្រើន ឬតិចជាងស្តង់ដារ។ ខ្លឹមសាររបស់វាគឺសាមញ្ញ៖ មាតិកាឋិតិវន្តទាំងអស់ត្រូវបានចែកចាយមិនមែនមកពីម៉ាស៊ីនមេតែមួយដែលកម្មវិធីមានទីតាំងនៅនោះទេ ប៉ុន្តែមកពីកម្មវិធីពិសេសដែលឧទ្ទិសជាពិសេសចំពោះកិច្ចការនេះ។ ជាលទ្ធផល ប្រតិបត្តិការទាំងនេះត្រូវបានអនុវត្តលឿនជាងមុន ( nginx តាមលក្ខខណ្ឌបម្រើឯកសារលឿនជាង និងមានតម្លៃថោកជាងម៉ាស៊ីនមេ Java )។ បូកនឹងស្ថាបត្យកម្ម CDN (បណ្តាញចែកចាយមាតិកា។) អនុញ្ញាតឱ្យយើងកំណត់ទីតាំងឯកសាររបស់យើងកាន់តែជិតអ្នកប្រើប្រាស់ចុងក្រោយ ដែលមានឥទ្ធិពលវិជ្ជមានទៅលើភាពងាយស្រួលនៃការធ្វើការជាមួយសេវាកម្ម។

ឧទាហរណ៍សាមញ្ញបំផុត និងស្តង់ដារបំផុតនៃមាតិកាឋិតិវន្ត គឺជាសំណុំនៃស្គ្រីប និងរូបភាពសម្រាប់គេហទំព័រមួយ។ អ្វីគ្រប់យ៉ាងគឺសាមញ្ញជាមួយពួកគេ - ពួកគេត្រូវបានគេស្គាល់ជាមុន បន្ទាប់មកប័ណ្ណសារត្រូវបានផ្ទុកឡើងទៅកាន់ម៉ាស៊ីនមេ CDN ពីកន្លែងដែលពួកគេត្រូវបានចែកចាយដល់អ្នកប្រើប្រាស់ចុងក្រោយ។

ទោះយ៉ាងណាក៏ដោយតាមការពិត សម្រាប់ខ្លឹមសារឋិតិវន្ត អ្នកអាចប្រើវិធីសាស្រ្តស្រដៀងនឹងស្ថាបត្យកម្ម lambda ។ ចូរយើងត្រលប់ទៅភារកិច្ចរបស់យើង (ការផ្ទុកឯកសារតាមអ៊ីនធឺណិត) ដែលយើងត្រូវចែកចាយឯកសារដល់អ្នកប្រើប្រាស់។ ដំណោះស្រាយដ៏សាមញ្ញបំផុតគឺបង្កើតសេវាកម្មដែលតាមសំណើរបស់អ្នកប្រើនីមួយៗធ្វើការត្រួតពិនិត្យចាំបាច់ទាំងអស់ (ការអនុញ្ញាត។ល។) ហើយបន្ទាប់មកទាញយកឯកសារដោយផ្ទាល់ពីកន្លែងផ្ទុករបស់យើង។ គុណវិបត្តិចម្បងនៃវិធីសាស្រ្តនេះគឺថាមាតិកាឋិតិវន្ត (និងឯកសារដែលមានការកែប្រែជាក់លាក់មួយគឺជាការពិតមាតិកាឋិតិវន្ត) ត្រូវបានចែកចាយដោយម៉ាស៊ីនមេដូចគ្នាដែលមានតក្កវិជ្ជាអាជីវកម្ម។ ជំនួសមកវិញ អ្នកអាចបង្កើតដ្យាក្រាមខាងក្រោម៖

ម៉ាស៊ីនមេផ្តល់ URL ទាញយក។ វាអាចជាទម្រង់ file_id + key ដែលកូនសោគឺជាហត្ថលេខាឌីជីថលខ្នាតតូចដែលផ្តល់សិទ្ធិក្នុងការចូលប្រើធនធានសម្រាប់រយៈពេល 24 ម៉ោងបន្ទាប់។
ឯកសារត្រូវបានចែកចាយដោយ nginx សាមញ្ញជាមួយនឹងជម្រើសដូចខាងក្រោមៈ
- ការរក្សាទុកមាតិកា។ ដោយសារសេវាកម្មនេះអាចមានទីតាំងនៅលើម៉ាស៊ីនមេដាច់ដោយឡែក យើងបានទុកខ្លួនយើងជាទុនបម្រុងសម្រាប់អនាគតជាមួយនឹងសមត្ថភាពក្នុងការរក្សាទុកឯកសារដែលបានទាញយកចុងក្រោយបំផុតទាំងអស់នៅលើថាស។
- ការពិនិត្យមើលសោនៅពេលបង្កើតការតភ្ជាប់
ស្រេចចិត្ត៖ ដំណើរការមាតិកាស្ទ្រីម។ ឧទាហរណ៍ ប្រសិនបើយើងបង្ហាប់ឯកសារទាំងអស់នៅក្នុងសេវាកម្ម នោះយើងអាចធ្វើការពន្លាដោយផ្ទាល់នៅក្នុងម៉ូឌុលនេះ។ ជាលទ្ធផល៖ ប្រតិបត្តិការ IO ត្រូវបានធ្វើនៅកន្លែងដែលពួកគេជាកម្មសិទ្ធិ។ បណ្ណសារនៅក្នុង Java នឹងងាយស្រួលបែងចែកអង្គចងចាំបន្ថែមជាច្រើន ប៉ុន្តែការសរសេរសេវាកម្មឡើងវិញជាមួយនឹងតក្កវិជ្ជាអាជីវកម្មទៅក្នុងលក្ខខណ្ឌ Rust/C++ ក៏អាចគ្មានប្រសិទ្ធភាពដែរ។ ក្នុងករណីរបស់យើង ដំណើរការផ្សេងៗគ្នា (ឬសូម្បីតែសេវាកម្ម) ត្រូវបានប្រើប្រាស់ ហើយដូច្នេះយើងអាចបែងចែកតក្កវិជ្ជាអាជីវកម្ម និងប្រតិបត្តិការ IO យ៉ាងមានប្រសិទ្ធភាព។

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

ជាឧទាហរណ៍មួយផ្សេងទៀត (សម្រាប់ការពង្រឹង): ប្រសិនបើអ្នកបានធ្វើការជាមួយ Jenkins/TeamCity នោះអ្នកដឹងថាដំណោះស្រាយទាំងពីរត្រូវបានសរសេរជាភាសាចាវ៉ា។ ពួកគេទាំងពីរគឺជាដំណើរការ Java ដែលគ្រប់គ្រងទាំងការបង្កើត orchestration និងការគ្រប់គ្រងមាតិកា។ ជាពិសេស ពួកគេទាំងពីរមានភារកិច្ចដូចជា "ផ្ទេរឯកសារ/ថតឯកសារពីម៉ាស៊ីនមេ"។ ជាឧទាហរណ៍៖ ការចេញវត្ថុបុរាណ ការផ្ទេរកូដប្រភព (នៅពេលដែលភ្នាក់ងារមិនទាញយកកូដដោយផ្ទាល់ពីឃ្លាំង ប៉ុន្តែម៉ាស៊ីនមេធ្វើវាសម្រាប់គាត់) ការចូលប្រើកំណត់ហេតុ។ ភារកិច្ចទាំងអស់នេះខុសគ្នានៅក្នុងបន្ទុក IO របស់ពួកគេ។ នោះគឺវាប្រែថាម៉ាស៊ីនមេដែលទទួលខុសត្រូវចំពោះតក្កវិជ្ជាអាជីវកម្មស្មុគស្មាញត្រូវតែក្នុងពេលតែមួយអាចជំរុញលំហូរទិន្នន័យដ៏ធំតាមរយៈខ្លួនវាយ៉ាងមានប្រសិទ្ធភាព។ ហើយអ្វីដែលគួរឱ្យចាប់អារម្មណ៍បំផុតនោះគឺថាប្រតិបត្តិការបែបនេះអាចត្រូវបានផ្ទេរទៅ nginx ដូចគ្នាដោយយោងទៅតាមគ្រោងការណ៍ដូចគ្នាយ៉ាងពិតប្រាកដ (លើកលែងតែលេខកូដទិន្នន័យគួរតែត្រូវបានបន្ថែមទៅសំណើ) ។

ទោះយ៉ាងណាក៏ដោយ ប្រសិនបើយើងត្រលប់ទៅប្រព័ន្ធរបស់យើង យើងទទួលបានដ្យាក្រាមស្រដៀងគ្នានេះ៖

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

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

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

វិធីសាស្រ្តទាំងអស់នេះត្រូវបានគេស្គាល់ពីមុន។ VK ដូចគ្នាបានប្រើប្រាស់គំនិតនៃ Static Content Hosting ជាយូរមកហើយដើម្បីបង្ហាញរូបភាព។ ហ្គេមអនឡាញជាច្រើនប្រើគ្រោងការណ៍ Sharding ដើម្បីបែងចែកអ្នកលេងទៅជាតំបន់ ឬដើម្បីបំបែកទីតាំងហ្គេម (ប្រសិនបើពិភពលោកតែមួយ)។ វិធីសាស្រ្តប្រភពព្រឹត្តិការណ៍ត្រូវបានប្រើប្រាស់យ៉ាងសកម្មនៅក្នុងអ៊ីមែល។ កម្មវិធីជួញដូរភាគច្រើនដែលទិន្នន័យត្រូវបានទទួលឥតឈប់ឈរគឺពិតជាត្រូវបានបង្កើតឡើងតាមវិធីសាស្រ្ត CQRS ដើម្បីអាចត្រងទិន្នន័យដែលទទួលបាន។ ជាការប្រសើរណាស់ ការធ្វើមាត្រដ្ឋានផ្ដេកត្រូវបានប្រើប្រាស់ក្នុងសេវាកម្មជាច្រើនអស់រយៈពេលយូរមកហើយ។

ទោះជាយ៉ាងណាក៏ដោយ សំខាន់បំផុត គំរូទាំងអស់នេះបានក្លាយទៅជាការងាយស្រួលបំផុតក្នុងការអនុវត្តនៅក្នុងកម្មវិធីទំនើបៗ (ជាការពិតណាស់ ប្រសិនបើពួកគេសមស្រប)។ Clouds ផ្តល់ជូន Sharding និងការធ្វើមាត្រដ្ឋានផ្ដេកភ្លាមៗ ដែលងាយស្រួលជាងការបញ្ជាម៉ាស៊ីនមេផ្សេងៗគ្នានៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យផ្សេងៗគ្នាដោយខ្លួនឯង។ CQRS កាន់តែងាយស្រួលជាងនេះទៅទៀត ប្រសិនបើមានតែដោយសារការអភិវឌ្ឍន៍បណ្ណាល័យដូចជា RX ប៉ុណ្ណោះ។ ប្រហែលជា 10 ឆ្នាំមុន គេហទំព័រដ៏កម្រមួយអាចគាំទ្ររឿងនេះបាន។ កម្មវិធីប្រភពព្រឹត្តិការណ៍ក៏ងាយស្រួលមិនគួរឱ្យជឿក្នុងការរៀបចំផងដែរ អរគុណចំពោះធុងដែលត្រៀមរួចជាស្រេចជាមួយ Apache Kafka។ កាលពី 10 ឆ្នាំមុន វានឹងក្លាយជាការច្នៃប្រឌិតមួយ ឥឡូវនេះវាជារឿងធម្មតាទៅហើយ។ វាដូចគ្នាជាមួយនឹងការបង្ហោះមាតិកាឋិតិវន្ត៖ ដោយសារតែបច្ចេកវិទ្យាងាយស្រួលជាងមុន (រួមទាំងការពិតដែលថាមានឯកសារលម្អិត និងមូលដ្ឋានទិន្នន័យធំនៃចម្លើយ) វិធីសាស្រ្តនេះកាន់តែសាមញ្ញ។

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

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

ប្រភព: www.habr.com

លំនាំស្ថាបត្យកម្មងាយស្រួល