Dirbu užsakomųjų paslaugų srityje, kur pagrindinį principą galima apibūdinti fraze „parduok daug, daryk greitai“. Kuo greičiau tai padarysime, tuo daugiau uždirbsime. Ir, pageidautina, kad viskas veiktų ne ant ramentų ir snarglių, o su priimtinu kokybės lygiu. Papasakosiu apie savo patirtį, kai reikėjo per trumpą laiką sukurti reklaminę paslaugą.
Dano: šakninė paskyra AWS, jokių apribojimų pasirenkant technologinį krūvą, vienas backend ir vienas mėnuo kūrimui.
Užduotis: įdiegti reklaminę paslaugą, kai vartotojai įkelia nuo vieno iki keturių vaizdo įrašų, trunkančių nuo vienos iki keturių sekundžių, kurie vėliau įterpiami į originalią vaizdo įrašų seriją.
sprendimas
Per tokį trumpą laiką sukurti savo dviračių paslaugą nėra gera idėja. Be to, kad paslauga atlaikytų krūvį ir visi gautų trokštamą vaizdo įrašą, reikės infrastruktūros. Ir pageidautina ne su kainų etikete iš lėktuvo. Todėl iš karto orientuojamės į paruoštus sprendimus su minimaliu pritaikymu.
Standartinis sprendimas darbui su vaizdo įrašu yra FFmpeg, kelių platformų konsolės įrankis, kuris, remiantis argumentais, leidžia iškirpti ir perrašyti garsą. Belieka parašyti pakuotę ir išleisti ją į gyvenimą. Rašome prototipą, kuris sujungia du vaizdo įrašus, ir... linksmybės prasideda. Biblioteka yra pagrįsta .NET Core 2, ji turėtų veikti bet kurioje virtualioje mašinoje, todėl paimame AWS EC2 egzempliorių ir viskas veiks
Paslėptas tekstasne, tai neveiks
.
Nors FFmpeg supaprastina užduotį, norint tikrai veikiančio sprendimo, reikia sukurti EC2 egzempliorių ir sukurti jam tinklo infrastruktūrą, įskaitant apkrovos balansavimo priemonę. Paprasta diegimo nuo nulio užduotis tampa „šiek tiek sudėtingesnė“, o infrastruktūra iškart pradeda reikalauti pinigų - kas valandą iš kliento sąskaitos nuimama suma už vykdymo laiką.
Mūsų paslauga neapima ilgalaikių procesų, nereikalauja didelės ir storos reliacinės duomenų bazės ir puikiai tinka įvykiais pagrįstai architektūrai su mikro paslaugų skambučių grandine. Sprendimas siūlo pats save – galime atsisakyti EC2 ir įdiegti be serverio veikiančią programą, pavyzdžiui, standartinį „Image Resizer“, pagrįstą AWS Lambda.
Beje, nepaisant akivaizdaus AWS kūrėjų nemėgimo .NET, jie palaiko .NET Core 2.1 kaip vykdymo laiką, o tai suteikia visas kūrimo galimybes.
Ir vyšnia ant torto – AWS teikia atskirą paslaugą darbui su vaizdo failais – AWS Elemental MediaConvert.
Darbo esmė neįtikėtinai paprasta: paimame S3 nuorodą į išeinantį vaizdo įrašą, per AWS Console, .NET SDK arba tiesiog JSON parašome, ką norime daryti su vaizdo įrašu ir iškviečiame paslaugą. Ji pati įdiegia eiles įeinančių užklausų apdorojimui, pati įkelia rezultatą į S3 ir, svarbiausia, sugeneruoja CloudWatch įvykį kiekvienam būsenos pakeitimui. Tai leidžia mums įdiegti lambda paleidiklius, kad užbaigtume vaizdo apdorojimą.
Štai kaip atrodo galutinė architektūra:
Visa užpakalinė dalis yra dviejose lambdose. Kitas skirtas vertikaliems vaizdo įrašams pasukti, nes tokio darbo negalima atlikti vienu praėjimu.
Priekinę dalį įdėsime į viešą S3 kibirą SPA paraiškos forma, parašyta JS kalba ir sudaryta per mopsą. Norint atsisiųsti pačius vaizdo įrašus, mums nereikia jokio serverio kodo – tereikia atidaryti REST galinius taškus, kuriuos mums suteikia S3. Vienintelis dalykas – nepamirškite sukonfigūruoti politikos ir CORS.
Spąstų
- AWS MediaConvert dėl nežinomos priežasties kiekvienam vaizdo įrašo fragmentui pritaiko tik garsą atskirai, tačiau mums reikia linksmos dainos iš visos ekrano užsklandos.
- Vertikalius vaizdo įrašus reikia apdoroti atskirai. AWS nemėgsta juodų juostų ir stato volelius 90° kampu.
Lengva čiuožykla
Nepaisant viso „Stateless“ grožio, turite sekti, ką reikia padaryti su vaizdo įrašu: klijuoti arba pridėti garso įrašą prie baigtos vaizdo įrašo sekos. Laimei, „MediaConvert“ palaiko metaduomenų perdavimą per savo darbus, ir mes visada galime naudoti paprastą „isMasterSoundJob“ formos vėliavėlę, analizuodami šiuos metaduomenis bet kuriame etape.
Be serverio puikiai leidžia dirbti su „NoOps“ – tai metodas, kuris prisiima atskiros komandos, atsakingos už projekto infrastruktūrą, nereikalingumą. Todėl tai buvo smulkmena – sprendimą AWS diegiame nedalyvaudami sistemos administratoriams, kurie ir taip visada turi ką veikti.
Ir norėdami visa tai paspartinti, mes kiek įmanoma automatizuojame diegimo scenarijų AWS CloudFormation, kuris leidžia įdiegti vienu mygtuku tiesiai iš VS. Dėl to 200 kodo eilučių failas leidžia įdiegti paruoštą sprendimą, nors CloudFormation sintaksė gali šokiruoti, jei nesate prie jos pripratę.
Iš viso
Be serverio nėra panacėja. Tačiau tai labai palengvins gyvenimą situacijose su trimis apribojimais: „riboti ištekliai – trumpalaikis – mažai pinigų“.
Programų, tinkamų be serverių, charakteristikos
- be ilgalaikių procesų. API šliuzo griežta riba yra 29 sekundės, lambda griežta riba yra 5 minutės;
- aprašyta Event-Driven architektūra;
- skyla į laisvai sujungtus komponentus, tokius kaip SOA;
- nereikalauja daug dirbti su jūsų būkle;
- parašyta .NET Core. Norint dirbti su .NET Framework, vis tiek reikės bent jau Docker su atitinkama vykdymo vieta.
Be serverio metodo pranašumai
- sumažina infrastruktūros išlaidas;
- sumažina sprendimo pristatymo išlaidas;
- automatinis mastelio keitimas;
- plėtra technologinės pažangos pažangoje.
Trūkumai, su konkrečiu pavyzdžiu
- Paskirstytas sekimas ir registravimas – iš dalies išspręsta naudojant AWS X-Ray ir AWS CloudWatch;
- nepatogus derinimas;
- Šaltas paleidimas, kai nėra apkrovos;
- AWS vartotojo priešiška sąsaja yra universali problema :)
Šaltinis: www.habr.com