Vi pasigis monatojn restrukturante vian monoliton en mikroservojn, kaj finfine ĉiuj kuniĝis por ŝalti la ŝaltilon. Vi iras al la unua retpaĝo... kaj nenio okazas. Vi reŝargas ĝin - kaj denove nenio bona, la retejo estas tiel malrapida, ke ĝi ne respondas dum kelkaj minutoj. Kio okazis?
En sia prelego, Jimmy Bogard faros "post-mortem" pri realviva mikroservo-katastrofo. Li montros la problemojn pri modelado, disvolviĝo kaj produktado, kiujn li malkovris, kaj kiel lia teamo malrapide transformis la novan distribuitan monoliton en la finan bildon de prudento. Kvankam estas neeble tute malhelpi erarojn de dezajno, vi almenaŭ povas identigi problemojn frue en la procezo de dezajno por certigi, ke la fina produkto fariĝu fidinda distribuita sistemo.
Saluton al ĉiuj, mi estas Jimmy kaj hodiaŭ vi aŭdos kiel vi povas eviti mega-katastrofojn dum konstruado de mikroservoj. Jen la rakonto de firmao, por kiu mi laboris dum proksimume jaro kaj duono por helpi malhelpi ilian ŝipon kolizii kun glacimonto. Por rakonti ĉi tiun historion ĝuste, ni devos reiri en la tempo kaj paroli pri kie ĉi tiu kompanio komencis kaj kiel ĝia IT-infrastrukturo kreskis laŭlonge de la tempo. Por protekti la nomojn de la senkulpaj en ĉi tiu katastrofo, mi ŝanĝis la nomon de ĉi tiu kompanio al Bell Computers. La sekva diapozitivo montras kiel aspektis la IT-infrastrukturo de tiaj kompanioj meze de la 90-aj jaroj. Ĉi tio estas tipa arkitekturo de granda universala mistolerema HP Tandem Mainframe-servilo por funkciigado de komputila aparataro.
Ili devis konstrui sistemon por administri ĉiujn mendojn, vendojn, revenojn, produktkatalogojn kaj klientbazon, do ili elektis la plej oftan komputilan solvon tiutempe. Ĉi tiu giganta sistemo enhavis ĉiun informon pri la kompanio, ĉion eblan, kaj ĉiu transakcio estis farita per ĉi tiu ĉefkomputilo. Ili konservis ĉiujn siajn ovojn en unu korbo kaj opiniis, ke tio estas normala. La sola afero, kiu ne estas inkluzivita ĉi tie, estas poŝtmendkatalogoj kaj mendoj telefone.
Kun la tempo, la sistemo fariĝis pli kaj pli granda, kaj grandega kvanto da rubo akumuliĝis en ĝi. Ankaŭ, COBOL ne estas la plej esprimplena lingvo en la mondo, do la sistemo finis esti granda, monolita peco da fatraso. Antaŭ 2000, ili vidis ke multaj kompanioj havis retejojn per kiuj ili faris absolute sian tutan komercon, kaj decidis konstrui sian unuan komercan punktokoman retejon.
La komenca dezajno aspektis sufiĉe bela kaj konsistis el altnivela retejo bell.com kaj kelkaj subdomajnoj por individuaj aplikoj: catalog.bell.com, accounts.bell.com, orders.bell.com, produktserĉo search.bell. com. Ĉiu subdomajno uzis la kadron ASP.Net 1.0 kaj ĝiajn proprajn datumbazojn, kaj ili ĉiuj parolis kun la sistema backend. Tamen, ĉiuj mendoj daŭre estis procesitaj kaj efektivigitaj ene de ununura grandega ĉefkomputilo, en kiu la tuta rubo restis, sed la fronto estis apartaj retejoj kun individuaj aplikoj kaj apartaj datumbazoj.
Do la dezajno de la sistemo aspektis orda kaj logika, sed la reala sistemo estis kiel montrita en la sekva diapozitivo.
Ĉiuj elementoj adresis alvokojn unu al la alia, aliris APIojn, enigis triajn dll-ojn kaj similajn. Ofte okazis, ke versio-kontrolsistemoj kaptas alies kodon, ŝovas ĝin enen la projekton, kaj tiam ĉio rompiĝus. MS SQL Server 2005 uzis la koncepton de ligaj serviloj, kaj kvankam mi ne montris la sagojn sur la glito, ĉiu el la datumbazoj ankaŭ parolis inter si, ĉar estas nenio malbona konstrui tabelojn bazitajn sur datumoj akiritaj de pluraj datumbazoj.
Ĉar ili nun havis iun apartigon inter malsamaj logikaj areoj de la sistemo, tio iĝis distribuitaj malpuraĵoj, kun la plej granda peco el rubo daŭre restanta en la ĉefkomputila malantaŭo.
La amuza afero estis, ke ĉi tiu ĉefkomputilo estis konstruita de konkurantoj de Bell Computers kaj daŭre estis konservita de iliaj teknikaj konsultistoj. Konvinkita pri la nekontentiga agado de ĝiaj aplikoj, la kompanio decidis forigi ilin kaj restrukturi la sistemon.
La ekzistanta aplikaĵo estis en produktado dum 15 jaroj, kio estas rekordo por ASP.Net-bazitaj aplikoj. La servo akceptis mendojn el la tuta mondo, kaj ĉiujara enspezo de ĉi tiu ununura aplikaĵo atingis miliardon da dolaroj. Grava parto de la profito estis generita de la retejo bell.com. En Nigraj Vendredoj, la nombro da mendoj faritaj tra la retejo atingis plurajn milionojn. Tamen, la ekzistanta arkitekturo ne permesis ajnan evoluon, ĉar la rigidaj interligoj de sistemelementoj praktike ne permesis iujn ajn ŝanĝojn esti faritaj al la servo.
La plej grava problemo estis la nekapablo fari mendon de unu lando, pagi ĝin en alia kaj sendi ĝin al tria, malgraŭ tio, ke tia komerca skemo estas tre ofta en tutmondaj kompanioj. La ekzistanta retejo ne permesis ion tian, do ili devis akcepti kaj fari ĉi tiujn mendojn telefone. Ĉi tio kondukis al la kompanio ĉiam pli pensi pri ŝanĝi la arkitekturon, precipe pri ŝanĝado al mikroservoj.
Ili faris la saĝan aferon rigardante aliajn kompaniojn por vidi kiel ili solvis similan problemon. Unu el ĉi tiuj solvoj estis la Netflix-serva arkitekturo, kiu konsistas el mikroservoj konektitaj per API kaj ekstera datumbazo.
Bell Computers-administrado decidis konstrui ĝuste tian arkitekturon, aliĝante al certaj bazaj principoj. Unue, ili eliminis datenmultobligon uzante komunan datumbazan aliron. Neniuj datumoj estis senditaj; male, ĉiuj, kiuj bezonis ĝin, devis iri al centralizita fonto. Sekvis izoliteco kaj aŭtonomio - ĉiu servo estis sendependa de la aliaj. Ili decidis uzi la TTT-API por absolute ĉio - se vi volis akiri datumojn aŭ fari ŝanĝojn al alia sistemo, ĉio estis farita per la TTT-API. La lasta granda aĵo estis nova komputilego nomita "Bell on Bell" kontraste al la "Bell" komputilego kiu estis bazita sur la aparataro de konkurantoj.
Do, dum 18 monatoj, ili konstruis la sistemon ĉirkaŭ ĉi tiuj kernaj principoj kaj alportis ĝin al antaŭproduktado. Reveninte al laboro post la semajnfino, la programistoj kunvenis kaj ŝaltis ĉiujn servilojn al kiuj la nova sistemo estis konektita. 18 monatoj da laboro, centoj da programistoj, la plej moderna Bell-aparataro - kaj neniu pozitiva rezulto! Ĉi tio seniluziigis multajn homojn ĉar ili multfoje funkciis ĉi tiun sistemon sur siaj tekkomputiloj kaj ĉio estis bone.
Ili estis inteligentaj ĵeti sian tutan monon por solvi ĉi tiun problemon. Ili instalis la plej modernajn servilojn kun ŝaltiloj, uzis gigabitan optikan fibron, la plej potencan servilan aparataron kun freneza kvanto da RAM, konektis ĉion, agordis ĝin - kaj denove nenion! Tiam ili komencis suspekti, ke la kialo povus esti tempoforpasoj, do ili eniris ĉiujn interretajn agordojn, ĉiujn API-agordojn kaj ĝisdatigis la tutan timeout-agordon al la maksimumaj valoroj, tiel ke ĉio, kion ili povis fari, estis sidi kaj atendi, ke io okazos. al la retejo. Ili atendis kaj atendis kaj atendis dum 9 minutoj kaj duono ĝis la retejo finfine ŝargis.
Post tio, ili ekkomprenis, ke la nuna situacio bezonas ĝisfundan analizon, kaj ili invitis nin. La unua afero, kiun ni eksciis, estis, ke dum ĉiuj 18 monatoj de evoluo, eĉ ne unu vera "mikro" estis kreita - ĉio nur pligrandiĝis. Post tio, ni komencis verki postmortan, ankaŭ konatan kiel "retrospektivo", aŭ "malĝoja retrospektivo", ankaŭ konata kiel "kulpa ŝtormo", simila al "cerboŝtormo", por kompreni la kaŭzon de la katastrofo.
Ni havis plurajn indicojn, unu el kiuj estis kompleta trafika saturiĝo en la momento de la API-voko. Kiam vi uzas monolitan servan arkitekturon, vi povas tuj kompreni, kio ĝuste misfunkciis, ĉar vi havas ununuran stakspuron, kiu raportas ĉion, kio povus kaŭzi la fiaskon. En la kazo, kie amaso da servoj samtempe aliras la saman API, estas neniu maniero spuri la spuron krom uzi pliajn retajn monitorajn ilojn kiel WireShark, dank'al kiu vi povas ekzameni ununuran peton kaj ekscii, kio okazis dum ĝia efektivigo. Do ni prenis unu retpaĝon kaj pasigis preskaŭ 2 semajnojn kunigante la pecojn de la enigmo, farante diversajn vokojn al ĝi kaj analizante, al kio ĉiu el ili kondukis.
Rigardu ĉi tiun bildon. Ĝi montras, ke unu ekstera peto instigas la servon fari multajn internajn vokojn, kiuj revenas. Montriĝas, ke ĉiu interna alvoko faras pliajn saltojn por povi memstare servi ĉi tiun peton, ĉar ĝi ne povas turni aliloke por akiri la necesajn informojn. Ĉi tiu bildo aspektas kiel sensignifa kaskado de vokoj, ĉar la ekstera peto vokas aldonajn servojn, kiuj vokas aliajn kromajn servojn, ktp, preskaŭ ĝis infinito.
La verda koloro en ĉi tiu diagramo montras duoncirklon en kiu servoj vokas unu la alian - servo A nomas servon B, servo B vokas servon C, kaj ĝi vokas servon A. Kiel rezulto, ni ricevas "distribuitan blokiĝon". Ununura peto kreis mil retajn API-vokojn, kaj ĉar la sistemo ne havis enkonstruitan faŭltoleremon kaj bukloprotekton, la peto malsukcesus se eĉ unu el ĉi tiuj API-vokoj malsukcesus.
Ni faris iom da matematiko. Ĉiu API-voko havis SLA de ne pli ol 150 ms kaj 99,9% da tempo. Unu peto kaŭzis 200 malsamajn vokojn, kaj en la plej bona kazo, la paĝo povus esti montrita en 200 x 150 ms = 30 sekundoj. Kompreneble, ĉi tio ne estis bona. Multiplikante 99,9% da funkciado per 200, ni ricevis 0% haveblecon. Montriĝas, ke ĉi tiu arkitekturo estis kondamnita al fiasko de la komenco mem.
Ni demandis la programistojn, kiel ili malsukcesis rekoni ĉi tiun problemon post 18 monatoj da laboro? Montriĝis, ke ili nur kalkulis la SLA por la kodo, kiun ili kuris, sed se ilia servo vokis alian servon, ili ne kalkulis tiun tempon en sia SLA. Ĉio, kio estis lanĉita ene de unu procezo, aliĝis al la valoro de 150 ms, sed aliro al aliaj servaj procezoj multfoje pliigis la totalan prokraston. La unua leciono lernita estis: "Ĉu vi regas vian SLA, aŭ ĉu la SLA regas vin?" En nia kazo, ĝi estis la lasta.
La sekva afero, kiun ni malkovris, estis, ke ili sciis pri la koncepto de distribuitaj komputikaj miskomprenoj, formulita de Peter Deitch kaj James Gosling, sed ili ignoris la unuan parton de ĝi. Ĝi deklaras ke la deklaroj "la reto estas fidinda", "nula latencia" kaj "senfina trairo" estas miskompreniĝoj. Aliaj miskompreniĝoj inkluzivas la deklarojn "la reto estas sekura", "la topologio neniam ŝanĝiĝas", "ĉiam estas nur unu administranto", "la kosto de transdono de datumoj estas nula" kaj "la reto estas homogena".
Ili faris eraron ĉar ili testis sian servon sur lokaj maŝinoj kaj neniam konektis kun eksteraj servoj. Dum evoluado loke kaj uzante lokan kaŝmemoron, ili neniam renkontis retajn saltojn. En ĉiuj 18 monatoj da evoluo, ili neniam scivolis, kio povus okazi se eksteraj servoj estus tuŝitaj.
Se vi rigardas la servolimojn en la antaŭa bildo, vi povas vidi, ke ili ĉiuj estas malĝustaj. Estas multaj fontoj, kiuj konsilas pri kiel difini servajn limojn, kaj plej multaj faras tion malĝuste, kiel Mikrosofto en la sekva diapozitivo.
Ĉi tiu bildo estas de la MS-blogo pri la temo "Kiel konstrui mikroservojn". Ĉi tio montras simplan TTT-aplikaĵon, blokon de komerca logiko kaj datumbazon. La peto venas rekte, verŝajne ekzistas unu servilo por la reto, unu servilo por la komerco kaj unu por la datumbazo. Se vi pliigas trafikon, la bildo iom ŝanĝiĝos.
Jen venas ŝarĝobalancilo por distribui trafikon inter du retserviloj, kaŝmemoro situanta inter la retservo kaj la komerca logiko, kaj alia kaŝmemoro inter la komerca logiko kaj la datumbazo. Ĉi tio estas ĝuste la arkitekturo kiun Bell uzis por sia ŝarĝbalancado kaj blua/verda deploja aplikaĵo meze de la 2000-aj jaroj. Ĝis iom da tempo ĉio funkciis bone, ĉar ĉi tiu skemo estis destinita al monolita strukturo.
La sekva bildo montras kiel MS rekomendas transiri de monolito al mikroservoj - simple disigu ĉiun el la ĉefaj servoj en apartajn mikroservojn. Estis dum la efektivigo de tiu skemo ke Bell faris eraron.
Ili dividis ĉiujn siajn servojn en malsamajn partojn, ĉiu el kiuj konsistis el multaj individuaj servoj. Ekzemple, la retservo inkludis mikroservojn por enhava bildigo kaj aŭtentigo, la komerca logika servo konsistis el mikroservoj por prilaborado de mendoj kaj kontinformoj, la datumbazo estis dividita en amason da mikroservoj kun specialigitaj datumoj. Kaj la reto, komerca logiko kaj datumbazo estis sennaciaj servoj.
Tamen, ĉi tiu bildo estis tute malĝusta ĉar ĝi ne mapis iujn ajn komercajn unuojn ekster la IT-grupo de la kompanio. Ĉi tiu skemo ne enkalkulis ajnan rilaton kun la ekstera mondo, do ne estis klare kiel ekzemple akiri triapartan komercan analizon. Mi rimarkas, ke ili ankaŭ havis plurajn servojn inventitajn simple por disvolvi la karierojn de individuaj dungitoj, kiuj klopodis administri kiel eble plej multajn homojn por akiri pli da mono por ĝi.
Ili kredis, ke moviĝi al mikroservoj estis tiel facila kiel preni sian internan N-nivelan fizikan tavolinfrastrukturon kaj alglui Docker sur ĝi. Ni rigardu kiel aspektas tradicia N-tavola arkitekturo.
Ĝi konsistas el 4 niveloj: la nivelo de uzantinterfaco de UI, la komerca logika nivelo, la nivelo de aliro al datumoj kaj la datumbazo. Pli progresema estas DDD (Domain-Driven Design), aŭ softvar-orientita arkitekturo, kie la du mezaj niveloj estas domajnaj objektoj kaj deponejo.
Mi provis rigardi malsamajn areojn de ŝanĝo, malsamajn areojn de respondeco en ĉi tiu arkitekturo. En tipa N-tavola apliko, malsamaj areoj de ŝanĝo estas klasifikitaj kiuj trapenetras la strukturon vertikale de supre ĝis malsupre. Ĉi tiuj estas Katalogo, Agordaj agordoj faritaj sur individuaj komputiloj, kaj Checkout-kontroloj, kiuj estis pritraktitaj de mia teamo.
La propreco de ĉi tiu skemo estas, ke la limoj de ĉi tiuj areoj de ŝanĝo influas ne nur la komercan logiknivelon, sed ankaŭ etendiĝas al la datumbazo.
Ni rigardu, kion signifas esti servo. Estas 6 karakterizaj propraĵoj de servodifino - ĝi estas programaro kiu:
- kreita kaj uzata de specifa organizo;
- respondecas pri la enhavo, prilaborado kaj/aŭ provizo de certa speco de informoj ene de la sistemo;
- povas esti konstruita, deplojita kaj funkcii sendepende por renkonti specifajn funkciajn bezonojn;
- komunikas kun konsumantoj kaj aliaj servoj, provizante informojn bazitajn sur interkonsentoj aŭ kontraktaj garantioj;
- protektas sin kontraŭ neaŭtorizita aliro, kaj ĝiajn informojn kontraŭ perdo;
- pritraktas misfunkciadojn tiel, ke ili ne kondukas al informadifekto.
Ĉiuj ĉi tiuj propraĵoj povas esti esprimitaj per unu vorto "aŭtonomio". Servoj funkcias sendepende unu de la alia, kontentigas certajn limigojn kaj difinas kontraktojn surbaze de kiuj homoj povas ricevi la informojn, kiujn ili bezonas. Mi ne menciis specifajn teknologiojn, kies uzo estas memkomprenebla.
Nun ni rigardu la difinon de mikroservoj:
- mikroservo estas malgranda en grandeco kaj dizajnita por solvi unu specifan problemon;
- La mikroservo estas aŭtonoma;
- Dum kreado de mikroserva arkitekturo, la urboplanada metaforo estas uzata. Ĉi tiu estas la difino de la libro de Sam Newman, Building Microservices.
La difino de Bounded Context estas prenita de la libro Domain-Driven Design de Eric Evans. Ĉi tio estas kernpadrono en DDD, arkitektura dezajnocentro kiu funkcias kun volumetraj arkitekturaj modeloj, dividante ilin en malsamajn Limigitajn Kuntekstojn kaj eksplicite difinante la interagojn inter ili.
Simple dirite, Bounded Kunteksto indikas la amplekson en kiu speciala modulo povas esti uzita. Ene de ĉi tiu kunteksto estas logike unuigita modelo kiu povas esti vidita, ekzemple, en via komerca domajno. Se vi demandas "kiu estas kliento" al la dungitaro implikita en mendoj, vi ricevos unu difinon, se vi demandas tiujn, kiuj okupiĝas pri vendoj, vi ricevos alian, kaj la prezentistoj donos al vi trian difinon.
Do, Bounded Context diras, ke se ni ne povas doni klaran difinon pri tio, kio estas konsumanto de niaj servoj, ni difinu la limojn ene de kiuj ni povas paroli pri la signifo de ĉi tiu termino, kaj poste difinu la transirajn punktojn inter ĉi tiuj malsamaj difinoj. Tio estas, se ni parolas pri kliento el la vidpunkto de mendoj, tio signifas ĉi kaj tio, kaj se el la vidpunkto de vendo, tio signifas ĉi kaj tio.
La sekva difino de mikroservo estas la enkapsuligo de ajna speco de internaj operacioj, malhelpante la "elfluon" de la komponantoj de la laborprocezo en la medion. Poste venas la "difino de eksplicitaj kontraktoj por eksteraj interagoj, aŭ eksteraj komunikadoj", kiu estas reprezentita per la ideo de kontraktoj revenantaj de SLAoj. La lasta difino estas la metaforo de ĉelo, aŭ ĉelo, kio signifas la kompletan enkapsuligon de aro de operacioj ene de mikroservo kaj la ĉeesto en ĝi de riceviloj por komunikado kun la ekstera mondo.
Do ni diris al la uloj ĉe Bell Computers, "Ni ne povas ripari iun ajn el la kaoso, kiun vi kreis, ĉar vi simple ne havas la monon por fari ĝin, sed ni riparos nur unu servon por ke ĉio fariĝu. senco.” Je ĉi tiu punkto, mi komencos rakontante al vi kiel ni riparis nian solan servon por ke ĝi respondu al petoj pli rapide ol 9 minutoj kaj duono.
22:30 min
Daŭrigota tre baldaŭ...
Iom da reklamado
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com