Dir hutt Méint verbruecht fir Äre Monolith a Mikroservicer nei ze designen, a schliisslech ass jiddereen zesummekomm fir de Schalter ze wiesselen. Dir gitt op déi éischt Websäit ... an näischt geschitt. Dir lued et nei - an erëm näischt Guddes, de Site ass sou lues datt et fir e puer Minutten net reagéiert. Wat ass geschitt?
A sengem Gespréich wäert den Jimmy Bogard e "Post-mortem" iwwer eng real-Liewen Mikroservice Katastroph maachen. Hie wäert d'Modelléierungs-, Entwécklungs- a Produktiounsprobleemer weisen, déi hien entdeckt huet, a wéi säi Team den neie verdeelte Monolith lues a lues an dat lescht Bild vu Verstand transforméiert huet. Och wann et onméiglech ass Designfehler komplett ze vermeiden, kënnt Dir op d'mannst Probleemer fréi am Designprozess identifizéieren fir sécherzestellen datt d'Finale Produkt en zouverléissege verdeelte System gëtt.
Moien alleguer, ech sinn den Jimmy an haut héiert dir wéi een mega Katastrophen vermeide kann wann een Mikroservicer baut. Dëst ass d'Geschicht vun enger Firma fir déi ech fir ongeféier engem Joer an en halleft geschafft hunn fir ze hëllefen ze verhënneren datt hiert Schëff mat engem Äisbierg kollidéiert. Fir dës Geschicht richteg ze erzielen, musse mir zréck an d'Zäit goen a schwätzen iwwer wou dës Firma ugefaang huet a wéi hir IT Infrastruktur mat der Zäit gewuess ass. Fir d'Nimm vun deenen Onschëlleg an dëser Katastroph ze schützen, hunn ech den Numm vun dëser Firma op Bell Computers geännert. Déi nächst Rutsch weist wéi d'IT Infrastruktur vun esou Firmen an der Mëtt vun den 90er ausgesinn huet. Dëst ass eng typesch Architektur vun engem grousse universelle Feeler-tolerante HP Tandem Mainframe Server fir e Computer Hardware Store ze bedreiwen.
Si hu missen e System bauen fir all Bestellungen, Verkaf, Retouren, Produktkatalogen a Clientsbasis ze managen, sou datt se déi allgemeng Mainframe Léisung zu där Zäit gewielt hunn. Dëse gigantesche System enthält all Informatioun iwwer d'Firma, alles méiglech, an all Transaktioun gouf duerch dësen Mainframe duerchgefouert. Si hunn all hir Eeër an engem Kuerf gehal a geduecht dat wier normal. Dat eenzegt wat hei net mat abegraff ass, sinn d'Mailorderkatalogen an d'Bestellung per Telefon.
Mat der Zäit ass de System ëmmer méi grouss ginn, an et ass eng rieseg Quantitéit vu Gerempels accumuléiert. Och COBOL ass net déi expressivst Sprooch op der Welt, sou datt de System e grousst, monolithescht Stéck Dreck ass. Bis 2000 hu se gesinn datt vill Firmen Websäiten haten, duerch déi se absolut all hir Geschäfter gemaach hunn, an hunn decidéiert hir éischt kommerziell Dot-com Websäit ze bauen.
Den initialen Design huet zimmlech flott ausgesinn a bestoung aus engem Top-Level Site bell.com an enger Zuel vun Ënnerdomaine fir eenzel Uwendungen: catalog.bell.com, accounts.bell.com, orders.bell.com, Produkt Sich search.bell. com. All Subdomain huet den ASP.Net 1.0 Kader a seng eege Datenbanken benotzt, a si hunn all mam System Backend geschwat. Wéi och ëmmer, all Bestellungen goufen weider veraarbecht an ausgefouert an engem eenzegen riesegen Mainframe, an deem all Dreck bliwwen ass, awer de Frontend war separat Websäite mat individuellen Uwendungen a separaten Datenbanken.
Also huet den Design vum System uerdentlech a logesch ausgesinn, awer den eigentleche System war wéi an der nächster Rutsch gewisen.
All Elementer adresséiert Uruff uneneen, zougänglech APIen, embedded Drëtt-Partei dlls, an dergläiche. Et ass dacks geschitt datt Versiounskontrollsystemer de Code vun engem anere géifen gräifen, se an de Projet drécken, an da géif alles briechen. MS SQL Server 2005 huet d'Konzept vu Link-Server benotzt, an obwuel ech d'Pfeiler op der Rutsch net gewisen hunn, huet jidderee vun den Datenbanken och matenee geschwat, well et ass näischt falsch mam Bau vun Dëscher op Basis vun Daten aus verschiddene Datenbanken.
Well se elo eng Trennung tëscht verschiddene logesche Beräicher vum System haten, gouf dëst verdeelt Dreckstécker, mat dem gréisste Stéck Gerempels nach am Mainframe Backend.
Déi witzeg Saach war datt dëst Mainframe vu Konkurrenten vu Bell Computers gebaut gouf an nach ëmmer vun hiren technesche Beroder gehale gouf. Iwwerzeegt vun der onzefriddenheetlecher Leeschtung vun hiren Uwendungen, huet d'Firma beschloss, se ze läschen an de System nei ze designen.
Déi existent Applikatioun war zënter 15 Joer an der Produktioun, wat e Rekord fir ASP.Net-baséiert Uwendungen ass. De Service akzeptéiert Bestellungen aus der ganzer Welt, an alljährlechen Einnahmen aus dëser eenzeger Applikatioun erreecht eng Milliard Dollar. E groussen Deel vum Gewënn gouf vun der bell.com Websäit generéiert. Op Black Fridays huet d'Zuel vun de Bestellungen iwwer de Site e puer Millioune erreecht. Wéi och ëmmer, déi existent Architektur huet keng Entwécklung erlaabt, well déi steif Verbindunge vu Systemelementer praktesch keng Ännerunge vum Service erlaabt hunn.
De seriösten Problem war d'Onméiglechkeet eng Bestellung vun engem Land ze placéieren, fir se an engem aneren ze bezuelen an an en Drëttel ze schécken, trotz der Tatsaach, datt sou en Handelsschema ganz heefeg ass an de globale Firmen. Déi existéierend Websäit huet näischt wéi dëst erlaabt, sou datt se dës Bestellungen iwwer Telefon hunn akzeptéieren an ofginn. Dëst huet dozou gefouert datt d'Firma ëmmer méi iwwer d'Verännerung vun der Architektur geduecht huet, besonnesch iwwer de Wiessel op Mikroservicer.
Si hunn déi intelligent Saach gemaach andeems se aner Firmen kucken fir ze kucken wéi se en ähnleche Problem geléist hunn. Eng vun dëse Léisunge war d'Netflix Servicearchitektur, déi aus Mikroservicer besteet, déi iwwer eng API an eng extern Datebank verbonne sinn.
Bell Computers Gestioun huet decidéiert just esou eng Architektur ze bauen, a bestëmmte Grondprinzipien halen. Als éischt hunn se Dateduplikatioun eliminéiert andeems se eng gemeinsam Datebank Approche benotzen. Keng Donnéeën geschéckt ginn, am Géigendeel, jiddereen deen se gebraucht huet, huet missen op eng zentraliséiert Quell goen. Duerno koum Isolatioun an Autonomie - all Service war onofhängeg vun deenen aneren. Si hunn décidéiert d'Web API fir absolut alles ze benotzen - wann Dir wëllt Daten kréien oder Ännerunge fir en anere System maachen, ass alles duerch d'Web API gemaach. Déi lescht grouss Saach war en neie Mainframe genannt "Bell on Bell" am Géigesaz zum "Bell" Mainframe baséiert op Hardware vun de Konkurrenten.
Also, am Laf vun 18 Méint, hunn se de System ronderëm dës Kärprinzipien gebaut an et an d'Pre-Produktioun bruecht. Zréck op d'Aarbecht nom Weekend, hunn d'Entwéckler sech zesummegefaasst an hunn all d'Serveren op déi den neie System verbonne war. 18 Méint Aarbecht, Honnerte vun Entwéckler, déi modernst Bell Hardware - a kee positiven Resultat! Dëst huet vill Leit enttäuscht well se dëse System vill Mol op hire Laptops lafen an alles war gutt.
Si ware schlau fir all hir Sue fir dëse Problem ze léisen. Si hunn déi modernst Serverrack mat Schalteren installéiert, gigabit optesch Faser benotzt, déi mächtegst Serverhardware mat enger verréckter Quantitéit RAM, alles verbonnen, konfiguréiert - an erëm näischt! Dunn hunn se ugefaang ze verdächtegen datt de Grond Timeouts kéint sinn, sou datt se an all d'Web-Astellungen, all d'API-Astellunge gaang sinn an déi ganz Timeout-Konfiguratioun op déi maximal Wäerter aktualiséiert hunn, sou datt alles wat se maache konnten ass ze sëtzen a waarden op eppes geschitt op de Site. Si hunn gewaart a gewaart a gewaart fir 9 an eng hallef Minutte bis d'Websäit endlech gelueden ass.
Duerno huet et hinnen opgefall, datt déi aktuell Situatioun eng grëndlech Analyse brauch, a si hunn eis invitéiert. Déi éischt Saach, déi mir erausfonnt hunn, war datt während allen 18 Méint vun der Entwécklung keen eenzege richtege "Mikro" erstallt gouf - alles gouf nëmme méi grouss. Duerno hu mir ugefaang eng Postmortem ze schreiwen, och als "Regretrospektiv" oder "traureg Réckbléck", och bekannt als "Scholdstuerm", ähnlech wéi e "Gehirnstuerm", fir d'Ursaach vun der Katastroph ze verstoen.
Mir haten e puer Hiweiser, ee vun deenen war komplett Verkéier Sättigung zur Zäit vum API Uruff. Wann Dir eng monolithesch Servicearchitektur benotzt, kënnt Dir direkt verstoen wat genee falsch gaang ass, well Dir eng eenzeg Stackspur hutt, déi alles bericht wat den Echec verursaacht hätt. Am Fall wou eng Rëtsch Servicer gläichzäiteg op déiselwecht API zougänglech sinn, gëtt et kee Wee fir d'Spuer ze verfolgen ausser zousätzlech Netzwierk Iwwerwaachungsinstrumenter wéi WireShark ze benotzen, dank deenen Dir eng eenzeg Ufro ënnersicht an erausfannen wat während senger Ëmsetzung geschitt ass. Also hu mir eng Websäit geholl a bal 2 Woche verbruecht fir d'Stécker vum Puzzle zesummen ze setzen, eng Vielfalt vun Uruff unzeruffen an ze analyséieren wat jidderee vun hinnen gefouert huet.
Kuckt dëst Bild. Et weist datt eng extern Ufro de Service freet fir vill intern Uriff ze maachen déi zréckkommen. Et stellt sech eraus datt all internen Uruff zousätzlech Hopfen mécht fir dës Ufro onofhängeg ze kënnen ze servéieren, well et net soss néierens ka goen fir déi néideg Informatioun ze kréien. Dëst Bild gesäit aus wéi eng sënnlos Kaskade vun Uriff, well déi extern Ufro zousätzlech Servicer nennt, déi aner zousätzlech Servicer nennen, a sou weider, bal ad infinitum.
Déi gréng Faarf an dësem Diagramm weist en Hallefkrees an deem d'Servicer géigesäiteg ruffen - Service A rifft Service B, Service B rifft Service C, an et rifft erëm Service A. Als Resultat kréie mir e "verdeelt Deadlock". Eng eenzeg Ufro huet eng dausend Netzwierk API Uriff erstallt, a well de System keng agebaute Feelertoleranz a Schleifschutz huet, géif d'Ufro versoen wann souguer ee vun dësen API Uriff gescheitert ass.
Mir hunn e bësse Mathematik gemaach. All API Uruff hat eng SLA vun net méi wéi 150 ms an 99,9% uptime. Eng Ufro huet 200 verschidden Uruff verursaacht, an am beschte Fall konnt d'Säit an 200 x 150 ms = 30 Sekonnen ugewise ginn. Natierlech war dëst net gutt. Multiplizéiert 99,9% Uptime mat 200, hu mir 0% Disponibilitéit. Et stellt sech eraus datt dës Architektur vun Ufank un zu Echec veruerteelt gouf.
Mir hunn d'Entwéckler gefrot wéi se dëse Problem no 18 Méint Aarbecht net erkannt hunn? Et huet sech erausgestallt datt se nëmmen de SLA fir de Code gezielt hunn, deen se lafen, awer wann hire Service en anere Service genannt huet, hunn se dës Zäit net an hirem SLA gezielt. Alles wat an engem Prozess lancéiert gouf, huet sech un de Wäert vun 150 ms gehalen, awer den Zougang zu anere Serviceprozesser huet d'total Verzögerung vill Mol erhéicht. Déi éischt Lektioun geléiert war: "Sidd Dir Kontroll vun Ärem SLA, oder ass d'SLA Kontroll iwwer Iech?" An eisem Fall war et déi lescht.
Déi nächst Saach, déi mir entdeckt hunn, war datt si iwwer d'Konzept vun verdeelt Computing Mëssverständnis woussten, formuléiert vum Peter Deitch an James Gosling, awer si hunn den éischten Deel dovun ignoréiert. Et seet datt d'Aussoen "d'Netzwierk ass zouverlässeg", "Null latency", an "onendlech Duerchgang" Mëssverständnisser sinn. Aner Mëssverständnisser enthalen d'Aussoen "d'Netzwierk ass sécher", "d'Topologie ännert sech ni", "et gëtt ëmmer nëmmen een Administrateur", "d'Käschte vum Datentransfer sinn null", an "d'Netz ass homogen."
Si hunn e Feeler gemaach well se hire Service op lokalen Maschinnen getest hunn an ni mat externe Servicer ugeschloss hunn. Wann se lokal entwéckelen an e lokalen Cache benotzen, hu se ni Netzwierkhops begéint. An allen 18 Méint vun der Entwécklung hu si sech ni eng Kéier gefrot, wat kéint geschéien, wann extern Servicer betraff wieren.
Wann Dir d'Servicegrenzen an der viregter Bild kuckt, kënnt Dir gesinn datt se all falsch sinn. Et gi vill Quellen déi beroden wéi Dir Servicegrenzen definéiert, an déi meescht maachen et falsch, wéi Microsoft op der nächster Rutsch.
Dëst Bild ass vum MS Blog zum Thema "Wéi bauen ech Mikroservicer". Dëst weist eng einfach Webapplikatioun, e Block vu Geschäftslogik an eng Datebank. D'Ufro kënnt direkt, et gëtt wahrscheinlech ee Server fir de Web, ee Server fir d'Geschäft an een fir d'Datebank. Wann Dir den Traffic erhéicht, ännert sech d'Bild e bëssen.
Здесь появляется балансировщик нагрузки для распределения трафика между двумя веб-серверами, кэш, расположенный между веб-сервисом и бизнес-логикой и еще один кэш между бизнес-логикой и базой данных. Именно такую архитектуру использовала компания Bell для своего приложения – балансировку нагрузки и blue/green развертывание, выполненное в середине 2000-х. До некоторого времени все работало хорошо, поскольку данная схема предназначалась для монолитной структуры.
Déi folgend Bild weist wéi MS recommandéiert vun engem Monolith op Mikroservicer ze plënneren - einfach all eenzel vun den Haaptservicer an getrennten Mikroservicer opzedeelen. Et war während der Ëmsetzung vun dësem Schema datt Bell e Feeler gemaach huet.
Si hunn all hir Servicer an verschidden Niveauen opgedeelt, déi all aus villen eenzelne Servicer bestoen. Zum Beispill huet de Webservice Mikroservicer fir Inhaltsrendering an Authentifikatioun abegraff, de Business Logik Service bestoung aus Mikroservicer fir Bestellungen a Kontinformatioun ze veraarbecht, d'Datebank gouf an eng Rëtsch Mikroservicer mat spezialiséierten Donnéeën opgedeelt. Souwuel de Web, d'Geschäftslogik an d'Datebank ware stateless Servicer.
Allerdéngs war dëst Bild komplett falsch well et keng Geschäftsunitéiten ausserhalb vum IT-Cluster vun der Firma kartéiert huet. Dëse Schema huet keng Verbindung mat der Äussewelt berücksichtegt, sou datt et net kloer war wéi zum Beispill Drëtt Partei Business Analytiken ze kréien. Ech stelle fest, datt si och verschidde Servicer erfonnt hunn, einfach fir d'Carrière vun eenzelne Mataarbechter z'entwéckelen, déi versicht hunn, sou vill wéi méiglech Leit ze managen, fir méi Sue dofir ze kréien.
Si hunn gegleeft datt de Plënneren op Mikroservicer sou einfach war wéi hir intern N-Tier kierperlech Layerinfrastruktur ze huelen an Docker drop ze hänken. Loosst eis kucken wéi traditionell N-Tier Architektur ausgesäit.
Et besteet aus 4 Niveauen: den UI User Interface Niveau, de Business Logik Niveau, den Datezougang Niveau an d'Datebank. Méi progressiv ass DDD (Domain-Driven Design), oder Software-orientéiert Architektur, wou déi zwee Mëttelstufe Domainobjekter an e Repository sinn.
Ech hu probéiert verschidde Verännerungsberäicher, verschidde Verantwortungsberäicher an dëser Architektur ze kucken. An enger typescher N-Tier Applikatioun gi verschidde Verännerungsberäicher klasséiert déi d'Struktur vertikal vun uewe bis ënnen permeéieren. Dëst sinn Katalog, Config-Astellungen, déi op eenzel Computere gemaach goufen, a Checkout-Kontrollen, déi vu mengem Team gehandhabt goufen.
D'Besonderheet vun dësem Schema ass datt d'Grenze vun dëse Verännerungsberäicher net nëmmen de Business Logik Niveau beaflossen, awer och op d'Datebank verlängeren.
Loosst eis kucken wat et heescht e Service ze sinn. Et gi 6 charakteristesch Eegeschafte vun enger Servicedefinitioun - et ass Software déi:
- erstallt a benotzt vun enger spezifescher Organisatioun;
- ass verantwortlech fir den Inhalt, d'Veraarbechtung an/oder d'Versuergung vun enger bestëmmter Zort vun Informatioun am System;
- kann onofhängeg gebaut, agesat a lafen fir spezifesch operationell Bedierfnesser ze treffen;
- kommunizéiert mat Konsumenten an aner Servicer, liwwert Informatioun baséiert op Ofkommes oder kontraktuell Garantien;
- schützt sech virun onerlaabten Zougang, a seng Informatioun vu Verloscht;
- geréiert Feeler esou, datt se net zu Informatiounsschued féieren.
All dës Eegeschafte kënnen an engem Wuert "Autonomie" ausgedréckt ginn. D'Servicer funktionnéieren onofhängeg vuneneen, erfëllen bestëmmte Restriktiounen, an definéieren Kontrakter op Basis vun deenen d'Leit d'Informatioun kréien déi se brauchen. Ech hunn net spezifesch Technologien ernimmt, d'Benotzung vun deenen selbstverständlech ass.
Loosst eis elo d'Definitioun vu Mikroservicer kucken:
- e Mikroservice ass kleng a Gréisst an entwéckelt fir ee spezifesche Problem ze léisen;
- De Mikroservice ass autonom;
- Wann Dir eng Mikroservicearchitektur erstellt, gëtt d'Stadplanungsmetapher benotzt. Dëst ass d'Definitioun vum Sam Newman sengem Buch, Building Microservices.
D'Definitioun vu Bounded Context ass aus dem Eric Evans sengem Buch Domain-Driven Design geholl. Dëst ass e Kärmuster an DDD, en Architekturdesignzentrum dee mat volumetreschen architektonesche Modeller schafft, se a verschidde begrenzte Kontexter opdeelt an d'Interaktiounen tëscht hinnen explizit definéiert.
Einfach gesot, e Bounded Context bezeechent den Ëmfang an deem e bestëmmte Modul ka benotzt ginn. An dësem Kontext ass e logesch vereenegt Modell deen zum Beispill an Ärem Business Domain gesi ka ginn. Wann Dir frot "wien ass e Client" un d'Personal, déi u Bestellungen involvéiert ass, kritt Dir eng Definitioun, wann Dir déi, déi am Verkaf involvéiert sinn, freet, kritt Dir eng aner, an d'Performance ginn Iech eng drëtt Definitioun.
Also, Bounded Context seet datt wa mir net eng kloer Definitioun kënne ginn wat e Konsument vun eise Servicer ass, loosst eis d'Grenze definéieren, an deenen mir iwwer d'Bedeitung vun dësem Begrëff schwätzen, an dann d'Iwwergangspunkten tëscht dësen verschiddenen Definitiounen definéieren. Dat heescht, wa mir iwwer e Client schwätzen aus der Siicht vun der Bestellung, heescht dat an dat, a wann aus der Siicht vum Verkaf, heescht dat dat an dat.
Déi nächst Definitioun vun engem Mikroservice ass d'Verkapselung vun all Zort vun internen Operatiounen, verhënnert datt d'"Leckage" vun de Komponente vum Aarbechtsprozess an d'Ëmwelt verhënnert. Als nächst kënnt d'"Definitioun vun explizit Kontrakter fir extern Interaktiounen, oder extern Kommunikatiounen", déi duerch d'Iddi vu Kontrakter vertruede gëtt, déi aus SLAs zréckkommen. Déi lescht Definitioun ass d'Metapher vun enger Zell, oder Zell, dat heescht déi komplett Verkapselung vun enger Rei vun Operatiounen an engem Mikrodéngscht an d'Präsenz an deem vun Rezeptoren fir Kommunikatioun mat der Äussewelt.
Also hu mir zu de Kärelen vun Bell Computers gesot: "Mir kënnen de Chaos net fixéieren deen Dir erstallt hutt well Dir just net d'Suen hutt fir et ze maachen, awer mir fixéieren nëmmen ee Service fir alles ze maachen Sënn." Zu dësem Zäitpunkt fänken ech un Iech ze soen wéi mir eisen eenzegen Service fixéiert hunn, sou datt en op Ufroe méi séier wéi 9 an eng hallef Minutt geäntwert huet.
22:30 Uhr Min
Ganz geschwënn weiderféieren...
E bësse Reklamm
Merci datt Dir bei eis bleift. Hutt Dir eis Artikelen gär? Wëllt Dir méi interessant Inhalt gesinn? Ënnerstëtzt eis andeems Dir eng Bestellung maacht oder Frënn empfeelt, , en eenzegaartegen Analog vun Entry-Level Serveren, dee vun eis fir Iech erfonnt gouf: (verfügbar mat RAID1 an RAID10, bis zu 24 Kären a bis zu 40GB DDR4).
Dell R730xd 2 Mol méi bëlleg an Equinix Tier IV Daten Zentrum zu Amsterdam? Nëmmen hei an Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vun $99! Liest iwwer
Source: will.com