ដំណើរការមិនត្រឹមតែប៉ុណ្ណោះ៖ របៀបដែលយើងបង្កើតមូលដ្ឋានទិន្នន័យចែកចាយពី Kafka Stream និងអ្វីដែលបានមកពីវា។

ហេហេ!

យើងរំលឹកអ្នកថាធ្វើតាមសៀវភៅអំពី កាកាកា។ យើង​បាន​បោះពុម្ព​ផ្សាយ​ការងារ​គួរ​ឱ្យ​ចាប់​អារម្មណ៍​ស្មើ​គ្នា​អំពី​បណ្ណាល័យ Kafka Stream API.

សម្រាប់ពេលនេះ សហគមន៍គ្រាន់តែសិក្សាពីដែនកំណត់នៃឧបករណ៍ដ៏មានឥទ្ធិពលនេះ។ ដូច្នេះ អត្ថបទ​មួយ​ត្រូវ​បាន​ចុះ​ផ្សាយ​នា​ពេល​ថ្មី​ៗ​នេះ ដែល​ជា​ការ​បក​ប្រែ​ដែល​យើង​ចង់​ណែនាំ​អ្នក​ឲ្យ​ស្គាល់។ តាមបទពិសោធន៍ផ្ទាល់ខ្លួន អ្នកនិពន្ធប្រាប់ពីរបៀបបង្វែរ Kafka Stream ទៅជាកន្លែងផ្ទុកទិន្នន័យចែកចាយ។ សូមរីករាយអាន!

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

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

ប្រសិនបើអ្នកចាប់អារម្មណ៍លើវិធីសាស្រ្តជំនួសដែលអនុញ្ញាតឱ្យអ្នកប្រើមូលដ្ឋានទិន្នន័យកណ្តាលតែមួយដើម្បីគាំទ្រស្ថានភាពផ្លូវការនៃវត្ថុរបស់អ្នក អានវា វានឹងគួរឱ្យចាប់អារម្មណ៍ ...

ហេតុ​អ្វី​បាន​ជា​យើង​គិត​ថា​ដល់​ពេល​ត្រូវ​ផ្លាស់​ប្តូរ​របៀប​ធ្វើ​ការ​ជាមួយ​រដ្ឋ​រួម

យើងត្រូវរក្សាស្ថានភាពនៃវត្ថុផ្សេងៗដោយផ្អែកលើរបាយការណ៍ភ្នាក់ងារ (ឧទាហរណ៍៖ តើគេហទំព័រនេះស្ថិតនៅក្រោមការវាយប្រហារ)? មុនពេលធ្វើចំណាកស្រុកទៅកាន់ Kafka Stream យើងតែងតែពឹងផ្អែកលើមូលដ្ឋានទិន្នន័យកណ្តាលតែមួយ (+ API សេវាកម្ម) សម្រាប់ការគ្រប់គ្រងរដ្ឋ។ វិធីសាស្រ្តនេះមានគុណវិបត្តិរបស់វា: កាលបរិច្ឆេទនៃស្ថានភាពដែលពឹងផ្អែកខ្លាំង ការរក្សាភាពស៊ីសង្វាក់គ្នា និងការធ្វើសមកាលកម្មក្លាយជាបញ្ហាប្រឈមពិតប្រាកដ។ មូលដ្ឋានទិន្នន័យអាចក្លាយជាឧបសគ្គ ឬបញ្ចប់នៅក្នុង ស្ថានភាពប្រណាំង និងទទួលរងពីការមិនអាចទាយទុកជាមុនបាន។

រូបភាពទី 1៖ សេណារីយ៉ូនៃរដ្ឋបំបែកធម្មតាដែលឃើញមុនពេលការផ្លាស់ប្តូរទៅ
Kafka និង Kafka Stream៖ ភ្នាក់ងារទំនាក់ទំនងទស្សនៈរបស់ពួកគេតាមរយៈ API ស្ថានភាពដែលបានធ្វើបច្ចុប្បន្នភាពត្រូវបានគណនាតាមរយៈមូលដ្ឋានទិន្នន័យកណ្តាល

ជួបជាមួយ Kafka Stream ដែលធ្វើឱ្យវាងាយស្រួលក្នុងការបង្កើតសេវាមីក្រូរដ្ឋដែលបានចែករំលែក

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

សេវាមីក្រូហិរញ្ញវត្ថុនីមួយៗដែលយើងបានបង្កើតត្រូវបានបង្កើតឡើងនៅលើកំពូលនៃ Kafka Stream instance ជាមួយនឹង topology សាមញ្ញសមរម្យ។ វាមាន 1) ប្រភព 2) ខួរក្បាលដែលមានឃ្លាំងតម្លៃជាប់លាប់ 3) លិចមួយ:

រូបភាពទី 2៖ តូប៉ូឡូញលំនាំដើមនៃឧទាហរណ៍ការផ្សាយរបស់យើងសម្រាប់សេវាមីក្រូរដ្ឋ។ ចំណាំថាមានឃ្លាំងនៅទីនេះផងដែរដែលមានទិន្នន័យមេតានៃផែនការ។

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

រូបភាពទី 3៖ លំហូរការងារឧទាហរណ៍ថ្មីសម្រាប់សេណារីយ៉ូជាមួយសេវាកម្មមីក្រូចែករំលែក៖ 1) ភ្នាក់ងារបង្កើតសារដែលមកដល់ប្រធានបទប្រភព Kafka ។ 2) សេវាមីក្រូដែលមានរដ្ឋចែករំលែក (ដោយប្រើ Kafka Stream) ដំណើរការវា ហើយសរសេរស្ថានភាពដែលបានគណនាទៅប្រធានបទ Kafka ចុងក្រោយ។ បន្ទាប់ពីនោះ 3) អ្នកប្រើប្រាស់ទទួលយករដ្ឋថ្មី។

ហេ ហាងតម្លៃដែលភ្ជាប់មកជាមួយនេះពិតជាមានប្រយោជន៍ខ្លាំងណាស់!

ដូចដែលបានរៀបរាប់ខាងលើ Topology រដ្ឋដែលបានចែករំលែករបស់យើងមានឃ្លាំងតម្លៃគន្លឹះ។ យើងបានរកឃើញជម្រើសជាច្រើនសម្រាប់ការប្រើប្រាស់វា ហើយពីរក្នុងចំណោមពួកវាត្រូវបានពិពណ៌នាខាងក្រោម។

ជម្រើសទី 1៖ ប្រើឃ្លាំងតម្លៃសម្រាប់ការគណនា

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

រូបភាពទី 4៖ យើងបើកការចូលទៅកាន់ឃ្លាំងតម្លៃសម្រាប់វិធីសាស្ត្រដំណើរការរបស់ processor (បន្ទាប់ពីនេះ រាល់ស្គ្រីបដែលដំណើរការជាមួយរដ្ឋចែករំលែកត្រូវតែអនុវត្តវិធីសាស្ត្រ doProcess)

ជម្រើសទី 2៖ ការបង្កើត CRUD API នៅលើកំពូលនៃ Kafka Stream

ដោយបានបង្កើតលំហូរការងារជាមូលដ្ឋានរបស់យើង យើងបានចាប់ផ្តើមព្យាយាមសរសេរ RESTful CRUD API សម្រាប់សេវាមីក្រូរដ្ឋដែលបានចែករំលែករបស់យើង។ យើង​ចង់​អាច​ទៅ​យក​ស្ថានភាព​របស់​វត្ថុ​មួយ​ចំនួន ឬ​ទាំងអស់ ព្រម​ទាំង​កំណត់ ឬ​លុប​ស្ថានភាព​របស់​វត្ថុ​ចេញ (មាន​ប្រយោជន៍​សម្រាប់​ការ​គាំទ្រ​ផ្នែក​ខាងក្រោយ)។

ដើម្បីគាំទ្រ Get State API ទាំងអស់ នៅពេលណាដែលយើងត្រូវការដើម្បីគណនាឡើងវិញនូវស្ថានភាពកំឡុងពេលដំណើរការ យើងបានរក្សាទុកវានៅក្នុងឃ្លាំងតម្លៃសោដែលមានស្រាប់ក្នុងរយៈពេលយូរ។ ក្នុងករណីនេះ វាគឺសាមញ្ញណាស់ក្នុងការអនុវត្ត API បែបនេះដោយប្រើឧទាហរណ៍តែមួយនៃ Kafka Stream ដូចដែលបានបង្ហាញក្នុងបញ្ជីខាងក្រោម៖

រូបភាពទី 5: ការប្រើប្រាស់ឃ្លាំងតម្លៃដែលភ្ជាប់មកជាមួយ ដើម្បីទទួលបានស្ថានភាពដែលបានគណនាជាមុននៃវត្ថុ

ការធ្វើបច្ចុប្បន្នភាពស្ថានភាពនៃវត្ថុតាមរយៈ API ក៏ងាយស្រួលក្នុងការអនុវត្តផងដែរ។ ជាទូទៅអ្វីដែលអ្នកត្រូវធ្វើគឺបង្កើតអ្នកផលិត Kafka ហើយប្រើវាដើម្បីបង្កើតកំណត់ត្រាដែលមានរដ្ឋថ្មី។ នេះធានាថាសារទាំងអស់ដែលបានបង្កើតតាមរយៈ API នឹងត្រូវបានដំណើរការតាមរបៀបដូចគ្នានឹងសារដែលទទួលបានពីអ្នកផលិតផ្សេងទៀត (ឧទាហរណ៍ភ្នាក់ងារ)។

រូបភាពទី 6: អ្នកអាចកំណត់ស្ថានភាពរបស់វត្ថុដោយប្រើអ្នកផលិត Kafka

ភាពស្មុគស្មាញតូច: Kafka មានភាគថាសជាច្រើន។

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

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

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

រូបភាពទី 7: ដោយប្រើទិន្នន័យមេតាស្ទ្រីម យើងកំណត់ពីវត្ថុណាមួយដែលត្រូវសួរស្ថានភាពនៃវត្ថុដែលចង់បាន។ វិធីសាស្រ្តស្រដៀងគ្នានេះត្រូវបានប្រើជាមួយ GET ALL API

ការរកឃើញសំខាន់ៗ

ហាងរបស់រដ្ឋនៅក្នុង Kafka Stream អាចបម្រើជាមូលដ្ឋានទិន្នន័យចែកចាយជាក់ស្តែង។

• ចម្លងជាបន្តបន្ទាប់នៅក្នុង Kafka
• CRUD API អាចត្រូវបានបង្កើតឡើងយ៉ាងងាយស្រួលនៅលើកំពូលនៃប្រព័ន្ធបែបនេះ
• ការគ្រប់គ្រងភាគថាសច្រើនគឺស្មុគស្មាញបន្តិច
• វាក៏អាចធ្វើទៅបានផងដែរក្នុងការបន្ថែមហាងរដ្ឋមួយ ឬច្រើនទៅក្នុង topology ស្ទ្រីម ដើម្បីរក្សាទុកទិន្នន័យជំនួយ។ ជម្រើសនេះអាចត្រូវបានប្រើសម្រាប់៖
• ការផ្ទុកទិន្នន័យរយៈពេលវែងដែលត្រូវការសម្រាប់ការគណនាកំឡុងពេលដំណើរការស្ទ្រីម
• ការផ្ទុកទិន្នន័យរយៈពេលវែងដែលអាចមានប្រយោជន៍នៅពេលក្រោយដែលការផ្សាយព័ត៌មានត្រូវបានផ្តល់ជូន
• ជា​ច្រើន​ទៀត...

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

ប្រភព: www.habr.com