Strávili ste mesiace prestavbou svojho monolitu na mikroslužby a nakoniec sa všetci spojili, aby prehodili vypínač. Idete na prvú webovú stránku... a nič sa nedeje. Znovu ho načítate – a opäť nič dobré, stránka je taká pomalá, že niekoľko minút nereaguje. Čo sa stalo?
Jimmy Bogard vo svojej prednáške vykoná „post-mortem“ katastrofu mikroslužieb v reálnom živote. Ukáže problémy s modelovaním, vývojom a výrobou, ktoré objavil, a ako jeho tím pomaly transformoval nový distribuovaný monolit na konečný obraz zdravého rozumu. Aj keď je nemožné úplne zabrániť chybám v návrhu, môžete aspoň identifikovať problémy na začiatku procesu návrhu, aby ste zabezpečili, že konečný produkt sa stane spoľahlivým distribuovaným systémom.
Ahojte všetci, som Jimmy a dnes budete počuť, ako sa môžete vyhnúť mega katastrofám pri budovaní mikroslužieb. Toto je príbeh spoločnosti, pre ktorú som pracoval asi rok a pol, aby som pomohol zabrániť zrážke ich lode s ľadovcom. Aby sme tento príbeh správne vyrozprávali, budeme sa musieť vrátiť v čase a porozprávať sa o tom, kde táto spoločnosť začala a ako sa jej IT infraštruktúra časom rozrástla. Aby som ochránil mená nevinných v tejto katastrofe, zmenil som názov tejto spoločnosti na Bell Computers. Ďalší slide ukazuje, ako vyzerala IT infraštruktúra takýchto spoločností v polovici 90. rokov. Toto je typická architektúra veľkého univerzálneho servera HP Tandem Mainframe odolného voči chybám na prevádzku obchodu s počítačovým hardvérom.
Potrebovali vybudovať systém na manažovanie všetkých objednávok, predaja, vrátenia tovaru, katalógov produktov a zákazníckej základne, preto si zvolili v tom čase najbežnejšie mainframové riešenie. Tento obrovský systém obsahoval všetky informácie o spoločnosti, všetko možné a každá transakcia bola vykonaná cez tento mainframe. Všetky vajcia držali v jednom košíku a mysleli si, že je to normálne. Jediná vec, ktorá tu nie je zahrnutá, sú katalógy poštových objednávok a telefonické objednávky.
Postupom času sa systém zväčšoval a zväčšoval a hromadilo sa v ňom obrovské množstvo odpadu. COBOL tiež nie je najexpresívnejší jazyk na svete, takže systém skončil ako veľký, monolitický kus odpadu. V roku 2000 videli, že veľa spoločností má webové stránky, prostredníctvom ktorých riadia úplne všetky svoje obchody, a rozhodli sa vybudovať svoju prvú komerčnú webovú stránku s dot-com.
Počiatočný dizajn vyzeral celkom pekne a pozostával zo stránky najvyššej úrovne bell.com a niekoľkých subdomén pre jednotlivé aplikácie: Catalog.bell.com, accounts.bell.com, orders.bell.com, vyhľadávanie produktov search.bell. com. Každá subdoména používala rámec ASP.Net 1.0 a svoje vlastné databázy a všetky hovorili s backendom systému. Všetky objednávky sa však naďalej spracovávali a vykonávali v rámci jedného obrovského mainframe, v ktorom zostal všetok odpad, no frontendom boli samostatné webové stránky s jednotlivými aplikáciami a samostatnými databázami.
Takže návrh systému vyzeral usporiadane a logicky, ale skutočný systém bol taký, ako je znázornené na ďalšej snímke.
Všetky prvky riešili vzájomné volania, pristupovali k API, vstavaným dll tretích strán a podobne. Často sa stávalo, že systémy na správu verzií chytili cudzí kód, strčili ho do projektu a potom sa všetko pokazilo. MS SQL Server 2005 využíval koncepciu link serverov a hoci som šípky na snímke neukázal, každá z databáz sa rozprávala aj medzi sebou, pretože na zostavovaní tabuliek na základe údajov získaných z viacerých databáz nie je nič zlé.
Keďže teraz mali určité oddelenie medzi rôznymi logickými oblasťami systému, stali sa z toho rozmiestnené kvapôčky špiny, pričom najväčší kus odpadu stále zostával v backende mainframe.
Vtipné bolo, že tento mainframe postavili konkurenti Bell Computers a stále ho udržiavali ich technickí konzultanti. Spoločnosť je presvedčená o neuspokojivom výkone svojich aplikácií a rozhodla sa ich zbaviť a systém prepracovať.
Existujúca aplikácia bola vo výrobe 15 rokov, čo je rekord pre aplikácie založené na ASP.Net. Služba prijímala objednávky z celého sveta a ročné príjmy z tejto jedinej aplikácie dosiahli miliardu dolárov. Značnú časť zisku vytvoril web bell.com. Počas čiernych piatkov dosiahol počet objednávok cez stránku niekoľko miliónov. Existujúca architektúra však neumožňovala žiadny rozvoj, keďže tuhé prepojenia systémových prvkov prakticky neumožňovali vykonať v službe žiadne zmeny.
Najzávažnejším problémom bola nemožnosť zadať objednávku z jednej krajiny, zaplatiť za ňu v inej a poslať ju do tretej, a to aj napriek tomu, že takáto schéma obchodovania je vo svetových spoločnostiach veľmi bežná. Existujúci web nič také neumožňoval, a tak museli tieto objednávky prijímať a zadávať cez telefón. To viedlo k tomu, že spoločnosť stále viac premýšľala o zmene architektúry, najmä o prechode na mikroslužby.
Urobili šikovnú vec, keď sa pozreli na iné spoločnosti, aby zistili, ako vyriešili podobný problém. Jedným z týchto riešení bola architektúra služieb Netflix, ktorá pozostáva z mikroslužieb prepojených cez API a externú databázu.
Vedenie spoločnosti Bell Computers sa rozhodlo vybudovať práve takúto architektúru pri dodržaní určitých základných princípov. Po prvé, eliminovali duplicitu údajov použitím prístupu zdieľanej databázy. Neposielali sa žiadne dáta, naopak, každý, kto ich potreboval, musel ísť do centralizovaného zdroja. Nasledovala izolácia a autonómia – každá služba bola nezávislá od ostatných. Rozhodli sa použiť Web API úplne na všetko – ak ste chceli získať dáta alebo vykonať zmeny v inom systéme, všetko sa to dialo cez Web API. Poslednou veľkou vecou bol nový sálový počítač s názvom „Bell on Bell“ na rozdiel od sálového počítača „Bell“ založeného na hardvéri konkurentov.
Takže v priebehu 18 mesiacov postavili systém na týchto základných princípoch a priviedli ho do predprodukcie. Po víkendovom návrate do práce sa vývojári spojili a zapli všetky servery, ku ktorým bol nový systém pripojený. 18 mesiacov práce, stovky vývojárov, najmodernejší hardvér Bell – a žiadny pozitívny výsledok! To sklamalo veľa ľudí, pretože tento systém spustili na svojich notebookoch mnohokrát a všetko bolo v poriadku.
Boli chytrí, že vynaložili všetky svoje peniaze na vyriešenie tohto problému. Nainštalovali najmodernejšie serverové racky s prepínačmi, použili gigabitové optické vlákno, najvýkonnejší serverový hardvér so šialeným množstvom RAM, všetko pripojili, nakonfigurovali – a opäť nič! Potom začali mať podozrenie, že dôvodom môžu byť timeouty, a tak prešli do všetkých nastavení webu, všetkých nastavení API a aktualizovali celú konfiguráciu timeoutu na maximálne hodnoty, takže mohli len sedieť a čakať, kým sa niečo stane. na stránku. Čakali a čakali a čakali 9 a pol minúty, kým sa web konečne načítal.
Potom im došlo, že súčasná situácia potrebuje dôkladnú analýzu a pozvali nás. Ako prvé sme zistili, že počas celých 18 mesiacov vývoja nevzniklo jediné skutočné „mikro“ – všetko sa len zväčšovalo. Potom sme začali písať post-mortem, tiež známu ako „regretrospektíva“ alebo „smutná retrospektíva“, známa aj ako „búrka viny“, podobná „búre mozgov“, aby sme pochopili príčinu katastrofy.
Mali sme viacero indícií, jednou z nich bola úplná saturácia premávky v čase volania API. Keď použijete monolitickú architektúru služieb, môžete okamžite pochopiť, čo presne sa pokazilo, pretože máte jediné sledovanie zásobníka, ktoré hlási všetko, čo mohlo spôsobiť zlyhanie. V prípade, že množstvo služieb súčasne pristupuje k rovnakému API, neexistuje žiadny spôsob, ako sledovať sledovanie, okrem použitia ďalších nástrojov na monitorovanie siete, ako je WireShark, vďaka ktorým môžete preskúmať jednu požiadavku a zistiť, čo sa stalo počas jej implementácie. Vzali sme teda jednu webovú stránku a strávili sme takmer 2 týždne skladaním kúskov skladačky, robili sme na ňu rôzne volania a analyzovali, k čomu každá z nich viedla.
Pozrite sa na tento obrázok. Ukazuje, že jedna externá požiadavka vyzve službu, aby uskutočnila mnoho interných hovorov, ktoré sa vrátia späť. Ukazuje sa, že každý interný hovor robí ďalšie skoky, aby bolo možné nezávisle obsluhovať túto požiadavku, pretože sa nemôže obrátiť nikam inam, aby získal potrebné informácie. Tento obrázok vyzerá ako nezmyselná kaskáda hovorov, pretože externá požiadavka volá doplnkové služby, ktoré volajú ďalšie doplnkové služby atď., takmer donekonečna.
Zelená farba v tomto diagrame znázorňuje polkruh, v ktorom si služby navzájom volajú – služba A volá službu B, služba B volá službu C a opäť volá službu A. Výsledkom je „distribuované zablokovanie“. Jedna požiadavka vytvorila tisíc sieťových volaní API a keďže systém nemal zabudovanú odolnosť proti chybám a ochranu slučky, požiadavka by zlyhala, ak by čo i len jedno z týchto volaní API zlyhalo.
Urobili sme trochu matematiky. Každé volanie API malo SLA maximálne 150 ms a 99,9% dostupnosť. Jedna požiadavka spôsobila 200 rôznych hovorov a v najlepšom prípade sa stránka mohla zobraziť za 200 x 150 ms = 30 sekúnd. Prirodzene, nebolo to dobré. Vynásobením 99,9% dostupnosti číslom 200 sme získali 0% dostupnosť. Ukazuje sa, že táto architektúra bola od samého začiatku odsúdená na neúspech.
Spýtali sme sa vývojárov, ako nedokázali rozpoznať tento problém po 18 mesiacoch práce? Ukázalo sa, že započítali iba SLA pre kód, ktorý spustili, ale ak ich služba zavolala inú službu, tento čas do svojej SLA nezapočítali. Všetko, čo bolo spustené v rámci jedného procesu, sa držalo na hodnote 150 ms, no prístup k ďalším obslužným procesom mnohonásobne zvýšil celkové oneskorenie. Prvá lekcia, ktorú sme sa naučili, bola: „Máte kontrolu nad svojou SLA alebo má SLA kontrolu nad vami?“ V našom prípade to bolo to druhé.
Ďalšia vec, ktorú sme zistili, bola, že vedeli o koncepte distribuovaných výpočtových mylných predstáv, ktorý sformulovali Peter Deitch a James Gosling, ale ignorovali jeho prvú časť. Uvádza, že vyhlásenia „sieť je spoľahlivá“, „nulová latencia“ a „nekonečná priepustnosť“ sú mylné. Medzi ďalšie mylné predstavy patria výroky „sieť je bezpečná“, „topológia sa nikdy nemení“, „vždy existuje len jeden správca“, „cena prenosu dát je nulová“ a „sieť je homogénna“.
Urobili chybu, pretože testovali svoju službu na miestnych počítačoch a nikdy sa nepripojili k externým službám. Pri lokálnom vývoji a používaní lokálnej vyrovnávacej pamäte sa nikdy nestretli so skokmi v sieti. Počas celých 18 mesiacov vývoja ich ani raz nenapadlo, čo by sa mohlo stať, keby boli ovplyvnené externé služby.
Ak sa pozriete na hranice služieb na predchádzajúcom obrázku, môžete vidieť, že všetky sú nesprávne. Existuje veľa zdrojov, ktoré radia, ako definovať hranice služieb, a väčšina z nich to robí zle, ako napríklad Microsoft na ďalšej snímke.
Tento obrázok je z blogu MS na tému “Ako vybudovať mikroslužby”. Zobrazuje jednoduchú webovú aplikáciu, blok obchodnej logiky a databázu. Požiadavka prichádza priamo, pravdepodobne existuje jeden server pre web, jeden server pre obchod a jeden pre databázu. Ak zvýšite návštevnosť, obraz sa trochu zmení.
Tu prichádza vyrovnávač zaťaženia na distribúciu prevádzky medzi dvoma webovými servermi, vyrovnávacia pamäť umiestnená medzi webovou službou a obchodnou logikou a ďalšia vyrovnávacia pamäť medzi obchodnou logikou a databázou. Toto je presne architektúra, ktorú Bell použil pre svoju aplikáciu na vyvažovanie záťaže a modro-zelenú aplikáciu v polovici 2000-tych rokov. Až do určitej doby všetko fungovalo dobre, pretože táto schéma bola určená pre monolitickú štruktúru.
Nasledujúci obrázok ukazuje, ako MS odporúča prejsť z monolitu na mikroslužby – jednoducho rozdeliť každú z hlavných služieb na samostatné mikroslužby. Práve pri implementácii tejto schémy sa Bell dopustil chyby.
Všetky svoje služby rozdelili do rôznych úrovní, z ktorých každá pozostávala z mnohých individuálnych služieb. Napríklad webová služba zahŕňala mikroslužby na vykresľovanie obsahu a autentifikáciu, služba obchodnej logiky pozostávala z mikroslužieb na spracovanie objednávok a informácií o účte, databáza bola rozdelená na množstvo mikroslužieb so špecializovanými údajmi. Web, obchodná logika aj databáza boli služby bez štátnej príslušnosti.
Tento obrázok bol však úplne nesprávny, pretože nemapoval žiadne obchodné jednotky mimo IT klastra spoločnosti. Táto schéma nezohľadňovala žiadne prepojenie s vonkajším svetom, takže nebolo jasné, ako napríklad získať obchodné analýzy tretích strán. Podotýkam, že mali vymyslených aj niekoľko služieb jednoducho na rozvoj kariéry jednotlivých zamestnancov, ktorí sa snažili riadiť čo najviac ľudí, aby za to dostali viac peňazí.
Verili, že prechod na mikroslužby je taký jednoduchý, ako vziať ich internú infraštruktúru fyzickej vrstvy N-tier a nalepiť na ňu Docker. Poďme sa pozrieť na to, ako vyzerá tradičná architektúra N-tier.
Pozostáva zo 4 úrovní: úroveň používateľského rozhrania používateľského rozhrania, úroveň obchodnej logiky, úroveň prístupu k údajom a databáza. Progresívnejšia je DDD (Domain-Driven Design), čiže softvérovo orientovaná architektúra, kde dve stredné úrovne sú doménové objekty a repozitár.
Snažil som sa pozrieť na rôzne oblasti zmien, rôzne oblasti zodpovednosti v tejto architektúre. V typickej N-vrstvovej aplikácii sú klasifikované rôzne oblasti zmien, ktoré prechádzajú štruktúrou vertikálne zhora nadol. Ide o katalóg, nastavenia konfigurácie vykonávané na jednotlivých počítačoch a kontroly pokladne, ktoré riešil môj tím.
Zvláštnosťou tejto schémy je, že hranice týchto oblastí zmien ovplyvňujú nielen úroveň obchodnej logiky, ale siahajú aj do databázy.
Pozrime sa, čo znamená byť službou. Definícia služby má 6 charakteristických vlastností – je to softvér, ktorý:
- vytvorené a používané konkrétnou organizáciou;
- zodpovedá za obsah, spracovanie a/alebo poskytovanie určitého druhu informácií v rámci systému;
- môžu byť zostavené, nasadené a prevádzkované nezávisle, aby vyhovovali špecifickým prevádzkovým potrebám;
- komunikuje so spotrebiteľmi a inými službami, poskytuje informácie na základe dohôd alebo zmluvných záruk;
- chráni sa pred neoprávneným prístupom a svoje informácie pred stratou;
- rieši poruchy tak, aby neviedli k poškodeniu informácií.
Všetky tieto vlastnosti možno vyjadriť jedným slovom „autonómia“. Služby fungujú nezávisle od seba, spĺňajú určité obmedzenia a definujú zmluvy, na základe ktorých môžu ľudia dostávať informácie, ktoré potrebujú. Konkrétne technológie, ktorých použitie je samozrejmé, som nespomenul.
Teraz sa pozrime na definíciu mikroslužieb:
- mikroslužba má malú veľkosť a je určená na riešenie jedného konkrétneho problému;
- Mikroslužba je autonómna;
- Pri tvorbe architektúry mikroslužieb sa používa metafora urbanizmu. Toto je definícia z knihy Sama Newmana Building Microservices.
Definícia ohraničeného kontextu je prevzatá z knihy Erica Evansa Domain-Driven Design. Toto je základný vzor v DDD, architektonickom dizajnovom centre, ktoré pracuje s objemovými architektonickými modelmi, rozdeľuje ich do rôznych ohraničených kontextov a explicitne definuje interakcie medzi nimi.
Jednoducho povedané, ohraničený kontext označuje rozsah, v ktorom je možné použiť konkrétny modul. V tomto kontexte je logicky jednotný model, ktorý možno vidieť napríklad vo vašej obchodnej doméne. Ak sa spýtate „kto je klient“ personálu zapojeného do objednávok, dostanete jednu definíciu, ak sa spýtate tých, ktorí sú zapojení do predaja, dostanete inú a účinkujúci vám dajú tretiu definíciu.
Bounded Context teda hovorí, že ak nedokážeme jasne definovať, čo je spotrebiteľom našich služieb, definujme hranice, v rámci ktorých môžeme hovoriť o význame tohto pojmu, a potom definujme prechodové body medzi týmito rôznymi definíciami. Čiže ak sa bavíme o klientovi z pohľadu zadávania objednávok, tak to znamená to a to, a ak z pohľadu predaja, tak toto a tamto.
Ďalšou definíciou mikroslužby je zapuzdrenie akéhokoľvek druhu interných operácií, ktoré bráni „úniku“ komponentov pracovného procesu do prostredia. Ďalej prichádza „definícia explicitných zmlúv pre externé interakcie alebo externú komunikáciu“, ktorá je reprezentovaná myšlienkou zmlúv vracajúcich sa z SLA. Poslednou definíciou je metafora bunky alebo bunky, ktorá znamená úplné zapuzdrenie súboru operácií v rámci mikroslužby a prítomnosť v nej receptorov pre komunikáciu s vonkajším svetom.
Povedali sme teda chlapcom z Bell Computers: „Nemôžeme napraviť žiadny chaos, ktorý ste vytvorili, pretože na to jednoducho nemáte peniaze, ale opravíme len jednu službu, aby to všetko zmysel.” V tejto chvíli začnem tým, že vám poviem, ako sme našu jedinú službu opravili tak, aby reagovala na požiadavky rýchlejšie ako 9 a pol minúty.
22:30 min
Pokračovanie už čoskoro...
Trochu reklamy
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, , jedinečný analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
Dell R730xd 2 krát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com