Ovaj članak sadrži neke uobičajene obrasce koji pomažu inženjerima da rade s uslugama velikih razmjera kojima pristupaju milijuni korisnika.
Prema iskustvu autora, ovo nije potpuna lista, ali zaista efikasan savjetovati. Dakle, počnimo.
Prevedeno uz podršku .
Prvi nivo
Dolje navedene mjere su relativno jednostavne za implementaciju, ali imaju veliki učinak. Ako ih niste ranije isprobali, iznenadit ćete se značajnim poboljšanjima.
Infrastruktura kao kod
Prvi dio savjeta je implementacija infrastrukture kao koda. To znači da morate imati programski način za postavljanje cjelokupne infrastrukture. Zvuči komplikovano, ali zapravo govorimo o sljedećem kodu:
Postavljanje 100 virtuelnih mašina
- sa Ubuntuom
- 2 GB RAM-a svaki
- oni će imati sljedeći kod
- sa ovim parametrima
Možete pratiti promjene u vašoj infrastrukturi i brzo se vratiti na njih pomoću kontrole verzija.
Modernista u meni kaže da možete koristiti Kubernetes/Docker za sve gore navedeno, i u pravu je.
Osim toga, možete osigurati automatizaciju koristeći Chef, Puppet ili Terraform.
Kontinuirana integracija i isporuka
Da biste kreirali skalabilnu uslugu, važno je imati cevovod za izgradnju i testiranje za svaki zahtjev za povlačenjem. Čak i ako je test vrlo jednostavan, on će barem osigurati da se kod koji implementirate kompilira.
Svaki put u ovoj fazi odgovarate na pitanje: hoće li moj sklop kompajlirati i proći testove, da li je valjan? Ovo može izgledati kao niska traka, ali rješava mnogo problema.
Nema ništa ljepše nego vidjeti ove krpelje
Za ovu tehnologiju možete procijeniti Github, CircleCI ili Jenkins.
Load Balancers
Dakle, želimo pokrenuti balansiranje opterećenja kako bismo preusmjerili promet i osigurali jednako opterećenje na svim čvorovima ili će se usluga nastaviti u slučaju kvara:
Balansator opterećenja obično radi dobar posao u distribuciji saobraćaja. Najbolja praksa je da prebalansirate kako ne biste imali ni jednu tačku neuspjeha.
Obično se balanseri opterećenja konfigurišu u oblaku koji koristite.
RayID, ID korelacije ili UUID za zahtjeve
Da li ste ikada naišli na grešku aplikacije sa ovakvom porukom: „Nešto je pošlo po zlu. Sačuvajte ovaj ID i pošaljite ga našem timu za podršku"?
Jedinstveni identifikator, ID korelacije, RayID ili bilo koja od varijacija je jedinstveni identifikator koji vam omogućava da pratite zahtjev tokom njegovog životnog ciklusa. Ovo vam omogućava da pratite cijelu putanju zahtjeva u evidenciji.
Korisnik postavlja zahtjev sistemu A, zatim A kontaktira B, koji kontaktira C, pohranjuje ga u X, a zatim se zahtjev vraća A
Kada biste se daljinski povezali sa virtuelnim mašinama i pokušali da uđete u trag putanji zahteva (i da ručno povežete koji pozivi se upućuju), poludeli biste. Posjedovanje jedinstvenog identifikatora čini život mnogo lakšim. Ovo je jedna od najjednostavnijih stvari koje možete učiniti da uštedite vrijeme kako vaša usluga raste.
Srednji nivo
Ovdje su savjeti složeniji od prethodnih, ali pravi alati olakšavaju zadatak, osiguravajući povrat ulaganja čak i za mala i srednja preduzeća.
Centralizirana sječa
Čestitamo! Postavili ste 100 virtuelnih mašina. Sljedećeg dana dolazi izvršni direktor i žali se na grešku koju je dobio prilikom testiranja usluge. Izvještava o odgovarajućem ID-u o kojem smo gore govorili, ali ćete morati pregledati dnevnike 100 mašina da biste pronašli onu koja je izazvala pad. I to treba pronaći prije sutrašnje prezentacije.
Iako ovo zvuči kao zabavna avantura, najbolje je osigurati da imate mogućnost pretraživanja svih časopisa na jednom mjestu. Rešio sam problem centralizacije dnevnika koristeći ugrađenu funkcionalnost ELK steka: podržava kolekciju dnevnika koja se može pretraživati. Ovo će zaista pomoći u rješavanju problema pronalaska određenog časopisa. Kao bonus, možete kreirati grafikone i druge slične stvari.
ELK funkcionalnost steka
Nadzorni agenti
Sada kada je vaša usluga pokrenuta i radi, morate biti sigurni da radi glatko. Najbolji način da to učinite je pokretanje nekoliko agenti, koji rade paralelno i provjerite da li radi i da se izvode osnovne operacije.
U ovom trenutku to provjerite radna konstrukcija je dobra i radi dobro.
Za male i srednje projekte preporučujem Postman za praćenje i dokumentovanje API-ja. Ali općenito, samo želite biti sigurni da imate način da znate kada je došlo do prekida rada i da budete blagovremeno obaviješteni.
Automatsko skaliranje ovisno o opterećenju
Vrlo je jednostavno. Ako imate zahtjeve za servisiranje VM-a i on se približava 80% korištenja memorije, možete ili povećati njegove resurse ili dodati više VM-ova u klaster. Automatsko izvođenje ovih operacija je odlično za elastične promjene snage pod opterećenjem. Ali uvijek treba paziti koliko novca trošite i postaviti razumne granice.
Uz većinu usluga u oblaku, možete ga konfigurirati za automatsko skaliranje koristeći više servera ili moćnije servere.
Eksperiment sistem
Dobar način za sigurno uvođenje ažuriranja je mogućnost testiranja nečega za 1% korisnika na sat vremena. Vi ste, naravno, vidjeli takve mehanizme na djelu. Na primjer, Facebook prikazuje dijelove publike u drugoj boji ili mijenja veličinu fonta kako bi vidio kako korisnici percipiraju promjene. To se zove A/B testiranje.
Čak se i izdavanje nove funkcije može započeti kao eksperiment, a zatim odrediti kako će se objaviti. Takođe dobijate mogućnost da "zapamtite" ili promenite konfiguraciju u hodu na osnovu funkcije koja uzrokuje degradaciju vaše usluge.
napredni nivo
Evo savjeta koje je prilično teško implementirati. Vjerovatno će vam trebati malo više resursa, tako da će mala ili srednja kompanija imati poteškoća s tim.
Plavo-zeleno raspoređivanje
To je ono što ja nazivam "Erlang" načinom odvijanja. Erlang je postao široko korišten kada su se pojavile telefonske kompanije. Softswitchevi su se počeli koristiti za usmjeravanje telefonskih poziva. Glavna svrha softvera na ovim prekidačima bila je da ne ispušta pozive tokom nadogradnje sistema. Erlang ima dobar način učitavanja novog modula bez rušenja prethodnog.
Ovaj korak ovisi o prisutnosti balansera opterećenja. Zamislimo da imate verziju N vašeg softvera, a zatim želite da implementirate verziju N+1.
Ti mogao samo zaustavite uslugu i uvedite sljedeću verziju u vrijeme koje odgovara vašim korisnicima i dobijete malo vremena zastoja. Ali pretpostavimo da jeste stvarno strogi SLA uslovi. Dakle, SLA 99,99% znači da možete ići van mreže samo za 52 minuta godišnje.
Ako zaista želite postići takve pokazatelje, potrebne su vam dvije implementacije u isto vrijeme:
- onaj koji je upravo sada (N);
- sljedeća verzija (N+1).
Kažete balanseru opterećenja da preusmjeri postotak prometa na novu verziju (N+1) dok aktivno pratite regresije.
Ovdje imamo zelenu N implementaciju koja dobro funkcionira. Pokušavamo prijeći na sljedeću verziju ove implementacije
Prvo šaljemo zaista mali test da vidimo da li naša N+1 implementacija radi s malom količinom prometa:
Konačno, imamo set automatiziranih provjera koje na kraju izvodimo dok se ne završi naša implementacija. Ako ti veoma veoma oprezno, također možete zauvijek sačuvati svoju N implementaciju za brzo vraćanje unatrag u slučaju loše regresije:
Ako želite ići na još napredniji nivo, pustite da se sve u plavo-zelenoj implementaciji pokreće automatski.
Detekcija anomalija i automatsko ublažavanje
S obzirom da imate centralizirano evidentiranje i dobru kolekciju dnevnika, već možete postaviti više ciljeve. Na primjer, proaktivno predvidjeti neuspjehe. Funkcije se prate na monitorima i u zapisnicima i grade se različiti dijagrami - i možete unaprijed predvidjeti šta će poći po zlu:
Kada se otkriju anomalije, počinjete da ispitujete neke od naznaka koje pruža usluga. Na primjer, skok u opterećenju CPU-a može ukazivati na kvar tvrdog diska, dok nagli porast zahtjeva može ukazivati na to da morate povećati veličinu. Ova vrsta statističkih podataka vam omogućava da uslugu učinite proaktivnom.
Uz ove uvide, možete skalirati u bilo kojoj dimenziji i proaktivno i reaktivno mijenjati karakteristike strojeva, baza podataka, veza i drugih resursa.
To je sve!
Ova lista prioriteta će vam uštedjeti mnogo problema ako podižete uslugu u oblaku.
Autor originalnog članka poziva čitatelje da ostave svoje komentare i unesu izmjene. Članak je distribuiran kao open source, zahtjevi za povlačenje od strane autora .
Šta još pročitati na temu:
izvor: www.habr.com