Pa server nuk ka të bëjë me mungesën fizike të serverëve. Ky nuk është një vrasës kontejnerësh apo një tendencë kalimtare. Kjo është një qasje e re për ndërtimin e sistemeve në re. Në artikullin e sotëm do të prekim arkitekturën e aplikacioneve pa server, le të shohim se çfarë roli luajnë ofruesi i shërbimit pa server dhe projektet me burim të hapur. Së fundi, le të flasim për çështjet e përdorimit të Serverless.
Unë dua të shkruaj një pjesë të serverit të një aplikacioni (ose edhe një dyqan online). Ky mund të jetë një bisedë, një shërbim publikimi i përmbajtjes ose një balancues i ngarkesës. Në çdo rast, do të ketë shumë dhimbje koke: do t'ju duhet të përgatisni infrastrukturën, të përcaktoni varësitë e aplikacionit dhe të mendoni për sistemin operativ pritës. Atëherë do t'ju duhet të përditësoni përbërës të vegjël që nuk ndikojnë në funksionimin e pjesës tjetër të monolitit. Epo, le të mos harrojmë shkallëzimin nën ngarkesë.
Po sikur të marrim kontejnerë kalimtarë, në të cilët varësitë e kërkuara janë tashmë të instaluara paraprakisht, dhe vetë kontejnerët janë të izoluar nga njëri-tjetri dhe nga sistemi operativ pritës? Ne do ta ndajmë monolitin në mikroshërbime, secila prej të cilave mund të përditësohet dhe të shkallëzohet në mënyrë të pavarur nga të tjerët. Duke vendosur kodin në një enë të tillë, unë mund ta ekzekutoj atë në çdo infrastrukturë. Tashmë më mirë.
Po nëse nuk dëshironi të konfiguroni kontejnerët? Nuk dua të mendoj për shkallëzimin e aplikacionit. Nuk dua të paguaj për kontejnerët që funksionojnë boshe kur ngarkesa në shërbim është minimale. Unë dua të shkruaj kodin. Përqendrohuni në logjikën e biznesit dhe sillni produktet në treg me shpejtësinë e dritës.
Mendime të tilla më çuan në kompjuter pa server. Pa server në këtë rast do të thotë jo mungesa fizike e serverëve, por mungesa e dhimbjeve të kokës në menaxhimin e infrastrukturës.
Ideja është që logjika e aplikacionit ndahet në funksione të pavarura. Ata kanë një strukturë ngjarjesh. Çdo funksion kryen një "mikrodetyrë". Gjithçka që kërkohet nga zhvilluesi është të ngarkojë funksionet në tastierën e ofruar nga ofruesi i resë kompjuterike dhe t'i ndërlidhë ato me burimet e ngjarjeve. Kodi do të ekzekutohet sipas kërkesës në një enë të përgatitur automatikisht, dhe unë do të paguaj vetëm për kohën e ekzekutimit.
Le të shohim se si do të duket tani procesi i zhvillimit të aplikacionit.
Nga ana e zhvilluesit
Më herët filluam të flasim për një aplikacion për një dyqan online. Në qasjen tradicionale, logjika kryesore e sistemit kryhet nga një aplikim monolit. Dhe serveri me aplikacionin po funksionon vazhdimisht, edhe nëse nuk ka ngarkesë.
Për të kaluar te pa server, ne e ndajmë aplikacionin në mikrodetyra. Ne shkruajmë funksionin tonë për secilën prej tyre. Funksionet janë të pavarura nga njëri-tjetri dhe nuk ruajnë informacione shtetërore (pa shtetësi). Ato madje mund të shkruhen në gjuhë të ndryshme. Nëse njëri prej tyre "bie", i gjithë aplikacioni nuk do të ndalet. Arkitektura e aplikacionit do të duket si kjo:
Ndarja në funksione në Serverless është e ngjashme me punën me mikroshërbime. Por një mikroshërbim mund të kryejë disa detyra dhe një funksion duhet të kryejë në mënyrë ideale një. Le të imagjinojmë se detyra është mbledhja e statistikave dhe shfaqja e tyre me kërkesën e përdoruesit. Në qasjen e mikroshërbimit, një detyrë kryhet nga një shërbim me dy pika hyrëse: shkrimi dhe leximi. Në llogaritjen pa server, këto do të jenë dy funksione të ndryshme që nuk kanë lidhje me njëri-tjetrin. Zhvilluesi kursen burimet e llogaritjes nëse, për shembull, statistikat përditësohen më shpesh sesa shkarkohen.
Funksionet pa server duhet të ekzekutohen në një periudhë të shkurtër kohe (timeout), e cila përcaktohet nga ofruesi i shërbimit. Për shembull, për AWS koha është 15 minuta. Kjo do të thotë se funksionet jetëgjatë do të duhet të ndryshohen për t'iu përshtatur kërkesave - kjo është ajo që e dallon Serverless nga teknologjitë e tjera të njohura sot (kontejnerët dhe Platforma si shërbim).
Ne caktojmë një ngjarje për secilin funksion. Një ngjarje është një nxitës për një veprim:
ngjarje
Veprimi që kryen funksioni
Një imazh produkti është ngarkuar në depo.
Kompresoni imazhin dhe ngarkoni në një drejtori
Adresa e dyqanit fizik është përditësuar në bazën e të dhënave
Ngarko një vendndodhje të re në harta
Klienti paguan për mallrat
Filloni përpunimin e pagesës
Ngjarjet mund të jenë kërkesa HTTP, të dhëna transmetimi, radhë mesazhesh, etj. Burimet e ngjarjeve janë ndryshimet ose ndodhitë e të dhënave. Përveç kësaj, funksionet mund të aktivizohen nga një kohëmatës.
Arkitektura u përpunua dhe aplikacioni pothuajse u bë pa server. Më pas shkojmë te ofruesi i shërbimit.
Nga ana e ofruesit
Në mënyrë tipike, llogaritja pa server ofrohet nga ofruesit e shërbimeve cloud. Ato quhen ndryshe: Funksionet Azure, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Ne do ta përdorim shërbimin përmes konsolës së ofruesit ose llogarisë personale. Kodi i funksionit mund të shkarkohet në një nga mënyrat e mëposhtme:
- shkruani kodin në redaktorët e integruar nëpërmjet konsolës së internetit,
- shkarkoni arkivin me kodin,
- punoni me depo publike ose private git.
Këtu kemi vendosur ngjarjet që thërrasin funksionin. Grupet e ngjarjeve mund të ndryshojnë për ofrues të ndryshëm.
Ofruesi ndërtoi dhe automatizoi sistemin e funksionit si shërbim (FaaS) në infrastrukturën e tij:
- Kodi i funksionit përfundon në ruajtje në anën e ofruesit.
- Kur ndodh një ngjarje, kontejnerët me një mjedis të përgatitur vendosen automatikisht në server. Çdo shembull funksioni ka kontejnerin e vet të izoluar.
- Nga ruajtja, funksioni dërgohet në kontejner, llogaritet dhe kthen rezultatin.
- Numri i ngjarjeve paralele po rritet - numri i kontejnerëve po rritet. Sistemi shkallëzohet automatikisht. Nëse përdoruesit nuk i qasen funksionit, ai do të jetë joaktiv.
- Ofruesi cakton kohën e papunësisë për kontejnerët - nëse gjatë kësaj kohe funksionet nuk shfaqen në kontejner, ai shkatërrohet.
Në këtë mënyrë ne nxjerrim pa server nga kutia. Ne do të paguajmë për shërbimin duke përdorur modelin pay-as-you-go dhe vetëm për ato funksione që përdoren dhe vetëm për kohën kur janë përdorur.
Për të prezantuar zhvilluesit me shërbimin, ofruesit ofrojnë deri në 12 muaj testim falas, por kufizojnë kohën totale të llogaritjes, numrin e kërkesave në muaj, fondet ose konsumin e energjisë.
Avantazhi kryesor i punës me një ofrues është aftësia për të mos u shqetësuar për infrastrukturën (serverët, makinat virtuale, kontejnerët). Nga ana e tij, ofruesi mund të zbatojë FaaS duke përdorur zhvillimet e veta dhe duke përdorur mjete me burim të hapur. Le të flasim për to më tej.
Nga ana e burimit të hapur
Komuniteti me burim të hapur ka punuar në mënyrë aktive në mjetet pa server gjatë dy viteve të fundit. Lojtarët më të mëdhenj të tregut gjithashtu kontribuojnë në zhvillimin e platformave pa server:
- Google u ofron zhvilluesve mjetin e tij me burim të hapur - . IBM, RedHat, Pivotal dhe SAP morën pjesë në zhvillimin e tij;
- IBM ka punuar në një platformë pa server , i cili më pas u bë një projekt i Fondacionit Apache;
- microsoft hapi pjesërisht kodin e platformës .
Zhvillimet janë duke u zhvilluar edhe në drejtim të kornizave pa server. и të vendosura brenda grupimeve të Kubernetes të përgatitura paraprakisht, punon me Kubernetes dhe Docker Swarm. Korniza vepron si një lloj kontrolluesi - sipas kërkesës, përgatit një mjedis të ekzekutimit brenda grupit dhe më pas lëshon një funksion atje.
Kornizat lënë hapësirë për konfigurimin e mjetit për t'iu përshtatur nevojave tuaja. Pra, në Kubeless, një zhvillues mund të konfigurojë afatin e ekzekutimit të funksionit (vlera e paracaktuar është 180 sekonda). Fission, në një përpjekje për të zgjidhur problemin e fillimit të ftohtë, sugjeron që disa kontejnerë të funksionojnë gjatë gjithë kohës (megjithëse kjo kërkon kosto të ndërprerjes së burimeve). Dhe OpenFaaS ofron një sërë nxitësish për çdo shije dhe ngjyrë: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs dhe të tjerë.
Udhëzimet për fillimin mund të gjenden në dokumentacionin zyrtar të kornizave. Puna me ta kërkon të kesh pak më shumë aftësi sesa kur punon me një ofrues - kjo është të paktën aftësia për të nisur një grup Kubernetes përmes CLI. Më së shumti, përfshini mjete të tjera me burim të hapur (për shembull, menaxherin e radhës Kafka).
Pavarësisht se si punojmë me Serverless - përmes një ofruesi ose duke përdorur burim të hapur, do të marrim një sërë avantazhesh dhe disavantazhesh të qasjes pa server.
Nga pikëpamja e avantazheve dhe disavantazheve
Pa server zhvillon idetë e një infrastrukture kontejneri dhe një qasje mikroservice, në të cilën ekipet mund të punojnë në një mënyrë shumëgjuhëshe pa u lidhur me një platformë. Ndërtimi i një sistemi është thjeshtuar dhe gabimet janë më të lehta për t'u korrigjuar. Arkitektura Microservice ju lejon të shtoni funksionalitet të ri në sistem shumë më shpejt sesa në rastin e një aplikacioni monolit.
Pa server zvogëlon edhe më tej kohën e zhvillimit, duke i lejuar zhvilluesit të fokusohet vetëm në logjikën dhe kodimin e biznesit të aplikacionit. Si rezultat, koha për të tregtuar për zhvillime zvogëlohet.
Si bonus, marrim shkallëzim automatik për ngarkesën, dhe ne paguajmë vetëm për burimet e përdorura dhe vetëm në kohën kur ato përdoren.
Si çdo teknologji, Serverless ka disavantazhe.
Për shembull, një disavantazh i tillë mund të jetë koha e fillimit të ftohtë (mesatarisht deri në 1 sekondë për gjuhë të tilla si JavaScript, Python, Go, Java, Ruby).
Nga njëra anë, në realitet, koha e fillimit të ftohtë varet nga shumë variabla: gjuha në të cilën është shkruar funksioni, numri i bibliotekave, sasia e kodit, komunikimi me burime shtesë (të njëjtat baza të dhënash ose serverë vërtetimi). Meqenëse zhvilluesi i kontrollon këto variabla, ai mund të zvogëlojë kohën e fillimit. Por nga ana tjetër, zhvilluesi nuk mund të kontrollojë kohën e nisjes së kontejnerit - gjithçka varet nga ofruesi.
Një fillim i ftohtë mund të kthehet në një fillim të ngrohtë kur një funksion ripërdor një kontejner të nisur nga një ngjarje e mëparshme. Kjo situatë do të lindë në tre raste:
- nëse klientët e përdorin shpesh shërbimin dhe numri i thirrjeve në funksion rritet;
- nëse ofruesi, platforma ose korniza ju lejon të mbani disa kontejnerë të funksionojnë gjatë gjithë kohës;
- nëse zhvilluesi ekzekuton funksionet në një kohëmatës (të themi çdo 3 minuta).
Për shumë aplikacione, fillimi i ftohtë nuk është problem. Këtu ju duhet të ndërtoni llojin dhe detyrat e shërbimit. Një vonesë e fillimit prej një sekonde nuk është gjithmonë kritike për një aplikacion biznesi, por mund të bëhet kritike për shërbimet mjekësore. Në këtë rast, qasja pa server ndoshta nuk do të jetë më e përshtatshme.
Disavantazhi tjetër i "Serverless" është jetëgjatësia e shkurtër e një funksioni (timeout gjatë së cilës funksioni duhet të ekzekutohet).
Por, nëse duhet të punoni me detyra jetëgjata, mund të përdorni një arkitekturë hibride - kombinoni pa server me një teknologji tjetër.
Jo të gjitha sistemet do të jenë në gjendje të punojnë duke përdorur skemën pa server.
Disa aplikacione do të ruajnë ende të dhëna dhe gjendje gjatë ekzekutimit. Disa arkitektura do të mbeten monolite dhe disa veçori do të jenë jetëgjatë. Megjithatë (si teknologjitë cloud dhe më pas kontejnerët), Serverless është një teknologji me një të ardhme të shkëlqyer.
Në këtë drejtim, do të doja të kaloja pa probleme në çështjen e përdorimit të qasjes pa server.
Nga ana e aplikimit
Për 2018, përqindja e përdorimit pa server . Ndër kompanitë që tashmë e kanë zbatuar teknologjinë në shërbimet e tyre janë gjigantë të tillë tregu si Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Në të njëjtën kohë, duhet të kuptoni se Serverless nuk është një ilaç, por një mjet për zgjidhjen e një sërë problemesh:
- Zvogëloni kohën e ndërprerjes së burimeve. Nuk ka nevojë të mbani vazhdimisht një makinë virtuale për shërbimet që kanë pak thirrje.
- Përpunoni të dhënat në fluturim. Kompresoni fotot, prisni sfondet, ndryshoni kodimin e videos, punoni me sensorë IoT, kryeni operacione matematikore.
- “Ngjitni” shërbimet e tjera së bashku. Depoja e Git me programe të brendshme, chat bot në Slack me Jira dhe kalendar.
- Balanconi ngarkesën. Le të hedhim një vështrim më të afërt këtu.
Le të themi se ka një shërbim që tërheq 50 persona. Nën të ka një makinë virtuale me harduer të dobët. Herë pas here, ngarkesa në shërbim rritet ndjeshëm. Atëherë hardueri i dobët nuk mund të përballojë.
Ju mund të përfshini një balancues në sistem që do të shpërndajë ngarkesën, të themi, në tre makina virtuale. Në këtë fazë, ne nuk mund të parashikojmë me saktësi ngarkesën, kështu që mbajmë një sasi të caktuar burimesh të funksionojnë "në rezervë". Dhe ne paguajmë më tepër për kohën joproduktive.
Në një situatë të tillë, ne mund të optimizojmë sistemin përmes një qasjeje hibride: ne lëmë një makinë virtuale pas balancuesit të ngarkesës dhe vendosim një lidhje me pikën përfundimtare pa server me funksione. Nëse ngarkesa e kalon pragun, balancuesi lëshon instancat e funksionit që marrin përsipër një pjesë të përpunimit të kërkesës.
Kështu, Serverless mund të përdoret aty ku është e nevojshme për të përpunuar një numër të madh kërkesash jo shumë shpesh, por intensivisht. Në këtë rast, drejtimi i disa funksioneve për 15 minuta është më fitimprurës sesa mbajtja e një makine virtuale ose serveri gjatë gjithë kohës.
Me të gjitha avantazhet e llogaritjes pa server, përpara zbatimit, së pari duhet të vlerësoni logjikën e aplikacionit dhe të kuptoni se cilat probleme mund të zgjidhë pa server në një rast të veçantë.
pa server dhe Selectel
Në Selectel jemi tashmë nëpërmjet panelit tonë të kontrollit. Tani ne po ndërtojmë platformën tonë FaaS. Ne duam që zhvilluesit të jenë në gjendje të zgjidhin problemet e tyre duke përdorur Serverless përmes një ndërfaqeje të përshtatshme dhe fleksibël.
Nëse keni ide se cila duhet të jetë platforma ideale FaaS dhe si dëshironi të përdorni Serverless në projektet tuaja, ndajini ato në komente. Ne do të marrim parasysh dëshirat tuaja gjatë zhvillimit të platformës.
Materialet e përdorura në artikull:
Burimi: www.habr.com