របៀបដែលយើងបង្កើត cloud FaaS នៅខាងក្នុង Kubernetes និងបានឈ្នះ Tinkoff hackathon

ចាប់ពីឆ្នាំមុន ក្រុមហ៊ុនរបស់យើងបានចាប់ផ្តើមរៀបចំកម្មវិធី hackathons ។ ការ​ប្រកួត​ប្រជែង​បែប​នេះ​ដំបូង​គេ​ទទួល​បាន​ជោគជ័យ​ខ្លាំង​ណាស់ យើង​បាន​សរសេរ​អំពី​វា​នៅ​ក្នុង អត្ថបទ. ការ hackathon លើកទីពីរបានធ្វើឡើងនៅក្នុងខែកុម្ភៈ 2019 ហើយមិនតិចទេ។ អំពី​គោល​ដៅ​នៃ​ការ​កាន់​ក្រោយ​មិន​យូរ​ប៉ុន្មាន​កន្លង​មក​នេះ​ បានសរសេរ អ្នករៀបចំ។

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

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

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

តើអ្វីទៅជាពិន្ទុ

Tinkoff.ru ដូចជាក្រុមហ៊ុនទំនើប ៗ ជាច្រើនមានការវាយតម្លៃអតិថិជន។ ការដាក់ពិន្ទុគឺជាប្រព័ន្ធវាយតម្លៃអតិថិជនដោយផ្អែកលើវិធីសាស្រ្តស្ថិតិនៃការវិភាគទិន្នន័យ។

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

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

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

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

សម្រាប់កិច្ចការនៅក្នុងដៃ យើងប្រើប្រាស់ប្រព័ន្ធធ្វើការសម្រេចចិត្តឯកទេសរួចហើយ IBM WebSphere ILOG JRules BRMSដែលផ្អែកលើច្បាប់កំណត់ដោយអ្នកវិភាគ អ្នកបច្ចេកទេស និងអ្នកអភិវឌ្ឍន៍ សម្រេចថាតើត្រូវអនុម័ត ឬបដិសេធផលិតផលធនាគារជាក់លាក់ណាមួយដល់អតិថិជន។

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

កិច្ចការ

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

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

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

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

ដំណោះស្រាយរបស់យើង។

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

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

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

1. អ្នកវិភាគសរសេរស្គ្រីប ច្បាប់ ឬគំរូ ML ដោយផ្អែកលើទិន្នន័យពីឃ្លាំង។ ជាផ្នែកមួយនៃការ hackathon យើងបានសម្រេចចិត្តប្រើ Mongodb ប៉ុន្តែជម្រើសនៃប្រព័ន្ធផ្ទុកទិន្នន័យមិនសំខាន់នៅទីនេះទេ។
2. បន្ទាប់​ពី​បាន​សាកល្បង​ច្បាប់​ដែល​បាន​បង្កើត​លើ​ទិន្នន័យ​ប្រវត្តិសាស្ត្រ អ្នក​វិភាគ​បង្ហោះ​កូដ​របស់​គាត់​ទៅ​ផ្ទាំង​គ្រប់គ្រង។
3. ដើម្បីធានាឱ្យមានកំណែ លេខកូដទាំងអស់នឹងទៅកាន់ឃ្លាំង Git ។
4. តាមរយៈផ្ទាំងគ្រប់គ្រង វានឹងអាចដាក់ពង្រាយកូដក្នុងពពកជាម៉ូឌុល Serverless មុខងារដាច់ដោយឡែក។

ទិន្នន័យដំបូងពីអតិថិជនត្រូវតែឆ្លងកាត់សេវាកម្ម Enrichment ឯកទេសដែលត្រូវបានរចនាឡើងដើម្បីពង្រឹងសំណើដំបូងជាមួយនឹងទិន្នន័យពីឃ្លាំង។ វាមានសារៈសំខាន់ណាស់ក្នុងការអនុវត្តសេវាកម្មនេះតាមរបៀបដែលវានឹងដំណើរការជាមួយឃ្លាំងតែមួយ (ដែលអ្នកវិភាគយកទិន្នន័យនៅពេលបង្កើតច្បាប់) ដើម្បីរក្សារចនាសម្ព័ន្ធទិន្នន័យរួមមួយ។

សូម្បីតែមុនពេល hackathon យើងបានសម្រេចចិត្តលើក្របខ័ណ្ឌ Serverless ដែលយើងនឹងប្រើ។ សព្វថ្ងៃនេះមានបច្ចេកវិទ្យាជាច្រើននៅលើទីផ្សារដែលអនុវត្តវិធីសាស្រ្តនេះ។ ដំណោះស្រាយពេញនិយមបំផុតនៅក្នុងស្ថាបត្យកម្ម Kubernetes គឺ Fission, Open FaaS និង Kubeless ។ មានសូម្បីតែ អត្ថបទល្អជាមួយនឹងការពិពណ៌នានិងការវិភាគប្រៀបធៀបរបស់ពួកគេ។.

បន្ទាប់ពីថ្លឹងថ្លែងនូវគុណសម្បត្តិ និងគុណវិបត្តិទាំងអស់ យើងបានជ្រើសរើស ការបំភាន់. ក្របខ័ណ្ឌ Serverless នេះពិតជាងាយស្រួលក្នុងការគ្រប់គ្រង និងបំពេញតាមតម្រូវការនៃកិច្ចការ។

ដើម្បីធ្វើការជាមួយ Fission អ្នកត្រូវយល់ពីគោលគំនិតជាមូលដ្ឋានចំនួនពីរ៖ មុខងារ និងបរិស្ថាន។ អនុគមន៍​គឺ​ជា​បំណែក​នៃ​កូដ​ដែល​សរសេរ​ជា​ភាសា​មួយ​ដែល​មាន​បរិយាកាស​ Fission។ បញ្ជីបរិស្ថានដែលបានអនុវត្តក្នុងក្របខ័ណ្ឌនេះ។ រួមមាន Python, JS, Go, JVM និងភាសា និងបច្ចេកវិទ្យាពេញនិយមជាច្រើនទៀត។

Fission ក៏មានសមត្ថភាពក្នុងការអនុវត្តមុខងារដែលបែងចែកជាឯកសារជាច្រើន ដោយបានខ្ចប់ជាមុនទៅក្នុងបណ្ណសារ។ ប្រតិបត្តិការរបស់ Fission នៅក្នុងចង្កោម Kubernetes ត្រូវបានធានាដោយផ្នែកឯកទេស ដែលត្រូវបានគ្រប់គ្រងដោយក្របខ័ណ្ឌខ្លួនឯង។ ដើម្បី​ធ្វើ​អន្តរកម្ម​ជាមួយ​ដុំ​ចង្កោម មុខងារ​នីមួយៗ​ត្រូវ​តែ​ត្រូវ​បាន​កំណត់​ផ្លូវ​ផ្ទាល់​ខ្លួន​របស់​វា ហើយ​ដែល​អ្នក​អាច​ឆ្លង​កាត់​ប៉ារ៉ាម៉ែត្រ GET ឬ​ស្នើ​តួ​ក្នុង​ករណី​នៃ​សំណើ POST។

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

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

អ្វីដែលយើងទទួលបាន

ចាប់តាំងពីយើងបានមកដល់កម្មវិធី hackathon ជាមួយនឹងដំណោះស្រាយដែលត្រៀមរួចជាស្រេច (នៅក្នុងការស្រមើស្រមៃរបស់យើង) អ្វីដែលយើងត្រូវធ្វើគឺបំប្លែងគំនិតរបស់យើងទាំងអស់ទៅជាកូដ។

គន្លឹះដើម្បីជោគជ័យក្នុងកម្មវិធី hackathon គឺការរៀបចំ និងផែនការសរសេរបានល្អ។ ដូច្នេះ រឿងដំបូងដែលយើងបានធ្វើគឺសម្រេចចិត្តថាតើម៉ូឌុលស្ថាបត្យកម្មប្រព័ន្ធរបស់យើងនឹងមាន និងបច្ចេកវិទ្យាអ្វីដែលយើងនឹងប្រើ។

ស្ថាបត្យកម្មនៃគម្រោងរបស់យើងមានដូចខាងក្រោម៖

ដ្យាក្រាមនេះបង្ហាញពីចំណុចចូលពីរ គឺអ្នកវិភាគ (អ្នកប្រើប្រាស់សំខាន់នៃប្រព័ន្ធរបស់យើង) និងអតិថិជន។

ដំណើរការការងារត្រូវបានរៀបចំដូចនេះ។ អ្នកវិភាគបង្កើតមុខងារច្បាប់ និងមុខងារបង្កើនទិន្នន័យសម្រាប់គំរូរបស់គាត់ រក្សាទុកកូដរបស់គាត់នៅក្នុងឃ្លាំង Git និងដាក់ពង្រាយគំរូរបស់គាត់ទៅពពកតាមរយៈកម្មវិធីអ្នកគ្រប់គ្រង។ ចូរយើងពិចារណាពីរបៀបដែលមុខងារដែលបានដាក់ពង្រាយនឹងត្រូវបានហៅ និងធ្វើការសម្រេចចិត្តលើសំណើចូលពីអតិថិជន៖

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

យើងបានសម្រេចចិត្តប្រើ MongoDB ជាកន្លែងផ្ទុកនៅក្នុងប្រព័ន្ធរបស់យើង ដោយសារការផ្ទុកទិន្នន័យតម្រង់ទិសឯកសារក្នុងទម្រង់ឯកសារ JSON ចាប់តាំងពីសេវាកម្មពង្រឹង រួមទាំងសំណើដើមបានប្រមូលផ្តុំទិន្នន័យទាំងអស់តាមរយៈឧបករណ៍បញ្ជា REST ។

ដូច្នេះ យើងមានពេល XNUMX ម៉ោងដើម្បីអនុវត្តវេទិកានេះ។ យើងបានចែកចាយតួនាទីយ៉ាងជោគជ័យ សមាជិកក្រុមនីមួយៗមានផ្នែកទទួលខុសត្រូវផ្ទាល់ខ្លួននៅក្នុងគម្រោងរបស់យើង៖

1. ផ្ទាំងគ្រប់គ្រងផ្នែកខាងមុខសម្រាប់ការងាររបស់អ្នកវិភាគ តាមរយៈការដែលគាត់អាចទាញយកច្បាប់ពីប្រព័ន្ធគ្រប់គ្រងកំណែនៃស្គ្រីបដែលបានសរសេរ ជ្រើសរើសជម្រើសសម្រាប់ការពង្រឹងទិន្នន័យបញ្ចូល និងកែសម្រួលស្គ្រីបច្បាប់តាមអ៊ីនធឺណិត។
2. អ្នកគ្រប់គ្រងផ្នែកខាងក្រោយ រួមទាំង REST API សម្រាប់ផ្នែកខាងមុខ និងការរួមបញ្ចូលជាមួយ VCS ។
3. ការដំឡើងហេដ្ឋារចនាសម្ព័ន្ធនៅក្នុង Google Cloud និងបង្កើតសេវាកម្មសម្រាប់ការពង្រឹងទិន្នន័យប្រភព។
4. ម៉ូឌុលសម្រាប់ការរួមបញ្ចូលកម្មវិធីគ្រប់គ្រងជាមួយក្របខ័ណ្ឌ Serverless សម្រាប់ការដាក់ឱ្យប្រើប្រាស់ជាបន្តបន្ទាប់នៃច្បាប់។
5. ស្គ្រីបនៃច្បាប់សម្រាប់សាកល្បងដំណើរការនៃប្រព័ន្ធទាំងមូល និងការប្រមូលផ្តុំនៃការវិភាគលើកម្មវិធីចូល (ការសម្រេចចិត្តដែលបានធ្វើឡើង) សម្រាប់ការបង្ហាញចុងក្រោយ។

តោះចាប់ផ្តើមតាមលំដាប់លំដោយ។

ផ្នែកខាងមុខរបស់យើងត្រូវបានសរសេរនៅក្នុង Angular 7 ដោយប្រើ UI Kit របស់ធនាគារ។ កំណែចុងក្រោយនៃផ្ទាំងគ្រប់គ្រងមើលទៅដូចនេះ៖

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

កូដមុខងារទាំងអស់ត្រូវបានរក្សាទុកនៅក្នុងឃ្លាំង Git ពីចម្ងាយ ដែលត្រូវតែកំណត់នៅក្នុងផ្ទាំងគ្រប់គ្រងផងដែរ។ ដើម្បីកំណែកូដ មុខងារទាំងអស់ត្រូវបានរក្សាទុកនៅក្នុងសាខាផ្សេងគ្នានៃឃ្លាំង។ បន្ទះគ្រប់គ្រងក៏ផ្តល់នូវសមត្ថភាពក្នុងការធ្វើការកែតម្រូវលើស្គ្រីបដែលបានសរសេរផងដែរ ដូច្នេះមុនពេលដាក់ពង្រាយមុខងារទៅផលិតកម្ម អ្នកមិនត្រឹមតែអាចពិនិត្យមើលកូដដែលបានសរសេរប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងធ្វើការផ្លាស់ប្តូរចាំបាច់ផងដែរ។

បន្ថែមពីលើមុខងារច្បាប់ យើងក៏បានអនុវត្តសមត្ថភាពក្នុងការបង្កើនទិន្នន័យប្រភពជាបណ្តើរៗដោយប្រើមុខងារ Enrichment ដែលកូដនោះក៏ជាស្គ្រីបដែលអាចចូលទៅឃ្លាំងទិន្នន័យ ហៅទូរសព្ទទៅសេវាភាគីទីបី និងធ្វើការគណនាបឋម។ . ដើម្បីបង្ហាញពីដំណោះស្រាយរបស់យើង យើងបានគណនាសញ្ញារាសីចក្ររបស់អតិថិជនដែលបានចាកចេញពីសំណើ និងកំណត់ប្រតិបត្តិករទូរស័ព្ទចល័តរបស់គាត់ដោយប្រើប្រាស់សេវាកម្ម REST ភាគីទីបី។

ផ្នែកខាងក្រោយនៃវេទិកាត្រូវបានសរសេរជា Java និងបានអនុវត្តជាកម្មវិធី Spring Boot ។ ដំបូងឡើយ យើងមានគម្រោងប្រើ Postgres ដើម្បីរក្សាទុកទិន្នន័យអ្នកគ្រប់គ្រង ប៉ុន្តែជាផ្នែកមួយនៃការ hackathon យើងបានសម្រេចចិត្តដាក់កម្រិតខ្លួនយើងទៅ H2 សាមញ្ញ ដើម្បីសន្សំពេលវេលា។ នៅលើផ្នែកខាងក្រោយ ការធ្វើសមាហរណកម្មជាមួយ Bitbucket ត្រូវបានអនុវត្តដើម្បីកំណែមុខងារពង្រឹងសំណួរ និងស្គ្រីបច្បាប់។ សម្រាប់ការរួមបញ្ចូលជាមួយឃ្លាំង Git ពីចម្ងាយ យើងបានប្រើ បណ្ណាល័យ JGitដែលជាប្រភេទនៃការរុំលើពាក្យបញ្ជា CLI ដែលអនុញ្ញាតឱ្យអ្នកប្រតិបត្តិការណែនាំ git ដោយប្រើចំណុចប្រទាក់កម្មវិធីងាយស្រួល។ ដូច្នេះ យើង​មាន​ឃ្លាំង​ពីរ​ដាច់​ដោយ​ឡែក​សម្រាប់​មុខងារ និង​ច្បាប់​ពង្រឹង ហើយ​ស្គ្រីប​ទាំងអស់​ត្រូវ​បាន​បែងចែក​ជា​ថត។ តាមរយៈ UI វាអាចជ្រើសរើសការប្តេជ្ញាចិត្តចុងក្រោយបំផុតនៃស្គ្រីបនៃសាខាតាមអំពើចិត្តនៃឃ្លាំង។ នៅពេលធ្វើការផ្លាស់ប្តូរកូដតាមរយៈផ្ទាំងគ្រប់គ្រង ការប្តេជ្ញាចិត្តនៃកូដដែលបានផ្លាស់ប្តូរត្រូវបានបង្កើតនៅក្នុងឃ្លាំងពីចម្ងាយ។

ដើម្បីអនុវត្តគំនិតរបស់យើង យើងត្រូវការហេដ្ឋារចនាសម្ព័ន្ធសមស្រប។ យើងបានសម្រេចចិត្តដាក់ពង្រាយក្រុម Kubernetes របស់យើងនៅក្នុងពពក។ ជម្រើសរបស់យើងគឺ Google Cloud Platform ។ Fission serverless framework ត្រូវបានដំឡើងនៅលើចង្កោម Kubernetes ដែលយើងបានដាក់ពង្រាយនៅក្នុង Gcloud។ ដំបូង សេវាពង្រឹងទិន្នន័យប្រភពត្រូវបានអនុវត្តជាកម្មវិធី Java ដាច់ដោយឡែកដែលរុំក្នុង Pod នៅខាងក្នុងចង្កោម k8s ។ ប៉ុន្តែបន្ទាប់ពីការបង្ហាញបឋមនៃគម្រោងរបស់យើងនៅពាក់កណ្តាលនៃកម្មវិធី hackathon យើងត្រូវបានគេណែនាំអោយធ្វើឱ្យសេវាកម្ម Enrichment មានភាពបត់បែនជាងមុន ដើម្បីផ្តល់ឱកាសក្នុងការជ្រើសរើសពីរបៀបបង្កើនទិន្នន័យឆៅនៃកម្មវិធីដែលចូលមក។ ហើយ​យើង​គ្មាន​ជម្រើស​ក្រៅ​ពី​ធ្វើ​ឱ្យ​សេវា​ពង្រឹង​ក៏ Serverless ដែរ។

ដើម្បីធ្វើការជាមួយ Fission យើងបានប្រើ Fission CLI ដែលត្រូវតែដំឡើងនៅលើ Kubernetes CLI ។ ការដាក់ពង្រាយមុខងារទៅក្នុងចង្កោម k8s គឺសាមញ្ញណាស់ អ្នកគ្រាន់តែត្រូវកំណត់ផ្លូវខាងក្នុង ហើយបញ្ចូលទៅក្នុងមុខងារ ដើម្បីអនុញ្ញាតចរាចរណ៍ចូល ប្រសិនបើការចូលប្រើខាងក្រៅចង្កោមគឺចាំបាច់។ ការដាក់ឱ្យប្រើប្រាស់មុខងារមួយជាធម្មតាចំណាយពេលមិនលើសពី 10 វិនាទី។

បទបង្ហាញចុងក្រោយនៃគម្រោង និងសង្ខេប

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

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

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

មានផលិតផលធនាគារប្រឌិតចំនួន 3 ដែលអាចរកបាន៖

• ឥណទាន។
• តុក្កតា
• បញ្ចាំ។

ក្នុងអំឡុងពេលនៃការធ្វើបាតុកម្ម យើងបានដាក់ពង្រាយមុខងារដែលបានរៀបចំ និងស្គ្រីបពង្រឹងសម្រាប់សេវាកម្មនីមួយៗ។

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

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

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

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

ប្រភព: www.habr.com