ការផ្លាស់ប្តូរពី monolith ទៅ microservices: ប្រវត្តិសាស្រ្តនិងការអនុវត្ត

នៅក្នុងអត្ថបទនេះ ខ្ញុំនឹងនិយាយអំពីរបៀបដែលគម្រោងដែលខ្ញុំកំពុងធ្វើការលើការបំប្លែងពី monolith ដ៏ធំមួយទៅជាសំណុំនៃ microservices ។

គម្រោងនេះបានចាប់ផ្តើមប្រវត្តិរបស់វាតាំងពីយូរយារណាស់មកហើយ នៅដើមឆ្នាំ 2000។ កំណែដំបូងត្រូវបានសរសេរនៅក្នុង Visual Basic 6។ យូរៗទៅ វាច្បាស់ណាស់ថាការអភិវឌ្ឍន៍នៅក្នុងភាសានេះពិបាកនឹងគាំទ្រនៅពេលអនាគត ដោយសារ IDE ហើយភាសាខ្លួនឯងត្រូវបានអភិវឌ្ឍតិចតួច។ នៅចុងទស្សវត្សរ៍ឆ្នាំ 2000 វាត្រូវបានសម្រេចចិត្តប្តូរទៅ C# ដែលកាន់តែរីកចម្រើន។ កំណែថ្មីត្រូវបានសរសេរស្របជាមួយនឹងការកែប្រែកំណែចាស់ បន្តិចម្តងៗ កូដកាន់តែច្រើនឡើងត្រូវបានសរសេរក្នុង .NET ។ Backend នៅក្នុង C# ដំបូងត្រូវបានផ្តោតលើស្ថាបត្យកម្មសេវាកម្ម ប៉ុន្តែក្នុងអំឡុងពេលនៃការអភិវឌ្ឍន៍ បណ្ណាល័យទូទៅដែលមានតក្កវិជ្ជាត្រូវបានប្រើប្រាស់ ហើយសេវាកម្មត្រូវបានចាប់ផ្តើមនៅក្នុងដំណើរការតែមួយ។ លទ្ធផល​គឺ​ជា​កម្មវិធី​មួយ​ដែល​យើង​ហៅ​ថា "សេវា​ទោល"។

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

យើង​បាន​ចាប់​ផ្តើម​ការងារ​របស់​យើង​លើ​ការ​រលួយ​ប្រហែល​ឆ្នាំ ២០១៥។ យើងមិនទាន់ឈានដល់ស្ថានភាពដ៏ល្អមួយនៅឡើយ - វានៅតែមានផ្នែកនៃគម្រោងធំដែលស្ទើរតែមិនអាចហៅថា monoliths ប៉ុន្តែពួកវាមិនមើលទៅដូចជា microservices ផងដែរ។ ទោះយ៉ាងណាក៏ដោយ វឌ្ឍនភាពមានសារៈសំខាន់។
ខ្ញុំនឹងនិយាយអំពីវានៅក្នុងអត្ថបទ។

មាតិកា

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

ស្ថាបត្យកម្មនិងបញ្ហានៃដំណោះស្រាយដែលមានស្រាប់

ដំបូង ស្ថាបត្យកម្មមើលទៅដូចនេះ៖ UI គឺជាកម្មវិធីដាច់ដោយឡែក ផ្នែក monolithic ត្រូវបានសរសេរនៅក្នុង Visual Basic 6 កម្មវិធី .NET គឺជាសំណុំនៃសេវាកម្មពាក់ព័ន្ធដែលធ្វើការជាមួយមូលដ្ឋានទិន្នន័យធំល្មម។

គុណវិបត្តិនៃដំណោះស្រាយមុន។

ចំណុចតែមួយនៃការបរាជ័យ
យើងមានចំណុចមួយនៃការបរាជ័យ៖ កម្មវិធី .NET បានដំណើរការក្នុងដំណើរការតែមួយ។ ប្រសិនបើម៉ូឌុលណាមួយបរាជ័យ កម្មវិធីទាំងមូលបានបរាជ័យ ហើយត្រូវចាប់ផ្តើមឡើងវិញ។ ដោយសារយើងស្វ័យប្រវត្តិកម្មមួយចំនួនធំនៃដំណើរការសម្រាប់អ្នកប្រើប្រាស់ផ្សេងៗគ្នា ដោយសារការបរាជ័យក្នុងមួយក្នុងចំណោមពួកវា អ្នកគ្រប់គ្នាមិនអាចដំណើរការបានមួយរយៈ។ ហើយក្នុងករណីមានកំហុសផ្នែកទន់ សូម្បីតែការបម្រុងទុកក៏មិនអាចជួយបានដែរ។

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

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

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

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

ការរំពឹងទុកពីសេវាកម្មមីក្រូ

បញ្ហានៃសមាសធាតុនៅពេលរួចរាល់។ ការចែកចាយសមាសធាតុនៅពេលរួចរាល់ដោយការរំលាយដំណោះស្រាយ និងបំបែកដំណើរការផ្សេងៗ។

ក្រុមផលិតផលតូចៗ។ នេះគឺសំខាន់ណាស់ព្រោះថាក្រុមធំដែលធ្វើការលើ monolith ចាស់ពិបាកគ្រប់គ្រង។ ក្រុមបែបនេះត្រូវបានបង្ខំឱ្យធ្វើការស្របតាមដំណើរការដ៏តឹងរឹងមួយ ប៉ុន្តែពួកគេចង់បានភាពច្នៃប្រឌិត និងឯករាជ្យភាពបន្ថែមទៀត។ មានតែក្រុមតូចៗប៉ុណ្ណោះដែលអាចមានលទ្ធភាពទិញវាបាន។

ភាពឯកោនៃសេវាកម្មនៅក្នុងដំណើរការដាច់ដោយឡែក។ តាមឧត្ដមគតិ ខ្ញុំចង់ញែកវានៅក្នុងកុងតឺន័រ ប៉ុន្តែសេវាកម្មមួយចំនួនធំដែលសរសេរនៅក្នុង .NET Framework ដំណើរការតែនៅក្រោម Windowsសេវាកម្មដែលផ្អែកលើ .NET Core ឥឡូវនេះកំពុងលេចចេញជារូបរាងហើយ ប៉ុន្តែនៅតែមានសេវាកម្មមួយចំនួនតូចប៉ុណ្ណោះ។

ភាពបត់បែននៃការដាក់ពង្រាយ។ យើងចង់បញ្ចូលគ្នានូវសេវាកម្មតាមរបៀបដែលយើងត្រូវការ មិនមែនវិធីដែលលេខកូដបង្ខំវានោះទេ។

ការប្រើប្រាស់បច្ចេកវិទ្យាថ្មីៗ។ នេះគួរឱ្យចាប់អារម្មណ៍សម្រាប់អ្នកសរសេរកម្មវិធីណាមួយ។

បញ្ហាផ្លាស់ប្តូរ

ជាការពិតណាស់ ប្រសិនបើវាងាយស្រួលក្នុងការបំបែក monolith ទៅជា microservices នោះ វាមិនចាំបាច់និយាយអំពីវានៅឯសន្និសីទ និងសរសេរអត្ថបទនោះទេ។ មានឧបសគ្គជាច្រើននៅក្នុងដំណើរការនេះ ខ្ញុំនឹងរៀបរាប់អំពីចំណុចសំខាន់ៗដែលរារាំងយើង។

បញ្ហាទីមួយ ធម្មតាសម្រាប់ monoliths ភាគច្រើន៖ ភាពស៊ីសង្វាក់គ្នានៃតក្កវិជ្ជាអាជីវកម្ម។ នៅពេលយើងសរសេរ monolith យើងចង់ប្រើ class របស់យើងឡើងវិញ ដើម្បីកុំឱ្យសរសេរកូដដែលមិនចាំបាច់។ ហើយនៅពេលផ្លាស់ទីទៅសេវាមីក្រូ បញ្ហានេះក្លាយជាបញ្ហា៖ លេខកូដទាំងអស់ត្រូវបានភ្ជាប់គ្នាយ៉ាងតឹងរ៉ឹង ហើយវាពិបាកក្នុងការបំបែកសេវាកម្ម។

នៅពេលចាប់ផ្តើមការងារ ឃ្លាំងមានគម្រោងជាង 500 និងកូដជាង 700 ពាន់ខ្សែ។ នេះ​ជា​ការ​សម្រេច​ចិត្ត​ដ៏​ធំ​មួយ។ បញ្ហាទីពីរ. វាមិនអាចទៅរួចទេក្នុងការយកវាមកចែកជាមីក្រូសេវា។

បញ្ហាទីបី - កង្វះហេដ្ឋារចនាសម្ព័ន្ធចាំបាច់។ តាមពិត យើងកំពុងចម្លងកូដប្រភពដោយដៃទៅម៉ាស៊ីនមេ។

តើធ្វើដូចម្តេចដើម្បីផ្លាស់ទីពី monolith ទៅ microservices

ការផ្តល់សេវាមីក្រូ

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

តើ​យើង​ប្រើ​វិធី​ណា​ខ្លះ​ដើម្បី​ញែក​មីក្រូ​សេវា​ដោយ​ឡែក?

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

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

ការជួបប្រជុំគ្នាជាមួយម៉ាស៊ីនគឺគ្រាន់តែជាកូដមួយជួរនៅក្នុងថ្នាក់កម្មវិធីប៉ុណ្ណោះ។ យើងលាក់ការងារជាមួយ Topshelf នៅក្នុងថ្នាក់ជំនួយ។

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");

       }
    }
}

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

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

វិធីទីបីដើម្បីបែងចែកសេវាមីក្រូមួយដែលយើងប្រើគឺជាក់លាក់បន្តិចសម្រាប់យើង។ នេះគឺជាការដកចេញនូវតក្កវិជ្ជាអាជីវកម្មចេញពីស្រទាប់ UI ។ កម្មវិធី UI ចម្បងរបស់យើងគឺផ្ទៃតុ វាដូចជាផ្នែកខាងក្រោយត្រូវបានសរសេរក្នុង C# ។ អ្នកអភិវឌ្ឍន៍បានធ្វើកំហុសជាទៀងទាត់ និងផ្ទេរផ្នែកនៃតក្កវិជ្ជាទៅ UI ដែលគួរតែមាននៅក្នុងផ្នែកខាងក្រោយ ហើយត្រូវបានប្រើប្រាស់ឡើងវិញ។

ប្រសិនបើអ្នកក្រឡេកមើលឧទាហរណ៍ជាក់ស្តែងពីកូដផ្នែក UI អ្នកអាចមើលឃើញថាភាគច្រើននៃដំណោះស្រាយនេះមានតក្កវិជ្ជាអាជីវកម្មពិតប្រាកដដែលមានប្រយោជន៍ក្នុងដំណើរការផ្សេងទៀត មិនត្រឹមតែសម្រាប់បង្កើតទម្រង់ UI ប៉ុណ្ណោះទេ។

តក្កវិជ្ជា UI ពិតប្រាកដគឺមានតែនៅក្នុងជួរចុងក្រោយប៉ុណ្ណោះ។ យើងបានផ្ទេរវាទៅម៉ាស៊ីនមេ ដើម្បីឱ្យវាអាចប្រើឡើងវិញបាន ដោយកាត់បន្ថយ UI និងសម្រេចបាននូវស្ថាបត្យកម្មត្រឹមត្រូវ។

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

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

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

ដើម្បីបំបែកបរិបទដែលមានព្រំដែនទាំងនេះចេញពីគ្នាទៅវិញទៅមក ហើយចាប់ផ្តើមដំណើរការបំបែកមីក្រូសេវាកម្មចេញពីដំណោះស្រាយ monolithic យើងបានប្រើវិធីសាស្រ្តដូចជាការបង្កើត APIs ខាងក្រៅនៅក្នុងកម្មវិធី។ ប្រសិនបើយើងដឹងថាម៉ូឌុលមួយចំនួនគួរតែក្លាយជាសេវាមីក្រូ ដូចម្ដេចបានកែប្រែនៅក្នុងដំណើរការនោះ នោះយើងភ្លាមៗបានធ្វើការហៅទៅកាន់តក្កវិជ្ជាដែលជាកម្មសិទ្ធិរបស់បរិបទដែលមានកម្រិតមួយផ្សេងទៀតតាមរយៈការហៅខាងក្រៅ។ ឧទាហរណ៍តាមរយៈ REST ឬ WCF ។

យើងបានសម្រេចចិត្តយ៉ាងម៉ឺងម៉ាត់ថា យើងនឹងមិនជៀសវាងកូដដែលទាមទារប្រតិបត្តិការចែកចាយនោះទេ។ ក្នុងករណីរបស់យើង វាប្រែទៅជាងាយស្រួលណាស់ក្នុងការអនុវត្តតាមច្បាប់នេះ។ យើងមិនទាន់ជួបប្រទះស្ថានភាពដែលប្រតិបត្តិការចែកចាយដ៏តឹងរឹងគឺពិតជាត្រូវការ - ភាពស៊ីសង្វាក់គ្នាចុងក្រោយរវាងម៉ូឌុលគឺគ្រប់គ្រាន់ណាស់។

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

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

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

ដំបូងយើងបង្កើត microservice ដោយសរសេរកូដឡើងវិញ។ យើងកំពុងកែលម្អទិដ្ឋភាពមួយចំនួនដែលយើងមិនសប្បាយចិត្ត។ យើងអនុវត្តតម្រូវការអាជីវកម្មថ្មីពីអតិថិជន។ យើងបន្ថែម API Gateway ទៅការតភ្ជាប់រវាង UI និង backend ដែលនឹងផ្តល់ការបញ្ជូនបន្តការហៅទូរសព្ទ។

បន្ទាប់មក យើងបញ្ចេញការកំណត់នេះឱ្យដំណើរការ ប៉ុន្តែស្ថិតក្នុងស្ថានភាពសាកល្បង។ អ្នកប្រើប្រាស់របស់យើងភាគច្រើននៅតែធ្វើការជាមួយដំណើរការអាជីវកម្មចាស់។ សម្រាប់អ្នកប្រើប្រាស់ថ្មី យើងកំពុងបង្កើតកំណែថ្មីនៃកម្មវិធី monolithic ដែលលែងមានដំណើរការនេះទៀតហើយ។ សំខាន់យើងមានការរួមបញ្ចូលគ្នានៃ monolith និង microservice ដែលធ្វើការជាអ្នកបើកយន្តហោះ។

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

សរុបមក យើងប្រើវិធីសាស្រ្តដែលមានស្រាប់ស្ទើរតែទាំងអស់សម្រាប់ការបំបែកកូដប្រភពនៃ monolith មួយ។ ពួកវាទាំងអស់អនុញ្ញាតឱ្យយើងកាត់បន្ថយទំហំនៃផ្នែកនៃកម្មវិធី ហើយបកប្រែវាទៅបណ្ណាល័យថ្មី ធ្វើឱ្យកូដប្រភពប្រសើរជាងមុន។

ធ្វើការជាមួយមូលដ្ឋានទិន្នន័យ

មូលដ្ឋានទិន្នន័យអាចត្រូវបានបែងចែកកាន់តែអាក្រក់ជាងកូដប្រភព ព្រោះវាមិនត្រឹមតែមានគ្រោងការណ៍បច្ចុប្បន្នប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានទិន្នន័យប្រវត្តិសាស្រ្តដែលបានប្រមូលផ្តុំផងដែរ។

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

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

ការបែងចែកដូចគ្នាទៅក្នុងបរិបទដែលមានកម្រិតនៅក្នុងកូដជួយយើងក្នុងការបំបែកខ្លួន។ ជាធម្មតាវាផ្តល់ឱ្យយើងនូវគំនិតដ៏ល្អមួយអំពីរបៀបដែលយើងបំបែកទិន្នន័យនៅកម្រិតមូលដ្ឋានទិន្នន័យ។ យើង​យល់​ថា​តារាង​មួយ​ណា​ជា​របស់​បរិបទ​ដែល​មាន​ព្រំដែន​មួយ និង​មួយ​ណា​ទៅ​មួយ​ទៀត។

យើងបានប្រើវិធីសាស្រ្តសកលចំនួនពីរនៃការបែងចែកមូលដ្ឋានទិន្នន័យ៖ ការបែងចែកតារាងដែលមានស្រាប់ និងការបែងចែកជាមួយដំណើរការ។

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

ត្រូវការផ្នែកដែលមានដំណើរការនៅពេលដែលគំរូអាជីវកម្មបានផ្លាស់ប្តូរយ៉ាងខ្លាំង ហើយតារាងលែងបំពេញចិត្តយើងទៀតហើយ។

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

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

ជំហានបន្ទាប់គឺថា យើងអាចបំបែកផ្នែកនៃកូដដែលធ្វើការជាមួយតារាងដាច់ដោយឡែក ដោយមានឬគ្មានដំណើរការ ចូលទៅក្នុង microservice ដាច់ដោយឡែក ហើយដំណើរការវានៅក្នុងដំណើរការដាច់ដោយឡែក ធុងមួយ។ នេះនឹងជាសេវាកម្មដាច់ដោយឡែកមួយដែលមានការតភ្ជាប់ទៅមូលដ្ឋានទិន្នន័យ monolith និងតារាងទាំងនោះដែលមិនទាក់ទងដោយផ្ទាល់ទៅវា។ monolith នៅតែធ្វើអន្តរកម្មសម្រាប់ការអានជាមួយនឹងផ្នែកដែលអាចផ្ដាច់បាន។

ក្រោយមកយើងនឹងដកការតភ្ជាប់នេះចេញ ពោលគឺការអានទិន្នន័យពីកម្មវិធី monolithic ពីតារាងដាច់ដោយឡែកក៏នឹងត្រូវបានផ្ទេរទៅ API ផងដែរ។

បន្ទាប់ យើងនឹងជ្រើសរើសពីមូលដ្ឋានទិន្នន័យទូទៅ តារាងដែលមានតែសេវាមីក្រូថ្មីប៉ុណ្ណោះដែលដំណើរការ។ យើងអាចផ្លាស់ទីតារាងទៅជាគ្រោងការណ៍ដាច់ដោយឡែក ឬសូម្បីតែទៅមូលដ្ឋានទិន្នន័យរូបវន្តដាច់ដោយឡែក។ វានៅតែមានការតភ្ជាប់ការអានរវាង microservice និង monolith database ប៉ុន្តែមិនមានអ្វីដែលត្រូវព្រួយបារម្ភនោះទេ នៅក្នុងការកំណត់នេះវាអាចរស់នៅបានយូរ។

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

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

ដើម្បីឱ្យគ្រោងការណ៍នេះដំណើរការ យើងទំនងជាត្រូវការរយៈពេលផ្លាស់ប្តូរ។

បន្ទាប់មកមានវិធីសាស្រ្តពីរដែលអាចមាន។

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

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

វិធីសាស្រ្តទាំងពីរដំណើរការ, ជ្រើសរើសអាស្រ័យលើស្ថានភាព។

បន្ទាប់ពីយើងប្រាកដថាអ្វីៗដំណើរការបាន ផ្នែកនៃ monolith ដែលធ្វើការជាមួយរចនាសម្ព័ន្ធមូលដ្ឋានទិន្នន័យចាស់អាចត្រូវបានបិទ។

ជំហានចុងក្រោយគឺត្រូវយករចនាសម្ព័ន្ធទិន្នន័យចាស់ចេញ។

សរុបមក យើងអាចនិយាយបានថា យើងមានបញ្ហាជាមួយ database៖ វាពិបាកក្នុងការធ្វើការជាមួយវា បើធៀបនឹង source code វាពិបាកចែករំលែកជាង ប៉ុន្តែវាអាច និងគួរធ្វើ។ យើងបានរកឃើញវិធីមួយចំនួនដែលអនុញ្ញាតឱ្យយើងធ្វើវាដោយសុវត្ថិភាព ប៉ុន្តែវានៅតែងាយស្រួលក្នុងការធ្វើឱ្យមានកំហុសជាមួយទិន្នន័យជាជាងកូដប្រភព។

ធ្វើការជាមួយកូដប្រភព

នេះគឺជាអ្វីដែលដ្យាក្រាមកូដប្រភពមើលទៅនៅពេលដែលយើងចាប់ផ្តើមវិភាគគម្រោង monolithic ។

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

យើងមានសំណាងដែលមានបណ្ណាល័យហេដ្ឋារចនាសម្ព័ន្ធដែលអាចប្រើបានដោយឡែកពីគ្នា។

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

កង្វល់ដ៏ធំបំផុតគឺបរិបទដែលមានព្រំដែន។ វាបានកើតឡើងដែលបរិបទ 3-4 ត្រូវបានលាយបញ្ចូលគ្នានៅក្នុងសន្និបាតទូទៅមួយ ហើយប្រើប្រាស់គ្នាទៅវិញទៅមកក្នុងមុខងារអាជីវកម្មដូចគ្នា។ វាចាំបាច់ដើម្បីយល់ពីកន្លែងដែលវាអាចបែងចែក និងតាមបណ្តោយព្រំដែនអ្វី និងអ្វីដែលត្រូវធ្វើបន្ទាប់ជាមួយនឹងការគូសផែនទីការបែងចែកនេះទៅជាបណ្តុំកូដប្រភព។

យើងបានបង្កើតច្បាប់ជាច្រើនសម្រាប់ដំណើរការបំបែកកូដ។

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

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

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

បន្ទាប់មកយើងចាប់ផ្តើមផ្លាស់ទីទៅគំរូមួយដែលមានឃ្លាំងដាច់ដោយឡែក។ តក្កវិជ្ជាអាជីវកម្មលែងហូរចេញពីសេវាកម្មមួយទៅសេវាកម្មទៀតហើយ ដែនពិតជាបានក្លាយទៅជាឯករាជ្យ។ បរិបទដែលមានព្រំដែនត្រូវបានគាំទ្រកាន់តែច្បាស់។ តើយើងប្រើបណ្ណាល័យហេដ្ឋារចនាសម្ព័ន្ធឡើងវិញដោយរបៀបណា? យើងបានបំបែកពួកវាទៅក្នុងឃ្លាំងដាច់ដោយឡែកមួយ បន្ទាប់មកដាក់វាចូលទៅក្នុងកញ្ចប់ Nuget ដែលយើងដាក់ចូលទៅក្នុង Artifactory ។ ជាមួយនឹងការផ្លាស់ប្តូរណាមួយ ការប្រមូលផ្តុំ និងការបោះពុម្ពកើតឡើងដោយស្វ័យប្រវត្តិ។

សេវាកម្មរបស់យើងបានចាប់ផ្តើមយោងកញ្ចប់ហេដ្ឋារចនាសម្ព័ន្ធខាងក្នុងតាមរបៀបដូចគ្នានឹងកញ្ចប់ខាងក្រៅដែរ។ យើងទាញយកបណ្ណាល័យខាងក្រៅពី Nuget ។ ដើម្បីធ្វើការជាមួយ Artifactory ដែលជាកន្លែងដែលយើងដាក់កញ្ចប់ទាំងនេះ យើងបានប្រើកម្មវិធីគ្រប់គ្រងកញ្ចប់ពីរ។ នៅក្នុងឃ្លាំងតូចៗ យើងក៏បានប្រើ Nuget ផងដែរ។ នៅក្នុងឃ្លាំងដែលមានសេវាកម្មច្រើន យើងបានប្រើ Paket ដែលផ្តល់នូវភាពស៊ីសង្វាក់គ្នានៃកំណែកាន់តែច្រើនរវាងម៉ូឌុល។

ដូច្នេះ ដោយធ្វើការលើកូដប្រភព ការផ្លាស់ប្តូរស្ថាបត្យកម្មបន្តិច និងការបំបែកឃ្លាំង យើងធ្វើឱ្យសេវាកម្មរបស់យើងកាន់តែមានភាពឯករាជ្យ។

បញ្ហាហេដ្ឋារចនាសម្ព័ន្ធ

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

ការដំឡើងដោយដៃនៅក្នុងបរិស្ថាន

ជាដំបូង យើងបានដំឡើងដំណោះស្រាយសម្រាប់បរិស្ថានដោយដៃ។ ដើម្បីធ្វើស្វ័យប្រវត្តិកម្មដំណើរការនេះ យើងបានបង្កើតបំពង់ CI/CD។ យើងបានជ្រើសរើសដំណើរការចែកចាយបន្ត ពីព្រោះការដាក់ពង្រាយបន្តមិនទាន់អាចទទួលយកបានសម្រាប់យើងពីទស្សនៈនៃដំណើរការអាជីវកម្ម។ ដូច្នេះការផ្ញើសម្រាប់ប្រតិបត្តិការត្រូវបានអនុវត្តដោយប្រើប៊ូតុងមួយហើយសម្រាប់ការធ្វើតេស្ត - ដោយស្វ័យប្រវត្តិ។

យើងប្រើ Atlassian, Bitbucket សម្រាប់ការផ្ទុកកូដប្រភព និង Bamboo សម្រាប់ការសាងសង់។ យើងចូលចិត្តសរសេរ build scripts នៅក្នុង Cake ព្រោះវាដូចគ្នាទៅនឹង C#។ កញ្ចប់ដែលផលិតរួចរាល់បានមកដល់ Artifactory ហើយ Ansible ទទួលបានដោយស្វ័យប្រវត្តិទៅកាន់ម៉ាស៊ីនមេសាកល្បង បន្ទាប់ពីនោះពួកគេអាចធ្វើតេស្តភ្លាមៗ។

ការកាប់ឈើដាច់ដោយឡែក

នៅពេលមួយគំនិតមួយនៃគំនិតរបស់ monolith គឺដើម្បីផ្តល់នូវការកាប់ឈើរួមគ្នា។ យើងក៏ត្រូវយល់ពីអ្វីដែលត្រូវធ្វើជាមួយកំណត់ហេតុបុគ្គលដែលមាននៅលើថាស។ កំណត់ហេតុរបស់យើងត្រូវបានសរសេរជាឯកសារអត្ថបទ។ យើងបានសម្រេចចិត្តប្រើជង់ ELK ស្តង់ដារ។ យើងមិនបានសរសេរទៅ ELK ដោយផ្ទាល់តាមរយៈអ្នកផ្តល់សេវានោះទេ ប៉ុន្តែបានសម្រេចចិត្តថាយើងនឹងកែប្រែកំណត់ហេតុអត្ថបទ និងសរសេរលេខសម្គាល់ដាននៅក្នុងពួកវាជាឧបករណ៍កំណត់អត្តសញ្ញាណ ដោយបន្ថែមឈ្មោះសេវាកម្ម ដូច្នេះកំណត់ហេតុទាំងនេះអាចត្រូវបានញែកនៅពេលក្រោយ។

ជាមួយ Filebeat យើងអាចប្រមូលកំណត់ហេតុរបស់យើងពី ម៉ាស៊ីនបម្រើបន្ទាប់មកបំលែងពួកវា ប្រើ Kibana ដើម្បីបង្កើតសំណួរនៅក្នុង UI ហើយមើលពីរបៀបដែលការហៅត្រូវបានបញ្ជូនរវាងសេវាកម្មនានា។ លេខសម្គាល់តាមដានមានប្រយោជន៍ខ្លាំងណាស់សម្រាប់រឿងនេះ។

សាកល្បង និងបំបាត់កំហុសសេវាកម្មពាក់ព័ន្ធ

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

មានម៉ាស៊ីនមេដែលដំណើរការតែកំណែផលិតកម្មនៃសេវាកម្មប៉ុណ្ណោះ។ ម៉ាស៊ីនមេទាំងនេះត្រូវការជាចាំបាច់ក្នុងករណីមានឧប្បត្តិហេតុ ដើម្បីពិនិត្យមើលការដឹកជញ្ជូនមុនពេលដាក់ឱ្យប្រើប្រាស់ និងសម្រាប់ការបណ្តុះបណ្តាលផ្ទៃក្នុង។

យើងបានបន្ថែមដំណើរការសាកល្បងស្វ័យប្រវត្តិដោយប្រើបណ្ណាល័យ Specflow ដ៏ពេញនិយម។ ការធ្វើតេស្តដំណើរការដោយស្វ័យប្រវត្តិដោយប្រើ NUnit ភ្លាមៗបន្ទាប់ពីការដាក់ពង្រាយពី Ansible ។ ប្រសិនបើការគ្របដណ្តប់ភារកិច្ចគឺដោយស្វ័យប្រវត្តិពេញលេញ នោះមិនចាំបាច់មានការធ្វើតេស្តដោយដៃទេ។ ទោះបីជាពេលខ្លះការធ្វើតេស្តដោយដៃបន្ថែមនៅតែត្រូវបានទាមទារ។ យើងប្រើស្លាកនៅក្នុង Jira ដើម្បីកំណត់ការធ្វើតេស្តណាមួយដែលត្រូវដំណើរការសម្រាប់បញ្ហាជាក់លាក់មួយ។

លើសពីនេះទៀតតម្រូវការសម្រាប់ការធ្វើតេស្តផ្ទុកបានកើនឡើងពីមុនវាត្រូវបានអនុវត្តតែនៅក្នុងករណីដ៏កម្រ។ យើងប្រើ JMeter ដើម្បីដំណើរការតេស្ត InfluxDB ដើម្បីរក្សាទុកពួកវា និង Grafana ដើម្បីបង្កើតក្រាហ្វដំណើរការ។

តើយើងសម្រេចបានអ្វីខ្លះ?

ទីមួយ យើងបានកម្ចាត់គំនិតនៃ "ការដោះលែង" ។ ការចេញផ្សាយដ៏អស្ចារ្យរយៈពេលពីរខែបានកន្លងផុតទៅហើយ នៅពេលដែល colossus នេះត្រូវបានដាក់ពង្រាយនៅក្នុងបរិយាកាសផលិតកម្ម ដែលរំខានដល់ដំណើរការអាជីវកម្មជាបណ្តោះអាសន្ន។ ឥឡូវនេះ យើងដាក់ពង្រាយសេវាកម្មជាមធ្យមរៀងរាល់ 1,5 ថ្ងៃម្តង ដោយដាក់ជាក្រុម ព្រោះវាដំណើរការបន្ទាប់ពីមានការយល់ព្រម។

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

យើងអាចគ្រប់គ្រងលំនាំនៃការដាក់ពង្រាយ។ អ្នកអាចជ្រើសរើសក្រុមសេវាកម្មដាច់ដោយឡែកពីដំណោះស្រាយដែលនៅសល់ ប្រសិនបើចាំបាច់។

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

សង្ខេប

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

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

  PS ជា​រឿង​រំជួល​ចិត្ត​បន្ថែម​ទៀត (ហើយ​ដូច​ជា​សម្រាប់​អ្នក​ផ្ទាល់) - យោង​តាម​ តំណភ្ជាប់.
  នេះគឺជាកំណែពេញលេញនៃរបាយការណ៍។

ប្រភព: www.habr.com