Jo hawwe moannen bestege oan it werûntwerpen fan jo monolith yn mikrotsjinsten, en úteinlik is elkenien gearkommen om de skeakel om te draaien. Jo geane nei de earste webside ... en neat bart. Jo opnij laden - en wer neat goed, de side is sa stadich dat it net reagearret foar ferskate minuten. Wat is bard?
Yn syn petear sil Jimmy Bogard in "post-mortem" útfiere op in real-life microservice-ramp. Hy sil de problemen mei modellen, ûntwikkeling en produksje sjen litte dy't hy ûntduts, en hoe't syn team de nije ferspraat monolith stadichoan transformearre yn it definitive byld fan ferstân. Hoewol it ûnmooglik is om ûntwerpflaters folslein te foarkommen, kinne jo op syn minst problemen betiid identifisearje yn it ûntwerpproses om te soargjen dat it definitive produkt in betrouber ferspraat systeem wurdt.
Hallo elkenien, ik bin Jimmy en hjoed sille jo hearre hoe't jo mega-rampen kinne foarkomme by it bouwen fan mikrotsjinsten. Dit is it ferhaal fan in bedriuw wêrfoar ik sawat oardel jier wurke om te helpen foar te kommen dat har skip mei in iisberch botst. Om dit ferhaal goed te fertellen, sille wy werom moatte yn 'e tiid en prate oer wêr't dit bedriuw begon en hoe't har IT-ynfrastruktuer yn 'e rin fan' e tiid groeid is. Om de nammen fan dy ûnskuldigen yn dizze ramp te beskermjen, haw ik de namme fan dit bedriuw feroare yn Bell Computers. De folgjende dia lit sjen hoe't de IT-ynfrastruktuer fan sokke bedriuwen der yn 'e midden fan' e jierren '90 útseach. Dit is in typyske arsjitektuer fan in grutte universele fault-tolerante HP Tandem Mainframe tsjinner foar it operearjen fan in kompjûter hardware winkel.
Se moasten in systeem bouwe om alle oarders, ferkeap, rendeminten, produktkatalogen en klantbasis te behearjen, sadat se destiids de meast foarkommende mainframe-oplossing keas. Dit gigantyske systeem befette elke bytsje ynformaasje oer it bedriuw, alles mooglik, en elke transaksje waard útfierd fia dit mainframe. Se holden al har aaien yn ien koer en tochten dat dat normaal wie. It iennichste ding dat hjir net opnommen is is postorderkatalogen en it pleatsen fan bestellingen fia tillefoan.
Nei ferrin fan tiid, it systeem waard grutter en grutter, en in grutte hoemannichte jiskefet sammele yn it. COBOL is ek net de meast ekspressive taal yn 'e wrâld, sadat it systeem úteinlik in grut, monolitysk stik rommel wie. Tsjin 2000 seagen se dat in protte bedriuwen websiden hiene wêrmei't se absolút al har bedriuw fierden, en besleaten om har earste kommersjele dot-com-webside te bouwen.
It earste ûntwerp seach aardich moai út en bestie út in top-nivo site bell.com en in oantal subdomains foar yndividuele applikaasjes: catalog.bell.com, accounts.bell.com, orders.bell.com, produkt sykje search.bell. com. Elk subdomein brûkte it ASP.Net 1.0-ramt en har eigen databases, en se prate allegear mei it systeembackend. Alle oarders bleaunen lykwols ferwurke en útfierd binnen ien enoarme mainframe, wêryn alle ôffal bleau, mar de foarkant wie aparte websiden mei yndividuele applikaasjes en aparte databases.
Sa seach it ûntwerp fan it systeem oarderlik en logysk út, mar it eigentlike systeem wie lykas werjûn yn 'e folgjende dia.
Alle eleminten rjochte oproppen oan elkoar, tagong API's, ynbêde dll's fan tredden, en sa. It barde faak dat ferzjekontrôlesystemen de koade fan in oar pakke, it binnen it projekt skowe, en dan soe alles brekke. MS SQL Server 2005 brûkte it konsept fan keppeling tsjinners, en hoewol't ik net sjen litte de pylken op 'e slide, elk fan' e databases ek praat mei elkoar, want der is neat mis mei it bouwen fan tabellen basearre op gegevens krigen út ferskate databases .
Om't se no wat skieding hiene tusken ferskate logyske gebieten fan it systeem, waard dit ferspraat smoargens, mei it grutste stik jiskefet noch oerbleaun yn 'e mainframe-backend.
It grappige ding wie dat dit mainframe waard boud troch konkurrinten fan Bell Computers en waard noch ûnderhâlden troch harren technyske adviseurs. Oertsjûge fan 'e ûnfoldwaande prestaasjes fan har applikaasjes, besleat it bedriuw har kwyt te reitsjen en it systeem opnij te ûntwerpen.
De besteande applikaasje wie 15 jier yn produksje west, wat in rekord is foar ASP.Net-basearre applikaasjes. De tsjinst akseptearre oarders fan oer de hiele wrâld, en jierlikse ynkomsten út dizze inkele applikaasje berikte in miljard dollar. In signifikant diel fan 'e winst waard generearre troch de webside bell.com. Op Black Fridays berikte it oantal bestellingen pleatst fia de side ferskate miljoenen. De besteande arsjitektuer hat lykwols gjin ûntjouwing tastien, om't de stive ferbiningen fan systeemeleminten praktysk gjin feroaringen yn 'e tsjinst talitte.
It meast serieuze probleem wie it ûnfermogen om in bestelling út ien lân te pleatsen, it yn in oar te beteljen en it nei in tredde te stjoeren, nettsjinsteande it feit dat sa'n hannelskema heul gewoan is yn globale bedriuwen. De besteande webside liet soks net ta, dat se moasten dizze bestellingen fia de telefoan akseptearje en pleatse. Dat late der ta dat it bedriuw hieltyd mear neitocht oer it feroarjen fan de arsjitektuer, benammen oer de oerstap nei mikrotsjinsten.
Se diene it tûke ding troch te sjen nei oare bedriuwen om te sjen hoe't se in ferlykber probleem hienen oplost. Ien fan dizze oplossingen wie de Netflix-tsjinstarsjitektuer, dy't bestiet út mikrotsjinsten ferbûn fia in API en in eksterne database.
Bell Computers behear besletten om te bouwen krekt sa'n arsjitektuer, adhering oan bepaalde basisprinsipes. Earst elimineare se gegevensduplikaasje troch in dielde databankoanpak te brûken. Der waarden gjin gegevens ferstjoerd, krekt oarsom, elkenien dy't it nedich hie, moast nei in sintrale boarne. Dit waard folge troch isolemint en autonomy - elke tsjinst wie ûnôfhinklik fan 'e oaren. Se besleaten de Web API te brûken foar absolút alles - as jo gegevens wolle krije of wizigingen meitsje wolle oan in oar systeem, waard it allegear dien fia de Web API. De lêste grutte ding wie in nij mainframe neamd "Bell on Bell" yn tsjinstelling ta de "Bell" mainframe dat wie basearre op konkurrinten 'hardware.
Dat, yn 'e rin fan 18 moannen, bouden se it systeem om dizze kearnprinsipes hinne en brochten it nei foarproduksje. Nei it wykein werom nei it wurk, kamen de ûntwikkelders byinoar en skeakelen alle servers oan wêrmei it nije systeem ferbûn wie. 18 moannen fan wurk, hûnderten ûntwikkelders, de meast moderne Bell-hardware - en gjin posityf resultaat! Dit hat in protte minsken teloarsteld, om't se dit systeem in protte kearen op har laptops hawwe útfierd en alles wie goed.
Se wiene tûk om al har jild te goaien by it oplossen fan dit probleem. Se ynstalleare de meast moderne serverracks mei skeakels, brûkten gigabit optyske glêstried, de machtichste serverhardware mei in dwylsinnige hoemannichte RAM, ferbûn it allegear, konfigureare it - en nochris neat! Doe begûnen se te fermoedzjen dat de reden time-outs koe wêze, dat se gongen yn alle webynstellingen, alle API-ynstellingen en aktualisearren de heule time-outkonfiguraasje nei de maksimale wearden, sadat se allinich koenen sitte en wachtsje oant der wat barde nei de side. Se wachte en wachte en wachte foar 9 en in heale minuten oant de webside úteinlik laden.
Dêrnei kaam it har troch dat de hjoeddeistige situaasje in yngeande analyze nedich wie, en hawwe se ús útnoege. It earste ding dat wy fûnen wie dat yn alle 18 moannen fan ûntwikkeling net ien echte "mikro" waard makke - alles waard allinich grutter. Hjirnei begûnen wy in post-mortem te skriuwen, ek wol bekend as in "regretrospective", of "sad retrospective", ek wol bekend as in "blame stoarm", fergelykber mei in "brain stoarm", om de oarsaak fan 'e ramp te begripen.
Wy hienen ferskate oanwizings, wêrfan ien folsleine ferkearsferzadiging wie op it momint fan 'e API-oprop. As jo gebrûk meitsje fan in monolithic tsjinst arsjitektuer, kinne jo fuortendaliks begripe wat krekt gie ferkeard omdat jo hawwe in inkele stack trace dat rapportearret alles dat koe hawwe feroarsake it mislearjen. Yn it gefal dêr't in bosk tsjinsten tagelyk tagong krije ta deselde API, is d'r gjin manier om it spoar te folgjen, útsein ekstra ark foar netwurkmonitoring lykas WireShark te brûken, wêrtroch jo in inkeld fersyk kinne ûndersykje en útfine wat der bard is tidens de ymplemintaasje. Dat wy namen ien webside en hawwe hast 2 wiken bestege om de puzelstikken byinoar te setten, der in ferskaat oan oproppen nei te meitsjen en te analysearjen wêr't elk fan har liede ta.
Sjoch nei dizze foto. It lit sjen dat ien ekstern fersyk de tsjinst freget om in protte ynterne petearen te meitsjen dy't weromkomme. It docht bliken dat elke ynterne oprop ekstra hops makket om dit fersyk selsstannich te tsjinjen, om't it net oars kin draaie om de nedige ynformaasje te krijen. Dizze foto liket in sinleaze kaskade fan petearen, om't it eksterne fersyk ekstra tsjinsten neamt, dy't oare ekstra tsjinsten neame, ensafuorthinne, hast ad infinitum.
De griene kleur yn dit diagram lit in heale sirkel sjen wêryn tsjinsten inoar neame - tsjinst A ropt tsjinst B, tsjinst B ropt tsjinst C, en it ropt tsjinst A wer op. In inkeld fersyk makke tûzen netwurk API-oproppen, en om't it systeem gjin ynboude fouttolerânsje en loopbeskerming hie, soe it fersyk mislearje as sels ien fan dizze API-oproppen mislearre.
Wy diene wat wiskunde. Elke API-oprop hie in SLA fan net mear as 150 ms en 99,9% uptime. Ien fersyk feroarsake 200 ferskillende oproppen, en yn it bêste gefal koe de side yn 200 x 150 ms = 30 sekonden werjûn wurde. Fansels wie dit net goed. Fermannichfâldigje 99,9% uptime troch 200, wy krigen 0% beskikberens. It docht bliken dat dizze arsjitektuer fan it begjin ôf feroardiele wie ta mislearring.
Wy fregen de ûntwikkelders hoe't se dit probleem net wisten te werkennen nei 18 moannen fan wurk? It die bliken dat se allinich de SLA telden foar de koade dy't se rûnen, mar as har tsjinst in oare tsjinst neamde, telden se dy tiid net yn har SLA. Alles dat waard lansearre binnen ien proses folge oan de wearde fan 150 ms, mar tagong ta oare tsjinst prosessen fergrutte de totale fertraging in protte kearen. De earste les dy't hjirfan leard wie: "Bisto yn kontrôle fan jo SLA, of is de SLA yn kontrôle oer jo?" Yn ús gefal wie it de lêste.
It folgjende ding dat wy ûntdutsen wie dat se wisten oer it konsept fan ferdielde komputermisfettings, formulearre troch Peter Deitch en James Gosling, mar se negeare it earste diel dêrfan. It stelt dat de útspraken "it netwurk is betrouber," "nul latency," en "ûneinige trochput" binne misfettings. Oare misferstannen omfetsje de útspraken "it netwurk is feilich", "de topology feroaret noait," "d'r is altyd mar ien behearder," "de kosten fan gegevensferfier binne nul," en "it netwurk is homogeen."
Se makken in flater om't se har tsjinst testten op lokale masines en nea ferbûn mei eksterne tsjinsten. By it ûntwikkeljen fan lokaal en it brûken fan in lokale cache, se hawwe nea tsjinkaam netwurk hops. Yn alle 18 moannen fan ûntwikkeling hawwe se har noait ienris ôffrege wat der barre soe as eksterne tsjinsten wurde beynfloede.
As jo nei de tsjinstgrinzen yn 'e foarige foto sjogge, kinne jo sjen dat se allegear ferkeard binne. D'r binne genôch boarnen dy't advisearje oer hoe't jo tsjinstgrinzen kinne definiearje, en de measten dogge it ferkeard, lykas Microsoft op 'e folgjende dia.
Dizze foto is fan it MS-blog oer it ûnderwerp "Hoe kinne jo mikrotsjinsten bouwe". Dit toant in ienfâldige webapplikaasje, in blok fan saaklike logika, en in database. It fersyk komt direkt, d'r is wierskynlik ien server foar it web, ien server foar it bedriuw en ien foar de database. As jo ferkear ferheegje, sil de ôfbylding in bytsje feroarje.
Hjir komt in load balancer om ferkear te fersprieden tusken twa webservers, in cache tusken de webtsjinst en de saaklike logika, en in oare cache tusken de bedriuwslogika en de database. Dit is krekt de arsjitektuer dy't Bell brûkte foar har load balancing en blau / griene ynsetapplikaasje yn 'e midden fan' e 2000's. Oant in skoftke alles wurke goed, want dit skema wie bedoeld foar in monolithic struktuer.
De folgjende ôfbylding lit sjen hoe't MS oanbefellet te ferpleatsen fan in monolith nei mikrotsjinsten - splitst gewoan elk fan 'e haadtsjinsten yn aparte mikrotsjinsten. It wie by de útfiering fan dit skema dat Bell in flater makke.
Se ferdielde al har tsjinsten yn ferskate lagen, elk fan dy bestie út in protte yndividuele tsjinsten. Bygelyks, de webtsjinst omfette mikrotsjinsten foar ynhâld rendering en autentikaasje, de saaklike logikatsjinst bestie út mikrotsjinsten foar it ferwurkjen fan oarders en akkountynformaasje, de databank waard ferdield yn in bosk mikrotsjinsten mei spesjalisearre gegevens. Sawol it web, saaklike logika en database wiene steatleaze tsjinsten.
Dit byld wie lykwols folslein ferkeard, om't it gjin saaklike ienheden bûten it IT-kluster fan it bedriuw yn kaart brocht. Dit skema hat gjin rekken holden mei elke ferbining mei de bûtenwrâld, dus it wie net dúdlik hoe't, bygelyks, bedriuwsanalytiken fan tredden te krijen. Ik konstatearje dat se ek ferskate tsjinsten hawwe útfûn gewoan om de karriêres te ûntwikkeljen fan yndividuele meiwurkers dy't sochten om safolle mooglik minsken te behearjen om der mear jild foar te krijen.
Se leauden dat it ferpleatsen nei mikrotsjinsten sa maklik wie as har ynterne N-tier fysike laach-ynfrastruktuer nimme en Docker derop plakke. Litte wy ris sjen hoe't tradisjonele N-tier-arsjitektuer derút sjocht.
It bestiet út 4 nivo's: it nivo fan 'e brûkersynterface, it nivo fan bedriuwslogika, it nivo fan gegevenstagong en de databank. Mear progressive is DDD (Domain-Driven Design), of software-rjochte arsjitektuer, wêrby't de twa middelste nivo's domeinobjekten en in repository binne.
Ik besocht te sjen nei ferskate gebieten fan feroaring, ferskillende gebieten fan ferantwurdlikens yn dizze arsjitektuer. Yn in typyske N-tier-applikaasje wurde ferskate gebieten fan feroaring klassifisearre dy't de struktuer fertikaal fan boppe nei ûnderen trochkringe. Dit binne Catalog, Config-ynstellingen útfierd op yndividuele kompjûters, en Checkout-kontrôles, dy't waarden behannele troch myn team.
De eigenaardichheid fan dit skema is dat de grinzen fan dizze gebieten fan feroaring beynfloedzje net allinich it bedriuwslogikanivo, mar ek útwreidzje nei de databank.
Litte wy sjen nei wat it betsjut om in tsjinst te wêzen. D'r binne 6 karakteristike eigenskippen fan in tsjinstdefinysje - it is software dy't:
- makke en brûkt troch in spesifike organisaasje;
- ferantwurdlik is foar de ynhâld, ferwurking en/of fersoarging fan in bepaald soarte ynformaasje binnen it systeem;
- kin selsstannich boud, ynset en rinne om te foldwaan oan spesifike operasjonele behoeften;
- kommunisearret mei konsuminten en oare tsjinsten, it jaan fan ynformaasje basearre op ôfspraken of kontraktuele garânsjes;
- beskermet himsels tsjin net foech tagong, en syn ynformaasje tsjin ferlies;
- behannelet storingen sa dat se net liede ta ynformaasjeskea.
Al dizze eigenskippen kinne wurde útdrukt yn ien wurd "autonomy". Tsjinsten wurkje ûnôfhinklik fan elkoar, foldogge oan bepaalde beheiningen en definiearje kontrakten op basis wêrfan minsken de ynformaasje krije kinne dy't se nedich binne. Ik haw gjin spesifike technologyen neamd, wêrfan it gebrûk fanselssprekkend is.
Litte wy no sjen nei de definysje fan mikrotsjinsten:
- in mikrotsjinst is lyts yn grutte en ûntwurpen om ien spesifyk probleem op te lossen;
- De mikrotsjinst is autonoom;
- By it meitsjen fan in microservice-arsjitektuer wurdt de stedsplanningsmetafoar brûkt. Dit is de definysje fan Sam Newman's boek, Building Microservices.
De definysje fan Bounded Context is nommen út Eric Evans' boek Domain-Driven Design. Dit is in kearnpatroan yn DDD, in arsjitektuerûntwerpsintrum dat wurket mei volumetryske arsjitektoanyske modellen, ferdield yn ferskate Bounded Contexts en eksplisyt de ynteraksjes tusken har definieare.
Simply set, in Bounded Context jout de omfang oan wêryn in bepaalde module kin wurde brûkt. Binnen dizze kontekst is in logysk ferienige model dat te sjen is, bygelyks yn jo bedriuwsdomein. As jo freegje "wa is in klant" oan it personiel dat belutsen is by oarders, krije jo ien definysje, as jo freegje oan dyjingen dy't belutsen binne by ferkeap, krije jo in oare, en de artysten sille jo in tredde definysje jaan.
Dat, Bounded Context seit dat as wy gjin dúdlike definysje kinne jaan fan wat in konsumint fan ús tsjinsten is, litte wy de grinzen definiearje wêryn wy kinne prate oer de betsjutting fan dizze term, en dan de oergongspunten definiearje tusken dizze ferskate definysjes. Dat is, as wy it hawwe oer in klant út it eachpunt fan it pleatsen fan oarders, dit betsjut dit en dat, en as út it eachpunt fan ferkeap, dit betsjut dit en dat.
De folgjende definysje fan in mikroservice is de ynkapseling fan elke soart ynterne operaasjes, it foarkommen fan 'e "lekkage" fan 'e komponinten fan it wurkproses yn 'e omjouwing. Dêrnei komt de "definysje fan eksplisite kontrakten foar eksterne ynteraksjes, as eksterne kommunikaasje", dy't wurdt fertsjintwurdige troch it idee fan kontrakten dy't weromkomme fan SLA's. De lêste definysje is de metafoar fan in sel, of sel, dat betsjut de folsleine ynkapseling fan in set fan operaasjes binnen in mikroservice en de oanwêzigens dêryn fan receptors foar kommunikaasje mei de bûtenwrâld.
Dat wy seine tsjin de jonges by Bell Computers, "Wy kinne net ien fan 'e gaos reparearje dy't jo hawwe makke, om't jo gewoan net it jild hawwe om it te dwaan, mar wy sille mar ien tsjinst reparearje om it allegear te meitsjen sin." Op dit punt sil ik begjinne mei jo te fertellen hoe't wy ús ienige tsjinst reparearre hawwe, sadat it reageare op fersiken rapper dan 9 en in heale minuten.
22:30 min
Folgjende hiel gau ...
In bytsje reklame
Tankewol foar it bliuwen by ús. Hâld jo fan ús artikels? Wolle jo mear ynteressante ynhâld sjen? Stypje ús troch in bestelling te pleatsen of oan te befeljen oan freonen, , in unike analoog fan servers op yngongsnivo, dy't troch ús foar jo útfûn is: (beskikber mei RAID1 en RAID10, oant 24 kearnen en oant 40GB DDR4).
Dell R730xd 2 kear goedkeaper yn Equinix Tier IV data sintrum yn Amsterdam? Allinne hjir yn Nederlân! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fan $99! Lêze oer
Boarne: www.habr.com
