Olet käyttänyt kuukausia suunnittelemalla monoliittisi uudelleen mikropalveluiksi, ja vihdoin kaikki ovat kokoontuneet kääntämään kytkintä. Menet ensimmäiselle verkkosivulle... eikä mitään tapahdu. Lataat sen uudelleen - eikä taaskaan mitään hyvää, sivusto on niin hidas, että se ei vastaa useaan minuuttiin. Mitä tapahtui?
Puheessaan Jimmy Bogard suorittaa "post mortemin" tosielämän mikropalvelukatastrofista. Hän näyttää löytämänsä mallinnus-, kehitys- ja tuotantoongelmat ja kuinka hänen tiiminsä muutti hitaasti uuden hajautetun monoliitin lopulliseksi mielenterveyden kuvaksi. Vaikka suunnitteluvirheitä on mahdotonta estää kokonaan, voit ainakin tunnistaa ongelmat suunnitteluprosessin varhaisessa vaiheessa varmistaaksesi, että lopputuotteesta tulee luotettava hajautettu järjestelmä.
Hei kaikille, olen Jimmy ja tänään kuulet kuinka voit välttää mega-katastrofit mikropalveluita rakentaessasi. Tämä on tarina yrityksestä, jossa työskentelin noin puolitoista vuotta auttaakseni estämään heidän aluksensa törmäämästä jäävuoreen. Kerroksemme tämän tarinan oikein, meidän on palattava ajassa taaksepäin ja puhuttava siitä, mistä tämä yritys sai alkunsa ja kuinka sen IT-infrastruktuuri on kasvanut ajan myötä. Olen vaihtanut tämän yrityksen nimen Bell Computersiksi suojellakseni tässä katastrofissa viattomien nimiä. Seuraava dia näyttää, miltä tällaisten yritysten IT-infrastruktuuri näytti 90-luvun puolivälissä. Tämä on tyypillinen arkkitehtuuri suurelle yleiselle, vikasietoiselle HP Tandem Mainframe -palvelimelle tietokonelaitteistokaupan toimintaan.
Heidän täytyi rakentaa järjestelmä hallitakseen kaikkia tilauksia, myyntiä, palautuksia, tuoteluetteloita ja asiakaskuntaa, joten he valitsivat tuolloin yleisimmän keskustietokoneratkaisun. Tämä jättiläinen järjestelmä sisälsi kaiken tiedon yrityksestä, kaiken mahdollisen, ja kaikki tapahtumat tehtiin tämän keskuskoneen kautta. He pitivät kaikki munansa samassa korissa ja pitivät sitä normaalina. Ainoa asia, joka ei sisälly tähän, on postimyyntiluettelot ja tilausten tekeminen puhelimitse.
Ajan myötä järjestelmästä tuli suurempi ja suurempi, ja siihen kertyi valtava määrä roskia. COBOL ei myöskään ole maailman ilmeikkäin kieli, joten järjestelmästä tuli iso, monoliittinen roskapala. Vuoteen 2000 mennessä he huomasivat, että monilla yrityksillä oli verkkosivustoja, joiden kautta ne harjoittivat kaikkea liiketoimintaansa, ja päättivät rakentaa ensimmäisen kaupallisen dot-com-verkkosivustonsa.
Alkuperäinen suunnittelu näytti melko hyvältä ja koostui huipputason sivustosta bell.com ja useista aliverkkotunnuksista yksittäisille sovelluksille: catalog.bell.com, accounts.bell.com, orders.bell.com, tuotehaku search.bell. com. Jokainen aliverkkotunnus käytti ASP.Net 1.0 -kehystä ja omia tietokantojaan, ja ne kaikki keskustelivat järjestelmän taustajärjestelmän kanssa. Kaikki tilaukset kuitenkin jatkoivat käsittelyä ja toteutusta yhdessä valtavassa keskuskoneessa, johon kaikki roskat jäivät, mutta käyttöliittymä oli erilliset verkkosivustot yksittäisillä sovelluksilla ja erillisillä tietokannoilla.
Joten järjestelmän suunnittelu näytti järjestetyltä ja loogiselta, mutta varsinainen järjestelmä oli seuraavan dian mukainen.
Kaikki elementit osoittivat kutsuja toisilleen, käyttivät sovellusliittymiä, sulautettuja kolmannen osapuolen dll-tiedostoja ja vastaavia. Usein kävi niin, että versionhallintajärjestelmät nappasivat jonkun toisen koodin, työnsivät sen projektin sisään ja sitten kaikki meni rikki. MS SQL Server 2005 käytti linkkipalvelimien käsitettä, ja vaikka en näyttänytkään nuolia diassa, niin jokainen tietokanta myös puhui keskenään, koska ei ole mitään vikaa taulukoiden rakentamisessa useista tietokannoista saatujen tietojen perusteella .
Koska heillä oli nyt jonkin verran eroa järjestelmän eri loogisten alueiden välillä, tästä tuli hajallaan olevia likapilkkuja, joista suurin roskat jäi edelleen keskuskoneen taustajärjestelmään.
Hassua oli, että tämän keskuskoneen rakensivat Bell Computersin kilpailijat ja sitä ylläpisivät edelleen heidän tekniset konsulttinsa. Yritys oli vakuuttunut sovellustensa epätyydyttävästä suorituskyvystä ja päätti luopua niistä ja suunnitella järjestelmän uudelleen.
Nykyinen sovellus oli ollut tuotannossa 15 vuotta, mikä on ASP.Net-pohjaisten sovellusten ennätys. Palvelu vastaanotti tilauksia kaikkialta maailmasta, ja tämän yksittäisen sovelluksen vuositulot nousivat miljardiin dollariin. Merkittävä osa voitosta tuli bell.com-sivustolta. Black Fridayna sivuston kautta tehtyjen tilausten määrä nousi useisiin miljooniin. Nykyinen arkkitehtuuri ei kuitenkaan mahdollistanut kehitystä, koska järjestelmäelementtien jäykät yhteenliitännät eivät käytännössä mahdollistaneet muutosten tekemistä palveluun.
Vakavin ongelma oli kyvyttömyys tehdä tilausta yhdestä maasta, maksaa siitä toisessa ja lähettää se kolmanteen huolimatta siitä, että tällainen kaupankäyntijärjestelmä on hyvin yleinen globaaleissa yrityksissä. Nykyinen verkkosivusto ei sallinut mitään tällaista, joten heidän piti hyväksyä ja tehdä nämä tilaukset puhelimitse. Tämä johti siihen, että yritys pohtii yhä enemmän arkkitehtuurin muuttamista, erityisesti siirtymistä mikropalveluihin.
He tekivät älykkään asian katsomalla muita yrityksiä nähdäkseen, kuinka he olivat ratkaisseet samanlaisen ongelman. Yksi näistä ratkaisuista oli Netflix-palveluarkkitehtuuri, joka koostuu API:n kautta yhdistetyistä mikropalveluista ja ulkoisesta tietokannasta.
Bell Computersin johto päätti rakentaa juuri tällaisen arkkitehtuurin tiettyjä perusperiaatteita noudattaen. Ensinnäkin he eliminoivat tietojen päällekkäisyyden käyttämällä jaettua tietokantalähestymistapaa. Tietoja ei lähetetty, päinvastoin kaikkien sitä tarvittavien piti mennä keskitetylle lähteelle. Tätä seurasi eristäytyminen ja autonomia - jokainen palvelu oli riippumaton muista. He päättivät käyttää Web API:ta ehdottomasti kaikkeen - jos halusit saada tietoja tai tehdä muutoksia toiseen järjestelmään, se tehtiin Web API:n kautta. Viimeinen iso asia oli uusi keskuskone nimeltä "Bell on Bell" verrattuna kilpailijoiden laitteistoihin perustuvaan "Bell"-mainframeen.
Joten 18 kuukauden aikana he rakensivat järjestelmän näiden ydinperiaatteiden ympärille ja toivat sen esituotantoon. Palattuaan töihin viikonlopun jälkeen, kehittäjät kokoontuivat ja käynnistivät kaikki palvelimet, joihin uusi järjestelmä oli kytketty. 18 kuukautta työtä, satoja kehittäjiä, nykyaikaisin Bell-laitteisto - eikä positiivista tulosta! Tämä on pettynyt moniin ihmisiin, koska he ovat käyttäneet tätä järjestelmää kannettavissa tietokoneissaan monta kertaa ja kaikki oli hyvin.
He olivat fiksuja heittäessään kaikki rahansa tämän ongelman ratkaisemiseen. He asensivat nykyaikaisimmat palvelintelineet kytkimillä, käyttivät gigabitin optista kuitua, tehokkain palvelinlaitteisto mielettömällä määrällä RAM-muistia, yhdistivät kaiken, konfiguroivat - ja taas ei mitään! Sitten he alkoivat epäillä, että syy saattaa olla aikakatkaisut, joten he menivät kaikkiin verkkoasetuksiin, kaikkiin API-asetuksiin ja päivittivät koko aikakatkaisukokoonpanon maksimiarvoihin, jotta he eivät voineet muuta kuin istua ja odottaa, että jotain tapahtuisi. sivustolle. He odottivat ja odottivat ja odottivat 9 ja puoli minuuttia, kunnes verkkosivusto lopulta latautui.
Sen jälkeen heille valkeni, että nykyinen tilanne vaatii perusteellisen analyysin, ja he kutsuivat meidät. Ensimmäinen asia, jonka saimme selville, oli, että kaikkien 18 kuukauden kehitystyön aikana ei luotu yhtään todellista "mikroa" - kaikki vain kasvoi. Tämän jälkeen aloimme kirjoittaa post mortemia, joka tunnetaan myös nimellä "regretrospective" tai "sad retrospective", joka tunnetaan myös "syymyrskynä", joka on samanlainen kuin "aivomyrsky", ymmärtääksemme katastrofin syyn.
Meillä oli useita vihjeitä, joista yksi oli täydellinen liikenteen kyllästyminen API-kutsun aikaan. Kun käytät monoliittista palveluarkkitehtuuria, voit heti ymmärtää, mikä meni pieleen, koska sinulla on yksi pinojälki, joka raportoi kaiken, mikä on voinut aiheuttaa vian. Siinä tapauksessa, että joukko palveluita käyttää samanaikaisesti samaa API:a, jälkiä ei voi seurata vain käyttämällä muita verkonvalvontatyökaluja, kuten WireShark, jonka ansiosta voit tarkastella yksittäistä pyyntöä ja selvittää, mitä tapahtui sen toteutuksen aikana. Joten otimme yhden web-sivun ja käytimme melkein 2 viikkoa kokoamalla palapelin palasia, soittaen sille erilaisia kutsuja ja analysoimalla, mihin kukin niistä johti.
Katso tätä kuvaa. Se osoittaa, että yksi ulkoinen pyyntö kehottaa palvelua soittamaan useita sisäisiä puheluita, jotka palaavat takaisin. Osoittautuu, että jokainen sisäinen puhelu tekee lisähyppejä voidakseen palvella tätä pyyntöä itsenäisesti, koska se ei voi kääntyä minnekään muualle saadakseen tarvittavia tietoja. Tämä kuva näyttää merkityksettömältä puhelujen kaskadilta, koska ulkoinen pyyntö kutsuu lisäpalveluita, jotka kutsuvat muita lisäpalveluita ja niin edelleen, melkein loputtomiin.
Vihreä väri tässä kaaviossa näyttää puoliympyrän, jossa palvelut soittavat toisilleen - palvelu A soittaa palveluun B, palvelu B soittaa palveluun C ja se soittaa uudelleen palveluun A. Tuloksena saadaan "hajautunut lukkiutuma". Yksi pyyntö loi tuhat verkko-API-kutsua, ja koska järjestelmässä ei ollut sisäänrakennettua vikasietoisuutta ja silmukkasuojausta, pyyntö epäonnistuisi, jos edes yksi näistä API-kutsuista epäonnistuisi.
Teimme vähän matematiikkaa. Jokaisen API-kutsun SLA oli korkeintaan 150 ms ja käyttöaika 99,9 %. Yksi pyyntö aiheutti 200 erilaista puhelua, ja parhaassa tapauksessa sivu pystyttiin näyttämään 200 x 150 ms = 30 sekunnissa. Luonnollisesti tämä ei ollut hyvä. Kertomalla 99,9 %:n käyttöaika 200:lla, saimme 0 %:n käytettävyyden. Osoittautuu, että tämä arkkitehtuuri oli tuomittu epäonnistumaan alusta alkaen.
Kysyimme kehittäjiltä, kuinka he eivät tunnistaneet tätä ongelmaa 18 kuukauden työn jälkeen? Kävi ilmi, että he laskivat vain suorittamansa koodin SLA:n, mutta jos heidän palvelunsa kutsui toista palvelua, he eivät laskeneet sitä aikaa SLA:ssaan. Kaikki yhden prosessin sisällä käynnistetty piti 150 ms:n arvoa, mutta pääsy muihin palveluprosesseihin moninkertaisti kokonaisviiveen. Ensimmäinen oppitunti oli: "Hallitsetko SLA-sopimustasi vai hallitseeko SLA sinua?" Meidän tapauksessamme se oli jälkimmäinen.
Seuraavaksi havaitsimme, että he tiesivät Peter Deitchin ja James Goslingin muotoilemasta hajautetun laskennan väärinkäsityksestä, mutta he jättivät huomiotta sen ensimmäisen osan. Siinä todetaan, että väitteet "verkko on luotettava", "nollaviive" ja "rajaton suoritusteho" ovat väärinkäsityksiä. Muita väärinkäsityksiä ovat väitteet "verkko on turvallinen", "topologia ei muutu koskaan", "aina on vain yksi ylläpitäjä", "tiedonsiirron hinta on nolla" ja "verkko on homogeeninen".
He tekivät virheen, koska he testasivat palveluaan paikallisilla koneilla eivätkä koskaan ottaneet yhteyttä ulkoisiin palveluihin. Paikallisesti kehitettäessä ja paikallista välimuistia käytettäessä he eivät koskaan kohdanneet verkon hyppyjä. Kaiken 18 kuukauden kehitystyön aikana he eivät koskaan miettineet, mitä voisi tapahtua, jos ulkoiset palvelut vaikuttaisivat.
Jos katsot edellisen kuvan palvelurajoja, voit nähdä, että ne ovat kaikki vääriä. On monia lähteitä, jotka neuvovat palvelurajojen määrittämisessä, ja useimmat tekevät sen väärin, kuten Microsoft seuraavassa diassa.
Tämä kuva on MS-blogista aiheesta "Mikropalveluiden rakentaminen". Tämä näyttää yksinkertaisen verkkosovelluksen, liiketoimintalogiikan lohkon ja tietokannan. Pyyntö tulee suoraan, luultavasti on yksi palvelin verkkoa varten, yksi palvelin yritykselle ja yksi tietokantaa varten. Jos lisäät liikennettä, kuva muuttuu hieman.
Tässä tulee kuormituksen tasapainotin, joka jakaa liikenteen kahden verkkopalvelimen välillä, välimuisti, joka sijaitsee verkkopalvelun ja liiketoimintalogiikan välillä, ja toinen välimuisti liiketoimintalogiikan ja tietokannan välillä. Juuri tätä arkkitehtuuria Bell käytti kuormituksen tasapainottamisessa ja sinisen/vihreän käyttöönottosovelluksessa 2000-luvun puolivälissä. Jonkin aikaa kaikki toimi hyvin, koska tämä järjestelmä oli tarkoitettu monoliittiselle rakenteelle.
Seuraava kuva näyttää, kuinka MS suosittelee siirtymistä monoliitista mikropalveluihin - yksinkertaisesti jakaa jokainen pääpalvelu erillisiksi mikropalveluihin. Tämän järjestelmän toteuttamisen aikana Bell teki virheen.
He jakoivat kaikki palvelunsa eri tasoihin, joista jokainen koostui useista yksittäisistä palveluista. Esimerkiksi verkkopalvelu sisälsi mikropalvelut sisällön renderöimiseen ja autentikointiin, liiketoimintalogiikkapalvelu koostui tilausten ja tilitietojen käsittelyyn tarkoitetuista mikropalveluista, tietokanta oli jaettu nippuun mikropalveluihin erikoistuneella tiedolla. Sekä verkko, liiketoimintalogiikka että tietokanta olivat valtiottomia palveluita.
Tämä kuva oli kuitenkin täysin väärä, koska se ei kartoittanut yhtään liiketoimintayksikköä yrityksen IT-klusterin ulkopuolelta. Tämä järjestelmä ei ottanut huomioon mitään yhteyttä ulkomaailmaan, joten ei ollut selvää, kuinka esimerkiksi saada kolmannen osapuolen yritysanalytiikkaa. Huomaan, että heillä oli myös useita palveluita, jotka oli keksitty yksinkertaisesti kehittämään yksittäisten työntekijöiden uraa, jotka pyrkivät johtamaan mahdollisimman monia ihmisiä saadakseen siitä enemmän rahaa.
He uskoivat, että siirtyminen mikropalveluihin oli yhtä helppoa kuin ottaa heidän sisäisen N-tason fyysisen kerroksen infrastruktuurinsa ja kiinnittää Dockerin siihen. Katsotaanpa, miltä perinteinen N-tason arkkitehtuuri näyttää.
Se koostuu 4 tasosta: käyttöliittymän käyttöliittymätasosta, liiketoimintalogiikkatasosta, tietojen käyttöoikeustasosta ja tietokannasta. Edistyksellisempi on DDD (Domain-Driven Design) tai ohjelmistokeskeinen arkkitehtuuri, jossa kaksi keskitasoa ovat toimialueen objektit ja arkisto.
Yritin tarkastella eri muutosalueita, erilaisia vastuualueita tässä arkkitehtuurissa. Tyypillisessä N-tason sovelluksessa luokitellaan erilaiset muutosalueet, jotka läpäisevät rakenteen pystysuunnassa ylhäältä alas. Nämä ovat Katalogi, yksittäisissä tietokoneissa tehdyt konfigurointiasetukset ja Checkout-tarkistukset, jotka tiimini käsitteli.
Tämän mallin erikoisuus on, että näiden muutosalueiden rajat eivät vaikuta vain liiketoimintalogiikkatasoon, vaan ulottuvat myös tietokantaan.
Katsotaanpa, mitä palvelu tarkoittaa. Palvelun määritelmällä on 6 ominaista ominaisuutta - se on ohjelmisto, joka:
- tietyn organisaation luoma ja käyttämä;
- on vastuussa tietyntyyppisten tietojen sisällöstä, käsittelystä ja/tai toimittamisesta järjestelmässä;
- voidaan rakentaa, ottaa käyttöön ja käyttää itsenäisesti vastaamaan erityisiä toiminnallisia tarpeita;
- kommunikoi kuluttajien ja muiden palvelujen kanssa tarjoamalla tietoa sopimusten tai sopimustakuiden perusteella;
- suojaa itseään luvattomalta käytöltä ja tietojaan katoamiselta;
- käsittelee vikoja siten, että ne eivät aiheuta tietovaurioita.
Kaikki nämä ominaisuudet voidaan ilmaista yhdellä sanalla "autonomia". Palvelut toimivat toisistaan riippumatta, täyttävät tietyt rajoitukset ja määrittelevät sopimuksia, joiden perusteella ihmiset voivat saada tarvitsemansa tiedon. En maininnut tiettyjä teknologioita, joiden käyttö on itsestään selvää.
Katsotaanpa nyt mikropalvelujen määritelmää:
- mikropalvelu on kooltaan pieni ja suunniteltu ratkaisemaan yksi tietty ongelma;
- Mikropalvelu on itsenäinen;
- Mikropalveluarkkitehtuuria luotaessa käytetään kaupunkisuunnittelun metaforaa. Tämä on määritelmä Sam Newmanin kirjasta Building Microservices.
Bounded Contextin määritelmä on otettu Eric Evansin kirjasta Domain-Driven Design. Tämä on ydinmalli DDD:ssä, arkkitehtuurin suunnittelukeskuksessa, joka työskentelee volumetristen arkkitehtonisten mallien kanssa jakaen ne erilaisiin rajattuihin konteksteihin ja määrittelemällä selkeästi niiden väliset vuorovaikutukset.
Yksinkertaisesti sanottuna rajattu konteksti ilmaisee laajuuden, jossa tiettyä moduulia voidaan käyttää. Tässä yhteydessä on loogisesti yhtenäinen malli, joka näkyy esimerkiksi yrityksesi toimialueella. Jos kysyt "kuka on asiakas" tilauksiin osallistuvalta henkilökunnalta, saat yhden määritelmän, jos kysyt myyntiin osallistuvilta, saat toisen ja esiintyjät antavat sinulle kolmannen määritelmän.
Bounded Context sanoo siis, että jos emme voi antaa selkeää määritelmää palveluidemme kuluttajalle, määritellään rajat, joiden sisällä voimme puhua tämän termin merkityksestä, ja sitten määritellään siirtymäkohdat näiden eri määritelmien välillä. Eli jos puhutaan asiakkaasta tilausten tekemisen näkökulmasta, tämä tarkoittaa sitä ja tätä, ja jos myynnin kannalta tämä tarkoittaa sitä ja tätä.
Seuraava mikropalvelun määritelmä on kaikenlaisten sisäisten toimintojen kapselointi, joka estää työprosessin komponenttien ”vuodot” ympäristöön. Seuraavaksi tulee "ulkoisen vuorovaikutuksen tai ulkoisen viestinnän eksplisiittisten sopimusten määritelmä", jota edustaa ajatus SLA-sopimuksista palaavista sopimuksista. Viimeinen määritelmä on metafora solusta tai solusta, joka tarkoittaa toimintosarjan täydellistä kapselointia mikropalvelun sisällä ja reseptorien läsnäoloa siinä, jotta se voi olla yhteydessä ulkomaailmaan.
Joten sanoimme Bell Computersin kavereille: "Emme voi korjata mitään luomaasi kaaosta, koska teillä ei vain ole rahaa tehdä sitä, mutta korjaamme vain yhden palvelun, jotta kaikki saadaan aikaan. järkeä.” Tässä vaiheessa aloitan kertomalla, kuinka korjasimme ainoan palvelumme niin, että se vastasi pyyntöihin nopeammin kuin 9 ja puoli minuuttia.
22:30 min
Jatkuu pian...
Jotain mainontaa
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com