Jy het maande spandeer om jou monoliet in mikrodienste te herontwerp, en uiteindelik het almal saamgekom om die skakelaar te draai. Jy gaan na die eerste webblad... en niks gebeur nie. Jy herlaai dit - en weer niks goed nie, die webwerf is so stadig dat dit vir 'n paar minute nie reageer nie. Wat het gebeur?
In sy toespraak sal Jimmy Bogard 'n "nadoodse ondersoek" doen oor 'n werklike mikrodiensramp. Hy sal die modellerings-, ontwikkelings- en produksieprobleme wys wat hy ontdek het, en hoe sy span die nuwe verspreide monoliet stadig omskep het in die finale prentjie van gesonde verstand. Alhoewel dit onmoontlik is om ontwerpfoute heeltemal te voorkom, kan u ten minste probleme vroeg in die ontwerpproses identifiseer om te verseker dat die finale produk 'n betroubare verspreide stelsel word.
Hallo almal, ek is Jimmy en vandag gaan jy hoor hoe jy mega-rampe kan vermy wanneer jy mikrodienste bou. Dit is die storie van 'n maatskappy vir wie ek sowat 'n jaar en 'n half gewerk het om te help voorkom dat hul skip met 'n ysberg bots. Om hierdie storie behoorlik te vertel, sal ons terug in tyd moet gaan en praat oor waar hierdie maatskappy begin het en hoe sy IT-infrastruktuur mettertyd gegroei het. Om die name van die onskuldiges in hierdie ramp te beskerm, het ek die naam van hierdie maatskappy na Bell Computers verander. Die volgende skyfie wys hoe die IT-infrastruktuur van sulke maatskappye in die middel-90's gelyk het. Dit is 'n tipiese argitektuur van 'n groot universele foutverdraagsame HP Tandem Mainframe-bediener vir die bedryf van 'n rekenaar hardewarewinkel.
Hulle moes 'n stelsel bou om alle bestellings, verkope, opbrengste, produkkatalogusse en kliëntebasis te bestuur, so hulle het destyds die mees algemene hoofraamoplossing gekies. Hierdie reusagtige stelsel het elke stukkie inligting oor die maatskappy bevat, alles moontlik, en elke transaksie is deur hierdie hoofraam uitgevoer. Hulle het al hul eiers in een mandjie gehou en gedink dit is normaal. Die enigste ding wat nie hier ingesluit is nie, is posbestellingskatalogusse en die plasing van bestellings per telefoon.
Met verloop van tyd het die stelsel groter en groter geword, en 'n groot hoeveelheid vullis het daarin opgehoop. COBOL is ook nie die mees ekspressiewe taal in die wêreld nie, so die stelsel het uiteindelik 'n groot, monolitiese rommel geword. Teen 2000 het hulle gesien dat baie maatskappye webwerwe gehad het waardeur hulle absoluut al hul besigheid gedoen het, en het besluit om hul eerste kommersiële dot-com-webwerf te bou.
Die aanvanklike ontwerp het redelik mooi gelyk en het bestaan uit 'n topvlak-werf bell.com en 'n aantal subdomeine vir individuele toepassings: catalog.bell.com, accounts.bell.com, orders.bell.com, produksoektog search.bell. com. Elke subdomein het die ASP.Net 1.0-raamwerk en sy eie databasisse gebruik, en hulle het almal met die stelsel se agterkant gepraat. Alle bestellings het egter voortgegaan om verwerk en uitgevoer te word binne 'n enkele groot hoofraam, waarin al die vullis gebly het, maar die voorkant was aparte webwerwe met individuele toepassings en aparte databasisse.
Die ontwerp van die stelsel het dus ordelik en logies gelyk, maar die werklike stelsel was soos in die volgende skyfie getoon.
Alle elemente het oproepe aan mekaar gerig, toegang tot API's, ingebedde derdeparty-dll's, en dies meer. Dit het dikwels gebeur dat weergawebeheerstelsels iemand anders se kode sou gryp, dit binne die projek stoot, en dan sou alles breek. MS SQL Server 2005 het die konsep van skakelbedieners gebruik, en alhoewel ek nie die pyle op die skyfie gewys het nie, het elkeen van die databasisse ook met mekaar gepraat, want daar is niks fout daarmee om tabelle te bou gebaseer op data wat van verskeie databasisse verkry is nie.
Aangesien hulle nou 'n mate van skeiding tussen verskillende logiese areas van die stelsel gehad het, het dit verspreide stukke vuil geword, met die grootste stuk vullis wat nog in die hoofraam-agterkant oorgebly het.
Die snaakse ding was dat hierdie hoofraam gebou is deur mededingers van Bell Computers en steeds deur hul tegniese konsultante in stand gehou is. Oortuig van die onbevredigende prestasie van sy toepassings, het die maatskappy besluit om daarvan ontslae te raak en die stelsel te herontwerp.
Die bestaande toepassing was vir 15 jaar in produksie, wat 'n rekord vir ASP.Net-gebaseerde toepassings is. Die diens het bestellings van regoor die wêreld aanvaar, en die jaarlikse inkomste uit hierdie enkele toepassing het 'n miljard dollar bereik. 'n Beduidende deel van die wins is deur die bell.com-webwerf gegenereer. Op Swart Vrydae het die aantal bestellings wat deur die webwerf geplaas is, etlike miljoene bereik. Die bestaande argitektuur het egter geen ontwikkeling toegelaat nie, aangesien die rigiede onderlinge verbindings van stelselelemente feitlik nie toegelaat het dat enige veranderinge aan die diens gemaak kon word nie.
Die ernstigste probleem was die onvermoë om 'n bestelling van een land te plaas, daarvoor in 'n ander te betaal en dit na 'n derde te stuur, ten spyte van die feit dat so 'n handelskema baie algemeen in globale maatskappye voorkom. Die bestaande webwerf het nie vir so iets toegelaat nie, so hulle moes hierdie bestellings oor die telefoon aanvaar en plaas. Dit het daartoe gelei dat die maatskappy toenemend daaraan gedink het om die argitektuur te verander, veral om na mikrodienste oor te skakel.
Hulle het die slim ding gedoen deur na ander maatskappye te kyk om te sien hoe hulle 'n soortgelyke probleem opgelos het. Een van hierdie oplossings was die Netflix-diensargitektuur, wat bestaan uit mikrodienste wat via 'n API en 'n eksterne databasis gekoppel is.
Bell Computers-bestuur het besluit om net so 'n argitektuur te bou, met voldoening aan sekere basiese beginsels. Eerstens het hulle dataduplisering uitgeskakel deur 'n gedeelde databasisbenadering te gebruik. Geen data is gestuur nie, inteendeel, almal wat dit nodig gehad het, moes na 'n gesentraliseerde bron gaan. Dit is gevolg deur isolasie en outonomie – elke diens was onafhanklik van die ander. Hulle het besluit om die Web API vir absoluut alles te gebruik - as jy data wou kry of veranderinge aan 'n ander stelsel wou maak, is dit alles deur die Web API gedoen. Die laaste groot ding was 'n nuwe hoofraam genaamd "Bell on Bell" in teenstelling met die "Bell" hoofraam gebaseer op mededingers se hardeware.
So, oor die loop van 18 maande het hulle die stelsel rondom hierdie kernbeginsels gebou en dit na voorproduksie gebring. Toe hulle ná die naweek teruggekeer het werk toe, het die ontwikkelaars bymekaargekom en al die bedieners aangeskakel waaraan die nuwe stelsel gekoppel is. 18 maande se werk, honderde ontwikkelaars, die modernste Bell-hardeware - en geen positiewe resultaat nie! Dit het baie mense teleurgestel omdat hulle hierdie stelsel al baie keer op hul skootrekenaars gebruik het en alles was in orde.
Hulle was slim om al hul geld te gooi om hierdie probleem op te los. Hulle het die modernste bedienerrakke met skakelaars geïnstalleer, gigabit optiese vesel gebruik, die kragtigste bedienerhardeware met 'n waansinnige hoeveelheid RAM, alles gekoppel, dit gekonfigureer - en weer, niks! Toe begin hulle vermoed dat die rede dalk time-outs is, so hulle het in al die webinstellings, al die API-instellings ingegaan en die hele timeout-konfigurasie opgedateer tot die maksimum waardes, sodat al wat hulle kon doen was om te sit en wag dat iets gebeur na die werf. Hulle het vir 9 en 'n half minute gewag en gewag en gewag totdat die webwerf uiteindelik gelaai het.
Daarna het dit tot hulle deurgedring dat die huidige situasie 'n deeglike ontleding nodig het, en hulle het ons genooi. Die eerste ding wat ons uitgevind het, was dat daar gedurende al 18 maande van ontwikkeling nie 'n enkele werklike "mikro" geskep is nie - alles het net groter geword. Hierna het ons begin om 'n nadoodse ondersoek te skryf, ook bekend as 'n "regretrospective", of "sad retrospective", ook bekend as 'n "blame storm", soortgelyk aan 'n "brein storm", om die oorsaak van die ramp te verstaan.
Ons het verskeie leidrade gehad, waarvan een volledige verkeerversadiging was ten tyde van die API-oproep. Wanneer jy 'n monolitiese diensargitektuur gebruik, kan jy dadelik verstaan wat presies verkeerd geloop het, want jy het 'n enkele stapelspoor wat alles rapporteer wat die mislukking kon veroorsaak het. In die geval waar 'n klomp dienste gelyktydig toegang tot dieselfde API het, is daar geen manier om die spoor op te spoor nie, behalwe om addisionele netwerkmoniteringsinstrumente soos WireShark te gebruik, waardeur u 'n enkele versoek kan ondersoek en uitvind wat tydens die implementering daarvan gebeur het. Ons het dus een webbladsy geneem en byna 2 weke spandeer om die stukkies van die legkaart bymekaar te sit, 'n verskeidenheid oproepe daarheen te maak en te ontleed waartoe elkeen gelei het.
Kyk na hierdie prentjie. Dit wys dat een eksterne versoek die diens aanspoor om baie interne oproepe te maak wat terugkom. Dit blyk dat elke interne oproep bykomende hops maak om hierdie versoek onafhanklik te kan bedien, want dit kan nêrens anders draai om die nodige inligting te bekom nie. Hierdie prentjie lyk soos 'n betekenislose waterval van oproepe, aangesien die eksterne versoek addisionele dienste oproep, wat ander bykomende dienste oproep, ensovoorts, amper ad infinitum.
Die groen kleur in hierdie diagram toon 'n halfsirkel waarin dienste mekaar roep - diens A roep diens B, diens B roep diens C, en dit roep weer diens A. Gevolglik kry ons 'n "verspreide dooiepunt". 'n Enkele versoek het 'n duisend netwerk-API-oproepe geskep, en aangesien die stelsel nie ingeboude fouttoleransie en lusbeskerming gehad het nie, sou die versoek misluk as selfs een van hierdie API-oproepe misluk het.
Ons het 'n bietjie wiskunde gedoen. Elke API-oproep het 'n SLA van nie meer as 150 ms en 99,9% uptyd gehad nie. Een versoek het 200 verskillende oproepe veroorsaak, en in die beste geval kon die bladsy in 200 x 150 ms = 30 sekondes gewys word. Dit was natuurlik nie goed nie. Deur 99,9% uptyd met 200 te vermenigvuldig, het ons 0% beskikbaarheid gekry. Dit blyk dat hierdie argitektuur van die begin af tot mislukking gedoem was.
Ons het die ontwikkelaars gevra hoe hulle nie hierdie probleem herken het na 18 maande se werk nie? Dit het geblyk dat hulle net die SLA getel het vir die kode wat hulle gebruik het, maar as hul diens 'n ander diens gebel het, het hulle nie daardie tyd in hul SLA getel nie. Alles wat binne een proses van stapel gestuur is, het by die waarde van 150 ms gehou, maar toegang tot ander diensprosesse het die totale vertraging baie keer verhoog. Die eerste les wat geleer is was: "Is jy in beheer van jou SLA, of is die SLA in beheer van jou?" In ons geval was dit laasgenoemde.
Die volgende ding wat ons ontdek het, was dat hulle geweet het van die konsep van verspreide rekenaar wanopvattings, geformuleer deur Peter Deitch en James Gosling, maar hulle het die eerste deel daarvan geïgnoreer. Dit verklaar dat die stellings "die netwerk is betroubaar", "nul latensie" en "oneindige deurset" wanopvattings is. Ander wanopvattings sluit in die stellings "die netwerk is veilig", "die topologie verander nooit nie," "daar is altyd net een administrateur," "die koste van data-oordrag is nul," en "die netwerk is homogeen."
Hulle het 'n fout gemaak omdat hulle hul diens op plaaslike masjiene getoets het en nooit by eksterne dienste aangesluit het nie. Wanneer hulle plaaslik ontwikkel en 'n plaaslike kas gebruik, het hulle nooit netwerk hops teëgekom nie. In al 18 maande van ontwikkeling het hulle nooit een keer gewonder wat kan gebeur as eksterne dienste geraak word nie.
As jy na die diensgrense in die vorige prent kyk, kan jy sien dat hulle almal verkeerd is. Daar is baie bronne wat raad gee oor hoe om diensgrense te definieer, en die meeste doen dit verkeerd, soos Microsoft op die volgende skyfie.
Hierdie foto is van die MS-blog oor die onderwerp "Hoe om mikrodienste te bou". Dit wys 'n eenvoudige webtoepassing, 'n blok besigheidslogika en 'n databasis. Die versoek kom direk, daar is waarskynlik een bediener vir die web, een bediener vir die besigheid en een vir die databasis. As jy verkeer verhoog, sal die prentjie 'n bietjie verander.
Hier kom 'n lasbalanseerder om verkeer tussen twee webbedieners te versprei, 'n kas geleë tussen die webdiens en die besigheidslogika, en 'n ander kas tussen die besigheidslogika en die databasis. Dit is presies die argitektuur wat Bell gebruik het vir sy lasbalansering en blou/groen-ontplooiingstoepassing in die middel van die 2000's. Tot 'n geruime tyd het alles goed gewerk, aangesien hierdie skema bedoel was vir 'n monolitiese struktuur.
Die volgende prent wys hoe MS aanbeveel om van 'n monoliet na mikrodienste te beweeg - om elkeen van die hoofdienste in aparte mikrodienste te verdeel. Dit was tydens die implementering van hierdie skema dat Bell 'n fout gemaak het.
Hulle het al hul dienste in verskillende vlakke verdeel, wat elkeen uit baie individuele dienste bestaan het. Die webdiens het byvoorbeeld mikrodienste vir inhoudweergawe en verifikasie ingesluit, die besigheidslogikadiens het bestaan uit mikrodienste vir die verwerking van bestellings en rekeninginligting, die databasis is in 'n klomp mikrodienste met gespesialiseerde data verdeel. Beide die web, besigheidslogika en databasis was staatlose dienste.
Hierdie prentjie was egter heeltemal verkeerd omdat dit geen besigheidseenhede buite die maatskappy se IT-groepering gekarteer het nie. Hierdie skema het geen verband met die buitewêreld in ag geneem nie, so dit was nie duidelik hoe om byvoorbeeld derdeparty-besigheidsanalise te verkry nie. Ek merk op dat hulle ook verskeie dienste laat uitvind het bloot om die loopbane van individuele werknemers te ontwikkel wat probeer het om soveel mense as moontlik te bestuur om meer geld daarvoor te kry.
Hulle het geglo dat die oorskakeling na mikrodienste so maklik was soos om hul interne N-vlak fisieke laag-infrastruktuur te neem en Docker daarop te plak. Kom ons kyk na hoe tradisionele N-vlak argitektuur lyk.
Dit bestaan uit 4 vlakke: die UI-gebruikerskoppelvlakvlak, die besigheidslogikavlak, die datatoegangsvlak en die databasis. Meer progressief is DDD (Domain-Driven Design), of sagteware-georiënteerde argitektuur, waar die twee middelste vlakke domeinobjekte en 'n bewaarplek is.
Ek het probeer om te kyk na verskillende areas van verandering, verskillende areas van verantwoordelikheid in hierdie argitektuur. In 'n tipiese N-vlak toepassing word verskillende areas van verandering geklassifiseer wat die struktuur vertikaal van bo na onder deurdring. Dit is Katalogus, Config-instellings wat op individuele rekenaars uitgevoer word, en Checkout-kontroles, wat deur my span hanteer is.
Die eienaardigheid van hierdie skema is dat die grense van hierdie gebiede van verandering nie net die besigheidslogikavlak beïnvloed nie, maar ook na die databasis strek.
Kom ons kyk na wat dit beteken om 'n diens te wees. Daar is 6 kenmerkende eienskappe van 'n diensdefinisie - dit is sagteware wat:
- geskep en gebruik deur 'n spesifieke organisasie;
- verantwoordelik is vir die inhoud, verwerking en/of verskaffing van 'n sekere tipe inligting binne die stelsel;
- onafhanklik gebou, ontplooi en bedryf kan word om aan spesifieke operasionele behoeftes te voldoen;
- kommunikeer met verbruikers en ander dienste, verskaf inligting gebaseer op ooreenkomste of kontraktuele waarborge;
- beskerm homself teen ongemagtigde toegang, en sy inligting teen verlies;
- mislukkings op so 'n wyse hanteer dat dit nie tot inligtingskade lei nie.
Al hierdie eienskappe kan in een woord "outonomie" uitgedruk word. Dienste funksioneer onafhanklik van mekaar, voldoen aan sekere beperkings, en definieer kontrakte op grond waarvan mense die inligting kan ontvang wat hulle benodig. Ek het nie spesifieke tegnologieë genoem nie, waarvan die gebruik vanselfsprekend is.
Kom ons kyk nou na die definisie van mikrodienste:
- 'n mikrodiens is klein van grootte en ontwerp om een spesifieke probleem op te los;
- Die mikrodiens is outonoom;
- Wanneer 'n mikrodiensargitektuur geskep word, word die stadsbeplanningsmetafoor gebruik. Dit is die definisie uit Sam Newman se boek, Building Microservices.
Die definisie van Bounded Context is geneem uit Eric Evans se boek Domain-Driven Design. Dit is 'n kernpatroon in DDD, 'n argitektuurontwerpsentrum wat met volumetriese argitektoniese modelle werk, wat hulle in verskillende Begrensde kontekste verdeel en die interaksies tussen hulle uitdruklik definieer.
Eenvoudig gestel, 'n Begrensde konteks dui die omvang aan waarin 'n bepaalde module gebruik kan word. Binne hierdie konteks is 'n logies verenigde model wat byvoorbeeld in jou besigheidsdomein gesien kan word. As jy vra "wie is 'n kliënt" aan die personeel betrokke by bestellings, sal jy een definisie kry, as jy diegene wat betrokke is by verkope vra, sal jy 'n ander kry, en die kunstenaars sal vir jou 'n derde definisie gee.
Dus, Bounded Context sê dat as ons nie 'n duidelike definisie kan gee van wat 'n verbruiker van ons dienste is nie, kom ons definieer die grense waarbinne ons kan praat oor die betekenis van hierdie term, en definieer dan die oorgangspunte tussen hierdie verskillende definisies. Dit wil sê, as ons van 'n kliënt praat uit die oogpunt van bestellings, beteken dit dit en dat, en as uit die oogpunt van verkope, beteken dit dit en dat.
Die volgende definisie van 'n mikrodiens is die inkapseling van enige soort interne bedrywighede, wat die "lekkasie" van die komponente van die werkproses in die omgewing voorkom. Vervolgens kom die "definisie van eksplisiete kontrakte vir eksterne interaksies, of eksterne kommunikasie," wat verteenwoordig word deur die idee van kontrakte wat terugkeer van SLA's. Die laaste definisie is die metafoor van 'n sel, of sel, wat beteken die volledige inkapseling van 'n stel bewerkings binne 'n mikrodiens en die teenwoordigheid daarin van reseptore vir kommunikasie met die buitewêreld.
So ons het vir die ouens by Bell Computers gesê: "Ons kan nie enige van die chaos wat jy geskep het regmaak nie, want jy het net nie die geld om dit te doen nie, maar ons sal net een diens regmaak om dit alles te maak sin.” Op hierdie stadium sal ek begin deur jou te vertel hoe ons ons enigste diens reggestel het sodat dit vinniger as 9 en 'n half minute op versoeke gereageer het.
22:30 min
Word binnekort vervolg...
Bietjie advertensie
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com