Nid yw Serverless yn ymwneud ag absenoldeb corfforol gweinyddion. Nid yw hyn yn lladdwr cynhwysydd nac yn duedd pasio. Mae hwn yn ddull newydd o adeiladu systemau yn y cwmwl. Yn yr erthygl heddiw byddwn yn cyffwrdd â phensaernïaeth cymwysiadau Serverless, gadewch i ni weld pa rôl y mae darparwr gwasanaeth Serverless a phrosiectau ffynhonnell agored yn ei chwarae. Yn olaf, gadewch i ni siarad am y materion o ddefnyddio Serverless.
Rwyf am ysgrifennu rhan gweinydd o gais (neu hyd yn oed siop ar-lein). Gallai hyn fod yn sgwrs, yn wasanaeth cyhoeddi cynnwys, neu'n gydbwysydd llwyth. Mewn unrhyw achos, bydd llawer o gur pen: bydd yn rhaid i chi baratoi'r seilwaith, pennu dibyniaethau'r cais, a meddwl am y system weithredu gwesteiwr. Yna bydd angen i chi ddiweddaru cydrannau bach nad ydynt yn effeithio ar weithrediad gweddill y monolith. Wel, gadewch inni beidio ag anghofio am raddio dan lwyth.
Beth os cymerwn gynwysyddion byrhoedlog, lle mae'r dibyniaethau gofynnol eisoes wedi'u gosod ymlaen llaw, a bod y cynwysyddion eu hunain wedi'u hynysu oddi wrth ei gilydd ac oddi wrth yr OS gwesteiwr? Byddwn yn rhannu'r monolith yn ficrowasanaethau, a gellir diweddaru a graddio pob un ohonynt yn annibynnol ar y lleill. Trwy osod y cod mewn cynhwysydd o'r fath, gallaf ei redeg ar unrhyw seilwaith. Eisoes yn well.
Beth os nad ydych chi am ffurfweddu cynwysyddion? Dydw i ddim eisiau meddwl am raddio'r cais. Nid wyf am dalu am gynwysyddion rhedeg segur pan fo'r llwyth ar y gwasanaeth yn fach iawn. Rwyf am ysgrifennu cod. Canolbwyntiwch ar resymeg busnes a dod â chynhyrchion i'r farchnad ar gyflymder golau.
Arweiniodd meddyliau o'r fath fi at gyfrifiadura di-weinydd. Serverless yn yr achos hwn yn golygu nid absenoldeb corfforol gweinyddion, ond absenoldeb cur pen rheoli seilwaith.
Y syniad yw bod rhesymeg cymhwyso yn cael ei dorri i lawr yn swyddogaethau annibynnol. Mae ganddyn nhw strwythur digwyddiadau. Mae pob swyddogaeth yn perfformio un “microtasg”. Y cyfan sydd ei angen gan y datblygwr yw llwytho'r swyddogaethau i'r consol a ddarperir gan ddarparwr y cwmwl a'u cydberthyn â ffynonellau digwyddiadau. Bydd y cod yn cael ei weithredu ar gais mewn cynhwysydd a baratowyd yn awtomatig, a byddaf yn talu am yr amser gweithredu yn unig.
Gawn ni weld sut olwg fydd ar y broses datblygu ceisiadau nawr.
O ochr y datblygwr
Yn gynharach fe ddechreuon ni siarad am gais am siop ar-lein. Yn y dull traddodiadol, mae prif resymeg y system yn cael ei berfformio gan gymhwysiad monolithig. Ac mae'r gweinydd gyda'r cais yn rhedeg yn gyson, hyd yn oed os nad oes llwyth.
Er mwyn symud i ddi-weinydd, rydym yn torri'r rhaglen yn ficrodasgau. Rydym yn ysgrifennu ein swyddogaeth ein hunain ar gyfer pob un ohonynt. Mae'r swyddogaethau'n annibynnol ar ei gilydd ac nid ydynt yn storio gwybodaeth am y wladwriaeth (di-wladwriaeth). Gallant hyd yn oed gael eu hysgrifennu mewn gwahanol ieithoedd. Os bydd un ohonynt yn “cwympo”, ni fydd y cais cyfan yn dod i ben. Bydd pensaernïaeth y cais yn edrych fel hyn:
Mae'r rhaniad yn swyddogaethau yn Serverless yn debyg i weithio gyda microwasanaethau. Ond gall microwasanaeth gyflawni sawl tasg, a dylai swyddogaeth gyflawni un yn ddelfrydol. Gadewch i ni ddychmygu mai'r dasg yw casglu ystadegau a'u harddangos ar gais y defnyddiwr. Yn y dull microwasanaeth, cyflawnir tasg gan un gwasanaeth gyda dau bwynt mynediad: ysgrifennu a darllen. Mewn cyfrifiadura di-weinydd, bydd y rhain yn ddwy swyddogaeth wahanol nad ydynt yn gysylltiedig â'i gilydd. Mae'r datblygwr yn arbed adnoddau cyfrifiadurol os, er enghraifft, mae ystadegau'n cael eu diweddaru'n amlach nag y maent yn cael eu llwytho i lawr.
Rhaid cyflawni swyddogaethau di-weinydd mewn cyfnod byr o amser (goramser), a bennir gan y darparwr gwasanaeth. Er enghraifft, ar gyfer AWS y terfyn amser yw 15 munud. Mae hyn yn golygu y bydd yn rhaid newid swyddogaethau hirhoedlog i weddu i'r gofynion - dyma sy'n gwahaniaethu Serverless oddi wrth dechnolegau poblogaidd eraill heddiw (cynwysyddion a Platfform fel Gwasanaeth).
Rydym yn neilltuo digwyddiad i bob digwyddiad. Mae digwyddiad yn sbardun i weithred:
Digwyddiad
Y weithred y mae'r swyddogaeth yn ei chyflawni
Mae delwedd cynnyrch wedi'i huwchlwytho i'r gadwrfa.
Cywasgwch y ddelwedd a'i huwchlwytho i gyfeiriadur
Mae cyfeiriad y storfa ffisegol wedi'i ddiweddaru yn y gronfa ddata
Llwythwch leoliad newydd i fapiau
Mae'r cleient yn talu am y nwyddau
Dechrau prosesu taliadau
Gall digwyddiadau fod yn geisiadau HTTP, yn ffrydio data, yn giwiau neges, ac yn y blaen. Newidiadau neu ddigwyddiadau data yw ffynonellau digwyddiadau. Yn ogystal, gall swyddogaethau gael eu sbarduno gan amserydd.
Gweithiwyd y bensaernïaeth allan, a bu bron i'r cymhwysiad fynd yn ddi-weinydd. Nesaf rydym yn mynd at y darparwr gwasanaeth.
O ochr y darparwr
Yn nodweddiadol, mae cyfrifiadura di-weinydd yn cael ei gynnig gan ddarparwyr gwasanaethau cwmwl. Fe'u gelwir yn wahanol: Swyddogaethau Azure, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Byddwn yn defnyddio’r gwasanaeth trwy gonsol neu gyfrif personol y darparwr. Gellir lawrlwytho cod swyddogaeth mewn un o'r ffyrdd canlynol:
- ysgrifennu cod mewn golygyddion adeiledig trwy'r consol gwe,
- lawrlwythwch yr archif gyda'r cod,
- gweithio gyda storfeydd git cyhoeddus neu breifat.
Yma rydym yn sefydlu'r digwyddiadau sy'n galw'r swyddogaeth. Gall y setiau o ddigwyddiadau amrywio ar gyfer darparwyr gwahanol.
Adeiladodd ac awtomeiddiodd y darparwr y system Swyddogaeth fel Gwasanaeth (FaaS) ar ei seilwaith:
- Mae'r cod swyddogaeth yn cael ei storio ar ochr y darparwr yn y pen draw.
- Pan fydd digwyddiad yn digwydd, mae cynwysyddion ag amgylchedd parod yn cael eu gosod yn awtomatig ar y gweinydd. Mae gan bob achos swyddogaeth ei gynhwysydd ynysig ei hun.
- O'r storfa, anfonir y swyddogaeth i'r cynhwysydd, ei gyfrifo, a dychwelyd y canlyniad.
- Mae nifer y digwyddiadau cyfochrog yn tyfu - mae nifer y cynwysyddion yn tyfu. Mae'r system yn graddio'n awtomatig. Os na fydd defnyddwyr yn cyrchu'r swyddogaeth, bydd yn anactif.
- Mae'r darparwr yn gosod yr amser segur ar gyfer cynwysyddion - os nad yw swyddogaethau yn ymddangos yn y cynhwysydd yn ystod yr amser hwn, caiff ei ddinistrio.
Fel hyn rydym yn cael Serverless allan o'r bocs. Byddwn yn talu am y gwasanaeth gan ddefnyddio’r model talu-wrth-fynd a dim ond ar gyfer y swyddogaethau hynny a ddefnyddir, a dim ond ar gyfer yr amser pan gawsant eu defnyddio.
Er mwyn cyflwyno datblygwyr i'r gwasanaeth, mae darparwyr yn cynnig hyd at 12 mis o brofion am ddim, ond yn cyfyngu ar gyfanswm yr amser cyfrifo, nifer y ceisiadau y mis, arian neu ddefnydd pŵer.
Prif fantais gweithio gyda darparwr yw'r gallu i beidio â phoeni am seilwaith (gweinyddwyr, peiriannau rhithwir, cynwysyddion). O'i ran ef, gall y darparwr roi FaaS ar waith gan ddefnyddio ei ddatblygiadau ei hun a defnyddio offer ffynhonnell agored. Gadewch i ni siarad amdanynt ymhellach.
O'r ochr ffynhonnell agored
Mae'r gymuned ffynhonnell agored wedi bod yn gweithio'n weithredol ar offer Serverless am yr ychydig flynyddoedd diwethaf. Mae chwaraewyr mwyaf y farchnad hefyd yn cyfrannu at ddatblygiad llwyfannau di-weinydd:
- google yn cynnig ei offeryn ffynhonnell agored i ddatblygwyr - . Cymerodd IBM, RedHat, Pivotal a SAP ran yn ei ddatblygiad;
- IBM gweithio ar blatfform Serverless , a ddaeth wedyn yn brosiect Sefydliad Apache;
- microsoft yn rhannol agor y cod platfform .
Mae datblygiadau hefyd ar y gweill i gyfeiriad fframweithiau di-weinydd. и yn cael ei ddefnyddio y tu mewn i glystyrau Kubernetes a baratowyd ymlaen llaw, yn gweithio gyda Kubernetes a Docker Swarm. Mae'r fframwaith yn gweithredu fel math o reolwr - ar gais, mae'n paratoi amgylchedd amser rhedeg y tu mewn i'r clwstwr, yna'n lansio swyddogaeth yno.
Mae fframweithiau'n gadael lle i ffurfweddu'r offeryn i weddu i'ch anghenion. Felly, yn Kubeless, gall datblygwr ffurfweddu'r terfyn amser gweithredu swyddogaeth (y gwerth rhagosodedig yw 180 eiliad). Mae ymholltiad, mewn ymgais i ddatrys y broblem cychwyn oer, yn awgrymu cadw rhai cynwysyddion yn rhedeg drwy'r amser (er bod hyn yn golygu costau amser segur adnoddau). Ac mae OpenFaaS yn cynnig set o sbardunau ar gyfer pob chwaeth a lliw: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs ac eraill.
Gellir dod o hyd i gyfarwyddiadau ar gyfer dechrau arni yn nogfennaeth swyddogol y fframweithiau. Mae gweithio gyda nhw yn gofyn am ychydig mwy o sgiliau nag wrth weithio gyda darparwr - dyma o leiaf y gallu i lansio clwstwr Kubernetes trwy'r CLI. Ar y mwyaf, cynhwyswch offer ffynhonnell agored eraill (er enghraifft, rheolwr ciw Kafka).
Waeth sut rydym yn gweithio gyda Serverless - trwy ddarparwr neu ddefnyddio ffynhonnell agored, byddwn yn derbyn nifer o fanteision ac anfanteision y dull Serverless.
O safbwynt manteision ac anfanteision
Mae Serverless yn datblygu syniadau seilwaith cynhwysydd a dull microwasanaeth, lle gall timau weithio mewn modd amlieithog heb fod yn gysylltiedig ag un platfform. Mae adeiladu system yn cael ei symleiddio ac mae gwallau'n haws eu cywiro. Mae pensaernïaeth microservice yn caniatáu ichi ychwanegu ymarferoldeb newydd i'r system yn llawer cyflymach nag yn achos cymhwysiad monolithig.
Mae di-weinydd yn lleihau amser datblygu hyd yn oed ymhellach, caniatáu i'r datblygwr ganolbwyntio ar resymeg busnes a chodio'r cais yn unig. O ganlyniad, mae'r amser i farchnata ar gyfer datblygiadau yn cael ei leihau.
Fel bonws, rydym yn cael graddio awtomatig ar gyfer llwyth, ac rydym yn talu am yr adnoddau a ddefnyddir yn unig a dim ond ar yr adeg y cânt eu defnyddio.
Fel unrhyw dechnoleg, mae gan Serverless anfanteision.
Er enghraifft, efallai mai anfantais o'r fath yw'r amser cychwyn oer (ar gyfartaledd hyd at 1 eiliad ar gyfer ieithoedd fel JavaScript, Python, Go, Java, Ruby).
Ar y naill law, mewn gwirionedd, mae'r amser cychwyn oer yn dibynnu ar lawer o newidynnau: yr iaith y mae'r swyddogaeth wedi'i hysgrifennu ynddi, nifer y llyfrgelloedd, faint o god, cyfathrebu ag adnoddau ychwanegol (yr un cronfeydd data neu weinyddion dilysu). Gan fod y datblygwr yn rheoli'r newidynnau hyn, gall leihau'r amser cychwyn. Ond ar y llaw arall, ni all y datblygwr reoli amser cychwyn y cynhwysydd - mae'r cyfan yn dibynnu ar y darparwr.
Gall cychwyn oer droi'n ddechrau cynnes pan fydd swyddogaeth yn ailddefnyddio cynhwysydd a lansiwyd gan ddigwyddiad blaenorol. Bydd y sefyllfa hon yn codi mewn tri achos:
- os yw cleientiaid yn defnyddio'r gwasanaeth yn aml a bod nifer y galwadau i'r swyddogaeth yn cynyddu;
- os yw'r darparwr, platfform neu fframwaith yn caniatáu ichi gadw rhai cynwysyddion i redeg drwy'r amser;
- os yw'r datblygwr yn rhedeg swyddogaethau ar amserydd (dyweder bob 3 munud).
Ar gyfer llawer o geisiadau, nid yw cychwyn oer yn broblem. Yma mae angen i chi adeiladu ar y math a thasgau'r gwasanaeth. Nid yw oedi cychwynnol o eiliad bob amser yn hanfodol ar gyfer cais busnes, ond gall ddod yn hollbwysig i wasanaethau meddygol. Yn yr achos hwn, mae'n debyg na fydd y dull di-weinydd yn addas mwyach.
Anfantais nesaf Serverless yw oes fer swyddogaeth (amser terfyn pryd y mae'n rhaid cyflawni'r swyddogaeth).
Ond, os oes rhaid i chi weithio gyda thasgau hirhoedlog, gallwch ddefnyddio pensaernïaeth hybrid - cyfuno Serverless â thechnoleg arall.
Ni fydd pob system yn gallu gweithio gan ddefnyddio'r cynllun Serverless.
Bydd rhai cymwysiadau yn dal i storio data a chyflwr yn ystod gweithredu. Bydd rhai pensaernïaeth yn aros yn fonolithig a bydd rhai nodweddion yn hirhoedlog. Fodd bynnag (fel technolegau cwmwl ac yna cynwysyddion), mae Serverless yn dechnoleg sydd â dyfodol gwych.
Yn hyn o beth, hoffwn symud ymlaen yn ddidrafferth at y mater o ddefnyddio'r dull Serverless.
O ochr y cais
Ar gyfer 2018, canran y defnydd di-weinydd . Ymhlith y cwmnïau sydd eisoes wedi gweithredu'r dechnoleg yn eu gwasanaethau mae cewri'r farchnad fel Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Ar yr un pryd, mae angen i chi ddeall nad yw Serverless yn ateb i bob problem, ond yn offeryn ar gyfer datrys ystod benodol o broblemau:
- Lleihau amser segur adnoddau. Nid oes angen cadw peiriant rhithwir yn gyson ar gyfer gwasanaethau sydd ag ychydig o alwadau.
- Prosesu data ar y hedfan. Cywasgu lluniau, torri cefndiroedd allan, newid amgodio fideo, gweithio gyda synwyryddion IoT, perfformio gweithrediadau mathemategol.
- “Gludwch” gwasanaethau eraill at ei gilydd. Ystorfa Git gyda rhaglenni mewnol, bot sgwrsio yn Slack gyda Jira a calendr.
- Cydbwyso'r llwyth. Gadewch i ni edrych yn agosach yma.
Gadewch i ni ddweud bod yna wasanaeth sy'n denu 50 o bobl. O dan iddo mae peiriant rhithwir gyda chaledwedd gwan. O bryd i'w gilydd, mae'r llwyth ar y gwasanaeth yn cynyddu'n sylweddol. Yna ni all caledwedd gwan ymdopi.
Gallwch gynnwys balancer yn y system a fydd yn dosbarthu'r llwyth, dyweder, ar draws tri pheiriant rhithwir. Ar hyn o bryd, ni allwn ragweld y llwyth yn gywir, felly rydym yn cadw rhywfaint o adnoddau yn rhedeg “wrth gefn.” Ac rydym yn gordalu am amser segur.
Mewn sefyllfa o'r fath, gallwn optimeiddio'r system trwy ddull hybrid: rydym yn gadael un peiriant rhithwir y tu ôl i'r cydbwysedd llwyth ac yn rhoi dolen i'r Endpoint Serverless gyda swyddogaethau. Os yw'r llwyth yn fwy na'r trothwy, mae'r balansydd yn lansio achosion swyddogaeth sy'n cymryd drosodd rhan o'r prosesu cais.
Felly, gellir defnyddio Serverless lle mae angen prosesu nifer fawr o geisiadau nid yn rhy aml, ond yn ddwys. Yn yr achos hwn, mae rhedeg sawl swyddogaeth am 15 munud yn fwy proffidiol na chynnal peiriant rhithwir neu weinydd trwy'r amser.
Gyda holl fanteision cyfrifiadura di-weinydd, cyn gweithredu, dylech werthuso rhesymeg y cais yn gyntaf a deall pa broblemau y gall Serverless eu datrys mewn achos penodol.
Heb weinydd a Selectel
Yn Selectel yr ydym yn barod trwy ein panel rheoli. Nawr rydym yn adeiladu ein platfform FaaS ein hunain. Rydym am i ddatblygwyr allu datrys eu problemau gan ddefnyddio Serverless trwy ryngwyneb cyfleus, hyblyg.
Os oes gennych chi syniadau ar beth ddylai'r platfform FaaS delfrydol fod a sut rydych chi am ddefnyddio Serverless yn eich prosiectau, rhannwch nhw yn y sylwadau. Byddwn yn cymryd eich dymuniadau i ystyriaeth wrth ddatblygu'r platfform.
Deunyddiau a ddefnyddir yn yr erthygl:
Ffynhonnell: hab.com