Работя в сферата на аутсорсинга, където основният принцип може да се опише с израза „продай много, направи го бързо“. Колкото по-бързо го направим, толкова повече ще спечелим. И е желателно всичко да работи не на патерици и сополи, а с приемливо ниво на качество. Ще ви разкажа за моя опит, когато беше необходимо да се разработи промоционална услуга за кратък период от време.
Като се има предвид: root акаунт в AWS, без ограничения за избор на технологичен стек, един бекенд и един месец за разработка.
Цел: прилагане на промоционална услуга, при която потребителите качват от един до четири видеоклипа с продължителност от една до четири секунди, които след това се вграждат в оригиналната видео серия.
Решение
Да напишете свой собствен велосипеден сервиз за толкова кратко време не е добра идея. Освен това, за да може услугата да се справи с натоварването и всеки да получи желаното видео, ще е необходима инфраструктура. И за предпочитане не с етикета с цената от самолета. Затова веднага се фокусираме върху готови решения с минимална персонализация.
Стандартното решение за работа с видео е FFmpeg, крос-платформена конзолна програма, която чрез аргументи ви позволява да изрязвате и презаписвате аудио. Всичко, което остава да направите, е да напишете обвивка и да я пуснете в живот. Пишем прототип, който свързва два видеоклипа и... забавлението започва. Библиотеката е базирана на .NET Core 2, трябва да работи на всяка виртуална машина, така че вземаме екземпляр на AWS EC2 и всичко ще работи
Скрит текстне, няма да работи
.
Въпреки че FFmpeg опростява задачата, за наистина работещо решение трябва да създадете екземпляр на EC2 и да проектирате мрежова инфраструктура за него, включително Load Balancer. Простата задача за внедряване от нулата става „малко“ по-сложна и инфраструктурата започва да изисква пари веднага - на всеки час сумата за време на изпълнение се изтегля от клиентската сметка.
Нашата услуга не включва дълготрайни процеси, не изисква голяма и плътна релационна база данни и се вписва идеално в базирана на събития архитектура с верига от повиквания на микросервизи. Решението се предлага само по себе си - можем да изоставим EC2 и да внедрим истинско безсървърно приложение, като стандартния Image Resizer, базиран на AWS Lambda.
Между другото, въпреки очевидната неприязън на разработчиците на AWS към .NET, те поддържат .NET Core 2.1 като време за изпълнение, което предоставя пълен набор от възможности за разработка.
И черешката на тортата - AWS предоставя отделна услуга за работа с видео файлове - AWS Elemental MediaConvert.
Същността на работата е невероятно проста: вземаме S3 връзка към изходящото видео, пишем чрез AWS Console, .NET SDK или просто JSON какво искаме да направим с видеото и се обаждаме на услугата. Самият той реализира опашки за обработка на входящи заявки, качва резултата в самия S3 и, най-важното, генерира CloudWatch Event за всяка промяна на статуса. Това ни позволява да внедрим ламбда тригери, за да завършим видео обработката.
Ето как изглежда крайната архитектура:
Целият бекенд се помещава в две ламбда. Друг е за въртене на вертикални видеоклипове, тъй като такава работа не може да се извърши наведнъж.
Ще поставим предната част под формата на SPA приложение, написано на JS и компилирано чрез pug в публична S3 кофа. За да изтеглим самите видеоклипове, не се нуждаем от сървърен код - просто трябва да отворим REST крайните точки, които S3 ни предоставя. Единственото нещо е да не забравите да конфигурирате политики и CORS.
Клопките
- AWS MediaConvert по някаква неизвестна причина прилага звук само към всеки видеоклип отделно, но имаме нужда от весела песен от целия скрийнсейвър.
- Вертикалните видеоклипове трябва да се обработват отделно. AWS не харесва черни ленти и поставя ролките на 90°.
Лесна пързалка
Въпреки цялата красота на Stateless, трябва да следите какво трябва да се направи с видеото: да залепите или да добавите аудио към готовата видео поредица. За щастие MediaConvert поддържа предаване на метаданни през своите задания и винаги можем да използваме прост флаг във формата „isMasterSoundJob“, анализирайки тези метаданни на всеки етап.
Serverless перфектно позволява работа с NoOps - подход, който предполага ненужността на отделен екип, отговорен за инфраструктурата на проекта. Следователно беше малък въпрос - внедряваме решението на AWS без участието на системни администратори, които така или иначе винаги имат какво да правят.
И за да ускорим всичко това, ние автоматизираме скрипта за внедряване, доколкото е възможно в AWS CloudFormation, което ви позволява да внедрявате с един бутон директно от VS. В резултат на това файл от 200 реда код ви позволява да пуснете готово решение, въпреки че синтаксисът на CloudFormation може да бъде шокиращ, ако не сте свикнали с него.
Общо
Без сървър не е панацея. Но това ще направи живота много по-лесен в ситуации с три ограничения: „ограничени ресурси – краткосрочен план – малко пари“.
Характеристики на приложения, подходящи за сървър без сървър
- без дълготрайни процеси. Твърдият лимит на API Gateway е 29 секунди, ламбда твърдият лимит е 5 минути;
- описано от управлявана от събития архитектура;
- се разпада на слабо свързани компоненти като SOA;
- не изисква много работа с вашето състояние;
- написан на .NET Core. За да работите с .NET Framework, все още ще ви трябва поне Docker с подходящо време за изпълнение.
Предимства на подхода без сървър
- намалява разходите за инфраструктура;
- намалява разходите за доставка на решението;
- автоматична мащабируемост;
- развитие на върха на технологичния прогрес.
Недостатъци, с конкретен пример
- Разпределено проследяване и регистриране – частично решено чрез AWS X-Ray и AWS CloudWatch;
- неудобно отстраняване на грешки;
- Студен старт при липса на товар;
- Враждебният към потребителя интерфейс на AWS е универсален проблем :)
Източник: www.habr.com