🥇Service mesh use case

ចំណាំ។ បកប្រែ៖ អ្នកនិពន្ធអត្ថបទនេះ (Luc Perkins) គឺជាអ្នកតស៊ូមតិអ្នកអភិវឌ្ឍន៍នៅអង្គការ CNCF ដែលជាផ្ទះសម្រាប់គម្រោងប្រភពបើកចំហដូចជា Linkerd, SMI (Service Mesh Interface) និង Kuma (ដោយវិធីនេះ តើអ្នកក៏ឆ្ងល់ដែរទេថាហេតុអ្វីបានជា Istio ជា មិនមាននៅក្នុងបញ្ជីនេះទេ? ជាថ្មីម្តងទៀតការព្យាយាមនាំយកសហគមន៍ DevOps នូវការយល់ដឹងកាន់តែច្បាស់អំពីការឃោសនាបំផ្លើសដែលហៅថា "សេវាសំណាញ់" គាត់រាយបញ្ជីសមត្ថភាពលក្ខណៈ 16 ដែលដំណោះស្រាយបែបនេះផ្តល់។

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

* ចំណាំ ការបកប្រែ៖ នៅទីនេះ និងបន្ថែមទៀតនៅក្នុងអត្ថបទ ការបកប្រែនេះ ("សេវាសំណាញ់") នឹងត្រូវបានប្រើសម្រាប់ សំណាញ់សេវាពាក្យថ្មីនៅឡើយ។

ប៉ុន្តែជាដំបូងខ្ញុំចង់កត់ចំណាំមួយចំនួន៖

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

បញ្ជីខ្លី៖

ការរកឃើញសេវាកម្ម;
ការអ៊ិនគ្រីប;
ការផ្ទៀងផ្ទាត់និងការអនុញ្ញាត;
តុល្យភាពបន្ទុក;
ការបំបែកសៀគ្វី;
ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ;
ការដាក់ពង្រាយ Canary;
ការដាក់ពង្រាយពណ៌ខៀវបៃតង;
ត្រួតពិនិត្យសុខភាព;
ការផ្ទុកបន្ទុក;
កញ្ចក់ចរាចរណ៍;
អ៊ីសូឡង់;
ការកំណត់អត្រាការស្នើសុំ ការព្យាយាម និងការអស់ពេល;
តេឡេម៉ែត្រ;
សវនកម្ម;
ការមើលឃើញ។

1. ការរកឃើញសេវាកម្ម

TL;DR៖ ភ្ជាប់ទៅសេវាកម្មផ្សេងទៀតនៅលើបណ្តាញដោយប្រើឈ្មោះសាមញ្ញ។

សេវាកម្មគួរតែអាច "ស្វែងរក" គ្នាទៅវិញទៅមកដោយស្វ័យប្រវត្តិដោយប្រើឈ្មោះគ្រប់គ្រាន់ - ឧទាហរណ៍ service.api.production, pets/staging ឬ cassandra. បរិស្ថានពពកមានភាពយឺតយ៉ាវ ហើយឈ្មោះតែមួយអាចលាក់ករណីជាច្រើននៃសេវាកម្មមួយ។ វាច្បាស់ណាស់ថាក្នុងស្ថានភាពបែបនេះ វាមិនអាចទៅរួចទេក្នុងការ hardcode អាសយដ្ឋាន IP ទាំងអស់។

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

សំណាញ់សេវាកម្មនីមួយៗអនុវត្តយន្តការស្វែងរកសេវាកម្មខុសៗគ្នា។ នៅពេលនេះ វិធីទូទៅបំផុតគឺផ្ទេរសិទ្ធិទៅដំណើរការខាងក្រៅដូចជា Kubernetes DNS ជាដើម។ កាលពីមុននៅលើ Twitter យើងបានប្រើប្រព័ន្ធដាក់ឈ្មោះសម្រាប់គោលបំណងនេះ។ ចប់. លើសពីនេះ បច្ចេកវិទ្យាសេវាសំណាញ់ធ្វើឱ្យវាអាចទៅរួចសម្រាប់យន្តការដាក់ឈ្មោះផ្ទាល់ខ្លួនលេចឡើង (ទោះបីជាខ្ញុំមិនទាន់បានឃើញការអនុវត្ត SM ជាមួយមុខងារបែបនេះក៏ដោយ)។

2. ការអ៊ិនគ្រីប

TL;DR៖ កម្ចាត់ចរាចរដែលមិនបានអ៊ិនគ្រីបរវាងសេវាកម្ម និងធ្វើឱ្យដំណើរការនេះមានលក្ខណៈស្វ័យប្រវត្តិ និងអាចធ្វើមាត្រដ្ឋានបាន។

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

ជាការពិតណាស់សម្រាប់សំណាញ់សេវា mTLS ស្រេចចិត្ត. សេវាកម្មនីមួយៗអាចថែរក្សា TLS របស់ខ្លួនបាន ប៉ុន្តែនេះមានន័យថាអ្នកនឹងត្រូវស្វែងរកវិធីដើម្បីបង្កើតវិញ្ញាបនបត្រ ចែកចាយវានៅទូទាំងម៉ាស៊ីនសេវា និងរួមបញ្ចូលកូដនៅក្នុងកម្មវិធីដែលនឹងផ្ទុកវិញ្ញាបនបត្រទាំងនេះពីឯកសារ។ បាទ/ចាស កុំភ្លេចបន្តវិញ្ញាបនបត្រទាំងនេះនៅចន្លោះពេលទៀងទាត់។ សេវា Meshes ស្វ័យប្រវត្តិកម្ម mTLS ជាមួយប្រព័ន្ធដូចជា SPIFFEដែលធ្វើឱ្យដំណើរការនៃការចេញ និងបង្វិលវិញ្ញាបនបត្រដោយស្វ័យប្រវត្តិ។

3. ការផ្ទៀងផ្ទាត់ និងការអនុញ្ញាត

TL;DR៖ កំណត់ថាតើនរណាជាអ្នកស្នើសុំ ហើយកំណត់នូវអ្វីដែលពួកគេត្រូវបានអនុញ្ញាតឱ្យធ្វើ មុនពេលសំណើឈានដល់សេវាកម្ម។

សេវាកម្មតែងតែចង់ដឹង នរណា អនុវត្តសំណើ (ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ) និងការប្រើប្រាស់ព័ត៌មាននេះ សម្រេចចិត្ត ថា អង្គភាពដែលបានផ្តល់ឱ្យត្រូវបានអនុញ្ញាតឱ្យធ្វើ (ការអនុញ្ញាត) ។ ក្នុងករណីនេះសព្វនាម "អ្នកណា" អាចលាក់:

សេវាកម្មផ្សេងៗ។ វាត្រូវបានគេហៅថា "ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ" ។ មិត្តភក្ដិ" ឧទាហរណ៍សេវាកម្ម web ចង់ចូលប្រើសេវាកម្ម db. បណ្តាញសេវាជាធម្មតាដោះស្រាយបញ្ហាបែបនេះដោយប្រើ mTLS៖ វិញ្ញាបនបត្រក្នុងករណីនេះដើរតួជាឧបករណ៍កំណត់អត្តសញ្ញាណចាំបាច់។
អ្នកប្រើប្រាស់មនុស្សមួយចំនួន។ វាត្រូវបានគេហៅថា "ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ" ។ សំណើ" ឧទាហរណ៍អ្នកប្រើប្រាស់ haxor69 ចង់ទិញចង្កៀងថ្មី។ សំណាញ់សេវាកម្មផ្តល់នូវយន្តការផ្សេងៗ ឧ. និមិត្តសញ្ញាបណ្តាញ JSON.
ពួកយើងជាច្រើនបានធ្វើវានៅក្នុងកូដកម្មវិធី។ សំណើមួយចូលមក យើងមើលតាមតារាង usersស្វែងរកអ្នកប្រើប្រាស់ ហើយប្រៀបធៀបពាក្យសម្ងាត់ បន្ទាប់មកពិនិត្យជួរឈរ permissions ល។ ក្នុងករណីនៃសេវាសំណាញ់មួយ វាកើតឡើងមុនពេលសំណើឈានដល់សេវា។

នៅពេលដែលយើងកំណត់បានថាតើសំណើនោះមកពីណា យើងត្រូវកំណត់ថាតើអង្គភាពនេះត្រូវបានអនុញ្ញាតឱ្យធ្វើអ្វី។ សំណាញ់សេវាកម្មមួយចំនួនអនុញ្ញាតឱ្យអ្នកកំណត់គោលការណ៍ជាមូលដ្ឋាន (អំពីអ្នកណាអាចធ្វើអ្វីបាន) ជាឯកសារ YAML ឬនៅលើបន្ទាត់ពាក្យបញ្ជា ខណៈពេលដែលអ្នកផ្សេងទៀតផ្តល់នូវការរួមបញ្ចូលជាមួយក្របខ័ណ្ឌដូចជា បើកភ្នាក់ងារគោលនយោបាយ. គោលដៅចុងក្រោយគឺសម្រាប់សេវាកម្មរបស់អ្នកដើម្បីទទួលយកសំណើណាមួយដោយសុវត្ថិភាព ដោយសន្មត់ថាវាមកពីប្រភពដែលអាចទុកចិត្តបាន។ и សកម្មភាពនេះត្រូវបានអនុញ្ញាត។

4. ផ្ទុកតុល្យភាព

TL;DR៖ ចែកចាយបន្ទុកឆ្លងកាត់សេវាកម្មតាមគំរូជាក់លាក់មួយ។

"សេវាកម្ម" នៅក្នុងផ្នែកសេវាកម្មជាញឹកញាប់មានឧទាហរណ៍ស្រដៀងគ្នាជាច្រើន។ ឧទាហរណ៍ថ្ងៃនេះសេវាកម្ម cache មាន 5 ច្បាប់ចម្លង ហើយថ្ងៃស្អែកចំនួនរបស់ពួកគេអាចកើនឡើងដល់ 11 ។ សំណើដែលបានផ្ញើទៅ cacheត្រូវតែចែកចាយស្របតាមគោលបំណងជាក់លាក់។ ជាឧទាហរណ៍ កាត់បន្ថយភាពយឺតយ៉ាវជាអតិបរមា ឬបង្កើនប្រូបាប៊ីលីតេនៃការទៅដល់កន្លែងធ្វើការ។ ក្បួនដោះស្រាយដែលប្រើជាទូទៅបំផុតគឺ Round-robin ប៉ុន្តែមានច្រើនផ្សេងទៀត - ឧទាហរណ៍ វិធីសាស្ត្រទម្ងន់ (មានទម្ងន់) សំណួរ (អ្នកអាចជ្រើសរើសគោលដៅដែលពេញចិត្ត) រោទ៍ (ចិញ្ចៀន) hashing (ដោយប្រើ hashing ជាប់លាប់នៅទូទាំង upstream hosts) ឬវិធីសាស្រ្តស្នើសុំយ៉ាងហោចណាស់ (ចំណូលចិត្តត្រូវបានផ្តល់ទៅឱ្យ instance ជាមួយនឹងសំណើតិចតួចបំផុត) ។

ឧបករណ៍តុល្យភាពបុរាណមានមុខងារផ្សេងទៀតដូចជា HTTP caching និងការការពារ DDoS ប៉ុន្តែវាមិនពាក់ព័ន្ធខ្លាំងសម្រាប់ចរាចរណ៍ខាងកើត-ខាងលិច (នោះគឺសម្រាប់ចរាចរដែលហូរក្នុងមជ្ឈមណ្ឌលទិន្នន័យ - ប្រហាក់ប្រហែល transl ។ ) (វិសាលភាពនៃបណ្តាញសេវាធម្មតា) ។ ជាការពិតណាស់ វាមិនចាំបាច់ប្រើសេវាសំណាញ់សម្រាប់តុល្យភាពបន្ទុកនោះទេ ប៉ុន្តែវាអនុញ្ញាតឱ្យអ្នកកំណត់ និងគ្រប់គ្រងគោលការណ៍សមតុល្យសម្រាប់សេវាកម្មនីមួយៗពីស្រទាប់គ្រប់គ្រងកណ្តាល ដោយហេតុនេះការលុបបំបាត់តម្រូវការក្នុងការដំណើរការ និងកំណត់រចនាសម្ព័ន្ធតុល្យភាពផ្ទុកដាច់ដោយឡែកនៅក្នុងជង់បណ្តាញ។ .

5. ការបំបែកសៀគ្វី

TL;DR៖ បញ្ឈប់ចរាចរណ៍ទៅកាន់សេវាកម្មដែលមានបញ្ហា និងគ្រប់គ្រងការខូចខាតក្នុងករណីធ្ងន់ធ្ងរបំផុត។

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

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

អ្នកប្រហែលជាមិនចង់បំពានការបំបែកសៀគ្វីទេ ប៉ុន្តែវាជាការប្រសើរណាស់ដែលដឹងថាអ្នកមានគម្រោងបម្រុងទុកក្នុងករណីមានអាសន្ន។

6. ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ

TL;DR៖ បង្កើន ឬបន្ថយចំនួននៃសេវាកម្ម អាស្រ័យលើលក្ខណៈវិនិច្ឆ័យដែលបានបញ្ជាក់។

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

ឧទាហរណ៍ Kubernetes ធ្វើមាត្រដ្ឋានសេវាកម្មដោយផ្អែកលើ CPU និងការប្រើប្រាស់អង្គចងចាំរបស់ pods (សូមមើលរបាយការណ៍របស់យើង "ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ និងការគ្រប់គ្រងធនធាននៅក្នុង Kubernetes" - ប្រហែល។ បកប្រែ។ )ប៉ុន្តែប្រសិនបើអ្នកសម្រេចចិត្តធ្វើមាត្រដ្ឋានដោយផ្អែកលើម៉ែត្រផ្សេងទៀត (ក្នុងករណីរបស់យើង ទាក់ទងនឹងចរាចរណ៍) អ្នកនឹងត្រូវការម៉ែត្រពិសេស។ ការគ្រប់គ្រង ដូចនេះ បង្ហាញពីរបៀបធ្វើវាជាមួយ ប្រេសិត, អ៊ីស៊ីអូ и Prometheusប៉ុន្តែដំណើរការខ្លួនវាគឺស្មុគស្មាញណាស់។ យើងចង់ឱ្យបណ្តាញសេវាសម្រួលនេះដោយអនុញ្ញាតឱ្យយើងកំណត់លក្ខខណ្ឌដូចជា "បង្កើនចំនួនករណីសេវា authប្រសិនបើចំនួនសំណើដែលមិនទាន់សម្រេចលើសពីកម្រិតកំណត់ក្នុងរយៈពេលមួយនាទី។"

7. ការដាក់ពង្រាយ Canary

TL;DR៖ សាកល្បងមុខងារថ្មី ឬកំណែសេវាកម្មនៅលើសំណុំរងនៃអ្នកប្រើប្រាស់។

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

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

8. ការដាក់ពង្រាយពណ៌ខៀវបៃតង

TL;DR៖ បញ្ចេញមុខងារថ្មីដ៏ត្រជាក់ ប៉ុន្តែត្រូវរៀបចំដើម្បីយកអ្វីគ្រប់យ៉ាងមកវិញភ្លាមៗ។

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

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

ចំណាំ។ បកប្រែ៖ អ្នកអាចអានបន្ថែមអំពីយុទ្ធសាស្ត្រដាក់ពង្រាយផ្សេងៗនៅក្នុង Kubernetes (រួមទាំង Canary ដែលបានរៀបរាប់ ខៀវ/បៃតង និងផ្សេងទៀត) នៅក្នុង អត្ថបទនេះ.

9. ពិនិត្យសុខភាព

TL;DR៖ តាមដានថាតើសេវាកម្មណាមួយមានមុខងារ និងឆ្លើយតបទៅនឹងអ្វីដែលលែងមានមុខងារ។

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

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

10. ផ្ទុកស្រក់

TL;DR៖ ប្តូរទិសចរាចរណ៍ក្នុងការឆ្លើយតបទៅនឹងការកើនឡើងជាបណ្តោះអាសន្នក្នុងការប្រើប្រាស់។

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

11. ភាពស្របគ្នានៃចរាចរណ៍/ការឆ្លុះកញ្ចក់

TL;DR៖ ផ្ញើសំណើមួយទៅកន្លែងជាច្រើនក្នុងពេលតែមួយ។

ពេលខ្លះមានតម្រូវការក្នុងការផ្ញើសំណើមួយ (ឬជម្រើសជាក់លាក់នៃសំណើ) ទៅកាន់សេវាកម្មជាច្រើនក្នុងពេលតែមួយ។ ឧទាហរណ៍ធម្មតាមួយគឺការបញ្ជូនផ្នែកនៃចរាចរផលិតកម្មទៅកាន់សេវាកម្មដំណាក់កាល។ ម៉ាស៊ីនមេបណ្តាញផលិតកម្មចម្បងផ្ញើសំណើទៅសេវាកម្មចុះក្រោម products.production ហើយចំពោះគាត់តែប៉ុណ្ណោះ។ ហើយសេវាសំណាញ់ចម្លងសំណើនេះដោយឆ្លាតវៃ ហើយផ្ញើវាទៅ products.stagingដែលម៉ាស៊ីនមេគេហទំព័រមិនដឹងសូម្បីតែ។

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

12. អ៊ីសូឡង់

TL;DR៖ បំបែកបណ្តាញសេវារបស់អ្នកទៅជាបណ្តាញខ្នាតតូច។

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

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

13. ស្នើសុំការកំណត់អត្រា ការព្យាយាម និងការអស់ពេល

TL;DR៖ អ្នកលែងត្រូវការបញ្ចូលកិច្ចការគ្រប់គ្រងសំណើ nitty-gritty នៅក្នុងមូលដ្ឋានកូដរបស់អ្នកទៀតហើយ។

អ្វីៗទាំងអស់នេះអាចត្រូវបានចាត់ទុកថាជាករណីប្រើប្រាស់ដាច់ដោយឡែក ប៉ុន្តែខ្ញុំបានសម្រេចចិត្តបញ្ចូលវាដោយសារតែមុខងារទូទៅមួយ៖ ពួកគេគ្រប់គ្រងលើសំណើរគ្រប់គ្រងវដ្តជីវិតដែលជាធម្មតាត្រូវបានគ្រប់គ្រងដោយបណ្ណាល័យកម្មវិធី។ ប្រសិនបើអ្នកកំពុងបង្កើតម៉ាស៊ីនមេគេហទំព័រនៅក្នុង Ruby on Rails (មិនរួមបញ្ចូលជាមួយបណ្តាញសេវា) ដែលធ្វើការស្នើសុំទៅកាន់សេវាកម្ម backend តាមរយៈ gRPCកម្មវិធីនឹងត្រូវសម្រេចចិត្តថាត្រូវធ្វើអ្វីប្រសិនបើសំណើ N បរាជ័យ។ អ្នកក៏នឹងត្រូវស្វែងរកថាតើសេវាទាំងនេះនឹងអាចដំណើរការ និង hardcode ប៉ារ៉ាម៉ែត្រទាំងនេះបានប៉ុន្មានដោយប្រើបណ្ណាល័យពិសេស។ លើសពីនេះ កម្មវិធីនឹងត្រូវសម្រេចចិត្តថាពេលណាដល់ពេលដែលត្រូវបោះបង់ ហើយអនុញ្ញាតឱ្យសំណើរនេះរលត់ទៅវិញ (ផ្អែកលើការអស់ពេល)។ ហើយដើម្បីផ្លាស់ប្តូរប៉ារ៉ាម៉ែត្រខាងលើណាមួយ ម៉ាស៊ីនមេគេហទំព័រនឹងត្រូវបញ្ឈប់ កំណត់រចនាសម្ព័ន្ធឡើងវិញ និងចាប់ផ្តើមម្តងទៀត។

ការបញ្ជូនភារកិច្ចទាំងនេះទៅបណ្តាញសេវាមិនត្រឹមតែមានន័យថាអ្នកអភិវឌ្ឍន៍សេវាកម្មនឹងមិនចាំបាច់គិតអំពីពួកគេប៉ុណ្ណោះទេ ប៉ុន្តែពួកគេក៏អាចមើលបានក្នុងលក្ខណៈសកលផងដែរ។ ប្រសិនបើខ្សែសង្វាក់នៃសេវាកម្មស្មុគស្មាញត្រូវបានប្រើប្រាស់ និយាយថា A -> B -> C -> D -> E នោះវដ្តជីវិតទាំងមូលនៃសំណើត្រូវតែយកមកពិចារណា។ ប្រសិនបើភារកិច្ចគឺដើម្បីពង្រីកការអស់ពេលនៅក្នុងសេវាកម្ម C វាជាឡូជីខលក្នុងការធ្វើវាទាំងអស់ក្នុងពេលតែមួយ មិនមែននៅក្នុងផ្នែកទេ៖ ដោយធ្វើបច្ចុប្បន្នភាពលេខកូដសេវាកម្ម ហើយរង់ចាំរហូតដល់សំណើទាញត្រូវបានទទួលយក ហើយប្រព័ន្ធ CI ដាក់ពង្រាយសេវាកម្មដែលបានធ្វើបច្ចុប្បន្នភាព។

14. Telemetry

TL;DR៖ ប្រមូលព័ត៌មានចាំបាច់ទាំងអស់ (និងមិនពិត) ពីសេវាកម្ម។

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

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

កន្ទុយកំណត់ហេតុពីសេវាកម្មជាក់លាក់មួយនៅក្នុង CLI;
ត្រួតពិនិត្យបរិមាណនៃសំណើពីផ្ទាំងគ្រប់គ្រងសំណាញ់សេវា;
ប្រមូលដានដែលបានចែកចាយ ហើយបញ្ជូនវាទៅប្រព័ន្ធដូចជា Jaeger ។

ការយកចិត្តទុកដាក់, ការវិនិច្ឆ័យប្រធានបទ: និយាយជាទូទៅ តេឡេម៉ែត្រគឺជាតំបន់មួយដែលការជ្រៀតជ្រែកយ៉ាងខ្លាំងពីបណ្តាញសេវាគឺមិនចង់បាន។ ការប្រមូលព័ត៌មានជាមូលដ្ឋាន និងតាមដានការវាស់វែងមាសមួយចំនួនដូចជាអត្រាជោគជ័យនៃសំណើ និងការពន្យាពេលគឺល្អ ប៉ុន្តែយើងសង្ឃឹមថាយើងមិនឃើញបណ្តុំ Frankenstein លេចឡើងដែលព្យាយាមជំនួសប្រព័ន្ធឯកទេស ដែលមួយចំនួនបានបង្ហាញឱ្យឃើញរួចមកហើយ និងបានសិក្សាយ៉ាងល្អ។ .

15. សវនកម្ម

TL;DR៖ អ្នកដែលភ្លេចមេរៀនប្រវត្តិសាស្ត្រនឹងត្រូវវិនាសដើម្បីធ្វើវាឡើងវិញ។

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

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

16. មើលជាមុន

TL;DR៖ React.js រស់នៅបានយូរ - ប្រភពដែលមិនអាចខ្វះបាននៃចំណុចប្រទាក់ពុម្ពអក្សរក្បូរក្បាច់។

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

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

មិនត្រូវបានបញ្ចូលក្នុងបញ្ជី

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

មជ្ឈមណ្ឌលទិន្នន័យច្រើន។. នៅក្នុងគំនិតរបស់ខ្ញុំ, នេះមិនមែនជាករណីប្រើប្រាស់ច្រើនទេដែលជាតំបន់តូចចង្អៀតនិងជាក់លាក់នៃការអនុវត្តនៃសំណាញ់សេវាឬសំណុំនៃមុខងារមួយចំនួនដូចជាការរកឃើញសេវា។
ចូល និង ចេញ. នេះគឺជាផ្នែកដែលពាក់ព័ន្ធ ប៉ុន្តែខ្ញុំបានកំណត់ខ្លួនឯង (ប្រហែលជាសិប្បនិម្មិត) ចំពោះករណីប្រើប្រាស់ "ចរាចរណ៍ខាងកើត-ខាងលិច"។ Ingress និង egress សមនឹងទទួលបានអត្ថបទដាច់ដោយឡែកមួយ។

សេចក្តីសន្និដ្ឋាន

នោះហើយជាទាំងអស់សម្រាប់ពេលនេះ! ជាថ្មីម្តងទៀត បញ្ជីនេះគឺបំពានខ្លាំងណាស់ ហើយទំនងជាមិនពេញលេញ។ ប្រសិនបើអ្នកគិតថាខ្ញុំខកខានអ្វីមួយ ឬមានអ្វីខុស សូមទាក់ទងមកខ្ញុំតាម Twitter (@lucckerkins) សូមគោរពច្បាប់នៃសេចក្តីថ្លៃថ្នូរ។

PS ពីអ្នកបកប្រែ

ចំណងជើងរូបភាពសម្រាប់អត្ថបទគឺផ្អែកលើរូបភាពពីអត្ថបទ "តើ Service Mesh ជាអ្វី (ហើយពេលណាត្រូវប្រើមួយ)?(ដោយ Gregory MacKinnon) ។ វាបង្ហាញពីរបៀបដែលមុខងារមួយចំនួនពីកម្មវិធី (ជាពណ៌បៃតង) បានផ្លាស់ប្តូរទៅបណ្តាញសេវាដែលផ្តល់នូវទំនាក់ទំនងអន្តរកម្មរវាងពួកវា (ជាពណ៌ខៀវ)។

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

ប្រភព: www.habr.com