Mi laboras en subkontraktado, kie la ĉefa principo povas esti priskribita per la frazo "vendu multe, faru ĝin rapide." Ju pli rapide ni faros ĝin, des pli ni gajnos. Kaj, estas dezirinde, ke ĉio funkcias ne sur lambastonoj kaj muko, sed kun akceptebla nivelo de kvalito. Mi rakontos al vi pri mia sperto, kiam necesis disvolvi reklaman servon en mallonga tempodaŭro.
Donita: radika konto en AWS, neniuj limigoj pri la elekto de teknologia stako, unu backend kaj unu monato por disvolviĝo.
Tasko: efektivigi varban servon kie uzantoj alŝutas de unu ĝis kvar filmetoj daŭrantaj de unu ĝis kvar sekundoj, kiuj tiam estas enigitaj en la origina videoserio.
decido
Verki vian propran biciklan servon en tiel mallonga tempo ne estas bona ideo. Krome, por ke la servo eltenu la ŝarĝon kaj ke ĉiuj ricevu la aviditan videon, infrastrukturo estos postulata. Kaj prefere ne kun la prezetikedo de la aviadilo. Tial ni tuj koncentriĝas pri pretaj solvoj kun minimuma personigo.
La norma solvo por labori kun video estas FFmpeg, transplatforma konzola ilo, kiu, per argumentoj, ebligas al vi tranĉi kaj superdubi audio. Restas nur skribi envolvaĵon kaj liberigi ĝin en la vivon. Ni skribas prototipon, kiu kunmetas du filmetojn, kaj... komenciĝas la amuzo. La biblioteko baziĝas sur .NET Core 2, ĝi devus funkcii per iu ajn virtuala maŝino, do ni prenas AWS EC2-instancon kaj ĉio funkcios
Kaŝita tekstone, ĝi ne funkcios
.
Kvankam FFmpeg simpligas la taskon, por vere funkcianta solvo vi devas krei EC2-instancon kaj desegni retan infrastrukturon por ĝi, inkluzive de Load Balancer. La simpla tasko disfaldi de nulo fariĝas "iom" pli komplika, kaj la infrastrukturo komencas postuli monon tuj - ĉiun horon la kvanto por rultempo estas retirita de la klienta konto.
Nia servo ne implikas Longdaŭrajn procezojn, ne postulas grandan kaj grasan interrilatan datumbazon, kaj perfekte persvadas en arkitekturon bazitan pri evento kun ĉeno de mikroservovokoj. La solvo sugestas sin - ni povas forlasi EC2 kaj efektivigi veran senservilan aplikaĵon, kiel la norma Image Resizer bazita sur AWS Lambda.
Cetere, malgraŭ la evidenta malŝato de AWS-programistoj por .NET, ili subtenas .NET Core 2.1 kiel rultempon, kiu disponigas plenan gamon da evoluŝancoj.
Kaj la ĉerizo sur la kuko - AWS provizas apartan servon por labori kun videodosieroj - AWS Elemental MediaConvert.
La esenco de la laboro estas nekredeble simpla: ni prenas S3-ligilon al la eksiĝinta video, skribas per AWS Console, .NET SDK aŭ simple JSON, kion ni volas fari kun la video kaj vokas la servon. Ĝi mem efektivigas atendovicojn por prilabori envenantajn petojn, alŝutas la rezulton al S3 mem kaj, plej grave, generas CloudWatch Event por ĉiu statusŝanĝo. Ĉi tio permesas al ni efektivigi lambda ellasilon por kompletigi videopretigon.
Jen kiel aspektas la fina arkitekturo:
La tuta malantaŭo estas loĝigita en du lambdoj. Alia estas por turni vertikalajn filmetojn, ĉar tia laboro ne povas esti farita per unu paŝo.
Ni metos la fronton en la formo de SPA-aplikaĵo skribita en JS kaj kompilita per pug en publika S3-sitelo. Por elŝuti la filmetojn mem, ni ne bezonas iun servilan kodon - ni nur bezonas malfermi la REST-finpunktojn, kiujn S3 provizas al ni. La sola afero estas ne forgesu agordi politikojn kaj CORS.
enfaliloj
- AWS MediaConvert, pro iu nekonata kialo, nur aplikas sonon al ĉiu videofragmento aparte, sed ni bezonas gajan kanton de la tuta ekranŝparo.
- Vertikalaj filmetoj devas esti prilaboritaj aparte. AWS ne ŝatas nigrajn stangojn kaj metas la rulpremilojn ĉe 90°.
Facila sketejo
Malgraŭ la tuta beleco de Sennacia, vi devas observi tion, kion oni devas fari kun la video: glui aŭ aldoni aŭdion al la finita videosekvenco. Feliĉe, MediaConvert subtenas pasi metadatenojn tra siaj Laborpostenoj, kaj ni ĉiam povas uzi simplan flagon de la formo "isMasterSoundJob", analizante ĉi tiujn metadatumojn en ajna stadio.
Senservilo perfekte permesas labori kun NoOps - aliro kiu supozas la neneceson de aparta teamo respondeca por la projekta infrastrukturo. Sekve, ĝi estis malgranda afero - ni deplojas la solvon sur AWS sen la partopreno de sistemadministrantoj, kiuj ĉiam havas ion por fari ĉiuokaze.
Kaj por akceli ĉion ĉi, ni aŭtomatigas la deplojan skripton kiel eble plej multe sur AWS CloudFormation, kiu permesas vin disfaldi per unu butono rekte de VS. Kiel rezulto, dosiero de 200 linioj de kodo permesas al vi elŝuti pretan solvon, kvankam la CloudFormation-sintakso povas esti ŝoka se vi ne kutimas ĝin.
Tuta
Senservilo ne estas panaceo. Sed ĝi multe pli facilas la vivon en situacioj kun tri limoj: "limigitaj rimedoj—mallongdaŭra—malmulta mono."
Karakterizaĵoj de Aplikoj Taŭga por Senservilo
- sen Longdaŭraj procezoj. API Gateway malmola limo estas 29 sekundoj, lambda malmola limo estas 5 minutoj;
- priskribita de Event-Driven arkitekturo;
- rompiĝas en loze kunligitaj komponentoj kiel SOA;
- ne postulas multe da laboro kun via kondiĉo;
- skribita en .NET Core. Por labori kun la .NET Framework, vi ankoraŭ bezonos almenaŭ Docker kun la taŭga rultempo.
Avantaĝoj de la Senservila aliro
- reduktas infrastrukturajn kostojn;
- reduktas la koston de liverado de la solvo;
- aŭtomata skaleblo;
- evoluo ĉe la avangardo de teknologia progreso.
Malavantaĝoj, kun specifa ekzemplo
- Distribuita spurado kaj registrado - parte solvita per AWS X-Ray kaj AWS CloudWatch;
- maloportuna senararigado;
- Malvarma Komenco kiam ne estas ŝarĝo;
- AWS uzant-malamika interfaco estas universala problemo :)
fonto: www.habr.com