ប្រព័ន្ធគ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធបណ្តាញត្រង Qrator

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

Qrator Labs ដំណើរការបណ្តាញកាត់បន្ថយការវាយប្រហារដែលចែកចាយទូទាំងពិភពលោក។ បណ្តាញរបស់យើងដំណើរការលើគោលការណ៍ anycast ហើយបណ្តាញរងត្រូវបានផ្សព្វផ្សាយតាមរយៈ BGP ។ ក្នុងនាមជាបណ្តាញ BGP anycast ដែលមានទីតាំងនៅក្នុងតំបន់ជាច្រើននៃផែនដី យើងអាចដំណើរការ និងត្រងចរាចរណ៍ខុសច្បាប់កាន់តែជិតទៅនឹងស្នូលនៃអ៊ីនធឺណិត - ប្រតិបត្តិករលំដាប់ថ្នាក់ 1 ។

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

នៅដើមដំបូងគឺជាព្រះបន្ទូល។ វាបានក្លាយជាពិធីការទំនាក់ទំនងយ៉ាងឆាប់រហ័សដែលត្រូវការការអាប់ដេត។

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

ជាលទ្ធផលយើងបានបង្កើតគ្រោងការណ៍ដូចខាងក្រោមៈ

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

គុណភាពនៃការតភ្ជាប់អ៊ីធឺណិតនៅតែប្រែប្រួលយ៉ាងទូលំទូលាយនៅជុំវិញពិភពលោក - ដើម្បីបង្ហាញពីចំណុចនេះ សូមក្រឡេកមើល MTR ដ៏សាមញ្ញមួយពីទីក្រុង Prague សាធារណរដ្ឋឆេក ទៅសិង្ហបុរី និងហុងកុង។

MTR ពី Prague ទៅសិង្ហបុរី

រឿងដូចគ្នាទៅនឹងហុងកុង

ភាពយឺតយ៉ាវខ្ពស់មានន័យថាល្បឿនទាប។ លើសពីនេះទៀតមានការបាត់បង់កញ្ចប់ព័ត៌មាន។ ទទឹងឆានែលមិនផ្តល់សំណងសម្រាប់បញ្ហានេះទេដែលត្រូវតែយកមកពិចារណាជានិច្ចនៅពេលសាងសង់ប្រព័ន្ធវិមជ្ឈការ។

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

ការរចនាស្ថេរភាពថ្មីៗ

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

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

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

ស្ថាបត្យកម្មនៃការដឹកជញ្ជូនពីរកម្រិត

ហេតុអ្វី​បាន​ជា​យើង​បង្កើត​ការ​ដឹក​ជញ្ជូន​របស់​យើង​ជា​ពីរ​កម្រិត? ចម្លើយគឺសាមញ្ញណាស់ - យើងចង់បំបែកផ្លូវចេញពីតក្កវិជ្ជាកម្រិតខ្ពស់ ដោយទទួលយកការបំផុសគំនិតពីគំរូ OSI ជាមួយនឹងការដឹកជញ្ជូន និងស្រទាប់កម្មវិធីរបស់វា។ យើងបានប្រើ Thrift សម្រាប់តួនាទីនៃពិធីការដឹកជញ្ជូន និងទម្រង់ msgpack serialization សម្រាប់ទម្រង់កម្រិតខ្ពស់នៃសារត្រួតពិនិត្យ។ នេះ​ជា​មូលហេតុ​ដែល​រ៉ោតទ័រ (ដំណើរការ​ពហុខាស/ផ្សាយ/បញ្ជូនត) មិន​មើល​ទៅ​ក្នុង msgpack មិន​ខ្ចប់ ឬ​ខ្ចប់​មាតិកា​មក​វិញ ហើយ​បញ្ជូន​តែ​ទិន្នន័យ​ប៉ុណ្ណោះ។

Thrift (មកពីភាសាអង់គ្លេស - "thrift" បញ្ចេញសំឡេង [θrift]) គឺជាភាសាពិពណ៌នាចំណុចប្រទាក់ដែលត្រូវបានប្រើដើម្បីកំណត់ និងបង្កើតសេវាកម្មសម្រាប់ភាសាសរសេរកម្មវិធីផ្សេងៗ។ វាជាក្របខ័ណ្ឌសម្រាប់ការហៅតាមនីតិវិធីពីចម្ងាយ (RPC)។ រួមបញ្ចូលគ្នានូវបំពង់ផ្នែកទន់ជាមួយនឹងម៉ាស៊ីនបង្កើតកូដ ដើម្បីបង្កើតសេវាកម្មដែលដំណើរការច្រើន ឬតិចប្រកបដោយប្រសិទ្ធភាព និងងាយស្រួលរវាងភាសា។

យើងបានជ្រើសរើសក្របខ័ណ្ឌ Thrift ដោយសារតែ RPC និងការគាំទ្រសម្រាប់ភាសាជាច្រើន។ ដូចធម្មតា ផ្នែកងាយស្រួលគឺម៉ាស៊ីនភ្ញៀវ និងម៉ាស៊ីនមេ។ ទោះជាយ៉ាងណាក៏ដោយ រ៉ោតទ័របានប្រែក្លាយទៅជាគ្រាប់ដ៏លំបាកក្នុងការបំបែក ដែលមួយផ្នែកដោយសារតែការខ្វះដំណោះស្រាយដែលត្រៀមរួចជាស្រេចកំឡុងពេលអភិវឌ្ឍរបស់យើង។

មានជម្រើសផ្សេងទៀតដូចជា protobuf / gRPC ទោះយ៉ាងណានៅពេលយើងចាប់ផ្តើមគម្រោងរបស់យើង gRPC គឺថ្មីណាស់ ហើយយើងមិនហ៊ានយកវានៅលើយន្តហោះទេ។

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

Msgpack គឺស្រដៀងទៅនឹង JSON ប៉ុន្តែលឿន និងតូចជាង។ វាជាទម្រង់សៀរៀលទិន្នន័យគោលពីរ ដែលអនុញ្ញាតឱ្យទិន្នន័យត្រូវបានផ្លាស់ប្តូររវាងភាសាជាច្រើន។

នៅកម្រិតទីមួយ យើងមាន Thrift ជាមួយនឹងព័ត៌មានអប្បបរមាដែលចាំបាច់សម្រាប់រ៉ោតទ័រដើម្បីបញ្ជូនសារ។ នៅកម្រិតទីពីរមានរចនាសម្ព័ន្ធ msgpack ខ្ចប់។

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

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

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

ដើម្បីបង្កើតឯកសារកំណត់រចនាសម្ព័ន្ធ យើងត្រូវការសំណើ JMESPath គំរូសម្រាប់ទីតាំងឯកសារក្នុង FS និងគំរូសម្រាប់ការកំណត់រចនាសម្ព័ន្ធខ្លួនឯង។ វាក៏ជាគំនិតល្អនៅដំណាក់កាលនេះផងដែរ ដើម្បីបញ្ជាក់ការអនុញ្ញាតឯកសារ។ ទាំងអស់នេះត្រូវបានរួមបញ្ចូលគ្នាដោយជោគជ័យនៅក្នុងឯកសារមួយ - មុនពេលចាប់ផ្តើមនៃគំរូកំណត់រចនាសម្ព័ន្ធ យើងបានដាក់បឋមកថាក្នុងទម្រង់ YAML ដែលពិពណ៌នាអំពីអ្វីដែលនៅសល់។

ឧទាហរណ៍:

---
selector: "[@][[email protected]._meta.version == `42`] | items([0].fft_config || `{}`)"
destination_filename: "fft/{{ match[0] }}.json"
file_mode: 0644
reload_daemons: [fft] ...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}


ដើម្បីបង្កើតឯកសារកំណត់រចនាសម្ព័ន្ធសម្រាប់សេវាកម្មថ្មី យើងគ្រាន់តែបន្ថែមឯកសារគំរូថ្មីប៉ុណ្ណោះ។ គ្មានការផ្លាស់ប្តូរកូដប្រភព ឬកម្មវិធីនៅលើចំណុចវត្តមានគឺត្រូវបានទាមទារ។

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

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

សូមអរគុណចំពោះជំនួយរបស់អ្នកក្នុងការសរសេរសម្ភារៈ។ វ៉ុលឡង់ដាមរ៉ូដ, សេរិនហៃ, ណ.

ភាសាអង់គ្លេស ប្រកាស។

ប្រភព: www.habr.com