Je hebt maanden besteed aan het opnieuw ontwerpen van je monoliet tot microservices, en eindelijk is iedereen bij elkaar gekomen om de schakelaar om te zetten. U gaat naar de eerste webpagina... en er gebeurt niets. Je laadt het opnieuw - en opnieuw niets goeds, de site is zo traag dat hij enkele minuten niet reageert. Wat is er gebeurd?
In zijn lezing zal Jimmy Bogard een ‘post-mortem’ uitvoeren over een echte microservice-ramp. Hij zal de modellerings-, ontwikkelings- en productieproblemen laten zien die hij ontdekte, en hoe zijn team de nieuwe gedistribueerde monoliet langzaam transformeerde in het uiteindelijke beeld van gezond verstand. Hoewel het onmogelijk is om ontwerpfouten volledig te voorkomen, kunt u problemen in ieder geval vroeg in het ontwerpproces identificeren om ervoor te zorgen dat het eindproduct een betrouwbaar gedistribueerd systeem wordt.
Hallo allemaal, ik ben Jimmy en vandaag gaan jullie horen hoe je megarampen kunt voorkomen bij het bouwen van microservices. Dit is het verhaal van een bedrijf waar ik ongeveer anderhalf jaar voor heb gewerkt om te voorkomen dat hun schip in aanvaring komt met een ijsberg. Om dit verhaal goed te vertellen, moeten we terug in de tijd gaan en praten over waar dit bedrijf begon en hoe zijn IT-infrastructuur in de loop van de tijd is gegroeid. Om de namen van de onschuldigen bij deze ramp te beschermen, heb ik de naam van dit bedrijf veranderd in Bell Computers. De volgende dia laat zien hoe de IT-infrastructuur van dergelijke bedrijven er halverwege de jaren negentig uitzag. Dit is een typische architectuur van een grote universele fouttolerante HP Tandem Mainframe-server voor het exploiteren van een computerhardwarewinkel.
Ze moesten een systeem bouwen om alle bestellingen, verkopen, retouren, productcatalogi en klantenbestand te beheren, dus kozen ze voor de destijds meest gebruikelijke mainframeoplossing. Dit gigantische systeem bevatte alle mogelijke informatie over het bedrijf, en elke transactie werd via dit mainframe uitgevoerd. Ze hielden al hun eieren in één mandje en vonden dat normaal. Het enige dat hier niet is opgenomen, zijn postordercatalogi en het telefonisch plaatsen van bestellingen.
In de loop van de tijd werd het systeem steeds groter en verzamelde zich een enorme hoeveelheid afval. Bovendien is COBOL niet de meest expressieve taal ter wereld, dus het systeem werd uiteindelijk een groot, monolithisch stuk rommel. In 2000 zagen ze dat veel bedrijven websites hadden waarmee ze absoluut al hun zaken konden doen, en ze besloten hun eerste commerciële dotcom-website te bouwen.
Het initiële ontwerp zag er best aardig uit en bestond uit een top-level site bell.com en een aantal subdomeinen voor individuele toepassingen: catalog.bell.com, accounts.bell.com, orders.bell.com, product search search.bell. com. Elk subdomein gebruikte het ASP.Net 1.0-framework en zijn eigen databases, en ze communiceerden allemaal met de backend van het systeem. Alle bestellingen werden echter nog steeds verwerkt en uitgevoerd binnen één groot mainframe, waarin al het afval achterbleef, maar de front-end bestond uit afzonderlijke websites met individuele applicaties en afzonderlijke databases.
Het ontwerp van het systeem zag er dus ordelijk en logisch uit, maar het daadwerkelijke systeem was zoals weergegeven in de volgende dia.
Alle elementen richtten zich op oproepen naar elkaar, toegang tot API's, ingebedde dll's van derden en dergelijke. Het gebeurde vaak dat versiebeheersystemen de code van iemand anders pakten, deze in het project stopten, en dan ging alles kapot. MS SQL Server 2005 gebruikte het concept van linkservers, en hoewel ik de pijlen op de dia niet liet zien, communiceerde elk van de databases ook met elkaar, omdat er niets mis is met het bouwen van tabellen op basis van gegevens verkregen uit verschillende databases.
Omdat ze nu enige scheiding hadden tussen verschillende logische delen van het systeem, werden dit verspreide klodders vuil, waarbij het grootste stuk afval nog steeds in de backend van het mainframe achterbleef.
Het grappige was dat dit mainframe werd gebouwd door concurrenten van Bell Computers en nog steeds werd onderhouden door hun technische adviseurs. Overtuigd van de onbevredigende prestaties van zijn applicaties besloot het bedrijf deze te verwijderen en het systeem opnieuw te ontwerpen.
De bestaande applicatie was al 15 jaar in productie, wat een record is voor op ASP.Net gebaseerde applicaties. De dienst accepteerde bestellingen van over de hele wereld en de jaarlijkse inkomsten uit deze ene applicatie bereikten een miljard dollar. Een aanzienlijk deel van de winst werd gegenereerd door de website bell.com. Op Black Friday bereikte het aantal via de site geplaatste bestellingen enkele miljoenen. De bestaande architectuur liet echter geen enkele ontwikkeling toe, omdat de rigide onderlinge verbindingen van systeemelementen het praktisch niet mogelijk maakten dat er wijzigingen in de dienst werden aangebracht.
Het ernstigste probleem was het onvermogen om vanuit het ene land een bestelling te plaatsen, deze in een ander land te betalen en naar een derde land te sturen, ondanks het feit dat een dergelijk handelssysteem heel gebruikelijk is bij mondiale bedrijven. De bestaande website stond zoiets niet toe, dus moesten ze deze bestellingen telefonisch accepteren en plaatsen. Dit leidde ertoe dat het bedrijf steeds meer nadacht over het veranderen van de architectuur, met name over de overstap naar microservices.
Ze deden het slimme door naar andere bedrijven te kijken om te zien hoe zij een soortgelijk probleem hadden opgelost. Eén van deze oplossingen was de Netflix-servicearchitectuur, die bestaat uit microservices die via een API en een externe database met elkaar zijn verbonden.
Het management van Bell Computers besloot precies zo'n architectuur te bouwen, waarbij hij zich aan bepaalde basisprincipes hield. Ten eerste hebben ze gegevensduplicatie geëlimineerd door gebruik te maken van een gedeelde databasebenadering. Er werden geen gegevens verzonden; integendeel: iedereen die ze nodig had, moest naar een gecentraliseerde bron. Dit werd gevolgd door isolatie en autonomie: elke dienst was onafhankelijk van de andere. Ze besloten om de Web API voor werkelijk alles te gebruiken: als je gegevens wilde ophalen of wijzigingen wilde aanbrengen in een ander systeem, gebeurde dat allemaal via de Web API. Het laatste grote ding was een nieuw mainframe genaamd "Bell on Bell", in tegenstelling tot het "Bell" mainframe, gebaseerd op de hardware van concurrenten.
Dus in de loop van 18 maanden bouwden ze het systeem rond deze kernprincipes en brachten het naar de pre-productie. Toen de ontwikkelaars na het weekend weer aan het werk gingen, kwamen ze bij elkaar en schakelden alle servers in waarmee het nieuwe systeem was verbonden. 18 maanden werk, honderden ontwikkelaars, de modernste Bell-hardware - en geen positief resultaat! Dit heeft veel mensen teleurgesteld, omdat ze dit systeem vele malen op hun laptops hebben gedraaid en alles in orde was.
Ze waren slim om al hun geld te steken in het oplossen van dit probleem. Ze installeerden de modernste serverracks met schakelaars, gebruikten gigabit glasvezel, de krachtigste serverhardware met een waanzinnige hoeveelheid RAM, sloten alles aan, configureerden het - en nogmaals, niets! Toen begonnen ze te vermoeden dat de reden misschien time-outs waren, dus gingen ze naar alle webinstellingen, alle API-instellingen en werkten ze de hele time-outconfiguratie bij naar de maximale waarden, zodat ze alleen maar konden wachten tot er iets gebeurde. naar de site. Ze wachtten en wachtten en wachtten 9 en een halve minuut totdat de website eindelijk laadde.
Daarna drong het tot hen door dat de huidige situatie een grondige analyse nodig had, en ze nodigden ons uit. Het eerste dat we ontdekten was dat er tijdens de 18 maanden van ontwikkeling geen enkele echte “micro” werd gecreëerd; alles werd alleen maar groter. Hierna zijn we begonnen met het schrijven van een post-mortem, ook bekend als een ‘regretrospective’ of ‘trieste retrospectief’, ook wel bekend als een ‘blame storm’, vergelijkbaar met een ‘brain storm’, om de oorzaak van de ramp te begrijpen.
We hadden verschillende aanwijzingen, waaronder een volledige verkeersverzadiging op het moment van de API-aanroep. Wanneer je een monolithische servicearchitectuur gebruikt, begrijp je meteen wat er precies mis is gegaan, omdat je één enkele stacktrace hebt die alles rapporteert wat de storing had kunnen veroorzaken. In het geval dat een aantal services tegelijkertijd toegang hebben tot dezelfde API, is er geen manier om de tracering te volgen, behalve door extra netwerkmonitoringtools zoals WireShark te gebruiken, waardoor je een enkel verzoek kunt onderzoeken en erachter kunt komen wat er tijdens de implementatie ervan is gebeurd. Dus namen we één webpagina en besteedden er bijna twee weken aan om de stukjes van de puzzel in elkaar te zetten, er verschillende oproepen naar te doen en te analyseren waar elk van hen toe leidde.
Kijk naar deze foto. Het laat zien dat één extern verzoek de service ertoe aanzet veel interne oproepen te doen die terugkomen. Het blijkt dat elke interne oproep extra hops maakt om zelfstandig aan dit verzoek te kunnen voldoen, omdat het nergens anders terecht kan om de benodigde informatie te verkrijgen. Dit beeld lijkt op een zinloze cascade van oproepen, aangezien het externe verzoek aanvullende diensten aanroept, die andere aanvullende diensten aanroepen, enzovoort, bijna tot in het oneindige.
De groene kleur in dit diagram toont een halve cirkel waarin services elkaar bellen: service A belt service B, service B belt service C en deze belt opnieuw service A. Als resultaat krijgen we een “gedistribueerde impasse”. Eén enkel verzoek creëerde duizend netwerk-API-aanroepen, en aangezien het systeem geen ingebouwde fouttolerantie en lusbescherming had, zou het verzoek mislukken als zelfs maar één van deze API-aanroepen mislukte.
We hebben wat wiskunde gedaan. Elke API-aanroep had een SLA van niet meer dan 150 ms en een uptime van 99,9%. Eén verzoek veroorzaakte 200 verschillende oproepen, en in het beste geval kon de pagina in 200 x 150 ms = 30 seconden worden weergegeven. Dit was uiteraard niet goed. Door de uptime van 99,9% met 200 te vermenigvuldigen, kregen we een beschikbaarheid van 0%. Het blijkt dat deze architectuur vanaf het begin gedoemd was te mislukken.
We vroegen de ontwikkelaars hoe het kwam dat ze dit probleem na 18 maanden werken niet onderkenden? Het bleek dat ze alleen de SLA meetelden voor de code die ze draaiden, maar als hun dienst een andere dienst belde, telden ze die tijd niet mee in hun SLA. Alles wat binnen één proces werd gelanceerd, hield zich aan de waarde van 150 ms, maar toegang tot andere serviceprocessen verhoogde de totale vertraging vele malen. De eerste les die we leerden was: “Heb jij de controle over jouw SLA, of heeft de SLA de controle over jou?” In ons geval was dat het laatste.
Het volgende dat we ontdekten was dat ze op de hoogte waren van het concept van misvattingen over gedistribueerd computergebruik, geformuleerd door Peter Deitch en James Gosling, maar dat ze het eerste deel ervan negeerden. Er wordt gesteld dat de beweringen ‘het netwerk is betrouwbaar’, ‘geen latentie’ en ‘oneindige doorvoer’ misvattingen zijn. Andere misvattingen zijn onder meer de uitspraken ‘het netwerk is veilig’, ‘de topologie verandert nooit’, ‘er is altijd maar één beheerder’, ‘de kosten van gegevensoverdracht zijn nul’ en ‘het netwerk is homogeen’.
Ze hebben een fout gemaakt omdat ze hun service op lokale machines hebben getest en nooit verbinding hebben gemaakt met externe services. Bij het lokaal ontwikkelen en het gebruik van een lokale cache kwamen ze nooit netwerkhops tegen. In de achttien maanden van ontwikkeling hebben ze zich nooit afgevraagd wat er zou gebeuren als externe diensten hierdoor zouden worden getroffen.
Als u naar de servicegrenzen in de vorige afbeelding kijkt, ziet u dat ze allemaal onjuist zijn. Er zijn tal van bronnen die adviseren over het definiëren van servicegrenzen, en de meeste doen het verkeerd, zoals Microsoft op de volgende dia.
Deze afbeelding komt van de MS-blog over het onderwerp “Hoe microservices te bouwen”. Dit toont een eenvoudige webapplicatie, een blok bedrijfslogica en een database. Het verzoek komt rechtstreeks, er is waarschijnlijk één server voor het web, één server voor het bedrijf en één voor de database. Als u het verkeer vergroot, zal het beeld enigszins veranderen.
Hier komt een load balancer om het verkeer tussen twee webservers te verdelen, een cache tussen de webservice en de bedrijfslogica, en een andere cache tussen de bedrijfslogica en de database. Dit is precies de architectuur die Bell halverwege de jaren 2000 gebruikte voor zijn load-balancing en blauw/groen-implementatietoepassing. Tot enige tijd werkte alles goed, omdat dit schema bedoeld was voor een monolithische structuur.
De volgende afbeelding laat zien hoe MS aanbeveelt om van een monoliet naar microservices over te stappen: eenvoudigweg elk van de hoofdservices opsplitsen in afzonderlijke microservices. Het was tijdens de implementatie van dit plan dat Bell een fout maakte.
Ze verdeelden al hun diensten in verschillende lagen, die elk uit veel individuele diensten bestonden. De webservice omvatte bijvoorbeeld microservices voor het weergeven van inhoud en authenticatie, de bedrijfslogische service bestond uit microservices voor het verwerken van bestellingen en accountinformatie, de database was opgedeeld in een aantal microservices met gespecialiseerde gegevens. Zowel het web, de bedrijfslogica als de database waren staatloze diensten.
Dit beeld klopte echter totaal niet, omdat er geen bedrijfsonderdelen buiten de IT-cluster van het bedrijf in kaart werden gebracht. Bij dit plan werd geen rekening gehouden met enige verbinding met de buitenwereld, waardoor het niet duidelijk was hoe bijvoorbeeld bedrijfsanalyses van derden konden worden verkregen. Ik merk op dat ze ook verschillende diensten hadden uitgevonden, eenvoudigweg om de carrières van individuele werknemers te ontwikkelen, die probeerden zoveel mogelijk mensen te managen om er meer geld voor te krijgen.
Ze geloofden dat de overstap naar microservices net zo eenvoudig was als het nemen van hun interne N-tier fysieke laaginfrastructuur en het erop plakken van Docker. Laten we eens kijken hoe de traditionele N-tier-architectuur eruit ziet.
Het bestaat uit 4 niveaus: het niveau van de UI-gebruikersinterface, het niveau van de bedrijfslogica, het niveau van gegevenstoegang en de database. Progressiever is DDD (Domain-Driven Design), of softwaregeoriënteerde architectuur, waarbij de twee middelste niveaus domeinobjecten en een repository zijn.
Ik probeerde te kijken naar verschillende gebieden van verandering, verschillende verantwoordelijkheidsgebieden in deze architectuur. In een typische N-tier-toepassing worden verschillende veranderingsgebieden geclassificeerd die de structuur verticaal van boven naar beneden doordringen. Dit zijn Catalogus, Config-instellingen uitgevoerd op individuele computers en Checkout-controles, die door mijn team zijn afgehandeld.
Het bijzondere van dit schema is dat de grenzen van deze veranderingsgebieden niet alleen van invloed zijn op het niveau van de bedrijfslogica, maar zich ook uitstrekken tot de database.
Laten we eens kijken naar wat het betekent om een dienst te zijn. Er zijn 6 karakteristieke eigenschappen van een servicedefinitie: het is software die:
- gemaakt en gebruikt door een specifieke organisatie;
- is verantwoordelijk voor de inhoud, verwerking en/of verstrekking van een bepaald soort informatie binnen het systeem;
- kan onafhankelijk worden gebouwd, ingezet en beheerd om aan specifieke operationele behoeften te voldoen;
- communiceert met consumenten en andere diensten en verstrekt informatie op basis van overeenkomsten of contractuele garanties;
- beschermt zichzelf tegen ongeoorloofde toegang en zijn informatie tegen verlies;
- handelt storingen zodanig af dat deze niet tot informatieschade leiden.
Al deze eigenschappen kunnen in één woord ‘autonomie’ worden uitgedrukt. Diensten opereren onafhankelijk van elkaar, voldoen aan bepaalde beperkingen en definiëren contracten op basis waarvan mensen de informatie kunnen ontvangen die ze nodig hebben. Ik heb geen specifieke technologieën genoemd, waarvan het gebruik vanzelfsprekend is.
Laten we nu eens kijken naar de definitie van microservices:
- een microservice is klein van formaat en ontworpen om één specifiek probleem op te lossen;
- De microservice is autonoom;
- Bij het creëren van een microservice-architectuur wordt de stedenbouwkundige metafoor gebruikt. Dit is de definitie uit het boek van Sam Newman, Building Microservices.
De definitie van Bounded Context is ontleend aan het boek Domain-Driven Design van Eric Evans. Dit is een kernpatroon in DDD, een architectuurontwerpcentrum dat werkt met volumetrische architecturale modellen, deze opdeelt in verschillende begrensde contexten en expliciet de interacties daartussen definieert.
In eenvoudige bewoordingen geeft een begrensde context de reikwijdte aan waarin een bepaalde module kan worden gebruikt. Binnen deze context bevindt zich een logisch uniform model dat bijvoorbeeld in uw bedrijfsdomein te zien is. Als je vraagt “wie is een klant” aan het personeel dat betrokken is bij de bestellingen, krijg je één definitie, als je het vraagt aan degenen die betrokken zijn bij de verkoop, krijg je een andere, en de artiesten geven je een derde definitie.
Bounded Context zegt dus dat als we geen duidelijke definitie kunnen geven van wat een consument van onze diensten is, we de grenzen moeten definiëren waarbinnen we over de betekenis van deze term kunnen praten, en dan de overgangspunten tussen deze verschillende definities kunnen definiëren. Dat wil zeggen, als we het hebben over een klant vanuit het oogpunt van het plaatsen van bestellingen, betekent dit dit en dat, en als het vanuit het oogpunt van verkoop dit en dat betekent.
De volgende definitie van een microservice is het inkapselen van alle soorten interne activiteiten, waardoor het ‘lekken’ van de componenten van het werkproces naar de omgeving wordt voorkomen. Vervolgens komt de ‘definitie van expliciete contracten voor externe interacties of externe communicatie’, die wordt weergegeven door het idee van contracten die terugkeren uit SLA’s. De laatste definitie is de metafoor van een cel, of cel, wat de volledige inkapseling betekent van een reeks operaties binnen een microservice en de aanwezigheid daarin van receptoren voor communicatie met de buitenwereld.
Dus zeiden we tegen de jongens van Bell Computers: “We kunnen de chaos die jullie hebben veroorzaakt niet oplossen, omdat jullie er gewoon het geld niet voor hebben, maar we zullen slechts één dienst repareren om alles goed te maken. gevoel." Op dit punt zal ik beginnen met te vertellen hoe we onze enige service hebben opgelost, zodat deze sneller dan negen en een halve minuut op verzoeken reageerde.
22:30 min
Wordt zeer binnenkort vervolgd...
wat reclame
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, , een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over
Bron: www.habr.com