2025 m. daugiausia dėmesio skiriu taupiam diegimui, išmatuojamai sąnaudų naudai ir pasauliniam pristatymui per "Edge", kad funkcijos būtų įdiegtos per kelias dienas, o ne savaites. Tuo pačiu metu planuoju specialiai šaltąjį paleidimą, prieigą prie duomenų ir stebėjimą, kad našumas, sąnaudos ir veikimas išliktų subalansuoti ir Komandos pristatyti greičiau.
Centriniai taškai
- Išlaidos Taupykite mokėdami už naudojimąsi, išvengsite prastovų
- Mastelis per kelias sekundes, be savo serverio priežiūros
- Pardavimo laikas mažėja dėl automatizuoto aprūpinimo
- Rizika valdyti: šaltasis startas, tiekėjų lojalumas, ribos
- Scenarijai 2025: "Edge", API, paketinis apdorojimas, mikroservisai
Kas iš tikrųjų slypi už "Serverless 2025
Serverio priežiūrą palieku paslaugų teikėjui ir sutelkiu dėmesį į kodą, įvykius ir duomenų srautus. Be serverio kasdieniame gyvenime. Funkcijos įsijungia tik tada, kai jų reikia, jų mastas nustatomas automatiškai ir už jas atsiskaitoma pagal naudojimą, todėl sumažėja piko apkrovos ir palaikomos palankios ramybės fazės. Už uždangos serveriai ir toliau veikia, tačiau abstrahuotai, su centralizuotais atnaujinimais, pataisymais ir mastelio keitimo logika. Funkcijas kviečiu HTTP, eilėmis, "cron" ar saugojimo įvykiais, užduotis organizuoju naudodamas būsenų mašinas ir saugau būsenas duomenų bazėse, kurios sukurtos dideliam skaičiui vienalaikių kreipimųsi. Ši architektūra pasiteisina, kai duomenų srautas svyruoja, dažnai išleidžiamos versijos ir mažoms komandoms reikia greitai pasiekti rezultatų.
Privalumai, kurie bus svarbūs 2025 m.
Sumažinu pastoviąsias sąnaudas, nes moku tik už tai, ką iš tikrųjų naudoju, ir sutaupau prastovos laiko, kuris būtų iššvaistytas dirbant nepertraukiamai. brangus tampa. Kai prasideda kampanijos ar sezoniškumas, platforma automatiškai keičiasi, o pasibaigus didžiausioms apkrovoms taip pat greitai sumažėja. Funkcijas išleidžiu greitai, nes nebereikia užtikrinti, taisyti ir planuoti pajėgumų, todėl galiu sutelkti dėmesį į testavimą, stebėjimą ir UX. Saugumui naudingi centralizuoti atnaujinimai, izoliacija ir smulkūs įgaliojimai, kuriuos apibrėšiu kiekvienai funkcijai ir ištekliui. Jei norite giliau susipažinti su privalumais ir trūkumais, šioje apžvalgoje Privalumai ir apribojimai Tai kompaktiškas suskirstymas į kategorijas, kuriuo grindžiami mano sprendimai.
Nurodykite nefunkcinius reikalavimus
Pradžioje aiškiai apibrėžiu SLOs kiekvienam galiniam taškui: prieinamumas, p95/p99 vėlavimas, klaidų dažnis ir vienos užklausos kaina. Iš to išvedžiau Klaidų biudžetai ir našumo biudžetus, pagal kuriuos sprendžiama, kur naudoti numatytąjį lygiagretumą, kraštinį perkėlimą ar agresyvų spartinimą. Produktyviam darbui suformuluoju tikslines vertes, pavyzdžiui, „p95 TTFB < 200 ms prie krašto“ arba „p95 API uždelsimas < 500 ms“, ir nuolat jas matuoju.
Atminties ir vykdymo laiko dydžius pasirinkau sąmoningai: daugiau operatyviosios atminties padidina milisekundės sąnaudas, tačiau dažnai sumažina procesoriaus laiką, taigi ir bendrą sumą. Bandau skirtingus Atmintis / laiko tarpas-kombinacijas pagal A/B ir sukurti vieną konkrečią kombinaciją kiekvienai funkcijai. Konkuravimas-limit, kad nebūtų perkrautos duomenų bazės ir išorinės API.
Sąžiningai kategorizuoti ribas
Planuoju "šaltąjį" paleidimą, nes retai iškviečiamoms funkcijoms reikia paleidimo laiko; kritiniams galutiniams taškams naudoju "keep-warm" parinktis, numatytąjį lygiagretumą arba kraštines funkcijas, artimas Vartotojas. Naudodamas standartinius karkasus, perkeliamumo sluoksnius ir aiškiai atskirdamas domeno logiką nuo konkrečiai platformai būdingų paslaugų, mažinu priklausomybę nuo gamintojo. Darbo krūviams, kurių vykdymo laikas labai ilgas arba kuriems keliami specialūs sistemos reikalavimai, taip pat naudoju konteinerius arba valdomas virtualias mašinas ir derinu juos abu. Jau pačioje architektūros pradžioje patikrinu tinklo ribas, laiko limitus ir didžiausius paketų dydžius, kad vėliau leidiniai nesugestų dėl platformos apribojimų. Man stebėsena, paskirstytas sekimas ir struktūrizuoti žurnalai yra dalis nuo pat pirmos dienos, nes priešingu atveju vėlavimo pikas ir klaidų lygis išlieka nematomas.
Idempotencija, pasikartojimai ir seka
Pagal numatytuosius nustatymus manau, kad bent kartą-pristatymas. Todėl dirbu su Idempotencijos raktai kiekvienai užduočiai, deduplikuoti naudojant unikalius raktus ir išsaugoti apdorojimo rezultatus su versijomis arba sekos numeriais. Lygiagrečioms darbo eigoms vietoj visuotinių operacijų naudoju SAGA modelius su kompensavimo etapais. Nustatau pakartotinius bandymus su Eksponentinis grįžtamasis nuokrypis ir drebėjimą, persiųsti probleminius pranešimus į Negyvų laiškų eilės ir užkirsti kelią „užnuodytiems pranešimams“, apribojant maksimalų pasikartojimų skaičių ir numatant rankinį patikrinimą.
Palyginimas: tradicinis ir beserveris
Prieš priimdamas sprendimus, vertinu veikimą, sąnaudas, mastelio keitimą ir vėlavimą, nes abiejų modelių privalumai skirtingose situacijose yra skirtingi ir jiems reikia skirtingų Įgūdžiai. Toliau pateiktoje lentelėje apibendrinti pagrindiniai matmenys ir parodyta, kuriose srityse turiu laisvę, o kuriose platforma yra labiau normatyvinė. Jei man reikia rinkos įspūdžių, prieglobos ir serverių palyginimų ieškokite tinklalapyje webhoster.de. Labai svyruojančiam srautui ir greitam išleidimo ciklui renkuosi serverless; specializuotai aparatinei įrangai arba griežtiems vėlavimo tikslams esu linkęs rinktis konteinerius rezervuotuose ištekliuose. Tai išlieka svarbu: Įvertinu darbo krūvio modelius, o ne tik technologinius pageidavimus, ir vėliau sprendimą vertinu pagal realius. Metrikos.
| Kriterijus | Tradicinė priegloba | Be serverio veikianti žiniatinklio priegloba |
|---|---|---|
| Serverio valdymas | Savarankiškas | Teikėjo valdomas |
| Išlaidų modelis | Fiksuotos mėnesinės ir (arba) metinės kainos | Mokėti už naudojimą |
| Mastelis | Dažnai rankinis arba ribotas | Automatinis, įvykiu valdomas |
| Lankstumas | Aukštas aparatinės įrangos/OS lygis | Iš anksto nustatytos ribos |
| Techninė priežiūra | Pataisos ir atnaujinimai savarankiškai | Centralizuotai pagal paslaugų teikėją |
| Vėlavimas | Pastovus, šiltas serveris | Galimas šaltasis paleidimas |
| Pavyzdžiai | VM, valdomas serveris | Funkcijos, kraštinių funkcijos |
Tinkami taikymo scenarijai 2025
Didelę naudą gaunu iš API, į kurias kreipiamasi nereguliariai, sezoninių parduotuvių, naujienų platformų ar renginių svetainių, kurios turi absorbuoti didžiausias kampanijų apkrovas, nuolat neprarasdamos pajėgumų. mokėti. Kurdamas MVP ir prototipus greitai įgyvendinu pagrindines funkcijas, gyvai išbandau hipotezes ir atmetu tai, kas neveikia. Vaizdų ir vaizdo įrašų konvertavimas, ataskaitų rengimo užduotys, ETL maršrutai ir "webhooks" yra tinkami, nes juos galima paleisti pagal įvykius. Švariai atskiriu autentifikavimo, mokėjimo patvirtinimo, turinio perkodavimo ar pranešimų mikroservisus ir juos savarankiškai keičiu masteliu. Įkvėpimo semiuosi iš realių pavyzdžių, pavyzdžiui, vaizdų apdorojimo, realaus laiko telemetrijos ir turinio pristatymo, kurie parodo, kaip gerai įvykių valdomus darbo krūvius galima mastelizuoti be pridėtinių išlaidų Serveris.
Migracija ir modernizacija be didelio sprogimo
Modernizuoju palaipsniui: pirmiausia prieš monolitą (API vartus / kraštą) įdedu sluoksnį, nukreipiu atskirus maršrutus į naujas funkcijas, o likusią dalį palieku nepakeistą. Replikuoju duomenis per Pakeitimų duomenų fiksavimas arba apibrėžti aiškią duomenų srities nuosavybę, kad nekiltų rašymo konfliktų. Tai leidžia man nepriklausomai diegti funkcijas, o kritiniai keliai išlieka stabilūs. Išmatuojami KPI - tokie kaip konversijos rodiklis, vėlavimas, klaidų skaičius - parodo, ar naujas kelias yra paruoštas gamybai. Tolesnius galinius taškus išbraukiu tik tada, kai pagrindiniai rodikliai yra tinkami.
Architektūros modeliai kasdieniam gyvenimui
Funkcijas derinu su API vartais, eilių sudarymu, objektų saugykla ir duomenų baze, kuri gali susidoroti su skaitymo ir rašymo apkrovomis, kad programa neveiktų piko metu. pakreipia. Ilgesnes darbo eigas įtraukiu į būsenų mašinas, o procesoriui imlius veiksmus atskiriu į asinchroninius vamzdynus, kad atsako laikas būtų trumpas. Naudoju spartinimą per CDN ir KV saugyklas tinklo pakraštyje, kad statiniai ištekliai ir dažni API atsakymai būtų greitai pasiekiami visame pasaulyje. Autentifikavimui naudoju žetonais pagrįstas procedūras ir paslaptis laikau centralizuotai; taip funkcijos išlieka trumpos ir saugios. Naudodamasis struktūrizuotais žurnalais, metrikomis ir sekimo ID, sukuriu stebėjimo galimybę, kad galėčiau greitai nustatyti šaltojo paleidimo, prieigos prie duomenų bazės ar išorinių priklausomybių trikdžius. rasti.
Duomenys ir atkaklumas be serverio
Planuoju duomenų kelius taip, kad vyrautų trumpos, pasikartojančios operacijos. Nuolatinius TCP ryšius su reliacinėmis duomenų bazėmis Jungčių telkimas arba naudokite HTTP tvarkykles ir tarpinius serverius, kad išvengtumėte ryšio audrų. Jei įmanoma, rašymo procesus atskiriu per eiles ir srautus; skaitymo kelius pagreitinu naudodamas kraštinius KV, į dokumentus orientuotus talpyklas arba materializuotus vaizdus. Sandorių atveju pirmenybę teikiu Smulkūs agregatai ir galimas nuoseklumas su aiškiomis kompensacijomis, o ne sudėtingi, paskirstyti užraktai.
Visuotinėms programoms aš atskiriu „karštas“ duomenis (pvz., seansus, funkcijų vėliavas) iš „sunkusis“ duomenis (pvz., užsakymų istoriją). Pirmuosius talpinu į talpyklą netoli naudotojo, o antruosius saugau centralizuotai arba regioniniu lygmeniu, atsižvelgdamas į atitiktį reikalavimams. Iš anksto atsižvelgiu į skaitymo ir rašymo santykį, indekso dydį ir skaidymą, kad užklausos išliktų stabilios net ir esant tūkstančiams užklausų vienu metu.
Praktika: nuo MVP iki mastelio keitimo
Pradedu nuo mažų dalykų: API, kelių įvykių, duomenų bazės - ir matuoju uždelsimą, klaidų dažnį ir vienos užklausos sąnaudas, prieš pridėdamas daugiau paslaugų ir aklųjų veiklos vietų. priimti. Jei MVP veikia, išskaidau didelės apimties galutinius taškus į funkcijas su aiškiomis atsakomybėmis. Apibrėžiu SLO kiekvienam maršrutui, kad galėčiau numatyti lygiagretumą arba kraštinę perkrovą ten, kur užklausos yra tikrai svarbios. Atnaujinimai vykdomi per CI/CD vamzdynus su inkrementiniu srautu, kad galėčiau ištaisyti klaidas, stipriai nesukeldamas smūgio naudotojams. Vėliau pridedu spartos ribojimą, grandinės pertraukiklius ir atsargines priemones, kad išorinės API neperduotų nesėkmių naudotojams. perduoti.
Kūrimas, bandymai ir vietinis modeliavimas
Kuriu su vietos Emuliatoriai eilių, saugyklų ir funkcijų arba paleisti trumpalaikes peržiūros aplinkas per filialą. Užtikrinu sutartis su vartotojo valdomais sutarčių testais, kad klaidingi schemos pakeitimai nepatektų į gamybą. Kraštinės logikos atveju imituoju antraštes, geoIP ir slapukus ir tikrinu taisykles dėl šalutinių poveikių.
Automatizavau Apkrovos bandymai su tikroviškais duomenų srauto profiliais (spūstys, padidėjimas, sezoniškumas) ir susieti juos su pėdsakais, kad būtų galima atpažinti priklausomybių "karštuosius taškus". Sintetiniai kanarai nuolat stebi kritinius srautus. Griežtai atskiriu funkcijų vėliavėles nuo diegimo, kad galėčiau aktyvuoti arba atšaukti funkcijas be naujo diegimo.
Realiai apskaičiuokite išlaidas
Sudedu kiekvienos funkcijos užklausas, vykdymo laiką ir atmintį ir patikrinu, kaip dažnai kuris kelias veikia, kad būtų galima planuoti biudžetą. pasilikti. Tipinis skaičiavimas: užklausų skaičius x (vidutinis vykdymo laikas x saugojimo lygis) plius objektų ir prieigos prie duomenų bazės saugojimo ir perdavimo išlaidos. Naudodamas spartinančiąją atmintinę, paketinį apdorojimą ir trumpesnį vykdymo laiką, sumažinu kintamąsias sąnaudas; naudodamas kraštinę spartinančiąją atmintinę, gerokai sumažinu atgalinius skambučius. Projektuose, kurių nuolatinė bazinė apkrova yra didelė, bendrą sumą gali sumažinti beserverio ir palankių nuolatinės apkrovos išteklių derinys. Galiausiai, svarbiausia yra vieno naudingo įvykio kaina - jei ją matuojate, nustatote priemonių prioritetus pagal Poveikis.
FinOps praktiškai
Aš atleidžiu Žymos / etiketės produktams, komandoms, aplinkoms ir funkcijoms ir pagal juos rengti išlaidų ataskaitas. Informacinėse lentelėse rodomos išlaidos pagal maršrutus ir įvykius; pastebėjus anomalijas, skamba pavojaus signalai. Kiekybiškai įvertinu numatytų lygiagrečių, saugojimo laikų, spartinančiosios atminties TTL ir saugojimo klasių poveikį. Jei funkcija turi nuolatinę didelę bazinę apkrovą, palyginu vieneto sąnaudas su taupia konteinerių paslauga ir priimu duomenimis pagrįstą sprendimą. Taip išlaikoma architektūra ekonominis o ne tik techniškai elegantiškas.
Greitas visame pasaulyje su "Edge
Dinamines dalis, kurioms nereikia didelės prieigos prie duomenų, talpinu tinklo pakraštyje, o HTML, JSON ir nedidelius transformacijos etapus pateikiu netoli tinklo. Vartotojas. Taip sutaupoma kelionių į duomenų centrą, sumažėja TTFB ir palengvėja duomenų perdavimo sistema. Personalizavimas naudojant slapukų / antraštės duomenis, geografinis nukreipimas, A/B testai ir funkcijų žymos vykdomi tiesiogiai PoP, o daug duomenų reikalaujančios užduotys lieka branduolyje. Norėdami pradėti, šis kompaktiškas Kraštų darbo eiga, kuri rodo, kad kraštinė ir pagrindinė logika yra aiškiai atskirtos. Svarbu: krašto taisykles dokumentavau taip, kad vėliau jas būtų galima patikrinti kodo peržiūrose, o ne CDN. pasidėti smėlio.
Eksploatavimas: "Runbooks", pavojaus signalai ir avariniai keliai
Apibrėžiu Veiklos knygos kiekvienai paslaugai: kokie pavojaus signalai suveikia, kokios metrikos yra svarbios, kokius jungiklius turiu (srauto ribojimas, pakartotinių bandymų skaičiaus reguliavimas, laikinas funkcijų išjungimas, statinių atsarginių puslapių pristatymas). Perdegimo greičio pavojaus signalai rodo, kaip greitai išnaudojamas klaidų biudžetas. Išorinėms priklausomybėms nustatau jungiklius, laiko limitus ir protingas numatytąsias reikšmes, kad naudotojo patirtį būtų galima optimizuoti nepaisant nesėkmių. patikimas likučiai.
Saugumas, atitiktis ir valdymas
Kuriu kuo mažiau leidimų, kiekvienai funkcijai skiriu atskirus vaidmenis ir neleidžiu per daug dalytis tinklu, kad sumažėtų atakos paviršius. pasilikti. Paslaptys, aš jas valdau centralizuotai, automatiškai jas sukuriu ir registruoju prieigą. Duomenų klasifikavimas man padeda apibrėžti kraštinius kelius, saugojimo vietas ir šifravimą pagal duomenų tipą. Naudodamas centralizuotą audito registravimą, nekintamus žurnalus ir perspėjimus apie neįprastus modelius, anksti aptinku incidentus. Gaires įtvirtinu kaip kodą saugyklose, kad komandos galėtų stebėti pakeitimus ir rimtai žiūrėti į peržiūras. patikrinkite.
Didesnė sauga ir atitiktis
Manau, kad Privatumas pagal dizainąMinimalus duomenų rinkimas, trumpas saugojimas, nuoseklūs ištrynimo būdai. Kiekvienai klasei skiriu duomenų buvimo vietą ir šifravimą ramybės būsenoje / transportavimą. Rūpinuosi tiekimo grandinės saugumu, naudodamasis parašais, priklausomybės skenavimu ir SBOM, kad incidento atveju galėčiau greitai įvertinti, kas paveikta. Tinklo apribojimus (išėjimo kontrolė, tik reikalingi galiniai taškai) ir WAF taisykles papildau mTLS tarp jautrių paslaugų.
Kontrolinis sąrašas prieš paleidimą
- SLOs apibrėžti ir įtvirtinti rodikliais ir (arba) rodyklėmis.
- Krašto taisyklės dokumentuotas, išbandytas, versijuotas
- Idempotencija ir pakartotiniai bandymai su DLQ
- Apribojimai (laiko tarpai, naudingoji apkrova, lygiagretumas) patvirtinta
- Duomenų keliai "karštųjų" ir (arba) sunkiųjų atskirtųjų, talpyklų su TTL/patvirtinimo funkcija
- ApsaugaMažiausios privilegijos, paslaptys, audito žurnalai, išėjimo kontrolė
- FinOpsŽymos, biudžetai, vieneto sąnaudų suvestinės
- Veiklos knygos, atsarginiai puslapiai, galimi rankiniai jungikliai
- TestaiPaskutinį kartą, Sutartys, Kanarėlės, Rollback praktikuojamas
2025 m. ir vėliau
Matau, kad serverless susijungia su konteineriais: darbo vietos vykdomos kaip funkcijos, ilgalaikės paslaugos "Fargate" arba į virtualiąją mašiną panašiuose ištekliuose, viskas per vamzdyną. valdomas. AI palaikomas automatinis mastelio keitimas, efektyvesnis veikimo laikas ir trumpesnis "šaltasis startas" mažina vėlavimus, o kraštinės platformos vis dažniau teikia personalizuotą turinį tiesiai į kraštą. Tvarumas tampa vis svarbesnis, nes mokant už naudojimą išvengiama prastovų, o pajėgumai dinamiškai reaguoja į realią paklausą. Teikėjai išplečia ribas, supaprastina derinimą paskirstytame kontekste ir pateikia daugiau apsaugos mechanizmų. Tie, kurie aktyviai prisideda prie šios plėtros, 2025 m. sukurs programas, kurios bus greitai paleidžiamos, teikiamos visame pasaulyje ir ekonomiškai gyvybingos. paleisti; išsamesnis vaizdas pateikiamas vertinant Be serverio veikiančios sistemos ateitis.
Trumpa santrauka
Aš naudoju beserverinę prieglobą 2025 būtent ten, kur svyruoja apimtis, skaičiuojamas išleidimo greitis ir būtinas visuotinis pristatymas, ir, jei reikia, derinu ją su konteineriais nuolatinei prieglobai. Paslaugos. Skaičiuodamas pagal kiekvieną įvykį ir teikdamas pirmenybę spartinimui, kraštinėms ir trumpam veikimo laikui, užtikrinu skaidrias sąnaudas. Iki minimumo sumažinu tokią riziką, kaip "šaltasis startas" ir tiekėjo užstrigimas, naudodamasis palaikymo strategijomis, perkeliamumu ir aiškiu atsakomybės atskyrimu. Saugumas, stebimumas ir testavimas man yra ne papildomi, o pagrindiniai kiekvieno vamzdyno komponentai. Taip užtikrinu patikimai veikiančias, biudžetą atitinkančias ir naudotojus visame pasaulyje greitai pasiekiančias funkcijas. pasiekti.
