{"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\/sv\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","title":{"rendered":"Data Dichotomy: Ompr\u00f6va f\u00f6rh\u00e5llandet till data och tj\u00e4nster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej alla! Vi har fantastiska nyheter, i juni startar OTUS \u00e5terigen en kurs Software Architect<\/a><\/noindex>, d\u00e4rf\u00f6r delar vi traditionellt med oss av anv\u00e4ndbart material till er.<\/b><\/i><\/p>\n

\"Data
\n
\n Om du har st\u00f6tt p\u00e5 hela denna historia med mikrotj\u00e4nster utan n\u00e5got sammanhang, kan du kanske tycka att den \u00e4r lite konstig. Att bryta ner en applikation i fragment som \u00e4r kopplade till varandra via n\u00e4tverket inneb\u00e4r n\u00f6dv\u00e4ndigtvis att man m\u00e5ste l\u00e4gga till komplexa felhanteringsmetoder i det resulterande distribuerade systemet. <\/p>\n

Trots att denna metod inkluderar uppdelning i m\u00e5nga oberoende tj\u00e4nster, \u00e4r det slutgiltiga m\u00e5let mycket mer \u00e4n bara att dessa tj\u00e4nster fungerar p\u00e5 olika maskiner. Det handlar om interaktion med omv\u00e4rlden, som i sin natur ocks\u00e5 \u00e4r distribuerad. Inte i teknisk mening, utan snarare i mening av ett ekosystem som best\u00e5r av m\u00e5nga m\u00e4nniskor, team och program, och varje del m\u00e5ste p\u00e5 sitt s\u00e4tt utf\u00f6ra sitt arbete.<\/a><\/noindex><\/p>\n

F\u00f6retag, till exempel, representerar en upps\u00e4ttning distribuerade system som tillsammans bidrar till att n\u00e5 ett visst m\u00e5l. Vi har ignorerat denna fakta i \u00e5rtionden, p\u00e5 jakt efter sammanslagning, genom att \u00f6verf\u00f6ra filer via FTP eller anv\u00e4nda f\u00f6retagsintegrationsverktyg, samtidigt som vi har fokuserat p\u00e5 v\u00e5ra egna isolerade m\u00e5l. Men med tj\u00e4nsternas ankomst f\u00f6r\u00e4ndrades allt. Tj\u00e4nster har hj\u00e4lpt oss att se bortom horisonten och uppt\u00e4cka en v\u00e4rld av \u00f6msesidigt beroende program som arbetar tillsammans. Men f\u00f6r att lyckas m\u00e5ste vi erk\u00e4nna och konstruera tv\u00e5 helt olika v\u00e4rldar: den externa v\u00e4rlden, d\u00e4r vi lever i ett ekosystem av m\u00e5nga andra tj\u00e4nster, och v\u00e5r personliga, interna v\u00e4rld, d\u00e4r vi h\u00e4rskar ensamma.<\/p>\n

\"Data
\n
\n Denna distribuerade v\u00e4rld skiljer sig fr\u00e5n den vi v\u00e4xte upp i och \u00e4r vana vid. Principerna f\u00f6r att bygga traditionell monolitisk arkitektur h\u00e5ller inte f\u00f6r granskning. D\u00e4rf\u00f6r \u00e4r en korrekt f\u00f6rst\u00e5else av s\u00e5dana system mer \u00e4n bara att skapa en snygg skiss p\u00e5 en vit tavla eller ett imponerande bevis p\u00e5 konceptet. Det handlar om att s\u00e5dana system m\u00e5ste fungera framg\u00e5ngsrikt under l\u00e5ng tid. Lyckligtvis har tj\u00e4nster funnits ganska l\u00e4nge, \u00e4ven om de ser olika ut. SOA-lektioner<\/a><\/noindex> \u00e4r fortfarande relevanta, \u00e4ven om de \u00e4r kryddade med Docker, Kubernetes och lite slitna hiptster-sk\u00e4gg. <\/p>\n

S\u00e5 idag ska vi titta p\u00e5 hur reglerna har f\u00f6r\u00e4ndrats, varf\u00f6r vi beh\u00f6ver ompr\u00f6va v\u00e5rt tillv\u00e4gag\u00e5ngss\u00e4tt till tj\u00e4nster och den data de utbyter med varandra, och varf\u00f6r vi kommer att beh\u00f6va helt andra verktyg f\u00f6r detta.<\/p>\n

Inkapsling kommer inte alltid vara din v\u00e4n.<\/h3>\n

\n Mikrotj\u00e4nster kan fungera oberoende av varandra. Just denna egenskap ger dem det st\u00f6rsta v\u00e4rdet. Denna egenskap m\u00f6jligg\u00f6r ocks\u00e5 att tj\u00e4nster kan skala och v\u00e4xa. Inte s\u00e5 mycket i termer av att skala till kvadriljoner anv\u00e4ndare eller petabyte data (\u00e4ven om de kan hj\u00e4lpa till d\u00e4r ocks\u00e5), utan i termer av att skala i fr\u00e5ga om m\u00e4nniskor, eftersom team och organisationer st\u00e4ndigt v\u00e4xer.<\/p>\n

\"Data
\n
\nMen oberoende \u00e4r ett dubbel\u00e4ggat sv\u00e4rd. Det vill s\u00e4ga, en tj\u00e4nst kan enkelt och smidigt k\u00f6ras p\u00e5 egen hand. Men om en funktion inom tj\u00e4nsten kr\u00e4ver att en annan tj\u00e4nst aktiveras, s\u00e5 m\u00e5ste vi i slut\u00e4ndan g\u00f6ra \u00e4ndringar i b\u00e5da tj\u00e4nsterna n\u00e4stan samtidigt. I en monolit \u00e4r det enkelt, man g\u00f6r bara \u00e4ndringen och skickar ut den, men i fallet med samordning av oberoende tj\u00e4nster finns det fler problem. Koordinering mellan team och releasecykler undergr\u00e4ver flexibelheten.<\/p>\n

\"Data
\n
\nInom den standardmetoden f\u00f6rs\u00f6ker man helt enkelt undvika frustrerande tv\u00e4rg\u00e5ende f\u00f6r\u00e4ndringar genom att tydligt separera funktionaliteten mellan tj\u00e4nsterna. En systemets enhetliga ing\u00e5ngstj\u00e4nst kan h\u00e4r vara ett bra exempel. Den har en klart definierad roll som s\u00e4rskiljer den fr\u00e5n andra tj\u00e4nster. En s\u00e5dan tydlig separation inneb\u00e4r att i en v\u00e4rld av snabbt f\u00f6r\u00e4nderliga krav p\u00e5 kringliggande tj\u00e4nster, l\u00e4r systemets enhetliga ing\u00e5ngstj\u00e4nst s\u00e4llan att f\u00f6r\u00e4ndras. Den existerar inom en strikt avgr\u00e4nsad kontext.<\/p>\n

\"Data
\n
\n Problemet \u00e4r att aff\u00e4rstj\u00e4nster i verkligheten inte kan uppr\u00e4tth\u00e5lla en konstant tydlig separation av roller. Till exempel arbetar dessa aff\u00e4rstj\u00e4nster i st\u00f6rre utstr\u00e4ckning med data som kommer fr\u00e5n andra liknande tj\u00e4nster. Om du bedriver e-handel kommer hantering av best\u00e4llningsfl\u00f6den, produktkataloger eller anv\u00e4ndarinformation att vara ett krav f\u00f6r m\u00e5nga av dina tj\u00e4nster. Varje tj\u00e4nst beh\u00f6ver tillg\u00e5ng till dessa data f\u00f6r att fungera. <\/p>\n

\"Data
\nDe flesta aff\u00e4rstj\u00e4nster anv\u00e4nder samma datak\u00e4lla, vilket g\u00f6r att deras arbete alltid sammanfl\u00e4tas.<\/i><\/p>\n

S\u00e5 vi har kommit till en viktig punkt som f\u00f6rtj\u00e4nar att diskuteras. Medan tj\u00e4nster fungerar bra f\u00f6r infrastrukturella komponenter som i stor utstr\u00e4ckning \u00e4r avskilda, visar det sig att de flesta aff\u00e4rstj\u00e4nster \u00e4r mycket mer t\u00e4t sammanfl\u00e4tade.<\/p>\n

Datanikomi<\/h3>\n

\n Tj\u00e4nsteorienterade tillv\u00e4gag\u00e5ngss\u00e4tt kan redan existera, men det finns fortfarande brist p\u00e5 information om hur man utbyter stora datam\u00e4ngder mellan tj\u00e4nster.<\/p>\n

Huvudproblemet \u00e4r att data och tj\u00e4nster \u00e4r oskiljaktiga. \u00c5 ena sidan uppmanar inkapsling oss att d\u00f6lja data s\u00e5 att tj\u00e4nster kan separeras fr\u00e5n varandra, vilket underl\u00e4ttar deras tillv\u00e4xt och vidare f\u00f6r\u00e4ndringar. \u00c5 andra sidan beh\u00f6ver vi ha m\u00f6jlighet att fritt dela och f\u00f6rvalta gemensamma data, precis som med alla andra. Det handlar om att kunna b\u00f6rja arbeta genast, lika fritt som i vilket annat informationssystem som helst.<\/p>\n

Men informationssystem har lite gemensamt med inkapsling. Faktum \u00e4r att det \u00e4r motsatsen. Databaser g\u00f6r allt de kan f\u00f6r att ge tillg\u00e5ng till de data som lagras i dem. De levereras med ett kraftfullt deklarativt gr\u00e4nssnitt som l\u00e5ter dig modifiera data enligt dina behov. Denna funktionalitet \u00e4r viktig i forskningsskedet, men inte f\u00f6r att hantera den v\u00e4xande komplexiteten hos en st\u00e4ndigt utvecklande tj\u00e4nst.<\/p>\n

\"Data
\n
\n Och h\u00e4r uppst\u00e5r dilemman. Mots\u00e4gelser. Dikotomier. F\u00f6r informationssystem handlar det om att tillhandah\u00e5lla data, medan tj\u00e4nster handlar om att d\u00f6lja.<\/p>\n

Dessa tv\u00e5 krafter \u00e4r fundamentala. De ligger till grund f\u00f6r det mesta av v\u00e5rt arbete, st\u00e4ndigt k\u00e4mpande om \u00f6verl\u00e4gsenhet i de system vi skapar.<\/p>\n

Allteftersom tj\u00e4nstesystem v\u00e4xer och utvecklas ser vi olika manifestationer av konsekvenserna av datadichotomier. Antingen kommer tj\u00e4nstens gr\u00e4nssnitt att v\u00e4xa, erbjuda en alltmer omfattande upps\u00e4ttning funktioner och b\u00f6rja likna en mycket egenh\u00e4ndigt skapad databas, eller s\u00e5 drabbas vi av besvikelse och m\u00e5ste implementera ett s\u00e4tt att extrahera eller flytta hela datam\u00e4ngder fr\u00e5n tj\u00e4nst till tj\u00e4nst.<\/p>\n

\"Data
\n
\n Att skapa n\u00e5got som ser ut som en egenh\u00e4ndigt skapad databas leder i sin tur till en rad problem. Vi g\u00e5r inte in p\u00e5 detaljer om vad som \u00e4r farligt med shared database<\/i>, utan s\u00e4ger bara att det medf\u00f6r betydande kostsamma tekniska och operativa utmaningar<\/a><\/noindex> f\u00f6r ett f\u00f6retag som f\u00f6rs\u00f6ker anv\u00e4nda den.<\/p>\n

V\u00e4rre \u00e4r att datavolymerna f\u00f6rv\u00e4rrar problemen med tj\u00e4nstebehovens gr\u00e4nser. Ju fler gemensamma data som finns inom en tj\u00e4nst, desto mer komplicerat blir gr\u00e4nssnittet och desto sv\u00e5rare blir det att kombinera datam\u00e4ngder som kommer fr\u00e5n olika tj\u00e4nster.<\/p>\n

Ett alternativt tillv\u00e4gag\u00e5ngss\u00e4tt f\u00f6r att extrahera och flytta hela datam\u00e4ngder har ocks\u00e5 sina problem. Den vanligaste metoden ser ut som en enkel extraktion och lagring av datam\u00e4ngden i sin helhet, f\u00f6r att sedan lagra den lokalt i varje mottagande tj\u00e4nst.<\/p>\n

\"Data
\n
\n Problemet \u00e4r att olika tj\u00e4nster tolkar de data de konsumerar p\u00e5 olika s\u00e4tt. Dessa data finns alltid tillg\u00e4ngliga. De \u00e4ndras och bearbetas lokalt. Snart har de inte l\u00e4ngre n\u00e5got gemensamt med de data som finns i k\u00e4llan.<\/p>\n

\"Data
\n Ju mer muterbara kopiorna blir, desto mer kommer data att avvika med tiden.<\/i><\/p>\n

Vad som \u00e4r \u00e4nnu v\u00e4rre \u00e4r att s\u00e5dana data \u00e4r sv\u00e5ra att korrigera i efterhand (MDM<\/a><\/noindex> kan verkligen hj\u00e4lpa h\u00e4r). Faktum \u00e4r att vissa av de sv\u00e5r\u00f6verblickbara tekniska problem som f\u00f6retag st\u00e5r inf\u00f6r uppst\u00e5r p\u00e5 grund av heterogena data som multipliceras fr\u00e5n applikation till applikation.<\/p>\n

F\u00f6r att hitta en l\u00f6sning p\u00e5 detta problem med gemensamma data m\u00e5ste vi t\u00e4nka annorlunda. De m\u00e5ste bli f\u00f6rstklassiga objekt i de arkitekturer vi bygger. P\u00e4t Hailand<\/a><\/noindex> ben\u00e4mner s\u00e5dan data som \"extern\", och det \u00e4r en mycket viktig egenskap. Vi beh\u00f6ver inkapsling f\u00f6r att inte avsl\u00f6ja den inre strukturen av tj\u00e4nsten, men vi m\u00e5ste underl\u00e4tta \u00e5tkomsten till delad data f\u00f6r tj\u00e4nster s\u00e5 att de kan utf\u00f6ra sina uppgifter korrekt.<\/p>\n

\"Data
\n
\n Problemet \u00e4r att ingen av metoderna idag \u00e4r relevanta l\u00e4ngre, eftersom varken tj\u00e4nstegr\u00e4nssnitt, meddelandefl\u00f6den eller delad databas erbjuder en bra l\u00f6sning f\u00f6r arbete med externa data. Tj\u00e4nstegr\u00e4nssnitt passar d\u00e5ligt f\u00f6r datadelning i n\u00e5gon skala. Meddelandefl\u00f6den flyttar data, men lagrar inte deras historia, vilket g\u00f6r att data blir skadade \u00f6ver tid. Delade databaser fokuserar f\u00f6r mycket p\u00e5 en enda punkt, vilket hindrar utvecklingen av framsteg. Vi hamnar oundvikligen i en cykel av otillr\u00e4cklighet av data:<\/p>\n

\"Data
\n Cykel av otillr\u00e4cklighet av data<\/i><\/p>\n

Fl\u00f6den: en decentraliserad metod f\u00f6r data och tj\u00e4nster<\/h3>\n

\n I idealfallet beh\u00f6ver vi f\u00f6r\u00e4ndra s\u00e4ttet p\u00e5 vilket tj\u00e4nster arbetar med gemensam data. Just nu st\u00e5r varje metod inf\u00f6r den tidigare n\u00e4mnda dikotomin, eftersom det inte finns n\u00e5gon magisk l\u00f6sning som kan str\u00f6s gener\u00f6st f\u00f6r att f\u00e5 den att f\u00f6rsvinna. Men vi kan omformulera problemet och n\u00e5 en kompromiss.<\/p>\n

Denna kompromiss inneb\u00e4r en viss grad av centralisering. Vi kan dra nytta av mekanismen f\u00f6r distribuerade loggar, eftersom den erbjuder tillf\u00f6rlitliga skalbara fl\u00f6den. Nu beh\u00f6ver tj\u00e4nster kunna ansluta och arbeta med dessa gemensamma fl\u00f6den, men vi vill undvika komplexa centraliserade God Service:er som utf\u00f6r s\u00e5dan bearbetning. D\u00e4rf\u00f6r \u00e4r det b\u00e4sta alternativet att integrera str\u00f6mbehandling i varje tj\u00e4nst-konsument. P\u00e5 s\u00e5 s\u00e4tt kan tj\u00e4nster kombinera datam\u00e4ngder fr\u00e5n olika k\u00e4llor och arbeta med dem som de beh\u00f6ver.<\/p>\n

Ett s\u00e4tt att n\u00e5 en s\u00e5dan metod \u00e4r att anv\u00e4nda en str\u00f6mmande plattform. Det finns m\u00e5nga alternativ, men idag kommer vi att titta p\u00e5 just Kafka, eftersom dess Stateful Stream Processing effektivt l\u00f6ser det presenterade problemet.<\/p>\n

\"Data
\n
\n Anv\u00e4ndningen av mekanismen f\u00f6r distribuerad loggning g\u00f6r att vi kan g\u00e5 p\u00e5 den stig som redan har trampats, och anv\u00e4nda meddelandefl\u00f6den f\u00f6r att arbeta med h\u00e4ndelseorienterad arkitektur<\/a><\/noindex>. Det anses att detta tillv\u00e4gag\u00e5ngss\u00e4tt ger b\u00e4ttre skalbarhet och separation \u00e4n \"request-response\"-mekanismen, eftersom det ger mottagaren snarare \u00e4n avs\u00e4ndaren kontroll \u00f6ver fl\u00f6det. Men f\u00f6r allt i livet f\u00e5r man betala, och h\u00e4r beh\u00f6ver du en broker. Men f\u00f6r stora system \u00e4r denna kompromiss v\u00e4rd det (vilket inte g\u00e4ller f\u00f6r dina genomsnittliga webbapplikationer).<\/p>\n

Om det distribuerade loggandet hanteras av en broker snarare \u00e4n ett traditionellt meddelandesystem kan ytterligare funktioner utnyttjas. Transporten kan skalas linj\u00e4rt n\u00e4stan lika bra som ett distribuerat filsystem. Data kan lagras i loggar ganska l\u00e4nge, s\u00e5 vi f\u00e5r inte bara meddelandeutbyte utan ocks\u00e5 lagring av information. Skalbar lagring utan r\u00e4dsla f\u00f6r att f\u00e5 ett f\u00f6r\u00e4ndrat gemensamt tillst\u00e5nd.<\/p>\n

D\u00e4refter kan en stateful stream processing-mekanism (bearbetning av str\u00f6m med bevarande av tillst\u00e5nd) anv\u00e4ndas f\u00f6r att l\u00e4gga till deklarativa databasverktyg i konsumenttj\u00e4nster. Detta \u00e4r en mycket viktig tanke. S\u00e5 l\u00e4nge data lagras i gemensamma str\u00f6mmar, som alla tj\u00e4nster kan f\u00e5 tillg\u00e5ng till, \u00e4r sammanfogningen och bearbetningen som g\u00f6rs av tj\u00e4nsten privata. De visar sig vara isolerade inom en strikt begr\u00e4nsad kontext.<\/p>\n

\"Data
\n Bli av med dikotomin av data genom att dela upp den immutabla fl\u00f6det av tillst\u00e5nd. L\u00e4gg sedan till denna funktion i varje tj\u00e4nst med hj\u00e4lp av Stateful Stream Processing.<\/i><\/p>\n

S\u00e5 om din tj\u00e4nst m\u00e5ste arbeta med best\u00e4llningar, produktkataloger, lager, s\u00e5 kommer den att ha full tillg\u00e5ng: endast du best\u00e4mmer vilka data som ska sammanfogas, var de ska bearbetas och hur de ska f\u00f6r\u00e4ndras \u00f6ver tid. Trots att data \u00e4r gemensamma, \u00e4r arbetet med dem helt decentraliserat. Det utf\u00f6rs inom varje tj\u00e4nst, i en v\u00e4rld d\u00e4r allt g\u00e5r efter dina regler.<\/p>\n

\"Data
\nDela data p\u00e5 ett s\u00e4tt som inte bryter deras integritet. Kapsla in funktionen, inte k\u00e4llan, i varje tj\u00e4nst som beh\u00f6ver den.<\/i><\/p>\n

Det h\u00e4nder att data beh\u00f6ver flyttas i bulk. Ibland kr\u00e4ver tj\u00e4nsten ett lokalt historiskt dataset i den valda databashanteraren. Nyckeln \u00e4r att man kan garantera att en kopia kan \u00e5terst\u00e4llas fr\u00e5n k\u00e4llan vid behov genom att anv\u00e4nda den distribuerade loggmekanismen. Anslutare i Kafka g\u00f6r ett utm\u00e4rkt jobb med denna uppgift.<\/p>\n

S\u00e5, den metod vi diskuterat idag har flera f\u00f6rdelar:<\/p>\n