Olete kulutanud kuid oma monoliidi mikroteenusteks ümber kujundades ja lõpuks on kõik kokku tulnud, et lüliti ümber pöörata. Lähete esimesele veebilehele... ja midagi ei juhtu. Laadite selle uuesti - ja jälle ei midagi head, sait on nii aeglane, et ei reageeri mitu minutit. Mis juhtus?
Oma kõnes viib Jimmy Bogard läbi reaalse mikroteenuse katastroofi surmajärgse uuringu. Ta näitab avastatud modelleerimis-, arendus- ja tootmisprobleeme ning seda, kuidas tema meeskond uue hajutatud monoliidi aeglaselt terve mõistuse lõplikuks pildiks muutis. Kuigi projekteerimisvigu on võimatu täielikult ära hoida, saate probleeme vähemalt projekteerimisprotsessi alguses tuvastada, et tagada lõpptootest töökindel hajutatud süsteem.
Tere kõigile, mina olen Jimmy ja täna kuulete, kuidas saate mikroteenuste loomisel vältida megakatastroofe. See on lugu ettevõttest, kus töötasin umbes poolteist aastat, et aidata vältida nende laeva kokkupõrget jäämäega. Selle loo õigeks jutustamiseks peame minema ajas tagasi ja rääkima, millest see ettevõte alguse sai ja kuidas selle IT-infrastruktuur on aja jooksul kasvanud. Katastroofis süütute nimede kaitsmiseks muutsin selle ettevõtte nime Bell Computersiks. Järgmine slaid näitab, milline nägi välja selliste ettevõtete IT-infrastruktuur 90ndate keskel. See on suure universaalse tõrketaluva HP Tandem Mainframe serveri tüüpiline arhitektuur arvuti riistvarapoe haldamiseks.
Neil oli vaja luua süsteem kõigi tellimuste, müükide, tagastuste, tootekataloogide ja kliendibaasi haldamiseks, mistõttu nad valisid sel ajal kõige levinuma suurarvuti lahenduse. See hiiglaslik süsteem sisaldas kogu teavet ettevõtte kohta, kõike võimalikku ja kõik tehingud viidi läbi selle suurarvuti kaudu. Nad hoidsid kõiki mune ühes korvis ja arvasid, et see on normaalne. Ainus, mis siia ei kuulu, on postimüügikataloogid ja tellimuste esitamine telefoni teel.
Aja jooksul muutus süsteem aina suuremaks ja sellesse kogunes tohutult palju prügi. Samuti ei ole COBOL kõige väljendusrikkam keel maailmas, nii et süsteem sai lõpuks suureks monoliitseks rämpsuks. 2000. aastaks nägid nad, et paljudel ettevõtetel on veebisaidid, mille kaudu nad korraldasid absoluutselt kogu oma äri, ja otsustasid luua oma esimese kaubandusliku dot-com veebisaidi.
Esialgne kujundus nägi päris kena välja ja koosnes tipptasemel saidist bell.com ja mitmest üksikute rakenduste alamdomeenist: catalog.bell.com, accounts.bell.com, orders.bell.com, tooteotsing search.bell. com. Iga alamdomeen kasutas ASP.Net 1.0 raamistikku ja oma andmebaase ning nad kõik rääkisid süsteemi taustaprogrammiga. Kõikide tellimuste töötlemine ja täitmine jätkus aga ühes hiiglaslikus suurarvutis, millesse jäi kogu prügi sisse, kuid esiotsa olid eraldi veebisaidid üksikute rakenduste ja eraldi andmebaasidega.
Seega nägi süsteemi ülesehitus korras ja loogiline, kuid tegelik süsteem oli selline, nagu on näidatud järgmisel slaidil.
Kõik elemendid adresseerisid kõnesid üksteisele, juurdepääsu API-dele, manustatud kolmandate osapoolte dll-e ja muud sarnast. Tihti juhtus, et versioonikontrollisüsteemid haarasid kellegi teise koodi, lükkasid selle projekti sisse ja siis läks kõik katki. MS SQL Server 2005 kasutas lingiserverite kontseptsiooni ja kuigi ma slaidil nooli ei näidanud, rääkisid kõik andmebaasid ka omavahel, sest mitmest andmebaasist saadud andmete põhjal tabelite koostamisel pole midagi halba.
Kuna neil oli nüüd süsteemi erinevate loogiliste piirkondade vahel teatud eraldus, muutusid need laiali jaotatud mustuselaikudeks, kusjuures suurim prügi jäi endiselt suurarvuti taustaprogrammi.
Naljakas oli see, et selle suurarvuti ehitasid Bell Computersi konkurendid ja seda hooldasid endiselt nende tehnilised konsultandid. Olles veendunud oma rakenduste ebarahuldavas toimimises, otsustas ettevõte neist lahti saada ja süsteemi ümber kujundada.
Olemasolev rakendus oli olnud tootmises 15 aastat, mis on ASP.Neti-põhiste rakenduste rekord. Teenus võttis vastu tellimusi üle kogu maailma ja selle ühe rakenduse aastane tulu ulatus miljardi dollarini. Märkimisväärse osa kasumist tootis veebisait bell.com. Mustadel reedetel ulatus saidi kaudu tehtud tellimuste arv mitme miljonini. Olemasolev arhitektuur aga arengut ei võimaldanud, kuna süsteemi elementide jäigad omavahelised ühendused ei võimaldanud praktiliselt teenuses muudatusi teha.
Kõige tõsisem probleem oli võimetus esitada tellimust ühest riigist, maksta selle eest teises ja saata kolmandasse, hoolimata sellest, et selline kauplemisskeem on globaalsetes ettevõtetes väga levinud. Olemasolev veebisait ei võimaldanud midagi sellist, nii et nad pidid need tellimused vastu võtma ja telefoni teel esitama. See pani ettevõtte üha enam mõtlema arhitektuuri muutmisele, eelkõige mikroteenustele üleminekule.
Nad tegid targa asja, vaadates teisi ettevõtteid, et näha, kuidas nad sarnase probleemi lahendasid. Üks neist lahendustest oli Netflixi teenuse arhitektuur, mis koosneb API ja välise andmebaasi kaudu ühendatud mikroteenustest.
Bell Computersi juhtkond otsustas teatud põhiprintsiipe järgides ehitada just sellise arhitektuuri. Esiteks kõrvaldasid nad andmete dubleerimise, kasutades jagatud andmebaasi lähenemisviisi. Andmeid ei saadetud, vastupidi, kõik, kes neid vajasid, pidid minema tsentraliseeritud allikasse. Sellele järgnes eraldatus ja autonoomia – iga teenus oli teistest sõltumatu. Nad otsustasid kasutada Web API-d absoluutselt kõige jaoks – kui tahtsite saada andmeid või teha muudatusi mõnes teises süsteemis, tehti seda kõike Web API kaudu. Viimane suur asi oli uus suurarvuti nimega "Bell on Bell" vastandina konkurentide riistvaral põhinevale "Bell" suurarvutile.
Nii ehitasid nad 18 kuu jooksul süsteemi nende põhiprintsiipide ümber ja viisid selle eeltootmiseni. Pärast nädalavahetust tööle naastes said arendajad kokku ja lülitasid sisse kõik serverid, millega uus süsteem oli ühendatud. 18 kuud tööd, sadu arendajaid, kõige moodsaim Belli riistvara – ja mitte ühtegi positiivset tulemust! See on paljudele inimestele pettumust valmistanud, sest nad on seda süsteemi oma sülearvutites korduvalt käivitanud ja kõik oli korras.
Nad olid nutikad, kui panid kogu oma raha selle probleemi lahendamisele. Paigaldasid moodsaimad lülititega serveririiulid, kasutasid gigabitist optilist kiudu, võimsaimat serveririistvara meeletu hulga RAM-iga, ühendasid selle kõik, seadistasid – ja jälle ei midagi! Siis hakkasid nad kahtlustama, et põhjuseks võivad olla ajalõpud, nii et nad läksid kõikidesse veebiseadetesse, API sätetesse ja uuendasid kogu ajalõpu konfiguratsiooni maksimaalsetele väärtustele, nii et nad ei saanud teha muud, kui istuda ja oodata, kuni midagi juhtub. saidile. Nad ootasid ja ootasid ja ootasid 9 ja pool minutit, kuni veebisait lõpuks laaditi.
Pärast seda jõudis neile kohale, et praegune olukord vajab põhjalikku analüüsi ja nad kutsusid meid. Esimese asjana saime teada, et kogu 18 arenduskuu jooksul ei loodud ainsatki tõelist “mikrot” – kõik muutus ainult suuremaks. Pärast seda hakkasime katastroofi põhjuse mõistmiseks kirjutama surmajärgset ülevaadet, mida tuntakse ka kui "kahjulikkust" või "kurvat tagasivaadet", tuntud ka kui "süüdistustorm", mis sarnaneb "ajutormiga".
Meil oli mitu vihjet, millest üks oli täielik liikluse küllastumine API kõne ajal. Kui kasutate monoliitset teenusearhitektuuri, saate kohe aru, mis täpselt valesti läks, kuna teil on üks pinu jälg, mis teatab kõigest, mis võis tõrke põhjustada. Juhul, kui hunnik teenuseid pääseb samaaegselt juurde samale API-le, ei saa jälge jälgida ainult selleks, et kasutada täiendavaid võrgu jälgimise tööriistu, nagu WireShark, tänu millele saate uurida ühte päringut ja teada saada, mis selle rakendamise ajal juhtus. Niisiis võtsime ühe veebilehe ja veetsime peaaegu 2 nädalat, et pusletükke kokku panna, sellele erinevaid kõnesid teha ja analüüsida, milleni igaüks neist viis.
Vaata seda pilti. See näitab, et üks väline päring sunnib teenust tegema palju sisekõnesid, mis naasevad. Selgub, et iga sisekõne teeb täiendavaid hüppeid, et seda päringut iseseisvalt teenindada, kuna see ei saa vajaliku teabe saamiseks mujale pöörduda. See pilt näeb välja nagu mõttetu kõnede kaskaad, kuna väline päring kutsub välja lisateenuseid, mis helistavad teistele lisateenustele ja nii edasi, peaaegu lõpmatuseni.
Selle diagrammi roheline värv näitab poolringi, kus teenused helistavad üksteisele - teenus A helistab teenusele B, teenus B helistab teenusele C ja see helistab uuesti teenusele A. Selle tulemusena saame "jaotatud ummikseisu". Üks päring tekitas tuhat võrgu API-kõnet ja kuna süsteemil polnud sisseehitatud tõrketaluvust ja silmuskaitset, siis taotlus nurjub, kui isegi üks neist API-kõnedest ebaõnnestub.
Tegime natuke matemaatikat. Iga API-kõne SLA ei ületanud 150 ms ja tööaeg oli 99,9%. Üks päring põhjustas 200 erinevat kõnet ja heal juhul sai lehekülge näidata 200 x 150 ms = 30 sekundiga. Loomulikult polnud see hea. Korrutades 99,9% tööaega 200-ga, saime saadavuse 0%. Selgub, et see arhitektuur oli algusest peale määratud läbikukkumisele.
Küsisime arendajatelt, kuidas nad seda probleemi pärast 18-kuulist tööd ei tuvastanud? Selgus, et nad lugesid ainult käitatud koodi SLA-d, kuid kui nende teenus kutsus mõne muu teenuse, ei arvestanud nad seda aega oma SLA-s. Kõik, mis ühe protsessi raames käivitati, pidas kinni 150 ms väärtusest, kuid juurdepääs teistele teenindusprotsessidele suurendas kogu viivitust kordades. Esimene õppetund oli järgmine: "Kas te kontrollite oma SLA-d või kas SLA kontrollib teid?" Meie puhul oli see viimane.
Järgmisena avastasime, et nad teadsid Peter Deitchi ja James Goslingi sõnastatud hajutatud andmetöötluse väärarusaamu, kuid nad eirasid selle esimest osa. Selles öeldakse, et väited "võrk on usaldusväärne", "null latentsusaeg" ja "lõpmatu läbilaskevõime" on väärarusaamad. Muud väärarusaamad hõlmavad väiteid "võrk on turvaline", "topoloogia ei muutu kunagi", "alati on ainult üks administraator", "andmeedastuse hind on null" ja "võrk on homogeenne".
Nad tegid vea, kuna testisid oma teenust kohalikes masinates ega ühendanud kunagi välisteenustega. Lokaalselt arendades ja kohalikku vahemälu kasutades ei kohanud nad kunagi võrguhüppeid. Kogu 18 arenduskuu jooksul ei mõelnud nad kordagi, mis võiks juhtuda, kui välisteenused oleksid mõjutatud.
Kui vaatate eelmisel pildil olevaid teenusepiire, näete, et need on kõik valed. On palju allikaid, mis annavad nõu, kuidas teenusepiire määratleda, ja enamik teeb seda valesti, nagu Microsoft järgmisel slaidil.
See pilt on MS blogist teemal “Kuidas ehitada mikroteenuseid”. See näitab lihtsat veebirakendust, äriloogika plokki ja andmebaasi. Päring tuleb otse, ilmselt on üks server veebi jaoks, üks server ettevõtte jaoks ja üks andmebaasi jaoks. Kui liiklust suurendada, muutub pilt veidi.
Siin on koormuse tasakaalustaja liikluse jaotamiseks kahe veebiserveri vahel, vahemälu, mis asub veebiteenuse ja äriloogika vahel, ning teine vahemälu äriloogika ja andmebaasi vahel. Just sellist arhitektuuri kasutas Bell 2000. aastate keskel oma koormuse tasakaalustamise ja sinise/rohelise juurutusrakenduse jaoks. Kuni mõnda aega töötas kõik hästi, kuna see skeem oli mõeldud monoliitsele struktuurile.
Järgmisel pildil on näha, kuidas MS soovitab liikuda monoliidilt mikroteenustele – lihtsalt jagada iga põhiteenus eraldi mikroteenusteks. Just selle skeemi rakendamise ajal tegi Bell vea.
Nad jagasid kõik oma teenused erinevateks tasanditeks, millest igaüks koosnes paljudest individuaalsetest teenustest. Näiteks sisaldas veebiteenus sisu renderdamise ja autentimise mikroteenuseid, äriloogikateenus koosnes tellimuste ja kontoinfo töötlemise mikroteenustest, andmebaas oli jagatud hunnikuks spetsiaalsete andmetega mikroteenusteks. Nii veeb, äriloogika kui ka andmebaas olid kodakondsuseta teenused.
See pilt oli aga täiesti vale, kuna see ei kaardistanud ühtegi äriüksust väljaspool ettevõtte IT-klastrit. See skeem ei võtnud arvesse mingit seost välismaailmaga, mistõttu polnud selge, kuidas saada näiteks kolmanda osapoole ärianalüüsi. Märgin, et neil oli ka mitmeid teenuseid, mis leiutati lihtsalt üksikute töötajate karjääri arendamiseks, kes püüdsid juhtida võimalikult palju inimesi, et selle eest rohkem raha saada.
Nad uskusid, et mikroteenustele üleminek on sama lihtne kui võtta oma sisemine N-tasandi füüsilise kihi infrastruktuur ja kleepida sellele Docker. Vaatame, milline näeb välja traditsiooniline N-tasandi arhitektuur.
See koosneb 4 tasemest: UI kasutajaliidese tase, äriloogika tase, andmete juurdepääsu tase ja andmebaas. Progressiivsem on DDD (Domain-Driven Design) ehk tarkvarale orienteeritud arhitektuur, kus kaks keskmist taset on domeeniobjektid ja hoidla.
Püüdsin selles arhitektuuris vaadelda erinevaid muutuste valdkondi, erinevaid vastutusvaldkondi. Tüüpilises N-tasandi rakenduses klassifitseeritakse erinevad muutused, mis imbuvad struktuuri vertikaalselt ülalt alla. Need on kataloog, üksikutes arvutites tehtud konfiguratsioonisätted ja Checkouti kontrollid, millega tegeles minu meeskond.
Selle skeemi eripära seisneb selles, et nende muutuste valdkondade piirid ei mõjuta mitte ainult äriloogika taset, vaid ulatuvad ka andmebaasi.
Vaatame, mida tähendab olla teenus. Teenuse definitsioonil on 6 iseloomulikku omadust – see on tarkvara, mis:
- loodud ja kasutatav konkreetse organisatsiooni poolt;
- vastutab teatud tüüpi teabe sisu, töötlemise ja/või edastamise eest süsteemis;
- saab ehitada, kasutusele võtta ja käitada iseseisvalt, et rahuldada konkreetseid tegevusvajadusi;
- suhtleb tarbijate ja muude teenustega, andes teavet lepingute või lepinguliste garantiide alusel;
- kaitseb end volitamata juurdepääsu eest ja oma teavet kaotsimineku eest;
- käsitleb tõrkeid nii, et need ei too kaasa infokahjustusi.
Kõiki neid omadusi saab väljendada ühe sõnaga "autonoomia". Teenused toimivad üksteisest sõltumatult, vastavad teatud piirangutele ja määratlevad lepingud, mille alusel inimesed saavad vajalikku teavet. Ma ei maininud konkreetseid tehnoloogiaid, mille kasutamine on iseenesestmõistetav.
Vaatame nüüd mikroteenuste määratlust:
- mikroteenus on väikese suurusega ja mõeldud ühe konkreetse probleemi lahendamiseks;
- Mikroteenus on autonoomne;
- Mikroteenuse arhitektuuri loomisel kasutatakse linnaplaneerimise metafoori. See on definitsioon Sam Newmani raamatust Building Microservices.
Piiratud konteksti definitsioon on võetud Eric Evansi raamatust Domain-Driven Design. See on DDD põhimuster, arhitektuuri disainikeskus, mis töötab mahuliste arhitektuurimudelitega, jagades need erinevatesse piiritletud kontekstidesse ja määratledes selgesõnaliselt nendevahelise vastasmõju.
Lihtsamalt öeldes tähistab piiritletud kontekst ulatust, milles konkreetset moodulit saab kasutada. Selles kontekstis on loogiliselt ühtne mudel, mida saab näha näiteks teie ärivaldkonnas. Kui küsite tellimustega seotud töötajatelt "kes on klient", saate ühe definitsiooni, kui küsite müügiga seotud isikutelt, saate teise ja esitajad annavad teile kolmanda definitsiooni.
Piiratud kontekst ütleb, et kui me ei suuda anda selget definitsiooni selle kohta, mis on meie teenuste tarbija, siis määratlegem piirid, mille raames saame selle mõiste tähendusest rääkida, ja seejärel määratlegem üleminekupunktid nende erinevate määratluste vahel. Ehk kui räägime kliendist tellimuste esitamise seisukohalt, siis see tähendab seda ja seda ja kui müügi seisukohalt, siis seda ja teist.
Järgmine mikroteenuse definitsioon on igasuguste sisemiste toimingute kapseldamine, vältides tööprotsessi komponentide “lekkimist” keskkonda. Järgmiseks tuleb "välise suhtluse või välise suhtluse selgesõnaliste lepingute määratlus", mida esindab SLA-dest naasvate lepingute idee. Viimane määratlus on raku või raku metafoor, mis tähendab operatsioonide komplekti täielikku kapseldamist mikroteenuse sees ja retseptorite olemasolu selles välismaailmaga suhtlemiseks.
Ütlesime Bell Computersi kuttidele: "Me ei saa teie tekitatud kaost parandada, sest teil pole lihtsalt raha selle tegemiseks, kuid me parandame vaid ühe teenuse, et see kõik muutuks. meel." Siinkohal räägin teile alustuseks sellest, kuidas parandasime oma ainsa teenuse nii, et see vastas päringutele kiiremini kui 9 ja pool minutit.
22:30 min
Jätkub peagi...
Natuke reklaami
Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, , algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).
Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema
Allikas: www.habr.com