"ដើរក្នុងស្បែកជើងរបស់ខ្ញុំ" - ​​រង់ចាំតើពួកគេត្រូវបានសម្គាល់ទេ?

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

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

ការផ្ទុកខ្ពស់ពិតប្រាកដ

“ម៉ាកុស” ដោះស្រាយបញ្ហាជាច្រើន ដែលសំខាន់គឺអន្តរកម្មនៃការរួមបញ្ចូលរវាងប្រព័ន្ធព័ត៌មាន X5 និងប្រព័ន្ធព័ត៌មានរដ្ឋសម្រាប់ផលិតផលដែលមានស្លាក (GIS MP) ដើម្បីតាមដានចលនានៃផលិតផលដែលមានស្លាក។ វេទិកានេះក៏រក្សាទុកលេខកូដដាក់ស្លាកទាំងអស់ដែលបានទទួលដោយយើង និងប្រវត្តិទាំងមូលនៃចលនានៃកូដទាំងនេះឆ្លងកាត់វត្ថុ និងជួយលុបបំបាត់ការដាក់ចំណាត់ថ្នាក់ឡើងវិញនៃផលិតផលដែលមានស្លាក។ ដោយប្រើឧទាហរណ៍នៃផលិតផលថ្នាំជក់ ដែលត្រូវបានដាក់បញ្ចូលក្នុងក្រុមដំបូងនៃទំនិញដែលមានស្លាកសញ្ញា បារីមួយដុំផ្ទុកប្រហែល 600 កញ្ចប់ ដែលនីមួយៗមានលេខកូដផ្ទាល់ខ្លួន។ ហើយភារកិច្ចនៃប្រព័ន្ធរបស់យើងគឺដើម្បីតាមដាន និងផ្ទៀងផ្ទាត់ភាពស្របច្បាប់នៃចលនានៃកញ្ចប់នីមួយៗរវាងឃ្លាំង និងហាង ហើយទីបំផុតផ្ទៀងផ្ទាត់លទ្ធភាពនៃការលក់របស់ពួកគេទៅឱ្យអ្នកទិញចុងក្រោយ។ ហើយយើងកត់ត្រាប្រតិបត្តិការសាច់ប្រាក់ប្រហែល 000 ក្នុងមួយម៉ោង ហើយយើងក៏ត្រូវកត់ត្រាពីរបៀបដែលកញ្ចប់នីមួយៗបានចូលទៅក្នុងហាងផងដែរ។ ដូច្នេះ ដោយគិតគូរពីចលនាទាំងអស់រវាងវត្ថុ យើងរំពឹងថានឹងមានកំណត់ត្រារាប់សិបពាន់លានក្នុងមួយឆ្នាំ។

ក្រុម M

ទោះបីជាការពិតដែលថា Marcus ត្រូវបានគេចាត់ទុកថាជាគម្រោងនៅក្នុង X5 ក៏ដោយក៏វាត្រូវបានអនុវត្តដោយប្រើវិធីសាស្រ្តផលិតផល។ ក្រុមនេះធ្វើការយោងទៅតាម Scrum ។ គម្រោងនេះបានចាប់ផ្តើមកាលពីរដូវក្តៅមុន ប៉ុន្តែលទ្ធផលដំបូងបានកើតឡើងតែក្នុងខែតុលាប៉ុណ្ណោះ - ក្រុមរបស់យើងផ្ទាល់ត្រូវបានប្រមូលផ្តុំយ៉ាងពេញលេញ ស្ថាបត្យកម្មប្រព័ន្ធត្រូវបានបង្កើតឡើង ហើយឧបករណ៍ត្រូវបានទិញ។ ឥឡូវនេះក្រុមនេះមាន 16 នាក់ដែលក្នុងនោះ XNUMX នាក់បានចូលរួមក្នុងការអភិវឌ្ឍន៍ផ្នែកខាងក្រោយនិងផ្នែកខាងមុខដែល XNUMX នាក់ចូលរួមក្នុងការវិភាគប្រព័ន្ធ។ មនុស្សប្រាំមួយនាក់ទៀតត្រូវបានចូលរួមនៅក្នុងសៀវភៅដៃ ការផ្ទុក ការធ្វើតេស្តដោយស្វ័យប្រវត្តិ និងការថែទាំផលិតផល។ លើសពីនេះទៀតយើងមានអ្នកឯកទេស SRE ។

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

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

ការប្រជុំក្រុមពីចម្ងាយ

ការប្រជុំក្នុងអំឡុងពេលការងារពីចម្ងាយ

ជង់បច្ចេកវិទ្យានៃដំណោះស្រាយ

ឃ្លាំងស្ដង់ដារ និងឧបករណ៍ CI/CD សម្រាប់ X5 គឺ GitLab ។ យើងប្រើវាសម្រាប់ការផ្ទុកកូដ ការធ្វើតេស្តបន្ត និងការដាក់ឱ្យប្រើប្រាស់ដើម្បីសាកល្បង និងផលិតម៉ាស៊ីនមេ។ យើងក៏ប្រើការអនុវត្តនៃការត្រួតពិនិត្យកូដផងដែរ នៅពេលដែលសហសេវិកយ៉ាងហោចណាស់ 2 នាក់ត្រូវយល់ព្រមលើការផ្លាស់ប្តូរដែលធ្វើឡើងដោយអ្នកអភិវឌ្ឍន៍ចំពោះកូដ។ ឧបករណ៍វិភាគកូដឋិតិវន្ត SonarQube និង JaCoCo ជួយយើងរក្សាកូដរបស់យើងឱ្យស្អាត និងធានាបាននូវកម្រិតដែលត្រូវការនៃការគ្របដណ្តប់ការធ្វើតេស្តឯកតា។ រាល់ការផ្លាស់ប្តូរលេខកូដត្រូវតែឆ្លងកាត់ការត្រួតពិនិត្យទាំងនេះ។ ស្គ្រីបសាកល្បងទាំងអស់ដែលដំណើរការដោយដៃគឺដោយស្វ័យប្រវត្តិជាបន្តបន្ទាប់។

សម្រាប់ការអនុវត្តជោគជ័យនៃដំណើរការអាជីវកម្មដោយ "ម៉ាកុស" យើងត្រូវដោះស្រាយបញ្ហាបច្ចេកវិទ្យាមួយចំនួន អំពីលំដាប់នីមួយៗ។

កិច្ចការ 1. តម្រូវការសម្រាប់ការធ្វើមាត្រដ្ឋានផ្ដេកនៃប្រព័ន្ធ

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

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

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

សេវាមីក្រូទាំងអស់ត្រូវបានដាក់ពង្រាយនៅក្នុងចង្កោម OpenShift ដែលដោះស្រាយបញ្ហានៃការធ្វើមាត្រដ្ឋាន microservice នីមួយៗ និងអនុញ្ញាតឱ្យយើងមិនប្រើឧបករណ៍ Service Discovery ភាគីទីបី។

កិច្ចការទី 2. តម្រូវការដើម្បីរក្សាការផ្ទុកខ្ពស់ និងការផ្លាស់ប្តូរទិន្នន័យដែលពឹងផ្អែកខ្លាំងរវាងសេវាកម្មវេទិកា៖ ក្នុងដំណាក់កាលចាប់ផ្តើមគម្រោងតែមួយ ប្រតិបត្តិការប្រហែល 600 ក្នុងមួយវិនាទីត្រូវបានអនុវត្ត។ យើងរំពឹងថាតម្លៃនេះនឹងកើនឡើងដល់ 5000 ops/sec ដោយសារហាងលក់រាយភ្ជាប់ទៅវេទិការបស់យើង។

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

ការយកចិត្តទុកដាក់ជាច្រើនត្រូវបានយកចិត្តទុកដាក់ចំពោះកំណត់ហេតុតាមដាន ដើម្បីកុំឱ្យ TraceId របស់ពួកគេបាត់បង់នៅពេលដែលមានករណីលើកលែងកើតឡើងក្នុងអំឡុងពេលប្រតិបត្តិការសេវាកម្ម ឬនៅពេលធ្វើការជាមួយ Kafka batch ។ ហើយប្រសិនបើមិនមានបញ្ហាពិសេសជាមួយទីមួយទេ នោះនៅក្នុងករណីទីពីរ យើងបង្ខំឱ្យកត់ត្រា TraceIds ទាំងអស់ដែលបាច់មកជាមួយ ហើយជ្រើសរើសមួយដើម្បីបន្តការតាមដាន។ បន្ទាប់មក នៅពេលស្វែងរកដោយ TraceId ដើម អ្នកប្រើប្រាស់នឹងដឹងយ៉ាងងាយស្រួលនូវអ្វីដែលការតាមដានបន្ត។

កិច្ចការទី 3. តំរូវការក្នុងការរក្សាទុកទិន្នន័យមួយចំនួនធំ៖ ស្លាកសញ្ញាច្រើនជាង 1 ពាន់លានក្នុងមួយឆ្នាំសម្រាប់ថ្នាំជក់តែមួយបានមកដល់ X5 ។ ពួកគេត្រូវការការចូលប្រើជាប្រចាំ និងរហ័ស។ សរុបមក ប្រព័ន្ធត្រូវតែដំណើរការប្រហែល 10 ពាន់លានកំណត់ត្រានៃប្រវត្តិចលនានៃទំនិញដែលមានស្លាកសញ្ញាទាំងនេះ។

ដើម្បីដោះស្រាយបញ្ហាទីបី មូលដ្ឋានទិន្នន័យ NoSQL MongoDB ត្រូវបានជ្រើសរើស។ យើងបានបង្កើត shard នៃ 5 nodes ហើយ node នីមួយៗមាន Replica Set of 3 servers។ នេះអនុញ្ញាតឱ្យអ្នកធ្វើមាត្រដ្ឋានប្រព័ន្ធដោយផ្ដេក បន្ថែមម៉ាស៊ីនមេថ្មីទៅក្នុងចង្កោម និងធានាបាននូវការអត់ឱនកំហុសរបស់វា។ នៅទីនេះយើងបានជួបប្រទះបញ្ហាមួយផ្សេងទៀត - ការធានានូវប្រតិបត្តិការនៅក្នុងចង្កោម mongo ដោយគិតគូរពីការប្រើប្រាស់សេវាកម្មមីក្រូដែលអាចធ្វើមាត្រដ្ឋានបានដោយផ្ដេក។ ជាឧទាហរណ៍ ភារកិច្ចមួយនៃប្រព័ន្ធរបស់យើងគឺកំណត់អត្តសញ្ញាណការប៉ុនប៉ងលក់ផលិតផលឡើងវិញជាមួយនឹងលេខកូដស្លាកដូចគ្នា។ នៅទីនេះ ការត្រួតគ្នាលេចឡើងជាមួយនឹងការស្កេនខុស ឬប្រតិបត្តិការខុសដោយអ្នកគិតលុយ។ យើងបានរកឃើញថាការស្ទួនគ្នាបែបនេះអាចកើតឡើងទាំងនៅក្នុងកញ្ចប់ Kafka មួយដែលកំពុងដំណើរការ ហើយក្នុងរយៈពេលពីរបាច់ត្រូវបានដំណើរការស្របគ្នា។ ដូច្នេះ ការ​ពិនិត្យ​មើល​ការ​ស្ទួន​ដោយ​ការ​សាកសួរ​មូលដ្ឋាន​ទិន្នន័យ​មិន​បាន​ផ្តល់​អ្វី​ទេ។ សម្រាប់សេវាមីក្រូនីមួយៗ យើងបានដោះស្រាយបញ្ហាដោយឡែកពីគ្នា ដោយផ្អែកលើតក្កវិជ្ជាអាជីវកម្មនៃសេវាកម្មនេះ។ ឧទាហរណ៍ សម្រាប់ការត្រួតពិនិត្យ យើងបានបន្ថែមមូលប្បទានប័ត្រមួយនៅខាងក្នុងបាច់ និងដំណើរការដាច់ដោយឡែកសម្រាប់រូបរាងនៃការស្ទួននៅពេលបញ្ចូល។

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

កិច្ចការទី ៤៖ ដំណើរការឡើងវិញ និងត្រួតពិនិត្យជួរ៖

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

ដើម្បីអនុវត្តគ្រោងការណ៍បែបនេះ យើងត្រូវការដូចខាងក្រោម៖ ដើម្បីបញ្ចូលដំណោះស្រាយនេះជាមួយ Spring និងជៀសវាងការចម្លងកូដ។ ខណៈពេលដែលកំពុងប្រើប្រាស់បណ្តាញ យើងបានជួបប្រទះនូវដំណោះស្រាយស្រដៀងគ្នាមួយដោយផ្អែកលើ Spring BeanPostProccessor ប៉ុន្តែវាហាក់បីដូចជាមានការពិបាកសម្រាប់ពួកយើង។ ក្រុមរបស់យើងបានបង្កើតដំណោះស្រាយដ៏សាមញ្ញមួយដែលអនុញ្ញាតឱ្យយើងបញ្ចូលទៅក្នុងវដ្តនិទាឃរដូវសម្រាប់ការបង្កើតអ្នកប្រើប្រាស់ និងបន្ថែមការសាកល្បងអ្នកប្រើប្រាស់ម្តងទៀត។ យើងបានផ្តល់គំរូដើមនៃដំណោះស្រាយរបស់យើងដល់ក្រុម Spring អ្នកអាចមើលឃើញវា។ នៅទីនេះ. ចំនួនអ្នកប្រើប្រាស់ម្តងទៀត និងចំនួននៃការព្យាយាមសម្រាប់អ្នកប្រើប្រាស់នីមួយៗត្រូវបានកំណត់រចនាសម្ព័ន្ធតាមប៉ារ៉ាម៉ែត្រ អាស្រ័យលើតម្រូវការនៃដំណើរការអាជីវកម្ម ហើយដើម្បីឱ្យអ្វីៗដំណើរការបាន អ្វីដែលនៅសេសសល់គឺត្រូវបន្ថែមចំណារពន្យល់ org.springframework.kafka.annotation.KafkaListener ដែលស្គាល់អ្នកអភិវឌ្ឍន៍ Spring ទាំងអស់។

ប្រសិនបើសារមិនអាចដំណើរការបានបន្ទាប់ពីការព្យាយាមម្តងទៀតទាំងអស់ វាទៅ DLT (ប្រធានបទលិខិតស្លាប់) ដោយប្រើ Spring DeadLetterPublishingRecoverer ។ តាមសំណើនៃការគាំទ្រ យើងបានពង្រីកមុខងារនេះ និងបង្កើតសេវាកម្មដាច់ដោយឡែកដែលអនុញ្ញាតឱ្យអ្នកមើលសារដែលមាននៅក្នុង DLT, stackTrace, traceId និងព័ត៌មានមានប្រយោជន៍ផ្សេងទៀតអំពីពួកគេ។ លើសពីនេះទៀត ការត្រួតពិនិត្យ និងការដាស់តឿនត្រូវបានបន្ថែមទៅលើប្រធានបទ DLT ទាំងអស់ ហើយឥឡូវនេះ តាមពិតទៅ ការលេចចេញនូវសារនៅក្នុងប្រធានបទ DLT គឺជាហេតុផលដើម្បីវិភាគ និងជួសជុលពិការភាពមួយ។ នេះគឺងាយស្រួលណាស់ - តាមឈ្មោះប្រធានបទយើងយល់ភ្លាមៗនៅជំហាននៃដំណើរការដែលបញ្ហាបានកើតឡើងដែលបង្កើនល្បឿនយ៉ាងខ្លាំងក្នុងការស្វែងរកមូលហេតុរបស់វា។

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

ប្រតិបត្តិការវេទិកា

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

ក្រុមទាំងមូលរបស់យើងចូលរួមក្នុងការដឹកនាំអ្នកបើកយន្តហោះ វិភាគបញ្ហាដែលកំពុងកើតឡើង និងផ្តល់យោបល់សម្រាប់ការកែលម្អផលិតផលរបស់យើង ពីការកែលម្អកំណត់ហេតុរហូតដល់ដំណើរការផ្លាស់ប្តូរ។

ដើម្បីកុំឱ្យកំហុសរបស់យើងកើតឡើងដដែលៗ ករណីទាំងអស់ដែលបានរកឃើញក្នុងអំឡុងពេលអ្នកបើកយន្តហោះត្រូវបានឆ្លុះបញ្ចាំងនៅក្នុងការធ្វើតេស្តស្វ័យប្រវត្តិ។ វត្តមាននៃការធ្វើតេស្តស្វ័យប្រវត្តិ និងការធ្វើតេស្តឯកតាមួយចំនួនធំ អនុញ្ញាតឱ្យអ្នកធ្វើការធ្វើតេស្តតំរែតំរង់ និងដំឡើងកម្មវិធីជួសជុលតាមព្យញ្ជនៈក្នុងរយៈពេលពីរបីម៉ោង។

ឥឡូវនេះ យើងបន្តអភិវឌ្ឍ និងកែលម្អវេទិការបស់យើង ហើយប្រឈមមុខនឹងបញ្ហាប្រឈមថ្មីៗជានិច្ច។ ប្រសិនបើអ្នកចាប់អារម្មណ៍ យើងនឹងនិយាយអំពីដំណោះស្រាយរបស់យើងនៅក្នុងអត្ថបទខាងក្រោម។

ប្រភព: www.habr.com