Datadikotomien: revurdere forholdet mellom data og tjenester

Hei alle sammen! Vi har gode nyheter, OTUS lanserer kurset igjen i juni "Programvarearkitekt", i forbindelse med det vi tradisjonelt deler nyttig materiale med deg.

Hvis du har kommet over hele denne mikroservice-tingen uten noen sammenheng, vil du bli tilgitt for å synes det er litt rart. Å dele opp en applikasjon i fragmenter koblet til et nettverk betyr nødvendigvis å legge til komplekse feiltoleransemoduser til det resulterende distribuerte systemet.

Selv om denne tilnærmingen innebærer å dele den opp i mange uavhengige tjenester, er sluttmålet mye mer enn bare å få disse tjenestene til å kjøre på forskjellige maskiner. Vi snakker her om samhandling med omverdenen, som også er distribuert i sin essens. Ikke i teknisk forstand, men snarere i betydningen et økosystem som består av mange mennesker, team, programmer, og hver av disse delene må på en eller annen måte gjøre jobben sin.

Bedrifter, for eksempel, er en samling distribuerte systemer som til sammen bidrar til å oppnå et eller annet mål. Vi har ignorert dette faktum i flere tiår, og prøvd å oppnå forening ved å FTP-filer eller bruke integrasjonsverktøy for bedrifter mens vi fokuserer på våre egne isolerte mål. Men med ankomsten av tjenester endret alt seg. Tjenester har hjulpet oss med å se utover horisonten og se en verden av gjensidig avhengige programmer som fungerer sammen. Men for å fungere vellykket, er det nødvendig å gjenkjenne og designe to fundamentalt forskjellige verdener: den ytre verden, der vi lever i et økosystem av mange andre tjenester, og vår personlige, indre verden, der vi styrer alene.

Denne distribuerte verden er annerledes enn den vi vokste opp i og er vant til. Prinsippene for å konstruere tradisjonell monolitisk arkitektur tåler ikke kritikk. Så å få disse systemene riktig handler om mer enn å lage et kult tavlediagram eller et kult proof of concept. Poenget er å sikre at et slikt system fungerer vellykket over lang tid. Heldigvis har tjenestene eksistert ganske lenge, selv om de ser annerledes ut. SOA-leksjoner er fortsatt aktuelle, til og med krydret med Docker, Kubernetes og litt shabby hipsterskjegg.

Så i dag skal vi se på hvordan reglene har endret seg, hvorfor vi må revurdere måten vi nærmer oss tjenester på og dataene de sender videre til hverandre, og hvorfor vi trenger helt andre verktøy for å gjøre det.

Innkapsling vil ikke alltid være din venn

Mikrotjenester kan operere uavhengig av hverandre. Det er denne egenskapen som gir dem størst verdi. Denne samme egenskapen lar tjenester skalere og vokse. Ikke så mye i betydningen å skalere til kvadrillioner av brukere eller petabyte med data (selv om de kan hjelpe der også), men i betydningen å skalere når det gjelder mennesker når team og organisasjoner vokser kontinuerlig.

Uavhengighet er imidlertid et tveegget sverd. Det vil si at selve tjenesten kan kjøre enkelt og naturlig. Men hvis en funksjon implementeres innenfor en tjeneste som krever bruk av en annen tjeneste, så ender vi opp med å måtte gjøre endringer på begge tjenestene nesten samtidig. I en monolitt er dette enkelt å gjøre, du gjør bare en endring og sender den til utgivelse, men i tilfelle av synkronisering av uavhengige tjenester vil det være flere problemer. Koordinering mellom lag og frigjøringssykluser ødelegger smidigheten.

Som en del av standardtilnærmingen prøver de ganske enkelt å unngå irriterende ende-til-ende-endringer, og skiller funksjonalitet tydelig mellom tjenestene. Single sign-on-tjeneste kan være et godt eksempel her. Den har en klart definert rolle som skiller den fra andre tjenester. Denne klare separasjonen betyr at i en verden med raskt skiftende krav til tjenestene rundt seg, er det lite sannsynlig at single sign-on-tjenesten vil endre seg. Det eksisterer innenfor en strengt begrenset kontekst.

Problemet er at i den virkelige verden kan ikke forretningstjenester opprettholde det samme rene rolleskillet hele tiden. For eksempel fungerer de samme bedriftstjenestene i større grad med data som kommer fra andre lignende tjenester. Hvis du er involvert i netthandel, vil behandling av ordreflyt, produktkatalog eller brukerinformasjon bli et krav for mange av tjenestene dine. Hver av tjenestene vil trenge tilgang til disse dataene for å fungere.

De fleste forretningstjenester deler den samme datastrømmen, så arbeidet deres er alltid sammenvevd.

Dermed kommer vi til et viktig punkt som er verdt å snakke om. Selv om tjenester fungerer bra for infrastrukturkomponenter som stort sett opererer isolert, ender de fleste forretningstjenester med å bli mye tettere sammen.

Data dikotomi

Tjenesteorienterte tilnærminger finnes kanskje allerede, men de mangler fortsatt innsikt i hvordan man kan dele store mengder data mellom tjenester.

Hovedproblemet er at data og tjenester er uatskillelige. På den ene siden oppmuntrer innkapsling oss til å skjule data slik at tjenester kan skilles fra hverandre og legge til rette for deres vekst og ytterligere endringer. På den annen side må vi fritt kunne dele og erobre delt data, akkurat som alle andre data. Poenget er å kunne begynne å jobbe umiddelbart, like fritt som i ethvert annet informasjonssystem.

Informasjonssystemer har imidlertid lite med innkapsling å gjøre. Faktisk er det helt motsatt. Databaser gjør alt de kan for å gi tilgang til dataene de lagrer. De kommer med et kraftig deklarativt grensesnitt som lar deg endre dataene etter behov. Slik funksjonalitet er viktig på det foreløpige forskningsstadiet, men ikke for å håndtere den økende kompleksiteten til en tjeneste i stadig utvikling.

Og her oppstår et dilemma. Motsigelse. Dikotomi. Tross alt handler informasjonssystemer om å levere data, og tjenester handler om å gjemme seg.

Disse to kreftene er grunnleggende. De underbygger mye av arbeidet vårt, og kjemper konstant for fortreffelighet i systemene vi bygger.

Etter hvert som tjenestesystemer vokser og utvikler seg, ser vi konsekvensene av datadikotomi på mange måter. Enten vil tjenestegrensesnittet vokse, gi et stadig økende spekter av funksjonalitet og begynne å se ut som en veldig fancy hjemmelaget database, eller så vil vi bli frustrerte og implementere en eller annen måte å hente eller flytte massevis av hele sett med data fra tjeneste til tjeneste.

I sin tur vil det å lage noe som ser ut som en fancy hjemmelaget database føre til en hel rekke problemer. Vi vil ikke gå inn på detaljer om hvorfor det er farlig delt database, la oss bare si at det representerer betydelige kostbare ingeniør- og driftskostnader vanskeligheter for selskapet som prøver å bruke det.

Det som er verre er at datavolumer forstørrer tjenestegrenseproblemer. Jo mer delte data som ligger i en tjeneste, jo mer komplekst vil grensesnittet bli, og jo vanskeligere vil det være å kombinere datasett som kommer fra ulike tjenester.

Den alternative tilnærmingen med å trekke ut og flytte hele datasett har også sine problemer. En vanlig tilnærming til dette spørsmålet ser ut som å bare hente og lagre hele datasettet, og deretter lagre det lokalt i hver forbrukende tjeneste.

Problemet er at ulike tjenester tolker dataene de bruker forskjellig. Disse dataene er alltid tilgjengelig. De er modifisert og behandlet lokalt. Ganske raskt slutter de å ha noe til felles med dataene i kilden.

Jo mer foranderlige kopiene er, jo mer vil dataene variere over tid.

For å gjøre vondt verre, er slike data vanskelig å korrigere i ettertid (MDM Det er her den virkelig kan komme til unnsetning). Faktisk oppstår noen av de vanskelige teknologiproblemene som bedrifter står overfor, fra de ulike dataene som multipliserer fra applikasjon til applikasjon.

For å finne en løsning på dette problemet, må vi tenke annerledes om delte data. De må bli førsteklasses objekter i arkitekturene vi bygger. Pat Helland kaller slike data "eksterne", og dette er en veldig viktig funksjon. Vi trenger innkapsling slik at vi ikke avslører den indre funksjonen til en tjeneste, men vi må gjøre det enkelt for tjenester å få tilgang til delte data slik at de kan gjøre jobben sin på riktig måte.

Problemet er at ingen av tilnærmingene er relevante i dag, siden verken tjenestegrensesnittene, meldingsutvekslingen eller den delte databasen tilbyr en god løsning for arbeid med eksterne data. Tjenestegrensesnitt er dårlig egnet for datautveksling i alle skalaer. Meldinger flytter data, men lagrer ikke historikken, så data blir ødelagt over tid. Delte databaser fokuserer for mye på ett punkt, noe som holder fremgang tilbake. Vi blir uunngåelig fast i en syklus med datafeil:

Syklus av datafeil

Strømmer: en desentralisert tilnærming til data og tjenester

Ideelt sett må vi endre måten tjenester fungerer på med delte data. På dette tidspunktet vender begge tilnærmingene mot den nevnte dikotomien, siden det ikke er noe magisk støv som kan drysses på den for å få den til å forsvinne. Vi kan imidlertid revurdere problemet og komme til et kompromiss.

Dette kompromisset innebærer en viss grad av sentralisering. Vi kan bruke den distribuerte loggmekanismen fordi den gir pålitelige, skalerbare strømmer. Vi ønsker nå at tjenester skal kunne bli med og operere på disse delte trådene, men vi ønsker å unngå komplekse sentraliserte gudstjenester som utfører denne behandlingen. Derfor er det beste alternativet å bygge strømbehandling inn i hver forbrukertjeneste. På denne måten vil tjenester kunne kombinere datasett fra ulike kilder og jobbe med dem slik de trenger.

En måte å oppnå denne tilnærmingen er gjennom bruk av en strømmeplattform. Det er mange alternativer, men i dag skal vi se på Kafka, siden bruken av Stateful Stream Processing lar oss effektivt løse det presenterte problemet.

Ved å bruke en distribuert loggingsmekanisme kan vi følge den opptråkkede veien og bruke meldinger til å jobbe med hendelsesdrevet arkitektur. Denne tilnærmingen anses å gi bedre skalering og partisjonering enn forespørsel-svar-mekanismen fordi den gir kontroll over flyten til mottakeren i stedet for senderen. Men for alt her i livet må du betale, og her trenger du en megler. Men for store systemer er avveiningen verdt det (noe som kanskje ikke er tilfellet for din gjennomsnittlige nettapplikasjon).

Hvis en megler er ansvarlig for distribuert logging i stedet for et tradisjonelt meldingssystem, kan du dra nytte av tilleggsfunksjoner. Transporten kan skaleres lineært nesten like godt som et distribuert filsystem. Data kan lagres i logger ganske lenge, så vi får ikke bare meldingsutveksling, men også informasjonslagring. Skalerbar lagring uten frykt for foranderlig delt tilstand.

Du kan deretter bruke stateful strømbehandling for å legge til deklarative databaseverktøy til forbrukende tjenester. Dette er en veldig viktig idé. Mens dataene lagres i delte strømmer som alle tjenester har tilgang til, er aggregeringen og behandlingen som tjenesten gjør privat. De befinner seg isolert innenfor en strengt begrenset kontekst.

Eliminer datadikotomi ved å skille den uforanderlige tilstandsstrømmen. Legg deretter til denne funksjonaliteten til hver tjeneste ved hjelp av Stateful Stream Processing.

Derfor, hvis tjenesten din trenger å fungere med bestillinger, en produktkatalog, et lager, vil den ha full tilgang: bare du bestemmer hvilke data som skal kombineres, hvor de skal behandles og hvordan de skal endres over tid. Til tross for at dataene deles, er arbeidet med det fullstendig desentralisert. Den produseres innenfor hver tjeneste, i en verden der alt går etter dine regler.

Del data uten at det går på bekostning av integriteten. Innkapsle funksjonen, ikke kilden, i hver tjeneste som trenger den.

Det hender at data må flyttes massevis. Noen ganger krever en tjeneste et lokalt historisk datasett i den valgte databasemotoren. Trikset er at du kan garantere at kopien om nødvendig kan gjenopprettes fra kilden ved å få tilgang til den distribuerte loggingsmekanismen. Koblinger i Kafka gjør en god jobb med dette.

Så tilnærmingen diskutert i dag har flere fordeler:

• Data brukes i form av vanlige strømmer, som kan lagres i logger over lengre tid, og mekanismen for å arbeide med felles data er hardwired i hver enkelt kontekst, noe som gjør at tjenester kan fungere enkelt og raskt. På denne måten kan dataenes dikotomi balanseres.
• Data som kommer fra forskjellige tjenester kan enkelt kombineres til sett. Dette forenkler interaksjon med delte data og eliminerer behovet for å vedlikeholde lokale datasett i databasen.
• Stateful Stream Processing cacher bare data, og kilden til sannhet forblir de generelle loggene, så problemet med datakorrupsjon over tid er ikke så akutt.
• I kjernen er tjenester datadrevne, noe som betyr at til tross for stadig økende datamengder, kan tjenester fortsatt reagere raskt på forretningshendelser.
• Skalerbarhetsproblemer faller på megleren, ikke tjenestene. Dette reduserer kompleksiteten til skrivetjenester betydelig, siden det ikke er nødvendig å tenke på skalerbarhet.
• Å legge til nye tjenester krever ikke å endre gamle, så det blir enklere å koble til nye tjenester.

Som du kan se, er dette mer enn bare HVILE. Vi har mottatt et sett med verktøy som lar deg jobbe med delte data på en desentralisert måte.

Ikke alle aspekter ble dekket i dagens artikkel. Vi må fortsatt finne ut hvordan vi skal balansere mellom forespørsel-svar-paradigmet og det hendelsesdrevne paradigmet. Men vi skal ta tak i dette neste gang. Det er temaer du trenger for å bli bedre kjent med, for eksempel hvorfor Stateful Stream Processing er så bra. Vi vil snakke om dette i den tredje artikkelen. Og det er andre kraftige konstruksjoner som vi kan dra nytte av hvis vi tyr til dem, for eksempel, Behandling nøyaktig én gang. Det er en game changer for distribuerte forretningssystemer fordi det gir transaksjonsgarantier for XA i en skalerbar form. Dette vil bli diskutert i den fjerde artikkelen. Til slutt må vi gå gjennom implementeringsdetaljene til disse prinsippene.

Men for nå, bare husk dette: datadikotomien er en kraft vi møter når vi bygger forretningstjenester. Og dette må vi huske. Trikset er å snu alt på hodet og begynne å behandle delte data som førsteklasses objekter. Stateful Stream Processing gir et unikt kompromiss for dette. Den unngår sentraliserte "Gudskomponenter" som holder tilbake fremgang. Dessuten sikrer den smidigheten, skalerbarheten og robustheten til datastrømmingspipelines og legger dem til hver tjeneste. Derfor kan vi fokusere på den generelle bevissthetsstrømmen som enhver tjeneste kan koble seg til og jobbe med sine data til. Dette gjør tjenester mer skalerbare, utskiftbare og autonome. Så de vil ikke bare se bra ut på tavler og hypotesetester, men de vil også fungere og utvikle seg i flere tiår.

Lær mer om kurset.

Kilde: www.habr.com