Jeg arbejder med outsourcing, hvor hovedprincippet kan beskrives med sætningen "sælg meget, gør det hurtigt." Jo hurtigere vi gør det, jo mere vil vi tjene. Og det er ønskeligt, at alt fungerer ikke på krykker og snot, men med et acceptabelt kvalitetsniveau. Jeg vil fortælle dig om min oplevelse, da det var nødvendigt at udvikle en salgsfremmende tjeneste på kort tid.
Givet: root-konto på AWS, ingen begrænsninger for valg af teknologistack, en backend og en måned til udvikling.
Formål: implementere en salgsfremmende tjeneste, hvor brugere uploader fra en til fire videoer, der varer fra et til fire sekunder, og som derefter indlejres i den originale videoserie.
beslutning
At skrive sin egen cykelservice på så kort tid er ikke en god idé. For at tjenesten kan klare belastningen og for at alle kan modtage den eftertragtede video, vil der desuden være behov for infrastruktur. Og helst ikke med prisskiltet fra flyet. Derfor fokuserer vi straks på færdige løsninger med minimal tilpasning.
Standardløsningen til at arbejde med video er FFmpeg, et konsolværktøj på tværs af platforme, der gennem argumenter giver dig mulighed for at klippe og overdub lyd. Det eneste, der er tilbage at gøre, er at skrive en indpakning og slippe den ud i livet. Vi skriver en prototype, der syr to videoer sammen, og... det sjove begynder. Biblioteket er baseret på .NET Core 2, det burde køre på enhver virtuel maskine, så vi tager en AWS EC2-instans, og alt vil fungere
Skjult tekstnej, det vil ikke virke
.
Selvom FFmpeg forenkler opgaven, skal du for en virkelig fungerende løsning oprette en EC2-instans og designe en netværksinfrastruktur til den, inklusive en Load Balancer. Den simple opgave at implementere fra bunden bliver "lidt" mere kompliceret, og infrastrukturen begynder at kræve penge med det samme - hver time hæves beløbet for runtime fra klientkontoen.
Vores service involverer ikke langvarige processer, kræver ikke en stor og fed relationel database og passer perfekt ind i en begivenhedsbaseret arkitektur med en kæde af mikroservicekald. Løsningen foreslår sig selv - vi kan opgive EC2 og implementere en ægte serverløs applikation, som standard Image Resizer baseret på AWS Lambda.
På trods af den åbenlyse modvilje mod AWS-udviklere til .NET, understøtter de i øvrigt .NET Core 2.1 som runtime, hvilket giver en hel række af udviklingsmuligheder.
Og kirsebæret på kagen - AWS leverer en separat service til at arbejde med videofiler - AWS Elemental MediaConvert.
Essensen af arbejdet er utrolig simpelt: Vi tager et S3-link til den udgående video, skriver gennem AWS Console, .NET SDK eller blot JSON, hvad vi vil med videoen og kalder tjenesten. Den implementerer selv køer til behandling af indgående anmodninger, uploader resultatet til S3 selv og, vigtigst af alt, genererer den en CloudWatch Event for hver statusændring. Dette giver os mulighed for at implementere lambda-triggere for at fuldføre videobehandling.
Sådan ser den endelige arkitektur ud:
Hele backend er anbragt i to lambdaer. En anden er til at rotere lodrette videoer, da sådant arbejde ikke kan udføres i én omgang.
Vi vil placere fronten i form af en SPA-ansøgning skrevet i JS og kompileret via pug i en offentlig S3-spand. For at downloade selve videoerne behøver vi ikke nogen serverkode - vi skal bare åbne REST-endepunkterne, som S3 giver os. Det eneste er, glem ikke at konfigurere politikker og CORS.
Faldgruber
- AWS MediaConvert anvender af en eller anden ukendt årsag kun lyd til hvert videofragment separat, men vi har brug for en munter sang fra hele pauseskærmen.
- Lodrette videoer skal behandles separat. AWS bryder sig ikke om sorte bjælker og sætter rullerne i 90°.
Nem skøjtebane
På trods af alt det smukke ved Stateless skal du holde styr på, hvad der skal gøres med videoen: lim eller tilføj lyd til den færdige videosekvens. Heldigvis understøtter MediaConvert at sende metadata gennem sine job, og vi kan altid bruge et simpelt flag i formen "isMasterSoundJob", der analyserer disse metadata på ethvert tidspunkt.
Serverløs tillader perfekt arbejde med NoOps - en tilgang, der forudsætter unødvendigheden af et separat team, der er ansvarligt for projektinfrastrukturen. Derfor var det en lille sag – vi implementerer løsningen på AWS uden deltagelse af systemadministratorer, som altid har noget at lave alligevel.
Og for at fremskynde alt dette, automatiserer vi implementeringsscriptet så meget som muligt på AWS CloudFormation, som giver dig mulighed for at implementere med én knap direkte fra VS. Som et resultat giver en fil på 200 linjer kode dig mulighed for at udrulle en færdig løsning, selvom CloudFormation-syntaksen kan være chokerende, hvis du ikke er vant til det.
I alt
Serverløs er ikke et vidundermiddel. Men det vil gøre livet meget lettere i situationer med tre grænser: "begrænsede ressourcer - på kort sigt - små penge."
Egenskaber ved applikationer velegnet til serverløse
- uden langvarige processer. API Gateway hård grænse er 29 sekunder, lambda hård grænse er 5 minutter;
- beskrevet af Event-Driven architecture;
- bryder ned i løst koblede komponenter som SOA;
- kræver ikke meget arbejde med din tilstand;
- skrevet i .NET Core. For at arbejde med .NET Framework har du stadig brug for mindst Docker med den passende runtime.
Fordele ved den serverløse tilgang
- reducerer infrastrukturomkostninger;
- reducerer omkostningerne ved at levere løsningen;
- automatisk skalerbarhed;
- udvikling på forkant med teknologiske fremskridt.
Ulemper, med et specifikt eksempel
- Distribueret sporing og logning - delvist løst gennem AWS X-Ray og AWS CloudWatch;
- ubelejlig debugging;
- Koldstart, når der ikke er nogen belastning;
- AWS brugerfjendtlig grænseflade er et universelt problem :)
Kilde: www.habr.com