Nagtatrabaho ako sa outsourcing, kung saan ang pangunahing prinsipyo ay maaaring ilarawan ng pariralang "magbenta ng marami, gawin ito nang mabilis." Kung mas mabilis nating gawin ito, mas marami tayong kikitain. At, ito ay kanais-nais na ang lahat ay gumagana hindi sa saklay at snot, ngunit may isang katanggap-tanggap na antas ng kalidad. Sasabihin ko sa iyo ang tungkol sa aking karanasan noong kinakailangan na bumuo ng isang serbisyong pang-promosyon sa maikling panahon.
Ibinigay: root account sa AWS, walang mga paghihigpit sa pagpili ng stack ng teknolohiya, isang backend, at isang buwan para sa pag-unlad.
Problema: magpatupad ng serbisyong pang-promosyon kung saan ang mga user ay nag-a-upload ng isa hanggang apat na video na tumatagal ng isa hanggang apat na segundo, na pagkatapos ay naka-embed sa orihinal na serye ng video.
desisyon
Ang pagsulat ng sarili mong serbisyo ng bisikleta sa napakaikling panahon ay hindi magandang ideya. Bilang karagdagan, upang makayanan ng serbisyo ang pagkarga at para matanggap ng lahat ang hinahangad na video, kakailanganin ang imprastraktura. At mas mabuti na hindi kasama ang tag ng presyo mula sa eroplano. Samakatuwid, agad kaming tumutuon sa mga handa na solusyon na may kaunting pagpapasadya.
Ang karaniwang solusyon para sa pagtatrabaho sa video ay ang FFmpeg, isang cross-platform console utility na, sa pamamagitan ng mga argumento, ay nagbibigay-daan sa iyong mag-cut at mag-overdub ng audio. Ang natitira pang gawin ay magsulat ng isang balot at ilabas ito sa buhay. Nagsusulat kami ng isang prototype na pinagsasama ang dalawang video, at... magsisimula ang kasiyahan. Ang library ay batay sa .NET Core 2, dapat itong tumakbo sa anumang virtual machine, kaya kumuha kami ng isang halimbawa ng AWS EC2 at lahat ay gagana
Nakatagong tekstohindi, hindi ito gagana
.
Bagama't pinapasimple ng FFmpeg ang gawain, para sa isang talagang gumaganang solusyon kailangan mong lumikha ng isang EC2 instance at magdisenyo ng imprastraktura ng network para dito, kabilang ang isang Load Balancer. Ang simpleng gawain ng pag-deploy mula sa simula ay nagiging "medyo" na mas kumplikado, at ang imprastraktura ay nagsisimulang humingi ng pera kaagad - bawat oras ang halaga para sa runtime ay na-withdraw mula sa account ng kliyente.
Ang aming serbisyo ay hindi nagsasangkot ng mga Long-Running na proseso, hindi nangangailangan ng malaki at mataba na relational database, at akmang akma sa isang event-based na arkitektura na may chain ng mga microservice na tawag. Ang solusyon ay nagmumungkahi mismo - maaari nating talikuran ang EC2 at ipatupad ang isang true-serverless na application, tulad ng karaniwang Image Resizer batay sa AWS Lambda.
Siyanga pala, sa kabila ng halatang ayaw ng mga developer ng AWS para sa .NET, sinusuportahan nila ang .NET Core 2.1 bilang runtime, na nagbibigay ng buong hanay ng mga pagkakataon sa pag-unlad.
At ang cherry on the cake - Nagbibigay ang AWS ng hiwalay na serbisyo para sa pagtatrabaho sa mga video file - AWS Elemental MediaConvert.
Ang kakanyahan ng trabaho ay hindi kapani-paniwalang simple: kumukuha kami ng S3 na link sa papalabas na video, sumulat sa pamamagitan ng AWS Console, .NET SDK o simpleng JSON kung ano ang gusto naming gawin sa video at tumawag sa serbisyo. Ito mismo ang nagpapatupad ng mga pila para sa pagproseso ng mga papasok na kahilingan, ina-upload ang resulta sa S3 mismo at, higit sa lahat, bumubuo ng CloudWatch Event para sa bawat pagbabago ng status. Nagbibigay-daan ito sa amin na ipatupad ang mga trigger ng lambda para makumpleto ang pagpoproseso ng video.
Ganito ang hitsura ng huling arkitektura:
Ang buong backend ay makikita sa dalawang lambdas. Ang isa pa ay para sa pag-rotate ng mga vertical na video, dahil ang ganitong gawain ay hindi magagawa sa isang pass.
Ilalagay namin ang harap sa anyo ng isang SPA application na nakasulat sa JS at pinagsama-sama sa pamamagitan ng pug sa isang pampublikong S3 bucket. Para mag-download mismo ng mga video, hindi namin kailangan ng anumang server code - kailangan lang naming buksan ang REST endpoints na ibinibigay sa amin ng S3. Ang tanging bagay ay huwag kalimutang i-configure ang mga patakaran at CORS.
Pitfalls
- Ang AWS MediaConvert, sa hindi malamang dahilan, ay inilalapat lamang ang tunog sa bawat fragment ng video nang hiwalay, ngunit kailangan namin ng masayang kanta mula sa buong screensaver.
- Ang mga vertical na video ay kailangang iproseso nang hiwalay. Hindi gusto ng AWS ang mga itim na bar at inilalagay ang mga roller sa 90°.
Madaling skating rink
Sa kabila ng lahat ng kagandahan ng Stateless, kailangan mong subaybayan kung ano ang kailangang gawin sa video: i-glue o magdagdag ng audio sa tapos na sequence ng video. Sa kabutihang palad, sinusuportahan ng MediaConvert ang pagpasa ng metadata sa pamamagitan ng Mga Trabaho nito, at maaari kaming palaging gumamit ng isang simpleng flag ng form na "isMasterSoundJob", pag-parse ng metadata na ito sa anumang yugto.
Ang Serverless ay perpektong nagbibigay-daan sa pagtatrabaho sa NoOps - isang diskarte na ipinapalagay ang hindi kinakailangan ng isang hiwalay na koponan na responsable para sa imprastraktura ng proyekto. Samakatuwid, ito ay isang maliit na bagay - inilalagay namin ang solusyon sa AWS nang walang paglahok ng mga administrator ng system, na palaging may gagawin pa rin.
At para mapabilis ang lahat ng ito, ino-automate namin ang deployment script hangga't maaari sa AWS CloudFormation, na nagbibigay-daan sa iyong mag-deploy gamit ang isang button nang direkta mula sa VS. Bilang resulta, ang isang file na may 200 linya ng code ay nagbibigay-daan sa iyo upang ilunsad ang isang handa na solusyon, kahit na ang CloudFormation syntax ay maaaring nakakagulat kung hindi ka sanay dito.
Sa kabuuan
Ang serverless ay hindi isang panlunas sa lahat. Ngunit gagawin nitong mas madali ang buhay sa mga sitwasyong may tatlong limitasyon: “limitadong mapagkukunan—maikling panahon—maliit na pera.”
Mga Katangian ng Mga Application na Angkop para sa Walang Server
- nang walang mga prosesong Pangmatagalan. Ang hard limit ng API Gateway ay 29 segundo, ang lambda hard limit ay 5 minuto;
- inilarawan ng arkitektura na Hinihimok ng Kaganapan;
- bumabagsak sa maluwag na pinagsamang mga bahagi tulad ng SOA;
- hindi nangangailangan ng maraming trabaho sa iyong kondisyon;
- nakasulat sa .NET Core. Upang gumana sa .NET Framework, kakailanganin mo pa rin ng hindi bababa sa Docker na may naaangkop na runtime.
Mga benepisyo ng diskarte na Walang Server
- binabawasan ang mga gastos sa imprastraktura;
- binabawasan ang gastos ng paghahatid ng solusyon;
- awtomatikong scalability;
- pag-unlad sa dulo ng teknolohikal na pag-unlad.
Mga disadvantages, na may isang tiyak na halimbawa
- Ibinahagi ang pagsubaybay at pag-log - bahagyang nalutas sa pamamagitan ng AWS X-Ray at AWS CloudWatch;
- hindi maginhawang pag-debug;
- Cold Start kapag walang load;
- Ang interface ng user-hostile ng AWS ay isang pangkalahatang problema :)
Pinagmulan: www.habr.com