Работам во аутсорсинг, каде што главниот принцип може да се опише со фразата „продај многу, направи го тоа брзо“. Колку побрзо го направиме тоа, толку повеќе ќе заработуваме. И, пожелно е сè да работи не на патерици и мрсули, туку со прифатливо ниво на квалитет. Ќе ви кажам за моето искуство кога беше неопходно да се развие промотивна услуга за краток временски период.
Со оглед: 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 конзола, .NET SDK или едноставно JSON што сакаме да направиме со видеото и ја повикуваме услугата. Самиот спроведува редици за обработка на дојдовните барања, го прикачува резултатот на самиот S3 и што е најважно, генерира настан CloudWatch за секоја промена на статусот. Ова ни овозможува да имплементираме ламбда предизвикувачи за да ја завршиме обработката на видеото.
Вака изгледа конечната архитектура:
Целиот заден дел е сместен во две ламбди. Друга е за ротирачки вертикални видеа, бидејќи таква работа не може да се направи со едно поминување.
Ќе го поставиме предниот дел во форма на SPA апликација напишана во JS и составена преку мопс во јавна кофа S3. За да ги преземеме самите видеа, не ни треба никаков код на серверот - само треба да ги отвориме REST крајните точки што ни ги дава S3. Единственото нешто е не заборавајте да ги конфигурирате политиките и CORS.
Стапици
- AWS MediaConvert, од некоја непозната причина, го применува звукот само на секој видео фрагмент посебно, но ни треба весела песна од целиот скринсејвер.
- Вертикалните видеа треба да се обработуваат посебно. AWS не сака црни шипки и ги става ролерите на 90°.
Лесно лизгалиште
И покрај сета убавина на Без државјанство, треба да следите што треба да се направи со видеото: лепете или додадете аудио во готовиот видео секвенца. За среќа, MediaConvert поддржува пренесување метаподатоци преку неговите работни места и секогаш можеме да користиме едноставно знаменце од формата „isMasterSoundJob“, анализирајќи ги овие метаподатоци во која било фаза.
Без сервер совршено овозможува работа со 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