វិធីសាស្រ្តគ្មានម៉ាស៊ីនមេសម្រាប់ការអភិវឌ្ឍន៍យ៉ាងឆាប់រហ័សនៃសេវាកម្មវីដេអូដែលកំពុងដំណើរការ

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

បានផ្តល់ឱ្យ៖ គណនី root នៅលើ AWS គ្មានការរឹតបន្តឹងលើជម្រើសនៃជង់បច្ចេកវិទ្យា ផ្ទាំងខាងក្រោយមួយ និងរយៈពេលមួយខែសម្រាប់ការអភិវឌ្ឍន៍។

ភារកិច្ច៖ អនុវត្តសេវាកម្មផ្សព្វផ្សាយដែលអ្នកប្រើប្រាស់បង្ហោះពីមួយទៅបួនវីដេអូដែលមានរយៈពេលពីមួយទៅបួនវិនាទី ដែលបន្ទាប់មកត្រូវបានបង្កប់នៅក្នុងស៊េរីវីដេអូដើម។

ការសម្រេចចិត្ត

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

ដំណោះស្រាយស្តង់ដារសម្រាប់ធ្វើការជាមួយវីដេអូគឺ FFmpeg ដែលជាឧបករណ៍ប្រើប្រាស់កុងសូលឆ្លងវេទិកាដែលតាមរយៈអំណះអំណាងអនុញ្ញាតឱ្យអ្នកកាត់ និងមើលសំឡេងលើស។ អ្វី​ដែល​នៅ​សេសសល់​គឺ​សរសេរ​ក្រដាស​រុំ ហើយ​បញ្ចេញ​វា​ទៅក្នុង​ជីវិត។ យើង​សរសេរ​គំរូ​មួយ​ដែល​ដេរ​វីដេអូ​ពីរ​ចូល​គ្នា ហើយ... ភាព​សប្បាយ​រីករាយ​បាន​ចាប់​ផ្ដើម។ បណ្ណាល័យគឺផ្អែកលើ .NET Core 2 វាគួរតែដំណើរការលើម៉ាស៊ីននិម្មិតណាមួយ ដូច្នេះយើងយកឧទាហរណ៍ AWS EC2 ហើយអ្វីៗនឹងដំណើរការ

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

សេវាកម្មរបស់យើងមិនពាក់ព័ន្ធនឹងដំណើរការដែលដំណើរការយូរ មិនតម្រូវឱ្យមានមូលដ្ឋានទិន្នន័យទំនាក់ទំនងធំ និងខ្លាញ់ និងសមឥតខ្ចោះទៅក្នុងស្ថាបត្យកម្មផ្អែកលើព្រឹត្តិការណ៍ជាមួយនឹងខ្សែសង្វាក់នៃការហៅទូរសព្ទខ្នាតតូច។ ដំណោះស្រាយណែនាំខ្លួនវា - យើងអាចបោះបង់ចោល EC2 និងអនុវត្តកម្មវិធីពិត-serverless ដូចជា ស្តង់ដាររូបភាព Resizer ផ្អែកលើ AWS Lambda ជាដើម។

ដោយវិធីនេះ ថ្វីបើមានការមិនចូលចិត្តយ៉ាងច្បាស់របស់អ្នកអភិវឌ្ឍន៍ AWS សម្រាប់ .NET ក៏ដោយ ក៏ពួកគេគាំទ្រ .NET Core 2.1 ជាពេលដំណើរការ ដែលផ្តល់នូវឱកាសអភិវឌ្ឍន៍ពេញលេញ។

និង cherry នៅលើនំ - AWS ផ្តល់សេវាកម្មដាច់ដោយឡែកសម្រាប់ធ្វើការជាមួយឯកសារវីដេអូ - AWS Elemental MediaConvert ។

ខ្លឹមសារនៃការងារគឺសាមញ្ញមិនគួរឱ្យជឿ៖ យើងយកតំណភ្ជាប់ S3 ទៅកាន់វីដេអូចេញ សរសេរតាមរយៈ AWS Console, .NET SDK ឬសាមញ្ញ JSON នូវអ្វីដែលយើងចង់ធ្វើជាមួយវីដេអូ ហើយហៅសេវាកម្ម។ វាខ្លួនវាអនុវត្តជួរសម្រាប់ដំណើរការសំណើចូល ផ្ទុកលទ្ធផលទៅ S3 ខ្លួនវា ហើយសំខាន់បំផុតគឺបង្កើត CloudWatch Event សម្រាប់ការផ្លាស់ប្តូរស្ថានភាពនីមួយៗ។ វាអនុញ្ញាតឱ្យយើងអនុវត្ត lambda triggers ដើម្បីបញ្ចប់ដំណើរការវីដេអូ។

នេះជាអ្វីដែលស្ថាបត្យកម្មចុងក្រោយមើលទៅ៖

ផ្នែកខាងក្រោយទាំងមូលត្រូវបានដាក់នៅក្នុង lambdas ពីរ។ មួយ​ទៀត​គឺ​សម្រាប់​បង្វិល​វីដេអូ​បញ្ឈរ ព្រោះ​ការងារ​បែប​នេះ​មិន​អាច​ធ្វើ​បាន​ក្នុង​មួយ​វគ្គ​ទេ។

យើងនឹងដាក់ផ្នែកខាងមុខជាទម្រង់កម្មវិធី SPA ដែលសរសេរក្នុង JS ហើយចងក្រងតាមរយៈ pug នៅក្នុងធុង S3 សាធារណៈ។ ដើម្បីទាញយកវីដេអូដោយខ្លួនឯង យើងមិនត្រូវការលេខកូដម៉ាស៊ីនមេទេ - យើងគ្រាន់តែត្រូវការបើកចំណុចបញ្ចប់ REST ដែល S3 ផ្តល់ឱ្យយើង។ រឿងតែមួយគត់គឺកុំភ្លេចកំណត់រចនាសម្ព័ន្ធគោលនយោបាយនិង CORS ។

ចំនុចគ្រោះថ្នាក់

• AWS MediaConvert សម្រាប់ហេតុផលដែលមិនស្គាល់មួយចំនួន អនុវត្តតែសំឡេងចំពោះបំណែកវីដេអូនីមួយៗដាច់ដោយឡែក ប៉ុន្តែយើងត្រូវការបទចម្រៀងរីករាយពីធាតុរក្សាអេក្រង់ទាំងមូល។
• វីដេអូបញ្ឈរត្រូវដំណើរការដោយឡែកពីគ្នា។ AWS មិនចូលចិត្តរបារខ្មៅ ហើយដាក់ rollers នៅមុំ 90°។

កន្លែងជិះស្គីងាយស្រួល

ទោះបីជាមានភាពស្រស់ស្អាតនៃ Stateless ក៏ដោយ អ្នកត្រូវតាមដាននូវអ្វីដែលត្រូវធ្វើជាមួយវីដេអូ៖ កាវ ឬបន្ថែមសំឡេងទៅក្នុងលំដាប់វីដេអូដែលបានបញ្ចប់។ ជាសំណាងល្អ MediaConvert គាំទ្រការបញ្ជូនទិន្នន័យមេតាតាមរយៈការងាររបស់វា ហើយយើងតែងតែអាចប្រើទង់សាមញ្ញនៃទម្រង់ “isMasterSoundJob” ដោយញែកទិន្នន័យមេតានេះនៅគ្រប់ដំណាក់កាល។

Serverless អនុញ្ញាតឱ្យធ្វើការជាមួយ NoOps យ៉ាងល្អឥតខ្ចោះ - វិធីសាស្រ្តដែលសន្មត់ភាពមិនចាំបាច់នៃក្រុមដាច់ដោយឡែកដែលទទួលខុសត្រូវចំពោះហេដ្ឋារចនាសម្ព័ន្ធគម្រោង។ ដូច្នេះ វា​ជា​បញ្ហា​តូច​មួយ យើង​ដាក់​ពង្រាយ​ដំណោះ​ស្រាយ​លើ AWS ដោយ​មិន​មាន​ការ​ចូល​រួម​ពី​អ្នក​គ្រប់​គ្រង​ប្រព័ន្ធ ដែល​តែង​តែ​មាន​អ្វី​ដែល​ត្រូវ​ធ្វើ។
ហើយដើម្បីបង្កើនល្បឿនទាំងអស់នេះ យើងធ្វើឱ្យស្គ្រីបដាក់ពង្រាយដោយស្វ័យប្រវត្តិតាមដែលអាចធ្វើទៅបាននៅលើ AWS CloudFormation ដែលអនុញ្ញាតឱ្យអ្នកដាក់ពង្រាយដោយប្រើប៊ូតុងមួយដោយផ្ទាល់ពី VS ។ ជាលទ្ធផល ឯកសារនៃ 200 បន្ទាត់នៃកូដអនុញ្ញាតឱ្យអ្នកដាក់ចេញនូវដំណោះស្រាយដែលត្រៀមរួចជាស្រេច ទោះបីជាវាក្យសម្ព័ន្ធ CloudFormation អាចធ្វើឱ្យភ្ញាក់ផ្អើលប្រសិនបើអ្នកមិនទម្លាប់ប្រើវាក៏ដោយ។

សរុប

Serverless មិនមែនជា panacea ទេ។ ប៉ុន្តែ​វា​នឹង​ធ្វើឱ្យ​ជីវិត​កាន់តែ​ងាយស្រួល​ក្នុង​ស្ថានភាព​ដែល​មាន​ដែនកំណត់​ចំនួន​បី៖ "ធនធាន​មានកំណត់ - រយៈពេលខ្លី - ប្រាក់តិចតួច" ។

លក្ខណៈនៃកម្មវិធីដែលសាកសមសម្រាប់ Serverless

• ដោយគ្មានដំណើរការដំណើរការយូរ។ API Gateway hard limit គឺ 29 វិនាទី, lambda hard limit គឺ 5 នាទី;
• ពិពណ៌នាដោយស្ថាបត្យកម្ម Event-Driven;
• បំបែកទៅជាសមាសធាតុផ្សំរលុងដូចជា SOA;
• មិនតម្រូវឱ្យមានការងារច្រើនជាមួយនឹងលក្ខខណ្ឌរបស់អ្នក;
• សរសេរក្នុង .NET Core ។ ដើម្បីធ្វើការជាមួយ .NET Framework អ្នកនឹងនៅតែត្រូវការ Docker យ៉ាងហោចណាស់ជាមួយនឹងពេលវេលាដំណើរការសមរម្យ។

អត្ថប្រយោជន៍នៃវិធីសាស្រ្ត Serverless

• កាត់បន្ថយការចំណាយលើហេដ្ឋារចនាសម្ព័ន្ធ;
• កាត់បន្ថយថ្លៃដើមនៃដំណោះស្រាយ;
• ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ;
• ការអភិវឌ្ឍនៅគែមចុងក្រោយនៃវឌ្ឍនភាពបច្ចេកវិទ្យា។

គុណវិបត្តិ, ជាមួយនឹងឧទាហរណ៍ជាក់លាក់មួយ។

• ការតាមដាន និងការកត់ត្រាដែលបានចែកចាយ - ត្រូវបានដោះស្រាយដោយផ្នែកតាមរយៈ AWS X-Ray និង AWS CloudWatch;
• ការកែកំហុសមិនស្រួល;
• ចាប់ផ្តើមត្រជាក់នៅពេលដែលមិនមានបន្ទុក;
• ចំណុចប្រទាក់អ្នកប្រើ-អរិភាព AWS គឺជាបញ្ហាសកល :)

ប្រភព: www.habr.com