Ați petrecut luni de zile reproiectându-vă monolitul în microservicii și, în sfârșit, toată lumea s-a reunit pentru a schimba comutatorul. Te duci la prima pagină web... și nu se întâmplă nimic. Îl reîncărcați - și din nou nimic bun, site-ul este atât de lent încât nu răspunde timp de câteva minute. Ce s-a întâmplat?
În discursul său, Jimmy Bogard va efectua un „post-mortem” asupra unui dezastru de microservicii din viața reală. El va arăta problemele de modelare, dezvoltare și producție pe care le-a descoperit și modul în care echipa sa a transformat încet noul monolit distribuit în imaginea finală a sanității mentale. Deși este imposibil să preveniți complet erorile de proiectare, puteți cel puțin identifica problemele la începutul procesului de proiectare pentru a vă asigura că produsul final devine un sistem distribuit de încredere.
Salutare tuturor, sunt Jimmy și astăzi veți afla cum puteți evita mega-dezastrele atunci când construiți microservicii. Aceasta este povestea unei companii la care am lucrat aproximativ un an și jumătate pentru a preveni ciocnirea navei lor cu un aisberg. Pentru a spune această poveste în mod corespunzător, va trebui să ne întoarcem în timp și să vorbim despre locul în care a început această companie și despre modul în care infrastructura sa IT a crescut de-a lungul timpului. Pentru a proteja numele celor nevinovați în acest dezastru, am schimbat numele acestei companii în Bell Computers. Următorul slide arată cum arăta infrastructura IT a unor astfel de companii la mijlocul anilor '90. Aceasta este o arhitectură tipică a unui server HP Tandem Mainframe universal mare, tolerant la erori, pentru operarea unui magazin hardware de computer.
Aveau nevoie să construiască un sistem pentru a gestiona toate comenzile, vânzările, retururile, cataloagele de produse și baza de clienți, așa că au ales cea mai comună soluție mainframe la momentul respectiv. Acest sistem gigant conținea toate informațiile despre companie, tot ceea ce era posibil și fiecare tranzacție a fost efectuată prin intermediul acestui mainframe. Și-au păstrat toate ouăle într-un singur coș și au crezut că este normal. Singurul lucru care nu este inclus aici sunt cataloagele de comandă prin poștă și plasarea comenzilor prin telefon.
De-a lungul timpului, sistemul a devenit din ce în ce mai mare și s-a acumulat o cantitate imensă de gunoi în el. De asemenea, COBOL nu este cel mai expresiv limbaj din lume, așa că sistemul a ajuns să fie o bucată mare, monolitică de gunoi. Până în 2000, ei au văzut că multe companii aveau site-uri web prin care își desfășurau absolut toate afacerile și au decis să-și construiască primul site comercial dot-com.
Designul inițial arăta destul de frumos și a constat dintr-un site de nivel superior bell.com și un număr de subdomenii pentru aplicații individuale: catalog.bell.com, accounts.bell.com, orders.bell.com, căutare de produse search.bell. com. Fiecare subdomeniu a folosit cadrul ASP.Net 1.0 și propriile baze de date și toți au vorbit cu backend-ul sistemului. Cu toate acestea, toate comenzile au continuat să fie procesate și executate într-un singur mainframe imens, în care au rămas tot gunoiul, dar front-end-ul erau site-uri web separate cu aplicații individuale și baze de date separate.
Deci, designul sistemului arăta ordonat și logic, dar sistemul real a fost așa cum se arată în diapozitivul următor.
Toate elementele au adresat apeluri unul altuia, au accesat API-uri, dll-uri terțe încorporate și altele asemenea. S-a întâmplat adesea ca sistemele de control al versiunilor să prindă codul altcuiva, să-l introducă în proiect și apoi totul să se rupă. MS SQL Server 2005 a folosit conceptul de servere de legături și, deși nu am arătat săgețile de pe slide, fiecare dintre bazele de date au vorbit și între ele, deoarece nu este nimic greșit în construirea tabelelor pe baza datelor obținute din mai multe baze de date.
Deoarece acum aveau o anumită separare între diferitele zone logice ale sistemului, aceasta a devenit bulburi distribuite de murdărie, cel mai mare gunoi rămânând încă în backend-ul mainframe-ului.
Lucrul amuzant a fost că acest mainframe a fost construit de concurenții Bell Computers și a fost încă întreținut de consultanții lor tehnici. Convinsă de performanța nesatisfăcătoare a aplicațiilor sale, compania a decis să scape de ele și să reproiecteze sistemul.
Aplicația existentă a fost în producție de 15 ani, ceea ce este un record pentru aplicațiile bazate pe ASP.Net. Serviciul a acceptat comenzi din toată lumea, iar veniturile anuale din această singură aplicație au ajuns la un miliard de dolari. O parte semnificativă a profitului a fost generată de site-ul bell.com. În Black Friday, numărul comenzilor plasate prin intermediul site-ului a ajuns la câteva milioane. Cu toate acestea, arhitectura existentă nu a permis nicio dezvoltare, întrucât interconexiunile rigide ale elementelor sistemului practic nu au permis efectuarea de modificări la serviciu.
Cea mai gravă problemă a fost imposibilitatea de a plasa o comandă dintr-o țară, de a plăti pentru aceasta într-o altă țară și de a o trimite într-o a treia, în ciuda faptului că o astfel de schemă de tranzacționare este foarte comună în companiile globale. Site-ul web existent nu permitea așa ceva, așa că a trebuit să accepte și să plaseze aceste comenzi prin telefon. Acest lucru a făcut ca compania să se gândească din ce în ce mai mult la schimbarea arhitecturii, în special la trecerea la microservicii.
Au făcut lucrul inteligent, uitându-se la alte companii pentru a vedea cum au rezolvat o problemă similară. Una dintre aceste soluții a fost arhitectura serviciului Netflix, care constă din microservicii conectate printr-un API și o bază de date externă.
Conducerea Bell Computers a decis să construiască tocmai o astfel de arhitectură, aderând la anumite principii de bază. În primul rând, au eliminat duplicarea datelor utilizând o abordare a bazelor de date partajate. Nu au fost trimise date, dimpotrivă, toți cei care aveau nevoie de ele trebuiau să meargă la o sursă centralizată. A urmat izolare și autonomie - fiecare serviciu era independent de celelalte. Ei au decis să folosească API-ul web pentru absolut orice - dacă doreați să obțineți date sau să faceți modificări la alt sistem, totul se făcea prin API-ul web. Ultimul lucru important a fost un nou mainframe numit „Bell on Bell” spre deosebire de mainframe „Bell” bazat pe hardware-ul concurenților.
Deci, pe parcursul a 18 luni, au construit sistemul în jurul acestor principii de bază și l-au adus la pre-producție. Reveniți la lucru după weekend, dezvoltatorii s-au reunit și au pornit toate serverele la care era conectat noul sistem. 18 luni de muncă, sute de dezvoltatori, cel mai modern hardware Bell - și niciun rezultat pozitiv! Acest lucru i-a dezamăgit pe mulți oameni, deoarece au rulat acest sistem pe laptopurile lor de multe ori și totul a fost bine.
Au fost deștepți să-și arunce toți banii pentru a rezolva această problemă. Au instalat cele mai moderne rafturi de servere cu comutatoare, au folosit fibră optică gigabit, cel mai puternic hardware de server cu o cantitate nebună de RAM, le-au conectat pe toate, l-au configurat - și din nou, nimic! Apoi au început să bănuiască că motivul ar putea fi timeout-uri, așa că au intrat în toate setările web, toate setările API și au actualizat întreaga configurație de timeout la valorile maxime, astfel încât tot ce puteau face era să stea și să aștepte să se întâmple ceva. la site. Au așteptat și au așteptat și au așteptat 9 minute și jumătate până când site-ul s-a încărcat în sfârșit.
După aceea, le-a dat seama că situația actuală necesită o analiză amănunțită și ne-au invitat. Primul lucru pe care l-am aflat a fost că în toate cele 18 luni de dezvoltare, nu a fost creat un singur „micro” adevărat - totul a devenit mai mare. După aceasta, am început să scriem o autopsie, cunoscută și sub numele de „retrospectivă”, sau „retrospectivă tristă”, cunoscută și sub denumirea de „furtună de vină”, asemănătoare cu o „furtună de creier”, pentru a înțelege cauza dezastrului.
Am avut mai multe indicii, dintre care unul era saturația completă a traficului la momentul apelului API. Când utilizați o arhitectură de serviciu monolitică, puteți înțelege imediat ce a mers prost, deoarece aveți o singură urmă de stivă care raportează tot ceea ce ar fi putut cauza eșecul. În cazul în care o grămadă de servicii accesează simultan același API, nu există nicio modalitate de a urmări urmărirea, cu excepția utilizării unor instrumente suplimentare de monitorizare a rețelei precum WireShark, datorită cărora puteți examina o singură solicitare și puteți afla ce s-a întâmplat în timpul implementării acesteia. Așa că am luat o pagină web și am petrecut aproape 2 săptămâni punând cap la cap piesele puzzle-ului, făcând o varietate de apeluri și analizând la ce a condus fiecare dintre ele.
Uită-te la această poză. Acesta arată că o solicitare externă solicită serviciului să efectueze multe apeluri interne care revin înapoi. Se pare că fiecare apel intern face hopuri suplimentare pentru a putea deservi independent această solicitare, deoarece nu se poate întoarce nicăieri pentru a obține informațiile necesare. Această imagine arată ca o cascadă de apeluri fără sens, deoarece cererea externă apelează la servicii suplimentare, care apelează la alte servicii suplimentare și așa mai departe, aproape la infinit.
Culoarea verde din această diagramă arată un semicerc în care serviciile se apelează reciproc - serviciul A apelează serviciul B, serviciul B apelează serviciul C și apelează din nou serviciul A. Ca rezultat, obținem un „blocare distribuit”. O singură solicitare a creat o mie de apeluri API de rețea și, din moment ce sistemul nu avea toleranță la erori și protecție în bucle încorporate, cererea ar eșua dacă chiar și unul dintre aceste apeluri API ar eșua.
Am făcut niște matematică. Fiecare apel API avea un SLA de cel mult 150 ms și un timp de funcționare de 99,9%. O solicitare a provocat 200 de apeluri diferite și, în cel mai bun caz, pagina ar putea fi afișată în 200 x 150 ms = 30 de secunde. Desigur, acest lucru nu a fost bun. Înmulțind timpul de funcționare de 99,9% cu 200, am obținut o disponibilitate de 0%. Se pare că această arhitectură a fost sortită eșecului încă de la început.
Am întrebat dezvoltatorii cum nu au reușit să recunoască această problemă după 18 luni de muncă? S-a dovedit că au numărat SLA doar pentru codul pe care l-au rulat, dar dacă serviciul lor a apelat un alt serviciu, nu au numărat acel timp în SLA. Tot ceea ce a fost lansat într-un singur proces a aderat la valoarea de 150 ms, dar accesul la alte procese de serviciu a crescut întârzierea totală de multe ori. Prima lecție învățată a fost: „Sunteți controlul SLA-ul dvs. sau este SLA-ul controlul asupra dvs.?” În cazul nostru, a fost cea din urmă.
Următorul lucru pe care l-am descoperit a fost că știau despre conceptul de concepții greșite de calcul distribuit, formulat de Peter Deitch și James Gosling, dar au ignorat prima parte a acestuia. Se afirmă că afirmațiile „rețeaua este de încredere”, „latență zero” și „debit infinit” sunt concepții greșite. Alte concepții greșite includ afirmațiile „rețeaua este sigură”, „topologia nu se schimbă niciodată”, „există întotdeauna un singur administrator”, „costul transferului de date este zero” și „rețeaua este omogenă”.
Au făcut o greșeală pentru că și-au testat serviciul pe mașini locale și nu s-au conectat niciodată la servicii externe. La dezvoltarea locală și la utilizarea unui cache local, nu au întâlnit niciodată hopuri de rețea. În toate cele 18 luni de dezvoltare, nu s-au întrebat niciodată ce s-ar putea întâmpla dacă serviciile externe ar fi afectate.
Dacă vă uitați la limitele serviciului din imaginea anterioară, puteți vedea că toate sunt incorecte. Există o mulțime de surse care oferă sfaturi despre cum să definești limitele serviciilor și majoritatea o fac greșit, cum ar fi Microsoft în următorul diapozitiv.
Această imagine este de pe blogul MS cu tema „Cum să construiți microservicii”. Aceasta arată o aplicație web simplă, un bloc de logică de afaceri și o bază de date. Solicitarea vine direct, probabil că există un server pentru web, un server pentru afacere și unul pentru baza de date. Dacă creșteți traficul, imaginea se va schimba puțin.
Aici vine un echilibrator de încărcare pentru a distribui traficul între două servere web, un cache situat între serviciul web și logica de afaceri și un alt cache între logica de afaceri și baza de date. Aceasta este exact arhitectura pe care Bell a folosit-o pentru echilibrarea sarcinii și aplicația de implementare albastru/verde la mijlocul anilor 2000. Până la un timp, totul a funcționat bine, deoarece această schemă era destinată unei structuri monolitice.
Următoarea imagine arată cum MS recomandă trecerea de la un monolit la microservicii - pur și simplu împărțind fiecare dintre serviciile principale în microservicii separate. În timpul implementării acestei scheme, Bell a făcut o greșeală.
Și-au împărțit toate serviciile în diferite niveluri, fiecare dintre ele constând din multe servicii individuale. De exemplu, serviciul web includea microservicii pentru redarea și autentificarea conținutului, serviciul de logică de afaceri a constat din microservicii pentru procesarea comenzilor și informații despre cont, baza de date a fost împărțită într-o grămadă de microservicii cu date specializate. Atât web-ul, logica de afaceri, cât și baza de date erau servicii apatride.
Cu toate acestea, această imagine a fost complet greșită, deoarece nu a mapat nicio unitate de afaceri din afara clusterului IT al companiei. Această schemă nu a ținut cont de nicio legătură cu lumea exterioară, așa că nu era clar cum, de exemplu, să se obțină analize de afaceri de la terți. Remarc că au avut și mai multe servicii inventate pur și simplu pentru a dezvolta carierele angajaților individuali care au căutat să gestioneze cât mai mulți oameni pentru a obține mai mulți bani pentru asta.
Ei credeau că trecerea la microservicii a fost la fel de ușoară ca să luați infrastructura internă a stratului fizic N-tier și să lipiți Docker pe ea. Să aruncăm o privire la cum arată arhitectura tradițională N-tier.
Este format din 4 niveluri: nivelul interfeței cu utilizatorul UI, nivelul logicii de afaceri, nivelul de acces la date și baza de date. Mai progresiv este DDD (Domain-Driven Design), sau arhitectura orientată spre software, unde cele două niveluri medii sunt obiecte de domeniu și un depozit.
Am încercat să privesc diferite zone de schimbare, diferite domenii de responsabilitate în această arhitectură. Într-o aplicație tipică N-tier, sunt clasificate diferite zone de schimbare care pătrund structura vertical de sus în jos. Acestea sunt Catalogul, setările de configurare efectuate pe computere individuale și verificările Checkout, care au fost gestionate de echipa mea.
Particularitatea acestei scheme este că limitele acestor zone de schimbare afectează nu numai nivelul logicii de afaceri, ci se extind și la baza de date.
Să ne uităm la ce înseamnă să fii un serviciu. Există 6 proprietăți caracteristice ale definiției unui serviciu - este un software care:
- creat și utilizat de o anumită organizație;
- este responsabil pentru conținutul, prelucrarea și/sau furnizarea unui anumit tip de informații în cadrul sistemului;
- poate fi construit, implementat și rulat independent pentru a răspunde nevoilor operaționale specifice;
- comunică cu consumatorii și cu alte servicii, furnizând informații pe baza unor acorduri sau garanții contractuale;
- se protejează împotriva accesului neautorizat, iar informațiile sale împotriva pierderii;
- tratează defecțiunile în așa fel încât să nu conducă la deteriorarea informațiilor.
Toate aceste proprietăți pot fi exprimate într-un singur cuvânt „autonomie”. Serviciile funcționează independent unele de altele, îndeplinesc anumite restricții și definesc contracte pe baza cărora oamenii pot primi informațiile de care au nevoie. Nu am menționat tehnologii specifice, a căror utilizare este de la sine înțeleasă.
Acum să ne uităm la definiția microserviciilor:
- un microserviciu este de dimensiuni reduse și este conceput pentru a rezolva o problemă specifică;
- Microserviciul este autonom;
- Când se creează o arhitectură de microservicii, se folosește metafora urbanismului. Aceasta este definiția din cartea lui Sam Newman, Building Microservices.
Definiția contextului delimitat este preluată din cartea lui Eric Evans Domain-Driven Design. Acesta este un model de bază în DDD, un centru de proiectare a arhitecturii care lucrează cu modele arhitecturale volumetrice, împărțindu-le în diferite Contexte delimitate și definind în mod explicit interacțiunile dintre ele.
Mai simplu spus, un context delimitat denotă domeniul în care poate fi utilizat un anumit modul. În acest context se află un model unificat logic, care poate fi văzut, de exemplu, în domeniul dvs. de afaceri. Dacă întrebi „cine este client” personalului implicat în comenzi, vei primi o definiție, dacă îi întrebi pe cei implicați în vânzări, vei primi alta, iar executanții îți vor da o a treia definiție.
Deci, Bounded Context spune că, dacă nu putem da o definiție clară a ceea ce este un consumator al serviciilor noastre, să definim limitele în care putem vorbi despre sensul acestui termen și apoi să definim punctele de tranziție între aceste definiții diferite. Adică dacă vorbim despre un client din punctul de vedere al plasării comenzilor, asta înseamnă asta și asta, iar dacă din punct de vedere al vânzărilor, asta înseamnă asta și asta.
Următoarea definiție a unui microserviciu este încapsularea oricărui tip de operațiuni interne, prevenind „scurgerea” componentelor procesului de lucru în mediu. Urmează „definirea contractelor explicite pentru interacțiuni externe, sau comunicări externe”, care este reprezentată de ideea de contracte care se întorc din SLA. Ultima definiție este metafora unei celule, sau celulă, ceea ce înseamnă încapsularea completă a unui set de operațiuni în cadrul unui microserviciu și prezența în acesta a receptorilor de comunicare cu lumea exterioară.
Așa că le-am spus băieților de la Bell Computers: „Nu putem remedia niciunul din haosul pe care l-ați creat pentru că pur și simplu nu aveți bani să o faceți, dar vom repara un singur serviciu pentru a face totul sens." În acest moment, voi începe prin a vă spune cum am remediat singurul nostru serviciu, astfel încât să răspundă solicitărilor mai repede de 9 minute și jumătate.
22:30 min
Va continua foarte curand...
Niște reclame
Vă mulțumim că ați rămas cu noi. Vă plac articolele noastre? Vrei să vezi mai mult conținut interesant? Susține-ne plasând o comandă sau recomandând prietenilor, , un analog unic al serverelor entry-level, care a fost inventat de noi pentru tine: (disponibil cu RAID1 și RAID10, până la 24 de nuclee și până la 40 GB DDR4).
Dell R730xd de 2 ori mai ieftin în centrul de date Equinix Tier IV din Amsterdam? Numai aici in Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - de la 99 USD! Citește despre
Sursa: www.habr.com