Proveli ste mjesece redizajnirajući svoj monolit u mikroservise, i konačno su se svi okupili da pritisnu prekidač. Odete na prvu web stranicu... i ništa se ne događa. Ponovno ga učitate - i opet ništa dobro, stranica je toliko spora da ne odgovara nekoliko minuta. Što se dogodilo?
U svom govoru, Jimmy Bogard će provesti "post mortem" katastrofe mikroservisa u stvarnom životu. Pokazat će probleme modeliranja, razvoja i proizvodnje koje je otkrio te kako je njegov tim polako transformirao novi distribuirani monolit u konačnu sliku razuma. Iako je nemoguće u potpunosti spriječiti pogreške u dizajnu, probleme možete barem identificirati rano u procesu dizajna kako biste osigurali da konačni proizvod postane pouzdan distribuirani sustav.
Pozdrav svima, ja sam Jimmy i danas ćete čuti kako možete izbjeći mega katastrofe prilikom izgradnje mikroservisa. Ovo je priča o tvrtki za koju sam radio oko godinu i pol kako bih pomogao spriječiti sudar njihovog broda s santom leda. Da bismo pravilno ispričali ovu priču, morat ćemo se vratiti u prošlost i razgovarati o tome gdje je ova tvrtka započela i kako je njena IT infrastruktura rasla tijekom vremena. Kako bih zaštitio imena nevinih u ovoj katastrofi, promijenio sam ime ove tvrtke u Bell Computers. Sljedeći slajd pokazuje kako je izgledala IT infrastruktura takvih tvrtki sredinom 90-ih. Ovo je tipična arhitektura velikog univerzalnog HP Tandem Mainframe poslužitelja otpornog na greške za upravljanje trgovinom računalnog hardvera.
Trebali su izgraditi sustav za upravljanje svim narudžbama, prodajom, povratima, katalozima proizvoda i bazom kupaca, pa su odabrali najčešće rješenje glavnog računala u to vrijeme. Ovaj divovski sustav sadržavao je svaku informaciju o tvrtki, sve moguće, a svaka se transakcija provodila putem ovog glavnog računala. Držali su sva jaja u jednoj košari i mislili su da je to normalno. Jedino što ovdje nije uključeno je naručivanje kataloga poštom i narudžba putem telefona.
S vremenom je sustav postajao sve veći i veći, au njemu se nakupila ogromna količina smeća. Također, COBOL nije najizražajniji jezik na svijetu, pa je sustav završio kao veliko, monolitno smeće. Do 2000. godine vidjeli su da mnoge tvrtke imaju web stranice preko kojih obavljaju apsolutno sve svoje poslove i odlučili su izgraditi svoju prvu komercijalnu dot-com web stranicu.
Početni dizajn izgledao je prilično lijepo i sastojao se od web stranice najviše razine bell.com i niza poddomena za pojedinačne aplikacije: catalog.bell.com, accounts.bell.com, orders.bell.com, search.bell za pretraživanje proizvoda. com. Svaka poddomena koristila je okvir ASP.Net 1.0 i vlastite baze podataka, a sve su komunicirale s pozadinom sustava. Međutim, sve su se narudžbe nastavile obrađivati i izvršavati unutar jednog golemog glavnog računala, u kojem je ostalo sve smeće, ali prednji dio su bile zasebne web stranice s pojedinačnim aplikacijama i zasebnim bazama podataka.
Dakle, dizajn sustava izgledao je uredno i logično, ali je stvarni sustav bio onakav kakav je prikazan na sljedećem slajdu.
Svi elementi upućivali su pozive jedni drugima, pristupali API-jima, ugrađenim dll-ovima trećih strana i slično. Često se događalo da bi sustavi za kontrolu verzija zgrabili tuđi kod, ugurali ga u projekt i onda bi se sve pokvarilo. MS SQL Server 2005 koristio je koncept poslužitelja poveznica, i iako nisam pokazao strelice na slajdu, svaka od baza podataka je također razgovarala jedna s drugom, jer nema ništa loše u izgradnji tablica na temelju podataka dobivenih iz nekoliko baza podataka.
Budući da su sada imali određeno odvajanje između različitih logičkih područja sustava, to su postale raspoređene mrlje prljavštine, s najvećim komadom smeća koji je i dalje ostao u pozadini glavnog računala.
Smiješno je to što su ovo glavno računalo izgradili konkurenti tvrtke Bell Computers, a još uvijek su ga održavali njihovi tehnički konzultanti. Uvjereni u nezadovoljavajuću izvedbu svojih aplikacija, tvrtka ih se odlučila riješiti i redizajnirati sustav.
Postojeća aplikacija radila je 15 godina, što je rekord za aplikacije temeljene na ASP.Netu. Usluga je primala narudžbe iz cijelog svijeta, a godišnji prihod od ove jedne aplikacije dosegnuo je milijardu dolara. Značajan dio dobiti ostvarila je web stranica bell.com. Crnim petkom broj narudžbi putem stranice dosegnuo je nekoliko milijuna. Međutim, postojeća arhitektura nije dopuštala nikakav razvoj, budući da krute međusobne veze elemenata sustava praktički nisu dopuštale nikakve promjene usluge.
Najozbiljniji problem bila je nemogućnost naručivanja iz jedne zemlje, plaćanja u drugoj i slanja u treću, unatoč činjenici da je takva shema trgovanja vrlo česta u svjetskim tvrtkama. Postojeća web stranica nije dopuštala tako nešto, pa su te narudžbe morali prihvaćati i slati putem telefona. To je dovelo do toga da tvrtka sve više razmišlja o promjeni arhitekture, posebice o prelasku na mikroservise.
Učinili su pametnu stvar pogledavši druge tvrtke kako bi vidjeli kako su riješile sličan problem. Jedno od tih rješenja bila je Netflix servisna arhitektura koja se sastoji od mikroservisa povezanih preko API-ja i vanjske baze podataka.
Uprava Bell Computersa odlučila je izgraditi upravo takvu arhitekturu, pridržavajući se određenih osnovnih načela. Prvo, eliminirali su dupliciranje podataka korištenjem pristupa dijeljene baze podataka. Podaci nisu slani, naprotiv, svi koji su trebali morali su ići na centralizirani izvor. Slijedila je izolacija i autonomija – svaka je služba bila neovisna o drugima. Odlučili su koristiti Web API za apsolutno sve – ako ste željeli dobiti podatke ili napraviti promjene na drugom sustavu, sve se to radilo preko Web API-ja. Posljednja velika stvar bilo je novo glavno računalo nazvano "Bell on Bell" za razliku od "Bell" glavnog računala temeljenog na hardveru konkurenata.
Dakle, tijekom 18 mjeseci izgradili su sustav oko ovih temeljnih načela i doveli ga do predprodukcije. Vrativši se na posao nakon vikenda, programeri su se okupili i uključili sve servere na koje je bio spojen novi sustav. 18 mjeseci rada, stotine programera, najsuvremeniji Bellov hardver - a nijedan pozitivan rezultat! Ovo je razočaralo mnoge ljude jer su ovaj sustav pokretali na svojim prijenosnim računalima mnogo puta i sve je bilo u redu.
Bili su pametni baciti sav svoj novac na rješavanje ovog problema. Ugradili su najmodernije serverske regale sa switchevima, upotrijebili gigabitnu optičku vlaknu, najjači serverski hardver sa suludom količinom RAM-a, sve to spojili, konfigurirali – i opet ništa! Tada su počeli sumnjati da bi razlog mogao biti timeouts, pa su ušli u sve web postavke, sve API postavke i ažurirali cijelu konfiguraciju timeouta na maksimalne vrijednosti, tako da su jedino mogli sjediti i čekati da se nešto dogodi na stranicu. Čekali su i čekali i čekali 9 i pol minuta dok se web stranica konačno nije učitala.
Nakon toga im je sinulo da trenutnu situaciju treba temeljito analizirati te su nas pozvali. Prvo što smo saznali je da tijekom svih 18 mjeseci razvoja nije stvoren niti jedan pravi “mikro” - sve je samo postalo veće. Nakon toga, počeli smo pisati post-mortem, također poznat kao "retrospektiva", ili "tužna retrospektiva", također poznat kao "oluja krivaca", slično "oluji mozga", kako bismo razumjeli uzrok katastrofe.
Imali smo nekoliko tragova, a jedan od njih je bila potpuna zasićenost prometa u vrijeme API poziva. Kada koristite monolitnu servisnu arhitekturu, odmah možete shvatiti što je točno pošlo po zlu jer imate jedno praćenje hrpa koje izvještava o svemu što je moglo uzrokovati kvar. U slučaju da hrpa servisa istovremeno pristupa istom API-ju, ne postoji način za praćenje traga osim korištenja dodatnih alata za nadzor mreže poput WireSharka, zahvaljujući kojima možete ispitati jedan zahtjev i saznati što se dogodilo tijekom njegove implementacije. Stoga smo uzeli jednu web stranicu i proveli gotovo 2 tjedna slažući dijelove slagalice, upućujući joj razne pozive i analizirajući čemu je svaki od njih doveo.
Pogledaj ovu sliku. Pokazuje da jedan vanjski zahtjev navodi uslugu na mnogo internih poziva koji se vraćaju. Ispada da svaki interni poziv čini dodatne skokove kako bi mogao samostalno servisirati ovaj zahtjev, jer se ne može obratiti nigdje drugdje za dobivanje potrebnih informacija. Ova slika izgleda kao besmislena kaskada poziva, budući da vanjski zahtjev poziva dodatne usluge, koje pozivaju druge dodatne usluge i tako dalje, gotovo ad infinitum.
Zelena boja na ovom dijagramu pokazuje polukrug u kojem servisi pozivaju jedni druge - servis A poziva servis B, servis B poziva servis C, i ponovno poziva servis A. Kao rezultat, dobivamo "distribuirani zastoj". Jedan zahtjev stvorio je tisuću mrežnih API poziva, a budući da sustav nije imao ugrađenu toleranciju grešaka i zaštitu od petlje, zahtjev bi propao ako čak i jedan od ovih API poziva ne uspije.
Malo smo računali. Svaki API poziv imao je SLA od najviše 150 ms i 99,9% neprekidnog rada. Jedan zahtjev je uzrokovao 200 različitih poziva, au najboljem slučaju stranica bi se mogla prikazati za 200 x 150 ms = 30 sekundi. Naravno, ovo nije bilo dobro. Množenjem 99,9% radnog vremena s 200, dobili smo 0% dostupnosti. Ispostavilo se da je ta arhitektura od samog početka bila osuđena na propast.
Pitali smo programere kako nakon 18 mjeseci rada nisu prepoznali ovaj problem? Ispostavilo se da su računali samo SLA za kod koji su pokrenuli, ali ako je njihova usluga pozvala drugu uslugu, nisu računali to vrijeme u svom SLA-u. Sve što je pokrenuto unutar jednog procesa držalo se vrijednosti od 150 ms, ali je pristup drugim uslužnim procesima višestruko povećao ukupno kašnjenje. Prva naučena lekcija bila je: "Kontrolirate li vi svoj SLA ili SLA kontrolira vas?" U našem slučaju bilo je ovo drugo.
Sljedeća stvar koju smo otkrili je da su znali za koncept zabluda o distribuiranom računalstvu, koji su formulirali Peter Deitch i James Gosling, ali su zanemarili prvi dio toga. Navodi da su izjave "mreža pouzdana", "nula latencija" i "beskonačna propusnost" pogrešne predodžbe. Druge zablude uključuju izjave "mreža je sigurna", "topologija se nikada ne mijenja", "uvijek postoji samo jedan administrator", "cijena prijenosa podataka je nula" i "mreža je homogena".
Pogriješili su jer su svoju uslugu testirali na lokalnim strojevima i nikada se nisu spojili na vanjske usluge. Prilikom lokalnog razvoja i korištenja lokalne predmemorije nikada se nisu susreli s mrežnim skokovima. U svih 18 mjeseci razvoja niti jednom se nisu zapitali što bi se moglo dogoditi ako bi bile pogođene vanjske usluge.
Ako pogledate granice usluge na prethodnoj slici, možete vidjeti da su sve netočne. Postoji mnogo izvora koji savjetuju kako definirati granice usluga, a većina to čini pogrešno, poput Microsofta na sljedećem slajdu.
Ova slika je s MS bloga na temu “Kako izgraditi mikroservise”. Ovo prikazuje jednostavnu web aplikaciju, blok poslovne logike i bazu podataka. Zahtjev dolazi izravno, vjerojatno postoji jedan poslužitelj za web, jedan za posao i jedan za bazu podataka. Ako povećate promet, slika će se malo promijeniti.
Ovdje dolazi balanser opterećenja za raspodjelu prometa između dva web poslužitelja, predmemorije koja se nalazi između web usluge i poslovne logike i druge predmemorije između poslovne logike i baze podataka. Upravo je to arhitektura koju je Bell koristio za svoju aplikaciju za balansiranje opterećenja i plavo/zelenu implementaciju sredinom 2000-ih. Do nekog vremena sve je dobro funkcioniralo, jer je ova shema bila namijenjena monolitnoj strukturi.
Sljedeća slika prikazuje kako MS preporučuje prelazak s monolita na mikroservise – jednostavno razdvajanje svake od glavnih usluga u zasebne mikroservise. Bell je pogriješio tijekom provedbe ove sheme.
Podijelili su sve svoje usluge u različite razine, od kojih se svaka sastojala od mnogo pojedinačnih usluga. Na primjer, web servis je uključivao mikroservise za renderiranje sadržaja i autentifikaciju, servis poslovne logike sastojao se od mikroservisa za obradu naloga i informacija o računu, baza podataka je bila podijeljena na hrpu mikroservisa sa specijaliziranim podacima. I web, poslovna logika i baza podataka bile su usluge bez stanja.
Međutim, ta je slika bila potpuno pogrešna jer nije mapirala niti jednu poslovnu jedinicu izvan IT klastera tvrtke. Ova shema nije uzimala u obzir nikakvu vezu s vanjskim svijetom, pa nije bilo jasno kako, primjerice, dobiti poslovnu analitiku treće strane. Napominjem da su također imali nekoliko usluga izmišljenih samo za razvoj karijere pojedinih zaposlenika koji su nastojali upravljati što većim brojem ljudi kako bi za to dobili više novca.
Vjerovali su da je prelazak na mikroservise jednostavan kao preuzimanje njihove interne N-slojne infrastrukture fizičkog sloja i postavljanje Dockera na nju. Pogledajmo kako izgleda tradicionalna N-slojna arhitektura.
Sastoji se od 4 razine: razine korisničkog sučelja korisničkog sučelja, razine poslovne logike, razine pristupa podacima i baze podataka. Progresivniji je DDD (Domain-Driven Design) ili softverski orijentirana arhitektura, gdje su dvije srednje razine objekti domene i repozitorij.
Pokušao sam sagledati različita područja promjene, različita područja odgovornosti u ovoj arhitekturi. U tipičnoj primjeni s N slojeva klasificiraju se različita područja promjene koja prožimaju strukturu okomito od vrha do dna. To su Katalog, postavke konfiguracije koje se izvode na pojedinačnim računalima i Checkout provjere, kojima je upravljao moj tim.
Posebnost ove sheme je da granice ovih područja promjena utječu ne samo na razinu poslovne logike, već se protežu i na bazu podataka.
Pogledajmo što znači biti usluga. Postoji 6 karakterističnih svojstava definicije usluge - to je softver koji:
- kreirana i korištena od strane određene organizacije;
- odgovoran je za sadržaj, obradu i/ili pružanje određene vrste informacija unutar sustava;
- može se izgraditi, postaviti i pokrenuti neovisno kako bi se zadovoljile specifične operativne potrebe;
- komunicira s potrošačima i drugim uslugama, dajući informacije na temelju sporazuma ili ugovornih jamstava;
- štiti sebe od neovlaštenog pristupa, a svoje podatke od gubitka;
- rješava kvarove na takav način da ne dovode do oštećenja informacija.
Sva ova svojstva mogu se izraziti jednom riječju “autonomija”. Servisi djeluju neovisno jedan o drugom, zadovoljavaju određena ograničenja i definiraju ugovore na temelju kojih ljudi mogu dobiti informacije koje su im potrebne. Nisam spomenuo konkretne tehnologije, čija je upotreba razumljiva.
Sada pogledajmo definiciju mikroservisa:
- mikroservis je male veličine i dizajniran za rješavanje jednog specifičnog problema;
- Mikroservis je autonoman;
- Prilikom izrade mikroservisne arhitekture koristi se metafora urbanističkog planiranja. Ovo je definicija iz knjige Sama Newmana, Building Microservices.
Definicija ograničenog konteksta preuzeta je iz knjige Erica Evansa Domain-Driven Design. Ovo je temeljni obrazac u DDD-u, centru za dizajn arhitekture koji radi s volumetrijskim arhitektonskim modelima, dijeleći ih u različite ograničene kontekste i eksplicitno definirajući interakcije između njih.
Jednostavno rečeno, ograničeni kontekst označava opseg u kojem se određeni modul može koristiti. Unutar ovog konteksta je logički unificiran model koji se može vidjeti, na primjer, u vašoj poslovnoj domeni. Ako pitate “tko je klijent” osoblje koje se bavi narudžbama, dobit ćete jednu definiciju, ako pitate one koji se bave prodajom, dobit ćete drugu, a izvođači će vam dati treću definiciju.
Dakle, Ograničeni kontekst kaže da ako ne možemo dati jasnu definiciju onoga što je potrošač naših usluga, definirajmo granice unutar kojih možemo govoriti o značenju ovog pojma, a zatim definirajmo prijelazne točke između ovih različitih definicija. Odnosno, ako govorimo o klijentu sa stajališta narudžbe, ovo znači to i to, a ako sa stajališta prodaje, ovo znači to i to.
Sljedeća definicija mikroservisa je enkapsulacija bilo koje vrste internih operacija, sprječavajući “curenje” komponenti radnog procesa u okolinu. Slijedi "definicija eksplicitnih ugovora za vanjske interakcije ili vanjske komunikacije", koja je predstavljena idejom ugovora koji se vraćaju iz SLA-ova. Posljednja definicija je metafora ćelije, odnosno ćelije, što znači potpunu enkapsulaciju skupa operacija unutar mikroservisa i prisutnost u njemu receptora za komunikaciju s vanjskim svijetom.
Pa smo rekli momcima iz Bell Computersa: "Ne možemo popraviti ništa od kaosa koji ste stvorili jer jednostavno nemate novca za to, ali ćemo popraviti samo jednu uslugu kako bismo sve učinili osjećaj." U ovom trenutku, počet ću vam reći kako smo popravili našu jedinu uslugu tako da je na zahtjeve odgovarala brže od 9 i pol minuta.
22:30 min
Nastavak uskoro...
Malo reklame
Hvala što ste ostali s nama. Sviđaju li vam se naši članci? Želite li vidjeti više zanimljivog sadržaja? Podržite nas narudžbom ili preporukom prijateljima, , jedinstveni analog poslužitelja početne razine, koji smo izmislili za vas: (dostupno s RAID1 i RAID10, do 24 jezgre i do 40 GB DDR4).
Dell R730xd 2 puta jeftiniji u Equinix Tier IV podatkovnom centru u Amsterdamu? Samo ovdje u Nizozemskoj! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 USD! Pročitaj o
Izvor: www.habr.com