Serverless snýst ekki um líkamlega fjarveru netþjóna. Þetta er ekki gámamorðingi eða yfirgengileg þróun. Þetta er ný nálgun til að byggja upp kerfi í skýinu. Í greininni í dag munum við snerta arkitektúr Serverless forrita, við skulum sjá hvaða hlutverki Serverless þjónustuaðilinn og opinn uppspretta verkefni gegna. Að lokum skulum við tala um vandamálin við að nota Serverless.
Ég vil skrifa miðlarahluta af forriti (eða jafnvel netverslun). Þetta gæti verið spjall, efnisútgáfuþjónusta eða álagsjafnari. Í öllum tilvikum verður mikill höfuðverkur: þú verður að undirbúa innviðina, ákvarða háð forrita og hugsa um stýrikerfi gestgjafans. Þá þarftu að uppfæra litla íhluti sem hafa ekki áhrif á virkni restarinnar af monolithinu. Jæja, við skulum ekki gleyma mælikvarða undir álagi.
Hvað ef við tökum skammvinn gáma, þar sem nauðsynlegar ósjálfstæðir eru þegar foruppsettir og gámarnir sjálfir eru einangraðir hver frá öðrum og frá stýrikerfi gestgjafans? Við munum skipta einliðanum í örþjónustur, sem hver um sig er hægt að uppfæra og skala óháð öðrum. Með því að setja kóðann í slíkan gám get ég keyrt hann á hvaða innviði sem er. Nú þegar betri.
Hvað ef þú vilt ekki stilla gáma? Ég vil ekki hugsa um að stækka forritið. Ég vil ekki borga fyrir aðgerðalausa gáma þegar álagið á þjónustuna er í lágmarki. Ég vil skrifa kóða. Leggðu áherslu á viðskiptarökfræði og komdu með vörur á markað á ljóshraða.
Slíkar hugsanir leiddu mig til netþjónslausrar tölvuvinnslu. Serverless í þessu tilfelli þýðir ekki líkamlega fjarveru netþjóna, heldur skortur á höfuðverk í innviðastjórnun.
Hugmyndin er að umsóknarrökfræði sé sundurliðuð í sjálfstæðar aðgerðir. Þeir hafa viðburðarskipulag. Hver aðgerð framkvæmir eitt „örverk“. Allt sem þarf frá þróunaraðilanum er að hlaða aðgerðunum inn í stjórnborðið sem skýjaveitan lætur í té og tengja þær við viðburðauppsprettur. Kóðinn verður keyrður á eftirspurn í sjálfvirkt tilbúnum íláti og ég mun aðeins borga fyrir framkvæmdartímann.
Við skulum sjá hvernig umsóknarþróunarferlið mun líta út núna.
Frá hlið framkvæmdaraðila
Áðan fórum við að tala um umsókn fyrir netverslun. Í hefðbundinni nálgun er meginrökfræði kerfisins framkvæmd með einhæfri umsókn. Og þjónninn með forritinu er stöðugt í gangi, jafnvel þótt það sé ekkert álag.
Til að fara yfir í netþjónalaust skiptum við forritinu í örverkefni. Við skrifum okkar eigin aðgerð fyrir hvert þeirra. Aðgerðirnar eru óháðar hver annarri og geyma ekki ríkisupplýsingar (ríkislausar). Þeir geta jafnvel verið skrifaðir á mismunandi tungumálum. Ef einn þeirra „fellur“ hættir ekki öll umsóknin. Forritsarkitektúrinn mun líta svona út:
Skiptingin í aðgerðir í Serverless er svipuð og að vinna með örþjónustur. En örþjónusta getur framkvæmt mörg verkefni og aðgerð ætti helst að framkvæma eitt. Við skulum ímynda okkur að verkefnið sé að safna tölfræði og birta þær að beiðni notandans. Í örþjónustuaðferðinni er verkefni framkvæmt af einni þjónustu með tveimur inngangsstöðum: ritun og lestri. Í miðlaralausri tölvuvinnslu verða þetta tvær mismunandi aðgerðir sem eru ekki tengdar hvor annarri. Framkvæmdaraðilinn sparar tölvuauðlindir ef til dæmis tölfræði er uppfærð oftar en henni er hlaðið niður.
Þjónustulausar aðgerðir verða að vera keyrðar á stuttum tíma (timeout), sem er ákvarðað af þjónustuveitunni. Til dæmis, fyrir AWS er tíminn 15 mínútur. Þetta þýðir að breyta þarf langlífum aðgerðum til að henta kröfunum - þetta er það sem aðgreinir Serverless frá annarri vinsælri tækni í dag (gámar og Platform as a Service).
Við úthlutum atburði við hverja aðgerð. Atburður er kveikja að aðgerð:
Atburður
Aðgerðin sem aðgerðin framkvæmir
Vörumynd hefur verið hlaðið upp í geymsluna.
Þjappaðu myndinni saman og hlaða upp í möppu
Heimilisfang verslunarinnar hefur verið uppfært í gagnagrunninum
Hlaða nýja staðsetningu inn á kort
Viðskiptavinurinn greiðir fyrir vörurnar
Byrjaðu greiðsluvinnslu
Viðburðir geta verið HTTP beiðnir, streymigögn, skilaboðaraðir og svo framvegis. Uppsprettur atburða eru breytingar eða tilvik gagna. Að auki er hægt að kveikja á aðgerðum með tímamæli.
Arkitektúrinn var útfærður og forritið varð nánast netþjónalaust. Næst förum við til þjónustuveitunnar.
Frá hlið þjónustuveitunnar
Venjulega er netþjónalaus tölva í boði hjá skýjaþjónustuaðilum. Þeir eru kallaðir á annan hátt: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Við munum nota þjónustuna í gegnum stjórnborð þjónustuveitunnar eða persónulegan reikning. Aðgerðarkóða er hægt að hlaða niður á einn af eftirfarandi leiðum:
- skrifaðu kóða í innbyggðum ritstjórum í gegnum vefstjórnborðið,
- hlaða niður skjalasafninu með kóðanum,
- vinna með opinberum eða einkareknum git geymslum.
Hér setjum við upp atburðina sem kalla aðgerðina. Atburðir geta verið mismunandi fyrir mismunandi veitendur.
Þjónustuveitan smíðaði og gerði sjálfvirkt kerfið Function as a Service (FaaS) á innviðum sínum:
- Aðgerðarkóðinn endar í geymslu hjá þjónustuveitunni.
- Þegar atburður á sér stað eru gámar með undirbúnu umhverfi sjálfkrafa settir á netþjóninn. Hvert falltilvik hefur sinn einangraða ílát.
- Frá geymslunni er aðgerðin send í gáminn, reiknuð og skilar niðurstöðunni.
- Fjöldi samhliða atburða fer vaxandi - fjöldi gáma fer vaxandi. Kerfið skalast sjálfkrafa. Ef notendur hafa ekki aðgang að aðgerðinni verður hún óvirk.
- Þjónustuveitan setur aðgerðalausan tíma fyrir gáma - ef á þessum tíma birtast aðgerðir ekki í gámnum er honum eytt.
Þannig fáum við Serverless úr kassanum. Við munum greiða fyrir þjónustuna með því að nota borgunarlíkanið og aðeins fyrir þær aðgerðir sem eru notaðar og aðeins fyrir þann tíma sem þær voru notaðar.
Til að kynna forritara fyrir þjónustuna bjóða veitendur allt að 12 mánaða ókeypis prófun, en takmarka heildarútreikningstíma, fjölda beiðna á mánuði, fjármuni eða orkunotkun.
Helsti kosturinn við að vinna með þjónustuveitanda er hæfileikinn til að hafa ekki áhyggjur af innviðum (þjónum, sýndarvélum, gámum). Fyrir sitt leyti getur veitandinn innleitt FaaS bæði með því að nota sína eigin þróun og með því að nota opinn hugbúnað. Við skulum tala um þá frekar.
Frá opinn uppspretta hlið
Opinn uppspretta samfélagið hefur unnið virkan að Serverless verkfærum undanfarin tvö ár. Stærstu markaðsaðilarnir leggja einnig sitt af mörkum til þróunar á netþjónalausum kerfum:
- Google býður forriturum opinn uppspretta tól - . IBM, RedHat, Pivotal og SAP tóku þátt í þróun þess;
- IBM unnið á Serverless palli , sem síðan varð verkefni Apache Foundation;
- Microsoft opnaði pallkóðann að hluta .
Þróun er einnig í gangi í átt að netþjónalausum ramma. и sett inn í fyrirfram undirbúna Kubernetes klasa, virkar með bæði Kubernetes og Docker Swarm. Ramminn virkar sem eins konar stjórnandi - ef þess er óskað undirbýr hann keyrsluumhverfi inni í klasanum og setur síðan aðgerð þar af stað.
Rammar gefa svigrúm til að stilla tólið að þínum þörfum. Svo, í Kubeless, getur verktaki stillt tímamörk fyrir framkvæmd aðgerða (sjálfgefið gildi er 180 sekúndur). Fission, í tilraun til að leysa kaldræsingarvandamálið, leggur til að halda sumum gámum í gangi allan tímann (þó að þetta hafi í för með sér kostnað við niður í miðbæ). Og OpenFaaS býður upp á sett af kveikjum fyrir hvert bragð og lit: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs og fleiri.
Leiðbeiningar til að hefjast handa er að finna í opinberum skjölum ramma. Að vinna með þeim krefst þess að hafa aðeins meiri færni en þegar unnið er með þjónustuaðila - þetta er að minnsta kosti hæfileikinn til að ræsa Kubernetes þyrping í gegnum CLI. Láttu í mesta lagi önnur opinn hugbúnað fylgja með (til dæmis Kafka biðröðstjórann).
Óháð því hvernig við vinnum með Serverless - í gegnum þjónustuaðila eða með því að nota opinn uppspretta, munum við fá fjölda kosta og galla við Serverless nálgunina.
Frá sjónarhóli kosta og galla
Serverless þróar hugmyndir um gámainnviði og örþjónustunálgun, þar sem teymi geta unnið á fjöltyngdum ham án þess að vera bundin við einn vettvang. Uppbygging kerfis er einfölduð og villur er auðveldara að leiðrétta. Örþjónustuarkitektúr gerir þér kleift að bæta nýjum virkni við kerfið mun hraðar en þegar um er að ræða einhæft forrit.
Serverless styttir þróunartíma enn frekar, sem gerir verktaki kleift að einbeita sér eingöngu að viðskiptarökfræði og kóðun forritsins. Fyrir vikið styttist tíminn á markað fyrir þróun.
Sem bónus fáum við sjálfvirka mælingu fyrir álag, og við borgum aðeins fyrir þær auðlindir sem notaðar eru og aðeins á þeim tíma sem þær eru notaðar.
Eins og öll tækni hefur Serverless ókosti.
Til dæmis getur slíkur ókostur verið kaldræsitíminn (að meðaltali allt að 1 sekúnda fyrir tungumál eins og JavaScript, Python, Go, Java, Ruby).
Annars vegar, í raun og veru, fer kaldræsingartíminn eftir mörgum breytum: tungumálinu sem aðgerðin er skrifuð á, fjölda bókasöfna, magn kóða, samskipti við viðbótarauðlindir (sömu gagnagrunna eða auðkenningarþjónar). Þar sem verktaki stjórnar þessum breytum getur hann dregið úr ræsingartíma. En á hinn bóginn getur verktaki ekki stjórnað ræsingartíma gámsins - það veltur allt á veitandanum.
Köldræsing getur breyst í hlýbyrjun þegar aðgerð endurnýtir ílát sem ræst var af fyrri atburði. Þessi staða mun koma upp í þremur tilvikum:
- ef viðskiptavinir nota þjónustuna oft og símtölum í aðgerðina fjölgar;
- ef veitandi, vettvangur eða rammi gerir þér kleift að halda sumum gámum í gangi allan tímann;
- ef verktaki keyrir aðgerðir á tímamæli (segjum á 3 mínútna fresti).
Fyrir mörg forrit er kaldræsing ekki vandamál. Hér þarf að byggja á gerð og verkefnum þjónustunnar. Sekuna á byrjun er ekki alltaf mikilvæg fyrir viðskiptaforrit, en hún getur orðið mikilvæg fyrir læknisþjónustu. Í þessu tilviki mun netþjónalausa nálgunin líklega ekki lengur henta.
Næsti ókostur við Serverless er stuttur líftími aðgerða (tímatími þar sem aðgerðin verður að vera keyrð).
En ef þú þarft að vinna með langvarandi verkefni geturðu notað blendingsarkitektúr - sameinað Serverless með annarri tækni.
Ekki munu öll kerfi geta unnið með því að nota Serverless kerfið.
Sum forrit munu enn geyma gögn og ástand meðan á framkvæmd stendur. Sumir arkitektúrar verða áfram einsleitir og sumir eiginleikar munu halda langlífi. Hins vegar (eins og skýjatækni og síðan gámar), er Serverless tækni með mikla framtíð.
Í þessum efnum langar mig að fara snurðulaust yfir í málið að nota Serverless nálgunina.
Frá umsóknarhliðinni
Fyrir 2018, hlutfall netþjónalausrar notkunar . Meðal fyrirtækja sem þegar hafa innleitt tæknina í þjónustu sína eru markaðsrisar eins og Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Á sama tíma þarftu að skilja að Serverless er ekki panacea heldur tæki til að leysa ákveðin vandamál:
- Draga úr niður í miðbæ. Það er engin þörf á að halda stöðugt sýndarvél fyrir þjónustu sem hefur fá símtöl.
- Vinndu gögn á flugu. Þjappaðu myndum, klipptu út bakgrunn, breyttu myndkóðun, vinndu með IoT skynjara, framkvæmdu stærðfræðilegar aðgerðir.
- „Límdu“ aðra þjónustu saman. Git geymsla með innri forritum, spjallboti í Slack með Jira og dagatali.
- Jafnvægi álagið. Við skulum skoða nánar hér.
Segjum að það sé þjónusta sem laðar að 50 manns. Undir henni er sýndarvél með veikum vélbúnaði. Af og til eykst álagið á þjónustuna verulega. Þá getur veikur vélbúnaður ekki ráðið við.
Þú getur sett jafnvægisbúnað inn í kerfið sem mun dreifa álaginu, segjum, yfir þrjár sýndarvélar. Á þessu stigi getum við ekki spáð nákvæmlega fyrir um álagið, svo við höldum ákveðnu magni af auðlindum í gangi „í varasjóði“. Og við borgum of mikið fyrir stöðvunartíma.
Í slíkum aðstæðum getum við fínstillt kerfið með blendingsaðferð: við skiljum eftir eina sýndarvél á bak við álagsjafnarann og setjum tengil á Serverless Endpoint með aðgerðum. Ef álagið fer yfir viðmiðunarmörkin, setur jafnvægisstillirinn aðgerðatilvik sem taka yfir hluta af vinnslu beiðninnar.
Þannig er hægt að nota Serverless þar sem nauðsynlegt er að vinna úr miklum fjölda beiðna ekki of oft, heldur ákaft. Í þessu tilfelli er arðbærara að keyra nokkrar aðgerðir í 15 mínútur en að viðhalda sýndarvél eða netþjóni allan tímann.
Með öllum kostum netþjónalausrar tölvunar, fyrir innleiðingu, ættir þú fyrst að meta rökfræði forritsins og skilja hvaða vandamál Serverless getur leyst í tilteknu tilviki.
Serverless og Selectel
Hjá Selectel erum við nú þegar í gegnum stjórnborðið okkar. Nú erum við að byggja upp okkar eigin FaaS vettvang. Við viljum að verktaki geti leyst vandamál sín með því að nota Serverless í gegnum þægilegt, sveigjanlegt viðmót.
Ef þú hefur hugmyndir um hver hinn hugsjón FaaS vettvangur ætti að vera og hvernig þú vilt nota Serverless í verkefnum þínum, deildu þeim í athugasemdunum. Við munum taka tillit til óska þinna við þróun vettvangsins.
Efni sem notað er í greinina:
Heimild: www.habr.com