Treballo en subcontractació, on el principi principal es pot descriure amb la frase "ven molt, fes-ho ràpidament". Com més ràpid ho fem, més guanyarem. I, és desitjable que tot funcioni no amb crosses i mocs, sinó amb un nivell de qualitat acceptable. Us explicaré la meva experiència quan va ser necessari desenvolupar un servei promocional en un curt període de temps.
Donat: compte root a AWS, sense restriccions a l'elecció de la pila de tecnologia, un backend i un mes per al desenvolupament.
Una tasca: implementar un servei promocional on els usuaris pengin d'un a quatre vídeos d'entre un i quatre segons, que després s'incorporen a la sèrie de vídeos original.
decisió
Escriure el teu propi servei de bicicletes en tan poc temps no és una bona idea. A més, per tal que el servei faci front a la càrrega i que tothom rebi el cobejat vídeo, caldrà una infraestructura. I preferiblement no amb el preu de l'avió. Per tant, ens centrem immediatament en solucions ja fetes amb una personalització mínima.
La solució estàndard per treballar amb vídeo és FFmpeg, una utilitat de consola multiplataforma que, mitjançant arguments, permet retallar i sobregravar l'àudio. Tot el que queda per fer és escriure un embolcall i donar-lo a la vida. Escrivim un prototip que uneix dos vídeos junts i... comença la diversió. La biblioteca es basa en .NET Core 2, s'ha d'executar en qualsevol màquina virtual, així que prenem una instància AWS EC2 i tot funcionarà
Text ocultno, no funcionarà
.
Tot i que FFmpeg simplifica la tasca, per obtenir una solució realment funcional, cal crear una instància EC2 i dissenyar-hi una infraestructura de xarxa, inclòs un equilibrador de càrrega. La tasca senzilla de desplegar des de zero es fa "una mica" més complicada i la infraestructura comença a exigir diners immediatament: cada hora es retira l'import del temps d'execució del compte del client.
El nostre servei no implica processos de llarga durada, no requereix una base de dades relacional gran i grossa i s'adapta perfectament a una arquitectura basada en esdeveniments amb una cadena de trucades de microservei. La solució suggereix per si mateixa: podem abandonar l'EC2 i implementar una aplicació sense servidor real, com l'Image Resizer estàndard basat en AWS Lambda.
Per cert, malgrat l'evident disgust dels desenvolupadors d'AWS per .NET, admeten .NET Core 2.1 com a temps d'execució, que ofereix una àmplia gamma d'oportunitats de desenvolupament.
I la cirera del pastís: AWS ofereix un servei independent per treballar amb fitxers de vídeo: AWS Elemental MediaConvert.
L'essència del treball és increïblement senzilla: agafem un enllaç S3 al vídeo sortint, escrivim mitjançant AWS Console, .NET SDK o simplement JSON el que volem fer amb el vídeo i truquem al servei. Ell mateix implementa cues per processar les sol·licituds entrants, carrega el resultat al mateix S3 i, el més important, genera un esdeveniment CloudWatch per a cada canvi d'estat. Això ens permet implementar activadors lambda per completar el processament de vídeo.
Així és l'arquitectura final:
Tot el backend està allotjat en dues lambdas. Un altre és per girar vídeos verticals, ja que aquest treball no es pot fer en una sola passada.
Col·locarem la part davantera en forma d'aplicació SPA escrita en JS i compilada mitjançant pug en un bucket S3 públic. Per descarregar els vídeos en si, no necessitem cap codi de servidor, només hem d'obrir els punts finals REST que ens proporciona S3. L'única cosa és que no us oblideu de configurar polítiques i CORS.
Trampes
- AWS MediaConvert, per algun motiu desconegut, només aplica so a cada fragment de vídeo per separat, però necessitem una cançó alegre de tot el salvapantalles.
- Els vídeos verticals s'han de processar per separat. A AWS no li agraden les barres negres i posa els rodets a 90°.
Pista de patinatge fàcil
Malgrat tota la bellesa de Statess, cal fer un seguiment del que cal fer amb el vídeo: enganxar o afegir àudio a la seqüència de vídeo acabada. Afortunadament, MediaConvert admet el pas de metadades a través dels seus treballs, i sempre podem utilitzar una bandera simple de la forma "isMasterSoundJob", analitzant aquestes metadades en qualsevol moment.
Sense servidor permet treballar perfectament amb NoOps, un enfocament que suposa la innecessitat d'un equip separat responsable de la infraestructura del projecte. Per tant, era una qüestió petita: implementem la solució a AWS sense la participació dels administradors del sistema, que sempre tenen alguna cosa a fer de totes maneres.
I per accelerar tot això, automatitzem l'script de desplegament tant com sigui possible a AWS CloudFormation, que us permet implementar amb un botó directament des de VS. Com a resultat, un fitxer de 200 línies de codi us permet desplegar una solució ja feta, tot i que la sintaxi de CloudFormation pot ser impactant si no hi esteu acostumats.
En total
Sense servidor no és una panacea. Però farà la vida molt més fàcil en situacions amb tres límits: "recursos limitats, a curt termini, pocs diners".
Característiques de les aplicacions aptes per a servidors
- sense processos de llarga durada. El límit dur de l'API Gateway és de 29 segons, el límit dur de lambda és de 5 minuts;
- descrit per l'arquitectura impulsada per esdeveniments;
- es descompon en components poc acoblats com SOA;
- no requereix gaire treball amb la seva condició;
- escrit en .NET Core. Per treballar amb .NET Framework, encara necessitareu almenys Docker amb el temps d'execució adequat.
Beneficis de l'enfocament sense servidor
- redueix els costos d'infraestructura;
- redueix el cost de lliurament de la solució;
- escalabilitat automàtica;
- desenvolupament a l'avantguarda del progrés tecnològic.
Inconvenients, amb un exemple concret
- Traça i registre distribuïts: solucionat parcialment mitjançant AWS X-Ray i AWS CloudWatch;
- depuració incòmoda;
- Arrencada en fred quan no hi ha càrrega;
- La interfície hostil a l'usuari d'AWS és un problema universal :)
Font: www.habr.com