Mėnesius praleidote perkurdami savo monolitą į mikropaslaugas ir pagaliau visi susirinko pakeisti jungiklį. Einate į pirmąjį tinklalapį... ir nieko neįvyksta. Perkrauni – ir vėl nieko gero, svetainė tokia lėta, kad nereaguoja kelias minutes. Kas nutiko?
Savo kalboje Jimmy Bogardas atliks „pomirtinį“ tyrimą apie realią mikro paslaugų nelaimę. Jis parodys atrastas modeliavimo, kūrimo ir gamybos problemas ir kaip jo komanda pamažu transformavo naują paskirstytą monolitą į galutinį sveiko proto vaizdą. Nors neįmanoma visiškai užkirsti kelio projektavimo klaidoms, galite bent jau anksti nustatyti problemas, kad galutinis produktas taptų patikima paskirstyta sistema.
Sveiki visi, aš esu Jimmy ir šiandien jūs išgirsite, kaip galite išvengti didelių nelaimių kuriant mikropaslaugas. Tai istorija apie įmonę, kurioje dirbau maždaug pusantrų metų, kad padėtų išvengti jų laivo susidūrimo su ledkalniu. Norėdami tinkamai papasakoti šią istoriją, turėsime grįžti į praeitį ir pakalbėti apie tai, kur ši įmonė pradėjo veikti ir kaip laikui bėgant išaugo jos IT infrastruktūra. Siekdamas apsaugoti nekaltų šios nelaimės žmonių vardus, pakeičiau šios įmonės pavadinimą į Bell Computers. Kitoje skaidrėje parodyta, kaip tokių įmonių IT infrastruktūra atrodė 90-ųjų viduryje. Tai tipinė didelio universalaus gedimams atsparaus HP Tandem Mainframe serverio, skirto kompiuterių techninės įrangos parduotuvės valdymui, architektūra.
Jiems reikėjo sukurti sistemą, kuri valdytų visus užsakymus, pardavimus, grąžinimus, produktų katalogus ir klientų bazę, todėl jie pasirinko tuo metu labiausiai paplitusią pagrindinio kompiuterio sprendimą. Šioje milžiniškoje sistemoje buvo visa informacija apie įmonę, viskas, kas įmanoma, ir kiekvienas sandoris buvo atliktas per šį pagrindinį kompiuterį. Jie laikė visus kiaušinius viename krepšyje ir manė, kad tai normalu. Vienintelis dalykas, kurio čia nėra, yra užsakymų paštu katalogai ir užsakymų pateikimas telefonu.
Laikui bėgant sistema vis didėjo ir joje susikaupė didžiulis kiekis šiukšlių. Be to, COBOL nėra pati išraiškingiausia kalba pasaulyje, todėl sistema tapo dideliu, monolitiniu šlamštu. Iki 2000 m. jie pamatė, kad daugelis įmonių turi svetaines, kuriose vykdo absoliučiai visą savo verslą, ir nusprendė sukurti savo pirmąją komercinę dot-com svetainę.
Pradinis dizainas atrodė gana gražus ir jį sudarė aukščiausio lygio svetainė bell.com ir keletas subdomenų, skirtų individualioms programoms: catalog.bell.com, accounts.bell.com, orders.bell.com, produktų paieška search.bell. com. Kiekvienas subdomenas naudojo ASP.Net 1.0 sistemą ir savo duomenų bazes, ir jie visi bendravo su sistemos užpakaline programa. Tačiau visi užsakymai ir toliau buvo apdorojami ir vykdomi viename didžiuliame pagrindiniame kompiuteryje, kuriame liko visos šiukšlės, tačiau priekinė dalis buvo atskiros svetainės su atskiromis programomis ir atskiromis duomenų bazėmis.
Taigi sistemos dizainas atrodė tvarkingas ir logiškas, tačiau tikroji sistema buvo tokia, kaip parodyta kitoje skaidrėje.
Visi elementai buvo skirti vienas kitam skambučiams, prieigai prie API, įterptųjų trečiųjų šalių dll ir panašiai. Dažnai pasitaikydavo, kad versijų valdymo sistemos paimdavo svetimą kodą, įstumdavo jį į projektą ir tada viskas sugesdavo. MS SQL Server 2005 naudojo nuorodų serverių sąvoką ir, nors aš nerodžiau rodyklių skaidrėje, kiekviena duomenų bazė taip pat kalbėjosi tarpusavyje, nes nėra nieko blogo kurti lenteles pagal duomenis, gautus iš kelių duomenų bazių.
Kadangi dabar skirtingos loginės sistemos sritys buvo atskirtos, tai tapo paskirstytomis nešvarumų dėmėmis, o didžiausia šiukšlių dalis vis dar liko pagrindinio kompiuterio sistemoje.
Juokingiausia buvo tai, kad šį pagrindinį kompiuterį pastatė „Bell Computers“ konkurentai ir jį vis dar prižiūrėjo jų techniniai konsultantai. Įsitikinusi nepatenkinamu savo programų veikimu, įmonė nusprendė jų atsikratyti ir pertvarkyti sistemą.
Esama programa buvo gaminama 15 metų, o tai yra ASP.Net pagrįstų programų rekordas. Paslauga priėmė užsakymus iš viso pasaulio, o metinės pajamos iš šios vienos programos siekė milijardą dolerių. Nemažą dalį pelno sugeneravo svetainė bell.com. Juodaisiais penktadieniais svetainėje pateiktų užsakymų skaičius siekė kelis milijonus. Tačiau esama architektūra neleido vystytis, nes standžios sistemos elementų jungtys praktiškai neleido keisti paslaugos.
Rimčiausia problema buvo nesugebėjimas pateikti užsakymą iš vienos šalies, sumokėti už jį kitoje ir išsiųsti į trečią, nepaisant to, kad tokia prekybos schema yra labai paplitusi pasaulinėse įmonėse. Esama svetainė nieko panašaus neleido, todėl jie turėjo priimti ir pateikti šiuos užsakymus telefonu. Tai paskatino įmonę vis dažniau galvoti apie architektūros keitimą, ypač apie perėjimą prie mikro paslaugų.
Jie padarė protingą dalyką, žiūrėdami į kitas įmones, kad sužinotų, kaip jos išsprendė panašią problemą. Vienas iš šių sprendimų buvo „Netflix“ paslaugų architektūra, kurią sudaro mikropaslaugos, sujungtos per API ir išorinė duomenų bazė.
„Bell Computers“ vadovybė nusprendė sukurti būtent tokią architektūrą, vadovaudamasi tam tikrais pagrindiniais principais. Pirma, jie pašalino duomenų dubliavimą naudodami bendrą duomenų bazės metodą. Jokie duomenys nebuvo išsiųsti, priešingai, visi, kuriems jų reikėjo, turėjo kreiptis į centralizuotą šaltinį. Po to sekė izoliacija ir autonomija – kiekviena tarnyba buvo nepriklausoma nuo kitų. Jie nusprendė naudoti Web API absoliučiai viskam – jei norėjote gauti duomenis ar atlikti pakeitimus kitoje sistemoje, visa tai buvo daroma per Web API. Paskutinis didelis dalykas buvo naujas pagrindinis kompiuteris, pavadintas „Bell on Bell“, o ne „Bell“ pagrindinis kompiuteris, pagrįstas konkurentų technine įranga.
Taigi per 18 mėnesių jie sukūrė sistemą pagal šiuos pagrindinius principus ir pristatė ją iki gamybos pradžios. Po savaitgalio grįžę į darbą kūrėjai susibūrė ir įjungė visus serverius, prie kurių buvo prijungta naujoji sistema. 18 mėnesių darbo, šimtai kūrėjų, moderniausia Bell techninė įranga – ir jokio teigiamo rezultato! Tai nuvylė daugybę žmonių, nes jie daug kartų paleido šią sistemą savo nešiojamuosiuose kompiuteriuose ir viskas buvo gerai.
Jie sumaniai išmetė visus savo pinigus, kad išspręstų šią problemą. Sumontavo moderniausius serverių stovus su jungikliais, panaudojo gigabitinį šviesolaidį, galingiausią serverio aparatūrą su beprotišku kiekiu RAM, visa tai sujungė, sukonfigūravo – ir vėl nieko! Tada jie pradėjo įtarti, kad priežastis gali būti skirtasis laikas, todėl jie įėjo į visus žiniatinklio nustatymus, visus API nustatymus ir atnaujino visą skirtojo laiko konfigūraciją iki maksimalių reikšmių, kad beliko tik sėdėti ir laukti, kol kažkas atsitiks. į svetainę. Jie laukė, laukė ir laukė 9 su puse minutės, kol svetainė pagaliau buvo įkelta.
Po to jiems pasirodė, kad esamą situaciją reikia nuodugniai išanalizuoti, ir jie mus pakvietė. Pirmas dalykas, kurį sužinojome, buvo tai, kad per visus 18 kūrimo mėnesių nebuvo sukurta nei vieno tikro „mikro“ – viskas tik didėjo. Po to mes pradėjome rašyti pomirtinį dokumentą, dar žinomą kaip „retrospektyva“ arba „liūdna retrospektyva“, taip pat žinoma kaip „kaltės audra“, panašiai kaip „protų audra“, kad suprastume nelaimės priežastį.
Turėjome keletą užuominų, vienas iš jų buvo visiškas srauto prisotinimas API iškvietimo metu. Kai naudojate monolitinę paslaugų architektūrą, galite iš karto suprasti, kas tiksliai nutiko, nes turite vieną dėklo pėdsaką, kuris praneša apie viską, kas galėjo sukelti gedimą. Tuo atveju, kai daugybė paslaugų vienu metu pasiekia tą pačią API, nėra jokio būdo sekti pėdsaką, išskyrus naudojant papildomus tinklo stebėjimo įrankius, tokius kaip „WireShark“, kurių dėka galite išnagrinėti vieną užklausą ir sužinoti, kas atsitiko ją įgyvendinant. Taigi mes paėmėme vieną tinklalapį ir praleidome beveik 2 savaites, kurdami dėlionės dalis, įvairiais skambučiais į jį ir analizuodami, prie ko kiekvienas iš jų veda.
Pažiūrėkite į šį paveikslėlį. Tai rodo, kad viena išorinė užklausa ragina paslaugą atlikti daug vidinių skambučių, kurie grįžta atgal. Pasirodo, kiekvienas vidinis skambutis daro papildomus šuolius, kad būtų galima savarankiškai aptarnauti šią užklausą, nes ji negali niekur kitur kreiptis, kad gautų reikiamą informaciją. Šis paveikslėlis atrodo kaip beprasmė skambučių kaskada, nes išorinė užklausa iškviečia papildomas paslaugas, kurios iškviečia kitas papildomas paslaugas ir panašiai, beveik iki begalybės.
Žalia spalva šioje diagramoje rodo puslankį, kuriame tarnybos skambina viena kitai – tarnyba A skambina tarnybai B, tarnyba B – tarnybai C, o ji vėl iškviečia paslaugą A. Dėl to gauname „paskirstytą aklavietę“. Viena užklausa sukūrė tūkstantį tinklo API iškvietimų, o kadangi sistemoje nebuvo integruotos gedimų tolerancijos ir kilpos apsaugos, užklausa nepavyktų, jei nepavyktų net vienas iš šių API iškvietimų.
Atlikome šiek tiek matematikos. Kiekvieno API skambučio SLA neviršija 150 ms ir 99,9 % veikimo laiko. Viena užklausa sukėlė 200 skirtingų skambučių, o geriausiu atveju puslapis galėjo būti parodytas per 200 x 150 ms = 30 sekundžių. Natūralu, kad tai nebuvo gerai. Padauginus 99,9 % veikimo laiką iš 200, gauname 0 % pasiekiamumą. Pasirodo, ši architektūra nuo pat pradžių buvo pasmerkta žlugti.
Paklausėme kūrėjų, kaip jiems nepavyko atpažinti šios problemos po 18 mėnesių darbo? Paaiškėjo, kad jie skaičiavo tik SLA už paleistą kodą, tačiau jei jų paslauga iškvietė kitą paslaugą, jie to laiko savo SLA neįskaičiavo. Viskas, kas buvo paleista per vieną procesą, laikėsi 150 ms vertės, tačiau prieiga prie kitų paslaugų procesų bendrą vėlavimą padidino daug kartų. Pirmoji iš to išmokta pamoka buvo tokia: „Ar jūs kontroliuojate savo SLA, ar SLA valdo jus? Mūsų atveju tai buvo pastaroji.
Kitas dalykas, kurį sužinojome, buvo tai, kad jie žinojo apie Peterio Deitcho ir Jameso Goslingo suformuluotą paskirstytų skaičiavimų klaidingų nuomonių koncepciją, tačiau jie ignoravo pirmąją jos dalį. Jame teigiama, kad teiginiai „tinklas patikimas“, „nulis delsos“ ir „begalinis pralaidumas“ yra klaidingi supratimai. Kitos klaidingos nuomonės apima teiginius „tinklas yra saugus“, „topologija niekada nesikeičia“, „visada yra tik vienas administratorius“, „duomenų perdavimo kaina lygi nuliui“ ir „tinklas yra vienalytis“.
Jie padarė klaidą, nes išbandė savo paslaugą vietiniuose įrenginiuose ir niekada neprisijungė prie išorinių paslaugų. Kurdami vietoje ir naudodami vietinę talpyklą, jie niekada nesusidūrė su tinklo šuoliais. Per visus 18 plėtros mėnesių jie nė karto nesusimąstė, kas gali nutikti, jei būtų paveiktos išorinės paslaugos.
Jei pažvelgsite į paslaugų ribas ankstesniame paveikslėlyje, pamatysite, kad jos visos neteisingos. Yra daug šaltinių, kurie pataria, kaip apibrėžti paslaugų ribas, ir dauguma tai daro neteisingai, pavyzdžiui, „Microsoft“ kitoje skaidrėje.
Ši nuotrauka yra iš MS tinklaraščio tema „Kaip sukurti mikropaslaugas“. Tai rodo paprastą žiniatinklio programą, verslo logikos bloką ir duomenų bazę. Užklausa ateina tiesiogiai, tikriausiai yra vienas serveris žiniatinkliui, vienas serveris verslui ir vienas duomenų bazei. Jei padidinsite srautą, vaizdas šiek tiek pasikeis.
Čia yra apkrovos balansavimo priemonė, skirta srautui paskirstyti tarp dviejų žiniatinklio serverių, talpykla, esanti tarp žiniatinklio paslaugos ir verslo logikos, ir kita talpykla tarp verslo logikos ir duomenų bazės. Būtent tokią architektūrą „Bell“ naudojo apkrovos balansavimui ir mėlynai žalios spalvos diegimo programai 2000-ųjų viduryje. Iki kurio laiko viskas veikė gerai, nes ši schema buvo skirta monolitinei konstrukcijai.
Toliau pateiktame paveikslėlyje parodyta, kaip MS rekomenduoja pereiti nuo monolito prie mikropaslaugų – tiesiog padalinkite kiekvieną pagrindinę paslaugą į atskiras mikropaslaugas. Būtent įgyvendindamas šią schemą Bellas padarė klaidą.
Jie suskirstė visas savo paslaugas į skirtingus lygius, kurių kiekvieną sudarė daug atskirų paslaugų. Pavyzdžiui, žiniatinklio paslauga apėmė mikropaslaugas, skirtas turinio teikimui ir autentifikavimui, verslo logikos paslaugą sudarė mikropaslaugos, skirtos užsakymams ir sąskaitos informacijai apdoroti, duomenų bazė buvo padalinta į mikropaslaugų su specializuotais duomenimis krūvą. Tiek žiniatinklis, tiek verslo logika, tiek duomenų bazė buvo paslaugos be pilietybės.
Tačiau šis paveikslas buvo visiškai klaidingas, nes jis nenurodė jokių verslo padalinių, nepriklausančių įmonės IT klasteriui. Šioje schemoje nebuvo atsižvelgta į jokį ryšį su išoriniu pasauliu, todėl nebuvo aišku, kaip, pavyzdžiui, gauti trečiosios šalies verslo analizę. Atkreipiu dėmesį, kad jie taip pat turėjo keletą paslaugų, sugalvotų tiesiog tam, kad plėtotų pavienių darbuotojų, kurie siekė valdyti kuo daugiau žmonių, kad gautų už tai daugiau pinigų, karjerą.
Jie tikėjo, kad pereiti prie mikropaslaugų buvo taip paprasta, kaip paimti vidinę N pakopos fizinio lygmens infrastruktūrą ir prie jos priklijuoti „Docker“. Pažiūrėkime, kaip atrodo tradicinė N pakopos architektūra.
Jį sudaro 4 lygiai: UI vartotojo sąsajos lygis, verslo logikos lygis, duomenų prieigos lygis ir duomenų bazė. Progresyvesnė yra DDD (Domain-Driven Design) arba į programinę įrangą orientuota architektūra, kur du viduriniai lygiai yra domeno objektai ir saugykla.
Stengiausi pažvelgti į skirtingas pokyčių sritis, skirtingas atsakomybės sritis šioje architektūroje. Įprastoje N pakopos programoje klasifikuojamos skirtingos pokyčių sritys, kurios persmelkia konstrukciją vertikaliai iš viršaus į apačią. Tai yra katalogo, konfigūracijos nustatymai, atlikti atskiruose kompiuteriuose, ir patikros patikros, kurias atliko mano komanda.
Šios schemos ypatumas yra tas, kad šių pokyčių sričių ribos veikia ne tik verslo logikos lygmenį, bet ir apima duomenų bazę.
Pažiūrėkime, ką reiškia būti paslauga. Yra 6 būdingos paslaugos apibrėžimo savybės – tai programinė įranga, kuri:
- sukurta ir naudojama konkrečios organizacijos;
- yra atsakingas už tam tikros rūšies informacijos turinį, apdorojimą ir (arba) teikimą sistemoje;
- gali būti pastatytas, įdiegtas ir eksploatuojamas savarankiškai, kad atitiktų konkrečius veiklos poreikius;
- bendrauja su vartotojais ir kitomis tarnybomis, teikdamas informaciją pagal susitarimus ar sutartines garantijas;
- apsaugo save nuo neteisėtos prieigos ir savo informaciją nuo praradimo;
- gedimus tvarko taip, kad jie nesugadintų informacijos.
Visas šias savybes galima išreikšti vienu žodžiu „autonomija“. Paslaugos veikia nepriklausomai viena nuo kitos, atitinka tam tikrus apribojimus, apibrėžia sutartis, kurių pagrindu žmonės gali gauti jiems reikalingą informaciją. Konkrečių technologijų, kurių naudojimas yra savaime suprantamas, nepaminėjau.
Dabar pažvelkime į mikropaslaugų apibrėžimą:
- mikropaslauga yra mažo dydžio ir skirta vienai konkrečiai problemai išspręsti;
- Mikropaslauga yra autonomiška;
- Kuriant mikropaslaugų architektūrą, naudojama miesto planavimo metafora. Tai yra Samo Newmano knygos „Building Microservices“ apibrėžimas.
Apriboto konteksto apibrėžimas paimtas iš Erico Evanso knygos Domain-Driven Design. Tai yra pagrindinis DDD modelis, architektūros projektavimo centras, kuris dirba su tūriniais architektūriniais modeliais, suskirstydamas juos į skirtingus ribotus kontekstus ir aiškiai apibrėždamas jų sąveiką.
Paprasčiau tariant, ribotas kontekstas nurodo apimtį, kurioje gali būti naudojamas konkretus modulis. Šiame kontekste yra logiškai vieningas modelis, kurį galima pamatyti, pavyzdžiui, jūsų verslo srityje. Jei užsakymuose dalyvaujančio personalo paklausite „kas yra klientas“, gausite vieną apibrėžimą, jei paklausite dalyvaujančių pardavimuose, gausite kitą, o atlikėjai pateiks trečią apibrėžimą.
Taigi, „Bounded Context“ sako, kad jei negalime aiškiai apibrėžti, kas yra mūsų paslaugų vartotojas, apibrėžkime ribas, per kurias galime kalbėti apie šio termino reikšmę, ir tada apibrėžkime perėjimo tarp šių skirtingų apibrėžimų taškus. Tai yra, jei mes kalbame apie klientą iš užsakymų pateikimo pusės, tai reiškia tą ir tą, o jei iš pardavimų, tai reiškia šį bei tą.
Kitas mikropaslaugos apibrėžimas yra bet kokios rūšies vidinių operacijų įkapsuliavimas, užkertantis kelią darbo proceso komponentų „nutekėjimui“ į aplinką. Toliau pateikiamas „aiškių sutarčių, skirtų išorinei sąveikai ar išorinei komunikacijai, apibrėžimas“, kurį atspindi sutarčių, grįžtančių iš SLA, idėja. Paskutinis apibrėžimas yra ląstelės arba ląstelės metafora, kuri reiškia visišką operacijų rinkinio įterpimą į mikropaslaugą ir joje esančių receptorių, skirtų ryšiui su išoriniu pasauliu, buvimą.
Taigi mes pasakėme „Bell Computers“ vaikinams: „Negalime sutvarkyti jokio chaoso, kurį sukūrėte, nes jūs tiesiog neturite tam pinigų, bet mes sutvarkysime tik vieną paslaugą, kad visa tai padarytume. jausmas“. Pradėsiu nuo to, kaip sutvarkėme vienintelę paslaugą, kad ji į užklausas būtų atsakyta greičiau nei per 9 su puse minutės.
22:30 min
Tęsinys bus labai greitai...
Šiek tiek reklamos
Dėkojame, kad likote su mumis. Ar jums patinka mūsų straipsniai? Norite pamatyti įdomesnio turinio? Palaikykite mus pateikdami užsakymą ar rekomenduodami draugams, , unikalus pradinio lygio serverių analogas, kurį mes sugalvojome jums: (galima su RAID1 ir RAID10, iki 24 branduolių ir iki 40 GB DDR4).
„Dell R730xd“ 2 kartus pigiau „Equinix Tier IV“ duomenų centre Amsterdame? Tik čia Olandijoje! „Dell R420“ – 2 x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB – nuo 99 USD! Skaityti apie
Šaltinis: www.habr.com