Bezserveru pieeja ātrai strādājoša video pakalpojuma attīstībai

Bezserveru pieeja ātrai strādājoša video pakalpojuma attīstībai

Strādāju ārpakalpojumos, kur galveno principu var raksturot ar frāzi “pārdod daudz, dari ātri”. Jo ātrāk mēs to izdarīsim, jo ​​vairāk nopelnīsim. Un, vēlams, lai viss darbotos nevis uz kruķiem un puņķiem, bet gan ar pieņemamu kvalitātes līmeni. Pastāstīšu par savu pieredzi, kad bija nepieciešams īsā laika periodā izstrādāt akcijas servisu.

Ņemot vērā: saknes konts AWS, bez ierobežojumiem tehnoloģiju steka izvēlei, viena aizmugursistēma un viens mēnesis izstrādei.

Uzdevums: ieviest reklāmas pakalpojumu, kurā lietotāji augšupielādē no viena līdz četriem videoklipiem, kuru ilgums ir no vienas līdz četrām sekundēm, kas pēc tam tiek iegulti oriģinālajā video sērijā.

Šķīdums

Uzrakstīt savu velosipēdu servisu tik īsā laikā nav laba ideja. Turklāt, lai dienests tiktu galā ar slodzi un ikviens saņemtu kāroto video, būs nepieciešama infrastruktūra. Un vēlams ne ar cenu zīmi no lidmašīnas. Tāpēc mēs nekavējoties koncentrējamies uz gataviem risinājumiem ar minimālu pielāgošanu.

Standarta risinājums darbam ar video ir FFmpeg, starpplatformu konsoles utilīta, kas, izmantojot argumentus, ļauj izgriezt un pārdublēt audio. Atliek tikai uzrakstīt iesaiņojumu un atbrīvot to dzīvē. Mēs uzrakstām prototipu, kas savieno divus videoklipus, un... jautrība sākas. Bibliotēkas pamatā ir .NET Core 2, tai vajadzētu darboties jebkurā virtuālajā mašīnā, tāpēc mēs ņemam AWS EC2 gadījumu un viss darbosies.

Slēpts tekstsnē, tas nedarbosies
.
Lai gan FFmpeg vienkāršo uzdevumu, patiesi strādājošam risinājumam ir jāizveido EC2 instance un jāizveido tam tīkla infrastruktūra, tostarp Load Balancer. Vienkāršais izvietošanas uzdevums no nulles kļūst “nedaudz” sarežģītāks, un infrastruktūra nekavējoties sāk pieprasīt naudu - katru stundu no klienta konta tiek izņemta summa par izpildes laiku.

Mūsu pakalpojums neietver ilgstošus procesus, tam nav nepieciešama liela un apjomīga relāciju datu bāze, un tas lieliski iekļaujas uz notikumiem balstītā arhitektūrā ar mikropakalpojumu zvanu ķēdi. Risinājums liecina par sevi — mēs varam atteikties no EC2 un ieviest īstu bezservera lietojumprogrammu, piemēram, standarta Image Resizer, kura pamatā ir AWS Lambda.

Starp citu, neskatoties uz acīmredzamo AWS izstrādātāju nepatiku pret .NET, viņi atbalsta .NET Core 2.1 kā izpildlaiku, kas nodrošina pilnu attīstības iespēju klāstu.

Un ķirsis uz kūkas - AWS nodrošina atsevišķu pakalpojumu darbam ar video failiem - AWS Elemental MediaConvert.

Darba būtība ir neticami vienkārša: mēs paņemam S3 saiti uz izejošo video, ierakstām caur AWS konsoli, .NET SDK vai vienkārši JSON, ko vēlamies darīt ar video, un izsaucam pakalpojumu. Tas pats ievieš rindas ienākošo pieprasījumu apstrādei, augšupielādē rezultātu pašā S3 un, pats galvenais, ģenerē CloudWatch notikumu katrai statusa maiņai. Tas ļauj mums ieviest lambda trigerus, lai pabeigtu video apstrādi.

Bezserveru pieeja ātrai strādājoša video pakalpojuma attīstībai
Lūk, kā izskatās galīgā arhitektūra:

Visa aizmugure ir izvietota divās lambdas. Vēl viens ir paredzēts vertikālu video pagriešanai, jo šādu darbu nevar paveikt vienā piegājienā.

Priekšpusi ievietosim JS valodā rakstītas un ar mopša starpniecību sastādītas SPA pieteikuma formā publiskā S3 spainī. Lai lejupielādētu pašus videoklipus, mums nav nepieciešams nekāds servera kods — mums vienkārši jāatver REST galapunkti, ko mums nodrošina S3. Vienīgais, neaizmirstiet konfigurēt politikas un CORS.

Slazdiem

  • AWS MediaConvert nezināmu iemeslu dēļ skaņu piemēro tikai katram video fragmentam atsevišķi, taču mums ir nepieciešama jautra dziesma no visa ekrānsaudzētāja.
  • Vertikālie videoklipi ir jāapstrādā atsevišķi. AWS nepatīk melnas joslas un noliek rullīšus 90° leņķī.

Viegla slidotava

Neskatoties uz visu bezvalstnieku skaistumu, jums ir jāseko līdzi tam, kas jādara ar videoklipu: pielīmējiet vai pievienojiet audio gatavajai video secībai. Par laimi, MediaConvert atbalsta metadatu nodošanu, izmantojot savus darbus, un mēs vienmēr varam izmantot vienkāršu karogu formā “isMasterSoundJob”, analizējot šos metadatus jebkurā posmā.

Bez servera lieliski ļauj strādāt ar NoOps – pieeju, kas paredz atsevišķas komandas, kas atbildīga par projekta infrastruktūru, nevajadzīgumu. Tāpēc tas bija mazs jautājums - mēs izvietojām risinājumu AWS bez sistēmas administratoru līdzdalības, kuriem vienmēr ir ko darīt.
Un, lai to visu paātrinātu, mēs pēc iespējas vairāk automatizējam izvietošanas skriptu AWS CloudFormation, kas ļauj izvietot ar vienu pogu tieši no VS. Rezultātā fails ar 200 koda rindiņām ļauj izvērst gatavu risinājumu, lai gan CloudFormation sintakse var būt šokējoša, ja neesat pie tā pieradis.

Kopā

Bez servera nav panaceja. Bet tas padarīs dzīvi daudz vieglāku situācijās ar trim ierobežojumiem: "ierobežoti resursi — īstermiņa — maz naudas."

Bezserveriem piemēroto lietojumprogrammu raksturojums

  • bez ilgstošiem procesiem. API vārtejas cietais ierobežojums ir 29 sekundes, lambda cietais ierobežojums ir 5 minūtes;
  • apraksta Event-Driven arhitektūra;
  • sadalās brīvi savienotos komponentos, piemēram, SOA;
  • neprasa daudz darba ar jūsu stāvokli;
  • rakstīts .NET Core. Lai strādātu ar .NET Framework, jums joprojām būs nepieciešams vismaz Docker ar atbilstošu izpildlaiku.

Bez servera pieejas priekšrocības

  • samazina infrastruktūras izmaksas;
  • samazina risinājuma piegādes izmaksas;
  • automātiska mērogojamība;
  • attīstība tehnoloģiskā progresa līderiem.

Trūkumi, ar konkrētu piemēru

  • Izplatīta izsekošana un reģistrēšana — daļēji atrisināta, izmantojot AWS X-Ray un AWS CloudWatch;
  • neērta atkļūdošana;
  • Aukstā iedarbināšana, kad nav slodzes;
  • AWS lietotājam naidīgs interfeiss ir universāla problēma :)

Avots: www.habr.com

Pievieno komentāru