Strávili jste měsíce předěláním svého monolitu na mikroslužby a nakonec se všichni sešli, aby přepnuli přepínač. Přejdete na první webovou stránku... a nic se nestane. Znovu načtete - a opět nic dobrého, stránka je tak pomalá, že několik minut nereaguje. Co se stalo?
Jimmy Bogard ve své přednášce provede „post-mortem“ katastrofu mikroslužeb v reálném životě. Ukáže problémy s modelováním, vývojem a výrobou, které objevil, a jak jeho tým pomalu transformoval nový distribuovaný monolit do konečného obrazu zdravého rozumu. I když je nemožné zcela zabránit chybám v návrhu, můžete alespoň identifikovat problémy v rané fázi procesu návrhu, abyste zajistili, že se konečný produkt stane spolehlivým distribuovaným systémem.
Ahoj všichni, jsem Jimmy a dnes uslyšíte, jak se můžete vyhnout mega katastrofám při budování mikroslužeb. Toto je příběh společnosti, pro kterou jsem pracoval asi rok a půl, abych pomohl zabránit srážce jejich lodi s ledovcem. Abychom mohli správně vyprávět tento příběh, budeme se muset vrátit v čase a promluvit si o tom, kde tato společnost začala a jak se její IT infrastruktura postupem času rozrostla. Abych ochránil jména těch nevinných v této katastrofě, změnil jsem název této společnosti na Bell Computers. Další snímek ukazuje, jak vypadala IT infrastruktura takových společností v polovině 90. let. Toto je typická architektura velkého univerzálního serveru HP Tandem Mainframe odolného proti chybám pro provozování úložiště počítačového hardwaru.
Potřebovali vybudovat systém pro správu všech objednávek, prodejů, vracení zboží, katalogů produktů a zákaznické základny, a tak zvolili v té době nejběžnější řešení pro sálové počítače. Tento obří systém obsahoval všechny informace o společnosti, všechno možné a každá transakce byla prováděna prostřednictvím tohoto sálového počítače. Drželi všechna vejce v jednom košíku a mysleli si, že je to normální. Jediné, co zde není zahrnuto, jsou zásilkové katalogy a telefonické objednávky.
Postupem času se systém zvětšoval a zvětšoval a hromadilo se v něm obrovské množství odpadků. COBOL také není nejvýraznějším jazykem na světě, takže systém skončil jako velký, monolitický kus haraburdí. V roce 2000 viděli, že mnoho společností má webové stránky, přes které provádějí absolutně veškeré své podnikání, a rozhodli se vybudovat svůj první komerční web dot-com.
Původní design vypadal docela pěkně a sestával z top-level webu bell.com a řady subdomén pro jednotlivé aplikace: Catalog.bell.com, accounts.bell.com, orders.bell.com, product search search.bell. com. Každá subdoména používala rámec ASP.Net 1.0 a své vlastní databáze a všechny mluvily s backendem systému. Všechny objednávky se však i nadále zpracovávaly a vyřizovaly v rámci jediného obrovského sálového počítače, ve kterém zůstával veškerý odpad, ale frontendem byly samostatné weby s jednotlivými aplikacemi a oddělenými databázemi.
Takže návrh systému vypadal uspořádaně a logicky, ale skutečný systém byl takový, jak je znázorněno na dalším snímku.
Všechny prvky si navzájem adresovaly volání, přistupovaly k API, vestavěným knihovnám dll třetích stran a podobně. Často se stávalo, že systémy pro správu verzí chytily cizí kód, strčily ho dovnitř projektu a pak se všechno rozbilo. MS SQL Server 2005 využíval koncept linkových serverů, a přestože jsem na snímku neukázal šipky, každá z databází spolu také mluvila, protože na sestavování tabulek na základě dat získaných z několika databází není nic špatného.
Vzhledem k tomu, že nyní měli určité oddělení mezi různými logickými oblastmi systému, staly se z toho rozmístěné hlíny, přičemž největší kus smetí stále zůstával v backendu sálového počítače.
Legrační bylo, že tento sálový počítač postavili konkurenti Bell Computers a stále ho udržovali jejich techničtí poradci. Společnost byla přesvědčena o neuspokojivém výkonu svých aplikací a rozhodla se jich zbavit a systém přepracovat.
Stávající aplikace byla ve výrobě 15 let, což je rekord pro aplikace založené na ASP.Net. Služba přijímala objednávky z celého světa a roční výnosy z této jediné aplikace dosáhly miliardy dolarů. Významnou část zisku generoval web bell.com. O Black Fridays dosáhl počet objednávek zadaných prostřednictvím stránky několika milionů. Stávající architektura však neumožňovala žádný rozvoj, neboť tuhé propojení systémových prvků prakticky neumožňovalo provádět na službě žádné změny.
Nejzávažnějším problémem byla nemožnost zadat objednávku z jedné země, zaplatit za ni v druhé a odeslat do třetí, a to přesto, že takové obchodní schéma je u světových společností velmi běžné. Stávající web nic takového neumožňoval, a tak museli tyto objednávky přijímat a zadávat po telefonu. To vedlo k tomu, že společnost stále více přemýšlela o změně architektury, zejména o přechodu na mikroslužby.
Udělali chytrou věc, když se podívali na jiné společnosti, aby zjistili, jak vyřešili podobný problém. Jedním z těchto řešení byla architektura služeb Netflix, která se skládá z mikroslužeb propojených pomocí API a externí databáze.
Vedení společnosti Bell Computers se rozhodlo postavit právě takovou architekturu, dodržující určité základní principy. Za prvé, eliminovali duplicitu dat pomocí přístupu sdílené databáze. Žádná data se neposílala, naopak každý, kdo je potřeboval, musel k centralizovanému zdroji. Následovala izolace a autonomie – každá služba byla nezávislá na ostatních. Rozhodli se použít Web API úplně na všechno – pokud jste chtěli získat data nebo provést změny v jiném systému, vše se dělo přes Web API. Poslední velkou věcí byl nový sálový počítač s názvem „Bell on Bell“ na rozdíl od sálového počítače „Bell“ založeného na hardwaru konkurentů.
Během 18 měsíců tedy postavili systém na těchto základních principech a uvedli jej do předprodukce. Po víkendu se vývojáři vrátili do práce a sešli se a zapnuli všechny servery, ke kterým byl nový systém připojen. 18 měsíců práce, stovky vývojářů, nejmodernější hardware Bell – a žádný pozitivní výsledek! To mnoho lidí zklamalo, protože tento systém na svých noteboocích provozovali mnohokrát a vše bylo v pořádku.
Byli chytří vyhodit všechny své peníze na vyřešení tohoto problému. Nainstalovali nejmodernější serverové racky s přepínači, použili gigabitové optické vlákno, nejvýkonnější serverový hardware se šíleným množstvím RAM, vše propojili, nakonfigurovali – a zase nic! Pak začali mít podezření, že důvodem mohou být timeouty, tak šli do všech nastavení webu, všech nastavení API a aktualizovali celou konfiguraci timeoutu na maximální hodnoty, takže nezbývalo než sedět a čekat, až se něco stane. na web. Čekali a čekali a čekali 9 a půl minuty, než se web konečně načetl.
Poté jim došlo, že současná situace potřebuje důkladnou analýzu, a pozvali nás. První, co jsme zjistili, bylo, že za celých 18 měsíců vývoje nevzniklo jediné skutečné „mikro“ – vše se jen zvětšovalo. Poté jsme začali psát posmrtnou zprávu, známou také jako „regretrospektiva“ nebo „smutná retrospektiva“, také známá jako „vinná bouře“, podobná „bouři mozků“, abychom pochopili příčinu katastrofy.
Měli jsme několik vodítek, jednou z nich byla úplná saturace provozu v době volání API. Když používáte monolitickou architekturu služeb, můžete okamžitě pochopit, co přesně se pokazilo, protože máte jediné trasování zásobníku, které hlásí vše, co mohlo způsobit selhání. V případě, že ke stejnému API přistupuje současně spousta služeb, neexistuje žádný způsob, jak sledovat trasování, kromě použití dalších nástrojů pro monitorování sítě, jako je WireShark, díky kterému můžete prozkoumat jeden požadavek a zjistit, co se stalo během jeho implementace. Vzali jsme tedy jednu webovou stránku a strávili téměř 2 týdny skládáním kousků skládačky dohromady, prováděním různých volání a analýzou toho, k čemu každá z nich vedla.
Podívej se na tento obrázek. Ukazuje, že jeden externí požadavek vyzve službu k uskutečnění mnoha interních volání, která se vrátí zpět. Ukazuje se, že každý interní hovor dělá další skoky, aby bylo možné nezávisle obsloužit tento požadavek, protože se nemůže obrátit nikam jinam, aby získal potřebné informace. Tento obrázek vypadá jako nesmyslná kaskáda volání, protože externí požadavek volá doplňkové služby, které volají další doplňkové služby a tak dále, téměř do nekonečna.
Zelená barva v tomto diagramu znázorňuje půlkruh, ve kterém si služby navzájem volají – služba A volá službu B, služba B volá službu C a ta opět volá službu A. Výsledkem je „distribuované zablokování“. Jediný požadavek vytvořil tisíc síťových volání API, a protože systém neměl zabudovanou odolnost proti chybám a ochranu smyčky, požadavek by selhal, pokud by selhalo i jedno z těchto volání API.
Udělali jsme trochu matematiky. Každé volání API mělo SLA ne více než 150 ms a 99,9% dostupnost. Jeden požadavek způsobil 200 různých volání a v nejlepším případě se stránka mohla zobrazit za 200 x 150 ms = 30 sekund. Přirozeně to nebylo dobré. Vynásobením 99,9% doby provozuschopnosti číslem 200 jsme získali 0% dostupnost. Ukazuje se, že tato architektura byla od samého počátku odsouzena k neúspěchu.
Zeptali jsme se vývojářů, jak se jim po 18 měsících práce nepodařilo tento problém rozpoznat? Ukázalo se, že počítali pouze SLA pro kód, který spustili, ale pokud jejich služba volala jinou službu, nezapočítali tento čas do své SLA. Vše, co bylo spuštěno v rámci jednoho procesu, se drželo hodnoty 150 ms, ale přístup k dalším servisním procesům celkové zpoždění mnohonásobně zvýšil. První poučení bylo: „Máte kontrolu nad svou SLA, nebo SLA ovládá vás?“ V našem případě to bylo to druhé.
Další věc, kterou jsme zjistili, bylo, že věděli o konceptu distribuovaných výpočetních mylných představ, formulovaných Peterem Deitchem a Jamesem Goslingem, ale ignorovali jeho první část. Uvádí, že prohlášení „síť je spolehlivá“, „nulová latence“ a „nekonečná propustnost“ jsou mylné představy. Mezi další mylné představy patří výroky „síť je bezpečná“, „topologie se nikdy nemění“, „vždy existuje pouze jeden správce“, „cena za přenos dat je nulová“ a „síť je homogenní“.
Udělali chybu, protože testovali svou službu na místních počítačích a nikdy se nepřipojili k externím službám. Při lokálním vývoji a použití lokální mezipaměti nikdy nenarazili na síťové skoky. Za celých 18 měsíců vývoje je ani jednou nenapadlo, co by se mohlo stát, kdyby byly ovlivněny externí služby.
Pokud se podíváte na hranice služeb na předchozím obrázku, můžete vidět, že jsou všechny nesprávné. Existuje spousta zdrojů, které radí, jak definovat hranice služeb, a většina to dělá špatně, jako Microsoft na dalším snímku.
Tento obrázek je z blogu MS na téma “Jak budovat mikroslužby”. To ukazuje jednoduchou webovou aplikaci, blok obchodní logiky a databázi. Požadavek přichází přímo, pravděpodobně existuje jeden server pro web, jeden server pro obchod a jeden pro databázi. Pokud zvýšíte návštěvnost, obrázek se trochu změní.
Zde přichází load balancer pro distribuci provozu mezi dva webové servery, mezipaměť umístěnou mezi webovou službou a obchodní logikou a další mezipaměť mezi obchodní logikou a databází. To je přesně architektura, kterou Bell používal pro svou aplikaci pro vyrovnávání zátěže a modro-zelené nasazení v polovině 2000. století. Do určité doby vše fungovalo dobře, protože toto schéma bylo určeno pro monolitickou strukturu.
Následující obrázek ukazuje, jak MS doporučuje přejít od monolitu k mikroslužbám – jednoduše rozdělit každou z hlavních služeb na samostatné mikroslužby. Právě při realizaci tohoto schématu udělal Bell chybu.
Všechny své služby rozdělili do různých úrovní, z nichž každá sestávala z mnoha jednotlivých služeb. Webová služba například zahrnovala mikroslužby pro vykreslování obsahu a autentizaci, služba obchodní logiky se skládala z mikroslužeb pro zpracování objednávek a informací o účtu, databáze byla rozdělena do hromady mikroslužeb se specializovanými daty. Web, obchodní logika i databáze byly bezstavové služby.
Tento obrázek však byl zcela chybný, protože nemapoval žádné obchodní jednotky mimo IT cluster společnosti. Toto schéma nezohledňovalo žádné spojení s vnějším světem, takže nebylo jasné, jak například získat obchodní analytiku třetích stran. Podotýkám, že také měli několik služeb vymyšlených jednoduše pro rozvoj kariéry jednotlivých zaměstnanců, kteří se snažili řídit co nejvíce lidí, aby za to dostali více peněz.
Věřili, že přechod na mikroslužby je stejně snadný jako vzít jejich interní infrastrukturu fyzické vrstvy N-tier a nalepit na ni Docker. Pojďme se podívat, jak vypadá tradiční architektura N-tier.
Skládá se ze 4 úrovní: úroveň uživatelského rozhraní uživatelského rozhraní, úroveň obchodní logiky, úroveň přístupu k datům a databáze. Progresivnější je DDD (Domain-Driven Design), neboli softwarově orientovaná architektura, kde dvě střední úrovně jsou doménové objekty a repozitář.
Snažil jsem se podívat na různé oblasti změn, různé oblasti odpovědnosti v této architektuře. V typické N-vrstvé aplikaci jsou klasifikovány různé oblasti změn, které prostupují strukturou vertikálně shora dolů. Jedná se o katalog, nastavení konfigurace prováděné na jednotlivých počítačích a kontroly pokladny, které řešil můj tým.
Zvláštností tohoto schématu je, že hranice těchto oblastí změn ovlivňují nejen úroveň obchodní logiky, ale rozšiřují se i do databáze.
Podívejme se, co to znamená být službou. Definice služby má 6 charakteristických vlastností – je to software, který:
- vytvořené a používané konkrétní organizací;
- odpovídá za obsah, zpracování a/nebo poskytování určitého typu informací v rámci systému;
- lze sestavit, nasadit a provozovat nezávisle, aby vyhovovaly specifickým provozním potřebám;
- komunikuje se spotřebiteli a dalšími službami, poskytuje informace na základě dohod nebo smluvních záruk;
- chrání se před neoprávněným přístupem a své informace před ztrátou;
- řeší poruchy tak, aby nevedly k poškození informací.
Všechny tyto vlastnosti lze vyjádřit jedním slovem „autonomie“. Služby fungují nezávisle na sobě, splňují určitá omezení a definují smlouvy, na jejichž základě mohou lidé přijímat informace, které potřebují. Konkrétní technologie, jejichž použití je samozřejmé, jsem nezmínil.
Nyní se podívejme na definici mikroslužeb:
- mikroslužba má malou velikost a je navržena tak, aby řešila jeden konkrétní problém;
- Mikroslužba je autonomní;
- Při vytváření architektury mikroslužeb se používá metafora urbanismu. Toto je definice z knihy Sama Newmana Building Microservices.
Definice ohraničeného kontextu je převzata z knihy Erica Evanse Domain-Driven Design. Toto je základní vzor v DDD, architektonickém designérském centru, které pracuje s objemovými architektonickými modely, rozděluje je do různých ohraničených kontextů a explicitně definuje interakce mezi nimi.
Jednoduše řečeno, ohraničený kontext označuje rozsah, ve kterém lze konkrétní modul použít. V tomto kontextu je logicky jednotný model, který lze vidět například ve vaší obchodní doméně. Pokud se zeptáte „kdo je klient“ personálu zapojeného do objednávek, dostanete jednu definici, pokud se zeptáte těch, kteří se podílejí na prodeji, dostanete jinou a účinkující vám poskytnou třetí definici.
Bounded Context tedy říká, že pokud nemůžeme dát jasnou definici toho, co je spotřebitel našich služeb, definujme hranice, ve kterých můžeme mluvit o významu tohoto termínu, a pak definujme přechodové body mezi těmito různými definicemi. Čili pokud se bavíme o klientovi z pohledu zadávání zakázek, tak to znamená to a to, a pokud z pohledu prodeje, tak to a to.
Další definicí mikroslužby je zapouzdření jakéhokoli druhu vnitřních operací, zabraňující „úniku“ složek pracovního procesu do prostředí. Dále přichází „definice explicitních smluv pro externí interakce nebo externí komunikace“, která je reprezentována myšlenkou smluv vracejících se z SLA. Poslední definicí je metafora buňky neboli buňky, která znamená úplné zapouzdření souboru operací v rámci mikroslužby a přítomnost v ní receptorů pro komunikaci s vnějším světem.
Řekli jsme tedy klukům z Bell Computers: „Nemůžeme napravit žádný chaos, který jste vytvořili, protože na to prostě nemáte peníze, ale opravíme jen jednu službu, aby to všechno fungovalo. smysl." V tuto chvíli začnu tím, že vám řeknu, jak jsme naši jedinou službu opravili tak, aby reagovala na požadavky rychleji než 9 a půl minuty.
22:30 min
Pokračování již brzy...
Trochu reklamy
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com