Share
Conceptul de computere fără server este un model de execuție în continuă dezvoltare care încearcă să răspundă nevoilor software-ului modern, bazat pe cloud.
În acest videoclip din cursul meu, Introducere în Serverless, vă voi prezenta arhitectura fără server. Vom vorbi despre punctele sale cheie și o vom compara cu alte modele pentru abstractizarea funcționalității serverului în cloud.
În primul rând, într-un sistem fără server, există servere. Sperăm că nu este o mare surpriză pentru tine. E vorba doar de cine le administrează.
Să aruncăm o privire la o diagramă foarte comună care arată diferite tipuri de servicii.
În stânga, aveți sistemul tradițional local. Totul este gestionat de dvs., până la mașina fizică și în rețea. Apoi aveți diferite niveluri de abstractizare.
Primul nivel al abstractizării este infrastructura ca serviciu. Aici sunteți responsabil pentru tot, de la sistemul de operare sus. Exemple ar fi DigitalOcean sau Amazon EC2. Furnizorul oferă o instanță pentru dvs. și, din acel moment, sunteți pe cont propriu.
Următorul strat de abstracție este containerul ca serviciu. Este, de asemenea, un jucător destul de nou, care are o mulțime de tracțiune din cauza popularității lui Docker. Într-o lume AWS, aceasta ar fi EC2 Container Services.
Apoi, avem o platformă ca serviciu, în care nu sunteți responsabil pentru gestionarea vreunui sistem de operare sau containere. Sunteți singurul responsabil pentru cererea dumneavoastră. Exemple exemplificative din această categorie sunt Heroku, AWS Elastic Beanstalk și Google Compute Engine.
Câțiva ani în urmă, graficul s-ar fi terminat aici. Dar în zilele noastre avem o terminologie nouă, adică funcționează ca un serviciu. În loc să rulați o aplicație care are stat, ceea ce este valabil pentru toate cadrele web tradiționale, chiar dacă utilizați REST și alte lucruri, aveți un sistem care utilizează containere fără stat care sunt declanșate, efemerice și gestionate complet de către serviciu furnizor.
Aceasta este ceea ce se numește serverless. Există un alt concept numit back end ca un serviciu care uneori este, de asemenea, considerat o parte a arhitecturii serverului. Dar, în opinia mea, aparține mai mult software-ului ca serviciu, ceea ce este în esență ceea ce încercați să construiți.
Deci, să vorbim mai mult despre funcții ca serviciu.
După cum sugerează și numele, ca dezvoltator sunteți responsabili pentru scrierea funcțiilor executabile care sunt declanșate și executate de evenimente. Aceasta poate fi o încărcare completă a fișierului la S3 sau o cerere printr-un punct final API. Până acum, atât de simplu. Pentru a înțelege complet conceptul, totuși, voi vorbi despre câteva domenii cheie care definesc funcțiile ca serviciu.
Prima este statul. Funcțiile sunt foarte limitate când vine vorba de conservarea statului. În general, ar trebui să presupui că nu poți face deloc. Funcțiile urmăresc mai mult un principiu de foc și uitare. Dacă doriți să stocați orice, faceți acest lucru cu un serviciu extern, cum ar fi stocarea fișierelor sau o bază de date sau server de cache.
A doua este durata executării. Este posibil să aveți o aplicație server care rulează ore sau zile fără a reporni, în funcție de procesul de implementare. Același lucru este valabil și pentru procesarea de fundal. Cu funcții, timpul de execuție este limitat. Nu este de așteptat ca funcția să fie executată pentru mai mult de câteva secunde, iar AWS Lambda, de exemplu, termină fiecare funcție care nu a terminat să ruleze după cinci minute. Dacă aveți o sarcină foarte lungă, atunci funcția de serviciu poate să nu fie cea mai bună potrivire.
Apoi avem latență la pornire. Acest lucru poate fi totul între câteva milisecunde și minute. Desigur, aceasta depinde de limba și sistemul pe care îl utilizați. De obicei, o funcție Python sau JavaScript pe AWS pornește în milisecunde, dar dacă utilizați mașina virtuală Java, ar putea dura ceva timp până când mașina este răsturnată - mai ales dacă funcția dvs. nu a fost executată în ultimele zece minute, sau aveți o creștere bruscă a execuției.
Acest lucru duce la întrebări despre scalabilitatea și costul de execuție, iar răspunsul pe care îl căutați este: nu vă faceți griji. Scalarea este gestionată de furnizorul de servicii, iar costul este simplu.
Dacă executați o funcție de zece ori, plătiți exact aceste zece invocări. Dacă executați 1000 de ori, plătiți pentru 1.000. Este un pic mai complicat decât asta, desigur, dar asta e esența.
Având un sistem fără server poate fi foarte avantajos. Este minunat dacă aveți trafic inconsecvent - de exemplu, un vârf în vârful oră sau foarte puține solicitări ocazionale, pentru că nu trebuie să alocați resurse care sunt inactiv în majoritatea timpului.
Pentru a recupera, sistemele fără server au servere, dar sunt complet gestionate de furnizorii de nor. Funcțiile sunt nucleul unei arhitecturi fără servere și sunt executate utilizând declanșatoare. Scalarea și disponibilitatea ridicată sunt deja luate în grija furnizorilor de nor. Dacă aveți o cerere foarte ocazională sau o căutare mare, dar scurtă, serverless vă ajută să vă păstrați costul în jos.
În cursul complet, Introducere în serverless, vă vom arăta cum să utilizați serviciile Amazon Web Services pentru a crea o aplicație web fără server, completată cu back-end REST API. Veți vedea, de asemenea, cum să faceți față unor scenarii avansate cum ar fi integrarea altor servicii AWS și orchestrarea funcțiilor care țin de stat. Pe parcurs, veți construi un serviciu web răcoros pentru conversia textului în vorbire.
Puteți lua acest curs imediat cu un abonament la Envato Elements. Pentru o singură taxă lunară redusă, veți avea acces nu numai la acest curs, ci și la biblioteca noastră în creștere de peste 1.000 de cursuri video și cărți electronice de vârf din industria Envato Tuts+.
În plus, beneficiați de descărcări nelimitate din imensa bibliotecă Envato Elements cu 400.000 de active creative. Creează cu fonturi, fotografii, grafică și șabloane unice și oferă proiecte mai bune mai rapid.
Accentsconagua