Serverless nėra susijęs su fiziniu serverių nebuvimu. Tai nėra konteinerių žudikas ar praeinanti tendencija. Tai naujas požiūris į sistemų kūrimą debesyje. Šiandienos straipsnyje paliesime be serverių programų architektūrą, pažiūrėkime, kokį vaidmenį atlieka paslaugų teikėjas be serverio ir atvirojo kodo projektai. Galiausiai pakalbėkime apie „Serverless“ naudojimo problemas.
Noriu parašyti serverio dalį programoje (ar net internetinėje parduotuvėje). Tai gali būti pokalbis, turinio publikavimo paslauga arba apkrovos balansavimo priemonė. Bet kokiu atveju galvos skausmo bus nemažai: teks paruošti infrastruktūrą, nustatyti taikomųjų programų priklausomybes, pagalvoti apie pagrindinę operacinę sistemą. Tada turėsite atnaujinti mažus komponentus, kurie neturi įtakos likusio monolito veikimui. Na, nepamirškime mastelio keitimo esant apkrovai.
Ką daryti, jei imtume trumpalaikius konteinerius, kuriuose jau iš anksto įdiegtos reikiamos priklausomybės, o patys konteineriai yra izoliuoti vienas nuo kito ir nuo pagrindinės OS? Monolitą padalinsime į mikropaslaugas, kurių kiekviena gali būti atnaujinama ir keičiama nepriklausomai nuo kitų. Įdėjus kodą į tokį konteinerį, galiu jį paleisti bet kurioje infrastruktūroje. Jau geriau.
Ką daryti, jei nenorite konfigūruoti konteinerių? Nenoriu galvoti apie programos mastelio keitimą. Nenoriu mokėti už tuščiąja eiga veikiančius konteinerius, kai paslaugos apkrova minimali. Noriu parašyti kodą. Sutelkite dėmesį į verslo logiką ir pateikite produktus į rinką šviesos greičiu.
Tokios mintys privedė mane prie kompiuterio be serverio. Be serverio šiuo atveju reiškia ne fizinis serverių nebuvimas, o infrastruktūros valdymo galvos skausmo nebuvimas.
Idėja yra ta, kad programų logika yra suskirstyta į nepriklausomas funkcijas. Jie turi įvykių struktūrą. Kiekviena funkcija atlieka vieną „mikroužduotį“. Viskas, ko reikia iš kūrėjo, yra įkelti funkcijas į debesų tiekėjo teikiamą pultą ir susieti jas su įvykių šaltiniais. Kodas bus vykdomas pagal poreikį automatiškai paruoštame konteineryje, o aš mokėsiu tik už vykdymo laiką.
Pažiūrėkime, kaip dabar atrodys programų kūrimo procesas.
Iš kūrėjo pusės
Anksčiau pradėjome kalbėti apie paraišką internetinei parduotuvei. Tradiciniu požiūriu pagrindinę sistemos logiką atlieka monolitinė programa. Ir serveris su programa veikia nuolat, net jei nėra apkrovos.
Norėdami pereiti prie be serverio, programą suskaidome į mikroužduotį. Kiekvienai iš jų rašome savo funkciją. Funkcijos yra nepriklausomos viena nuo kitos ir nesaugo būsenos informacijos (bevalstybės). Jie netgi gali būti parašyti skirtingomis kalbomis. Jei vienas iš jų „nukris“, visa programa nesustos. Programos architektūra atrodys taip:
„Serless“ funkcijų padalijimas yra panašus į darbą su mikropaslaugomis. Tačiau mikropaslauga gali atlikti kelias užduotis, o idealiu atveju funkcija turėtų atlikti vieną. Įsivaizduokime, kad užduotis yra rinkti statistiką ir vartotojo pageidavimu ją rodyti. Taikant mikropaslaugų metodą, užduotį atlieka viena paslauga su dviem įėjimo taškais: rašymas ir skaitymas. Kompiuteryje be serverio tai bus dvi skirtingos funkcijos, nesusijusios viena su kita. Kūrėjas taupo skaičiavimo išteklius, jei, pavyzdžiui, statistika atnaujinama dažniau nei atsisiunčiama.
Funkcijos be serverių turi būti įvykdomos per trumpą laiką (timeout), kurį nustato paslaugos teikėjas. Pavyzdžiui, AWS skirtasis laikas yra 15 minučių. Tai reiškia, kad ilgai veikiančias funkcijas teks keisti, kad jos atitiktų reikalavimus – tuo „Serverless“ skiriasi nuo kitų šiandien populiarių technologijų (konteinerių ir platformos kaip paslauga).
Kiekvienai funkcijai priskiriame įvykį. Įvykis yra veiksmo paleidiklis:
Renginys
Veiksmas, kurį atlieka funkcija
Produkto vaizdas buvo įkeltas į saugyklą.
Suspauskite vaizdą ir įkelkite į katalogą
Fizinės parduotuvės adresas buvo atnaujintas duomenų bazėje
Įkelkite naują vietą į žemėlapius
Už prekes sumoka klientas
Pradėkite mokėjimo apdorojimą
Įvykiai gali būti HTTP užklausos, srautiniai duomenys, pranešimų eilės ir pan. Įvykių šaltiniai yra duomenų pasikeitimai arba įvykiai. Be to, funkcijas gali suaktyvinti laikmatis.
Architektūra buvo parengta ir programa beveik tapo be serverio. Toliau einame pas paslaugų teikėją.
Iš tiekėjo pusės
Paprastai kompiuteriją be serverio siūlo debesų paslaugų teikėjai. Jie vadinami skirtingai: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Paslauga naudosimės per teikėjo pultą arba asmeninę paskyrą. Funkcijos kodą galima atsisiųsti vienu iš šių būdų:
- rašyti kodą integruotuose redaktoriuose per žiniatinklio konsolę,
- atsisiųskite archyvą su kodu,
- dirbti su viešosiomis ar privačiomis git saugyklomis.
Čia nustatome įvykius, kurie iškviečia funkciją. Įvairių paslaugų teikėjų įvykių rinkiniai gali skirtis.
Teikėjas sukūrė ir automatizavo funkciją „Funkcija kaip paslauga“ (FaaS) savo infrastruktūroje:
- Funkcijos kodas patenka į saugyklą teikėjo pusėje.
- Įvykus įvykiui, konteineriai su paruošta aplinka automatiškai diegiami serveryje. Kiekvienas funkcijos egzempliorius turi savo atskirą konteinerį.
- Iš saugyklos funkcija siunčiama į konteinerį, apskaičiuojama ir grąžinamas rezultatas.
- Lygiagrečių renginių daugėja – daugėja konteinerių. Sistema automatiškai keičia mastelį. Jei vartotojai nepasieks šios funkcijos, ji bus neaktyvi.
- Teikėjas nustato konteinerių neveiklumo laiką – jei per tą laiką funkcijos konteineryje nepasirodo, jis sunaikinamas.
Tokiu būdu mes išimame be serverių. Už paslaugą mokėsime naudodamiesi „pay-as-you-go“ modeliu ir tik už tas funkcijas, kurios yra naudojamos, ir tik už laiką, kai jomis buvo naudojamasi.
Siekdami supažindinti kūrėjus su paslauga, teikėjai siūlo iki 12 mėnesių nemokamą testavimą, tačiau riboja bendrą skaičiavimo laiką, užklausų skaičių per mėnesį, lėšas arba energijos suvartojimą.
Pagrindinis privalumas dirbant su teikėju yra galimybė nesijaudinti dėl infrastruktūros (serverių, virtualių mašinų, konteinerių). Savo ruožtu teikėjas gali įdiegti FaaS tiek naudodamas savo plėtrą, tiek naudodamas atvirojo kodo įrankius. Pakalbėkime apie juos toliau.
Iš atvirojo kodo pusės
Atvirojo kodo bendruomenė pastaruosius porą metų aktyviai dirbo su įrankiais be serverių. Prie be serverių platformų kūrimo prisideda ir didžiausi rinkos žaidėjai:
- "Google" siūlo kūrėjams savo atvirojo kodo įrankį - . Kuriant jį dalyvavo IBM, RedHat, Pivotal ir SAP;
- IBM dirbo be serverio platformoje , kuris vėliau tapo Apache fondo projektu;
- "Microsoft" iš dalies atidarė platformos kodą .
Taip pat vyksta plėtra be serverių sistemų. и dislokuoti iš anksto paruoštuose Kubernetes klasteriuose, dirba su Kubernetes ir Docker Swarm. Sistema veikia kaip savotiškas valdiklis – paprašius, ji parengia vykdymo aplinką klasterio viduje, tada ten paleidžia funkciją.
Karkasai palieka vietos konfigūruoti įrankį, kad jis atitiktų jūsų poreikius. Taigi „Kubeless“ programuotojas gali sukonfigūruoti funkcijos vykdymo skirtąjį laiką (numatytoji reikšmė yra 180 sekundžių). Dalijimasis, bandant išspręsti šalto paleidimo problemą, siūlo kai kuriuos konteinerius nuolat veikti (nors tai reiškia išteklių prastovos išlaidas). O „OpenFaaS“ siūlo kiekvienam skoniui ir spalvoms skirtų trigerių rinkinį: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT ir kt.
Instrukcijas, kaip pradėti, galite rasti oficialioje struktūrų dokumentacijoje. Norint dirbti su jais reikia turėti šiek tiek daugiau įgūdžių nei dirbant su teikėju – tai bent jau galimybė paleisti Kubernetes klasterį per CLI. Daugiausia įtraukite kitus atvirojo kodo įrankius (pvz., Kafka eilių tvarkyklę).
Nepriklausomai nuo to, kaip dirbame su „Serverless“ – per tiekėją ar naudodami atvirąjį kodą, sulauksime nemažai „Serverless“ metodo privalumų ir trūkumų.
Privalumų ir trūkumų požiūriu
Serverless plėtoja konteinerių infrastruktūros ir mikro paslaugų metodo idėjas, kai komandos gali dirbti daugiakalbiu režimu, neprisirišdamos prie vienos platformos. Sistemos kūrimas yra supaprastintas, o klaidas lengviau ištaisyti. „Microservice“ architektūra leidžia daug greičiau pridėti naujų funkcijų prie sistemos nei monolitinės programos atveju.
Be serverio dar labiau sumažina kūrimo laiką, leidžianti kūrėjui sutelkti dėmesį tik į programos verslo logiką ir kodavimą. Dėl to sutrumpėja laikas, reikalingas pakeitimams pateikti į rinką.
Kaip premiją gauname automatinį apkrovos mastelį, ir mokame tik už panaudotus išteklius ir tik tuo metu, kai jie naudojami.
Kaip ir bet kuri technologija, „Serverless“ turi trūkumų.
Pavyzdžiui, toks trūkumas gali būti šalto paleidimo laikas (vidutiniškai iki 1 sekundės tokioms kalboms kaip JavaScript, Python, Go, Java, Ruby).
Viena vertus, realiai šaltojo paleidimo laikas priklauso nuo daugelio kintamųjų: kalbos, kuria parašyta funkcija, bibliotekų skaičiaus, kodo kiekio, ryšio su papildomais ištekliais (tos pačios duomenų bazės ar autentifikavimo serveriai). Kadangi kūrėjas valdo šiuos kintamuosius, jis gali sutrumpinti paleidimo laiką. Tačiau, kita vertus, kūrėjas negali kontroliuoti konteinerio paleidimo laiko – viskas priklauso nuo tiekėjo.
Šaltas paleidimas gali virsti šiltu paleidimu, kai funkcija pakartotinai naudoja konteinerį, paleistą dėl ankstesnio įvykio. Tokia situacija susiklostys trimis atvejais:
- jei klientai dažnai naudojasi paslauga ir didėja skambučių į funkciją skaičius;
- jei teikėjas, platforma ar sistema leidžia nuolat veikti kai kuriuos konteinerius;
- jei kūrėjas paleidžia funkcijas laikmačiu (tarkime, kas 3 minutes).
Daugeliu atvejų šaltas užvedimas nėra problema. Čia reikia remtis paslaugos tipu ir užduotimis. Paleidimo delsa sekunde ne visada yra svarbi verslo programai, tačiau ji gali tapti svarbia medicinos paslaugoms. Tokiu atveju metodas be serverio greičiausiai nebebus tinkamas.
Kitas „Serverless“ trūkumas yra trumpas funkcijos veikimo laikas (laikas, per kurį funkcija turi būti vykdoma).
Tačiau, jei turite dirbti su ilgai trunkančiomis užduotimis, galite naudoti hibridinę architektūrą – derinkite be serverių su kita technologija.
Ne visos sistemos galės veikti naudojant be serverio schemą.
Kai kurios programos vis tiek saugos duomenis ir būseną vykdymo metu. Kai kurios architektūros išliks monolitinės, o kai kurios funkcijos – ilgaamžės. Tačiau (kaip ir debesų technologijos ir konteineriai), be serverių yra technologija, turinti didelę ateitį.
Šiuo požiūriu norėčiau sklandžiai pereiti prie metodo be serverio naudojimo.
Iš taikymo pusės
2018 m. naudojimo be serverio procentas . Tarp technologiją savo paslaugose jau įdiegusių įmonių yra tokie rinkos gigantai kaip Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Tuo pačiu metu jūs turite suprasti, kad „Serverless“ nėra panacėja, o įrankis tam tikroms problemoms spręsti:
- Sumažinkite išteklių prastovos laiką. Nereikia nuolat laikyti virtualios mašinos paslaugoms, kurios turi mažai skambučių.
- Apdorokite duomenis skrendant. Suspausti paveikslėlius, iškirpti fonus, keisti vaizdo kodavimą, dirbti su daiktų interneto jutikliais, atlikti matematines operacijas.
- „Suklijuokite“ kitas paslaugas. Git saugykla su vidinėmis programomis, pokalbių robotas Slack su Jira ir kalendorius.
- Subalansuokite apkrovą. Pažiūrėkime čia atidžiau.
Tarkime, yra paslauga, kuri pritraukia 50 žmonių. Po juo yra virtuali mašina su silpna aparatūra. Kartkartėmis paslaugos apkrova gerokai padidėja. Tada silpna aparatinė įranga negali susidoroti.
Į sistemą galite įtraukti balansavimo priemonę, kuri paskirstys apkrovą, tarkime, per tris virtualias mašinas. Šiame etape negalime tiksliai numatyti apkrovos, todėl tam tikrą išteklių kiekį laikome „rezerve“. O už prastovą permokame.
Tokioje situacijoje galime optimizuoti sistemą hibridiniu metodu: paliekame vieną virtualią mašiną už apkrovos balansavimo priemonės ir įdedame nuorodą į be serverio galinį tašką su funkcijomis. Jei apkrova viršija slenkstį, balansavimo priemonė paleidžia funkcijų egzempliorius, kurie perima dalį užklausos apdorojimo.
Taigi, Serverless gali būti naudojamas ten, kur reikia apdoroti daugybę užklausų ne per dažnai, o intensyviai. Tokiu atveju 15 minučių vykdyti kelias funkcijas yra pelningiau nei nuolat prižiūrėti virtualią mašiną ar serverį.
Turėdami visus be serverio skaičiavimo privalumus, prieš diegdami pirmiausia turėtumėte įvertinti programos logiką ir suprasti, kokias problemas be serverio gali išspręsti konkrečiu atveju.
Be serverio ir Selectel
Mes jau esame „Selectel“. per mūsų valdymo skydelį. Dabar kuriame savo FaaS platformą. Norime, kad kūrėjai galėtų išspręsti savo problemas naudodami be serverio naudodami patogią ir lanksčią sąsają.
Jei turite idėjų, kokia turėtų būti ideali FaaS platforma ir kaip norite naudoti „Serverless“ savo projektuose, pasidalykite jomis komentaruose. Kurdami platformą atsižvelgsime į jūsų pageidavimus.
Straipsnyje naudotos medžiagos:
Šaltinis: www.habr.com