Du har brukt måneder på å redesigne monolitten din til mikrotjenester, og endelig har alle kommet sammen for å snu bryteren. Du går til den første nettsiden... og ingenting skjer. Du laster den inn på nytt - og igjen ingenting bra, siden er så treg at den ikke svarer på flere minutter. Hva skjedde?
I sitt foredrag vil Jimmy Bogard gjennomføre en "post-mortem" på en virkelig mikrotjenestekatastrofe. Han vil vise modellerings-, utviklings- og produksjonsproblemene han oppdaget, og hvordan teamet hans sakte forvandlet den nye distribuerte monolitten til det endelige bildet av fornuft. Selv om det er umulig å fullstendig forhindre designfeil, kan du i det minste identifisere problemer tidlig i designprosessen for å sikre at sluttproduktet blir et pålitelig distribuert system.
Hei alle sammen, jeg heter Jimmy og i dag skal du høre hvordan du kan unngå megakatastrofer når du bygger mikrotjenester. Dette er historien om et selskap jeg jobbet for i omtrent ett og et halvt år for å forhindre at skipet deres kolliderer med et isfjell. For å fortelle denne historien ordentlig, må vi gå tilbake i tid og snakke om hvor dette selskapet startet og hvordan IT-infrastrukturen har vokst over tid. For å beskytte navnene på de uskyldige i denne katastrofen, har jeg endret navnet på dette selskapet til Bell Computers. Neste lysbilde viser hvordan IT-infrastrukturen til slike selskaper så ut på midten av 90-tallet. Dette er en typisk arkitektur for en stor universell feiltolerant HP Tandem Mainframe-server for drift av en maskinvarebutikk.
De trengte å bygge et system for å administrere alle bestillinger, salg, returer, produktkataloger og kundebase, så de valgte den vanligste stormaskinløsningen den gangen. Dette gigantiske systemet inneholdt hver eneste bit av informasjon om selskapet, alt mulig, og hver transaksjon ble utført gjennom denne stormaskinen. De holdt alle eggene sine i en kurv og trodde det var normalt. Det eneste som ikke er inkludert her er postordrekataloger og bestilling på telefon.
Over tid ble systemet større og større, og det samlet seg en enorm mengde søppel i det. COBOL er heller ikke det mest uttrykksfulle språket i verden, så systemet endte opp med å bli et stort, monolittisk søppel. I 2000 så de at mange selskaper hadde nettsteder som de drev absolutt all virksomhet gjennom, og bestemte seg for å bygge sitt første kommersielle dot-com-nettsted.
Den opprinnelige designen så ganske fin ut og besto av et toppnivånettsted bell.com og en rekke underdomener for individuelle applikasjoner: catalog.bell.com, accounts.bell.com, orders.bell.com, produktsøk search.bell. com. Hvert underdomene brukte ASP.Net 1.0-rammeverket og sine egne databaser, og de snakket alle med systemets backend. Imidlertid fortsatte alle bestillinger å bli behandlet og utført innenfor en enkelt stor stormaskin, der alt søppelet ble igjen, men frontenden var separate nettsteder med individuelle applikasjoner og separate databaser.
Så utformingen av systemet så ryddig og logisk ut, men selve systemet var som vist i neste lysbilde.
Alle elementer adresserte kall til hverandre, åpnet APIer, innebygde tredjeparts dll-er og lignende. Det hendte ofte at versjonskontrollsystemer tok tak i andres kode, dyttet den inn i prosjektet, og så ville alt gå i stykker. MS SQL Server 2005 brukte konseptet lenkeservere, og selv om jeg ikke viste pilene på lysbildet, snakket også hver av databasene sammen, fordi det ikke er noe galt med å bygge tabeller basert på data hentet fra flere databaser .
Siden de nå hadde et visst skille mellom ulike logiske områder av systemet, ble dette distribuerte smussklatter, med det største søppelet som fortsatt var igjen i stormaskinens backend.
Det morsomme var at denne stormaskinen ble bygget av konkurrenter til Bell Computers og fortsatt ble vedlikeholdt av deres tekniske konsulenter. Overbevist om den utilfredsstillende ytelsen til applikasjonene, bestemte selskapet seg for å kvitte seg med dem og redesigne systemet.
Den eksisterende applikasjonen hadde vært i produksjon i 15 år, noe som er rekord for ASP.Net-baserte applikasjoner. Tjenesten aksepterte bestillinger fra hele verden, og årlige inntekter fra denne enkeltapplikasjonen nådde en milliard dollar. En betydelig del av overskuddet ble generert av nettstedet bell.com. På Black Fridays nådde antallet bestillinger som ble lagt gjennom nettstedet flere millioner. Den eksisterende arkitekturen tillot imidlertid ingen utvikling, siden de stive sammenkoblingene av systemelementer praktisk talt ikke tillot noen endringer i tjenesten.
Det mest alvorlige problemet var manglende evne til å legge inn en ordre fra ett land, betale for det i et annet og sende det til et tredje, til tross for at en slik handelsordning er veldig vanlig i globale selskaper. Den eksisterende nettsiden tillot ikke noe slikt, så de måtte akseptere og legge inn disse bestillingene over telefon. Dette førte til at selskapet i økende grad tenkte på å endre arkitekturen, spesielt på å gå over til mikrotjenester.
De gjorde det smarte ved å se på andre selskaper for å se hvordan de hadde løst et lignende problem. En av disse løsningene var Netflix-tjenestearkitekturen, som består av mikrotjenester koblet sammen via en API og en ekstern database.
Bell Computers-ledelsen bestemte seg for å bygge nettopp en slik arkitektur, og fulgte visse grunnleggende prinsipper. For det første eliminerte de dataduplisering ved å bruke en delt databasetilnærming. Ingen data ble sendt, tvert imot måtte alle som trengte det gå til en sentralisert kilde. Dette ble etterfulgt av isolasjon og autonomi - hver tjeneste var uavhengig av de andre. De bestemte seg for å bruke Web API til absolutt alt - hvis du ønsket å få data eller gjøre endringer i et annet system, ble det hele gjort gjennom Web API. Den siste store tingen var en ny stormaskin kalt "Bell on Bell" i motsetning til "Bell" stormaskinen basert på konkurrentenes maskinvare.
Så i løpet av 18 måneder bygde de systemet rundt disse kjerneprinsippene og brakte det til pre-produksjon. Da de kom tilbake på jobb etter helgen, tok utviklerne seg sammen og skrudde på alle serverne som det nye systemet var koblet til. 18 måneders arbeid, hundrevis av utviklere, den mest moderne Bell-maskinvaren - og ikke noe positivt resultat! Dette har skuffet mange mennesker fordi de har kjørt dette systemet på sine bærbare datamaskiner mange ganger, og alt var bra.
De var smarte til å kaste alle pengene sine på å løse dette problemet. De installerte de mest moderne serverrackene med brytere, brukte gigabit optisk fiber, den kraftigste servermaskinvaren med en vanvittig mengde RAM, koblet til alt, konfigurerte det – og igjen, ingenting! Så begynte de å mistenke at årsaken kunne være timeouts, så de gikk inn i alle nettinnstillingene, alle API-innstillingene og oppdaterte hele timeout-konfigurasjonen til maksimalverdiene, slik at alt de kunne gjøre var å sitte og vente på at noe skulle skje til nettstedet. De ventet og ventet og ventet i 9 og et halvt minutt til nettsiden endelig ble lastet.
Etter det gikk det opp for dem at dagens situasjon trengte en grundig analyse, og de inviterte oss. Det første vi fant ut var at i løpet av alle de 18 månedene med utvikling ble det ikke opprettet en eneste ekte "mikro" - alt ble bare større. Etter dette begynte vi å skrive en post mortem, også kjent som et "retrospektiv", eller "trist retrospektiv", også kjent som en "skyldestorm", som ligner på en "hjernestorm", for å forstå årsaken til katastrofen.
Vi hadde flere ledetråder, hvorav en var fullstendig trafikkmetning på tidspunktet for API-kallet. Når du bruker en monolittisk tjenestearkitektur, kan du umiddelbart forstå hva som gikk galt fordi du har en enkelt stabelsporing som rapporterer alt som kunne ha forårsaket feilen. I tilfellet der en haug med tjenester samtidig får tilgang til samme API, er det ingen måte å spore sporet bortsett fra å bruke ekstra nettverksovervåkingsverktøy som WireShark, takket være at du kan undersøke en enkelt forespørsel og finne ut hva som skjedde under implementeringen. Så vi tok én nettside og brukte nesten 2 uker på å sette sammen bitene i puslespillet, ringe til den og analysere hva hver av dem førte til.
Se på dette bildet. Den viser at én ekstern forespørsel ber tjenesten om å foreta mange interne anrop som går tilbake. Det viser seg at hvert internt anrop gjør ytterligere hopp for å kunne betjene denne forespørselen uavhengig, fordi den ikke kan henvende seg noe annet sted for å få den nødvendige informasjonen. Dette bildet ser ut som en meningsløs kaskade av samtaler, ettersom den eksterne forespørselen kaller tilleggstjenester, som kaller andre tilleggstjenester, og så videre, nesten i det uendelige.
Den grønne fargen i dette diagrammet viser en halvsirkel der tjenester ringer hverandre - tjeneste A ringer tjeneste B, tjeneste B ringer tjeneste C, og den kaller igjen tjeneste A. Som et resultat får vi en "distribuert vranglås". En enkelt forespørsel skapte tusen nettverks-API-kall, og siden systemet ikke hadde innebygd feiltoleranse og sløyfebeskyttelse, ville forespørselen mislykkes hvis til og med ett av disse API-kallene mislyktes.
Vi gjorde litt matematikk. Hvert API-kall hadde en SLA på ikke mer enn 150 ms og 99,9 % oppetid. En forespørsel forårsaket 200 forskjellige anrop, og i beste fall kunne siden vises på 200 x 150 ms = 30 sekunder. Naturligvis var dette ikke bra. Ved å multiplisere 99,9 % oppetid med 200 fikk vi 0 % tilgjengelighet. Det viser seg at denne arkitekturen var dømt til å mislykkes helt fra begynnelsen.
Vi spurte utviklerne hvordan de ikke klarte å gjenkjenne dette problemet etter 18 måneders arbeid? Det viste seg at de kun telte SLA for koden de kjørte, men hvis tjenesten deres kalte en annen tjeneste, telte de ikke den tiden i SLAen. Alt som ble lansert i én prosess holdt seg til en verdi på 150 ms, men tilgang til andre tjenesteprosesser økte den totale forsinkelsen mange ganger. Den første leksjonen var: "Har du kontroll over SLAen din, eller har SLAen kontroll over deg?" I vårt tilfelle var det sistnevnte.
Det neste vi oppdaget var at de visste om konseptet med distribuert databehandling misoppfatninger, formulert av Peter Deitch og James Gosling, men de ignorerte den første delen av det. Den sier at utsagnene "nettverket er pålitelig", "null latens" og "uendelig gjennomstrømning" er misoppfatninger. Andre misoppfatninger inkluderer påstandene «nettverket er sikkert», «topologien endres aldri», «det er alltid bare én administrator», «kostnaden for dataoverføring er null» og «nettverket er homogent».
De gjorde en feil fordi de testet tjenesten deres på lokale maskiner og aldri koblet til eksterne tjenester. Når de utviklet lokalt og brukte en lokal cache, møtte de aldri nettverkshopp. I alle 18 måneder med utvikling har de aldri lurt på hva som kan skje hvis eksterne tjenester ble berørt.
Hvis du ser på tjenestegrensene i forrige bilde, kan du se at alle er feil. Det er mange kilder som gir råd om hvordan du definerer tjenestegrenser, og de fleste gjør det feil, som Microsoft på neste lysbilde.
Dette bildet er fra MS-bloggen om emnet "Hvordan bygge mikrotjenester". Dette viser en enkel nettapplikasjon, en blokk med forretningslogikk og en database. Forespørselen kommer direkte, det er sannsynligvis en server for nettet, en server for bedriften og en for databasen. Øker du trafikken vil bildet endre seg litt.
Her kommer en lastbalanser for å distribuere trafikk mellom to webservere, en cache som ligger mellom webtjenesten og forretningslogikken, og en annen cache mellom forretningslogikken og databasen. Dette er nøyaktig arkitekturen Bell brukte for sin lastbalansering og blå/grønne distribusjonsapplikasjon på midten av 2000-tallet. Inntil en tid fungerte alt bra, siden denne ordningen var ment for en monolitisk struktur.
Følgende bilde viser hvordan MS anbefaler å gå fra en monolitt til mikrotjenester – ganske enkelt dele opp hver av hovedtjenestene i separate mikrotjenester. Det var under implementeringen av denne ordningen at Bell gjorde en feil.
De delte alle sine tjenester inn i ulike nivåer, som hver besto av mange individuelle tjenester. For eksempel inkluderte webtjenesten mikrotjenester for innholdsgjengivelse og autentisering, forretningslogikktjenesten besto av mikrotjenester for behandling av bestillinger og kontoinformasjon, databasen ble delt inn i en haug med mikrotjenester med spesialiserte data. Både nettet, forretningslogikken og databasen var statsløse tjenester.
Dette bildet var imidlertid helt feil fordi det ikke kartla noen forretningsenheter utenfor selskapets IT-klynge. Denne ordningen tok ikke hensyn til noen forbindelse med omverdenen, så det var ikke klart hvordan man for eksempel skulle få tak i tredjeparts forretningsanalyse. Jeg noterer meg at de også fikk oppfunnet flere tjenester rett og slett for å utvikle karrieren til enkeltansatte som søkte å lede flest mulig mennesker for å få mer penger for det.
De mente at det var like enkelt å flytte til mikrotjenester som å ta deres interne N-tier fysiske lag-infrastruktur og feste Docker på den. La oss ta en titt på hvordan tradisjonell N-tier-arkitektur ser ut.
Den består av 4 nivåer: UI-brukergrensesnittnivået, forretningslogikknivået, datatilgangsnivået og databasen. Mer progressiv er DDD (Domain-Driven Design), eller programvareorientert arkitektur, hvor de to midterste nivåene er domeneobjekter og et depot.
Jeg prøvde å se på ulike endringsområder, ulike ansvarsområder i denne arkitekturen. I en typisk N-tier-applikasjon klassifiseres forskjellige endringsområder som gjennomsyrer strukturen vertikalt fra topp til bunn. Dette er Catalog, Config-innstillinger utført på individuelle datamaskiner og Checkout-sjekker, som ble håndtert av teamet mitt.
Det særegne ved denne ordningen er at grensene for disse endringsområdene ikke bare påvirker forretningslogikknivået, men også strekker seg til databasen.
La oss se på hva det vil si å være en tjeneste. Det er 6 karakteristiske egenskaper for en tjenestedefinisjon - det er programvare som:
- opprettet og brukt av en spesifikk organisasjon;
- er ansvarlig for innhold, behandling og/eller levering av en bestemt type informasjon i systemet;
- kan bygges, distribueres og kjøres uavhengig for å møte spesifikke operasjonelle behov;
- kommuniserer med forbrukere og andre tjenester, gir informasjon basert på avtaler eller kontraktsmessige garantier;
- beskytter seg mot uautorisert tilgang og informasjonen mot tap;
- håndterer feil på en slik måte at de ikke fører til informasjonsskader.
Alle disse egenskapene kan uttrykkes i ett ord "autonomi". Tjenester opererer uavhengig av hverandre, tilfredsstiller visse begrensninger og definerer kontrakter som folk kan få informasjonen de trenger på grunnlag av. Jeg nevnte ikke spesifikke teknologier, bruken av disse er selvsagt.
La oss nå se på definisjonen av mikrotjenester:
- en mikrotjeneste er liten i størrelse og designet for å løse ett spesifikt problem;
- Mikrotjenesten er autonom;
- Når du lager en mikrotjenestearkitektur, brukes byplanleggingsmetaforen. Dette er definisjonen fra Sam Newmans bok, Building Microservices.
Definisjonen av Bounded Context er hentet fra Eric Evans bok Domain-Driven Design. Dette er et kjernemønster i DDD, et arkitekturdesignsenter som jobber med volumetriske arkitektoniske modeller, deler dem inn i forskjellige Bounded Contexts og eksplisitt definerer interaksjonene mellom dem.
Enkelt sagt, en Bounded Context angir omfanget der en bestemt modul kan brukes. Innenfor denne konteksten er en logisk enhetlig modell som kan sees for eksempel i ditt forretningsdomene. Hvis du spør «hvem er en klient» til personellet som er involvert i bestillinger, får du én definisjon, spør du de som er involvert i salg, får du en annen, og utøverne vil gi deg en tredje definisjon.
Så, Bounded Context sier at hvis vi ikke kan gi en klar definisjon av hva en forbruker av tjenestene våre er, la oss definere grensene innenfor hvilke vi kan snakke om betydningen av dette begrepet, og deretter definere overgangspunktene mellom disse forskjellige definisjonene. Det vil si at hvis vi snakker om en klient med tanke på å legge inn bestillinger, betyr dette dette og det, og hvis fra et salgssynspunkt betyr dette dette og hint.
Den neste definisjonen av en mikrotjeneste er innkapslingen av alle slags interne operasjoner, som forhindrer "lekkasje" av komponentene i arbeidsprosessen inn i miljøet. Deretter kommer "definisjonen av eksplisitte kontrakter for ekstern interaksjon, eller ekstern kommunikasjon," som er representert ved ideen om kontrakter som returnerer fra SLAer. Den siste definisjonen er metaforen til en celle, eller celle, som betyr fullstendig innkapsling av et sett med operasjoner i en mikrotjeneste og tilstedeværelsen i den av reseptorer for kommunikasjon med omverdenen.
Så vi sa til gutta i Bell Computers, "Vi kan ikke fikse noe av kaoset dere har skapt fordi dere bare ikke har penger til å gjøre det, men vi vil fikse bare én tjeneste for å få det til å bli føle." På dette tidspunktet vil jeg begynne med å fortelle deg hvordan vi fikset vår eneste tjeneste slik at den svarte på forespørsler raskere enn 9 og et halvt minutt.
22:30 min
Fortsettelse snart...
Litt reklame
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com