{"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 hittide k\u00e4rg","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Serverless
\nServerless ei t\u00e4henda f\u00fc\u00fcsiliste serverite puudumist. See ei ole konteinerite \u00abtapja\u00bb ega ajutine trend. See on uus l\u00e4henemine s\u00fcsteemide ehitamisele pilves. T\u00e4na vaatame Serverless-rakenduste arhitektuuri, uurime, millist rolli m\u00e4ngib Serverless-teenuste pakkuja ja open-source projektid. L\u00f5puks arutame, kuidas Serverless'i rakendusi kasutada.
\n<\/a><\/noindex>
\nMa tahan kirjutada rakenduse serveripoolset osa (isegi kui see on internetipood). See v\u00f5ib olla vestlus, sisu avaldamise teenus v\u00f5i koormuse tasakaalustaja. Igatahes tuleb tegeleda paljude muredega: tuleb ette valmistada infrastruktuur, m\u00e4\u00e4rata rakenduse s\u00f5ltuvused, m\u00f5elda hosti operatsioonis\u00fcsteemile. Siis tuleb uuendada v\u00e4ikseid komponente, mis ei m\u00f5juta \u00fclej\u00e4\u00e4nud monoliiti. Ja \u00e4rgem unustagem koormuse j\u00e4rgi skaleerimist.<\/p>\n

Aga mis siis, kui v\u00f5tta efemeerseid konteinereid, milles vajalikud s\u00f5ltuvused on juba eelnevalt installitud, ning need konteinerid on \u00fcksteisest ja hosti ops\u00fcsteemist eraldatud? Jagame monoliidi mikroteenusteks, millest iga\u00fcht saab uuendada ja skaleerida s\u00f5ltumatult teistest. Paigutades koodi sellisesse konteinerisse, saan seda k\u00e4ivitada igasuguses infrastruktuuris. See on juba parem. <\/p>\n

Aga kui ei taha konteinereid seadistada? Ei taha m\u00f5elda rakenduse skaleerimisele. Ei taha maksta k\u00e4ivitatud konteinerite ootamise eest, kui teenusele on minimaalne koormus. Tahan lihtsalt koodi kirjutada. Keskenduda \u00e4ri loogikale ja tuua tooted turule tuulekiirusel. <\/p>\n

Sellised m\u00f5tted viisid mind serverivabade arvutuste juurde. Serverless t\u00e4henduses t\u00e4hendab see mitte f\u00fc\u00fcsiliste serverite puudumist, vaid muret infrastruktuuri haldamise puudumisest.<\/em><\/p>\n

Idee seisneb selles, et rakenduse loogika jaguneb s\u00f5ltumatuteks funktsioonideks. Need on s\u00fcndmustep\u00f5hised. Iga funktsioon t\u00e4idab \u00fchte \u00abmikrotegevust\u00bb. K\u00f5ik, mida arendajalt n\u00f5utakse, on laadida funktsioonid pilveteenuse pakkuja konsooli ja seostada need s\u00fcndmuste allikatega. Kood k\u00e4ivitatakse n\u00f5udmisel automaatselt ette valmistatud konteineris ning maksan ainult k\u00e4ivitamise aja eest. <\/p>\n

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

Arendaja vaatepunktist<\/h2>\n

\nVarem r\u00e4\u00e4kisime e-poe rakendusest. Traditsioonilises l\u00e4henemisviisis t\u00e4idab s\u00fcsteemi p\u00f5hiloogika monoliitne rakendus. Ja server, kus rakendus on pidevalt k\u00e4ivitatud, t\u00f6\u00f6tab pidevalt, isegi kui koormust pole.<\/p>\n

Serverless lahendusele \u00fclemineku jaoks jagame rakenduse mikrotegevusteks.<\/strong> Iga\u00fche jaoks kirjutame oma funktsiooni. Funktsioonid on \u00fcksteisest s\u00f5ltumatud ja ei salvesta olekut (stateless). Need v\u00f5ivad olla kirjutatud isegi erinevates keeltes. Kui \u00fcks neist \u201ekukub\u201d, ei peatu kogu rakendus. Rakenduse arhitektuur n\u00e4eb v\u00e4lja selline:<\/p>\n

\"Serverless
\nFunktsioonide jaotamine Serverless'is sarnaneb mikroteenustega t\u00f6\u00f6tamisega. Kuid mikroteenus v\u00f5ib t\u00e4ita mitmeid \u00fclesandeid, samas kui funktsioon peaks ideaalis t\u00e4itma vaid \u00fcht. Kujutage ette, et \u00fclesanne on koguda statistikat ja esitada see kasutaja p\u00e4ringu j\u00e4rgi. Mikroteenuse l\u00e4henemisviisis t\u00e4idab \u00fclesande \u00fcks teenus, millel on kaks sisendpunkti: kirjutamiseks ja lugemiseks. Besserveritaseme arvutustes on need kaks eraldi funktsiooni, mis ei ole omavahel seotud. Arendaja s\u00e4\u00e4stab arvutusressursse, kui n\u00e4iteks statistikat uuendatakse sagedamini kui seda laaditakse. <\/p>\n

Serverless-funktsioonid peavad t\u00f6\u00f6tama l\u00fchikese aja jooksul (timeout), mille m\u00e4\u00e4rab teenuse pakkuja. N\u00e4iteks AWS puhul on timeout 15 minutit. See t\u00e4hendab, et pikaajalised funktsioonid (long-lived) tuleb kohandada n\u00f5uete j\u00e4rgi \u2014 sellega erineb Serverless teistest praegu populaarsetest tehnoloogiatest (nagu konteinerid ja Platform as a Service).<\/p>\n

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

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

Toote pilt on salvestatud salvestusruumi
\nPildistada pilt ja laadida see kataloogi<\/p>\n

Andmebaasis on uuendatud f\u00fc\u00fcsilise poe aadress
\nUue asukoha laadimine kaartidele<\/p>\n

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

S\u00fcndmusteks v\u00f5ivad olla HTTP-p\u00e4ringud, voogedastuse andmed, s\u00f5numij\u00e4rjed jne. S\u00fcndmuste allikad on andmete muutumine v\u00f5i ilmumine. Samuti saab funktsioone k\u00e4ivitada ajastatult.<\/p>\n

Arhitektuur on l\u00e4bi t\u00f6\u00f6tatud ja rakendus on peaaegu serverless. Edasi liikume teenuse pakkuja poole.<\/p>\n

Teenuse pakkuja poolt<\/h2>\n

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

Teenust kasutame l\u00e4bi teenusepakkuja konsooli v\u00f5i isikliku konto. Funktsioonide koodi saab laadida \u00fche j\u00e4rgmistest viisidest:<\/p>\n