Unë punoj në outsourcing, ku principi kryesor përshkruhet me frazën "shes shumë, bëj shpejt". Sa më shpejt të bëjmë, aq më shumë do të fitojmë. Gjithashtu, është e dëshirueshme që gjithçka të funksionojë pa probleme dhe në një nivel të pranueshëm cilësie. Do të flas për përvojën time kur për një kohë të shkurtër duhej të zhvillohej një shërbim promocional.
E dhënë: ruajtës-llogari në AWS, pa kufizime për zgjedhjen e teknologjive, një backend dhe një muaj për zhvillim.
Detyra: të realizojë një shërbim promocional ku përdoruesit ngarkojnë nga një deri në katër video me nga një deri në katër sekonda, që më pas integrohen në skenarin origjinal të videos.
Zgjidhja
Të shkruash shërbimin tënd në një afat të tillë është një ide mjaft e vështirë. Përveç kësaj, për të siguruar që shërbimi të përballojë ngarkesat dhe që të gjithë të jenë në gjendje të marrin videon e dëshiruara, do të nevojitet infrastruktura. Dhe do të ishte mirë që çmimi të mos ishte nga ai i avionëve. Prandaj, ne orientoheni menjëherë drejt zgjidhjeve gati me minimalizimin e personalizimit.
Zgjidhja standarde për punën me video është FFmpeg, një utilitar konsolë multi-platformë që duhet të lejojë prerje dhe mbivendosje zvokesh nëpërmjet argumenteve. Tani mbetet vetëm të shkruajmë një mbështjellës dhe ta hedhim atë në përdorim. Ne shkruajmë një prototip që bashkon dy video dhe... fillon pjesa interesante. Biblioteka në .NET Core 2 duhet të funksionojë në çdo makinë virtuale, prandaj marrim një instancë AWS EC2 dhe gjithçka do të funksionojë.
Teksti i fshehurjo, nuk do të funksionojë
.
FFmpeg, ndonëse lehtëson detyrën, për një zgjidhje funksionale kërkon krijimin e një instancë EC2, duke projektuar infrastrukturën rrjetore përfshirë Load Balancer. Një detyrë e thjeshtë për deploy me zero nga fillimi bëhet "pak" më e komplikuar, dhe infrastruktura fillon të kërkojë para menjëherë - çdo orë një shumë hiqet nga llogaria e klientit për runtime-in.
Shërbimi ynë nuk parashikon procese Long-Running, nuk kërkon një bazë të madhe rrelacionale dhe përkryer përshtatet në një arkitekturë ngjarjesh me një zinxhir thirrjesh mikroshërbimesh. Zgjidhja duket e qartë - ne mund të heqim dorë nga EC2 dhe të realizojmë një aplikacion true-serverless, si ato standarde për Image Resizer në AWS Lambda.
Për më tepër, përkundër dashurisë së dukshme të zhvilluesve të AWS për .NET, ata mbështesin .NET Core 2.1 si runtime, çka ofron një gamë të plotë mundësish për zhvillim.
Dhe i fundit, AWS ofron një shërbim të veçantë për punën me video - AWS Elemental MediaConvert.
Thelbi i funksionit është jashtëzakonisht i thjeshtë: marrim një lidhje S3 për videon origjinale, përmes AWS Console, .NET SDK ose thjesht nëpërmjet JSON-i shkruajmë se çfarë duam të bëjmë me videon dhe thërrasim shërbimin. Ai menaxhon vetë radhët për përpunimin e kërkesave që vijnë, për çliron rezultatet në S3 dhe, më e rëndësishmja, gjeneron një Ngjarje në CloudWatch për çdo ndryshim statusi. Kjo na lejon të realizojmë trigger-at lambda për përfundimin e përpunimit të videos.
Kështu duket versioni përfundimtar i arkitekturës
Të gjithë backend-i vendoset në dy lambda. Një tjetër - për rotacionin e videove vertikale, pasi një punë e tillë nuk mund të bëhet në një kalim të vetëm.
Fronti si një aplikacion SPA, i shkruajtur në JS dhe i kompiluara përmes pug, do të vendoset në një kovë publike S3. Për ngarkimin e videove vetë, nuk na nevojitet ndonjë kod serveri - mjafton të hapim REST-endpoints, që na ofron S3. Një e vetme - nuk harrojmë të rregullojmë politikat dhe CORS.
Pengesa
- AWS MediaConvert për ndonjë arsye të panjohur aplikon zërin vetëm në çdo video fragment përveç, kur ne kemi nevojë për një këngë të këndshme nga fillimi në përgjithësi.
- videot vertikale duhet të përpunohen veçmas. AWS nuk e pëlqen ngjyrën e zezë dhe i vendos videot në 90°.
E lehtë
Megjithëse i gjithë bukuria e Stateless, është e nevojshme të monitorosh se çfarë duhet bërë me videon: të bashkohen apo të mbivendosen zëra mbi materialin e gatshëm video. Për fat të mirë, MediaConvert mbështet kalimin e metadata nëpërmjet punëve të tij, dhe ne gjithmonë mund të aplikojmë një flamur të thjeshtë si "isMasterSoundJob", duke e analizuar këtë metadata në çdo hap.
Serverless lehtëson mësimin e NoOps - një qasje që sugjeron se nuk ka nevojë për një ekip të veçantë përgjegjës për infrastrukturën e projektit. Prandaj, ishte vetëm çështje të realizohet zgjidhja në AWS pa ndihmën e administratorëve të sistemit, të cilët gjithmonë kanë diçka për të bërë.
Dhe për ta gjithë këtë të shpejtojmë, maksimalisht automatizojmë deploy me një skript në AWS CloudFormation, duke lejuar deploy me një dük. Në përfundim, një skedar me 200 rreshta kod sjell një zgjidhje të gatshme, edhe pse sintaksa e CloudFormation mund të jetë e habitshme.
Në përfundim
Serverless nuk është një panace. Por do ta lehtësojë jetën në situatat me tre kufij: "burime të kufizuara—kohë të shkurtër—pak para".
Karakteristikat e aplikacioneve që i përshtatet Serverless
- pa Long-Running proceseve. Kuota maksimale për API Gateway është 29 sekonda, kuota maksimale për lambdën është 5 minuta;
- përshkruhet nga arkitektura Event-Driven;
- ndarë në komponente të lidhura në mënyrë të dobët si SOA;
- nuk kërkon shumë punë me gjendjen e saj;
- është shkruar në .NET Core. Për të punuar me .NET Framework, do të nevojitet ende të paktën Docker me runtime përkatës.
Përfitimet e qasjes Serverless
- redukon kostot e Infrastrukturës;
- redukon kostot e dorëzimit të zgjidhjes;
- shkallëzim automatik;
- zhvillim në majë të përparimeve teknologjike.
Disavantazhet, me një shembull konkret
- Shqyrtimi dhe regjistrimi i shpërndarë - pjesërisht zgjidhjet përmes AWS X-Ray dhe AWS CloudWatch;
- debugging i pakëndshëm;
- Cold Start kur nuk ka ngarkesë;
- Interfejsi kundër përdoruesve të AWS - një problem universal 🙂
Burimi: habr.com
