{"id":83248,"date":"2020-05-29T19:42:48","date_gmt":"2020-05-29T17:42:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam"},"modified":"2020-05-29T19:42:48","modified_gmt":"2020-05-29T17:42:48","slug":"dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","title":{"rendered":"Dichotomi af data: at genfortolke forholdet til data og tjenester","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej alle sammen! Vi har gode nyheder, i juni genoptager OTUS igen kurset \u00bbSoftwarearkitekt\u00ab<\/a><\/noindex>, og i den forbindelse deler vi traditionelt nyttigt materiale med jer.<\/b><\/i><\/p>\n

\"Dichotomi
\n
\n Hvis du har st\u00f8dt p\u00e5 hele denne historie om mikroservices uden nogen kontekst, kan det v\u00e6re forst\u00e5eligt, at du finder det en smule m\u00e6rkeligt. At opdele en applikation i fragmenter, der er forbundet via et netv\u00e6rk, betyder uundg\u00e5eligt at tilf\u00f8je komplekse fejlbeskyttelsesmetoder til det resulterende distribuerede system. <\/p>\n

Selvom denne tilgang involverer opdeling i mange uafh\u00e6ngige tjenester, er det overordnede m\u00e5l meget mere end bare at f\u00e5 disse tjenester til at k\u00f8re p\u00e5 forskellige maskiner. Det handler om at interagere med den omgivende verden, som i sin essens ogs\u00e5 er distribueret. Ikke i teknisk forstand, men snarere i betydningen af et \u00f8kosystem, som best\u00e5r af mange mennesker, teams, programmer, og at hver af disse dele p\u00e5 en eller anden m\u00e5de skal udf\u00f8re deres arbejde.<\/a><\/noindex><\/p>\n

Virksomheder, for eksempel, udg\u00f8r et s\u00e6t distribuerede systemer, der tilsammen bidrager til at opn\u00e5 et bestemt m\u00e5l. Vi har ignoreret denne kendsgerning i \u00e5rtier, hvor vi har fors\u00f8gt at opn\u00e5 integration ved at overf\u00f8re filer via FTP eller bruge v\u00e6rkt\u00f8jer til virksomhedsintegra\u00e7\u00e3o, mens vi har fokuseret p\u00e5 vores egne isolerede m\u00e5l. Men med ankomsten af tjenester blev alt \u00e6ndret. Tjenester har hjulpet os med at se ud over horisonten og se en verden af indbyrdes afh\u00e6ngige programmer, der arbejder sammen. Men for at have succes skal man forst\u00e5 og designe to fundamentalt forskellige verdener: den ydre verden, hvor vi lever i et \u00f8kosystem af mange andre tjenester, og vores personlige, indre verden, hvor vi hersker alene.<\/p>\n

\"Dichotomi
\n
\n Denne distribuerede verden adskiller sig fra den, vi voksede op i og er vant til. Principperne for opbygning af traditionel monolitisk arkitektur holder ikke. Derfor er en korrekt forst\u00e5else af s\u00e5danne systemer mere end bare at lave et flot diagram p\u00e5 en hvid markeringsplade eller en imponerende proof of concept. Det handler om, at et s\u00e5dant system fungerer effektivt over en lang periode. Heldigvis har tjenester eksisteret i lang tid, selvom de ser forskellige ud. Lektioner fra SOA<\/a><\/noindex> de stadig relevante, selv n\u00e5r de er krydret med Docker, Kubernetes og let slidte hipster-sk\u00e6g. <\/p>\n

S\u00e5 i dag vil vi se p\u00e5, hvordan reglerne har \u00e6ndret sig, hvorfor vi skal genoverveje vores tilgang til tjenesterne og dataene, de overf\u00f8rer til hinanden, og hvorfor vi f\u00e5r brug for helt anderledes v\u00e6rkt\u00f8jer til dette.<\/p>\n

Indkapsling vil ikke altid v\u00e6re din ven.<\/h3>\n

\n Mikrotjenester kan fungere uafh\u00e6ngigt af hinanden. Det er denne egenskab, der giver dem den st\u00f8rste v\u00e6rdi. Denne egenskab muligg\u00f8r ogs\u00e5, at tjenester kan skaleres og vokse. Ikke s\u00e5 meget i betydningen at skalere til kvadrillioner af brugere eller petabytes af data (selvom de ogs\u00e5 kan hj\u00e6lpe her), men i betydningen at skalere i forhold til mennesker, da teams og organisationer kontinuerligt vokser.<\/p>\n

\"Dichotomi
\n
\nDog er uafh\u00e6ngighed en tve\u00e6gget sv\u00e6rd. Det vil sige, at en tjeneste kan k\u00f8re let og ubesv\u00e6ret p\u00e5 egen h\u00e5nd. Men hvis der i tjenesten implementeres en funktion, der kr\u00e6ver at inddrage en anden tjeneste, ender vi til sidst med at skulle \u00e6ndre begge tjenester n\u00e6sten samtidig. I en monolit er det let at g\u00f8re; du laver blot \u00e6ndringen og sender den p\u00e5 udgivelse, men n\u00e5r det kommer til synkronisering af uafh\u00e6ngige tjenester, opst\u00e5r der flere problemer. Samordning mellem teams og udgivelsescyklusser \u00f8del\u00e6gger fleksibiliteten.<\/p>\n

\"Dichotomi
\n
\nI den standardtilgang tilstr\u00e6ber man at undg\u00e5 uhensigtsm\u00e6ssige tv\u00e6rg\u00e5ende \u00e6ndringer ved klart at adskille funktionaliteten mellem tjenesterne. En gateway-tjeneste kan v\u00e6re et godt eksempel her. Den har en klart defineret rolle, der adskiller den fra andre tjenester. En s\u00e5dan klar opdeling betyder, at i en verden med hurtigt skiftende krav til de tjenester, den omgiver sig med, vil gateway-tjenesten n\u00e6ppe \u00e6ndre sig. Den eksisterer inden for en strengt afgr\u00e6nset kontekst.<\/p>\n

\"Dichotomi
\n
\n Problemet er, at i den virkelige verden kan forretningstjenester ikke konstant opretholde en klar opdeling af rollerne. For eksempel arbejder de samme forretningstjenester i h\u00f8jere grad med data, der kommer fra andre tilsvarende tjenester. Hvis du driver online detailhandel, vil h\u00e5ndteringen af ordreflowet, produktkataloget eller brugerinformation blive en n\u00f8dvendighed for mange af dine tjenester. Hver tjeneste vil have brug for adgang til disse data for at fungere. <\/p>\n

\"Dichotomi
\nDe fleste forretningstjenester bruger det samme datastr\u00f8m, s\u00e5 deres arbejde er altid sammenv\u00e6vet.<\/i><\/p>\n

S\u00e5dan kom vi til et vigtigt punkt, som det er v\u00e6rd at tale om. Mens tjenester fungerer godt for infrastrukturkomponenter, der arbejder i h\u00f8j grad adskilt, viser det sig, at de fleste forretningstjenester er langt mere t\u00e6t sammenv\u00e6vet.<\/p>\n

Dichotomi af data<\/h3>\n

\n Tjenesteorienterede tilgange eksisterer muligvis allerede, men der er stadig lidt information om, hvordan man udveksler store datam\u00e6ngder mellem tjenester.<\/p>\n

Det grundl\u00e6ggende problem er, at data og tjenester er uadskillelige. P\u00e5 den ene side opfordrer indkapsling os til at skjule data for at adskille tjenester fra hinanden og g\u00f8re det lettere for dem at vokse og \u00e6ndre sig. P\u00e5 den anden side har vi brug for at kunne dele og have kontrol over f\u00e6lles data, ligesom med enhver anden. Det handler om at kunne g\u00e5 i gang med arbejdet med det samme, lige s\u00e5 frit som i ethvert andet informationssystem.<\/p>\n

Men informationssystemer har lidt til f\u00e6lles med indkapsling. Faktisk er det ofte det modsatte. Databaser g\u00f8r alt, hvad de kan, for at give adgang til de data, der er gemt i dem. De leveres med et kraftfuldt deklarativt interface, der g\u00f8r det muligt at \u00e6ndre data, som du har brug for. Denne funktionalitet er vigtig i forskningsfasen, men ikke til at styre den voksende kompleksitet af en konstant udviklende tjeneste.<\/p>\n

\"Dichotomi
\n
\n Og her opst\u00e5r dilemmaet. Modsigelsen. Dichotomien. For informationssystemer handler om at levere data, mens tjenester handler om at skjule.<\/p>\n

Disse to kr\u00e6fter er grundl\u00e6ggende. De ligger til grund for det meste af vores arbejde og k\u00e6mper konstant om overlegenhed i de systemer, vi skaber.<\/p>\n

Mens service-systemer vokser og udvikler sig, ser vi forskellige manifestationer af konsekvenserne af data-dikotomien. Enten vil servicegr\u00e6nsefladen vokse og tilbyde et stadigt bredere funktionalitetsudvalg og begynde at ligne en meget underlig skr\u00e6ddersyet database, eller ogs\u00e5 vil vi blive skuffede, og vi vil implementere en m\u00e5de at udtr\u00e6kke eller overf\u00f8re store datas\u00e6t fra service til service.<\/p>\n

\"Dichotomi
\n
\n At skabe noget, der ligner en underlig skr\u00e6ddersyet database, vil p\u00e5 sin side f\u00f8re til en r\u00e6kke problemer. Vi vil ikke g\u00e5 i detaljer om, hvad der er farligt ved shared database<\/i>, bare sige, at det medf\u00f8rer betydelige og kostbare ingeni\u00f8r- og drifts udfordringer<\/a><\/noindex> for virksomheder, der fors\u00f8ger at anvende den.<\/p>\n

Det v\u00e6rre er, at datam\u00e6ngderne forst\u00e6rker problemerne med servicegr\u00e6nser. Jo flere f\u00e6lles data der er inden for en service, desto vanskeligere bliver det at navigere i gr\u00e6nsefladen, og desto sv\u00e6rere bliver det at samle datas\u00e6t, der kommer fra forskellige tjenester.<\/p>\n

Et alternativt tilgang med at udtr\u00e6kke og overf\u00f8re hele datas\u00e6t har ogs\u00e5 sine problemer. En almindelig tilgang til dette sp\u00f8rgsm\u00e5l ser ud som simpelthen at udtr\u00e6kke og opbevare et datas\u00e6t helt og derefter gemme det lokalt i hver forbruger-service.<\/p>\n

\"Dichotomi
\n
\n Problemet er, at forskellige services fortolker de data, de forbruger, forskelligt. Disse data er altid lige ved h\u00e5nden. De \u00e6ndres og behandles lokalt. Ret hurtigt mister de alt, hvad de havde tilf\u00e6lles med dataene i kilden.<\/p>\n

\"Dichotomi
\n Jo mere mutable kopier er, desto mere vil data adskille sig over tid.<\/i><\/p>\n

Hvad der er v\u00e6rre, er, at s\u00e5danne data er sv\u00e6re at rette op i retrospektivet (MDM<\/a><\/noindex> her kan det virkelig komme til hj\u00e6lp). Faktisk opst\u00e5r nogle af de vanskeligt l\u00f8selige teknologiske problemer, som virksomheder st\u00e5r over for, p\u00e5 grund af heterogene data, der multipliceres fra anvendelse til anvendelse.<\/p>\n

For at finde en l\u00f8sning p\u00e5 problemet med f\u00e6lles data skal man t\u00e6nke anderledes. De skal blive f\u00f8rstklassige objekter i de arkitekturer, vi bygger. P\u00e6t Helland<\/a><\/noindex> kaldet s\u00e5danne data \u00bbeksterne\u00ab og dette er en meget vigtig egenskab. Vi har brug for indkapsling for ikke at afsl\u00f8re den interne struktur af tjenesten, men vi skal lette tjenesterne adgang til de delte data, s\u00e5 de kan udf\u00f8re deres arbejde korrekt.<\/p>\n

\"Dichotomi
\n
\n Problemet er, at ingen af tilgange i dag er relevante, fordi hverken tjenestegr\u00e6nseflader, beskedudveksling eller Shared Database tilbyder en god l\u00f8sning til h\u00e5ndtering af eksterne data. Tjenestegr\u00e6nseflader er d\u00e5rligt egnede til dataudveksling i enhver skala. Beskedudveksling flytter data, men opbevarer ikke deres historie, hvilket med tiden f\u00f8rer til beskadigede data. Shared Databases fokuserer for meget p\u00e5 en enkelt punkt, hvilket h\u00e6mmer udviklingen. Vi sidder uundg\u00e5eligt fast i en cyklus af datainvaliditet:<\/p>\n

\"Dichotomi
\n Cyklen af datainvaliditet<\/i><\/p>\n

Str\u00f8mme: en decentraliseret tilgang til data og tjenester<\/h3>\n

\n Ideelt set skal vi \u00e6ndre tilgang til, hvordan tjenester arbejder med delte data. Lige nu st\u00e5r enhver tilgang overfor den n\u00e6vnte dikotomi, da der ikke eksisterer noget magisk stof, som vi kan drysse over det og f\u00e5 det til at forsvinde. Men vi kan genoverveje problemet og komme til et kompromis.<\/p>\n

Dette kompromis indeb\u00e6rer en vis grad af centralisering. Vi kan drage fordel af mekanismen med distribuerede logs, da den tilbyder p\u00e5lidelige, skalerbare str\u00f8mme. Nu skal tjenesterne kunne tilslutte sig og arbejde med disse delte str\u00f8mme, men vi \u00f8nsker at undg\u00e5 komplekse centraliserede God Services, der udf\u00f8rer en s\u00e5dan behandling. Derfor er det bedste valg at indbygge str\u00f8mbehandling i hver service-forbruger. P\u00e5 den m\u00e5de kan tjenesterne kombinere datas\u00e6t fra forskellige kilder og arbejde med dem, som de \u00f8nsker.<\/p>\n

En m\u00e5de at opn\u00e5 denne tilgang p\u00e5 er ved at bruge en streamingsplatform. Der findes mange muligheder, men i dag vil vi se n\u00e6rmere p\u00e5 Kafka, da brugen af dens Stateful Stream Processing g\u00f8r det muligt effektivt at l\u00f8se det n\u00e6vnte problem.<\/p>\n

\"Dichotomi
\n
\n Brugen af mekanismen med distribueret logning g\u00f8r det muligt for os at f\u00f8lge den fastsl\u00e5ede vej og bruge beskedudveksling til at arbejde med. begivenhedsorienteret arkitektur<\/a><\/noindex>. Det anses for, at denne tilgang sikrer bedre skalerbarhed og adskillelse end \u00abforesp\u00f8rgsels-svar\u00bb mekanismen, da den giver kontrol over flowet til modtageren og ikke afsenderen. Men som med alt i livet, er der en pris, og du f\u00e5r brug for en m\u00e6gler. Men for store systemer er denne kompromis det v\u00e6rd (hvad du ikke kan sige om dine gennemsnitlige webapplikationer).<\/p>\n

Hvis en m\u00e6gler h\u00e5ndterer distribueret logning i stedet for et traditionelt meddelelsessystem, kan du drage fordel af ekstra funktioner. Transporten kan n\u00e6sten skaleres line\u00e6rt lige s\u00e5 godt som et distribueret fils system. Data kan opbevares i loggene i lang tid, s\u00e5 vi f\u00e5r ikke kun meddelelser, men ogs\u00e5 et datalager. Et skalerbart lager uden frygt for at f\u00e5 et \u00e6ndret samlet state.<\/p>\n

Derefter kan mekanismen for stateful stream processing (behandling af str\u00f8m med bevarelse af tilstand) bruges til at tilf\u00f8je deklarative databasev\u00e6rkt\u00f8jer til forbruger tjenester. Dette er en meget vigtig tanke. Mens data opbevares i f\u00e6lles str\u00f8mme, som alle tjenester kan f\u00e5 adgang til, er sammenskrivningen og behandlingen, som tjenesten udf\u00f8rer, privat. De er isolerede inden for en strengt afgr\u00e6nset kontekst.<\/p>\n

\"Dichotomi
\n Slip af med datadikotomien ved at adskille den immaterielle tilstandsstr\u00f8m. Tilf\u00f8j derefter denne funktion til hver service gennem Stateful Stream Processing.<\/i><\/p>\n

S\u00e5 hvis din service skal arbejde med ordrer, produktkataloget, lageret, vil den have fuld adgang: kun du vil beslutte, hvilke data der skal samles, hvor de skal behandles, og hvordan de b\u00f8r \u00e6ndre sig over tid. P\u00e5 trods af at dataene er f\u00e6lles, er arbejdet med dem helt decentraliseret. Det sker inden for hver service, i en verden, hvor alt f\u00f8lger dine regler.<\/p>\n

\"Dichotomi
\nDel data p\u00e5 en m\u00e5de, s\u00e5 deres integritet ikke kompromitteres. Kapsl funktionaliteten, ikke kilden, i hver service, som den er n\u00f8dvendig for.<\/i><\/p>\n

Det sker, at data skal flyttes i stor skala. Nogle gange har tjenesten brug for et lokalt historisk datas\u00e6t i den valgte databasebehandling. Pointen er, at man kan garantere, at en kopi kan genskabes fra kilden, n\u00e5r det er n\u00f8dvendigt, ved at anmode om mekanismen for distribueret logf\u00f8ring. Connectorerne i Kafka klarer denne opgave glimrende.<\/p>\n

S\u00e5ledes har den tilgang, vi har set p\u00e5 i dag, flere fordele:<\/p>\n