សេវាមីក្រូ៖ តើវាជាអ្វី ហេតុអ្វីពួកគេមាន និងពេលណាត្រូវអនុវត្តវា។

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

ច្បាប់របស់ Conway និងទំនាក់ទំនងរវាងអាជីវកម្ម អង្គការ និងប្រព័ន្ធព័ត៌មាន

ជាថ្មីម្តងទៀតខ្ញុំនឹងអនុញ្ញាតឱ្យខ្លួនខ្ញុំដកស្រង់:

"អង្គការណាក៏ដោយដែលរចនាប្រព័ន្ធ (ក្នុងន័យទូលំទូលាយ) នឹងទទួលបានការរចនាដែលរចនាសម្ព័ន្ធរបស់វាចម្លងរចនាសម្ព័ន្ធនៃក្រុមនៅក្នុងអង្គការនោះ។"
- Melvyn Conway, 1967

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

ទិសដៅអាជីវកម្មនៃប្រព័ន្ធព័ត៌មាន

ខ្ញុំសូមពន្យល់ជាមួយឧទាហរណ៍មួយ។ ចូរនិយាយថាមានឱកាសអាជីវកម្មមួយដើម្បីរៀបចំអាជីវកម្មលក់ភីហ្សា។ នៅក្នុងកំណែ V1 (សូមហៅវាថាព័ត៌មានមុន) ក្រុមហ៊ុនគឺជាហាងភីហ្សា ការចុះឈ្មោះសាច់ប្រាក់ និងសេវាកម្មដឹកជញ្ជូន។ កំណែនេះត្រូវបានប្រើប្រាស់បានយូរនៅក្នុងលក្ខខណ្ឌនៃភាពប្រែប្រួលនៃបរិស្ថានទាប។ បន្ទាប់មកកំណែទី 2 បានមកជំនួសវា - កាន់តែទំនើប និងអាចប្រើប្រព័ន្ធព័ត៌មានជាស្នូលសម្រាប់អាជីវកម្មជាមួយនឹងស្ថាបត្យកម្ម monolithic ។ ហើយនៅទីនេះ តាមគំនិតរបស់ខ្ញុំ មានភាពអយុត្តិធម៌ដ៏គួរឱ្យភ័យខ្លាចទាក់ទងនឹង monoliths - ស្ថាបត្យកម្ម monolithic ដែលត្រូវបានចោទប្រកាន់មិនទាក់ទងទៅនឹងគំរូអាជីវកម្មដែន. បាទ/ចាស ប្រសិនបើនេះជាដូច្នេះ ប្រព័ន្ធនឹងមិនអាចដំណើរការបានទាល់តែសោះ - ផ្ទុយពីច្បាប់ និងសុភវិនិច្ឆ័យរបស់ Conway ដូចគ្នា។ ទេ ស្ថាបត្យកម្ម monolithic គឺស្របទាំងស្រុងជាមួយនឹងគំរូអាជីវកម្មនៅដំណាក់កាលនៃការអភិវឌ្ឍន៍អាជីវកម្មនេះ - ជាការពិតណាស់ ខ្ញុំមានន័យថាដំណាក់កាលដែលប្រព័ន្ធត្រូវបានបង្កើត និងដាក់ឱ្យដំណើរការរួចហើយ។ វាគឺជាការពិតដ៏អស្ចារ្យមួយដែលមិនគិតពីវិធីសាស្រ្តស្ថាបត្យកម្ម ទាំងស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្មកំណែ 3 និងស្ថាបត្យកម្មមីក្រូសឺវីសកំណែ N នឹងដំណើរការបានល្អដូចគ្នា។ តើចាប់បានអ្វី?

អ្វីគ្រប់យ៉ាងហូរ អ្វីគ្រប់យ៉ាងផ្លាស់ប្តូរ ឬជាសេវាកម្មមីក្រូជាមធ្យោបាយដើម្បីប្រយុទ្ធប្រឆាំងនឹងភាពស្មុគស្មាញ?

មុនពេលយើងបន្ត សូមមើលការយល់ខុសមួយចំនួនអំពីស្ថាបត្យកម្មមីក្រូសេវាកម្ម។

អ្នកគាំទ្រនៃការប្រើប្រាស់វិធីសាស្រ្ត microservice ជារឿយៗប្រកែកថាការបំបែក monolith ទៅជា microservices ធ្វើឱ្យវិធីសាស្រ្តអភិវឌ្ឍន៍មានភាពងាយស្រួលដោយកាត់បន្ថយមូលដ្ឋានកូដនៃសេវាកម្មបុគ្គល។ តាមគំនិតរបស់ខ្ញុំ សេចក្តីថ្លែងការណ៍នេះគឺមិនសមហេតុសមផលពេញលេញ។ ជាក់ស្តែង អន្តរកម្មជាក់ស្តែងនៅក្នុងកូដ monolith និង homogeneous ហាក់ដូចជាស្មុគស្មាញមែនទេ? ប្រសិនបើនេះពិតជាករណីមែននោះ គម្រោងទាំងអស់នឹងចាប់ផ្តើមសាងសង់ជាសេវាកម្មខ្នាតតូច ខណៈដែលការអនុវត្តបង្ហាញថាការផ្ទេរពី monolith ទៅ microservices គឺជារឿងធម្មតាជាង។ ភាពស្មុគស្មាញមិនរលាយបាត់ទេ វាគ្រាន់តែផ្លាស់ទីពីម៉ូឌុលនីមួយៗទៅចំណុចប្រទាក់ (មិនថាជារថយន្តក្រុងទិន្នន័យ RPC APIs និងពិធីការផ្សេងទៀត) និងប្រព័ន្ធរៀបចំ។ ហើយនេះពិបាកណាស់!

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

វដ្តជីវិតផលិតផល និងវដ្តជីវិតសេវាកម្ម

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

ចូរបន្តទៅដំណាក់កាលបន្ទាប់ក្នុងការវិវត្តន៍នៃប្រព័ន្ធព័ត៌មាន - ទៅកាន់ស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្មរបស់ SOA ។ ដូច្នេះ នៅចំណុចជាក់លាក់ណាមួយ យើងបានគូសបញ្ជាក់នៅក្នុងផលិតផលរបស់យើង។ សេវាកម្មដែលមានអាយុកាលយូរ - មានអាយុវែងក្នុងន័យថា នៅពេលផ្លាស់ប្តូររវាងកំណែនៃផលិតផល មានឱកាសដែលវដ្តជីវិតនៃសេវាកម្មនឹងវែងជាងវដ្តជីវិតនៃកំណែបន្ទាប់នៃផលិតផល។ វា​នឹង​សមហេតុសមផល​ក្នុង​ការ​មិន​ផ្លាស់ប្តូរ​ពួកគេ​ទាល់តែសោះ - យើង អ្វីដែលសំខាន់គឺល្បឿននៃការផ្លាស់ប្តូរទៅកំណែបន្ទាប់. ប៉ុន្តែជាអកុសល យើងត្រូវបានគេបង្ខំឱ្យធ្វើការផ្លាស់ប្តូរឥតឈប់ឈរចំពោះសេវាកម្ម ហើយនៅទីនេះអ្វីគ្រប់យ៉ាងដំណើរការសម្រាប់យើង ការអនុវត្ត DevOps ការដាក់កុងតឺន័រ និងអ្វីៗផ្សេងទៀតដែលគិតដល់។ ប៉ុន្តែទាំងនេះនៅតែមិនមែនជាសេវាកម្មខ្នាតតូច!

Microservices ជាមធ្យោបាយមួយដើម្បីប្រយុទ្ធប្រឆាំងនឹងភាពស្មុគស្មាញ... ការគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធ

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

ការរកឃើញ

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

ប្រភព: www.habr.com