Serverless giet net oer it fysike ûntbrekken fan servers. Dit is gjin kontenermoardner as in trochrinnende trend. Dit is in nije oanpak foar it bouwen fan systemen yn 'e wolk. Yn it artikel fan hjoed sille wy de arsjitektuer fan Serverless-applikaasjes oanreitsje, litte wy sjen hokker rol de Serverless-tsjinstferliener en iepenboarneprojekten spylje. As lêste, litte wy prate oer de problemen fan it brûken fan Serverless.
Ik wol in tsjinner diel fan in applikaasje skriuwe (of sels in online winkel). Dit kin in petear wêze, in tsjinst foar publisearjen fan ynhâld, of in loadbalancer. Yn alle gefallen sil d'r in protte hoofdpijn wêze: jo moatte de ynfrastruktuer tariede, de ôfhinklikens fan applikaasjes bepale en tinke oer it bestjoeringssysteem fan 'e host. Dan moatte jo lytse komponinten bywurkje dy't gjin ynfloed hawwe op 'e wurking fan' e rest fan 'e monolith. No, lit ús net ferjitte oer skaalfergrutting ûnder lading.
Wat as wy efemere konteners nimme, wêryn de fereaske ôfhinklikens al foarôf ynstalleare binne, en de konteners sels binne isolearre fan elkoar en fan it host OS? Wy sille de monolyt ferdiele yn mikrotsjinsten, elk fan dy kin wurde bywurke en skalearre ûnôfhinklik fan 'e oaren. Troch de koade yn sa'n kontener te pleatsen, kin ik it op elke ynfrastruktuer útfiere. Al better.
Wat as jo konteners net wolle konfigurearje? Ik wol net tinke oer it skaalfergrutting fan de applikaasje. Ik wol net betelje foar idle rinnende konteners as de lading op 'e tsjinst minimaal is. Ik wol koade skriuwe. Fokus op saaklike logika en bring produkten op 'e merke mei de snelheid fan ljocht.
Sokke gedachten liede my ta serverless computing. Serverless yn dit gefal betsjut net it fysike ûntbrekken fan servers, mar it ûntbrekken fan hoofdpijn foar ynfrastruktuerbehear.
It idee is dat applikaasje logika wurdt opdield yn ûnôfhinklike funksjes. Se hawwe in evenemint struktuer. Elke funksje docht ien "mikrotask". Alles wat nedich is fan 'e ûntwikkelder is om de funksjes te laden yn' e konsole levere troch de wolkprovider en se te korrelearjen mei eveneminteboarnen. De koade wurdt útfierd op oanfraach yn in automatysk taret container, en ik sil allinne betelje foar de útfiering tiid.
Litte wy sjen hoe't it proses foar applikaasjeûntwikkeling no sil útsjen.
Fan 'e kant fan' e ûntwikkelders
Earder begûnen wy te praten oer in applikaasje foar in online winkel. Yn 'e tradisjonele oanpak wurdt de wichtichste logika fan it systeem útfierd troch in monolityske applikaasje. En de tsjinner mei de applikaasje rint konstant, sels as d'r gjin lading is.
Om nei serverless te ferpleatsen, brekke wy de applikaasje yn mikrotaken. Wy skriuwe ús eigen funksje foar elk fan harren. De funksjes binne ûnôfhinklik fan elkoar en bewarje gjin steatynformaasje (steateleas). Se kinne sels yn ferskate talen skreaun wurde. As ien fan har "falt", sil de heule applikaasje net stopje. De applikaasje-arsjitektuer sil der sa útsjen:
De ferdieling yn funksjes yn Serverless is fergelykber mei wurkjen mei mikrotsjinsten. Mar in mikroservice kin ferskate taken útfiere, en in funksje soe ideaal ien útfiere. Litte wy ús foarstelle dat de taak is om statistiken te sammeljen en te werjaan op fersyk fan 'e brûker. Yn 'e mikroservice-oanpak wurdt in taak útfierd troch ien tsjinst mei twa yngongspunten: skriuwen en lêzen. Yn serverless computing sille dit twa ferskillende funksjes wêze dy't net mei elkoar besibbe binne. De ûntwikkelder besparret komputerboarnen as bygelyks statistiken faker bywurke wurde as se wurde ynladen.
Serverless funksjes moatte wurde útfierd yn in koarte perioade fan tiid (timeout), dat wurdt bepaald troch de tsjinst provider. Bygelyks, foar AWS is de timeout 15 minuten. Dit betsjut dat lange libbensfunksjes moatte wurde feroare om oan 'e easken te passen - dit is wat Serverless ûnderskiedt fan oare populêre technologyen hjoed (containers en Platform as in tsjinst).
Wy jouwe in evenemint oan elke funksje. In evenemint is in trigger foar in aksje:
Evenemint
De aksje dy't de funksje útfiert
In produktôfbylding is opladen nei it repository.
Komprimearje de ôfbylding en upload nei in map
It fysike winkeladres is bywurke yn de databank
Laad in nije lokaasje yn kaarten
De klant betellet foar it guod
Begjinne betelling ferwurkjen
Eveneminten kinne HTTP-oanfragen, streaminggegevens, berjochtwachtrige, ensfh. Event boarnen binne feroarings of foarkommen fan gegevens. Dêrneist kinne funksjes wurde trigger troch in timer.
De arsjitektuer waard útwurke, en de applikaasje waard hast serverless. Dêrnei geane wy nei de tsjinstferliener.
Fan de kant fan de provider
Typysk wurdt serverless computing oanbean troch cloud-tsjinstferlieners. Se wurde oars neamd: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Wy sille de tsjinst brûke fia de konsole of persoanlik akkount fan de provider. Funksjekoade kin op ien fan 'e folgjende manieren downloade wurde:
- skriuw koade yn ynboude bewurkers fia de webkonsole,
- download it argyf mei de koade,
- wurkje mei iepenbiere as partikuliere git-repositories.
Hjir sette wy de eveneminten op dy't de funksje neame. De sets fan eveneminten kinne ferskille foar ferskate providers.
De provider boude en automatisearre it Function as a Service (FaaS) systeem op syn ynfrastruktuer:
- De funksje koade einiget yn opslach oan de provider kant.
- As in evenemint foarkomt, wurde konteners mei in tariede omjouwing automatysk ynset op de tsjinner. Elke funksje-eksimplaar hat syn eigen isolearre kontener.
- Fanút de opslach wurdt de funksje nei de kontener stjoerd, berekkene en jout it resultaat werom.
- It oantal parallelle eveneminten groeit - it oantal konteners groeit. It systeem skaal automatysk. As brûkers gjin tagong krije ta de funksje, sil dizze ynaktyf wêze.
- De provider stelt de idle tiid foar konteners yn - as yn dizze tiid funksjes net ferskine yn 'e kontener, wurdt it ferneatige.
Op dizze manier krije wy Serverless út 'e doaze. Wy sille betelje foar de tsjinst mei it pay-as-you-go-model en allinich foar dy funksjes dy't wurde brûkt, en allinich foar de tiid doe't se waarden brûkt.
Om ûntwikkelders oan 'e tsjinst yn te fieren, biede providers oant 12 moannen fergees testen, mar beheine de totale berekkeningstiid, oantal oanfragen per moanne, fûnsen of enerzjyferbrûk.
It wichtichste foardiel fan wurkjen mei in provider is de mooglikheid om gjin soargen te meitsjen oer ynfrastruktuer (servers, firtuele masines, konteners). Foar har diel kin de provider FaaS ymplementearje sawol mei har eigen ûntwikkelingen as mei help fan iepen boarne-ark. Litte wy fierder oer har prate.
Fan 'e iepen boarne kant
De iepen boarne-mienskip hat de ôfrûne pear jier aktyf wurke oan Serverless-ark. De grutste merkspilers drage ek by oan de ûntwikkeling fan serverless platfoarms:
- Google biedt ûntwikkelders syn iepen boarne-ark - . IBM, RedHat, Pivotal en SAP diene mei oan syn ûntwikkeling;
- IBM wurke op in Serverless platfoarm , dat doe in projekt waard fan de Apache Foundation;
- Microsoft foar in part iepene it platfoarm koade .
Untjouwings binne ek oan 'e gong yn' e rjochting fan serverless frameworks. и ynset yn foarbereide Kubernetes-klusters, wurket mei sawol Kubernetes as Docker Swarm. It ramt fungearret as in soarte fan controller - op oanfraach taret it in runtime-omjouwing yn it kluster ta, en lanseart dêr dan in funksje.
Frameworks litte romte foar it konfigurearjen fan it ark om oan jo behoeften te passen. Dat, yn Kubeless, kin in ûntwikkelder de time-out foar útfiering fan funksje konfigurearje (de standertwearde is 180 sekonden). Fission, yn in besykjen om it probleem fan 'e kâlde start op te lossen, suggerearret dat guon konteners de hiele tiid draaie (hoewol't dit kosten foar boarne-downtime meibringt). En OpenFaaS biedt in set triggers foar elke smaak en kleur: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT's en oaren.
Ynstruksjes om te begjinnen kinne jo fine yn 'e offisjele dokumintaasje fan' e kaders. Wurkje mei har fereasket in bytsje mear feardigens dan by it wurkjen mei in provider - dit is teminsten de mooglikheid om in Kubernetes-kluster te starten fia de CLI. Omfetsje op syn meast oare iepen boarne-ark (bygelyks de Kafka-wachtrigemanager).
Nettsjinsteande hoe't wy wurkje mei Serverless - fia in provider of it brûken fan iepen boarne, sille wy in oantal foardielen en neidielen krije fan 'e Serverless-oanpak.
Ut it eachpunt fan foardielen en neidielen
Serverless ûntwikkelet de ideeën fan in kontenerynfrastruktuer en in mikroservice-oanpak, wêryn teams kinne wurkje yn in meartalige modus sûnder te wêzen bûn oan ien platfoarm. It bouwen fan in systeem is ferienfâldige en flaters binne makliker te korrigearjen. Microservice-arsjitektuer kinne jo nije funksjonaliteit tafoegje oan it systeem folle flugger dan yn it gefal fan in monolityske applikaasje.
Serverless ferminderet ûntwikkelingstiid noch fierder, wêrtroch de ûntwikkelder allinich fokusje kin op 'e saaklike logika en kodearring fan' e applikaasje. Dêrtroch wurdt de tiid om te merken foar ûntwikkelingen fermindere.
As bonus krije wy automatyske skaalfergrutting foar lading, en wy betelje allinich foar de brûkte middels en allinich op it momint dat se brûkt wurde.
Lykas elke technology hat Serverless neidielen.
Sa'n neidiel kin bygelyks de kâlde starttiid wêze (gemiddeld oant 1 sekonde foar talen lykas JavaScript, Python, Go, Java, Ruby).
Oan 'e iene kant, yn' e realiteit, is de kâlde starttiid ôfhinklik fan in protte fariabelen: de taal wêryn de funksje skreaun is, it oantal biblioteken, it bedrach fan koade, kommunikaasje mei ekstra boarnen (deselde databases of autentikaasjeservers). Sûnt de ûntwikkelder dizze fariabelen kontrolearret, kin hy opstarttiid ferminderje. Mar oan 'e oare kant kin de ûntwikkelder de opstarttiid fan' e kontener net kontrolearje - it hinget allegear ôf fan 'e provider.
In kâlde start kin feroarje yn in waarm start as in funksje opnij brûkt in kontener lansearre troch in foarige evenemint. Dizze situaasje sil ûntstean yn trije gefallen:
- as kliïnten de tsjinst faak brûke en it oantal oproppen nei de funksje nimt ta;
- as de provider, platfoarm of ramt jo kinne guon konteners hieltyd rinnende hâlde;
- as de ûntwikkelder rint funksjes op in timer (sizze elke 3 minuten).
Foar in protte applikaasjes is in kâlde start gjin probleem. Hjir moatte jo bouwe op it type en taken fan 'e tsjinst. In startfertraging fan in sekonde is net altyd kritysk foar in saaklike applikaasje, mar it kin kritysk wurde foar medyske tsjinsten. Yn dit gefal sil de serverleaze oanpak wierskynlik net mear geskikt wêze.
It folgjende neidiel fan Serverless is it koarte libben fan in funksje (time-out wêryn't de funksje útfierd wurde moat).
Mar, as jo moatte wurkje mei lang libbene taken, kinne jo brûke in hybride arsjitektuer - kombinearje Serverless mei in oare technology.
Net alle systemen kinne wurkje mei it Serverless-skema.
Guon applikaasjes sille noch gegevens en steat opslaan by útfiering. Guon arsjitektuer sille monolithysk bliuwe en guon funksjes sille lang libje. Serverless is lykwols (lykas wolktechnologyen en dan konteners), in technology mei in geweldige takomst.
Yn dizze sfear wol ik soepel oergean nei it probleem fan it brûken fan de Serverless-oanpak.
Fan 'e applikaasje kant
Foar 2018, it persintaazje Serverless gebrûk . Under de bedriuwen dy't de technology al yn har tsjinsten hawwe ymplementearre binne sokke merkgiganten lykas Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Tagelyk moatte jo begripe dat Serverless gjin panacea is, mar in ark foar it oplossen fan in bepaald oanbod fan problemen:
- Ferminderje boarne downtime. D'r is gjin ferlet om konstant in firtuele masine te hâlden foar tsjinsten dy't in pear oproppen hawwe.
- Ferwurkje gegevens op 'e flecht. Ofbyldings komprimearje, eftergrûnen útknipe, fideokodearring feroarje, wurkje mei IoT-sensors, wiskundige operaasjes útfiere.
- "Lijm" oare tsjinsten tegearre. Git repository mei ynterne programma's, chat bot yn Slack mei Jira en kalinder.
- Balansearje de lading. Litte wy hjir in tichterby sjen.
Litte wy sizze dat d'r in tsjinst is dy't 50 minsken lûkt. Dêrûnder is d'r in firtuele masine mei swakke hardware. Fan tiid ta tiid nimt de lading op 'e tsjinst signifikant ta. Dan kin swakke hardware net oan.
Jo kinne opnimme in balancer yn it systeem dat sil fersprieden de lading, sizze, oer trije firtuele masines. Op dit stadium kinne wy de lading net krekt foarsizze, dus hâlde wy in bepaalde hoemannichte boarnen "yn reserve." En wy betelje tefolle foar downtime.
Yn sa'n situaasje kinne wy it systeem optimalisearje troch in hybride oanpak: wy litte ien firtuele masine efter de load balancer en sette in keppeling nei it Serverless Endpoint mei funksjes. As de lading boppe de drompel komt, lanseart de balancer funksje-eksimplaren dy't in diel fan 'e fersykferwurking oernimme.
Sa kin Serverless brûkt wurde wêr't it nedich is om in grut oantal oanfragen net te faak, mar yntinsyf te ferwurkjen. Yn dit gefal is it útfieren fan ferskate funksjes foar 15 minuten rendabeler dan it behâld fan in firtuele masine of server de hiele tiid.
Mei alle foardielen fan serverless computing, foardat ymplemintaasje, moatte jo earst de applikaasje logika evaluearje en begripe hokker problemen Serverless kin oplosse yn in bepaald gefal.
Serverless en Selectel
By Selectel binne wy al fia ús kontrôlepaniel. No bouwe wy ús eigen FaaS-platfoarm. Wy wolle dat ûntwikkelders har problemen kinne oplosse mei Serverless fia in handige, fleksibele interface.
As jo ideeën hawwe oer wat it ideale FaaS-platfoarm moat wêze en hoe't jo Serverless wolle brûke yn jo projekten, diel se dan yn 'e opmerkingen. Wy sille rekken hâlde mei jo winsken by it ûntwikkeljen fan it platfoarm.
Materialen brûkt yn it artikel:
Boarne: www.habr.com