Traballo en outsourcing, onde o principio principal pódese describir coa frase "vende moito, faino rapidamente". Canto máis rápido o fagamos, máis gañaremos. E, é desexable que todo funcione non con muletas e mocos, senón cun nivel de calidade aceptable. Vouvos contar a miña experiencia cando foi necesario desenvolver un servizo promocional nun curto período de tempo.
Dado: conta root en AWS, sen restricións na elección da pila de tecnoloxía, un backend e un mes para o desenvolvemento.
Unha tarefa: implementar un servizo promocional no que os usuarios cargan de un a catro vídeos cunha duración de entre un e catro segundos, que logo se incorporan á serie de vídeos orixinal.
decisión
Escribir o teu propio servizo de bicicletas en tan pouco tempo non é unha boa idea. Ademais, para que o servizo faga fronte á carga e que todos reciban o ansiado vídeo, será necesaria unha infraestrutura. E preferiblemente non co prezo do avión. Polo tanto, centrámonos inmediatamente en solucións preparadas cunha personalización mínima.
A solución estándar para traballar con vídeo é FFmpeg, unha utilidade de consola multiplataforma que, mediante argumentos, permite cortar e sobregrabar audio. Todo o que queda por facer é escribir un envoltorio e liberalo á vida. Escribimos un prototipo que une dous vídeos xuntos, e... comeza a diversión. A biblioteca está baseada en .NET Core 2, debería executarse en calquera máquina virtual, polo que tomamos unha instancia de AWS EC2 e todo funcionará
Texto ocultonon, non vai funcionar
.
Aínda que FFmpeg simplifica a tarefa, para unha solución que funcione realmente necesitas crear unha instancia EC2 e deseñar unha infraestrutura de rede para ela, incluíndo un equilibrador de carga. A simple tarefa de implementar desde cero faise "un pouco" máis complicada e a infraestrutura comeza a esixir diñeiro de inmediato: cada hora o importe para o tempo de execución retírase da conta do cliente.
O noso servizo non implica procesos de longa duración, non require unha base de datos relacional grande e gorda e encaixa perfectamente nunha arquitectura baseada en eventos cunha cadea de chamadas de microservizos. A solución suxire por si mesma: podemos abandonar EC2 e implementar unha aplicación verdadeiramente sen servidor, como o Image Resizer estándar baseado en AWS Lambda.
Por certo, a pesar da aversión evidente dos desenvolvedores de AWS por .NET, admiten .NET Core 2.1 como tempo de execución, que ofrece unha gama completa de oportunidades de desenvolvemento.
E a guinda do bolo: AWS ofrece un servizo separado para traballar con ficheiros de vídeo: AWS Elemental MediaConvert.
A esencia do traballo é incriblemente sinxela: collemos unha ligazón S3 ao vídeo saínte, escribimos a través da Consola AWS, .NET SDK ou simplemente JSON o que queremos facer co vídeo e chamamos ao servizo. El mesmo implementa colas para procesar as solicitudes entrantes, carga o resultado ao propio S3 e, o máis importante, xera un evento CloudWatch para cada cambio de estado. Isto permítenos implementar disparadores lambda para completar o procesamento de vídeo.
Este é o aspecto da arquitectura final:
Todo o backend está aloxado en dúas lambdas. Outra é para rotar vídeos verticais, xa que tal traballo non se pode facer nunha pasada.
Colocaremos a fronte en forma dunha aplicación SPA escrita en JS e compilada mediante pug nun bucket S3 público. Para descargar os propios vídeos, non necesitamos ningún código de servidor; só necesitamos abrir os puntos finais REST que nos proporciona S3. O único é que non esquezas configurar políticas e CORS.
Trampas
- AWS MediaConvert, por algún motivo descoñecido, só aplica o son a cada fragmento de vídeo por separado, pero necesitamos unha canción alegre de todo o protector de pantalla.
- Os vídeos verticais deben procesarse por separado. A AWS non lle gustan as barras negras e pon os rolos a 90°.
Pista de patinaxe fácil
A pesar de toda a beleza de Stateless, cómpre facer un seguimento do que hai que facer co vídeo: pegar ou engadir audio á secuencia de vídeo rematada. Afortunadamente, MediaConvert admite o paso de metadatos a través dos seus traballos, e sempre podemos usar unha bandeira sinxela da forma "isMasterSoundJob", analizando estes metadatos en calquera momento.
Sen servidor permite traballar perfectamente con NoOps, un enfoque que asume a innecesidade dun equipo separado responsable da infraestrutura do proxecto. Polo tanto, era un asunto pequeno: implementamos a solución en AWS sen a participación dos administradores do sistema, que sempre teñen algo que facer de todos os xeitos.
E para acelerar todo isto, automatizamos o script de implementación na medida do posible en AWS CloudFormation, que che permite implementar cun só botón directamente desde VS. Como resultado, un ficheiro de 200 liñas de código permítelle lanzar unha solución preparada, aínda que a sintaxe de CloudFormation pode ser impactante se non estás afeito a ela.
En total
Sen servidor non é unha panacea. Pero facilitará moito a vida en situacións con tres límites: "recursos limitados - curto prazo - pouco diñeiro".
Características das aplicacións aptas para sen servidor
- sen procesos de longa duración. O límite ríxido da API Gateway é de 29 segundos, o límite ríxido de lambda é de 5 minutos;
- descrito pola arquitectura Event-Driven;
- descompón en compoñentes pouco acoplados como SOA;
- non require moito traballo coa súa condición;
- escrito en .NET Core. Para traballar co .NET Framework, aínda necesitará polo menos Docker co tempo de execución adecuado.
Beneficios do enfoque sen servidor
- reduce os custos de infraestrutura;
- reduce o custo de entrega da solución;
- escalabilidade automática;
- desenvolvemento á vangarda do progreso tecnolóxico.
Desvantaxes, cun exemplo concreto
- Rastrexo e rexistro distribuídos: solucionados parcialmente a través de AWS X-Ray e AWS CloudWatch;
- depuración inconveniente;
- Arranque en frío cando non hai carga;
- A interface hostil ao usuario de AWS é un problema universal :)
Fonte: www.habr.com