អ្នកបានចំណាយពេលរាប់ខែក្នុងការរចនាម៉ូណូលីតរបស់អ្នកឡើងវិញទៅជាសេវាមីក្រូ ហើយទីបំផុតអ្នករាល់គ្នាបានរួមគ្នាដើម្បីបង្វិលកុងតាក់។ អ្នកចូលទៅកាន់គេហទំព័រដំបូង ... ហើយគ្មានអ្វីកើតឡើងទេ។ អ្នកផ្ទុកវាឡើងវិញ - ហើយម្តងទៀតគ្មានអ្វីល្អទេ គេហទំព័រនេះយឺតណាស់ ដែលវាមិនឆ្លើយតបអស់រយៈពេលជាច្រើននាទី។ តើមានអ្វីកើតឡើង?
នៅក្នុងសុន្ទរកថារបស់គាត់ លោក Jimmy Bogard នឹងធ្វើ "ការស្លាប់ក្រោយការស្លាប់" លើគ្រោះមហន្តរាយនៃសេវាកម្មខ្នាតតូចក្នុងជីវិតពិត។ គាត់នឹងបង្ហាញពីបញ្ហានៃការធ្វើម៉ូដែល ការអភិវឌ្ឍន៍ និងការផលិតដែលគាត់បានរកឃើញ និងរបៀបដែលក្រុមរបស់គាត់បានផ្លាស់ប្តូរបន្តិចម្តងៗនូវម៉ូណូលីតដែលចែកចាយថ្មីទៅជារូបភាពចុងក្រោយនៃអនាម័យ។ ខណៈពេលដែលវាមិនអាចទៅរួចទេក្នុងការទប់ស្កាត់កំហុសក្នុងការរចនាទាំងស្រុង យ៉ាងហោចណាស់អ្នកអាចកំណត់បញ្ហានៅដំណាក់កាលដំបូងក្នុងដំណើរការរចនា ដើម្បីធានាថាផលិតផលចុងក្រោយក្លាយជាប្រព័ន្ធចែកចាយដែលអាចទុកចិត្តបាន។
ជំរាបសួរអ្នកទាំងអស់គ្នា ខ្ញុំគឺ Jimmy ហើយថ្ងៃនេះអ្នកនឹងឮពីរបៀបដែលអ្នកអាចជៀសវាងគ្រោះមហន្តរាយធំនៅពេលសាងសង់សេវាកម្មមីក្រូ។ នេះជារឿងរបស់ក្រុមហ៊ុនដែលខ្ញុំបានធ្វើការប្រហែលមួយឆ្នាំកន្លះដើម្បីជួយការពារកប៉ាល់របស់ពួកគេពីការបុកជាមួយផ្ទាំងទឹកកក។ ដើម្បីប្រាប់រឿងនេះឱ្យបានត្រឹមត្រូវ យើងនឹងត្រូវត្រលប់ទៅពេលវេលាវិញ ហើយនិយាយអំពីកន្លែងដែលក្រុមហ៊ុននេះបានចាប់ផ្តើម និងរបៀបដែលហេដ្ឋារចនាសម្ព័ន្ធ IT របស់ខ្លួនបានរីកចម្រើនតាមពេលវេលា។ ដើម្បីការពារឈ្មោះជនស្លូតត្រង់ក្នុងគ្រោះមហន្តរាយនេះ ខ្ញុំបានប្តូរឈ្មោះក្រុមហ៊ុននេះទៅជា Bell Computers។ ស្លាយបន្ទាប់បង្ហាញពីអ្វីដែលហេដ្ឋារចនាសម្ព័ន្ធ IT របស់ក្រុមហ៊ុនបែបនេះមើលទៅដូចនៅពាក់កណ្តាលទសវត្សរ៍ទី 90 ។ នេះគឺជាស្ថាបត្យកម្មធម្មតានៃម៉ាស៊ីនមេ HP Tandem Mainframe ដែលធន់ទ្រាំនឹងកំហុសជាសកលដ៏ធំសម្រាប់ប្រតិបត្តិការហាងផ្នែករឹងកុំព្យូទ័រ។
ពួកគេត្រូវការដើម្បីបង្កើតប្រព័ន្ធមួយដើម្បីគ្រប់គ្រងរាល់ការបញ្ជាទិញ ការលក់ ការត្រឡប់មកវិញ កាតាឡុកផលិតផល និងមូលដ្ឋានអតិថិជន ដូច្នេះពួកគេបានជ្រើសរើសដំណោះស្រាយមេនហ្វ្រេមទូទៅបំផុតនៅពេលនោះ។ ប្រព័ន្ធយក្សនេះមានគ្រប់ព័ត៌មានអំពីក្រុមហ៊ុន អ្វីគ្រប់យ៉ាងដែលអាចធ្វើទៅបាន ហើយរាល់ប្រតិបត្តិការត្រូវបានអនុវត្តតាមរយៈ mainframe នេះ។ ពួកគេបានទុកស៊ុតទាំងអស់ក្នុងកន្ត្រកមួយ ហើយគិតថាវាធម្មតា។ រឿងតែមួយគត់ដែលមិនត្រូវបានរាប់បញ្ចូលនៅទីនេះគឺកាតាឡុកការបញ្ជាទិញតាមសំបុត្រ និងការបញ្ជាទិញតាមទូរស័ព្ទ។
យូរៗទៅ ប្រព័ន្ធនេះកាន់តែធំទៅៗ ហើយសំរាមយ៉ាងច្រើនកកកុញនៅក្នុងនោះ។ ម្យ៉ាងវិញទៀត COBOL មិនមែនជាភាសាដែលបញ្ចេញមតិច្រើនជាងគេបំផុតនៅក្នុងពិភពលោក ដូច្នេះប្រព័ន្ធនេះបានបញ្ចប់ទៅជាសារធាតុឥតបានការដ៏ធំ និង monolithic ។ នៅឆ្នាំ 2000 ពួកគេបានឃើញថាក្រុមហ៊ុនជាច្រើនមានគេហទំព័រដែលពួកគេបានធ្វើអាជីវកម្មរបស់ពួកគេទាំងស្រុង ហើយបានសម្រេចចិត្តបង្កើតគេហទំព័រពាណិជ្ជកម្មដំបូងគេ។
ការរចនាដំបូងមើលទៅស្អាត ហើយមានគេហទំព័រកម្រិតកំពូល bell.com និងដែនរងមួយចំនួនសម្រាប់កម្មវិធីនីមួយៗ៖ catalog.bell.com, accounts.bell.com, orders.bell.com, ផលិតផលស្វែងរក search.bell ។ com ដែនរងនីមួយៗបានប្រើប្រាស់ក្របខ័ណ្ឌ ASP.Net 1.0 និងមូលដ្ឋានទិន្នន័យផ្ទាល់ខ្លួនរបស់វា ហើយពួកគេទាំងអស់បាននិយាយទៅកាន់ផ្នែកខាងក្រោយរបស់ប្រព័ន្ធ។ ទោះជាយ៉ាងណាក៏ដោយ ការបញ្ជាទិញទាំងអស់បានបន្តដំណើរការ និងប្រតិបត្តិក្នុង mainframe ដ៏ធំតែមួយ ដែលក្នុងនោះសំរាមទាំងអស់នៅតែមាន ប៉ុន្តែផ្នែកខាងមុខគឺជាគេហទំព័រដាច់ដោយឡែកជាមួយនឹងកម្មវិធីនីមួយៗ និងមូលដ្ឋានទិន្នន័យដាច់ដោយឡែក។
ដូច្នេះការរចនានៃប្រព័ន្ធមើលទៅមានសណ្តាប់ធ្នាប់ និងឡូជីខល ប៉ុន្តែប្រព័ន្ធជាក់ស្តែងដូចបានបង្ហាញក្នុងស្លាយបន្ទាប់។
ធាតុទាំងអស់បានដោះស្រាយការហៅទៅគ្នាទៅវិញទៅមក ចូលប្រើ APIs ដែលបានបង្កប់ dlls ភាគីទីបី និងអ្វីៗផ្សេងទៀត។ ជារឿយៗវាបានកើតឡើងដែលប្រព័ន្ធគ្រប់គ្រងកំណែនឹងចាប់យកកូដរបស់នរណាម្នាក់ រុញវានៅខាងក្នុងគម្រោង ហើយបន្ទាប់មកអ្វីៗនឹងខូច។ MS SQL Server 2005 បានប្រើគោលគំនិតនៃតំណភ្ជាប់ servers ហើយទោះបីជាខ្ញុំមិនបានបង្ហាញព្រួញនៅលើស្លាយក៏ដោយ មូលដ្ឋានទិន្នន័យនីមួយៗក៏បាននិយាយជាមួយគ្នាដែរ ព្រោះមិនមានអ្វីខុសជាមួយការកសាងតារាងដោយផ្អែកលើទិន្នន័យដែលទទួលបានពីមូលដ្ឋានទិន្នន័យជាច្រើន។
ដោយសារឥឡូវនេះពួកគេមានការបំបែកគ្នារវាងផ្នែកឡូជីខលផ្សេងៗគ្នានៃប្រព័ន្ធនេះ វាបានក្លាយទៅជាការចែកចាយនូវភាពកខ្វក់ ដោយបំណែកដ៏ធំបំផុតនៃសំរាមនៅតែនៅសល់នៅក្នុងផ្នែកខាងក្រោយនៃ mainframe ។
អ្វីដែលគួរឱ្យអស់សំណើចនោះគឺថា mainframe នេះត្រូវបានបង្កើតឡើងដោយដៃគូប្រកួតប្រជែងរបស់ Bell Computers ហើយនៅតែត្រូវបានរក្សាដោយអ្នកប្រឹក្សាបច្ចេកទេសរបស់ពួកគេ។ ដោយជឿជាក់លើការអនុវត្តមិនពេញចិត្តនៃកម្មវិធីរបស់ខ្លួន ក្រុមហ៊ុនបានសម្រេចចិត្តកម្ចាត់ពួកវា និងរៀបចំប្រព័ន្ធឡើងវិញ។
កម្មវិធីដែលមានស្រាប់បានដំណើរការអស់រយៈពេល 15 ឆ្នាំមកហើយ ដែលជាកំណត់ត្រាសម្រាប់កម្មវិធីដែលមានមូលដ្ឋានលើ ASP.Net ។ សេវាកម្មនេះបានទទួលយកការបញ្ជាទិញពីទូទាំងពិភពលោក ហើយប្រាក់ចំណូលប្រចាំឆ្នាំពីកម្មវិធីតែមួយនេះឈានដល់មួយពាន់លានដុល្លារ។ ផ្នែកសំខាន់នៃប្រាក់ចំណេញត្រូវបានបង្កើតឡើងដោយគេហទំព័រ bell.com ។ នៅថ្ងៃ Black Fridays ចំនួននៃការបញ្ជាទិញតាមរយៈគេហទំព័របានឈានដល់ជាច្រើនលាន។ ទោះជាយ៉ាងណាក៏ដោយ ស្ថាបត្យកម្មដែលមានស្រាប់មិនអនុញ្ញាតឱ្យមានការអភិវឌ្ឍន៍ណាមួយឡើយ ចាប់តាំងពីការភ្ជាប់គ្នាយ៉ាងតឹងរ៉ឹងនៃធាតុប្រព័ន្ធជាក់ស្តែងមិនអនុញ្ញាតឱ្យមានការផ្លាស់ប្តូរណាមួយចំពោះសេវាកម្មនោះទេ។
បញ្ហាធ្ងន់ធ្ងរបំផុតគឺអសមត្ថភាពក្នុងការបញ្ជាទិញពីប្រទេសមួយ បង់ប្រាក់សម្រាប់ប្រទេសមួយទៀត ហើយផ្ញើទៅប្រទេសទីបី បើទោះបីជាគម្រោងការជួញដូរបែបនេះជារឿងធម្មតាណាស់នៅក្នុងក្រុមហ៊ុនពិភពលោកក៏ដោយ។ គេហទំព័រដែលមានស្រាប់មិនអនុញ្ញាតឱ្យមានអ្វីដូចនេះទេ ដូច្នេះពួកគេត្រូវតែទទួលយក និងដាក់ការបញ្ជាទិញទាំងនេះតាមទូរស័ព្ទ។ នេះនាំឱ្យក្រុមហ៊ុនគិតកាន់តែខ្លាំងឡើងអំពីការផ្លាស់ប្តូរស្ថាបត្យកម្ម ជាពិសេសអំពីការប្តូរទៅសេវាមីក្រូ។
ពួកគេបានធ្វើរឿងដ៏ឆ្លាតវៃដោយមើលក្រុមហ៊ុនផ្សេងទៀតដើម្បីមើលពីរបៀបដែលពួកគេដោះស្រាយបញ្ហាស្រដៀងគ្នានេះ។ ដំណោះស្រាយមួយក្នុងចំណោមដំណោះស្រាយទាំងនេះគឺស្ថាបត្យកម្មសេវាកម្ម Netflix ដែលមានមីក្រូសេវាភ្ជាប់តាមរយៈ API និងមូលដ្ឋានទិន្នន័យខាងក្រៅ។
ការគ្រប់គ្រងរបស់ Bell Computers បានសម្រេចចិត្តបង្កើតស្ថាបត្យកម្មបែបនេះ ដោយប្រកាន់ខ្ជាប់នូវគោលការណ៍ជាមូលដ្ឋានមួយចំនួន។ ជាដំបូង ពួកគេបានលុបបំបាត់ការចម្លងទិន្នន័យដោយប្រើវិធីសាស្រ្តមូលដ្ឋានទិន្នន័យរួម។ គ្មានទិន្នន័យត្រូវបានផ្ញើទេ ផ្ទុយទៅវិញ អ្នកដែលត្រូវការវាត្រូវទៅប្រភពមជ្ឈិម។ នេះត្រូវបានបន្តដោយភាពឯកោ និងស្វ័យភាព - សេវាកម្មនីមួយៗគឺឯករាជ្យពីអ្នកដទៃ។ ពួកគេបានសម្រេចចិត្តប្រើ Web API សម្រាប់អ្វីៗគ្រប់យ៉ាង - ប្រសិនបើអ្នកចង់ទទួលបានទិន្នន័យ ឬធ្វើការផ្លាស់ប្តូរទៅប្រព័ន្ធមួយផ្សេងទៀត វាត្រូវបានធ្វើទាំងអស់តាមរយៈ Web API ។ រឿងធំចុងក្រោយគឺ mainframe ថ្មីដែលហៅថា "Bell on Bell" ផ្ទុយពី mainframe "Bell" ដោយផ្អែកលើ hardware របស់គូប្រជែង។
ដូច្នេះ ក្នុងរយៈពេល 18 ខែ ពួកគេបានបង្កើតប្រព័ន្ធជុំវិញគោលការណ៍ស្នូលទាំងនេះ ហើយនាំវាទៅផលិតមុនគេ។ ការត្រលប់ទៅធ្វើការវិញបន្ទាប់ពីចុងសប្តាហ៍ អ្នកអភិវឌ្ឍន៍បានជួបជុំគ្នា ហើយបើកម៉ាស៊ីនមេទាំងអស់ដែលប្រព័ន្ធថ្មីត្រូវបានភ្ជាប់។ 18 ខែនៃការងារ, អ្នកអភិវឌ្ឍន៍រាប់រយនាក់, ផ្នែករឹង Bell ទំនើបបំផុត - និងមិនមានលទ្ធផលវិជ្ជមាន! នេះបានធ្វើឱ្យមនុស្សជាច្រើនខកចិត្ត ដោយសារតែពួកគេបានដំណើរការប្រព័ន្ធនេះនៅលើកុំព្យូទ័រយួរដៃរបស់ពួកគេជាច្រើនដង ហើយអ្វីៗគឺល្អ។
ពួកគេឆ្លាតក្នុងការបោះលុយទាំងអស់របស់ពួកគេដើម្បីដោះស្រាយបញ្ហានេះ។ ពួកគេបានដំឡើងម៉ាស៊ីនមេទំនើបបំផុតជាមួយនឹងកុងតាក់ ប្រើសរសៃអុបទិក gigabit ដែលជាផ្នែករឹងម៉ាស៊ីនមេដ៏មានឥទ្ធិពលបំផុតជាមួយនឹងចំនួន RAM ឆ្កួត ភ្ជាប់វាទាំងអស់ កំណត់រចនាសម្ព័ន្ធវា ហើយម្តងទៀតគ្មានអ្វីសោះ! បន្ទាប់មកពួកគេចាប់ផ្តើមសង្ស័យថាហេតុផលអាចជាការអស់ពេល ដូច្នេះពួកគេបានចូលទៅក្នុងការកំណត់បណ្តាញទាំងអស់ ការកំណត់ API ទាំងអស់ និងធ្វើបច្ចុប្បន្នភាពការកំណត់ការអស់ពេលទាំងមូលទៅជាតម្លៃអតិបរមា ដូច្នេះអ្វីដែលពួកគេអាចធ្វើបានគឺអង្គុយរង់ចាំអ្វីមួយកើតឡើង។ ទៅកាន់គេហទំព័រ។ ពួកគេបានរង់ចាំហើយរង់ចាំរយៈពេល 9 នាទីកន្លះរហូតដល់ទីបំផុតគេហទំព័របានផ្ទុកឡើង។
បន្ទាប់ពីនោះ វាបានភ្លឺឡើងលើពួកគេថា ស្ថានភាពបច្ចុប្បន្នត្រូវការការវិភាគយ៉ាងម៉ត់ចត់ ហើយពួកគេបានអញ្ជើញយើង។ រឿងដំបូងដែលយើងបានរកឃើញគឺថាក្នុងអំឡុងពេល 18 ខែនៃការអភិវឌ្ឍន៍ មិនមែន "មីក្រូ" ពិតប្រាកដមួយត្រូវបានបង្កើតឡើងទេ - អ្វីគ្រប់យ៉ាងកាន់តែធំ។ បន្ទាប់ពីនេះ យើងបានចាប់ផ្តើមសរសេរសំបុត្រមរណភាព ដែលត្រូវបានគេស្គាល់ថាជា "សោកនាដកម្ម" ឬ "ការរំលឹកឡើងវិញដ៏សោកសៅ" ដែលគេស្គាល់ថាជា "ព្យុះសង្ឃរា" ស្រដៀងទៅនឹង "ព្យុះខួរក្បាល" ដើម្បីយល់ពីមូលហេតុនៃគ្រោះមហន្តរាយនេះ។
យើងមានតម្រុយជាច្រើន ដែលមួយក្នុងចំណោមនោះគឺការឆ្អែតចរាចរណ៍ពេញលេញនៅពេលហៅ API។ នៅពេលអ្នកប្រើស្ថាបត្យកម្មសេវាកម្ម monolithic អ្នកអាចយល់ភ្លាមៗនូវអ្វីដែលពិតជាខុស ពីព្រោះអ្នកមានដានជង់តែមួយដែលរាយការណ៍ពីអ្វីគ្រប់យ៉ាងដែលអាចបណ្តាលឱ្យបរាជ័យ។ ក្នុងករណីដែលសេវាកម្មជាច្រើនចូលប្រើ API តែមួយក្នុងពេលដំណាលគ្នានោះ មិនមានវិធីដើម្បីតាមដានដានឡើយ លើកលែងតែប្រើឧបករណ៍ត្រួតពិនិត្យបណ្តាញបន្ថែមដូចជា WireShark អរគុណដែលអ្នកអាចពិនិត្យមើលសំណើតែមួយ និងស្វែងយល់ពីអ្វីដែលបានកើតឡើងអំឡុងពេលអនុវត្តរបស់វា។ ដូច្នេះហើយ យើងបានយកគេហទំព័រមួយ ហើយចំណាយពេលជិត 2 សប្តាហ៍ដាក់បំណែកនៃល្បែងផ្គុំរូបជាមួយគ្នា ដោយធ្វើការហៅទូរសព្ទជាច្រើនទៅកាន់វា និងវិភាគពីអ្វីដែលពួកគេម្នាក់ៗនាំទៅរក។
មើលរូបភាពនេះ។ វាបង្ហាញថាសំណើខាងក្រៅមួយជំរុញឱ្យសេវាកម្មធ្វើការហៅខាងក្នុងជាច្រើនដែលត្រលប់មកវិញ។ វាប្រែថាការហៅចូលខាងក្នុងនីមួយៗធ្វើឱ្យមានការកើនឡើងបន្ថែមទៀត ដើម្បីអាចផ្តល់សេវាកម្មដោយឯករាជ្យនូវសំណើនេះ ព្រោះវាមិនអាចទៅកន្លែងណាផ្សេងទៀតដើម្បីទទួលបានព័ត៌មានចាំបាច់នោះទេ។ រូបភាពនេះមើលទៅដូចជាការហៅទូរសព្ទដែលគ្មានន័យ ព្រោះសំណើខាងក្រៅហៅសេវាកម្មបន្ថែម ដែលហៅសេវាបន្ថែមផ្សេងទៀត ហើយដូច្នេះនៅលើ ស្ទើរតែគ្មានដែនកំណត់នៃការផ្សាយពាណិជ្ជកម្ម។
ពណ៌បៃតងនៅក្នុងដ្យាក្រាមនេះបង្ហាញពីរង្វង់ពាក់កណ្តាលដែលសេវាកម្មហៅគ្នាទៅវិញទៅមក - សេវាកម្ម A ហៅសេវា B សេវា B ហៅសេវា C ហើយវាហៅសេវាកម្ម A ម្តងទៀត។ ជាលទ្ធផលយើងទទួលបាន "ការជាប់គាំងចែកចាយ" ។ សំណើតែមួយបានបង្កើតការហៅ API បណ្តាញមួយពាន់ ហើយចាប់តាំងពីប្រព័ន្ធមិនមានការអត់ធ្មត់កំហុស និងការការពាររង្វិលជុំ សំណើនឹងបរាជ័យ ប្រសិនបើសូម្បីតែការហៅ API មួយក្នុងចំណោមការហៅទូរសព្ទទាំងនេះបរាជ័យ។
យើងធ្វើគណិតវិទ្យាខ្លះ។ ការហៅ API នីមួយៗមាន SLA មិនលើសពី 150 ms និង 99,9% ពេលវេលាដំណើរការ។ សំណើមួយបណ្តាលឱ្យមានការហៅទូរស័ព្ទចំនួន 200 ផ្សេងគ្នា ហើយក្នុងករណីដ៏ល្អបំផុត ទំព័រអាចត្រូវបានបង្ហាញក្នុង 200 x 150 ms = 30 វិនាទី។ តាមធម្មជាតិ នេះមិនល្អទេ។ គុណនឹង 99,9% ពេលវេលាដំណើរការដោយ 200 យើងទទួលបាន 0% ។ វាប្រែថាស្ថាបត្យកម្មនេះត្រូវបានបំផ្លាញដោយបរាជ័យតាំងពីដំបូង។
យើងបានសួរអ្នកអភិវឌ្ឍន៍ថាតើពួកគេបរាជ័យក្នុងការទទួលស្គាល់បញ្ហានេះដោយរបៀបណាបន្ទាប់ពីការងាររយៈពេល 18 ខែ? វាបានប្រែក្លាយថាពួកគេបានរាប់តែ SLA សម្រាប់លេខកូដដែលពួកគេបានដំណើរការ ប៉ុន្តែប្រសិនបើសេវាកម្មរបស់ពួកគេហៅថាសេវាផ្សេងទៀត ពួកគេមិនរាប់ពេលវេលានោះនៅក្នុង SLA របស់ពួកគេទេ។ អ្វីគ្រប់យ៉ាងដែលត្រូវបានដាក់ឱ្យដំណើរការក្នុងដំណើរការមួយបានប្រកាន់ខ្ជាប់នូវតម្លៃ 150 ms ប៉ុន្តែការចូលទៅកាន់ដំណើរការសេវាកម្មផ្សេងទៀតបានបង្កើនការពន្យារពេលសរុបជាច្រើនដង។ មេរៀនដំបូងដែលបានរៀនគឺ "តើអ្នកគ្រប់គ្រង SLA របស់អ្នកឬ SLA គ្រប់គ្រងអ្នក?" ក្នុងករណីរបស់យើងវាគឺជាចុងក្រោយ។
រឿងបន្ទាប់ដែលយើងបានរកឃើញគឺថាពួកគេបានដឹងអំពីគំនិតនៃការចែកចាយការយល់ខុសនៃការគណនាដែលបង្កើតដោយ Peter Deitch និង James Gosling ប៉ុន្តែពួកគេមិនបានអើពើផ្នែកដំបូងនៃវា។ វាចែងថាសេចក្តីថ្លែងការណ៍ "បណ្តាញអាចទុកចិត្តបាន" "សូន្យភាពយឺតយ៉ាវ" និង "ការបញ្ជូនបន្តគ្មានកំណត់" គឺជាការយល់ខុស។ ការយល់ខុសផ្សេងទៀតរួមមានសេចក្តីថ្លែងការណ៍ថា "បណ្តាញមានសុវត្ថិភាព" "ប្រធានបទមិនផ្លាស់ប្តូរ" "តែងតែមានអ្នកគ្រប់គ្រងតែមួយ" "តម្លៃនៃការផ្ទេរទិន្នន័យគឺសូន្យ" និង "បណ្តាញគឺដូចគ្នា" ។
ពួកគេបានធ្វើខុសដោយសារតែពួកគេបានសាកល្បងសេវាកម្មរបស់ពួកគេនៅលើម៉ាស៊ីនក្នុងស្រុក ហើយមិនដែលភ្ជាប់ជាមួយសេវាកម្មខាងក្រៅឡើយ។ នៅពេលអភិវឌ្ឍមូលដ្ឋាន និងប្រើប្រាស់ឃ្លាំងសម្ងាត់មូលដ្ឋាន ពួកគេមិនដែលជួបប្រទះបណ្តាញ hops ទេ។ ក្នុងរយៈពេល 18 ខែនៃការអភិវឌ្ឍន៍ ពួកគេមិនធ្លាប់ឆ្ងល់ថា តើមានអ្វីកើតឡើង ប្រសិនបើសេវាកម្មខាងក្រៅត្រូវបានប៉ះពាល់។
ប្រសិនបើអ្នកក្រឡេកមើលព្រំដែនសេវាកម្មក្នុងរូបភាពមុន អ្នកអាចមើលឃើញថាពួកវាទាំងអស់មិនត្រឹមត្រូវ។ មានប្រភពជាច្រើនដែលណែនាំអំពីរបៀបកំណត់ព្រំដែនសេវាកម្ម ហើយភាគច្រើនធ្វើវាខុស ដូចជា Microsoft នៅលើស្លាយបន្ទាប់។
រូបភាពនេះគឺមកពីប្លក់ MS លើប្រធានបទ "របៀបបង្កើតសេវាកម្មមីក្រូ"។ វាបង្ហាញពីកម្មវិធីគេហទំព័រសាមញ្ញ ប្លុកនៃតក្កវិជ្ជាអាជីវកម្ម និងមូលដ្ឋានទិន្នន័យ។ សំណើនេះមកដោយផ្ទាល់ ប្រហែលជាមានម៉ាស៊ីនមេមួយសម្រាប់គេហទំព័រ ម៉ាស៊ីនមេមួយសម្រាប់អាជីវកម្ម និងមួយទៀតសម្រាប់មូលដ្ឋានទិន្នន័យ។ ប្រសិនបើអ្នកបង្កើនចរាចរណ៍ រូបភាពនឹងផ្លាស់ប្តូរបន្តិច។
នេះគឺជាឧបករណ៍ផ្ទុកតុល្យភាពដើម្បីចែកចាយចរាចររវាងម៉ាស៊ីនមេគេហទំព័រពីរ ឃ្លាំងសម្ងាត់ដែលស្ថិតនៅចន្លោះសេវាគេហទំព័រ និងតក្កវិជ្ជាអាជីវកម្ម និងឃ្លាំងសម្ងាត់មួយទៀតរវាងតក្កវិជ្ជាអាជីវកម្ម និងមូលដ្ឋានទិន្នន័យ។ នេះពិតជាស្ថាបត្យកម្ម Bell ដែលប្រើសម្រាប់តុល្យភាពបន្ទុករបស់វា និងកម្មវិធីដាក់ពង្រាយពណ៌ខៀវ/បៃតងនៅពាក់កណ្តាលទសវត្សរ៍ឆ្នាំ 2000។ រហូតដល់ពេលខ្លះអ្វីៗដំណើរការបានល្អព្រោះគ្រោងការណ៍នេះត្រូវបានបម្រុងទុកសម្រាប់រចនាសម្ព័ន្ធ monolithic ។
រូបភាពខាងក្រោមបង្ហាញពីរបៀបដែល MS ណែនាំឱ្យផ្លាស់ប្តូរពី monolith ទៅ microservices ដោយគ្រាន់តែបំបែកសេវាសំខាន់ៗនីមួយៗទៅជា microservices ដាច់ដោយឡែក។ វាគឺកំឡុងពេលអនុវត្តគ្រោងការណ៍នេះដែល Bell បានធ្វើឱ្យមានកំហុស។
ពួកគេបានបែងចែកសេវាទាំងអស់របស់ពួកគេទៅជាថ្នាក់ផ្សេងៗគ្នា ដែលនីមួយៗមានសេវាកម្មបុគ្គលជាច្រើន។ ជាឧទាហរណ៍ សេវាបណ្ដាញរួមបញ្ចូលមីក្រូសេវាសម្រាប់ការបង្ហាញខ្លឹមសារ និងការផ្ទៀងផ្ទាត់ សេវាកម្មតក្កវិជ្ជាអាជីវកម្មមានមីក្រូសេវាសម្រាប់ដំណើរការការបញ្ជាទិញ និងព័ត៌មានគណនី មូលដ្ឋានទិន្នន័យត្រូវបានបែងចែកទៅជាក្រុមមីក្រូសេវាដែលមានទិន្នន័យឯកទេស។ ទាំងគេហទំព័រ តក្កវិជ្ជាអាជីវកម្ម និងមូលដ្ឋានទិន្នន័យ គឺជាសេវាកម្មគ្មានរដ្ឋ។
ទោះជាយ៉ាងណាក៏ដោយ រូបភាពនេះគឺខុសទាំងស្រុង ព្រោះវាមិនបានគូសផែនទីអង្គភាពអាជីវកម្មណាមួយនៅខាងក្រៅចង្កោម IT របស់ក្រុមហ៊ុន។ គ្រោងការណ៍នេះមិនបានគិតគូរពីទំនាក់ទំនងណាមួយជាមួយពិភពខាងក្រៅទេ ដូច្នេះវាមិនច្បាស់អំពីរបៀបដើម្បីទទួលបានការវិភាគអាជីវកម្មភាគីទីបីនោះទេ។ ខ្ញុំកត់សម្គាល់ថាពួកគេក៏មានសេវាកម្មជាច្រើនដែលបង្កើតឡើងយ៉ាងសាមញ្ញដើម្បីអភិវឌ្ឍអាជីពរបស់បុគ្គលិកម្នាក់ៗដែលស្វែងរកការគ្រប់គ្រងមនុស្សឱ្យបានច្រើនតាមដែលអាចធ្វើទៅបាន ដើម្បីទទួលបានប្រាក់បន្ថែមសម្រាប់វា។
ពួកគេជឿថាការផ្លាស់ប្តូរទៅកាន់សេវាមីក្រូគឺមានភាពងាយស្រួលដូចជាការយកហេដ្ឋារចនាសម្ព័ន្ធស្រទាប់ N-tier ខាងក្នុងរបស់ពួកគេ ហើយបិទ Docker នៅលើវា។ សូមក្រឡេកមើលថាតើស្ថាបត្យកម្ម N-tier ប្រពៃណីមើលទៅដូចម្ដេច។
វាមាន 4 កម្រិត៖ កម្រិតចំណុចប្រទាក់អ្នកប្រើ UI កម្រិតតក្កវិជ្ជាអាជីវកម្ម កម្រិតចូលប្រើទិន្នន័យ និងមូលដ្ឋានទិន្នន័យ។ វឌ្ឍនភាពបន្ថែមទៀតគឺ DDD (Domain-Driven Design) ឬស្ថាបត្យកម្មតម្រង់ទិសកម្មវិធី ដែលកម្រិតកណ្តាលពីរគឺជាវត្ថុដែន និងឃ្លាំង។
ខ្ញុំបានព្យាយាមសម្លឹងមើលផ្នែកផ្សេងគ្នានៃការផ្លាស់ប្តូរ, តំបន់ផ្សេងគ្នានៃការទទួលខុសត្រូវនៅក្នុងស្ថាបត្យកម្មនេះ។ នៅក្នុងកម្មវិធី N-tier ធម្មតា តំបន់ផ្សេងគ្នានៃការផ្លាស់ប្តូរត្រូវបានចាត់ថ្នាក់ដែលជ្រាបចូលទៅក្នុងរចនាសម្ព័ន្ធបញ្ឈរពីកំពូលទៅបាត។ ទាំងនេះគឺជាកាតាឡុក ការកំណត់រចនាសម្ព័ន្ធដែលធ្វើឡើងនៅលើកុំព្យូទ័រនីមួយៗ និងការត្រួតពិនិត្យ Checkout ដែលត្រូវបានគ្រប់គ្រងដោយក្រុមរបស់ខ្ញុំ។
ភាពប្លែកនៃគ្រោងការណ៍នេះគឺថាព្រំដែននៃតំបន់នៃការផ្លាស់ប្តូរទាំងនេះប៉ះពាល់មិនត្រឹមតែកម្រិតតក្កវិជ្ជាអាជីវកម្មប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងពង្រីកដល់មូលដ្ឋានទិន្នន័យផងដែរ។
សូមក្រឡេកមើលអ្វីដែលវាមានន័យថាជាសេវាកម្ម។ មានលក្ខណៈសម្បត្តិ 6 យ៉ាងនៃនិយមន័យសេវាកម្ម - វាគឺជាកម្មវិធីដែល៖
- បង្កើត និងប្រើប្រាស់ដោយអង្គការជាក់លាក់មួយ;
- ទទួលខុសត្រូវចំពោះខ្លឹមសារ ដំណើរការ និង/ឬការផ្តល់ព័ត៌មានប្រភេទជាក់លាក់មួយនៅក្នុងប្រព័ន្ធ។
- អាចត្រូវបានសាងសង់ ដាក់ពង្រាយ និងដំណើរការដោយឯករាជ្យ ដើម្បីបំពេញតម្រូវការប្រតិបត្តិការជាក់លាក់។
- ប្រាស្រ័យទាក់ទងជាមួយអ្នកប្រើប្រាស់ និងសេវាកម្មផ្សេងទៀត ការផ្តល់ព័ត៌មានដោយផ្អែកលើកិច្ចព្រមព្រៀង ឬការធានាតាមកិច្ចសន្យា។
- ការពារខ្លួនពីការចូលប្រើដោយគ្មានការអនុញ្ញាត និងព័ត៌មានរបស់វាពីការបាត់បង់។
- ដោះស្រាយការបរាជ័យតាមរបៀបដែលពួកគេមិននាំឱ្យខូចព័ត៌មាន។
លក្ខណៈសម្បត្តិទាំងអស់នេះអាចត្រូវបានបញ្ជាក់នៅក្នុងពាក្យមួយ "ស្វ័យភាព" ។ សេវាកម្មដំណើរការដោយឯករាជ្យពីគ្នាទៅវិញទៅមក បំពេញការរឹតបន្តឹងជាក់លាក់ និងកំណត់កិច្ចសន្យាដោយផ្អែកលើមូលដ្ឋានដែលមនុស្សអាចទទួលបានព័ត៌មានដែលពួកគេត្រូវការ។ ខ្ញុំមិនបាននិយាយអំពីបច្ចេកវិទ្យាជាក់លាក់ទេគឺការប្រើប្រាស់ដែលបង្ហាញឱ្យឃើញដោយខ្លួនឯង។
ឥឡូវសូមមើលនិយមន័យនៃសេវាមីក្រូ៖
- សេវាខ្នាតតូចមានទំហំតូច និងត្រូវបានរចនាឡើងដើម្បីដោះស្រាយបញ្ហាជាក់លាក់មួយ។
- សេវាមីក្រូគឺស្វយ័ត;
- នៅពេលបង្កើតស្ថាបត្យកម្មមីក្រូសេវា ការប្រៀបធៀបការធ្វើផែនការទីក្រុងត្រូវបានប្រើប្រាស់។ នេះជានិយមន័យចេញពីសៀវភៅរបស់លោក Sam Newman ដែលមានឈ្មោះថា Building Microservices។
និយមន័យនៃបរិបទដែលមានព្រំដែនគឺយកចេញពីសៀវភៅរបស់ Eric Evans របស់ Domain-Driven Design។ នេះគឺជាគំរូស្នូលនៅក្នុង DDD ដែលជាមជ្ឈមណ្ឌលរចនាស្ថាបត្យកម្មដែលធ្វើការជាមួយគំរូស្ថាបត្យកម្មបរិមាណ ដោយបែងចែកពួកវាទៅជាបរិបទដែលមានព្រំដែនផ្សេងៗគ្នា និងកំណត់យ៉ាងច្បាស់នូវអន្តរកម្មរវាងពួកគេ។
និយាយឱ្យសាមញ្ញ បរិបទដែលមានព្រំដែនបង្ហាញពីវិសាលភាពដែលម៉ូឌុលជាក់លាក់មួយអាចត្រូវបានប្រើ។ នៅក្នុងបរិបទនេះគឺជាគំរូបង្រួបបង្រួមឡូជីខលដែលអាចមើលឃើញឧទាហរណ៍នៅក្នុងដែនអាជីវកម្មរបស់អ្នក។ ប្រសិនបើអ្នកសួរថា "អ្នកណាជាអតិថិជន" ទៅកាន់បុគ្គលិកដែលពាក់ព័ន្ធនឹងការបញ្ជាទិញ អ្នកនឹងទទួលបាននិយមន័យមួយ ប្រសិនបើអ្នកសួរអ្នកដែលពាក់ព័ន្ធក្នុងការលក់ អ្នកនឹងទទួលបានមួយផ្សេងទៀត ហើយអ្នកសំដែងនឹងផ្តល់ឱ្យអ្នកនូវនិយមន័យទីបី។
ដូច្នេះ បរិបទដែលមានព្រំដែននិយាយថា ប្រសិនបើយើងមិនអាចផ្តល់និយមន័យច្បាស់លាស់នៃអ្នកប្រើប្រាស់សេវាកម្មរបស់យើងទេ ចូរយើងកំណត់ព្រំដែនដែលយើងអាចនិយាយអំពីអត្ថន័យនៃពាក្យនេះ ហើយបន្ទាប់មកកំណត់ចំណុចផ្លាស់ប្តូររវាងនិយមន័យផ្សេងគ្នាទាំងនេះ។ នោះគឺប្រសិនបើយើងកំពុងនិយាយអំពីអតិថិជនពីចំណុចនៃទិដ្ឋភាពនៃការបញ្ជាទិញនេះមានន័យថានេះនិងថាហើយប្រសិនបើពីចំណុចនៃទិដ្ឋភាពនៃការលក់នេះមានន័យថានេះនិងនោះ។
និយមន័យបន្ទាប់នៃសេវាមីក្រូគឺការរុំព័ទ្ធនៃប្រតិបត្តិការខាងក្នុងណាមួយ ការពារ "ការលេចធ្លាយ" នៃធាតុផ្សំនៃដំណើរការការងារទៅក្នុងបរិស្ថាន។ បន្ទាប់មក "និយមន័យនៃកិច្ចសន្យាច្បាស់លាស់សម្រាប់អន្តរកម្មខាងក្រៅ ឬទំនាក់ទំនងខាងក្រៅ" ដែលត្រូវបានតំណាងដោយគំនិតនៃកិច្ចសន្យាដែលត្រឡប់មកពី SLAs ។ និយមន័យចុងក្រោយគឺជាពាក្យប្រៀបធៀបនៃកោសិកា ឬកោសិកាដែលមានន័យថាការបំប្លែងពេញលេញនៃសំណុំនៃប្រតិបត្តិការនៅក្នុងសេវាមីក្រូ និងវត្តមាននៅក្នុងវានៃអ្នកទទួលសម្រាប់ការទំនាក់ទំនងជាមួយពិភពខាងក្រៅ។
ដូច្នេះហើយ យើងបាននិយាយទៅកាន់បុរសនៅ Bell Computers ថា "យើងមិនអាចជួសជុលភាពច្របូកច្របល់ណាមួយដែលអ្នកបានបង្កើតបានទេ ពីព្រោះអ្នកមិនមានលុយដើម្បីធ្វើវា ប៉ុន្តែយើងនឹងជួសជុលសេវាកម្មតែមួយគត់ដើម្បីធ្វើឱ្យវាទាំងអស់ អារម្មណ៍។” នៅពេលនេះ ខ្ញុំនឹងចាប់ផ្តើមដោយប្រាប់អ្នកពីរបៀបដែលយើងជួសជុលសេវាកម្មតែមួយគត់របស់យើង ដើម្បីឱ្យវាឆ្លើយតបទៅនឹងសំណើលឿនជាង 9 នាទីកន្លះ។
៣៧:៤០ នាទី
នឹងបន្តក្នុងពេលឆាប់ៗនេះ...
ការផ្សាយពាណិជ្ជកម្មតិចតួច
សូមអរគុណចំពោះការស្នាក់នៅជាមួយពួកយើង។ តើអ្នកចូលចិត្តអត្ថបទរបស់យើងទេ? ចង់មើលខ្លឹមសារគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតទេ? គាំទ្រយើងដោយការបញ្ជាទិញឬណែនាំដល់មិត្តភក្តិ, , analogue តែមួយគត់នៃម៉ាស៊ីនមេកម្រិតធាតុ ដែលត្រូវបានបង្កើតឡើងដោយពួកយើងសម្រាប់អ្នក៖ (អាចប្រើបានជាមួយ RAID1 និង RAID10 រហូតដល់ 24 cores និងរហូតដល់ 40GB DDR4)។
Dell R730xd 2x ថោកជាងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ Equinix Tier IV នៅទីក្រុង Amsterdam? នៅទីនេះ នៅប្រទេសហូឡង់! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ចាប់ពី $99! អានអំពី
ប្រភព: www.habr.com