Datadikotomi: att tänka om förhållandet mellan data och tjänster

Hej alla! Vi har goda nyheter, OTUS lanserar kursen igen i juni "Mjukvaruarkitekt", i samband med vilket vi traditionellt delar användbart material med dig.

Om du har stött på hela den här berättelsen om mikrotjänster utan något sammanhang, skulle du bli förlåten för att du tycker att det är lite konstigt. Att dela upp en applikation i fragment som är anslutna till ett nätverk innebär med nödvändighet att lägga till komplexa feltoleranslägen till det resulterande distribuerade systemet.

Även om detta tillvägagångssätt innebär uppdelning i många oberoende tjänster, är slutmålet mycket mer än att bara köra dessa tjänster på olika maskiner. Vi talar här om interaktion med omvärlden, som också är fördelad i sitt väsen. Inte i teknisk mening, utan snarare i betydelsen av ett ekosystem som består av många människor, team, program, och var och en av dessa delar måste göra sitt jobb på ett eller annat sätt.

Företag är till exempel en uppsättning distribuerade system som tillsammans bidrar till att nå något mål. Vi har ignorerat detta faktum i decennier, försökt uppnå enande genom FTP-överföringar eller verktyg för företagsintegration, samtidigt som vi fokuserar på våra egna separata mål. Men med tillkomsten av tjänster har allt förändrats. Tjänster har hjälpt oss att se bortom horisonten och se en värld av ömsesidigt beroende program som fungerar tillsammans. Men för att fungera framgångsrikt är det nödvändigt att känna igen och designa två fundamentalt olika världar: den yttre världen, där vi lever i ett ekosystem av många andra tjänster, och vår personliga, inre värld, där vi styr ensamma.

En sådan distribuerad värld är annorlunda än den vi växte upp i och är vana vid. Principerna för att bygga en traditionell monolitisk arkitektur står inte emot kritik. Så att få dessa system rätt handlar om mer än att skapa ett coolt whiteboarddiagram eller ett coolt proof of concept. Tanken är att ett sådant system ska fungera framgångsrikt under lång tid. Som tur är har tjänsterna funnits ganska länge, även om de ser annorlunda ut. SOA-lektioner fortfarande relevant, till och med kryddat med Docker, Kubernetes och lite sjaskiga hipsterskägg.

Så idag ska vi ta en titt på hur reglerna har förändrats, varför vi behöver tänka om vår inställning till tjänster och den data de skickar till varandra, och varför vi kommer att behöva en helt annan verktygslåda för det.

Encapsulation kommer inte alltid att vara din vän

Mikrotjänster kan arbeta oberoende av varandra. Det är denna egenskap som ger dem störst värde. Samma egenskap gör att tjänster kan skalas och växa. Inte så mycket när det gäller skalning till kvadriljoner användare eller petabyte av data (även om de kan hjälpa till här också), utan när det gäller skalning i termer av människor när team och organisationer växer kontinuerligt.

Men oberoende är ett tveeggat svärd. Det vill säga att själva tjänsten kan snurra enkelt och naturligt. Men om en funktion implementeras inuti en tjänst som kräver att en annan tjänst är involverad, då slutar vi med att vi måste göra ändringar i båda tjänsterna nästan samtidigt. I en monolit är detta lätt att göra, du gör bara en ändring och skickar den till release, men i fallet med synkronisering av oberoende tjänster kommer det att bli fler problem. Samordning mellan team och releasecykler förstör flexibiliteten.

Som en del av standardmetoden försöker de helt enkelt undvika irriterande förändringar från början till slut, vilket tydligt delar upp funktionaliteten mellan tjänsterna. Single sign-on-tjänst kan vara ett bra exempel här. Den har en väldefinierad roll som skiljer den från andra tjänster. Denna tydliga åtskillnad innebär att i en värld av snabbt föränderliga krav på tjänsterna runtomkring är det osannolikt att SSO kommer att förändras. Den existerar inom ett strikt begränsat sammanhang.

Problemet är att i den verkliga världen kan företagstjänster inte hålla samma rena rolluppdelning hela tiden. Till exempel fungerar samma företagstjänster mer med data som kommer från andra liknande tjänster. Om du är en onlineåterförsäljare kommer hantering av orderflöde, produktkatalog eller användarinformation att bli ett krav för många av dina tjänster. Var och en av tjänsterna kommer att behöva tillgång till denna data för att fungera.

De flesta företagstjänster använder samma dataström, så deras arbete är alltid sammanflätat.

Därmed kommer vi till en viktig punkt som är värd att prata om. Även om tjänster fungerar bra för infrastrukturkomponenter som till stor del fungerar isolerat, blir de flesta företagstjänster mycket tätare sammanflätade.

Datadikotomi

Tjänsteorienterade tillvägagångssätt kan redan finnas, men det finns fortfarande lite information om hur man utbyter stora mängder data mellan tjänster.

Det största problemet är att data och tjänster är oskiljaktiga. Å ena sidan uppmuntrar inkapsling oss att dölja data så att tjänster kan separeras från varandra och underlätta deras tillväxt och ytterligare förändringar. Å andra sidan måste vi kunna dela och erövra fritt över delad data, precis som alla andra. Det handlar om att kunna börja arbeta direkt, lika fritt som i vilket informationssystem som helst.

Informationssystem har dock lite med inkapsling att göra. Faktum är att det till och med är tvärtom. Databaser gör allt de kan för att ge tillgång till den data de lagrar. De kommer med ett kraftfullt deklarativt gränssnitt som låter dig ändra data hur du vill. Sådan funktionalitet är viktig vid preliminär forskning, men inte för att hantera den växande komplexiteten hos en tjänst som ständigt utvecklas.

Och här uppstår ett dilemma. Motsägelse. Dikotomi. När allt kommer omkring handlar informationssystem om att tillhandahålla data, och tjänster handlar om att gömma sig.

Dessa två krafter är grundläggande. De ligger till grund för mycket av vårt arbete och tävlar ständigt om överhöghet i de system vi bygger.

När tjänstesystem växer och utvecklas ser vi olika manifestationer av implikationerna av datadikotomi. Antingen kommer tjänstegränssnittet att växa för att ge mer och mer funktionalitet och börja se ut som en mycket snygg hemmagjord databas, eller så kommer vi att bli frustrerade och implementera något sätt att hämta eller flytta hela datamängder i bulk från tjänst till tjänst.

I sin tur kommer att skapa något som ser ut som en fancy hembryggningsdatabas leda till en mängd problem. Vi kommer inte gå in på detaljer om vad som är farligt delad databas, låt oss bara säga att det representerar en betydande kostsam konstruktion och drift svårigheter för företaget som försöker använda det.

Ännu värre, datavolymer multiplicerar problem med tjänstegränser. Ju vanligare data som finns i tjänsten, desto mer komplext blir gränssnittet och desto svårare blir det att kombinera datamängder som kommer från olika tjänster.

Det alternativa tillvägagångssättet att extrahera och flytta hela datamängder har också sina egna problem. Ett vanligt tillvägagångssätt för denna fråga verkar vara att helt enkelt hämta och lagra hela datasetet och sedan lagra det lokalt i varje konsumerande tjänst.

Problemet är att olika tjänster tolkar data de konsumerar olika. Dessa uppgifter finns alltid till hands. De modifieras och bearbetas lokalt. Ganska snart slutar de att ha något att göra med uppgifterna i källan.

Ju mer föränderliga kopiorna är, desto mer kommer data att variera över tiden.

Ännu värre, sådana uppgifter är svåra att korrigera i efterhand (MDM det är här det verkligen kommer till användning.) Faktum är att några av de svårlösta tekniska utmaningarna som företag står inför härrör från heterogena data som sprider sig från applikation till applikation.

För att hitta en lösning på detta vanliga dataproblem måste du tänka annorlunda. De ska bli förstklassiga objekt i de arkitekturer vi bygger. Pat Helland kallar sådan data "extern", och detta är en mycket viktig funktion. Vi behöver inkapsling så att vi inte exponerar det interna i en tjänst, men vi måste göra det enkelt för tjänster att komma åt delad data så att de kan göra sitt jobb korrekt.

Problemet är att inget av tillvägagångssätten är relevant idag, eftersom varken tjänstens gränssnitt, meddelanden eller den delade databasen erbjuder en bra lösning för att arbeta med extern data. Tjänstegränssnitt är illa lämpade för utbyte av data i vilken skala som helst. Meddelanden flyttar data men lagrar inte dess historik, så data skadas med tiden. Delade databaser är för mycket fokuserade på en punkt, vilket håller tillbaka framsteg. Vi fastnar oundvikligen i en cykel av datafel:

Datafelscykel

Flöden: ett decentraliserat förhållningssätt till data och tjänster

Helst måste vi förändra hur tjänster fungerar med delad data. För tillfället löper varje tillvägagångssätt in i den tidigare nämnda dikotomien, eftersom det inte finns något magiskt damm som generöst kan strö på den och få den att försvinna. Men vi kan tänka om problemet och komma fram till en kompromiss.

Denna kompromiss innebär en viss grad av centralisering. Vi kan dra fördel av den distribuerade loggningsmekanismen eftersom den ger pålitliga, skalbara strömmar. Nu vill vi att tjänster ska kunna gå med och köras på dessa delade trådar, men vi vill undvika komplexa centraliserade gudstjänster som gör denna bearbetning. Därför är det bästa alternativet att bygga in streamingbearbetning i varje konsumenttjänst. Detta gör att tjänster kan kombinera datamängder från olika källor och arbeta med dem på det sätt de behöver.

Ett sätt att uppnå detta tillvägagångssätt är genom att använda en streamingplattform. Det finns många alternativ, men idag kommer vi att överväga Kafka, eftersom användningen av dess Stateful Stream Processing tillåter oss att effektivt lösa det presenterade problemet.

Genom att använda den distribuerade loggningsmekanismen kan vi följa den misshandlade vägen och använda meddelanden att arbeta med händelsedriven arkitektur. Detta tillvägagångssätt anses ge bättre skalning och separation än begäran-svarsmekanismen eftersom det ger kontroll över flödet till mottagaren snarare än sändaren. Du måste dock betala för allt här i livet, och här behöver du en mäklare. Men för stora system är denna avvägning värt det (vilket du inte kan säga om dina genomsnittliga webbapplikationer).

Om en mäklare ansvarar för distribuerad loggning, och inte ett traditionellt meddelandesystem, kan du dra nytta av ytterligare funktioner. En transport kan skalas linjärt nästan lika bra som ett distribuerat filsystem. Data kan lagras i loggar under lång tid, så vi får inte bara meddelanden, utan också ett arkiv med information. Skalbar lagring utan rädsla för föränderligt delat tillstånd.

Du kan sedan använda mekanismen för stateful strömbehandling för att lägga till deklarativa databasverktyg till dina konsumerande tjänster. Detta är en mycket viktig tanke. Så länge data lagras i delade strömmar som kan nås av alla tjänster, är aggregeringen och bearbetningen som tjänsten gör privat. De är isolerade inom ett strikt begränsat sammanhang.

Bli av med datadikotomien genom att dela upp den oföränderliga tillståndsströmmen. Lägg sedan till den här funktionen till varje tjänst med Stateful Stream Processing.

Således, om din tjänst måste fungera med beställningar, en produktkatalog, ett lager, kommer den att ha full tillgång: bara du bestämmer vilken data som ska kombineras, var den ska behandlas och hur den ska förändras över tiden. Trots att data delas är arbetet med det helt decentraliserat. Den produceras inom varje tjänst, i en värld där allt går enligt dina regler.

Dela data utan att kompromissa med dess integritet. Kapsla in en funktion, inte en källa, i varje tjänst som behöver den.

Så det händer att data måste flyttas i bulk. Ibland behöver en tjänst en lokal historisk datauppsättning i den valda databasmotorn. Tricket är att det kan garanteras att en kopia vid behov kan återställas från källan genom att kontakta den distribuerade loggningsmekanismen. Connectors i Kafka gör ett bra jobb med detta.

Så tillvägagångssättet som diskuteras idag har flera fördelar:

• Datan används i form av delade strömmar som kan lagras i loggar under lång tid, och mekanismen för att arbeta med delad data är hårdkopplad i varje enskilt sammanhang, vilket gör att tjänsterna fungerar enkelt och snabbt. På så sätt kan datadikotomien balanseras.
• Data som kommer från olika tjänster kan enkelt kombineras till uppsättningar. Detta förenklar interaktion med delad data och eliminerar behovet av att underhålla lokala datauppsättningar i databasen.
• Stateful Stream Processing cachar bara data, och de vanliga loggarna förblir källan till sanningen, så problemet med datakorruption över tid är inte så akut.
• I kärnan är tjänsterna datadrivna, vilket innebär att trots den ständiga ökningen av datavolymer kan tjänster fortfarande reagera snabbt på affärshändelser.
• Skalbarhetsproblem faller på mäklaren, inte tjänsterna. Detta minskar skrivtjänsternas komplexitet avsevärt, eftersom det inte finns något behov av att tänka på skalbarhet.
• Att lägga till nya tjänster kräver inte att man byter gamla, så det blir lättare att ansluta nya tjänster.

Som du kan se är det mer än bara VILA. Vi har fått en uppsättning verktyg som gör att du kan arbeta med delad data på ett decentraliserat sätt.

Alla aspekter har inte avslöjats i dagens artikel. Vi behöver fortfarande ta reda på hur vi ska balansera mellan begäran-svar-paradigmet och det händelsestyrda paradigmet. Men vi kommer att ta itu med detta nästa gång. Det finns ämnen som du behöver lära dig bättre, till exempel varför Stateful Stream Processing är så bra. Vi kommer att prata om detta i den tredje artikeln. Och det finns andra kraftfulla konstruktioner som vi kan använda om vi tar till dem, t.ex. Exakt en gång Bearbetning. Det är en game changer för distribuerade affärssystem eftersom det ger transaktionsgarantier för XA i skalbar form. Detta kommer att diskuteras i den fjärde artikeln. Slutligen kommer vi att behöva gå igenom detaljerna kring genomförandet av dessa principer.

Men för nu, kom bara ihåg detta: datadikotomi är en kraft vi möter när vi bygger företagstjänster. Och vi måste komma ihåg detta. Tricket är att vända på allt och börja behandla delad data som förstklassiga objekt. Stateful Stream Processing ger en unik kompromiss för detta. Den undviker centraliserade "Gudskomponenter" som håller tillbaka framsteg. Dessutom ger den smidighet, skalbarhet och motståndskraft för dataströmningspipelines och lägger till dem i varje tjänst. Därför kan vi fokusera på den allmänna medvetandeströmmen som vilken tjänst som helst kan ansluta till och arbeta med sin data. Detta gör tjänsterna mer skalbara, utbytbara och autonoma. Därför kommer de inte bara att se bra ut på whiteboardtavlor och när man testar hypoteser, utan även fungera och utvecklas i decennier.

Läs mer om kursen.

Källa: will.com