សួស្តី ហាប! ខ្ញុំសូមបង្ហាញជូនអ្នកនូវការបកប្រែអត្ថបទ "Service mesh data plane vs control plane" អ្នកនិពន្ធ ម៉ាត់ខេលីន.

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

ដោយសារគំនិតនៃ "Service mesh" មានការពេញនិយមកាន់តែខ្លាំងឡើងក្នុងរយៈពេលពីរឆ្នាំចុងក្រោយនេះ (អត្ថបទដើមថ្ងៃទី 10 ខែតុលា ឆ្នាំ 2017) ហើយចំនួនអ្នកចូលរួមនៅក្នុងលំហរបានកើនឡើង ខ្ញុំបានឃើញការកើនឡើងនៃការភាន់ច្រលំក្នុងចំនោមមនុស្សទាំងអស់។ សហគមន៍បច្ចេកវិទ្យាទាក់ទងនឹងរបៀបប្រៀបធៀប និងដំណោះស្រាយខុសគ្នា។

ស្ថានភាពត្រូវបានសង្ខេបយ៉ាងល្អបំផុតដោយស៊េរី tweets ខាងក្រោមដែលខ្ញុំបានសរសេរក្នុងខែកក្កដា៖

ភាពច្របូកច្របល់នៃបណ្តាញសេវា #1: Linkerd ~ = Nginx ~ = Haproxy ~ = ប្រេសិត។ គ្មាននរណាម្នាក់ក្នុងចំណោមពួកគេស្មើនឹង Istio ទេ។ Istio គឺជាអ្វីដែលខុសគ្នាទាំងស្រុង។ ១/

ទីមួយគឺគ្រាន់តែជាយន្តហោះទិន្នន័យ។ ដោយខ្លួនឯងពួកគេមិនធ្វើអ្វីទេ។ ពួកគេត្រូវតែស្ថិតក្នុងអារម្មណ៍សម្រាប់អ្វីមួយបន្ថែមទៀត។ ២/

Istio គឺជាឧទាហរណ៍នៃយន្តហោះបញ្ជាដែលភ្ជាប់ផ្នែកជាមួយគ្នា។ នេះគឺជាស្រទាប់មួយទៀត។ / បញ្ចប់

ធ្វីតធឺមុនៗនិយាយអំពីគម្រោងផ្សេងៗគ្នាជាច្រើន (Linkerd, NGINX, HAProxy, Envoy, និង Istio) ប៉ុន្តែសំខាន់ជាងនេះទៅទៀតណែនាំអំពីគោលគំនិតទូទៅនៃយន្តហោះទិន្នន័យ បណ្តាញសេវា និងយន្តហោះបញ្ជា។ នៅក្នុងការប្រកាសនេះ ខ្ញុំនឹងបោះជំហានថយក្រោយ ហើយនិយាយអំពីអ្វីដែលខ្ញុំមានន័យដោយពាក្យ "យន្តហោះទិន្នន័យ" និង "យន្តហោះបញ្ជា" នៅកម្រិតខ្ពស់បំផុត ហើយបន្ទាប់មកនិយាយអំពីរបៀបដែលលក្ខខណ្ឌអនុវត្តចំពោះគម្រោងដែលបានរៀបរាប់នៅក្នុងធ្វីត។

តើ​អ្វី​ទៅ​ជា​សំណាញ់​សេវា?

រូបភាពទី 1: ទិដ្ឋភាពទូទៅនៃសំណាញ់សេវាកម្ម

រូបភាពទី 1 ។ បង្ហាញពីគំនិតនៃសេវាសំណាញ់នៅកម្រិតមូលដ្ឋានបំផុតរបស់វា។ មានចង្កោមសេវាកម្មចំនួនបួន (AD) ។ សេវាកម្មនីមួយៗត្រូវបានភ្ជាប់ជាមួយម៉ាស៊ីនមេប្រូកស៊ីមូលដ្ឋាន។ ចរាចរណ៍បណ្តាញទាំងអស់ (HTTP, REST, gRPC, Redis ។ វិធីនេះ កម្មវិធីមិន​ដឹង​អំពី​បណ្តាញ​ទាំងមូល ហើយ​ដឹង​តែ​ប្រូកស៊ី​មូលដ្ឋាន​របស់វា​ប៉ុណ្ណោះ។ ជាធរមាន បណ្តាញប្រព័ន្ធចែកចាយត្រូវបានដកចេញពីសេវាកម្ម។

យន្តហោះទិន្នន័យ

នៅក្នុងបណ្តាញសេវា ប្រូកស៊ីម៉ាស៊ីនមេដែលមានទីតាំងនៅមូលដ្ឋានសម្រាប់កម្មវិធីអនុវត្តភារកិច្ចដូចខាងក្រោមៈ

• ការរកឃើញសេវាកម្ម. តើសេវាកម្ម/កម្មវិធីអ្វីខ្លះដែលមានសម្រាប់កម្មវិធីរបស់អ្នក?
• ការពិនិត្យសុខភាព. តើ​ករណី​ផ្តល់​សេវា​ត្រឡប់​ដោយ​ការ​រក​ឃើញ​សេវា​មាន​សុខភាព​ល្អ និង​ត្រៀម​ខ្លួន​ជា​ស្រេច​ដើម្បី​ទទួល​យក​ចរាចរណ៍​បណ្តាញ​ឬ​ទេ? នេះអាចរួមបញ្ចូលទាំងសកម្ម (ឧ. ការឆ្លើយតប/ការពិនិត្យសុខភាព) និងអកម្ម (ឧ. ការប្រើ 3 កំហុស 5xx ជាប់ៗគ្នាជាការចង្អុលបង្ហាញអំពីស្ថានភាពសេវាមិនល្អ) ការពិនិត្យសុខភាព។
• ការនាំផ្លូវ. នៅពេលទទួលបានសំណើទៅ "/foo" ពីសេវាកម្ម REST តើក្រុមសេវាកម្មមួយណាគួរផ្ញើសំណើទៅ?
• ផ្ទុកតុល្យភាព. នៅពេលដែលចង្កោមសេវាកម្មត្រូវបានជ្រើសរើសកំឡុងពេលបញ្ជូន តើសំណើរគួរតែផ្ញើទៅកាន់សេវាកម្មមួយណា? តើអស់ពេលប៉ុន្មាន? ជាមួយនឹងការកំណត់ការបំបែកសៀគ្វីអ្វីខ្លះ? ប្រសិនបើសំណើនេះបរាជ័យ តើគួរសាកល្បងឡើងវិញទេ?
• ការផ្ទៀងផ្ទាត់ និងការអនុញ្ញាត. សម្រាប់សំណើចូល តើសេវាកម្មហៅទូរសព្ទអាចត្រូវបានកំណត់អត្តសញ្ញាណ/អនុញ្ញាតដោយប្រើ mTLS ឬយន្តការផ្សេងទៀតដែរឬទេ? ប្រសិនបើវាត្រូវបានទទួលស្គាល់/អនុញ្ញាត តើវាត្រូវបានអនុញ្ញាតឱ្យហៅទៅប្រតិបត្តិការដែលបានស្នើសុំ (ចំណុចបញ្ចប់) លើសេវាកម្មនេះ ឬគួរឆ្លើយតបដែលមិនបានផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវត្រូវបានបញ្ជូនមកវិញទេ?
• ការសង្កេត. ស្ថិតិលម្អិត កំណត់ហេតុ/កំណត់ហេតុ និងទិន្នន័យដានដែលបានចែកចាយគួរតែត្រូវបានបង្កើតសម្រាប់សំណើនីមួយៗ ដើម្បីឱ្យប្រតិបត្តិករអាចយល់អំពីលំហូរចរាចរណ៍ដែលបានចែកចាយ និងបញ្ហាបំបាត់កំហុសនៅពេលពួកគេកើតឡើង។

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

យន្តហោះគ្រប់គ្រង

អរូបីបណ្តាញដែលប្រូកស៊ីក្នុងស្រុកផ្តល់នៅក្នុងយន្តហោះទិន្នន័យគឺវេទមន្ត(?)។ ទោះជាយ៉ាងណាក៏ដោយ តើប្រូកស៊ីដឹងយ៉ាងដូចម្ដេចអំពីផ្លូវ "/foo" ទៅកាន់សេវាកម្ម B? តើសេវាកម្មរកឃើញទិន្នន័យដែលផ្ទុកដោយសំណើប្រូកស៊ីត្រូវប្រើយ៉ាងដូចម្តេច? តើ​ប៉ារ៉ាម៉ែត្រ​ត្រូវ​បាន​កំណត់​រចនាសម្ព័ន្ធ​ដោយ​របៀប​ណា​សម្រាប់​តុល្យភាព​បន្ទុក ការ​អស់​ពេល ការ​ដាច់​សៀគ្វី​ជាដើម? តើ​អ្នក​ដាក់​ឱ្យ​ប្រើ​កម្មវិធី​ដោយ​របៀប​ណា​ដោយ​ប្រើ​វិធី​ខៀវ/បៃតង ឬ​វិធីសាស្ត្រ​ផ្ទេរ​ចរាចរណ៍​ដ៏​ល្អ? តើអ្នកណាកំណត់ការផ្ទៀងផ្ទាត់ប្រព័ន្ធ និងការកំណត់ការអនុញ្ញាត?

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

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

រូបភាពទី 2: យន្តហោះគ្រប់គ្រងមនុស្ស

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

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

រូបភាពទី 3៖ យន្តហោះគ្រប់គ្រងសំណាញ់សេវាកម្រិតខ្ពស់

នៅលើ រូបភាពទី ១ បង្ហាញយន្តហោះគ្រប់គ្រង "ពង្រីក" នៃបណ្តាញសេវា។ វាមានផ្នែកដូចខាងក្រោមៈ

• មនុស្ស៖ នៅតែមានមនុស្សម្នាក់ (សង្ឃឹមថាមិនសូវខឹង) ដែលធ្វើការសម្រេចចិត្តកម្រិតខ្ពស់ទាក់ទងនឹងប្រព័ន្ធទាំងមូលទាំងមូល។
• គ្រប់គ្រង UI យន្តហោះ៖ មនុស្សម្នាក់ធ្វើអន្តរកម្មជាមួយប្រភេទនៃចំណុចប្រទាក់អ្នកប្រើមួយចំនួនដើម្បីគ្រប់គ្រងប្រព័ន្ធ។ នេះអាចជាវិបផតថល កម្មវិធីបន្ទាត់ពាក្យបញ្ជា (CLI) ឬចំណុចប្រទាក់ផ្សេងទៀត។ ដោយប្រើចំណុចប្រទាក់អ្នកប្រើ ប្រតិបត្តិករមានសិទ្ធិចូលប្រើប៉ារ៉ាម៉ែត្រកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធសកលដូចជា៖
  • ការគ្រប់គ្រងការដាក់ពង្រាយ ពណ៌ខៀវ/បៃតង និង/ឬការផ្លាស់ប្តូរចរាចរណ៍បន្តិចម្តងៗ
  • ជម្រើសនៃការផ្ទៀងផ្ទាត់ និងការអនុញ្ញាត
  • ការកំណត់ផ្លូវសម្រាប់តារាងកំណត់ ឧទាហរណ៍នៅពេលដែលកម្មវិធី A ស្នើសុំព័ត៌មានអំពី "/foo" មានអ្វីកើតឡើង
  • ផ្ទុកការកំណត់តុល្យភាព ដូចជាការអស់ពេល ការព្យាយាមឡើងវិញ ការកំណត់ការបំបែកសៀគ្វីជាដើម។
• កម្មវិធីកំណត់ពេលបន្ទុកការងារ៖ សេវាកម្មដំណើរការលើហេដ្ឋារចនាសម្ព័ន្ធតាមរយៈប្រភេទនៃប្រព័ន្ធកំណត់ពេល/វង់តន្រ្តីមួយចំនួនដូចជា Kubernetes ឬ Nomad ។ កម្មវិធីកំណត់ពេលត្រូវទទួលខុសត្រូវក្នុងការផ្ទុកសេវាកម្មរួមជាមួយនឹងប្រូកស៊ីក្នុងស្រុករបស់វា។
• ការរកឃើញសេវាកម្ម. នៅពេលអ្នកកំណត់ពេលចាប់ផ្តើម និងបញ្ឈប់ករណីសេវាកម្ម វារាយការណ៍ពីស្ថានភាពសុខភាពទៅកាន់ប្រព័ន្ធស្វែងរកសេវា។
• APIs ការកំណត់រចនាសម្ព័ន្ធប្រូកស៊ី Sidecar ៖ ប្រូកស៊ីមូលដ្ឋានទាញយកស្ថានភាពយ៉ាងស្វាហាប់ពីសមាសធាតុប្រព័ន្ធផ្សេងៗដោយប្រើគំរូដែលស្របគ្នាជាយថាហេតុដោយគ្មានការជ្រៀតជ្រែកពីប្រតិបត្តិករ។ ប្រព័ន្ធទាំងមូល ដែលរួមមានទាំងសេវាកម្មដែលកំពុងដំណើរការបច្ចុប្បន្ន និងម៉ាស៊ីនមេប្រូកស៊ីក្នុងស្រុក ទីបំផុតបានបញ្ចូលគ្នាទៅជាប្រព័ន្ធអេកូតែមួយ។ API យន្តហោះទិន្នន័យសកលរបស់បេសកជន គឺជាឧទាហរណ៍មួយនៃរបៀបដែលវាដំណើរការក្នុងការអនុវត្ត។

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

យន្តហោះទិន្នន័យ និងយន្តហោះគ្រប់គ្រង។ យន្តហោះទិន្នន័យធៀបនឹងការសង្ខេបយន្តហោះគ្រប់គ្រង

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

ទេសភាពនៃគម្រោងបច្ចុប្បន្ន

ដោយបានយល់ពីការពន្យល់ខាងលើ សូមក្រឡេកមើលស្ថានភាពបច្ចុប្បន្ននៃគម្រោងសេវាសំណាញ់។

• យន្តហោះទិន្នន័យ៖ Linkerd, NGINX, HAProxy, បេសកជន, Traefik
• គ្រប់គ្រងយន្តហោះ៖ Istio, Nelson, SmartStack

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

Linkerd គឺជាម៉ាស៊ីនមេប្រូកស៊ីនៃយន្តហោះទិន្នន័យដំបូងគេសម្រាប់សេវាសំណាញ់នៅដើមឆ្នាំ 2016 ហើយបានធ្វើការងារដ៏អស្ចារ្យក្នុងការបង្កើនការយល់ដឹង និងការយកចិត្តទុកដាក់ចំពោះគំរូរចនាសំណាញ់សេវាកម្ម។ ប្រហែល 6 ខែបន្ទាប់ពីនោះ Envoy បានចូលរួមជាមួយ Linkerd (ទោះបីជាគាត់បាននៅជាមួយ Lyft តាំងពីចុងឆ្នាំ 2015)។ Linkerd និង Envoy គឺជាគម្រោងទាំងពីរដែលត្រូវបានលើកឡើងជាញឹកញាប់បំផុតនៅពេលពិភាក្សាអំពីសេវាសំណាញ់។

Istio ត្រូវបានប្រកាសនៅក្នុងខែឧសភា 2017 ។ គោលដៅនៃគម្រោង Istio គឺស្រដៀងទៅនឹងយន្តហោះបញ្ជាដែលបានពង្រីកដែលបានបង្ហាញនៅក្នុង រូបភាពទី ១. បេសកជនសម្រាប់ Istio គឺជាប្រូកស៊ីលំនាំដើម។ ដូច្នេះ Istio គឺជាយន្តហោះគ្រប់គ្រង ហើយ Envoy គឺជាយន្តហោះទិន្នន័យ។ ក្នុងរយៈពេលដ៏ខ្លី Istio បានបង្កើតនូវភាពរំភើបជាច្រើន ហើយយន្តហោះទិន្នន័យផ្សេងទៀតបានចាប់ផ្តើមធ្វើសមាហរណកម្មជាការជំនួសសម្រាប់ Envoy (ទាំង Linkerd និង NGINX បានបង្ហាញពីការរួមបញ្ចូលជាមួយ Istio) ។ ការពិតដែលថាយន្តហោះទិន្នន័យផ្សេងគ្នាអាចត្រូវបានប្រើនៅក្នុងយន្តហោះគ្រប់គ្រងដូចគ្នា មានន័យថាយន្តហោះគ្រប់គ្រង និងយន្តហោះទិន្នន័យគឺមិនចាំបាច់ភ្ជាប់គ្នាយ៉ាងតឹងរ៉ឹងនោះទេ។ API ដូចជា API យន្តហោះទិន្នន័យទូទៅរបស់ Envoy អាចបង្កើតជាស្ពានរវាងផ្នែកពីរនៃប្រព័ន្ធ។

Nelson និង SmartStack ជួយបង្ហាញបន្ថែមអំពីការបំបែកយន្តហោះគ្រប់គ្រង និងយន្តហោះទិន្នន័យ។ Nelson ប្រើ Envoy ជាប្រូកស៊ីរបស់ខ្លួន និងបង្កើតយន្តហោះត្រួតពិនិត្យដែលអាចទុកចិត្តបានសម្រាប់សេវាសំណាញ់ដោយផ្អែកលើជង់ HashiCorp ពោលគឺឧ។ Nomad ជាដើម។ SmartStack ប្រហែល​ជា​រលក​ទីមួយ​នៃ​បណ្តាញ​សេវា​ថ្មី​។ SmartStack បង្កើតយន្តហោះគ្រប់គ្រងជុំវិញ HAProxy ឬ NGINX ដោយបង្ហាញពីសមត្ថភាពក្នុងការបំបែកយន្តហោះបញ្ជាពីបណ្តាញសេវាពីយន្តហោះទិន្នន័យ។

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

ការដកយកសំខាន់ៗ

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

ប្រភព: www.habr.com