Bedienerloos gaan nie oor die fisiese afwesigheid van bedieners nie. Dit is nie 'n houermoordenaar of 'n verbygaande neiging nie. Dit is 'n nuwe benadering om stelsels in die wolk te bou. In vandag se artikel sal ons die argitektuur van bedienerlose toepassings aanraak, kom ons kyk watter rol die bedienerlose diensverskaffer en oopbronprojekte speel. Laastens, kom ons praat oor die kwessies van die gebruik van Serverless.
Ek wil 'n bedienerdeel van 'n toepassing (of selfs 'n aanlynwinkel) skryf. Dit kan 'n klets, 'n inhoudpubliseringsdiens of 'n lasbalanseerder wees. In elk geval sal daar baie kopsere wees: jy sal die infrastruktuur moet voorberei, die toepassingsafhanklikhede moet bepaal en oor die gasheerbedryfstelsel moet dink. Dan sal jy klein komponente moet opdateer wat nie die werking van die res van die monoliet beïnvloed nie. Wel, laat ons nie vergeet van skaal onder vrag nie.
Wat as ons kortstondige houers neem, waarin die vereiste afhanklikhede reeds vooraf geïnstalleer is, en die houers self van mekaar en van die gasheer-bedryfstelsel geïsoleer is? Ons sal die monoliet in mikrodienste verdeel, wat elkeen onafhanklik van die ander opgedateer en geskaal kan word. Deur die kode in so 'n houer te plaas, kan ek dit op enige infrastruktuur laat loop. Reeds beter.
Wat as jy nie houers wil opstel nie? Ek wil nie daaraan dink om die toepassing te skaal nie. Ek wil nie vir leeglopende houers betaal as die las op die diens minimaal is nie. Ek wil kode skryf. Fokus op besigheidslogika en bring produkte teen die spoed van lig na die mark.
Sulke gedagtes het my gelei tot bedienerlose rekenaars. Bedienerloos in hierdie geval beteken nie die fisiese afwesigheid van bedieners nie, maar die afwesigheid van hoofpyne vir infrastruktuurbestuur.
Die idee is dat toepassingslogika in onafhanklike funksies afgebreek word. Hulle het 'n gebeurtenisstruktuur. Elke funksie voer een "mikrotaak" uit. Al wat van die ontwikkelaar vereis word, is om die funksies in die konsole te laai wat deur die wolkverskaffer verskaf word en dit met gebeurtenisbronne te korreleer. Die kode sal op aanvraag in 'n outomaties voorbereide houer uitgevoer word, en ek sal slegs vir die uitvoeringstyd betaal.
Kom ons kyk hoe die toepassingsontwikkelingsproses nou sal lyk.
Van die ontwikkelaar se kant af
Ons het vroeër begin praat oor 'n toepassing vir 'n aanlynwinkel. In die tradisionele benadering word die hooflogika van die stelsel uitgevoer deur 'n monolitiese toepassing. En die bediener met die toepassing loop voortdurend, selfs al is daar geen vrag nie.
Om na bedienerloos te beweeg, verdeel ons die toepassing in mikrotake. Ons skryf ons eie funksie vir elkeen van hulle. Die funksies is onafhanklik van mekaar en stoor nie staatsinligting (staatloos) nie. Hulle kan selfs in verskillende tale geskryf word. As een van hulle "val", sal die hele toepassing nie stop nie. Die toepassingsargitektuur sal soos volg lyk:
Die verdeling in funksies in Serverless is soortgelyk aan om met mikrodienste te werk. Maar 'n mikrodiens kan veelvuldige take verrig, terwyl 'n funksie ideaal een taak moet verrig. Kom ons stel ons voor dat die taak is om statistieke in te samel en dit op versoek van die gebruiker te vertoon. In die mikrodiensbenadering word die taak uitgevoer deur een diens met twee toegangspunte: vir skryf en vir lees. In bedienerlose rekenaars sal dit twee verskillende funksies wees wat nie met mekaar verband hou nie. Die ontwikkelaar spaar rekenaarhulpbronne as statistieke byvoorbeeld meer gereeld opgedateer word as wat dit opgelaai word.
Bedienerlose funksies moet in 'n kort tydperk (time-out) uitgevoer word, wat deur die diensverskaffer bepaal word. Byvoorbeeld, vir AWS is die time-out 15 minute. Dit beteken dat langlewende funksies verander sal moet word om aan die vereistes te voldoen - dit is wat Serverless onderskei van ander gewilde tegnologieë vandag (houers en Platform as 'n Diens).
Ons ken 'n gebeurtenis aan elke funksie toe. 'n Gebeurtenis is 'n sneller vir 'n handeling:
gebeurtenis
Die aksie wat die funksie uitvoer
'n Produkprent is na die bewaarplek opgelaai.
Druk die prent saam en laai dit op na 'n gids
Die fisiese winkeladres is in die databasis opgedateer
Laai 'n nuwe ligging in kaarte
Die kliënt betaal vir die goedere
Begin betalingsverwerking
Gebeurtenisse kan HTTP-versoeke, stroomdata, boodskaprye, ensovoorts wees. Gebeurtenisbronne is veranderinge of voorkoms van data. Daarbenewens kan funksies deur 'n timer geaktiveer word.
Die argitektuur is uitgewerk, en die toepassing het amper bedienerloos geword. Volgende gaan ons na die diensverskaffer.
Van die verskaffer se kant af
Tipies word bedienerlose rekenaars deur wolkdiensverskaffers aangebied. Hulle word anders genoem: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Ons sal die diens deur die verskaffer se konsole of persoonlike rekening gebruik. Funksiekode kan op een van die volgende maniere afgelaai word:
- skryf kode in ingeboude redigeerders via die webkonsole,
- laai die argief af met die kode,
- werk met publieke of private git-bewaarplekke.
Hier stel ons die gebeure op wat die funksie oproep. Die stelle gebeurtenisse kan verskil vir verskillende verskaffers.
Die verskaffer het die Function as a Service (FaaS)-stelsel op sy infrastruktuur gebou en geoutomatiseer:
- Die funksiekode beland in die stoor aan die verskafferkant.
- Wanneer 'n gebeurtenis plaasvind, word houers met 'n voorbereide omgewing outomaties op die bediener ontplooi. Elke funksie-instansie het sy eie geïsoleerde houer.
- Van die stoor af word die funksie na die houer gestuur, bereken, en gee die resultaat terug.
- Die aantal parallelle gebeurtenisse groei - die aantal houers groei. Die stelsel skaal outomaties. As gebruikers nie toegang tot die funksie het nie, sal dit onaktief wees.
- Die verskaffer stel die ledige tyd vir houers - as gedurende hierdie tyd funksies nie in die houer verskyn nie, word dit vernietig.
Op hierdie manier kry ons Serverless uit die boks. Ons sal vir die diens betaal deur die betaal-soos-jy-gaan-model te gebruik en slegs vir daardie funksies wat gebruik word, en slegs vir die tyd toe hulle gebruik is.
Om ontwikkelaars aan die diens bekend te stel, bied verskaffers tot 12 maande se gratis toetsing aan, maar beperk die totale berekeningstyd, aantal versoeke per maand, fondse of kragverbruik.
Die grootste voordeel van werk met 'n verskaffer is die vermoë om nie bekommerd te wees oor infrastruktuur (bedieners, virtuele masjiene, houers). Op sy beurt kan die verskaffer FaaS implementeer deur sy eie ontwikkelings sowel as oopbronnutsmiddels te gebruik. Kom ons praat verder oor hulle.
Van die oopbronkant
Die oopbrongemeenskap werk die afgelope paar jaar aktief aan bedienerlose nutsgoed. Die grootste markspelers dra ook by tot die ontwikkeling van bedienerlose platforms:
- Google bied ontwikkelaars sy oopbron-instrument aan - . IBM, RedHat, Pivotal en SAP het aan die ontwikkeling daarvan deelgeneem;
- IBM op 'n bedienerlose platform gewerk , wat toe 'n projek van die Apache-stigting geword het;
- Microsoft het die platformkode gedeeltelik oopgemaak .
Ontwikkelings is ook aan die gang in die rigting van bedienerlose raamwerke. и ontplooi binne vooraf voorbereide Kubernetes-klusters, werk met beide Kubernetes en Docker Swarm. Die raamwerk dien as 'n soort kontroleerder - op versoek berei dit 'n runtime-omgewing binne die cluster voor, en begin dan 'n funksie daar.
Raamwerke laat ruimte vir die opstel van die instrument om by jou behoeftes te pas. Dus, in Kubeless, kan 'n ontwikkelaar die funksie-uitvoeringstydperk instel (die verstekwaarde is 180 sekondes). Fission, in 'n poging om die koue begin probleem op te los, stel voor dat sommige houers heeltyd aan die gang hou (hoewel dit hulpbron-stilstandkoste meebring). En OpenFaaS bied 'n stel snellers vir elke smaak en kleur: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT's en ander.
Instruksies om te begin kan gevind word in die amptelike dokumentasie van die raamwerke. Om met hulle te werk, vereis 'n bietjie meer vaardighede as wanneer jy met 'n verskaffer werk - dit is ten minste die vermoë om 'n Kubernetes-kluster via die CLI te begin. Sluit hoogstens ander oopbronnutsgoed in (byvoorbeeld die Kafka-toubestuurder).
Ongeag hoe ons met Serverless werk - deur 'n verskaffer of deur oopbron te gebruik, sal ons 'n aantal voordele en nadele van die Serverless-benadering ontvang.
Uit die oogpunt van voordele en nadele
Serverless ontwikkel die idees van 'n houerinfrastruktuur en 'n mikrodiensbenadering, waarin spanne in 'n veeltalige modus kan werk sonder om aan een platform gekoppel te wees. Die bou van 'n stelsel is vereenvoudig en foute is makliker om reg te stel. Met mikrodiensargitektuur kan u baie vinniger nuwe funksionaliteit by die stelsel voeg as in die geval van 'n monolitiese toepassing.
Bedienerloos verminder ontwikkelingstyd nog verder, wat die ontwikkelaar toelaat om uitsluitlik op die toepassing se besigheidslogika en kodering te fokus. Gevolglik word die tyd tot mark vir ontwikkelings verminder.
As 'n bonus kry ons outomatiese skaal vir vrag, en ons betaal slegs vir die hulpbronne wat gebruik word en slegs op die tyd wanneer dit gebruik word.
Soos enige tegnologie, het Serverless nadele.
So 'n nadeel kan byvoorbeeld die koue begintyd wees (gemiddeld tot 1 sekonde vir tale soos JavaScript, Python, Go, Java, Ruby).
Aan die een kant hang die koue begintyd in werklikheid af van baie veranderlikes: die taal waarin die funksie geskryf is, die aantal biblioteke, die hoeveelheid kode, kommunikasie met bykomende hulpbronne (dieselfde databasisse of verifikasiebedieners). Aangesien die ontwikkelaar hierdie veranderlikes beheer, kan hy opstarttyd verminder. Maar aan die ander kant kan die ontwikkelaar nie die opstarttyd van die houer beheer nie – dit hang alles af van die verskaffer.
'n Koue begin kan in 'n warm begin verander wanneer 'n funksie 'n houer wat deur 'n vorige gebeurtenis gelanseer is, hergebruik. Hierdie situasie sal in drie gevalle ontstaan:
- indien kliënte gereeld die diens gebruik en die aantal oproepe na die funksie toeneem;
- as die verskaffer, platform of raamwerk jou toelaat om sommige houers heeltyd aan die gang te hou;
- as die ontwikkelaar funksies op 'n timer laat loop (sê elke 3 minute).
Vir baie toepassings is 'n koue begin nie 'n probleem nie. Hier moet jy voortbou op die tipe en take van die diens. 'n Beginvertraging van 'n sekonde is nie altyd van kritieke belang vir 'n besigheidstoepassing nie, maar dit kan krities raak vir mediese dienste. In hierdie geval sal die bedienerlose benadering waarskynlik nie meer geskik wees nie.
Die volgende nadeel van Serverless is die kort leeftyd van 'n funksie (time-out waartydens die funksie uitgevoer moet word).
Maar as jy met langdurige take moet werk, kan jy 'n hibriede argitektuur gebruik - kombineer Serverless met 'n ander tegnologie.
Nie alle stelsels sal met die bedienerlose skema kan werk nie.
Sommige toepassings sal steeds data en toestand stoor tydens uitvoering. Sommige argitekture sal monolities bly en sommige kenmerke sal lank lewe. Serverless is egter (soos wolktegnologieë en dan houers), 'n tegnologie met 'n groot toekoms.
In hierdie trant wil ek glad oorgaan na die kwessie van die gebruik van die bedienerlose benadering.
Van die toepassingskant af
Vir 2018, die persentasie van bedienerlose gebruik . Onder die maatskappye wat reeds die tegnologie in hul dienste geïmplementeer het, is markreuse soos Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Terselfdertyd moet u verstaan dat Serverless nie 'n wondermiddel is nie, maar 'n hulpmiddel om 'n sekere reeks probleme op te los:
- Verminder hulpbronstilstand. Dit is nie nodig om voortdurend 'n virtuele masjien te hou vir dienste wat min oproepe het nie.
- Verwerk data op die vlieg. Druk prente saam, knip agtergronde uit, verander video-kodering, werk met IoT-sensors, voer wiskundige bewerkings uit.
- "Gom" ander dienste aanmekaar. Git-bewaarplek met interne programme, kletsbot in Slack met Jira en kalender.
- Balanseer die vrag. Kom ons kyk hier van nader.
Kom ons sê daar is 'n diens wat 50 mense lok. Onder dit is daar 'n virtuele masjien met swak hardeware. Van tyd tot tyd neem die las op die diens aansienlik toe. Dan kan swak hardeware nie klaarkom nie.
U kan 'n balanseerder in die stelsel insluit wat die vrag, byvoorbeeld, oor drie virtuele masjiene sal versprei. Op hierdie stadium kan ons nie die vrag akkuraat voorspel nie, so ons hou 'n sekere hoeveelheid hulpbronne "in reserwe" aan die gang. En ons betaal te veel vir stilstand.
In so 'n situasie kan ons die stelsel optimaliseer deur 'n hibriede benadering: ons laat een virtuele masjien agter die lasbalanseerder en plaas 'n skakel na die bedienerlose eindpunt met funksies. As die vrag die drempel oorskry, begin die balanseerder funksie-instansies wat 'n deel van die versoekverwerking oorneem.
Serverless kan dus gebruik word waar dit nodig is om 'n groot aantal versoeke nie te gereeld nie, maar intensief te verwerk. In hierdie geval is dit meer winsgewend om verskeie funksies vir 15 minute te laat loop as om heeltyd 'n virtuele masjien of bediener in stand te hou.
Met al die voordele van bedienerlose rekenaars, voor implementering, moet jy eers die toepassingslogika evalueer en verstaan watter probleme Serverless in 'n spesifieke geval kan oplos.
Bedienerloos en Selectel
By Selectel is ons reeds via ons beheerpaneel. Nou bou ons ons eie FaaS-platform. Ons wil hê ontwikkelaars moet in staat wees om hul probleme op te los met behulp van Serverless deur 'n gerieflike, buigsame koppelvlak.
As jy idees het oor wat die ideale FaaS-platform moet wees en hoe jy Serverless in jou projekte wil gebruik, deel dit in die kommentaar. Ons sal u wense in ag neem wanneer ons die platform ontwikkel.
Materiaal wat in die artikel gebruik word:
Bron: will.com