ឌីកូតូមីតទិន្នន័យ៖ គិតឡើងវិញនូវទំនាក់ទំនងរវាងទិន្នន័យ និងសេវាកម្ម

សួស្តី​អ្នក​ទាំងអស់គ្នា! យើងមានព័ត៌មានដ៏អស្ចារ្យ OTUS នឹងចាប់ផ្តើមវគ្គសិក្សាម្តងទៀតនៅក្នុងខែមិថុនា "ស្ថាបត្យករផ្នែកទន់"ទាក់ទងនឹងអ្វីដែលជាប្រពៃណីយើងចែករំលែកសម្ភារៈមានប្រយោជន៍ជាមួយអ្នក។

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

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

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

ពិភពលោកដែលចែកចាយនេះគឺខុសពីអ្វីដែលយើងធំដឹងក្តី និងធ្លាប់ស្គាល់។ គោលការណ៍នៃការសាងសង់ស្ថាបត្យកម្ម monolithic ប្រពៃណីមិនឈរចំពោះការរិះគន់ទេ។ ដូច្នេះ ការធ្វើឱ្យប្រព័ន្ធទាំងនេះត្រឹមត្រូវគឺច្រើនជាងការបង្កើតដ្យាក្រាមក្តារខៀនដ៏ត្រជាក់ ឬភស្តុតាងដ៏ត្រជាក់នៃគំនិត។ ចំណុចគឺដើម្បីធានាថាប្រព័ន្ធបែបនេះដំណើរការដោយជោគជ័យក្នុងរយៈពេលយូរ។ ជាសំណាងល្អ សេវាកម្មបានដំណើរការអស់មួយរយៈមកហើយ ទោះបីជាវាមើលទៅខុសគ្នាក៏ដោយ។ មេរៀន SOA នៅតែពាក់ព័ន្ធ ទោះបីជាមានរដូវកាលជាមួយ Docker, Kubernetes និងពុកចង្ការ hipster បន្តិច។

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

Encapsulation នឹងមិនតែងតែជាមិត្តរបស់អ្នកទេ។

សេវាមីក្រូអាចដំណើរការដោយឯករាជ្យពីគ្នាទៅវិញទៅមក។ វាគឺជាទ្រព្យសម្បត្តិនេះដែលផ្តល់ឱ្យពួកគេនូវតម្លៃដ៏អស្ចារ្យបំផុត។ ទ្រព្យសម្បត្តិដូចគ្នានេះអនុញ្ញាតឱ្យសេវាកម្មធ្វើមាត្រដ្ឋាន និងរីកចម្រើន។ មិនច្រើនទេក្នុងន័យនៃការធ្វើមាត្រដ្ឋានដល់អ្នកប្រើប្រាស់ quadrillions ឬ petabytes នៃទិន្នន័យ (ទោះបីជាវាអាចជួយនៅទីនោះផងដែរ) ប៉ុន្តែក្នុងន័យនៃការធ្វើមាត្រដ្ឋាននៅក្នុងលក្ខខណ្ឌនៃមនុស្សនៅពេលដែលក្រុម និងអង្គការរីកចម្រើនជាបន្តបន្ទាប់។

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

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

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

សេវាកម្មអាជីវកម្មភាគច្រើនចែករំលែកស្ទ្រីមទិន្នន័យដូចគ្នា ដូច្នេះការងាររបស់ពួកគេគឺជាប់ទាក់ទងគ្នាមិនទៀងទាត់។

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

ឌីកូតូមីតទិន្នន័យ

វិធីសាស្រ្តតម្រង់ទិសសេវាកម្មអាចមានរួចហើយ ប៉ុន្តែពួកគេនៅតែខ្វះការយល់ដឹងអំពីរបៀបចែករំលែកទិន្នន័យដ៏ច្រើនរវាងសេវាកម្ម។

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

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

ហើយនៅទីនេះបញ្ហាកើតឡើង។ ភាពផ្ទុយគ្នា។ ឌីកូតូមៀ។ យ៉ាងណាមិញ ប្រព័ន្ធព័ត៌មាននិយាយអំពីការផ្តល់ទិន្នន័យ ហើយសេវាកម្មគឺអំពីការលាក់បាំង។

កម្លាំងទាំងពីរនេះគឺជាមូលដ្ឋាន។ ពួកគេគាំទ្រការងាររបស់យើងជាច្រើន ដោយតស៊ូឥតឈប់ឈរដើម្បីភាពល្អឥតខ្ចោះនៅក្នុងប្រព័ន្ធដែលយើងបង្កើត។

នៅពេលដែលប្រព័ន្ធសេវាកម្មរីកចម្រើន និងវិវឌ្ឍ យើងឃើញពីផលវិបាកនៃទិន្នន័យ dichotomy តាមវិធីជាច្រើន។ ទាំងចំណុចប្រទាក់សេវាកម្មនឹងកើនឡើង ដោយផ្តល់នូវមុខងារដែលកើនឡើងឥតឈប់ឈរ ហើយចាប់ផ្តើមមើលទៅដូចជាមូលដ្ឋានទិន្នន័យដែលមានលក្ខណៈស្រើបស្រាលបំផុត ឬយើងនឹងមានការខកចិត្ត និងអនុវត្តវិធីមួយចំនួនដើម្បីទាញយក ឬផ្លាស់ប្តូរសំណុំទិន្នន័យទាំងមូលពីសេវាកម្មមួយទៅសេវាកម្មមួយ។

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

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

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

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

ការចម្លងកាន់តែច្រើនអាចផ្លាស់ប្តូរបាន ទិន្នន័យនឹងប្រែប្រួលតាមពេលវេលា។

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

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

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

វដ្តនៃការបរាជ័យទិន្នន័យ

ស្ទ្រីម៖ វិធីសាស្រ្តវិមជ្ឈការចំពោះទិន្នន័យ និងសេវាកម្ម

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

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

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

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

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

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

លុបបំបាត់ dichotomy ទិន្នន័យដោយបំបែកចរន្តរដ្ឋដែលមិនអាចផ្លាស់ប្តូរបាន។ បន្ទាប់មកបន្ថែមមុខងារនេះទៅគ្រប់សេវាកម្មដោយប្រើប្រាស់ Stateful Stream Processing។

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

ចែករំលែកទិន្នន័យដោយមិនធ្វើឱ្យខូចគុណភាពរបស់វា។ បញ្ចូលមុខងារ មិនមែនប្រភពទេ នៅគ្រប់សេវាកម្មដែលត្រូវការវា។

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

ដូច្នេះ វិធីសាស្រ្តដែលបានពិភាក្សាថ្ងៃនេះមានអត្ថប្រយោជន៍ជាច្រើន៖

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

ដូចដែលអ្នកអាចឃើញ នេះគឺច្រើនជាង REST ប៉ុណ្ណោះ។ យើងបានទទួលសំណុំឧបករណ៍ដែលអនុញ្ញាតឱ្យអ្នកធ្វើការជាមួយទិន្នន័យដែលបានចែករំលែកក្នុងលក្ខណៈវិមជ្ឈការ។

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

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

ស្វែងយល់បន្ថែមអំពីវគ្គសិក្សា។

ប្រភព: www.habr.com