Hei kaikki! Meillä on mahtavia uutisia, OTUS käynnistää kurssin uudelleen kesäkuussa , jonka yhteydessä jaamme perinteisesti hyödyllistä materiaalia kanssasi.
Jos olet törmännyt tähän koko mikropalvelutarinaan ilman kontekstia, saisit anteeksi, jos ajattelet sitä hieman oudolta. Sovelluksen jakaminen verkon kautta yhdistettyihin fragmentteihin tarkoittaa välttämättä monimutkaisten vikasietotilojen lisäämistä tuloksena olevaan hajautettuun järjestelmään.
Vaikka tämä lähestymistapa edellyttää jakamista moniin itsenäisiin palveluihin, lopputavoite on paljon enemmän kuin vain näiden palvelujen suorittaminen eri koneissa. Puhumme tässä vuorovaikutuksesta ulkomaailman kanssa, joka myös jakautuu olemukseltaan. Ei teknisessä mielessä, vaan pikemminkin ekosysteemin mielessä, joka koostuu monista ihmisistä, ryhmistä, ohjelmista ja jokaisen näistä osista on tehtävä tehtävänsä tavalla tai toisella.
Esimerkiksi yritykset ovat joukko hajautettuja järjestelmiä, jotka yhdessä edistävät jonkin tavoitteen saavuttamista. Olemme jättäneet tämän tosiasian huomiotta vuosikymmeniä ja yrittäneet saavuttaa yhtenäistämistä FTP-siirroilla tai yritysintegraatiotyökaluilla keskittyen samalla omiin erillisiin tavoitteisiimme. Mutta palveluiden myötä kaikki on muuttunut. Palvelut ovat auttaneet meitä katsomaan horisontin taakse ja näkemään yhdessä toimivien, toisistaan riippuvaisten ohjelmien maailman. Onnistuneen työskentelyn kannalta on kuitenkin välttämätöntä tunnistaa ja suunnitella kaksi pohjimmiltaan erilaista maailmaa: ulkoinen maailma, jossa elämme monien muiden palveluiden ekosysteemissä, ja henkilökohtainen, sisäinen maailmamme, jossa hallitsemme yksin.
Tällainen hajallaan oleva maailma on erilainen kuin se, jossa olemme kasvaneet ja johon olemme tottuneet. Perinteisen monoliittisen arkkitehtuurin rakentamisen periaatteet eivät kestä kritiikkiä. Näiden järjestelmien oikea saaminen on siis muutakin kuin hienon taulukaavion tai hienon konseptin todisteen luomista. Ajatuksena on, että tällainen järjestelmä toimii menestyksekkäästi pitkään. Onneksi palvelut ovat olleet olemassa jo jonkin aikaa, vaikka ne näyttävätkin erilaisilta. edelleen ajankohtainen, jopa maustettuna Dockerilla, Kubernetesilla ja hieman nuhjuisilla hipsteripartoilla.
Joten tänään katsomme, miten säännöt ovat muuttuneet, miksi meidän on harkittava uudelleen lähestymistapaamme palveluihin ja niiden toisilleen välittämään dataan ja miksi tarvitsemme siihen täysin erilaisen työkalupakin.
Kapselointi ei aina ole ystäväsi
Mikropalvelut voivat toimia toisistaan riippumatta. Juuri tämä ominaisuus antaa heille suurimman arvon. Tämä sama kiinteistö mahdollistaa palvelujen skaalaamisen ja kasvun. Ei niinkään skaalautumisen kannalta kvadrillioihin käyttäjiin tai petatavuihin dataa (vaikka ne voivat auttaa myös tässä), vaan ihmisten skaalauksessa, kun tiimit ja organisaatiot kasvavat jatkuvasti.
Itsenäisyys on kuitenkin kaksiteräinen miekka. Eli itse palvelu pyörii helposti ja luonnollisesti. Mutta jos toiminto toteutetaan palvelun sisällä, joka vaatii toisen palvelun, joudumme tekemään muutoksia molempiin palveluihin lähes samanaikaisesti. Monoliitissa tämä on helppo tehdä, teet vain muutoksen ja lähetät sen julkaisuun, mutta itsenäisten palveluiden synkronoinnin tapauksessa tulee enemmän ongelmia. Tiimien välinen koordinointi ja julkaisujaksot tuhoavat joustavuuden.
Osana vakiolähestymistapaa he yksinkertaisesti yrittävät välttää ärsyttäviä päästä päähän muutoksia jakamalla toiminnallisuuden selvästi palveluiden välillä. Kertakirjautumispalvelu voi olla hyvä esimerkki tästä. Sillä on hyvin määritelty rooli, joka erottaa sen muista palveluista. Tämä selkeä erottelu tarkoittaa, että maailmassa, jossa ympärillä oleville palveluille vaatimukset muuttuvat nopeasti, SSO ei todennäköisesti muutu. Se on olemassa tiukasti rajoitetussa kontekstissa.
Ongelmana on, että todellisessa maailmassa liike-elämän palvelut eivät voi pitää jatkuvasti samaa puhdasta roolijakoa. Esimerkiksi samat yrityspalvelut toimivat enemmän muista vastaavista palveluista tulevan datan kanssa. Jos olet online-jälleenmyyjä, tilausvirran, tuoteluettelon tai käyttäjätietojen käsittelystä tulee vaatimus monille palveluillesi. Jokainen palvelu tarvitsee pääsyn näihin tietoihin toimiakseen.
Suurin osa yrityspalveluista käyttää samaa tietovirtaa, joten niiden työ on poikkeuksetta kietoutunut toisiinsa.
Näin pääsemme tärkeän asian äärelle, josta kannattaa puhua. Vaikka palvelut toimivat hyvin suurelta osin eristyksissä toimiville infrastruktuurikomponenteille, useimmat yrityspalvelut kietoutuvat paljon tiiviimmin toisiinsa.
Datan kaksijakoisuus
Palvelukeskeisiä lähestymistapoja saattaa jo olla olemassa, mutta tietoa suurten tietomäärien vaihtamisesta palvelujen välillä on vielä vähän.
Suurin ongelma on, että data ja palvelut ovat erottamattomia. Toisaalta kapselointi kannustaa piilottamaan dataa, jotta palvelut voidaan erottaa toisistaan ja edistää niiden kasvua ja jatkomuutoksia. Toisaalta meidän on kyettävä jakamaan ja valloittamaan vapaasti jaetun datan yli, aivan kuten minkä tahansa muunkin. Kyse on mahdollisuudesta aloittaa työskentely välittömästi, yhtä vapaasti kuin missä tahansa muussa tietojärjestelmässä.
Tietojärjestelmillä ei kuitenkaan ole juurikaan tekemistä kapseloinnin kanssa. Itse asiassa se on jopa päinvastoin. Tietokannat tekevät kaikkensa antaakseen pääsyn tallentamiinsa tietoihin. Niissä on tehokas deklaratiivinen käyttöliittymä, jonka avulla voit muokata tietoja haluamallasi tavalla. Tällainen toimivuus on tärkeä esitutkimuksen vaiheessa, mutta ei jatkuvasti kehittyvän palvelun kasvavan monimutkaisuuden hallinnassa.
Ja tässä syntyy dilemma. Ristiriita. Dikotomia. Tietojärjestelmissä on kyse tiedon tuottamisesta ja palveluissa piiloutumisesta.
Nämä kaksi voimaa ovat perustavanlaatuisia. Ne tukevat suurta osaa työstämme ja kilpailevat jatkuvasti ylivallasta rakentamissamme järjestelmissä.
Palvelujärjestelmien kasvaessa ja kehittyessä näemme datadikotomian vaikutuksista erilaisia ilmentymiä. Joko palvelurajapinta kasvaa tarjoamaan yhä enemmän toimintoja ja alkaa näyttämään erittäin hienolta kotitekoiselta tietokannalta, tai sitten turhaudumme ja toteutamme jonkin tavan hakea tai siirtää kokonaisia tietojoukkoja massana palvelusta palveluun.
Jos luot jotain, joka näyttää hienolta homebrew-tietokannasta, johtaa lukuisiin ongelmiin. Emme mene yksityiskohtiin siitä, mikä on vaarallista jaettu tietokanta, sanotaanpa vain, että se edustaa huomattavaa kallista suunnittelua ja toimintaa yritykselle, joka yrittää sitä käyttää.
Mikä pahempaa, tietomäärät moninkertaistavat palvelurajojen ongelmat. Mitä yleisempää dataa on palvelun sisällä, sitä monimutkaisempi käyttöliittymä tulee ja sitä vaikeampaa on eri palveluista tulevien tietokokonaisuuksien yhdistäminen.
Vaihtoehtoisessa lähestymistavassa kokonaisten tietojoukkojen poimimiseen ja siirtämiseen on myös omat ongelmansa. Yleinen lähestymistapa tähän kysymykseen näyttää olevan yksinkertaisesti hakea ja tallentaa koko tietojoukko ja sitten tallentaa se paikallisesti jokaiseen kuluttavaan palveluun.
Ongelmana on, että eri palvelut tulkitsevat käyttämänsä datan eri tavalla. Nämä tiedot ovat aina käsillä. Niitä muokataan ja käsitellään paikallisesti. Pian heillä ei ole mitään tekemistä lähteen tietojen kanssa.
Mitä muuttuvampia kopiot ovat, sitä enemmän tiedot vaihtelevat ajan myötä.
Vielä pahempaa on, että tällaisia tietoja on vaikea korjata jälkikäteen ( tässä se on todella kätevä.) Itse asiassa jotkin yritysten kohtaamista vaikeista teknologiahaasteista johtuvat heterogeenisestä tiedosta, joka lisääntyy sovelluksesta toiseen.
Jotta voit löytää ratkaisun tähän yleiseen tietoongelmaan, sinun on ajateltava toisin. Niistä pitäisi tulla ensiluokkaisia esineitä rakentamissamme arkkitehtuureissa. kutsuu tällaista dataa "ulkoiseksi", ja tämä on erittäin tärkeä ominaisuus. Tarvitsemme kapselointia, jotta emme paljasta palvelun sisäisiä osia, mutta meidän on tehtävä palveluille helppo pääsy jaettuun dataan, jotta ne voivat tehdä työnsä oikein.
Ongelmana on, että kumpikaan lähestymistapa ei ole nykypäivänä relevantti, koska palvelurajapinnat, viestintä tai Shared Database eivät tarjoa hyvää ratkaisua ulkoisten tietojen kanssa työskentelyyn. Palvelurajapinnat soveltuvat huonosti kaiken mittakaavan tiedonvaihtoon. Viestintä siirtää tietoja, mutta ei tallenna sen historiaa, joten tiedot vioituvat ajan myötä. Jaetut tietokannat keskittyvät liikaa yhteen kohtaan, mikä hidastaa edistymistä. Joudumme väistämättä jumissa datavikojen kierteeseen:
Tietojen epäonnistumisjakso
Flows: hajautettu lähestymistapa dataan ja palveluihin
Ihannetapauksessa meidän on muutettava tapaa, jolla palvelut toimivat jaettujen tietojen kanssa. Tällä hetkellä mikä tahansa lähestymistapa osuu edellä mainittuun kaksijakoisuuteen, sillä ei ole olemassa maagista pölyä, jota voisi avokätisesti ripotella ja saada katoamaan. Voimme kuitenkin miettiä ongelmaa uudelleen ja päästä kompromissiin.
Tämä kompromissi edellyttää tietynlaista keskittämistä. Voimme hyödyntää hajautettua lokimekanismia, koska se tarjoaa luotettavia, skaalautuvia virtoja. Nyt haluamme, että palvelut voivat liittyä ja toimia näissä jaetuissa säikeissä, mutta haluamme välttää monimutkaisia keskitettyjä jumalapalveluita, jotka suorittavat tämän käsittelyn. Siksi paras vaihtoehto on rakentaa suoratoistokäsittely jokaiseen kuluttajapalveluun. Näin palvelut voivat yhdistää eri lähteistä peräisin olevia tietojoukkoja ja työskennellä niiden kanssa haluamallaan tavalla.
Yksi tapa saavuttaa tämä lähestymistapa on käyttää suoratoistoalustaa. Vaihtoehtoja on monia, mutta tänään harkitsemme Kafkaa, koska sen Stateful Stream Processingin avulla voimme ratkaista esitetyn ongelman tehokkaasti.
Hajautetun kirjausmekanismin käyttäminen antaa meille mahdollisuuden seurata polkua ja käyttää viestejä . Tämän lähestymistavan katsotaan tarjoavan paremman skaalauksen ja erottelun kuin pyyntö-vastausmekanismin, koska se antaa virtauksen hallinnan vastaanottajalle lähettäjän sijaan. Sinun on kuitenkin maksettava kaikesta tässä elämässä, ja täällä tarvitset välittäjän. Mutta suurille järjestelmille tämä kompromissi on sen arvoinen (mitä et voi sanoa keskimääräisistä verkkosovelluksistasi).
Jos välittäjä on vastuussa hajautetusta kirjauksesta, ei perinteinen viestintäjärjestelmä, voit hyödyntää lisäominaisuuksia. Siirto voi skaalata lineaarisesti melkein yhtä hyvin kuin hajautettu tiedostojärjestelmä. Tietoja voidaan tallentaa lokeihin pitkään, joten saamme viestien lisäksi myös tietovaraston. Skaalautuva tallennustila ilman pelkoa muuttuvasta jaetusta tilasta.
Tämän jälkeen voit käyttää tilallista stream-käsittelymekanismia lisätäksesi deklaratiivisia tietokantatyökaluja kuluttaviin palveluihin. Tämä on erittäin tärkeä ajatus. Niin kauan kuin tiedot säilytetään jaetuissa virroissa, joihin kaikki palvelut voivat päästä käsiksi, palvelun suorittama yhdistäminen ja käsittely on yksityistä. Ne on eristetty tiukasti rajoitetussa kontekstissa.
Päästä eroon datadikotomiasta jakamalla muuttumaton tilavirta. Lisää sitten tämä toiminto jokaiseen palveluun Stateful Stream Processing -toiminnolla.
Jos palvelusi on siis toimittava tilausten, tuoteluettelon, varaston kanssa, sillä on täysi käyttöoikeus: vain sinä päätät, mitä tietoja yhdistät, missä ne käsitellään ja miten sen tulee muuttua ajan myötä. Huolimatta siitä, että tiedot jaetaan, työskentely sen kanssa on täysin hajautettua. Se tuotetaan jokaisen palvelun sisällä, maailmassa, jossa kaikki menee sääntöjen mukaan.
Jaa tietoja vaarantamatta niiden eheyttä. Kapseloi funktio, ei lähde, jokaiseen sitä tarvitsevaan palveluun.
Joten tapahtuu, että tiedot on siirrettävä massa. Joskus palvelu tarvitsee paikallisen historiatietojoukon valittuun tietokantamoottoriin. Temppu on, että voidaan taata, että kopio voidaan tarvittaessa palauttaa lähteestä ottamalla yhteyttä hajautettuun lokimekanismiin. Kafkan liittimet tekevät tässä hienoa työtä.
Joten tänään käsitellyllä lähestymistavalla on useita etuja:
- Dataa käytetään jaettujen virtojen muodossa, jotka voidaan tallentaa lokeihin pitkäksi ajaksi, ja jaetun tiedon kanssa työskentelymekanismi on langallinen jokaisessa yksittäisessä kontekstissa, mikä mahdollistaa palvelujen toiminnan helposti ja nopeasti. Tällä tavalla datan kaksijakoisuus voidaan tasapainottaa.
- Eri palveluista tuleva data on helposti yhdistettävissä sarjoiksi. Tämä yksinkertaistaa vuorovaikutusta jaettujen tietojen kanssa ja poistaa tarpeen ylläpitää paikallisia tietojoukkoja tietokannassa.
- Stateful Stream Processing vain tallentaa tiedot välimuistiin, ja yleiset lokit pysyvät totuuden lähteenä, joten ajan mittaan tapahtuva tietojen korruptio ei ole niin akuutti.
- Palvelut ovat ytimenään datavetoisia, mikä tarkoittaa, että datavolyymien jatkuvasta kasvusta huolimatta palvelut pystyvät silti reagoimaan nopeasti liiketoiminnan tapahtumiin.
- Skaalautuvuusongelmat kuuluvat välittäjälle, eivät palveluille. Tämä vähentää huomattavasti kirjoituspalvelujen monimutkaisuutta, koska skaalautuvuutta ei tarvitse ajatella.
- Uusien palvelujen lisääminen ei edellytä vanhojen vaihtamista, joten uusien palvelujen yhdistäminen helpottuu.
Kuten näet, se on enemmän kuin vain LEPOA. Olemme saaneet joukon työkaluja, joiden avulla voit työskennellä jaettujen tietojen kanssa hajautetusti.
Kaikkia näkökohtia ei ole paljastettu tämän päivän artikkelissa. Meidän on vielä selvitettävä, kuinka tasapainottaa pyyntö-vastaus-paradigma ja tapahtumalähtöinen paradigma. Mutta käsittelemme tätä ensi kerralla. On aiheita, joihin sinun täytyy tutustua paremmin, esimerkiksi miksi Stateful Stream Processing on niin hyvä. Puhumme tästä kolmannessa artikkelissa. Ja on muitakin tehokkaita rakenteita, joita voimme käyttää, jos turvaudumme niihin, esim. . Se on pelin vaihtaja hajautetuille yritysjärjestelmille, koska se tarjoaa kaupankäyntitakuita skaalautuvassa muodossa. Tätä käsitellään neljännessä artikkelissa. Lopuksi meidän on tarkasteltava näiden periaatteiden täytäntöönpanon yksityiskohtia.
Mutta nyt, muista vain tämä: datadikotomia on voima, jonka kohtaamme yrityspalveluita rakentaessamme. Ja tämä meidän on muistettava. Temppu on kääntää kaikki päälaelleen ja alkaa käsitellä jaettua dataa ensiluokkaisina esineinä. Stateful Stream Processing tarjoaa tähän ainutlaatuisen kompromissin. Se välttää keskitettyjä "jumalakomponentteja", jotka estävät edistystä. Lisäksi se tarjoaa ketteryyttä, skaalautuvuutta ja joustavuutta datan suoratoistoputkissa ja lisää ne jokaiseen palveluun. Siksi voimme keskittyä yleiseen tietoisuusvirtaan, johon mikä tahansa palvelu voi muodostaa yhteyden ja työskennellä tietojensa kanssa. Tämä tekee palveluista skaalautuvampia, keskenään vaihdettavia ja autonomisempia. Siksi ne eivät vain näytä hyvältä tauluilla ja hypoteeseja testattaessa, vaan myös toimivat ja kehittyvät vuosikymmeniä.
Lähde: will.com