បទពិសោធន៍ក្នុងការអភិវឌ្ឍន៍សេវាកម្មឧបករណ៍បង្វិលសងជាមួយ API អសមកាលនៅលើ Kafka

តើអ្វីអាចបង្ខំក្រុមហ៊ុនដ៏ធំដូចជា Lamoda ជាមួយនឹងដំណើរការដ៏រលូន និងសេវាកម្មដែលទាក់ទងគ្នារាប់សិប ដើម្បីផ្លាស់ប្តូរវិធីសាស្រ្តរបស់ខ្លួនយ៉ាងសំខាន់? ការលើកទឹកចិត្តអាចមានភាពខុសប្លែកគ្នាទាំងស្រុង៖ ពីនីតិប្បញ្ញត្តិ ដល់ការចង់ពិសោធន៍ដែលមាននៅក្នុងអ្នកសរសេរកម្មវិធីទាំងអស់។

ប៉ុន្តែនេះមិនមានន័យថាអ្នកមិនអាចពឹងផ្អែកលើអត្ថប្រយោជន៍បន្ថែមនោះទេ។ Sergey Zaika នឹងប្រាប់អ្នកពីអ្វីដែលអ្នកពិតជាអាចឈ្នះ ប្រសិនបើអ្នកអនុវត្ត API ដែលជំរុញដោយព្រឹត្តិការណ៍នៅលើ Kafka (តិចតួច) វាក៏នឹងមានការនិយាយអំពីការបាញ់ប្រហារដ៏ធំ និងការរកឃើញគួរឱ្យចាប់អារម្មណ៍ផងដែរ - ការពិសោធន៍មិនអាចធ្វើបានដោយគ្មានពួកគេ។

ការបដិសេធ៖ អត្ថបទនេះគឺផ្អែកលើសម្ភារៈដែលបានមកពីការប្រជុំដែលលោក Sergey បានធ្វើឡើងក្នុងខែវិច្ឆិកា ឆ្នាំ 2018 នៅលើ HighLoad++។ បទពិសោធន៍ផ្ទាល់របស់ Lamoda ក្នុងការធ្វើការជាមួយ Kafka បានទាក់ទាញអ្នកស្តាប់មិនតិចជាងរបាយការណ៍ផ្សេងទៀតនៅលើកាលវិភាគនោះទេ។ យើងគិតថានេះជាឧទាហរណ៍ដ៏ល្អមួយ ដែលអ្នកអាច និងគួរតែស្វែងរកមនុស្សដែលមានគំនិតដូចគ្នាជានិច្ច ហើយអ្នករៀបចំកម្មវិធី HighLoad++ នឹងបន្តព្យាយាមបង្កើតបរិយាកាសដែលអំណោយផលដល់រឿងនេះ។

អំពីដំណើរការ

Lamoda គឺជាវេទិកាពាណិជ្ជកម្មអេឡិចត្រូនិចដ៏ធំមួយដែលមានមជ្ឈមណ្ឌលទំនាក់ទំនងផ្ទាល់ខ្លួន សេវាកម្មដឹកជញ្ជូន (និងសាខាជាច្រើន) ស្ទូឌីយោរូបថត ឃ្លាំងដ៏ធំ ហើយអ្វីៗទាំងអស់នេះដំណើរការលើកម្មវិធីផ្ទាល់ខ្លួនរបស់វា។ មានវិធីសាស្រ្តទូទាត់រាប់សិប ដៃគូ b2b ដែលអាចប្រើប្រាស់សេវាកម្មទាំងនេះខ្លះ ឬទាំងអស់ ហើយចង់ដឹងព័ត៌មានថ្មីៗអំពីផលិតផលរបស់ពួកគេ។ លើសពីនេះទៀត Lamoda ប្រតិបត្តិការនៅក្នុងប្រទេសចំនួនបីក្រៅពីសហព័ន្ធរុស្ស៊ីហើយអ្វីគ្រប់យ៉ាងគឺខុសគ្នាបន្តិចបន្តួចនៅទីនោះ។ សរុបមក ប្រហែលជាមានវិធីច្រើនជាងមួយរយក្នុងការកំណត់រចនាសម្ព័ន្ធការបញ្ជាទិញថ្មី ដែលត្រូវតែដំណើរការតាមវិធីរបស់វា។ ទាំងអស់នេះដំណើរការដោយជំនួយពីសេវាកម្មរាប់សិបដែលជួនកាលទំនាក់ទំនងតាមរបៀបដែលមិនច្បាស់លាស់។ វាក៏មានប្រព័ន្ធកណ្តាលដែលការទទួលខុសត្រូវចម្បងគឺស្ថានភាពសណ្តាប់ធ្នាប់។ យើងហៅនាងថា BOB ខ្ញុំធ្វើការជាមួយនាង។

ឧបករណ៍សងប្រាក់វិញជាមួយ API ដែលជំរុញដោយព្រឹត្តិការណ៍

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

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

ប៉ុន្តែការត្រឡប់មកវិញកាន់តែមានភាពស្មុគស្មាញដោយសារការផ្លាស់ប្តូរច្បាប់ ហើយយើងត្រូវអនុវត្តសេវាកម្មខ្នាតតូចដាច់ដោយឡែកសម្រាប់វា។

ការលើកទឹកចិត្តរបស់យើង៖

1. ច្បាប់ FZ-54 - និយាយឱ្យខ្លី ច្បាប់តម្រូវឱ្យរាយការណ៍ទៅការិយាល័យពន្ធដារអំពីរាល់ប្រតិបត្តិការរូបិយវត្ថុ ថាតើវាជាការត្រឡប់មកវិញ ឬបង្កាន់ដៃ ក្នុងរយៈពេលខ្លីមួយ SLA ក្នុងរយៈពេលប៉ុន្មាននាទី។ យើងជាក្រុមហ៊ុនពាណិជ្ជកម្មអេឡិចត្រូនិក អនុវត្តប្រតិបត្តិការជាច្រើន។ តាមបច្ចេកទេស នេះមានន័យថា ទំនួលខុសត្រូវថ្មី (ហើយដូច្នេះសេវាកម្មថ្មី) និងការកែលម្អនៅក្នុងប្រព័ន្ធពាក់ព័ន្ធទាំងអស់។
2. BOB បំបែក គឺជាគម្រោងផ្ទៃក្នុងរបស់ក្រុមហ៊ុនដើម្បីបន្ធូរបន្ថយ BOB ​​ពីទំនួលខុសត្រូវមួយចំនួនធំដែលមិនមែនជាស្នូល និងកាត់បន្ថយភាពស្មុគស្មាញទាំងមូលរបស់វា។

ដ្យាក្រាមនេះបង្ហាញពីប្រព័ន្ធ Lamoda សំខាន់ៗ។ ឥឡូវនេះពួកគេភាគច្រើនមានច្រើនជាង ក្រុមតារានិករនៃសេវាមីក្រូ 5-10 នៅជុំវិញ monolith រួញតូច. ពួកវាកំពុងលូតលាស់យឺត ប៉ុន្តែយើងកំពុងព្យាយាមធ្វើឱ្យពួកវាតូចជាងមុន ពីព្រោះការដាក់ពង្រាយបំណែកដែលបានជ្រើសរើសនៅកណ្តាលគឺគួរឱ្យខ្លាច - យើងមិនអាចអនុញ្ញាតឱ្យវាធ្លាក់ចុះបានទេ។ យើង​ត្រូវ​បាន​បង្ខំ​ឱ្យ​កក់​ទុក​ការ​ផ្លាស់​ប្តូរ​ទាំងអស់ (ព្រួញ) ហើយ​គិត​ថា​ការ​ផ្លាស់​ប្តូរ​ទាំង​អស់​អាច​នឹង​ក្លាយ​ជា​មិន​អាច​ប្រើ​បាន។

BOB ក៏មានការផ្លាស់ប្តូរជាច្រើនផងដែរ៖ ប្រព័ន្ធទូទាត់ ប្រព័ន្ធដឹកជញ្ជូន ប្រព័ន្ធជូនដំណឹង។ល។

តាមបច្ចេកទេស BOB គឺ៖

• ~ 150k បន្ទាត់នៃកូដ + ~ 100k បន្ទាត់នៃការធ្វើតេស្ត;
• php7.2 + Zend 1 & Symfony Components 3;
• > 100 APIs & ~ 50 ការរួមបញ្ចូលខាងក្រៅ;
• 4 ប្រទេសដែលមានតក្កវិជ្ជាអាជីវកម្មផ្ទាល់ខ្លួន។

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

ដំណើរការត្រឡប់

ដំបូងប្រព័ន្ធពីរត្រូវបានចូលរួមនៅក្នុងដំណើរការ: BOB និងការទូទាត់។ ឥឡូវ​ពីរ​ទៀត​លេច​ឡើង​:

• សេវាសារពើពន្ធដែលនឹងថែរក្សាបញ្ហាជាមួយសារពើពន្ធ និងការទំនាក់ទំនងជាមួយសេវាកម្មខាងក្រៅ។
• ឧបករណ៍សងប្រាក់វិញ ដែលជាធម្មតាមានការផ្លាស់ប្តូរថ្មី ដើម្បីកុំឱ្យ BOB ​​កើនឡើង។

ឥឡូវនេះដំណើរការមើលទៅដូចនេះ:

1. BOB ទទួលបានសំណើសម្រាប់ការសងប្រាក់វិញ។
2. BOB និយាយអំពីឧបករណ៍បង្វិលសងនេះ។
3. ឧបករណ៍សងប្រាក់ប្រាប់ការទូទាត់៖ "ប្រគល់ប្រាក់វិញ។"
4. ការទូទាត់សងប្រាក់វិញ។
5. ឧបករណ៍សងប្រាក់វិញ និង BOB ធ្វើសមកាលកម្មស្ថានភាពជាមួយគ្នា ពីព្រោះសម្រាប់ពេលនេះពួកគេទាំងពីរត្រូវការវា។ យើងមិនទាន់រួចរាល់ក្នុងការប្តូរទាំងស្រុងទៅឧបករណ៍សងប្រាក់វិញទេ ដោយសារ BOB មាន UI របាយការណ៍សម្រាប់គណនេយ្យ និងជាទូទៅទិន្នន័យជាច្រើនដែលមិនអាចផ្ទេរបានយ៉ាងងាយស្រួល។ អ្នកត្រូវអង្គុយលើកៅអីពីរ។
6. សំណើ​សារពើពន្ធ​បាត់​ទៅ​ហើយ។

ជាលទ្ធផលយើងបានបង្កើតប្រភេទនៃឡានក្រុងព្រឹត្តិការណ៍នៅលើ Kafka - event-bus ដែលអ្វីៗបានចាប់ផ្តើម។ ហ៊ឺ ពេលនេះ យើងមានចំណុចតែមួយនៃការបរាជ័យ (ពាក្យសំដី)។

គុណសម្បត្តិនិងគុណវិបត្តិគឺច្បាស់ណាស់។ យើងបង្កើតឡានក្រុង ដែលមានន័យថាឥឡូវនេះសេវាកម្មទាំងអស់ពឹងផ្អែកលើវា។ នេះជួយសម្រួលដល់ការរចនា ប៉ុន្តែណែនាំចំណុចមួយនៃការបរាជ័យទៅក្នុងប្រព័ន្ធ។ Kafka នឹងគាំងដំណើរការនឹងឈប់។

តើអ្វីទៅជា API ដែលជំរុញដោយព្រឹត្តិការណ៍

ចម្លើយដ៏ល្អចំពោះសំណួរនេះគឺនៅក្នុងរបាយការណ៍ដោយ Martin Fowler (GOTO 2017) "អត្ថន័យជាច្រើននៃស្ថាបត្យកម្មដែលជំរុញដោយព្រឹត្តិការណ៍".

សង្ខេបអ្វីដែលយើងបានធ្វើ៖

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

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

សេវាឧបករណ៍សងប្រាក់វិញ។ មិនបានផ្ទុកដូច្នេះ Kafka មានរសជាតិប៊ិចច្រើនជាងភាពចាំបាច់។ ខ្ញុំ​មិន​គិត​ថា​ប្រសិន​បើ​សេវា​សង​ប្រាក់​វិញ​ក្លាយ​ជា​គម្រោង​ដែល​មាន​បន្ទុក​ខ្ពស់ នោះ​អាជីវកម្ម​នឹង​មាន​សុភមង្គល។

ការផ្លាស់ប្តូរ Async AS IS

សម្រាប់ការផ្លាស់ប្តូរអសមកាល នាយកដ្ឋាន PHP ជាធម្មតាប្រើ RabbitMQ ។ យើងបានប្រមូលទិន្នន័យសម្រាប់ការស្នើសុំ ដាក់វានៅក្នុងជួរមួយ ហើយអ្នកប្រើប្រាស់នៃសេវាកម្មដូចគ្នាបានអានវា ហើយផ្ញើវា (ឬមិនបានផ្ញើវា)។ សម្រាប់ API ខ្លួនវា Lamoda ប្រើ Swagger យ៉ាងសកម្ម។ យើងរចនា API ពិពណ៌នាវានៅក្នុង Swagger និងបង្កើតកូដម៉ាស៊ីនភ្ញៀវ និងម៉ាស៊ីនមេ។ យើងក៏ប្រើ JSON RPC 2.0 ដែលត្រូវបានកែលម្អបន្តិចផងដែរ។

នៅកន្លែងខ្លះ ឡានក្រុង ESB ត្រូវបានប្រើ ខ្លះរស់នៅលើ activeMQ ប៉ុន្តែជាទូទៅ RabbitMQ - ស្តង់ដារ.

ការផ្លាស់ប្តូរ Async TO BE

នៅពេលរចនាការផ្លាស់ប្តូរតាមរយៈ event-bus ភាពស្រដៀងគ្នាអាចតាមដានបាន។ យើងពណ៌នាស្រដៀងគ្នានឹងការផ្លាស់ប្តូរទិន្នន័យនាពេលអនាគតតាមរយៈការពិពណ៌នាអំពីរចនាសម្ព័ន្ធព្រឹត្តិការណ៍។ ទម្រង់ yaml យើងត្រូវបង្កើតកូដដោយខ្លួនឯង ម៉ាស៊ីនភ្លើងបង្កើត DTOs តាមការកំណត់ ហើយបង្រៀនអតិថិជន និងម៉ាស៊ីនមេឱ្យធ្វើការជាមួយពួកគេ។ ជំនាន់ទៅជាពីរភាសា - golang និង php. នេះជួយរក្សាបណ្ណាល័យឱ្យជាប់លាប់។ ម៉ាស៊ីនភ្លើង​ត្រូវ​បាន​សរសេរ​ជា​ភាសា​ហ្គោលាំង ដែល​ជា​មូលហេតុ​ដែល​វា​មាន​ឈ្មោះ​ថា ហ្គោហ្គី។

ប្រភពព្រឹត្តិការណ៍នៅលើ Kafka គឺជារឿងធម្មតា។ មានដំណោះស្រាយពីកំណែសហគ្រាសសំខាន់នៃ Kafka Confluent មាន ណាកាឌីដំណោះស្រាយពីបងប្អូនដែនរបស់យើង Zalando ។ របស់យើង។ ការលើកទឹកចិត្តដើម្បីចាប់ផ្តើមជាមួយ vanilla Kafka - នេះមានន័យថាទុកឱ្យដំណោះស្រាយដោយឥតគិតថ្លៃរហូតដល់ទីបំផុតយើងសម្រេចចិត្តថាតើយើងនឹងប្រើវានៅគ្រប់ទីកន្លែងហើយក៏ទុកកន្លែងសម្រាប់ខ្លួនយើងសម្រាប់ការធ្វើសមយុទ្ធ និងការកែលម្អ៖ យើងចង់បានការគាំទ្រសម្រាប់យើង។ JSON RPC 2.0, generators for two languages ​​and let's see what else.

វាគួរឱ្យអស់សំណើចណាស់ដែលសូម្បីតែនៅក្នុងករណីដ៏រីករាយមួយ នៅពេលដែលមានអាជីវកម្មស្រដៀងគ្នានេះ Zalando ដែលបានបង្កើតដំណោះស្រាយប្រហាក់ប្រហែលគ្នា យើងមិនអាចប្រើវាឱ្យមានប្រសិទ្ធភាពនោះទេ។

គំរូស្ថាបត្យកម្មនៅពេលចាប់ផ្តើមមានដូចខាងក្រោម: យើងអានដោយផ្ទាល់ពី Kafka ប៉ុន្តែសរសេរតែតាមរយៈព្រឹត្តិការណ៍ - ឡានក្រុង។ មានច្រើនដែលត្រៀមរួចជាស្រេចសម្រាប់ការអាននៅក្នុង Kafka: ឈ្មួញកណ្តាល តុល្យការ ហើយវាជាការត្រៀមខ្លួនច្រើនឬតិចសម្រាប់ការធ្វើមាត្រដ្ឋានផ្ដេក ខ្ញុំចង់រក្សាវាទុក។ យើងចង់បញ្ចប់ការថតតាមរយៈ Gateway aka Events-bus ហើយនេះជាមូលហេតុ។

ព្រឹត្តិការណ៍ - ឡានក្រុង

ឬឡានក្រុងព្រឹត្តិការណ៍។ នេះគ្រាន់តែជាច្រកផ្លូវ http គ្មានរដ្ឋ ដែលដើរតួនាទីសំខាន់ៗមួយចំនួន៖

• ការផលិតការបញ្ជាក់ - យើងពិនិត្យមើលថាព្រឹត្តិការណ៍ត្រូវនឹងលក្ខណៈជាក់លាក់របស់យើង។
• ប្រព័ន្ធមេនៃព្រឹត្តិការណ៍នោះគឺនេះគឺជាប្រព័ន្ធសំខាន់ និងតែមួយគត់នៅក្នុងក្រុមហ៊ុនដែលឆ្លើយសំណួរថាតើព្រឹត្តិការណ៍ណាដែលរចនាសម្ព័ន្ធត្រូវបានចាត់ទុកថាមានសុពលភាព។ សុពលភាពគ្រាន់តែពាក់ព័ន្ធនឹងប្រភេទទិន្នន័យ និង enums ដើម្បីបញ្ជាក់ខ្លឹមសារយ៉ាងតឹងរ៉ឹង។
• មុខងារហាស សម្រាប់ sharding - រចនាសម្ព័ន្ធសារ Kafka គឺជា key-value ហើយដោយប្រើ hash of key វាត្រូវបានគណនាកន្លែងដែលត្រូវដាក់វា។

ហេតុអ្វី

យើងធ្វើការនៅក្នុងក្រុមហ៊ុនធំមួយដែលមានដំណើរការរលូន ហេតុអ្វីបានជាផ្លាស់ប្តូរអ្វី? នេះជាការពិសោធន៍ហើយយើងរំពឹងថានឹងទទួលបានអត្ថប្រយោជន៍ជាច្រើន។

1: n + 1 ការផ្លាស់ប្តូរ (មួយទៅច្រើន)

Kafka ធ្វើឱ្យមានភាពងាយស្រួលក្នុងការភ្ជាប់អ្នកប្រើប្រាស់ថ្មីទៅកាន់ API ។

ឧបមាថាអ្នកមានថតដែលអ្នកត្រូវការដើម្បីរក្សាបច្ចុប្បន្នភាពនៅក្នុងប្រព័ន្ធជាច្រើនក្នុងពេលតែមួយ (និងនៅក្នុងមួយចំនួនថ្មី) ។ កាលពីមុន យើងបានបង្កើតបណ្តុំដែលអនុវត្ត set-API ហើយប្រព័ន្ធមេត្រូវបានជូនដំណឹងអំពីអាសយដ្ឋានអ្នកប្រើប្រាស់។ ឥឡូវនេះប្រព័ន្ធមេបញ្ជូនព័ត៌មានថ្មីៗទៅកាន់ប្រធានបទ ហើយអ្នកគ្រប់គ្នាដែលចាប់អារម្មណ៍អានវា។ ប្រព័ន្ធថ្មីមួយបានបង្ហាញខ្លួន - យើងបានចុះឈ្មោះវាសម្រាប់ប្រធានបទ។ បាទ/ចាស ក៏ជាកញ្ចប់ដែរ ប៉ុន្តែសាមញ្ញជាង។

ក្នុងករណីឧបករណ៍សងប្រាក់វិញ ដែលជាបំណែកនៃ BOB វាងាយស្រួលសម្រាប់យើងក្នុងការរក្សាពួកវាឱ្យធ្វើសមកាលកម្មតាមរយៈ Kafka ។ ការទូទាត់និយាយថាប្រាក់ត្រូវបានប្រគល់ជូនវិញ៖ BOB, RT បានរកឃើញអំពីបញ្ហានេះ ផ្លាស់ប្តូរស្ថានភាពរបស់ពួកគេ សេវាសារពើពន្ធបានរកឃើញអំពីបញ្ហានេះ និងបានចេញមូលប្បទានប័ត្រ។

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

ជំរុញទិន្នន័យ

ព័ត៌មានរវាងប្រព័ន្ធក្លាយជាតម្លាភាព - មិនថា "សហគ្រាសបង្ហូរឈាម" បែបណាដែលអ្នកមាន ហើយមិនថាកំណត់ហេតុរបស់អ្នកធ្លាក់ចុះយ៉ាងណានោះទេ។ Lamoda មាននាយកដ្ឋានវិភាគទិន្នន័យដែលប្រមូលទិន្នន័យពីប្រព័ន្ធ ហើយដាក់វាចូលទៅក្នុងទម្រង់ដែលអាចប្រើឡើងវិញបានទាំងសម្រាប់អាជីវកម្ម និងសម្រាប់ប្រព័ន្ធឆ្លាតវៃ។ Kafka អនុញ្ញាតឱ្យអ្នកផ្តល់ឱ្យពួកគេនូវទិន្នន័យជាច្រើនយ៉ាងឆាប់រហ័ស និងរក្សាលំហូរព័ត៌មាននោះឱ្យទាន់សម័យ។

កំណត់ហេតុចម្លង

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

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

បន្ទាប់មក ការរៀបរាប់ឡើងវិញបន្តិចនៃឯកសារសម្រាប់អ្នកដែលមិនស៊ាំជាមួយ Kafka (រូបភាពក៏មកពីឯកសារផងដែរ)

AMQP មានជួរ៖ យើងសរសេរសារទៅជួរសម្រាប់អតិថិជន។ ជាធម្មតា ជួរមួយត្រូវបានដំណើរការដោយប្រព័ន្ធមួយដែលមានតក្កវិជ្ជាអាជីវកម្មដូចគ្នា។ ប្រសិនបើអ្នកត្រូវការជូនដំណឹងដល់ប្រព័ន្ធជាច្រើន អ្នកអាចបង្រៀនកម្មវិធីឱ្យសរសេរទៅជួរជាច្រើន ឬកំណត់រចនាសម្ព័ន្ធការផ្លាស់ប្តូរជាមួយនឹងយន្តការ fanout ដែលក្លូនពួកវាដោយខ្លួនឯង។

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

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

តម្រូវការព្រឹត្តិការណ៍៖

• ភាពពេញលេញនៃទិន្នន័យ។ ខ្ញុំ​ចង់​ឱ្យ​ព្រឹត្តិការណ៍​នេះ​មាន​ទិន្នន័យ​គ្រប់គ្រាន់​ដើម្បី​ឱ្យ​វា​អាច​ដំណើរការ​បាន។

• សុចរិតភាព។ យើងប្រគល់ទៅឱ្យ Events-bus នូវការផ្ទៀងផ្ទាត់ថាព្រឹត្តិការណ៍គឺស្រប ហើយវាអាចដំណើរការវាបាន។
• លំដាប់គឺសំខាន់។ ក្នុង​ករណី​ត្រឡប់​មក​វិញ យើង​ត្រូវ​បង្ខំ​ឲ្យ​ធ្វើ​ការ​ជាមួយ​នឹង​ប្រវត្តិសាស្ត្រ។ ជាមួយនឹងការជូនដំណឹង ការបញ្ជាទិញមិនសំខាន់ទេ ប្រសិនបើពួកវាជាការជូនដំណឹងដូចគ្នា អ៊ីមែលនឹងដូចគ្នា ដោយមិនគិតពីការបញ្ជាទិញណាមួយបានមកដល់មុន។ នៅក្នុងករណីនៃការបង្វិលសងវិញ មានដំណើរការច្បាស់លាស់ ប្រសិនបើយើងផ្លាស់ប្តូរការបញ្ជាទិញ ការលើកលែងនឹងកើតឡើង ការបង្វិលសងនឹងមិនត្រូវបានបង្កើត ឬដំណើរការទេ យើងនឹងបញ្ចប់ក្នុងស្ថានភាពផ្សេង។
• ភាពជាប់លាប់។ យើងមានហាងមួយ ហើយឥឡូវនេះយើងបង្កើតព្រឹត្តិការណ៍ជំនួសឱ្យ API ។ យើងត្រូវការមធ្យោបាយដើម្បីបញ្ជូនព័ត៌មានយ៉ាងឆាប់រហ័ស និងថោកអំពីព្រឹត្តិការណ៍ថ្មីៗ និងការផ្លាស់ប្តូរទៅកាន់សេវាកម្មរបស់យើងដែលមានស្រាប់។ នេះត្រូវបានសម្រេចតាមរយៈការបញ្ជាក់ទូទៅនៅក្នុងឃ្លាំង git ដាច់ដោយឡែក និងម៉ាស៊ីនបង្កើតកូដ។ ដូច្នេះ អតិថិជន និងម៉ាស៊ីនមេនៅក្នុងសេវាកម្មផ្សេងៗគ្នាត្រូវបានសម្របសម្រួល។

Kafka នៅ Lamoda

យើងមានការដំឡើង Kafka ចំនួនបី៖

1. កំណត់ហេតុ;
2. R&D;
3. ព្រឹត្តិការណ៍ - ឡានក្រុង។

ថ្ងៃនេះយើងនិយាយតែចំណុចចុងក្រោយប៉ុណ្ណោះ។ នៅឯព្រឹត្តិការណ៍ - រថយន្តក្រុងយើងមិនមានការដំឡើងធំខ្លាំងណាស់ - ឈ្មួញកណ្តាល 3 (ម៉ាស៊ីនមេ) ហើយមានតែ 27 ប្រធានបទប៉ុណ្ណោះ។ តាមក្បួនមួយប្រធានបទគឺជាដំណើរការមួយ។ ប៉ុន្តែ​នេះ​ជា​ចំណុច​តូច​មួយ ហើយ​យើង​នឹង​ប៉ះ​វា​ឥឡូវ​នេះ។

ខាងលើគឺជាក្រាហ្វ rps ។ ដំណើរការសងប្រាក់វិញត្រូវបានសម្គាល់ដោយបន្ទាត់ពណ៌ខៀវ (បាទ មួយនៅលើអ័ក្ស X) ហើយបន្ទាត់ពណ៌ផ្កាឈូកគឺជាដំណើរការធ្វើបច្ចុប្បន្នភាពមាតិកា។

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

កំពូលពណ៌ផ្កាឈូកគឺជាការអាប់ដេតផលិតផល ពោលគឺការផ្លាស់ប្តូរផលិតផល។ ឃើញ​ប្រុស​ៗ​ថត​រូប​ទៀត​ហើយ! - បានផ្ទុកកញ្ចប់ព្រឹត្តិការណ៍។

Lamoda Events ប្រើករណី

យើងប្រើស្ថាបត្យកម្មដែលបានសាងសង់សម្រាប់ប្រតិបត្តិការដូចខាងក្រោមៈ

• ការតាមដានស្ថានភាពត្រឡប់មកវិញ៖ ការហៅទៅសកម្មភាព និងការតាមដានស្ថានភាពពីប្រព័ន្ធពាក់ព័ន្ធទាំងអស់។ ការទូទាត់ ស្ថានភាពសារពើពន្ធ ការជូនដំណឹង។ នៅទីនេះ យើងបានសាកល្បងវិធីសាស្រ្ត បង្កើតឧបករណ៍ ប្រមូលកំហុសទាំងអស់ សរសេរឯកសារ និងប្រាប់សហការីរបស់យើងពីរបៀបប្រើវា។
• ការធ្វើបច្ចុប្បន្នភាពកាតផលិតផល៖ ការកំណត់រចនាសម្ព័ន្ធ ទិន្នន័យមេតា លក្ខណៈ។ ប្រព័ន្ធមួយអាន (ដែលបង្ហាញ) និងសរសេរជាច្រើន។
• អ៊ីមែល ជំរុញ និងផ្ញើសារ: ការបញ្ជាទិញត្រូវបានប្រមូល, ការបញ្ជាទិញបានមកដល់, ការត្រឡប់មកវិញត្រូវបានទទួលយក, ល, មានច្រើននៃពួកគេ។
• ការស្តុកទុក ការបន្តឃ្លាំង - ការធ្វើបច្ចុប្បន្នភាពបរិមាណនៃធាតុគ្រាន់តែជាលេខ៖ ការមកដល់ឃ្លាំងត្រឡប់មកវិញ។ វាចាំបាច់ដែលប្រព័ន្ធទាំងអស់ដែលទាក់ទងនឹងការកក់ទំនិញដំណើរការជាមួយនឹងទិន្នន័យបច្ចុប្បន្នបំផុត។ បច្ចុប្បន្ននេះ ប្រព័ន្ធធ្វើបច្ចុប្បន្នភាពភាគហ៊ុនគឺស្មុគស្មាញណាស់ Kafka នឹងធ្វើឱ្យវាងាយស្រួល។
• ការវិភាគ​ទិន្នន័យ (នាយកដ្ឋាន R&D), ឧបករណ៍ ML, ការវិភាគ, ស្ថិតិ។ យើងចង់ឱ្យព័ត៌មានមានតម្លាភាព - Kafka គឺសមរម្យសម្រាប់រឿងនេះ។

ឥឡូវនេះផ្នែកគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតអំពីរដិបរដុបធំ ៗ និងការរកឃើញគួរឱ្យចាប់អារម្មណ៍ដែលបានកើតឡើងក្នុងរយៈពេលប្រាំមួយខែកន្លងមកនេះ។

បញ្ហារចនា

ចូរនិយាយថាយើងចង់ធ្វើរឿងថ្មី - ឧទាហរណ៍ផ្ទេរដំណើរការចែកចាយទាំងមូលទៅ Kafka ។ ឥឡូវនេះផ្នែកនៃដំណើរការត្រូវបានអនុវត្តនៅក្នុងដំណើរការលំដាប់នៅក្នុង BOB ។ មានគំរូស្ថានភាពនៅពីក្រោយការផ្ទេរការបញ្ជាទិញទៅកាន់សេវាកម្មដឹកជញ្ជូន ចលនាទៅកាន់ឃ្លាំងកម្រិតមធ្យម។ល។ មាន monolith ទាំងមូល សូម្បីតែពីរ រួមទាំង APIs ជាច្រើនដែលឧទ្ទិសដល់ការដឹកជញ្ជូន។ ពួកគេដឹងច្រើនអំពីការដឹកជញ្ជូន។

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

ស្ទ្រីមទិន្នន័យ

ក្នុងករណី Kafka សំណួរនៃការរៀបចំលំហូរទិន្នន័យកើតឡើង។ កិច្ចការនេះពាក់ព័ន្ធនឹងការជ្រើសរើសយុទ្ធសាស្ត្រដោយផ្អែកលើចំណុចជាច្រើន តោះឆ្លងកាត់វាទាំងអស់គ្នា។

ក្នុងប្រធានបទមួយ ឬក្នុងប្រធានបទផ្សេងគ្នា?

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

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

វាលថ្មី ឬព្រឹត្តិការណ៍ថ្មី?

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

ប្រសិនបើយើងណែនាំច្បាប់សម្រាប់ event-bus ដែលវាលនេះត្រូវបានទាមទារ នោះយើងត្រូវបានគេបង្ខំឱ្យកំណត់ច្បាប់សុពលភាពបន្ថែមនៅក្នុង BOB ឬនៅក្នុង start event handler។ សុពលភាពចាប់ផ្តើមរីករាលដាលពេញសេវាកម្ម - នេះមិនងាយស្រួលទេ។

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

នៅក្នុងករណីនៃការសងប្រាក់វិញយើងបានមកដល់ព្រឹត្តិការណ៍នៃព្រឹត្តិការណ៍ក្នុងរយៈពេលកន្លះឆ្នាំ។ យើង​មាន​ព្រឹត្តិការណ៍​មេតា​មួយ​ដែល​ហៅ​ថា​ការ​អាប់ដេត​ការ​សង​ប្រាក់​វិញ ដែល​មាន​វាល​ប្រភេទ​ដែល​ពិពណ៌នា​ថា​ការ​អាប់ដេត​នេះ​ពិត​ជា​អ្វី។ ដោយសារតែនេះ យើងមានកុងតាក់ "អស្ចារ្យ" ជាមួយអ្នកផ្តល់សុពលភាព ដែលបានប្រាប់យើងពីរបៀបធ្វើឱ្យព្រឹត្តិការណ៍នេះមានសុពលភាពជាមួយនឹងប្រភេទនេះ។

កំណែព្រឹត្តិការណ៍

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

ធានាការអានលំដាប់នៃភាគថាស

ប្រធានបទនៅខាងក្នុង Kafka ត្រូវបានបែងចែកទៅជាភាគថាស។ នេះមិនសំខាន់ទេ ខណៈពេលដែលយើងកំពុងរចនាអង្គភាព និងការផ្លាស់ប្តូរ ប៉ុន្តែវាមានសារៈសំខាន់នៅពេលសម្រេចចិត្តអំពីរបៀបប្រើប្រាស់ និងធ្វើមាត្រដ្ឋានវា។

ក្នុងករណីធម្មតាអ្នកសរសេរប្រធានបទមួយនៅក្នុង Kafka ។ តាមលំនាំដើម ភាគថាសមួយត្រូវបានប្រើ ហើយសារទាំងអស់នៅក្នុងប្រធានបទនេះទៅកាន់វា។ ហើយអ្នកប្រើប្រាស់បានអានសារទាំងនេះជាបន្តបន្ទាប់។ ចូរនិយាយថាឥឡូវនេះយើងត្រូវពង្រីកប្រព័ន្ធដើម្បីឱ្យសារត្រូវបានអានដោយអ្នកប្រើប្រាស់ពីរផ្សេងគ្នា។ ឧទាហរណ៍ ប្រសិនបើអ្នកកំពុងផ្ញើសារ SMS បន្ទាប់មកអ្នកអាចប្រាប់ Kafka ឱ្យបង្កើតភាគថាសបន្ថែម ហើយ Kafka នឹងចាប់ផ្តើមបំបែកសារជាពីរផ្នែក - ពាក់កណ្តាលនៅទីនេះ ពាក់កណ្តាលនៅទីនេះ។

តើ Kafka បែងចែកពួកគេដោយរបៀបណា? សារនីមួយៗមានតួអត្ថបទ (ដែលយើងរក្សាទុក JSON) និងសោ។ អ្នកអាចភ្ជាប់មុខងារ hash ទៅសោនេះ ដែលនឹងកំណត់ថាភាគថាសណាមួយដែលសារនឹងចូលទៅក្នុង។

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

ព្រឹត្តិការណ៍ទល់នឹងពាក្យបញ្ជា

នេះគឺជាបញ្ហាមួយទៀតដែលយើងជួបប្រទះ។ ព្រឹត្តិការណ៍គឺជាព្រឹត្តិការណ៍ជាក់លាក់មួយ៖ យើងនិយាយថាមានអ្វីមួយបានកើតឡើងនៅកន្លែងណាមួយ (something_happened) ឧទាហរណ៍ ធាតុមួយត្រូវបានលុបចោល ឬការសងប្រាក់វិញបានកើតឡើង។ ប្រសិនបើនរណាម្នាក់ស្តាប់ព្រឹត្តិការណ៍ទាំងនេះ នោះយោងទៅតាម "ធាតុដែលបានលុបចោល" អង្គភាពសងប្រាក់វិញនឹងត្រូវបានបង្កើត ហើយ "ការបង្វិលសងបានកើតឡើង" នឹងត្រូវបានសរសេរនៅកន្លែងណាមួយនៅក្នុងការដំឡើង។

ប៉ុន្តែជាធម្មតា នៅពេលអ្នករចនាព្រឹត្តិការណ៍ អ្នកមិនចង់សរសេរវាដោយឥតប្រយោជន៍ទេ - អ្នកពឹងផ្អែកលើការពិតដែលថានរណាម្នាក់នឹងអានវា។ មាន​ការ​ល្បួង​ខ្ពស់​ក្នុង​ការ​សរសេរ​មិន​មែន​អ្វី​ដែល​បាន​កើត​ឡើង (item_canceled, refund_refunded) ប៉ុន្តែ something_should_be_done។ ឧទាហរណ៍ ធាតុត្រៀមរួចរាល់ក្នុងការប្រគល់មកវិញ។

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

នៅក្នុងការផ្លាស់ប្តូរអសមកាលនៅក្នុង RabbitMQ នៅពេលអ្នកអានសារ សូមចូលទៅកាន់ http អ្នកមានការឆ្លើយតប - យ៉ាងហោចណាស់សារត្រូវបានទទួល។ នៅពេលអ្នកសរសេរទៅ Kafka មានសារដែលអ្នកបានសរសេរទៅ Kafka ប៉ុន្តែអ្នកមិនដឹងអ្វីទាំងអស់អំពីរបៀបដែលវាត្រូវបានដំណើរការ។

ដូច្នេះ ក្នុងករណីរបស់យើង យើងត្រូវណែនាំព្រឹត្តិការណ៍ឆ្លើយតប និងរៀបចំការត្រួតពិនិត្យ ដូច្នេះប្រសិនបើព្រឹត្តិការណ៍ជាច្រើនត្រូវបានបញ្ជូននោះ បន្ទាប់ពីពេលវេលាបែបនេះ និងពេលវេលាដូចគ្នានៃព្រឹត្តិការណ៍ឆ្លើយតបគួរតែមកដល់។ ប្រសិនបើរឿងនេះមិនកើតឡើងទេ នោះហាក់បីដូចជាមានអ្វីមួយខុសប្រក្រតី។ ឧទាហរណ៍ ប្រសិនបើយើងផ្ញើព្រឹត្តិការណ៍ “item_ready_to_refund” យើងរំពឹងថាការសងប្រាក់នឹងត្រូវបានបង្កើត ប្រាក់នឹងត្រូវបានប្រគល់ជូនអតិថិជនវិញ ហើយព្រឹត្តិការណ៍ “money_refunded” នឹងត្រូវបានផ្ញើមកយើង។ ប៉ុន្តែនេះមិនប្រាកដទេ ដូច្នេះការត្រួតពិនិត្យគឺចាំបាច់។

ពណ៌

មានបញ្ហាជាក់ស្តែងមួយ៖ ប្រសិនបើអ្នកអានពីប្រធានបទជាបន្តបន្ទាប់ ហើយអ្នកមានសារមិនល្អមួយចំនួន អ្នកប្រើប្រាស់នឹងធ្លាក់ចុះ ហើយអ្នកនឹងមិនបន្តទៅមុខទៀត។ អ្នក​ត្រូវការ បញ្ឈប់អ្នកប្រើប្រាស់ទាំងអស់។, ប្តេជ្ញាអុហ្វសិតបន្ថែមទៀតដើម្បីបន្តការអាន។

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

សេវាកម្មបានផ្អាកមួយរយៈ - ជាសំណាងល្អជាមួយ Kafka នេះមិនអាក្រក់ទេព្រោះសារនៅតែមាន។ នៅពេលការងារត្រូវបានស្តារឡើងវិញ អ្នកអាចអានពួកវាឱ្យចប់បាន។ វាមានផាសុកភាព។

Kafka មានសមត្ថភាពក្នុងការកំណត់អុហ្វសិតតាមអំពើចិត្តតាមរយៈឧបករណ៍។ ប៉ុន្តែដើម្បីធ្វើដូច្នេះ អ្នកត្រូវបញ្ឈប់អ្នកប្រើប្រាស់ទាំងអស់ - ក្នុងករណីរបស់យើង រៀបចំការចេញផ្សាយដាច់ដោយឡែកមួយ ដែលវានឹងមិនមានអ្នកប្រើប្រាស់ ការដាក់ឱ្យប្រើប្រាស់ឡើងវិញ។ បន្ទាប់មកនៅក្នុង Kafka អ្នកអាចប្តូរអុហ្វសិតតាមរយៈឧបករណ៍ ហើយសារនឹងឆ្លងកាត់។

nuance មួយផ្សេងទៀត - កំណត់ហេតុចម្លងធៀបនឹង rdkafka.so - គឺទាក់ទងទៅនឹងជាក់លាក់នៃគម្រោងរបស់យើង។ យើងប្រើ PHP ហើយនៅក្នុង PHP ជាក្បួន បណ្ណាល័យទាំងអស់ទាក់ទងជាមួយ Kafka តាមរយៈឃ្លាំង rdkafka.so ហើយបន្ទាប់មកមានប្រភេទ wrapper មួយចំនួន។ ប្រហែលជាទាំងនេះគឺជាការលំបាកផ្ទាល់ខ្លួនរបស់យើង ប៉ុន្តែវាបានប្រែក្លាយថាការអានឡើងវិញនូវអ្វីដែលយើងបានអានរួចហើយគឺមិនងាយស្រួលនោះទេ។ ជាទូទៅមានបញ្ហាផ្នែកទន់។

ត្រលប់ទៅភាពជាក់លាក់នៃការធ្វើការជាមួយភាគថាសវាត្រូវបានសរសេរត្រឹមត្រូវនៅក្នុងឯកសារ អ្នកប្រើប្រាស់ >= ការបែងចែកប្រធានបទ. ប៉ុន្តែ​ខ្ញុំ​បាន​ដឹង​អំពី​រឿង​នេះ​ក្រោយ​ពេល​ច្រើន​ជាង​អ្វី​ដែល​ខ្ញុំ​ចង់​បាន។ ប្រសិនបើអ្នកចង់ធ្វើមាត្រដ្ឋាន និងមានអ្នកប្រើប្រាស់ពីរនាក់ អ្នកត្រូវការភាគថាសយ៉ាងតិចពីរ។ នោះគឺប្រសិនបើអ្នកមានភាគថាសមួយដែលក្នុងនោះ 20 ពាន់សារបានប្រមូលផ្តុំ ហើយអ្នកបានបង្កើតថ្មីមួយនោះ ចំនួនសារនឹងមិនត្រូវបានស្មើគ្នាក្នុងពេលឆាប់ៗនេះទេ។ ដូច្នេះ​ដើម្បី​ឱ្យ​មាន​អ្នក​ប្រើ​ស្រប​គ្នា​ពីរ អ្នក​ត្រូវ​ដោះស្រាយ​ជាមួយ​ភាគ​ថាស។

ការត្រួតពិនិត្យ

ខ្ញុំ​គិត​ថា​វិធី​ដែល​យើង​ត្រួត​ពិនិត្យ​វា​នឹង​កាន់​តែ​ច្បាស់​ថា​តើ​មាន​បញ្ហា​អ្វី​នៅ​ក្នុង​វិធីសាស្ត្រ​ដែល​មាន​ស្រាប់។

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

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

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

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

នេះគឺជាអ្វីដែលការឆ្លើយតបរបស់ API មើលទៅដូច។ នេះគឺជាក្រុម bob-live-fifa, partition refund.update.v1, ស្ថានភាព OK, lag 0 - អុហ្វសិតចុងក្រោយចុងក្រោយដូចជាជាដើម។

ការត្រួតពិនិត្យ updated_at SLA (ជាប់គាំង) ខ្ញុំបានលើកឡើងរួចហើយ។ ឧទាហរណ៍ ផលិតផលបានប្តូរទៅជាស្ថានភាពដែលវារួចរាល់សម្រាប់ការត្រឡប់មកវិញ។ យើងដំឡើង Cron ដែលនិយាយថាប្រសិនបើក្នុងរយៈពេល 5 នាទីវត្ថុនេះមិនបានសងប្រាក់វិញទេ (យើងប្រគល់ប្រាក់វិញតាមរយៈប្រព័ន្ធទូទាត់យ៉ាងឆាប់រហ័ស) នោះប្រាកដជាមានអ្វីមួយខុសប្រក្រតី ហើយនេះពិតជាករណីសម្រាប់ការគាំទ្រ។ ដូច្នេះហើយ យើងគ្រាន់តែយក Cron ដែលអានរឿងបែបនេះ ហើយប្រសិនបើវាធំជាង 0 នោះវានឹងផ្ញើការជូនដំណឹង។

ដើម្បីសង្ខេបការប្រើប្រាស់ព្រឹត្តិការណ៍គឺងាយស្រួលនៅពេល:

• ព័ត៌មានគឺត្រូវការដោយប្រព័ន្ធជាច្រើន;
• លទ្ធផលនៃដំណើរការគឺមិនសំខាន់;
• មានព្រឹត្តិការណ៍តិចតួច ឬព្រឹត្តិការណ៍តូចតាច។

វាហាក់ដូចជាថាអត្ថបទមានប្រធានបទជាក់លាក់មួយ - API អសមកាលនៅលើ Kafka ប៉ុន្តែទាក់ទងនឹងវា ខ្ញុំចង់ណែនាំរឿងជាច្រើនក្នុងពេលតែមួយ។
ទីមួយបន្ទាប់ ការផ្ទុកខ្ពស់ ++ យើងត្រូវរង់ចាំរហូតដល់ខែវិច្ឆិកា ហើយនៅក្នុងខែមេសានឹងមានកំណែសាំងពេទឺប៊ឺគ ហើយនៅខែមិថុនា យើងនឹងនិយាយអំពីការផ្ទុកខ្ពស់នៅ Novosibirsk។
ទីពីរ អ្នកនិពន្ធរបាយការណ៍គឺលោក Sergei Zaika ជាសមាជិកនៃគណៈកម្មាធិការកម្មវិធីនៃសន្និសីទថ្មីរបស់យើងស្តីពីការគ្រប់គ្រងចំណេះដឹង។ KnowledgeConf. សន្និសិទនេះគឺមានរយៈពេលមួយថ្ងៃនឹងប្រព្រឹត្តទៅនៅថ្ងៃទី 26 ខែមេសា ប៉ុន្តែកម្មវិធីរបស់វាមានសភាពខ្លាំង។
ហើយវានឹងមាននៅក្នុងខែឧសភា PHP រុស្ស៊ី и RIT++ (ជាមួយ DevOpsConf រួមបញ្ចូល) - អ្នកក៏អាចស្នើប្រធានបទរបស់អ្នកនៅទីនោះ និយាយអំពីបទពិសោធន៍របស់អ្នក និងត្អូញត្អែរអំពីកោណដែលកប់របស់អ្នក។

ប្រភព: www.habr.com