{"id":33935,"date":"2019-10-31T21:55:27","date_gmt":"2019-10-31T18:55:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/serverless-po-stoechkam\/"},"modified":"2019-10-31T21:55:27","modified_gmt":"2019-10-31T18:55:27","slug":"serverless-po-stoechkam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/serverless-po-stoechkam","title":{"rendered":"Serverless teenuste korraldamine","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Serverless
\nServerless \u2015 ei t\u00e4henda f\u00fc\u00fcsiliste serverite puudumist. See pole \u00abnupp, mis tapab\u00bb konteinerid ega hetkeline trend. See on uus l\u00e4henemine pilves\u00fcsteemide ehitamisele. T\u00e4na k\u00e4sitleme Serverless-rakenduste arhitektuuri, vaatame, millist rolli m\u00e4ngib Serverless-teenuse pakkuja ja avatud l\u00e4htekoodiga projektid. L\u00f5pus arutame Serverless'i rakendamise k\u00fcsimusi.
\n<\/a><\/noindex>
\nMa tahan kirjutada rakenduse serveripoolset osa (\u00fcksk\u00f5ik, olgu see isegi veebipood). See v\u00f5ib olla ka vestlus ning sisu avaldamise teenus v\u00f5i koormuse tasakaalustaja. Igal juhul tuleb palju peavalu: tuleb ette valmistada infrastruktuur, m\u00e4\u00e4rata rakenduse s\u00f5ltuvused, m\u00f5elda hosti operatsioonis\u00fcsteemile. Seej\u00e4rel tuleb v\u00e4rskendada v\u00e4ikeseid komponente, mis ei m\u00f5juta \u00fclej\u00e4\u00e4nud monoliiti. Ja koormuse all k\u00f5rvutamise kohta ei tohi unustada.<\/p>\n

Kuidas oleks, kui v\u00f5tta efemeersed konteinerid, milles vajalikud s\u00f5ltuvused on juba ette paigutatud, ja need konteinerid on \u00fcksteisest ning host-OS-ist isoleeritud? Monoliit jagatakse mikroteenusteks, millest iga\u00fcht saab vahetada ja skaleerida s\u00f5ltumatult teistest. Kui paigaldada kood sellisesse konteinerisse, saan seda k\u00e4ivitada igasugusel infrastruktuuril. See on juba parem. <\/p>\n

Ent mis siis, kui ei soovi konteinerite seadistamisega tegeleda? Ei soovi m\u00f5elda rakenduse skaleerimisele. Ei soovi maksta k\u00e4ivitatud konteinerite seisakute eest, kui teenusele on minimaalne koormus. Tahan kirjutada koodi. Keskenduda \u00e4riloogikale ja tuua tooted turule valguskiirusel. <\/p>\n

Sellised m\u00f5tted viisid mind serverivabade arvutusteni. Serverless t\u00e4hendab sel juhul mitte f\u00fc\u00fcsilise serverite puudumist, vaid muretsemise puudumist infrastruktuuri juhtimise \u00fcle.<\/em><\/p>\n

Idee on see, et rakenduse loogika jaguneb s\u00f5ltumatuteks funktsioonideks. Neil on \u00fcrituste struktuur. Iga funktsioon t\u00e4idab \u00fchte \"mikrotehtavat\". K\u00f5ik, mis arendajalt n\u00f5utakse, on funktsioonide \u00fcleslaadimine pilveteenuse pakkuja pakutavasse konsolisse ja nende sidumine \u00fcritusallikatega. Kood t\u00e4idetakse n\u00f5udmisel automaatselt ettevalmistatud konteineris ning maksma pean ainult t\u00e4itmise aja eest. <\/p>\n

Vaatame, kuidas n\u00e4eb n\u00fc\u00fcd v\u00e4lja rakenduse arendamise protsess.<\/p>\n

Arendaja seisukohalt<\/h2>\n

\nVarasemalt r\u00e4\u00e4kisime e-kaubanduse rakendusest. Traditsioonilises l\u00e4henemises t\u00e4idab s\u00fcsteemi peamist loogikat monoliitne rakendus. Ja server, kus rakendus on pidevalt k\u00e4ivitatud, t\u00f6\u00f6tab isegi siis, kui koormust ei ole.<\/p>\n

Serverless'ile \u00fcleminekuks jagame rakenduse mikrotehtavateks.<\/strong> Iga\u00fche jaoks kirjutame oma funktsiooni. Funktsioonid on \u00fcksteisest s\u00f5ltumatud ja ei salvestata oleku (stateless) informatsiooni. Need v\u00f5ivad olla isegi kirjutatud erinevates keeltes. Kui \u00fcks neist \"kukub\", ei peatu kogu rakendus. Rakenduse arhitektuur n\u00e4eb v\u00e4lja nii:<\/p>\n

\"Serverless
\nServerless-funktsioonide jaotus sarnaneb mikroteenuste t\u00f6\u00f6le. Kuid mikroteenus v\u00f5ib t\u00e4ita mitmeid \u00fclesandeid, samas kui funktsioon peaks ideaaljuhul t\u00e4itma ainult \u00fchte. Kujutame ette, et \u00fclesanne on koguda statistikat ja esitada see kasutaja p\u00e4ringu j\u00e4rgi. Mikroteenuste l\u00e4henemisviisis t\u00e4idab \u00fclesannet \u00fcks teenus, millel on kaks sisendpunkti: kirjutamiseks ja lugemiseks. Besserverite arvutustes on need kaks erinevat funktsiooni, mis ei ole omavahel seotud. Arendaja s\u00e4\u00e4stab arvutusressursse, kui n\u00e4iteks statistikat uuendatakse sagedamini, kui seda v\u00e4ljastatakse. <\/p>\n

Serverless-funktsioonid peavad t\u00f6\u00f6tama l\u00fchikese ajavahemiku jooksul (timeout), mille m\u00e4\u00e4rab teenusepakkuja. N\u00e4iteks AWS jaoks on ajavahemik 15 minutit. See t\u00e4hendab, et pikaajalisi funktsioone tuleb kohandada n\u00f5uete j\u00e4rgi - sellega erineb Serverless teistest t\u00e4na populaarsetest tehnoloogiatest (konteineritest ja Platform as a Service'ist).<\/p>\n

Iga funktsioonile m\u00e4\u00e4rame s\u00fcndmuse.<\/strong> S\u00fcndmus on tegevuse k\u00e4ivitaja:<\/p>\n

S\u00fcndmus<\/strong>
\nTegevus, mida funktsioon t\u00e4idab<\/strong><\/p>\n

Hoidlasse on \u00fcles laaditud toote pilt
\nPildi kokkusurumine ja katalooge v\u00e4ljastamine<\/p>\n

Andmebaasis on f\u00fc\u00fcsilise poe aadress uuendatud
\nLaadige kaardile uus asukoht<\/p>\n

Klient maksab toote eest
\nK\u00e4ivitage makse t\u00f6\u00f6tlemine<\/p>\n

S\u00fcndmusteks v\u00f5ivad olla HTTP-p\u00e4ringud, voogandmed, s\u00f5numij\u00e4rjekorrad jne. S\u00fcndmuste allikad on andmete muutumine v\u00f5i ilmumine. Samuti saab funktsioone k\u00e4ivitada ajastatud p\u00f5hjal.<\/p>\n

Arhitektuur on v\u00e4lja t\u00f6\u00f6tatud ja rakendus on peaaegu serverivaba. Liikume n\u00fc\u00fcd teenusepakkuja poole.<\/p>\n

Teenusepakkuja poolt<\/h2>\n

\nTavaliselt pakuvad serverivabad arvutused pilveteenuse pakkujad. Neid nimetatakse erinevalt: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions. <\/p>\n

Kasutame teenust konsooli v\u00f5i teenusepakkuja isikliku konto kaudu. Funktsioonide koodi saab \u00fcles laadida j\u00e4rgmistel viisidel:<\/p>\n