Spodaj navedeni ukrepi so razmeroma enostavni za izvedbo, vendar imajo velik učinek. Če jih še niste poskusili, boste presenečeni nad občutnimi izboljšavami.
Infrastruktura kot koda
Prvi del nasveta je implementacija infrastrukture kot kode. To pomeni, da morate imeti programski način za namestitev celotne infrastrukture. Sliši se zapleteno, a dejansko govorimo o naslednji kodi:
Namestitev 100 virtualnih strojev
z Ubuntujem
2 GB RAM vsak
imeli bodo naslednjo kodo
s temi parametri
Spremembe svoje infrastrukture lahko spremljate in se nanje hitro vrnete z nadzorom različic.
Modernist v meni pravi, da lahko uporabite Kubernetes/Docker za vse našteto in ima prav.
Poleg tega lahko zagotovite avtomatizacijo z uporabo Chef, Puppet ali Terraform.
Nenehna integracija in dostava
Če želite ustvariti razširljivo storitev, je pomembno, da imate cevovod za gradnjo in testiranje za vsako zahtevo po vleku. Tudi če je preizkus zelo preprost, bo vsaj zagotovil, da se koda, ki jo uvedete, prevede.
Vsakič na tej stopnji odgovorite na vprašanje: ali bo moj sklop prevedel in opravil teste, ali je veljaven? To se morda zdi nizka letvica, vendar rešuje veliko težav.
Ni lepšega kot videti te klope
Za to tehnologijo lahko ocenite Github, CircleCI ali Jenkins.
Izravnalniki obremenitve
Želimo torej zagnati izravnalnik obremenitve za preusmeritev prometa in zagotoviti enako obremenitev vseh vozlišč ali pa se storitev nadaljuje v primeru okvare:
Izravnalnik obremenitve običajno dobro porazdeli promet. Najboljša praksa je, da nadzirate ravnotežje, da ne boste imeli niti ene točke napake.
Običajno so izravnalniki obremenitve konfigurirani v oblaku, ki ga uporabljate.
RayID, ID korelacije ali UUID za zahteve
Ali ste že kdaj naleteli na napako aplikacije s takšnim sporočilom: "Nekaj je šlo narobe. Shranite ta ID in ga pošljite naši skupini za podporo"?
Enolični identifikator, korelacijski ID, RayID ali katera koli različica je edinstven identifikator, ki vam omogoča sledenje zahtevi skozi njen življenjski cikel. To vam omogoča sledenje celotne poti zahteve v dnevnikih.
Uporabnik pošlje zahtevo sistemu A, nato A kontaktira B, ta kontaktira C, jo shrani v X, nato pa se zahteva vrne A
Če bi se na daljavo povezali z virtualnimi stroji in poskušali izslediti pot zahteve (in ročno povezati, kateri klici so opravljeni), bi se vam zmešalo. Z edinstvenim identifikatorjem je življenje veliko lažje. To je ena najpreprostejših stvari, ki jih lahko storite, da prihranite čas, ko vaša storitev raste.
Povprečna raven
Tukajšnji nasveti so bolj zapleteni od prejšnjih, vendar prava orodja olajšajo nalogo in zagotavljajo donosnost naložbe tudi za mala in srednje velika podjetja.
Centralizirano beleženje
čestitke! Namestili ste 100 virtualnih strojev. Naslednji dan pride izvršni direktor in se pritoži nad napako, ki jo je prejel med testiranjem storitve. Poroča o ustreznem ID-ju, o katerem smo govorili zgoraj, vendar boste morali pregledati dnevnike 100 strojev, da bi našli tistega, ki je povzročil zrušitev. In treba ga je najti pred jutrišnjo predstavitvijo.
Čeprav se to sliši kot zabavna dogodivščina, je najbolje, da zagotovite možnost iskanja po vseh revijah na enem mestu. Težavo centraliziranja dnevnikov sem rešil z vgrajeno funkcionalnostjo sklada ELK: podpira iskanje po zbiranju dnevnikov. To bo resnično pomagalo rešiti težavo pri iskanju določenega dnevnika. Kot bonus lahko ustvarite grafikone in druge podobne zabavne stvari.
Funkcionalnost sklada ELK
Nadzorni agenti
Zdaj, ko vaša storitev deluje, morate zagotoviti, da deluje brezhibno. Najboljši način za to je, da zaženete več zastopniki, ki delujejo vzporedno in preverjajo, ali deluje in se izvajajo osnovne operacije.
Na tej točki to preverite tekoča zgradba se počuti dobro in dobro deluje.
Za majhne do srednje velike projekte priporočam Postman za spremljanje in dokumentiranje API-jev. Toda na splošno se želite prepričati, ali imate možnost vedeti, kdaj je prišlo do izpada, in biti pravočasno obveščen.
Samodejno skaliranje glede na obremenitev
Je zelo preprosto. Če imate zahteve za servisiranje VM in se približuje 80-odstotni uporabi pomnilnika, lahko povečate njegove vire ali dodate več VM v gručo. Samodejno izvajanje teh operacij je odlično za elastične spremembe moči pod obremenitvijo. Vedno pa morate paziti, koliko denarja porabite, in postaviti razumne meje.
Pri večini storitev v oblaku jo lahko konfigurirate za samodejno prilagajanje z več strežniki ali zmogljivejšimi strežniki.
Eksperimentalni sistem
Dober način za varno uvajanje posodobitev je, da lahko eno uro testirate nekaj za 1 % uporabnikov. Takšne mehanizme ste seveda že videli v akciji. Na primer, Facebook dele občinstva prikaže z drugačno barvo ali spremeni velikost pisave, da vidi, kako uporabniki zaznavajo spremembe. To se imenuje A/B testiranje.
Celo objavo nove funkcije lahko začnete kot poskus in nato določite, kako jo izdati. Dobite tudi možnost, da si "zapomnite" ali sproti spreminjate konfiguracijo glede na funkcijo, ki povzroča poslabšanje vaše storitve.
Napredna raven
Tukaj so nasveti, ki jih je precej težko izvesti. Verjetno boste potrebovali malo več sredstev, zato bo malo ali srednje veliko podjetje to težko obvladalo.
Modro-zelene postavitve
Temu jaz pravim "Erlangov" način razpleta. Erlang se je začel široko uporabljati, ko so se pojavila telefonska podjetja. Programska stikala so se začela uporabljati za usmerjanje telefonskih klicev. Glavni namen programske opreme na teh stikalih je bil preprečiti prekinitev klicev med nadgradnjami sistema. Erlang ima lep način za nalaganje novega modula, ne da bi zrušil prejšnjega.
Ta korak je odvisen od prisotnosti izravnalnika obremenitve. Predstavljajmo si, da imate različico N vaše programske opreme, nato pa želite uvesti različico N+1.
Ti lahko bi samo ustavite storitev in uvedite naslednjo različico ob času, ki ustreza vašim uporabnikom, in si zagotovite nekaj izpadov. Toda predpostavimo, da imate res strogi pogoji SLA. Torej SLA 99,99 % pomeni, da lahko prekinete povezavo Samo za 52 minut na leto.
Če res želite doseči takšne kazalnike, potrebujete dve uvedbi hkrati:
tisti, ki je prav zdaj (N);
naslednja različica (N+1).
Izravnalniku obremenitve naročite, naj preusmeri odstotek prometa na novo različico (N+1), medtem ko vi aktivno spremljate regresije.
Tukaj imamo zeleno uvedbo N, ki dobro deluje. Poskušamo preiti na naslednjo različico te uvedbe
Najprej pošljemo res majhen preizkus, da vidimo, ali naša uvedba N+1 deluje z majhno količino prometa:
Končno imamo nabor samodejnih preverjanj, ki jih sčasoma izvajamo, dokler naša uvedba ni končana. Če ti zelo zelo previdni, svojo uvedbo N lahko tudi za vedno shranite za hitro povrnitev v prejšnje stanje v primeru slabe regresije:
Če želite iti na še naprednejšo raven, pustite, da se vse v modro-zeleni uvedbi izvaja samodejno.
Zaznavanje anomalij in samodejno ublažitev
Glede na to, da imate centralizirano sečnjo in dobro zbiranje hlodov, si že lahko postavite višje cilje. Na primer, proaktivno napovedujte napake. Funkcije se spremljajo na monitorjih in v dnevnikih ter sestavljajo različni diagrami - in vnaprej lahko napoveste, kaj bo šlo narobe:
Ko so odkrite anomalije, začnete preučevati nekatere namige, ki jih ponuja storitev. Na primer, skok v obremenitvi procesorja lahko pomeni, da je trdi disk odpovedal, medtem ko skok v zahtevah lahko pomeni, da morate povečati obseg. Tovrstni statistični podatki vam omogočajo, da storitev naredite proaktivno.
S temi vpogledi lahko prilagajate poljubno dimenzijo ter proaktivno in reaktivno spreminjate značilnosti strojev, baz podatkov, povezav in drugih virov.
To je vse!
Ta seznam prednostnih nalog vam bo prihranil veliko težav, če postavljate storitev v oblaku.
Avtor izvirnega članka vabi bralce, da pustijo svoje komentarje in spremenijo. Članek se distribuira kot odprtokoden, avtor zahteva vlečenje sprejema na Githubu.