Več mesecev ste porabili za preoblikovanje svojega monolita v mikrostoritve in končno so se vsi zbrali, da bi preklopili stikalo. Greš na prvo spletno stran ... in nič se ne zgodi. Ponovno naložiš - in spet nič dobrega, stran je tako počasna, da se ne odziva več minut. Kaj se je zgodilo?
V svojem govoru bo Jimmy Bogard izvedel "post mortem" katastrofo mikrostoritve v resničnem življenju. Pokazal bo težave pri modeliranju, razvoju in proizvodnji, ki jih je odkril, in kako je njegova ekipa počasi preoblikovala nov porazdeljeni monolit v končno sliko razuma. Čeprav je nemogoče popolnoma preprečiti načrtovalske napake, lahko vsaj prepoznate težave zgodaj v procesu načrtovanja, da zagotovite, da končni izdelek postane zanesljiv porazdeljen sistem.
Pozdravljeni vsi, jaz sem Jimmy in danes boste slišali, kako se lahko izognete mega katastrofam pri gradnji mikrostoritev. To je zgodba o podjetju, v katerem sem delal približno leto in pol, da bi pomagal preprečiti trčenje njihove ladje z ledeno goro. Da bi to zgodbo pravilno povedali, se bomo morali vrniti v preteklost in govoriti o tem, kje se je to podjetje začelo in kako je njegova IT infrastruktura sčasoma rasla. Da bi zaščitili imena nedolžnih v tej katastrofi, sem spremenil ime tega podjetja v Bell Computers. Naslednji diapozitiv prikazuje, kako je izgledala IT infrastruktura takih podjetij sredi 90. let. To je tipična arhitektura velikega univerzalnega strežnika HP Tandem Mainframe, odpornega na napake, za upravljanje trgovine z računalniško strojno opremo.
Morali so zgraditi sistem za upravljanje vseh naročil, prodaje, vračil, katalogov izdelkov in baze strank, zato so izbrali takrat najpogostejšo rešitev velikega računalnika. Ta velikanski sistem je vseboval vse informacije o podjetju, vse mogoče, in vsaka transakcija je bila izvedena prek tega glavnega računalnika. Vsa jajca so imeli v eni košari in mislili so, da je to normalno. Edina stvar, ki tukaj ni vključena, so katalogi po pošti in naročanje po telefonu.
Sčasoma je sistem postajal vse večji in v njem se je nabralo ogromno smeti. Poleg tega COBOL ni najbolj izrazit jezik na svetu, zato je sistem na koncu postal velik, monoliten kos smeti. Do leta 2000 so videli, da ima veliko podjetij spletna mesta, prek katerih so opravljali vse svoje posle, in se odločili zgraditi svojo prvo komercialno dot-com spletno stran.
Začetna zasnova je bila videti precej lepa in je bila sestavljena iz spletnega mesta bell.com na najvišji ravni in številnih poddomen za posamezne aplikacije: catalog.bell.com, accounts.bell.com, orders.bell.com, iskanje izdelkov search.bell. com. Vsaka poddomena je uporabljala ogrodje ASP.Net 1.0 in lastne baze podatkov, vse pa so se pogovarjale z zaledjem sistema. Vendar pa so se vsa naročila še naprej obdelovala in izvajala v enem samem ogromnem glavnem računalniku, v katerem je ostala vsa smeti, vendar so bila sprednja stran ločene spletne strani s posameznimi aplikacijami in ločenimi bazami podatkov.
Tako je bila zasnova sistema videti urejena in logična, dejanski sistem pa je bil tak, kot je prikazan na naslednjem diapozitivu.
Vsi elementi so naslavljali klice drug na drugega, dostopali do API-jev, vdelanih dll-jev tretjih oseb in podobno. Pogosto se je zgodilo, da so sistemi za nadzor različic zgrabili kodo nekoga drugega, jo potisnili v projekt in potem se je vse pokvarilo. MS SQL Server 2005 je uporabil koncept povezovalnih strežnikov in čeprav nisem pokazal puščic na prosojnici, se je vsaka od zbirk podatkov med seboj tudi pogovarjala, saj ni nič narobe, če tabele gradimo na podlagi podatkov, pridobljenih iz več zbirk podatkov.
Ker so zdaj imeli nekaj ločitve med različnimi logičnimi področji sistema, so to postale porazdeljene kepe umazanije, pri čemer je največji kos smeti še vedno ostal v ozadju glavnega računalnika.
Smešno je bilo to, da so ta glavni računalnik izdelali konkurenti podjetja Bell Computers in so ga še vedno vzdrževali njihovi tehnični svetovalci. Prepričani o nezadovoljivem delovanju svojih aplikacij, so se v podjetju odločili, da se jih znebijo in preoblikujejo sistem.
Obstoječa aplikacija je bila v izdelavi 15 let, kar je rekord za aplikacije, ki temeljijo na ASP.Net. Storitev je sprejemala naročila z vsega sveta, letni prihodek od te ene aplikacije pa je dosegel milijardo dolarjev. Precejšen del dobička je ustvarilo spletno mesto bell.com. Ob črnih petkih je število naročil, oddanih prek spletnega mesta, doseglo več milijonov. Obstoječa arhitektura pa ni dopuščala razvoja, saj toge medsebojne povezave sistemskih elementov praktično niso dopuščale sprememb storitve.
Največja težava je bila nezmožnost oddaje naročila iz ene države, plačila v drugi in pošiljanja v tretjo, kljub temu, da je takšna shema trgovanja zelo pogosta v globalnih podjetjih. Obstoječa spletna stran česa takega ni omogočala, zato so morali ta naročila sprejemati in oddajati po telefonu. To je pripeljalo do tega, da so v podjetju vedno bolj razmišljali o spremembi arhitekture, predvsem o prehodu na mikrostoritve.
Naredili so pametno, ko so pogledali druga podjetja, da bi videli, kako so rešila podoben problem. Ena od teh rešitev je bila storitvena arhitektura Netflix, ki je sestavljena iz mikrostoritev, povezanih preko API-ja, in zunanje baze podatkov.
Vodstvo Bell Computers se je odločilo zgraditi prav takšno arhitekturo, pri čemer se je držala določenih osnovnih načel. Najprej so odpravili podvajanje podatkov z uporabo pristopa skupne baze podatkov. Podatki niso bili poslani, nasprotno, vsi, ki so jih potrebovali, so se morali obrniti na centraliziran vir. Sledila je izolacija in avtonomija – vsaka služba je bila neodvisna od drugih. Odločili so se, da bodo uporabili spletni API za popolnoma vse – če ste želeli pridobiti podatke ali narediti spremembe v drugem sistemu, je bilo vse narejeno prek spletnega API-ja. Zadnja velika stvar je bil nov glavni računalnik, imenovan "Bell on Bell", v nasprotju z glavnim računalnikom "Bell", ki temelji na strojni opremi konkurentov.
Tako so v 18 mesecih zgradili sistem okoli teh temeljnih načel in ga pripeljali do predprodukcije. Ko so se po koncu tedna vrnili na delo, so se razvijalci zbrali in vklopili vse strežnike, na katere je bil povezan nov sistem. 18 mesecev dela, na stotine razvijalcev, najsodobnejša strojna oprema Bell - in nobenega pozitivnega rezultata! To je razočaralo veliko ljudi, ker so ta sistem večkrat poganjali na svojih prenosnikih in je bilo vse v redu.
Bili so pametni, da so vrgli ves svoj denar v rešitev tega problema. Namestili so najmodernejše strežniške regale s stikali, uporabili gigabitna optična vlakna, najzmogljivejšo strežniško strojno opremo z noro količino RAM-a, vse to povezali, konfigurirali – in spet nič! Potem so začeli sumiti, da so razlog morda časovne omejitve, zato so šli v vse spletne nastavitve, vse nastavitve API-ja in posodobili celotno konfiguracijo časovne omejitve na največje vrednosti, tako da so lahko le sedeli in čakali, da se kaj zgodi. na spletno mesto. Čakali so in čakali in čakali 9 minut in pol, dokler se spletna stran končno ni naložila.
Po tem se jim je posvetilo, da je treba trenutno situacijo temeljito analizirati, in so nas povabili. Prva stvar, ki smo jo ugotovili, je bila, da v vseh 18 mesecih razvoja ni bil ustvarjen niti en pravi "mikro" - vse je postalo samo večje. Po tem smo začeli pisati obdukcijo, znano tudi kot »retrospektiva« ali »žalostna retrospektiva«, znana tudi kot »nevihta krivde«, podobna »možganski nevihti«, da bi razumeli vzrok katastrofe.
Imeli smo več namigov, eden od njih je bila popolna zasičenost prometa v času klica API. Ko uporabljate monolitno storitveno arhitekturo, lahko takoj razumete, kaj točno je šlo narobe, ker imate eno samo sled sklada, ki poroča o vsem, kar bi lahko povzročilo napako. V primeru, ko več storitev istočasno dostopa do istega API-ja, ni možnosti za sledenje sledi, razen z uporabo dodatnih orodij za nadzor omrežja, kot je WireShark, zahvaljujoč kateremu lahko pregledate posamezno zahtevo in ugotovite, kaj se je zgodilo med njeno izvedbo. Tako smo vzeli eno spletno stran in porabili skoraj 2 tedna, da smo sestavljali koščke sestavljanke, jo izvajali na različne klice in analizirali, do česa je vsak izmed njih pripeljal.
Poglej to sliko. Prikazuje, da ena zunanja zahteva pozove storitev, da izvede veliko notranjih klicev, ki se vrnejo. Izkazalo se je, da vsak interni klic naredi dodatne skoke, da bi lahko samostojno servisiral to zahtevo, saj se ne more obrniti nikamor drugam, da bi dobil potrebne informacije. Ta slika je videti kot nesmiselna kaskada klicev, saj zunanja zahteva kliče dodatne storitve, te kličejo druge dodatne storitve in tako naprej, skoraj ad infinitum.
Zelena barva v tem diagramu prikazuje polkrog, v katerem storitve kličejo druga drugo - storitev A kliče storitev B, storitev B kliče storitev C in spet kliče storitev A. Posledično dobimo "razdeljeno zastoj". Ena sama zahteva je ustvarila tisoč klicev omrežnega API-ja in ker sistem ni imel vgrajene tolerance napak in zaščite pred zankami, bi zahteva propadla, če bi vsaj eden od teh klicev API-ja spodletel.
Nekaj smo računali. Vsak klic API-ja je imel SLA največ 150 ms in 99,9-odstotni čas delovanja. Ena zahteva je povzročila 200 različnih klicev, v najboljšem primeru pa je bila stran prikazana v 200 x 150 ms = 30 sekund. Seveda to ni bilo dobro. Če pomnožimo 99,9 % čas delovanja z 200, dobimo 0 % razpoložljivosti. Izkazalo se je, da je bila ta arhitektura že od samega začetka obsojena na propad.
Razvijalce smo vprašali, kako jim po 18 mesecih dela ni uspelo prepoznati te težave? Izkazalo se je, da so šteli samo SLA za kodo, ki so jo izvajali, če pa je njihova storitev poklicala drugo storitev, tega časa niso šteli v svoji SLA. Vse, kar je bilo zagnano znotraj enega procesa, se je držalo vrednosti 150 ms, dostop do drugih servisnih procesov pa je skupni zamik večkrat povečal. Prva naučena lekcija je bila: "Ali vi obvladujete svojo pogodbo o ravni storitev ali pogodba o ravni storitev nadzoruje vas?" V našem primeru je šlo za slednje.
Naslednja stvar, ki smo jo odkrili, je bila, da so vedeli za koncept porazdeljenih računalniških napačnih predstav, ki sta ga oblikovala Peter Deitch in James Gosling, vendar so prezrli njegov prvi del. Navaja, da so izjave "omrežje zanesljivo", "ničelna zakasnitev" in "neskončna prepustnost" napačne predstave. Druge napačne predstave vključujejo izjave »omrežje je varno«, »topologija se nikoli ne spremeni«, »vedno je samo en skrbnik«, »strošek prenosa podatkov je nič« in »omrežje je homogeno«.
Naredili so napako, ker so svojo storitev preizkusili na lokalnih strojih in se nikoli niso povezali z zunanjimi storitvami. Pri lokalnem razvoju in uporabi lokalnega predpomnilnika niso nikoli naleteli na omrežne skoke. V vseh 18 mesecih razvoja se niso niti enkrat vprašali, kaj bi se lahko zgodilo, če bi bile prizadete zunanje storitve.
Če pogledate meje storitve na prejšnji sliki, lahko vidite, da so vse nepravilne. Obstaja veliko virov, ki svetujejo, kako določiti meje storitev, in večina jih naredi napačno, kot je Microsoft na naslednjem diapozitivu.
Ta slika je iz bloga MS na temo "Kako zgraditi mikrostoritve". To prikazuje preprosto spletno aplikacijo, blok poslovne logike in bazo podatkov. Zahteva pride neposredno, verjetno obstaja en strežnik za splet, en strežnik za podjetje in eden za bazo podatkov. Če povečate promet, se bo slika nekoliko spremenila.
Prihaja izravnalnik obremenitve za porazdelitev prometa med dvema spletnima strežnikoma, predpomnilnik med spletno storitvijo in poslovno logiko ter drug predpomnilnik med poslovno logiko in bazo podatkov. To je točno arhitektura, ki jo je Bell uporabil za svojo aplikacijo za uravnoteženje obremenitve in modro/zeleno uvajanje sredi 2000-ih. Do nekaj časa je vse dobro delovalo, saj je bila ta shema namenjena monolitni strukturi.
Naslednja slika prikazuje, kako MS priporoča prehod z monolita na mikrostoritve – preprosto razdelitev vsake glavne storitve na ločene mikrostoritve. Med izvajanjem te sheme je Bell naredil napako.
Vse svoje storitve so razdelili na različne ravni, od katerih je vsaka sestavljena iz številnih posameznih storitev. Spletna storitev je na primer vključevala mikrostoritve za prikazovanje vsebine in avtentikacijo, storitev poslovne logike je bila sestavljena iz mikrostoritev za obdelavo naročil in informacij o računih, baza podatkov je bila razdeljena na kup mikrostoritev s specializiranimi podatki. Tako splet, poslovna logika kot baza podatkov so bile storitve brez stanja.
Vendar je bila ta slika popolnoma napačna, ker ni preslikala nobene poslovne enote zunaj IT grozda podjetja. Ta shema ni upoštevala nobene povezave z zunanjim svetom, zato ni bilo jasno, kako na primer pridobiti poslovno analitiko tretjih oseb. Opažam, da so si izmislili tudi več storitev zgolj za razvoj karier posameznih zaposlenih, ki so želeli upravljati čim več ljudi, da bi za to dobili več denarja.
Verjeli so, da je premik na mikrostoritve tako enostaven kot vzeti svojo notranjo infrastrukturo fizičnega sloja N in nanjo namestiti Docker. Oglejmo si, kako izgleda tradicionalna N-nivojska arhitektura.
Sestavljen je iz 4 ravni: ravni uporabniškega vmesnika, ravni poslovne logike, ravni dostopa do podatkov in baze podatkov. Bolj progresivna je DDD (Domain-Driven Design) ali programsko usmerjena arhitektura, kjer sta dve srednji ravni domenski objekti in repozitorij.
Poskušal sem pogledati različna področja sprememb, različna področja odgovornosti v tej arhitekturi. V tipični N-nivojski aplikaciji so razvrščena različna področja sprememb, ki prežemajo strukturo navpično od zgoraj navzdol. To so katalog, konfiguracijske nastavitve, izvedene na posameznih računalnikih, in preverjanja blagajne, ki jih je opravila moja ekipa.
Posebnost te sheme je, da meje teh območij sprememb ne vplivajo le na raven poslovne logike, ampak segajo tudi do baze podatkov.
Poglejmo, kaj pomeni biti storitev. Obstaja 6 značilnih lastnosti definicije storitve - to je programska oprema, ki:
- ustvarila in uporablja določena organizacija;
- je odgovoren za vsebino, obdelavo in/ali posredovanje določene vrste informacij znotraj sistema;
- mogoče zgraditi, namestiti in izvajati neodvisno za izpolnjevanje posebnih operativnih potreb;
- komunicira s potrošniki in drugimi storitvami, zagotavlja informacije na podlagi dogovorov ali pogodbenih garancij;
- ščiti sebe pred nepooblaščenim dostopom in svoje podatke pred izgubo;
- obravnava napake tako, da ne povzročajo informacijske škode.
Vse te lastnosti lahko izrazimo z eno besedo "avtonomija". Storitve delujejo neodvisno druga od druge, zadoščajo določenim omejitvam in določajo pogodbe, na podlagi katerih lahko ljudje prejmejo informacije, ki jih potrebujejo. Nisem omenil posebnih tehnologij, katerih uporaba je samoumevna.
Zdaj pa poglejmo definicijo mikrostoritev:
- mikrostoritev je majhna in zasnovana za reševanje določenega problema;
- Mikrostoritev je avtonomna;
- Pri ustvarjanju arhitekture mikrostoritve se uporablja metafora urbanističnega načrtovanja. To je definicija iz knjige Sama Newmana, Building Microservices.
Opredelitev omejenega konteksta je vzeta iz knjige Erica Evansa Domain-Driven Design. To je osrednji vzorec v DDD, centru za arhitekturno oblikovanje, ki dela z volumetričnimi arhitekturnimi modeli, ki jih deli v različne omejene kontekste in eksplicitno definira interakcije med njimi.
Preprosto povedano, omejeni kontekst označuje obseg, v katerem se lahko uporablja določen modul. Znotraj tega konteksta je logično enoten model, ki ga je mogoče videti na primer v vaši poslovni domeni. Če osebje, ki se ukvarja z naročili, vprašate »kdo je naročnik«, boste dobili eno definicijo, če vprašate tiste, ki se ukvarjajo s prodajo, boste dobili drugo, izvajalci pa vam bodo podali tretjo definicijo.
Torej, Bounded Context pravi, da če ne moremo dati jasne definicije, kaj je potrošnik naših storitev, določimo meje, znotraj katerih lahko govorimo o pomenu tega izraza, in nato določimo prehodne točke med temi različnimi definicijami. Se pravi, če govorimo o naročniku z vidika oddaje naročil, to pomeni to in to, če pa z vidika prodaje, to pomeni to in to.
Naslednja definicija mikrostoritve je enkapsulacija kakršnih koli notranjih operacij, ki preprečuje "uhajanje" komponent delovnega procesa v okolje. Sledi "opredelitev eksplicitnih pogodb za zunanje interakcije ali zunanje komunikacije", ki jih predstavlja zamisel o pogodbah, ki se vračajo iz SLA. Zadnja definicija je metafora celice ali celice, ki pomeni popolno inkapsulacijo nabora operacij znotraj mikrostoritve in prisotnost v njej receptorjev za komunikacijo z zunanjim svetom.
Zato smo fantom pri Bell Computers rekli: »Ne moremo popraviti nobenega kaosa, ki ste ga ustvarili, ker enostavno nimate denarja za to, vendar bomo popravili samo eno storitev, da bo vse smisel.” Na tej točki vam bom začel s tem, da vam povem, kako smo našo edino storitev popravili tako, da se je na zahteve odzivala hitreje kot v 9 minutah in pol.
22:30 min
Nadaljevanje kmalu ...
Malo reklame
Hvala, ker ste ostali z nami. So vam všeč naši članki? Želite videti več zanimivih vsebin? Podprite nas tako, da oddate naročilo ali priporočite prijateljem, , edinstven analog začetnih strežnikov, ki smo ga izumili za vas: (na voljo z RAID1 in RAID10, do 24 jeder in do 40 GB DDR4).
Dell R730xd dvakrat cenejši v podatkovnem centru Equinix Tier IV v Amsterdamu? Samo tukaj na Nizozemskem! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 $! Preberite o
Vir: www.habr.com