Du har ägnat månader åt att designa om din monolit till mikrotjänster, och äntligen har alla samlats för att vända omkopplaren. Du går till den första webbsidan... och ingenting händer. Du laddar om den - och återigen inget bra, sidan är så långsam att den inte svarar på flera minuter. Vad hände?
I sitt föredrag kommer Jimmy Bogard att genomföra en "obduktion" på en verklig mikrotjänstkatastrof. Han kommer att visa modellerings-, utvecklings- och produktionsproblemen han upptäckte, och hur hans team långsamt förvandlade den nya distribuerade monoliten till den slutliga bilden av förnuft. Även om det är omöjligt att helt förhindra designfel, kan du åtminstone identifiera problem tidigt i designprocessen för att säkerställa att slutprodukten blir ett tillförlitligt distribuerat system.
Hej alla, jag heter Jimmy och idag ska ni höra hur ni kan undvika megakatastrofer när ni bygger mikrotjänster. Det här är historien om ett företag som jag arbetat för i ungefär ett och ett halvt år för att hjälpa till att förhindra att deras fartyg kolliderar med ett isberg. För att berätta den här historien ordentligt måste vi gå tillbaka i tiden och prata om var detta företag började och hur dess IT-infrastruktur har växt över tiden. För att skydda namnen på de oskyldiga i den här katastrofen har jag ändrat namnet på det här företaget till Bell Computers. Nästa bild visar hur IT-infrastrukturen för sådana företag såg ut i mitten av 90-talet. Detta är en typisk arkitektur för en stor universell feltolerant HP Tandem Mainframe-server för drift av en hårdvarubutik.
De behövde bygga ett system för att hantera alla beställningar, försäljning, returer, produktkataloger och kundbas, så de valde den vanligaste stordatorlösningen vid den tiden. Detta gigantiska system innehöll varje bit av information om företaget, allt möjligt, och varje transaktion genomfördes genom denna stordator. De hade alla sina ägg i en korg och tyckte att det var normalt. Det enda som inte ingår här är postorderkataloger och beställningar via telefon.
Med tiden blev systemet större och större, och en enorm mängd sopor samlades i det. COBOL är inte heller det mest uttrycksfulla språket i världen, så systemet blev ett stort, monolitiskt skräp. År 2000 såg de att många företag hade webbplatser genom vilka de utförde absolut all sin verksamhet och bestämde sig för att bygga sin första kommersiella dot-com-webbplats.
Den ursprungliga designen såg ganska snygg ut och bestod av en toppnivåwebbplats bell.com och ett antal underdomäner för enskilda applikationer: catalog.bell.com, accounts.bell.com, orders.bell.com, produktsökning search.bell. com. Varje underdomän använde ramverket ASP.Net 1.0 och sina egna databaser, och de pratade alla med systemets backend. Alla beställningar fortsatte dock att behandlas och utföras inom en enda stor stordator, där allt skräp fanns kvar, men fronten var separata webbplatser med individuella applikationer och separata databaser.
Så designen av systemet såg ordnad och logisk ut, men själva systemet var som visas i nästa bild.
Alla element adresserade anrop till varandra, åtkomst till API:er, inbäddade dll-filer från tredje part och liknande. Det hände ofta att versionskontrollsystem tog tag i någon annans kod, stoppade in den i projektet och sedan gick allt sönder. MS SQL Server 2005 använde konceptet länkservrar, och även om jag inte visade pilarna på bilden pratade var och en av databaserna också med varandra, eftersom det inte är något fel med att bygga tabeller baserade på data som erhållits från flera databaser .
Eftersom de nu hade en viss separation mellan olika logiska områden i systemet, blev detta distribuerade smutsklatter, med den största skräpbiten kvar i stordatorns backend.
Det roliga var att denna stordator byggdes av konkurrenter till Bell Computers och fortfarande underhålls av deras tekniska konsulter. Övertygat om den otillfredsställande prestandan för sina applikationer, beslutade företaget att bli av med dem och designa om systemet.
Den befintliga applikationen hade varit i produktion i 15 år, vilket är rekord för ASP.Net-baserade applikationer. Tjänsten tog emot beställningar från hela världen och årliga intäkter från denna enda applikation nådde en miljard dollar. En betydande del av vinsten genererades av webbplatsen bell.com. På Black Fridays nådde antalet beställningar via sajten flera miljoner. Den befintliga arkitekturen tillät dock ingen utveckling, eftersom de stela sammankopplingarna av systemelement praktiskt taget inte medgav några ändringar i tjänsten.
Det allvarligaste problemet var oförmågan att lägga en order från ett land, betala för den i ett annat och skicka den till ett tredje, trots att ett sådant handelssystem är mycket vanligt i globala företag. Den befintliga webbplatsen tillät inte något liknande, så de var tvungna att acceptera och göra dessa beställningar via telefon. Detta ledde till att företaget alltmer funderade på att förändra arkitekturen, i synnerhet på att byta till mikrotjänster.
De gjorde det smarta genom att titta på andra företag för att se hur de hade löst ett liknande problem. En av dessa lösningar var tjänstearkitekturen Netflix, som består av mikrotjänster kopplade via ett API och en extern databas.
Bell Computers ledning bestämde sig för att bygga just en sådan arkitektur, i enlighet med vissa grundläggande principer. Först eliminerade de dataduplicering genom att använda en delad databasmetod. Ingen data skickades, tvärtom, alla som behövde det måste gå till en centraliserad källa. Detta följdes av isolering och autonomi - varje tjänst var oberoende av de andra. De bestämde sig för att använda webb-API:et till absolut allt – om du ville få data eller göra ändringar i ett annat system så gjordes allt via webb-API. Det sista stora var en ny stordator som heter "Bell on Bell" i motsats till "Bell" stordator baserad på konkurrenternas hårdvara.
Så under loppet av 18 månader byggde de systemet kring dessa kärnprinciper och tog det till förproduktion. När de återvände till jobbet efter helgen gick utvecklarna samman och slog på alla servrar som det nya systemet var anslutet till. 18 månaders arbete, hundratals utvecklare, den modernaste Bell-hårdvaran - och inget positivt resultat! Detta har gjort många människor besvikna eftersom de har kört det här systemet på sina bärbara datorer många gånger och allt var bra.
De var smarta att kasta alla sina pengar på att lösa detta problem. De installerade de modernaste serverracken med switchar, använde gigabit optisk fiber, den mest kraftfulla serverhårdvaran med en galen mängd RAM, kopplade upp allt, konfigurerade det - och igen, ingenting! Sedan började de misstänka att anledningen kunde vara timeouts, så de gick in i alla webbinställningar, alla API-inställningar och uppdaterade hela timeout-konfigurationen till maxvärdena, så att allt de kunde göra var att sitta och vänta på att något skulle hända till webbplatsen. De väntade och väntade och väntade i 9 och en halv minut tills webbplatsen äntligen laddades.
Efter det gick det upp för dem att den nuvarande situationen behövde en grundlig analys och de bjöd in oss. Det första vi fick reda på var att under alla 18 månaders utveckling skapades inte ett enda riktigt "mikro" - allt blev bara större. Efter detta började vi skriva en obduktion, även känd som en "regretrospective", eller "sad retrospective", även känd som en "blame storm", liknande en "brain storm", för att förstå orsaken till katastrofen.
Vi hade flera ledtrådar, varav en var fullständig trafikmättnad vid tidpunkten för API-anropet. När du använder en monolitisk tjänstearkitektur kan du omedelbart förstå vad som gick fel eftersom du har en enda stackspårning som rapporterar allt som kunde ha orsakat felet. I fallet där ett gäng tjänster samtidigt får åtkomst till samma API, finns det inget sätt att spåra spåret förutom att använda ytterligare nätverksövervakningsverktyg som WireShark, tack vare vilket du kan undersöka en enda begäran och ta reda på vad som hände under dess implementering. Så vi tog en webbsida och tillbringade nästan två veckor med att sätta ihop pusselbitarna, ringa en mängd olika samtal till den och analysera vad var och en av dem ledde till.
Titta på den här bilden. Det visar att en extern begäran uppmanar tjänsten att ringa många interna samtal som återkommer. Det visar sig att varje internt samtal gör ytterligare hopp för att självständigt kunna betjäna denna begäran, eftersom den inte kan vända sig någon annanstans för att få den nödvändiga informationen. Den här bilden ser ut som en meningslös kaskad av samtal, eftersom den externa begäran anropar ytterligare tjänster, som anropar andra tilläggstjänster och så vidare, nästan i oändlighet.
Den gröna färgen i detta diagram visar en halvcirkel där tjänster anropar varandra - tjänst A ringer tjänst B, tjänst B ringer tjänst C, och den anropar tjänst A igen. Som ett resultat får vi ett "distribuerat dödläge". En enda begäran skapade tusen nätverks-API-anrop, och eftersom systemet inte hade inbyggd feltolerans och loopskydd, skulle begäran misslyckas om ens ett av dessa API-anrop misslyckades.
Vi gjorde lite matte. Varje API-anrop hade en SLA på högst 150 ms och 99,9 % drifttid. En begäran orsakade 200 olika samtal och i bästa fall kunde sidan visas på 200 x 150 ms = 30 sekunder. Naturligtvis var detta inte bra. Genom att multiplicera 99,9 % drifttid med 200 fick vi 0 % tillgänglighet. Det visar sig att denna arkitektur var dömd att misslyckas från allra första början.
Vi frågade utvecklarna hur de inte kände igen detta problem efter 18 månaders arbete? Det visade sig att de bara räknade SLA för koden de körde, men om deras tjänst ringde en annan tjänst så räknade de inte in den tiden i sin SLA. Allt som lanserades inom en process höll sig till ett värde av 150 ms, men tillgången till andra serviceprocesser ökade den totala förseningen många gånger om. Den första lärdomen var: "Har du kontroll över din SLA, eller har SLA kontroll över dig?" I vårt fall var det det senare.
Nästa sak vi upptäckte var att de kände till konceptet med distribuerade datormissuppfattningar, formulerade av Peter Deitch och James Gosling, men de ignorerade den första delen av det. Den anger att påståendena "nätverket är tillförlitligt", "noll latens" och "oändlig genomströmning" är missuppfattningar. Andra missuppfattningar inkluderar påståendena "nätverket är säkert", "topologin förändras aldrig", "det finns alltid bara en administratör", "kostnaden för dataöverföring är noll" och "nätverket är homogent."
De gjorde ett misstag eftersom de testade sin tjänst på lokala maskiner och aldrig kopplade upp sig med externa tjänster. När de utvecklade lokalt och använde en lokal cache, stötte de aldrig på nätverkshopp. Under alla 18 månaders utveckling undrade de aldrig vad som kunde hända om externa tjänster påverkades.
Om du tittar på tjänstegränserna i föregående bild kan du se att de alla är felaktiga. Det finns gott om källor som ger råd om hur man definierar tjänstegränser, och de flesta gör det fel, som Microsoft på nästa bild.
Den här bilden är från MS-bloggen om ämnet "Hur man bygger mikrotjänster". Detta visar en enkel webbapplikation, ett block med affärslogik och en databas. Förfrågan kommer direkt, det finns förmodligen en server för webben, en server för verksamheten och en för databasen. Ökar du trafiken kommer bilden att förändras lite.
Här kommer en lastbalanserare för att fördela trafik mellan två webbservrar, en cache som ligger mellan webbtjänsten och affärslogiken, och en annan cache mellan affärslogiken och databasen. Det här är exakt den arkitektur som Bell använde för sin lastbalansering och blå/gröna implementeringsapplikation i mitten av 2000-talet. Fram till en tid fungerade allt bra, eftersom detta schema var avsett för en monolitisk struktur.
Följande bild visar hur MS rekommenderar att gå från en monolit till mikrotjänster – helt enkelt dela upp var och en av huvudtjänsterna i separata mikrotjänster. Det var under implementeringen av detta system som Bell gjorde ett misstag.
De delade upp alla sina tjänster i olika nivåer som var och en bestod av många individuella tjänster. Till exempel inkluderade webbtjänsten mikrotjänster för innehållsrendering och autentisering, affärslogiktjänsten bestod av mikrotjänster för bearbetning av order och kontoinformation, databasen var uppdelad i ett gäng mikrotjänster med specialiserad data. Både webben, affärslogiken och databasen var statslösa tjänster.
Denna bild var dock helt felaktig eftersom den inte kartlade några affärsenheter utanför företagets IT-kluster. Detta schema tog inte hänsyn till någon koppling till omvärlden, så det var inte klart hur man till exempel skaffar affärsanalys från tredje part. Jag noterar att de också lät uppfinna flera tjänster helt enkelt för att utveckla karriären för enskilda medarbetare som försökte leda så många människor som möjligt för att få mer pengar för det.
De trodde att det var lika enkelt att flytta till mikrotjänster som att ta deras interna N-tier fysiska lagerinfrastruktur och sätta Docker på den. Låt oss ta en titt på hur traditionell N-tier-arkitektur ser ut.
Den består av fyra nivåer: nivån för användargränssnittet, affärslogiknivån, dataåtkomstnivån och databasen. Mer progressiv är DDD (Domain-Driven Design), eller mjukvaruorienterad arkitektur, där de två mellannivåerna är domänobjekt och ett arkiv.
Jag försökte titta på olika förändringsområden, olika ansvarsområden i den här arkitekturen. I en typisk N-tier-applikation klassificeras olika förändringsområden som genomsyrar strukturen vertikalt från topp till botten. Dessa är katalog, konfigurationsinställningar utförda på enskilda datorer och checkout-kontroller, som hanterades av mitt team.
Det speciella med detta schema är att gränserna för dessa förändringsområden inte bara påverkar affärslogiknivån utan även sträcker sig till databasen.
Låt oss titta på vad det innebär att vara en tjänst. Det finns 6 karakteristiska egenskaper för en tjänstdefinition - det är programvara som:
- skapad och använd av en specifik organisation;
- är ansvarig för innehållet, behandlingen och/eller tillhandahållandet av en viss typ av information inom systemet;
- kan byggas, distribueras och drivas oberoende för att möta specifika operativa behov;
- kommunicerar med konsumenter och andra tjänster, tillhandahåller information baserad på avtal eller avtalsgarantier;
- skyddar sig från obehörig åtkomst och dess information från förlust;
- hanterar fel på ett sådant sätt att de inte leder till informationsskada.
Alla dessa egenskaper kan uttryckas i ett ord "autonomi". Tjänster fungerar oberoende av varandra, uppfyller vissa begränsningar och definierar kontrakt på basis av vilka människor kan få den information de behöver. Jag nämnde inte specifika tekniker, vars användning är självklar.
Låt oss nu titta på definitionen av mikrotjänster:
- en mikrotjänst är liten till storleken och utformad för att lösa ett specifikt problem;
- Mikrotjänsten är autonom;
- När man skapar en mikrotjänstarkitektur används stadsplaneringsmetaforen. Detta är definitionen från Sam Newmans bok, Building Microservices.
Definitionen av Bounded Context är hämtad från Eric Evans bok Domain-Driven Design. Detta är ett kärnmönster i DDD, ett arkitekturdesigncenter som arbetar med volymetriska arkitektoniska modeller, som delar in dem i olika Bounded Contexts och explicit definierar interaktionerna mellan dem.
Enkelt uttryckt betecknar en Bounded Context omfattningen inom vilken en viss modul kan användas. Inom detta sammanhang finns en logiskt enhetlig modell som kan ses till exempel i din affärsdomän. Om du frågar "vem är en kund" till personalen som är involverad i beställningar får du en definition, om du frågar de som är inblandade i försäljning får du en annan, och artisterna kommer att ge dig en tredje definition.
Så, Bounded Context säger att om vi inte kan ge en tydlig definition av vad en konsument av våra tjänster är, låt oss definiera gränserna inom vilka vi kan prata om innebörden av denna term, och sedan definiera övergångspunkterna mellan dessa olika definitioner. Det vill säga, om vi pratar om en kund ur beställningssynpunkt, betyder detta det och det, och om det ur försäljningssynpunkt betyder det här och det.
Nästa definition av en mikrotjänst är inkapslingen av alla slags interna operationer, vilket förhindrar "läckage" av komponenterna i arbetsprocessen till miljön. Därefter kommer "definitionen av explicita kontrakt för extern interaktion, eller extern kommunikation", som representeras av idén om kontrakt som återvänder från SLA. Den sista definitionen är metaforen för en cell, eller cell, vilket betyder den fullständiga inkapslingen av en uppsättning operationer inom en mikrotjänst och närvaron i den av receptorer för kommunikation med omvärlden.
Så vi sa till killarna på Bell Computers, "Vi kan inte fixa något av det kaos du har skapat eftersom du helt enkelt inte har pengarna för att göra det, men vi fixar bara en tjänst för att göra det hela känsla." Vid det här laget ska jag börja med att berätta hur vi fixade vår enda tjänst så att den svarade på förfrågningar snabbare än 9 och en halv minut.
22:30 min
Fortsättning snart...
En del reklam
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com