Ek werk in uitkontraktering, waar die hoofbeginsel beskryf kan word deur die frase "verkoop baie, doen dit vinnig." Hoe vinniger ons dit doen, hoe meer sal ons verdien. En, dit is wenslik dat alles nie op krukke en snot werk nie, maar met 'n aanvaarbare vlak van kwaliteit. Ek sal jou vertel van my ervaring toe dit nodig was om 'n promosiediens in 'n kort tydperk te ontwikkel.
Gegee: wortelrekening op AWS, geen beperkings op die keuse van tegnologiestapel nie, een backend en een maand vir ontwikkeling.
'N Taak: implementeer 'n promosiediens waar gebruikers van een tot vier video's oplaai wat van een tot vier sekondes duur, wat dan in die oorspronklike videoreeks ingebed word.
besluit
Om jou eie fietsdiens in so 'n kort tydjie te skryf is nie 'n goeie idee nie. Boonop sal infrastruktuur benodig word om die diens die las te kan hanteer en vir almal om die gesogte video te ontvang. En verkieslik nie met die prysetiket van die vliegtuig af nie. Daarom fokus ons dadelik op klaargemaakte oplossings met minimale aanpassing.
Die standaardoplossing om met video te werk, is FFmpeg, 'n kruisplatform-konsole-hulpmiddel wat jou deur argumente toelaat om oudio te sny en te oordubbel. Al wat oorbly om te doen is om 'n omslag te skryf en dit in die lewe vry te laat. Ons skryf 'n prototipe wat twee video's saamvoeg, en ... die pret begin. Die biblioteek is gebaseer op .NET Core 2, dit behoort op enige virtuele masjien te loop, so ons neem 'n AWS EC2-instansie en alles sal werk
Versteekte teksnee, dit sal nie werk nie
.
Alhoewel FFmpeg die taak vereenvoudig, moet jy vir 'n werklik werkende oplossing 'n EC2-instansie skep en 'n netwerkinfrastruktuur daarvoor ontwerp, insluitend 'n Load Balancer. Die eenvoudige taak om van nuuts af te ontplooi word "'n bietjie" meer ingewikkeld, en die infrastruktuur begin dadelik geld eis - elke uur word die bedrag vir looptyd uit die kliëntrekening onttrek.
Ons diens behels nie langdurige prosesse nie, vereis nie 'n groot en vet verhoudingsdatabasis nie, en pas perfek in 'n gebeurtenis-gebaseerde argitektuur met 'n ketting van mikrodiensoproepe. Die oplossing stel homself voor - ons kan EC2 laat vaar en 'n ware-bedienerlose toepassing implementeer, soos die standaard Image Resizer gebaseer op AWS Lambda.
Terloops, ten spyte van die duidelike afkeer van AWS-ontwikkelaars vir .NET, ondersteun hulle .NET Core 2.1 as runtime, wat 'n volledige reeks ontwikkelingsgeleenthede bied.
En die kersie op die koek - AWS bied 'n aparte diens om met videolêers te werk - AWS Elemental MediaConvert.
Die kern van die werk is ongelooflik eenvoudig: ons neem 'n S3-skakel na die uitgaande video, skryf deur AWS Console, .NET SDK of bloot JSON wat ons met die video wil doen en noem die diens. Dit implementeer self toue vir die verwerking van inkomende versoeke, laai die resultaat self na S3 op en, bowenal, genereer 'n CloudWatch-gebeurtenis vir elke statusverandering. Dit stel ons in staat om lambda-snellers te implementeer om videoverwerking te voltooi.
Dit is hoe die finale argitektuur lyk:
Die hele agterkant word in twee lambda's gehuisves. Nog een is vir roterende vertikale video's, aangesien sulke werk nie in een pas gedoen kan word nie.
Ons sal die voorkant plaas in die vorm van 'n SPA aansoek geskryf in JS en saamgestel via pug in 'n publieke S3 emmer. Om die video's self af te laai, het ons geen bedienerkode nodig nie - ons moet net die REST-eindpunte oopmaak wat S3 ons verskaf. Die enigste ding is, moenie vergeet om beleide en CORS op te stel nie.
Slaggate
- AWS MediaConvert pas om een of ander onbekende rede slegs klank op elke videofragment afsonderlik toe, maar ons benodig 'n vrolike liedjie van die hele skermbewaarder.
- Vertikale video's moet afsonderlik verwerk word. AWS hou nie van swart stawe nie en sit die rollers op 90°.
Maklike skaatsbaan
Ten spyte van al die skoonheid van Stateless, moet jy tred hou met wat met die video gedoen moet word: gom of voeg oudio by die voltooide videoreeks. Gelukkig ondersteun MediaConvert om metadata deur sy Jobs te stuur, en ons kan altyd 'n eenvoudige vlag van die vorm "isMasterSoundJob" gebruik om hierdie metadata op enige stadium te ontleed.
Bedienerloos laat dit perfek toe om met NoOps te werk - 'n benadering wat die onnodigheid aanvaar van 'n aparte span wat verantwoordelik is vir die projekinfrastruktuur. Daarom was dit 'n klein kwessie - ons ontplooi die oplossing op AWS sonder die deelname van stelseladministrateurs, wat in elk geval altyd iets het om te doen.
En om dit alles te bespoedig, outomatiseer ons die ontplooiingskrip soveel as moontlik op AWS CloudFormation, wat jou toelaat om met een knoppie direk vanaf VS te ontplooi. Gevolglik laat 'n lêer van 200 reëls kode jou toe om 'n klaargemaakte oplossing uit te voer, hoewel die CloudFormation-sintaksis skokkend kan wees as jy nie daaraan gewoond is nie.
In totaal
Bedienerloos is nie 'n wondermiddel nie. Maar dit sal die lewe baie makliker maak in situasies met drie perke: "beperkte hulpbronne - korttermyn - min geld."
Eienskappe van toepassings wat geskik is vir bedienerloos
- sonder langdurige prosesse. API Gateway harde limiet is 29 sekondes, lambda harde limiet is 5 minute;
- beskryf deur Gebeurtenisgedrewe argitektuur;
- breek af in losgekoppelde komponente soos SOA;
- vereis nie veel werk met jou toestand nie;
- geskryf in .NET Core. Om met die .NET Framework te werk, sal jy steeds ten minste Docker met die toepaslike looptyd nodig hê.
Voordele van die bedienerlose benadering
- verminder infrastruktuurkoste;
- verminder die koste om die oplossing te lewer;
- outomatiese skaalbaarheid;
- ontwikkeling op die voorpunt van tegnologiese vooruitgang.
Nadele, met 'n spesifieke voorbeeld
- Verspreide opsporing en logging - gedeeltelik opgelos deur AWS X-Ray en AWS CloudWatch;
- ongerieflike ontfouting;
- Koue begin wanneer daar geen vrag is nie;
- AWS-gebruiker-vyandige koppelvlak is 'n universele probleem :)
Bron: will.com