Jag arbetar med outsourcing, där huvudprincipen kan beskrivas med frasen "sälj mycket, gör det snabbt." Ju snabbare vi gör det, desto mer tjänar vi. Och det är önskvärt att allt fungerar inte på kryckor och snopp, utan med en acceptabel kvalitetsnivå. Jag kommer att berätta om min erfarenhet när det var nödvändigt att utveckla en PR-tjänst på kort tid.
Given: root-konto på AWS, inga begränsningar för valet av teknikstack, en backend och en månad för utveckling.
Uppgift: implementera en reklamtjänst där användare laddar upp från en till fyra videor som varar från en till fyra sekunder, som sedan bäddas in i den ursprungliga videoserien.
beslutet
Att skriva sin egen cykeltjänst på så kort tid är ingen bra idé. Dessutom kommer det att krävas infrastruktur för att tjänsten ska klara belastningen och för att alla ska få den eftertraktade videon. Och helst inte med prislappen från planet. Därför fokuserar vi direkt på färdiga lösningar med minimal anpassning.
Standardlösningen för att arbeta med video är FFmpeg, ett plattformsoberoende konsolverktyg som, genom argument, låter dig klippa och överdubba ljud. Allt som återstår att göra är att skriva ett omslag och släppa ut det i livet. Vi skriver en prototyp som syr ihop två videor, och... det roliga börjar. Biblioteket är baserat på .NET Core 2, det bör köras på vilken virtuell maskin som helst, så vi tar en AWS EC2-instans och allt kommer att fungera
Dold textnej, det kommer inte att fungera
.
Även om FFmpeg förenklar uppgiften, för en riktigt fungerande lösning måste du skapa en EC2-instans och designa en nätverksinfrastruktur för den, inklusive en lastbalanserare. Den enkla uppgiften att distribuera från grunden blir "lite" mer komplicerad, och infrastrukturen börjar kräva pengar omedelbart - varje timme dras beloppet för runtime från kundkontot.
Vår tjänst involverar inte långvariga processer, kräver ingen stor och fet relationsdatabas och passar perfekt in i en händelsebaserad arkitektur med en kedja av mikrotjänstanrop. Lösningen föreslår sig själv - vi kan överge EC2 och implementera en äkta serverlös applikation, som standard Image Resizer baserad på AWS Lambda.
Förresten, trots den uppenbara motviljan mot AWS-utvecklare för .NET, så stöder de .NET Core 2.1 som runtime, vilket ger ett komplett utbud av utvecklingsmöjligheter.
Och körsbäret på kakan - AWS tillhandahåller en separat tjänst för att arbeta med videofiler - AWS Elemental MediaConvert.
Kärnan i arbetet är otroligt enkelt: vi tar en S3-länk till den utgående videon, skriver via AWS Console, .NET SDK eller helt enkelt JSON vad vi vill göra med videon och kallar tjänsten. Den implementerar själv köer för att behandla inkommande förfrågningar, laddar upp resultatet till S3 själv och, viktigast av allt, genererar en CloudWatch Event för varje statusändring. Detta gör att vi kan implementera lambda-utlösare för att slutföra videobearbetning.
Så här ser den slutliga arkitekturen ut:
Hela backend är inrymt i två lambdas. En annan är för att rotera vertikala videor, eftersom sådant arbete inte kan utföras i ett pass.
Vi kommer att placera fronten i form av en SPA-ansökan skriven i JS och sammanställd via mops i en offentlig S3-hink. För att ladda ner själva videorna behöver vi ingen serverkod - vi behöver bara öppna REST-slutpunkterna som S3 ger oss. Det enda är glöm inte att konfigurera policyer och CORS.
Fallgropar
- AWS MediaConvert, av någon okänd anledning, applicerar bara ljud till varje videofragment separat, men vi behöver en glad låt från hela skärmsläckaren.
- Vertikala videor måste bearbetas separat. AWS gillar inte svarta stänger och sätter rullarna i 90°.
Lätt skridskobana
Trots all skönhet med Stateless måste du hålla reda på vad som behöver göras med videon: limma eller lägg till ljud till den färdiga videosekvensen. Lyckligtvis stöder MediaConvert att skicka metadata genom sina jobb, och vi kan alltid använda en enkel flagga i formen "isMasterSoundJob", som analyserar denna metadata när som helst.
Serverless tillåter perfekt arbete med NoOps - ett tillvägagångssätt som förutsätter onödigheten av ett separat team som ansvarar för projektinfrastrukturen. Därför var det en liten sak – vi distribuerar lösningen på AWS utan deltagande av systemadministratörer, som alltid har något att göra ändå.
Och för att påskynda allt detta automatiserar vi distributionsskriptet så mycket som möjligt på AWS CloudFormation, vilket låter dig distribuera med en knapp direkt från VS. Som ett resultat låter en fil på 200 rader kod dig rulla ut en färdig lösning, även om CloudFormations syntax kan vara chockerande om du inte är van vid det.
Totalt
Serverlöst är inget universalmedel. Men det kommer att göra livet mycket lättare i situationer med tre gränser: "begränsade resurser - kortsiktigt - lite pengar."
Egenskaper för applikationer Lämpliga för serverlösa
- utan långvariga processer. API Gateway hård gräns är 29 sekunder, lambda hård gräns är 5 minuter;
- beskrivs av händelsedriven arkitektur;
- bryts ner i löst kopplade komponenter som SOA;
- kräver inte mycket arbete med ditt tillstånd;
- skrivet i .NET Core. För att arbeta med .NET Framework behöver du fortfarande åtminstone Docker med lämplig körtid.
Fördelarna med det serverlösa tillvägagångssättet
- minskar infrastrukturkostnaderna;
- minskar kostnaden för att leverera lösningen;
- automatisk skalbarhet;
- utveckling i framkant av tekniska framsteg.
Nackdelar, med ett specifikt exempel
- Distribuerad spårning och loggning - delvis löst genom AWS X-Ray och AWS CloudWatch;
- obekväm felsökning;
- Kallstart när det inte finns någon belastning;
- AWS användarfientligt gränssnitt är ett universellt problem :)
Källa: will.com