ប្រវត្តិនៃស្ថាបត្យកម្ម Dodo IS: ដើមមនោរម្យ

ឬរាល់ក្រុមហ៊ុនដែលមិនសប្បាយចិត្តជាមួយ monolith គឺមិនសប្បាយចិត្តនៅក្នុងវិធីរបស់ខ្លួន។

ការអភិវឌ្ឍន៍ប្រព័ន្ធ Dodo IS បានចាប់ផ្តើមភ្លាមៗ ដូចជាអាជីវកម្ម Dodo Pizza ក្នុងឆ្នាំ 2011។ វាត្រូវបានផ្អែកលើគំនិតនៃការពេញលេញនិងឌីជីថលសរុបនៃដំណើរការអាជីវកម្ម, និង ដោយ​ខ្លួន​ពួកគេដែលសូម្បីតែនៅឆ្នាំ 2011 បានបង្កឱ្យមានចម្ងល់ និងការសង្ស័យជាច្រើន។ ប៉ុន្តែអស់រយៈពេល 9 ឆ្នាំមកហើយឥឡូវនេះយើងបានដើរតាមផ្លូវនេះ - ជាមួយនឹងការអភិវឌ្ឍន៍ផ្ទាល់ខ្លួនរបស់យើងដែលបានចាប់ផ្តើមជាមួយនឹង monolith ។

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

ស៊េរីនៃអត្ថបទ "តើ Dodo IS ជាអ្វី?" ប្រាប់អំពី៖

1. Monolith ដំបូងនៅ Dodo IS (2011-2015) ។ (អ្នកនៅទីនេះ)

2. ផ្លូវការិយាល័យខាងក្រោយ៖ មូលដ្ឋានដាច់ដោយឡែក និងឡានក្រុង.

3. ផ្លូវចំហៀងអតិថិជន៖ facade ពីលើមូលដ្ឋាន (2016-2017) ។ (កំពុង​ដំណើរការ…)

4. ប្រវត្តិនៃសេវាកម្មមីក្រូពិត។ (2018-2019)។ (កំពុង​ដំណើរការ...)

5. បានបញ្ចប់ sawing នៃ monolith និងស្ថេរភាពនៃស្ថាបត្យកម្ម។ (កំពុង​ដំណើរការ...)

ស្ថាបត្យកម្មដំបូង

ក្នុងឆ្នាំ 2011 ស្ថាបត្យកម្ម Dodo IS មើលទៅដូចនេះ:

ម៉ូឌុលដំបូងនៅក្នុងស្ថាបត្យកម្មគឺការទទួលយកការបញ្ជាទិញ។ ដំណើរការអាជីវកម្មគឺ៖

• អតិថិជនហៅភីហ្សា;

• អ្នកគ្រប់គ្រងលើកទូរស័ព្ទ;

• ទទួលយកការបញ្ជាទិញតាមទូរស័ព្ទ;

• បំពេញវាស្របគ្នានៅក្នុងចំណុចប្រទាក់ទទួលយកការបញ្ជាទិញ៖ ព័ត៌មានអំពីអតិថិជន ទិន្នន័យអំពីព័ត៌មានលម្អិតនៃការបញ្ជាទិញ អាសយដ្ឋានដឹកជញ្ជូនត្រូវបានយកមកពិចារណា។ 

ចំណុចប្រទាក់នៃប្រព័ន្ធព័ត៌មានមើលទៅដូចនេះ ...

កំណែដំបូងចាប់ពីខែតុលាឆ្នាំ 2011៖

មានភាពប្រសើរឡើងបន្តិចក្នុងខែមករា ឆ្នាំ 2012

ប្រព័ន្ធព័ត៌មាន Dodo Pizza Delivery Pizza Restaurant

ធនធានសម្រាប់ការអភិវឌ្ឍនៃម៉ូឌុលទទួលការបញ្ជាទិញដំបូងត្រូវបានកំណត់។ យើងត្រូវធ្វើច្រើន រហ័ស និងជាមួយក្រុមតូចមួយ។ ក្រុមតូចមួយគឺជាអ្នកអភិវឌ្ឍន៍ 2 នាក់ដែលបានដាក់មូលដ្ឋានគ្រឹះសម្រាប់ប្រព័ន្ធអនាគតទាំងមូល។

ការសម្រេចចិត្តដំបូងរបស់ពួកគេបានកំណត់ជោគវាសនានៃជង់បច្ចេកវិទ្យា៖

• ផ្នែកខាងក្រោយនៅលើ ASP.NET MVC, ភាសា C# ។ អ្នកអភិវឌ្ឍន៍គឺ dotnetchiki ជង់នេះគឺស៊ាំនិងរីករាយចំពោះពួកគេ។

• Frontend នៅលើ Bootstrap និង JQuery៖ ចំណុចប្រទាក់អ្នកប្រើលើរចនាប័ទ្ម និងស្គ្រីបដែលសរសេរដោយខ្លួនឯង។ 

• មូលដ្ឋានទិន្នន័យ MySQL៖ គ្មានថ្លៃអាជ្ញាប័ណ្ណ ងាយស្រួលប្រើ។

• ម៉ាស៊ីនមេនៅលើ Windows Server ដោយសារតែ .NET បន្ទាប់មកអាចស្ថិតនៅក្រោម Windows ប៉ុណ្ណោះ (យើងនឹងមិនពិភាក្សា Mono) ។

រាងកាយ ទាំងអស់នេះត្រូវបានបង្ហាញនៅក្នុង "ឧទ្ទិសដល់ម្ចាស់ផ្ទះ" ។ 

ស្ថាបត្យកម្មកម្មវិធីបញ្ជាទិញ

បន្ទាប់មកអ្នកគ្រប់គ្នាបាននិយាយរួចហើយអំពីសេវាមីក្រូ ហើយ SOA ត្រូវបានប្រើក្នុងគម្រោងធំៗក្នុងរយៈពេល 5 ឆ្នាំ ឧទាហរណ៍ WCF ត្រូវបានចេញផ្សាយក្នុងឆ្នាំ 2006 ។ ប៉ុន្តែបន្ទាប់មកពួកគេបានជ្រើសរើសដំណោះស្រាយដែលអាចទុកចិត្តបាន និងបង្ហាញឱ្យឃើញ។

វា​នៅ​ទីនេះ។

Asp.Net MVC គឺជា Razor ដែលតាមការស្នើសុំពីទម្រង់ ឬពីអតិថិជន បង្ហាញទំព័រ HTML ជាមួយនឹងការបង្ហាញម៉ាស៊ីនមេ។ នៅលើម៉ាស៊ីនភ្ញៀវ ស្គ្រីប CSS និង JS បង្ហាញព័ត៌មានរួចហើយ ហើយប្រសិនបើចាំបាច់ អនុវត្តសំណើ AJAX តាមរយៈ JQuery ។

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

• ឧទាហរណ៍ DepartmentStructureService បានផ្តល់ព័ត៌មានអំពីហាងភីហ្សា លើនាយកដ្ឋាន។ នាយកដ្ឋានគឺជាក្រុមនៃហាងភីហ្សាដែលដំណើរការដោយអ្នកទទួលសិទ្ធិផ្តាច់មុខតែមួយ។

• ReceivingOrdersService បានទទួលយក និងគណនាសមាសភាពនៃការបញ្ជាទិញ។

• ហើយ SmsService បានផ្ញើសារ SMS ដោយហៅទៅសេវាកម្ម API ដើម្បីផ្ញើសារ SMS ។

សេវាកម្មបានដំណើរការទិន្នន័យពីមូលដ្ឋានទិន្នន័យ តក្កវិជ្ជាអាជីវកម្មដែលបានរក្សាទុក។ សេវាកម្មនីមួយៗមានមួយ ឬច្រើន *ឃ្លាំងដែលមានឈ្មោះសមរម្យ។ ពួកវាមានសំណួរសម្រាប់នីតិវិធីដែលបានរក្សាទុកនៅក្នុងមូលដ្ឋានទិន្នន័យ និងស្រទាប់នៃអ្នកធ្វើផែនទីរួចហើយ។ មានតក្កវិជ្ជាអាជីវកម្មនៅក្នុងកន្លែងផ្ទុក ជាពិសេសមានច្រើននៅក្នុងអ្នកដែលចេញទិន្នន័យរបាយការណ៍។ ORM មិនត្រូវបានប្រើទេ មនុស្សគ្រប់គ្នាពឹងផ្អែកលើ sql ដែលសរសេរដោយដៃ។ 

វាក៏មានស្រទាប់នៃគំរូដែន និងថ្នាក់ជំនួយទូទៅផងដែរ ឧទាហរណ៍ ថ្នាក់លំដាប់ដែលរក្សាទុកការបញ្ជាទិញ។ នៅកន្លែងដដែល ក្នុងស្រទាប់មានជំនួយការសម្រាប់បំប្លែងអត្ថបទបង្ហាញទៅតាមរូបិយប័ណ្ណដែលបានជ្រើសរើស។

ទាំងអស់នេះអាចត្រូវបានតំណាងដោយគំរូបែបនេះ:

មធ្យោបាយបញ្ជា

ពិចារណាវិធីដំបូងសាមញ្ញដើម្បីបង្កើតការបញ្ជាទិញបែបនេះ។

ដំបូងគេហទំព័រគឺឋិតិវន្ត។ វាមានតម្លៃនៅលើវា ហើយនៅលើកំពូល - លេខទូរស័ព្ទ និងសិលាចារឹក "ប្រសិនបើអ្នកចង់បានភីហ្សា - ទូរស័ព្ទទៅលេខហើយបញ្ជាទិញ" ។ ដើម្បីបញ្ជា យើងត្រូវអនុវត្តលំហូរសាមញ្ញមួយ៖ 

• អតិថិជនចូលមើលគេហទំព័រឋិតិវន្តជាមួយនឹងតម្លៃ ជ្រើសរើសផលិតផល និងហៅទៅលេខដែលបានរាយនៅលើគេហទំព័រ។

• អតិថិជនដាក់ឈ្មោះផលិតផលដែលពួកគេចង់បន្ថែមទៅក្នុងការបញ្ជាទិញ។

• ផ្តល់អាសយដ្ឋាន និងឈ្មោះរបស់គាត់។

• ប្រតិបត្តិករទទួលយកការបញ្ជាទិញ។

• ការបញ្ជាទិញត្រូវបានបង្ហាញនៅក្នុងចំណុចប្រទាក់ការបញ្ជាទិញដែលបានទទួលយក។

វាទាំងអស់ចាប់ផ្តើមជាមួយនឹងការបង្ហាញម៉ឺនុយ។ ប្រតិបត្តិករអ្នកប្រើប្រាស់ដែលបានចូល ទទួលយកការបញ្ជាទិញតែមួយក្នុងពេលតែមួយ។ ដូច្នេះ រទេះ​ព្រាង​អាច​ត្រូវ​បាន​រក្សា​ទុក​ក្នុង​សម័យ​របស់​គាត់ (សម័យ​របស់​អ្នក​ប្រើ​ត្រូវ​បាន​រក្សា​ទុក​ក្នុង​អង្គ​ចងចាំ)។ មានវត្ថុរទេះដែលមានផលិតផល និងព័ត៌មានអតិថិជន។

អតិថិជនដាក់ឈ្មោះផលិតផល ប្រតិបត្តិករចុចលើ + នៅជាប់នឹងផលិតផល ហើយសំណើត្រូវបានផ្ញើទៅម៉ាស៊ីនមេ។ ព័ត៌មានអំពីផលិតផលត្រូវបានទាញចេញពីមូលដ្ឋានទិន្នន័យ ហើយព័ត៌មានអំពីផលិតផលត្រូវបានបញ្ចូលទៅក្នុងរទេះ។

ការកត់សម្គាល់. បាទ/ចាស នៅទីនេះអ្នកមិនអាចទាញផលិតផលពីមូលដ្ឋានទិន្នន័យបានទេ ប៉ុន្តែផ្ទេរវាពីផ្នែកខាងមុខ។ ប៉ុន្តែ​សម្រាប់​ភាព​ច្បាស់​លាស់ ខ្ញុំ​បាន​បង្ហាញ​ផ្លូវ​យ៉ាង​ច្បាស់​ពី​មូលដ្ឋាន​ទិន្នន័យ។ 

បន្ទាប់មកបញ្ចូលអាសយដ្ឋាន និងឈ្មោះរបស់អតិថិជន។ 

នៅពេលអ្នកចុច "បង្កើតការបញ្ជាទិញ"៖

• សំណើត្រូវបានផ្ញើទៅកាន់ OrderController.SaveOrder()។

• យើងទទួលបានរទេះពីសម័យប្រជុំ មានផលិតផលក្នុងបរិមាណដែលយើងត្រូវការ។

• យើងបំពេញបន្ថែមរទេះជាមួយនឹងព័ត៌មានអំពីអតិថិជន ហើយបញ្ជូនវាទៅវិធីសាស្ត្រ AddOrder នៃថ្នាក់ ReceivingOrderService ដែលវាត្រូវបានរក្សាទុកទៅក្នុងមូលដ្ឋានទិន្នន័យ។ 

• មូលដ្ឋានទិន្នន័យមានតារាងជាមួយនឹងលំដាប់ សមាសភាពនៃការបញ្ជាទិញ អតិថិជន ហើយពួកវាត្រូវបានភ្ជាប់ទាំងអស់។

• ចំណុចប្រទាក់បង្ហាញលំដាប់ទៅ និងទាញការបញ្ជាទិញចុងក្រោយបំផុត ហើយបង្ហាញពួកគេ។

ម៉ូឌុលថ្មី។

ការបញ្ជាទិញមានសារៈសំខាន់ និងចាំបាច់។ អ្នកមិនអាចធ្វើអាជីវកម្មភីហ្សាបានទេ ប្រសិនបើអ្នកមិនមានការបញ្ជាទិញដើម្បីលក់។ ដូច្នេះប្រព័ន្ធបានចាប់ផ្តើមទទួលបានមុខងារ - ប្រហែលពីឆ្នាំ 2012 ដល់ឆ្នាំ 2015 ។ ក្នុងអំឡុងពេលនេះប្លុកផ្សេងគ្នាជាច្រើននៃប្រព័ន្ធបានបង្ហាញខ្លួនដែលខ្ញុំនឹងហៅ ម៉ូឌុលផ្ទុយពីគំនិតនៃសេវាកម្ម ឬផលិតផល។ 

ម៉ូឌុលគឺជាសំណុំនៃមុខងារដែលត្រូវបានបង្រួបបង្រួមដោយគោលដៅអាជីវកម្មទូទៅមួយចំនួន។ ក្នុងពេលជាមួយគ្នានេះពួកគេមានរាងកាយនៅក្នុងកម្មវិធីដូចគ្នា។

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

តាមបច្ចេកទេស ម៉ូឌុលត្រូវបានរចនាឡើងជាតំបន់ (គំនិតបែបនេះនៅតែមាននៅក្នុង ស្នូល asp.net) មានឯកសារដាច់ដោយឡែកសម្រាប់ផ្នែកខាងមុខ ម៉ូដែល ក៏ដូចជាថ្នាក់ឧបករណ៍បញ្ជាផ្ទាល់របស់ពួកគេ។ ជាលទ្ធផលប្រព័ន្ធត្រូវបានផ្លាស់ប្តូរពីនេះ ...

... នៅក្នុងនេះ:

ម៉ូឌុលមួយចំនួនត្រូវបានអនុវត្តដោយគេហទំព័រដាច់ដោយឡែក (គម្រោងដែលអាចប្រតិបត្តិបាន) ដោយសារតែមុខងារដាច់ដោយឡែកទាំងស្រុង និងមួយផ្នែកដោយសារការអភិវឌ្ឍន៍ដែលផ្តោតខ្លាំងជាងដាច់ដោយឡែកបន្តិច។ នេះ៖

• តំបន់បណ្តាញ - កំណែដំបូង គេហទំព័រ dodopizza.ru ។

• ការនាំចេញ៖ ផ្ទុកឡើងរបាយការណ៍ពី Dodo IS សម្រាប់ 1C ។ 

• ផ្ទាល់ខ្លួន - គណនីផ្ទាល់ខ្លួនរបស់និយោជិក។ វាត្រូវបានបង្កើតឡើងដាច់ដោយឡែក និងមានចំណុចចូល និងការរចនាដាច់ដោយឡែក។

• fs - គម្រោងសម្រាប់ការបង្ហោះឋិតិវន្ត។ ក្រោយ​មក យើង​បាន​រើ​ចេញ​ឆ្ងាយ​ពី​វា ដោយ​ផ្លាស់​ទី​ឋិតិវន្ត​ទាំងអស់​ទៅ Akamai CDN ។ 

ប្លុកដែលនៅសល់គឺនៅក្នុងកម្មវិធី BackOffice ។ 

ការ​ពន្យល់​ឈ្មោះ​:

• Cashier - អ្នកគិតលុយភោជនីយដ្ឋាន។

• ShiftManager - ចំណុចប្រទាក់សម្រាប់តួនាទី "កម្មវិធីគ្រប់គ្រងការផ្លាស់ប្តូរ"៖ ស្ថិតិប្រតិបត្តិការលើការលក់ភីហ្សា សមត្ថភាពក្នុងការដាក់ផលិតផលក្នុងបញ្ជីឈប់ ផ្លាស់ប្តូរការបញ្ជាទិញ។

• OfficeManager - ចំណុចប្រទាក់សម្រាប់តួនាទី "Pizzeria Manager" និង "Franchisee" ។ នេះគឺជាមុខងារដែលប្រមូលបានសម្រាប់ការបង្កើតហាងភីហ្សា ការផ្សព្វផ្សាយប្រាក់រង្វាន់ ការទទួល និងធ្វើការជាមួយបុគ្គលិក របាយការណ៍។

• អេក្រង់សាធារណៈ - ចំណុចប្រទាក់សម្រាប់ទូរទស្សន៍ និងថេប្លេតដែលព្យួរនៅក្នុងហាងភីហ្សា។ ទូរទស្សន៍បង្ហាញម៉ឺនុយ ព័ត៌មានផ្សាយពាណិជ្ជកម្ម ស្ថានភាពបញ្ជាទិញនៅពេលចែកចាយ។ 

ពួកគេបានប្រើស្រទាប់សេវាកម្មទូទៅ ប្លុកថ្នាក់ដែន Dodo.Core ទូទៅ និងមូលដ្ឋានរួម។ ពេលខ្លះពួកគេនៅតែអាចដឹកនាំការផ្លាស់ប្តូរទៅគ្នាទៅវិញទៅមក។ រួមទាំងគេហទំព័រផ្ទាល់ខ្លួនដូចជា dodopizza.ru ឬ personal.dodopizza.ru បានទៅសេវាកម្មទូទៅ។

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

សម្រាប់ការយល់ដឹងកាន់តែច្បាស់អំពីមាត្រដ្ឋាននៃម៉ូឌុលដែលបានធ្វើនៅក្នុងប្រព័ន្ធ នេះគឺជាដ្យាក្រាមពីឆ្នាំ 2012 ជាមួយនឹងផែនការអភិវឌ្ឍន៍៖

នៅឆ្នាំ 2015 អ្វីគ្រប់យ៉ាងគឺនៅលើផែនទីហើយសូម្បីតែច្រើនទៀតគឺស្ថិតនៅក្នុងការផលិត។

• ការទទួលយកការបញ្ជាទិញបានរីកចម្រើនទៅជាប្លុកដាច់ដោយឡែកនៃមជ្ឈមណ្ឌលទំនាក់ទំនង ដែលការបញ្ជាទិញត្រូវបានទទួលយកដោយប្រតិបត្តិករ។

• មានអេក្រង់សាធារណៈដែលមានម៉ឺនុយ និងព័ត៌មានព្យួរនៅក្នុងហាងភីហ្សា។

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

• អង្គភាពដឹកជញ្ជូនបានក្លាយទៅជាកន្លែងត្រួតពិនិត្យការដឹកជញ្ជូនដាច់ដោយឡែក ដែលការបញ្ជាទិញត្រូវបានចេញឱ្យទៅអ្នកនាំសំបុត្រដែលបានធ្វើការផ្លាស់ប្តូរពីមុន។ ពេលវេលាធ្វើការរបស់គាត់ត្រូវបានយកមកគិតក្នុងការគណនាប្រាក់បៀវត្សរ៍។ 

ស្របគ្នា ពីឆ្នាំ 2012 ដល់ឆ្នាំ 2015 អ្នកអភិវឌ្ឍន៍ជាង 10 នាក់បានបង្ហាញខ្លួន ហាងភីហ្សាចំនួន 35 បានបើក ពង្រាយប្រព័ន្ធនេះទៅកាន់ប្រទេសរ៉ូម៉ានី និងរៀបចំសម្រាប់ការបើកហាងនៅសហរដ្ឋអាមេរិក។ អ្នកអភិវឌ្ឍន៍លែងដោះស្រាយរាល់កិច្ចការទាំងអស់ទៀតហើយ ប៉ុន្តែត្រូវបានបែងចែកទៅជាក្រុម។ នីមួយៗមានឯកទេសនៅក្នុងផ្នែករបស់ខ្លួននៃប្រព័ន្ធ។ 

បញ្ហា

រួមទាំងដោយសារតែស្ថាបត្យកម្ម (ប៉ុន្តែមិនត្រឹមតែប៉ុណ្ណោះ) ។

ភាពវឹកវរនៅក្នុងមូលដ្ឋាន

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

ប៉ុន្តែក្នុងរយៈពេលជាង 4 ឆ្នាំនៃការអភិវឌ្ឍន៍ មូលដ្ឋានទិន្នន័យបានប្រែទៅជាមានប្រហែល 600 តារាង 1500 នីតិវិធីត្រូវបានរក្សាទុក ដែលភាគច្រើនក៏មានតក្កវិជ្ជាផងដែរ។ Alas, នីតិវិធីដែលបានរក្សាទុកមិននាំមកនូវអត្ថប្រយោជន៍ច្រើនទេនៅពេលធ្វើការជាមួយ MySQL ។ ពួកវាមិនត្រូវបានទុកក្នុងឃ្លាំងសម្ងាត់ដោយមូលដ្ឋានទេ ហើយការរក្សាទុកតក្កវិជ្ជានៅក្នុងពួកវាធ្វើឱ្យមានភាពស្មុគស្មាញដល់ការអភិវឌ្ឍន៍ និងការបំបាត់កំហុស។ ការប្រើលេខកូដឡើងវិញក៏ពិបាកដែរ។

តារាងជាច្រើនមិនមានសន្ទស្សន៍សមស្របទេ។នៅកន្លែងណាមួយ ផ្ទុយទៅវិញ មានលិបិក្រមជាច្រើន ដែលធ្វើឱ្យវាពិបាកក្នុងការបញ្ចូល។ វាចាំបាច់ក្នុងការកែប្រែតារាងប្រហែល 20 - ប្រតិបត្តិការដើម្បីបង្កើតការបញ្ជាទិញអាចចំណាយពេលប្រហែល 3-5 វិនាទី។ 

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

ទៅតុដូចគ្នាត្រូវបានផលិតយ៉ាងខ្លាំង សំណើផ្សេងៗគ្នា. តារាងពេញនិយមទទួលរងការឈឺចាប់ជាពិសេសដូចជាតារាងដែលបានរៀបរាប់ខាងលើ។ ការបញ្ជាទិញ ឬតុ ភីហ្សា. ពួកវាត្រូវបានប្រើដើម្បីបង្ហាញចំណុចប្រទាក់ប្រតិបត្តិការនៅក្នុងផ្ទះបាយ ការវិភាគ។ គេហទំព័រមួយផ្សេងទៀតបានទាក់ទងពួកគេ (dodopizza.ru) ដែលនៅពេលណាមួយ សំណើជាច្រើនអាចមកភ្លាមៗ។ 

ទិន្នន័យមិនត្រូវបានប្រមូលផ្តុំទេ។ ហើយការគណនាជាច្រើនបានកើតឡើងភ្លាមៗដោយប្រើមូលដ្ឋាន។ នេះបានបង្កើតការគណនាដែលមិនចាំបាច់ និងបន្ទុកបន្ថែម។ 

ជាញឹកញាប់កូដបានទៅមូលដ្ឋានទិន្នន័យ នៅពេលដែលវាមិនអាចធ្វើបាន។ នៅកន្លែងណាមួយមិនមានប្រតិបត្តិការច្រើនគ្រប់គ្រាន់ កន្លែងណាមួយវាចាំបាច់ដើម្បីផ្សព្វផ្សាយសំណើមួយទៅជាច្រើនតាមរយៈកូដ ដើម្បីបង្កើនល្បឿន និងបង្កើនភាពជឿជាក់។ 

ភាពស្អិតរមួត និងច្របូកច្របល់ក្នុងកូដ

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

សេវាកម្ម (ថ្នាក់នៅក្នុងគម្រោងធំ monolithic មួយ) អាចហៅគ្នាទៅវិញទៅមកដើម្បីបង្កើនទិន្នន័យរបស់ពួកគេ។

ជាមួយនឹងថ្នាក់គំរូខ្លួនឯងដែលផ្ទុកទិន្នន័យ, ការងារនៅក្នុងកូដត្រូវបានអនុវត្តខុសគ្នា. នៅកន្លែងណាមួយមានអ្នកសាងសង់ ដែលអាចបញ្ជាក់វាលដែលត្រូវការ។ កន្លែងណាមួយនេះត្រូវបានធ្វើតាមរយៈទ្រព្យសម្បត្តិសាធារណៈ។ ជា​ការ​ពិត​ណាស់ ការ​ទទួល​និង​បំប្លែង​ទិន្នន័យ​ពី​មូលដ្ឋាន​ទិន្នន័យ​មាន​ភាព​ខុស​គ្នា​។ 

តក្កវិជ្ជាគឺនៅក្នុងឧបករណ៍បញ្ជា ឬនៅក្នុងថ្នាក់សេវាកម្ម។ 

ទាំងនេះហាក់ដូចជាបញ្ហាតូចតាច ប៉ុន្តែវាបានពន្យឺតការអភិវឌ្ឍន៍យ៉ាងខ្លាំង និងកាត់បន្ថយគុណភាព ដែលនាំឱ្យមានអស្ថិរភាព និងកំហុស។ 

ភាពស្មុគស្មាញនៃការអភិវឌ្ឍន៍ដ៏ធំមួយ

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

នៅក្នុងផ្នែកខ្លះនៃប្រព័ន្ធ មូលដ្ឋានទិន្នន័យដែលសមស្របជាងនេះអាចត្រូវបានប្រើប្រាស់។. ជាឧទាហរណ៍ ក្រោយមកយើងមានករណីប្រើប្រាស់នៃការផ្លាស់ប្តូរពី Redis ទៅ CosmosDB ដើម្បីរក្សាទុកកញ្ចប់បញ្ជាទិញ។ 

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

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

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

របៀបដែលប្លក់ថាមពលនៃចិត្តដាក់ការចុះឈ្មោះសាច់ប្រាក់នៅក្នុងភោជនីយដ្ឋាន

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

នៅក្នុងប្លុក "កម្លាំងចិត្ត” គឺជាធាតុក្រាហ្វិកដែលបង្ហាញទិន្នន័យស្តីពីប្រាក់ចំណូលសម្រាប់ឆ្នាំនៃបណ្តាញទាំងមូល។ ធាតុក្រាហ្វិកបានចូលប្រើ Dodo public API ដែលផ្តល់ទិន្នន័យនេះ។ ស្ថិតិនេះបច្ចុប្បន្នមាននៅ http://dodopizzastory.com/. ធាតុក្រាហ្វិកត្រូវបានបង្ហាញនៅគ្រប់ទំព័រ ហើយបានស្នើសុំនៅលើកម្មវិធីកំណត់ម៉ោងរៀងរាល់ 20 វិនាទី។ សំណើបានទៅ api.dodopizza.ru ហើយបានស្នើសុំ៖

• ចំនួនភីហ្សានៅក្នុងបណ្តាញ;

• ប្រាក់ចំណូលបណ្តាញសរុបចាប់តាំងពីដើមឆ្នាំ;

• ប្រាក់ចំណូលសម្រាប់ថ្ងៃនេះ។

សំណើសម្រាប់ស្ថិតិស្តីពីប្រាក់ចំណូលបានទៅមូលដ្ឋានទិន្នន័យដោយផ្ទាល់ ហើយបានចាប់ផ្តើមស្នើសុំទិន្នន័យលើការបញ្ជាទិញ ប្រមូលផ្តុំទិន្នន័យភ្លាមៗ និងផ្តល់ចំនួន។ 

តុសាច់ប្រាក់នៅក្នុងភោជនីយដ្ឋានបានទៅតារាងការបញ្ជាទិញដូចគ្នា ដោះបញ្ជីនៃការបញ្ជាទិញដែលបានទទួលសម្រាប់ថ្ងៃនេះ ហើយការបញ្ជាទិញថ្មីត្រូវបានបន្ថែមទៅវា។ ការចុះឈ្មោះសាច់ប្រាក់បានធ្វើសំណើរបស់ពួកគេរៀងរាល់ 5 វិនាទី ឬនៅលើទំព័រឡើងវិញ។

ដ្យាក្រាមមើលទៅដូចនេះ៖

ការដួលរលំមួយ Fyodor Ovchinnikov បានសរសេរអត្ថបទដ៏វែងនិងពេញនិយមនៅលើប្លក់របស់គាត់។ មនុស្ស​ជា​ច្រើន​បាន​ចូល​មក​ប្លុក ហើយ​ចាប់​ផ្ដើម​អាន​គ្រប់​យ៉ាង​ដោយ​យក​ចិត្ត​ទុក​ដាក់។ ខណៈពេលដែលមនុស្សម្នាក់ៗដែលបានមកកំពុងអានអត្ថបទ ធាតុក្រាហ្វិកចំណូលដំណើរការបានត្រឹមត្រូវ និងស្នើសុំ API រៀងរាល់ 20 វិនាទី។

API បានហៅនីតិវិធីដែលបានរក្សាទុកដើម្បីគណនាផលបូកនៃការបញ្ជាទិញទាំងអស់ចាប់តាំងពីដើមឆ្នាំសម្រាប់ហាងភីហ្សាទាំងអស់នៅក្នុងសង្វាក់។ ការប្រមូលផ្តុំគឺផ្អែកលើតារាងបញ្ជាទិញ ដែលមានប្រជាប្រិយភាពខ្លាំង។ តុសាច់ប្រាក់ទាំងអស់នៃភោជនីយដ្ឋានដែលបើកទាំងអស់នៅពេលនោះទៅវា។ តុសាច់ប្រាក់បានឈប់ឆ្លើយតប ការបញ្ជាទិញមិនត្រូវបានទទួលយកទេ។ ពួកគេក៏មិនត្រូវបានទទួលយកពីគេហទំព័រ មិនបង្ហាញនៅលើកម្មវិធីតាមដាន អ្នកគ្រប់គ្រងការផ្លាស់ប្តូរមិនអាចមើលឃើញពួកគេនៅក្នុងចំណុចប្រទាក់របស់គាត់ទេ។ 

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

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

កំណើនអាជីវកម្មយ៉ាងឆាប់រហ័ស

ហេតុអ្វីមិនអាចធ្វើបានភ្លាមៗ? គ្រាន់តែមើលតារាងខាងក្រោម។

ដូចគ្នានេះផងដែរនៅក្នុង 2014-2015 មានការបើកនៅប្រទេសរ៉ូម៉ានីហើយការបើកនៅសហរដ្ឋអាមេរិកកំពុងត្រូវបានរៀបចំ។

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

ឧបសគ្គមួយទៀតចំពោះការជួសជុលទាន់ពេលវេលានៃស្ថាបត្យកម្ម និងការយកចិត្តទុកដាក់ជាទូទៅចំពោះបញ្ហាបច្ចេកទេសគឺវិបត្តិឆ្នាំ 2014 ។ អ្វីៗដូចនេះបានជះឥទ្ធិពលយ៉ាងខ្លាំងទៅលើឱកាសសម្រាប់ក្រុមដើម្បីរីកចម្រើន ជាពិសេសសម្រាប់អាជីវកម្មវ័យក្មេងដូចជា Dodo Pizza ។

ដំណោះស្រាយរហ័សដែលបានជួយ

បញ្ហាដែលត្រូវការដំណោះស្រាយ។ តាមធម្មតា ដំណោះស្រាយអាចចែកចេញជា២ក្រុម៖

• លឿនដែលពន្លត់ភ្លើង និងផ្តល់សុវត្ថិភាពតិចតួច ហើយទិញពេលវេលាដើម្បីផ្លាស់ប្តូរ។

• ជាប្រព័ន្ធ ហើយដូច្នេះយូរ។ ការរៀបចំឡើងវិញនូវម៉ូឌុលមួយចំនួន ការបែងចែកស្ថាបត្យកម្ម monolithic ទៅជាសេវាកម្មដាច់ដោយឡែក (ភាគច្រើននៃពួកគេមិនមែននៅមីក្រូទាំងអស់ទេ ប៉ុន្តែជាសេវាម៉ាក្រូ ហើយវាមានអ្វីមួយអំពីវា របាយការណ៍របស់ Andrey Morevskiy). 

បញ្ជីស្ងួតនៃការផ្លាស់ប្តូររហ័សមានដូចខាងក្រោម៖

ពង្រីកមេមូលដ្ឋាន

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

ចាប់តាំងពីឆ្នាំ 2014 យើងបានផ្លាស់ទៅ Azure យើងក៏បានសរសេរអំពីប្រធានបទនេះនៅពេលនោះនៅក្នុងអត្ថបទ "របៀបដែល Dodo Pizza ចែកចាយ Pizza ដោយប្រើ Microsoft Azure Cloud"។ ប៉ុន្តែ​បន្ទាប់​ពី​ការ​កើន​ឡើង​ជា​បន្តបន្ទាប់​នៅ​ក្នុង​ម៉ាស៊ីន​បម្រើ​សម្រាប់​មូលដ្ឋាន ពួក​គេ​បាន​ឡើង​មក​ទល់​នឹង​ការ​ចំណាយ។ 

ការចម្លងមូលដ្ឋានសម្រាប់ការអាន

ការចម្លងពីរត្រូវបានធ្វើឡើងសម្រាប់មូលដ្ឋាន៖

អានចម្លង សម្រាប់សំណើជាឯកសារយោង. វាត្រូវបានប្រើដើម្បីអានបញ្ជីឈ្មោះ ប្រភេទ ទីក្រុង ផ្លូវ ហាងភីហ្សា ផលិតផល (ដែនដែលបានផ្លាស់ប្តូរយឺត) និងនៅក្នុងចំណុចប្រទាក់ទាំងនោះដែលអាចទទួលយកបាននូវការពន្យារពេលតិចតួច។ មាន 2 នៃការចម្លងទាំងនេះ យើងធានាភាពអាចរកបានរបស់ពួកគេតាមរបៀបដូចគ្នានឹងចៅហ្វាយនាយ។

ReadReplica សម្រាប់សំណើររបាយការណ៍. មូលដ្ឋានទិន្នន័យនេះមានភាពអាចរកបានទាបជាង ប៉ុន្តែរបាយការណ៍ទាំងអស់បានទៅវា។ អនុញ្ញាតឱ្យពួកគេមានសំណើធ្ងន់ៗសម្រាប់ការគណនាទិន្នន័យដ៏ធំ ប៉ុន្តែពួកគេមិនប៉ះពាល់ដល់មូលដ្ឋានទិន្នន័យសំខាន់ និងចំណុចប្រទាក់ប្រតិបត្តិការទេ។ 

ឃ្លាំងសម្ងាត់នៅក្នុងកូដ

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

ម៉ាស៊ីនមេ backend ច្រើន។

ផ្នែកខាងក្រោយនៃកម្មវិធីក៏ត្រូវការធ្វើមាត្រដ្ឋានផងដែរ ដើម្បីគ្រប់គ្រងបន្ទុកការងារដែលកើនឡើង។ វាចាំបាច់ក្នុងការបង្កើតចង្កោមពីម៉ាស៊ីនមេ iis មួយ។ យើងបានកំណត់ពេលវេលាឡើងវិញ សម័យកម្មវិធី ពី memory ទៅ RedisCache ដែលធ្វើឱ្យវាអាចបង្កើត servers ជាច្រើននៅពីក្រោយ load balancer សាមញ្ញជាមួយ round robin។ ដំបូង Redis ដូចគ្នាត្រូវបានគេប្រើសម្រាប់ឃ្លាំងសម្ងាត់បន្ទាប់មកវាត្រូវបានបំបែកទៅជាជាច្រើន។ 

ជាលទ្ធផល ស្ថាបត្យកម្មកាន់តែមានភាពស្មុគស្មាញ…

… ប៉ុន្តែភាពតានតឹងខ្លះត្រូវបានដកចេញ។

ហើយបន្ទាប់មកវាចាំបាច់ក្នុងការធ្វើឡើងវិញនូវសមាសធាតុដែលបានផ្ទុកដែលយើងបានធ្វើ។ យើងនឹងនិយាយអំពីរឿងនេះនៅផ្នែកបន្ទាប់។

ប្រភព: www.habr.com