{"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\/nl\/blog\/administrirovanie\/dihotomiya-dannyh-pereosmyslenie-otnosheniya-k-dannym-i-servisam","title":{"rendered":"Data dichotomie: heroverweging van de relatie tot data en diensten","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo allemaal! We hebben geweldig nieuws, in juni lanceert OTUS opnieuw een cursus Software Architect<\/a><\/noindex>, daarom delen we traditioneel nuttige materialen met jullie.<\/b><\/i><\/p>\n

\"Data
\n
\n Als je met het hele verhaal van microservices zonder enige context te maken hebt gehad, is het begrijpelijk dat je het een beetje vreemd vindt. Het opsplitsen van een applicatie in fragmenten die met elkaar verbonden zijn via een netwerk betekent ongetwijfeld dat er complexe failover-modi aan het resulterende gedistribueerde systeem moeten worden toegevoegd. <\/p>\n

Hoewel deze aanpak inhoudt dat we opsplitsen in meerdere onafhankelijke diensten, is het einddoel veel groter dan alleen dat deze diensten op verschillende machines functioneren. Het gaat hier om interactie met de omringende wereld, die van nature ook gedistribueerd is. Niet in technische zin, maar eerder in termen van een ecosysteem dat bestaat uit vele mensen, teams, programma's, en elk van deze delen moet op zijn manier zijn werk doen.<\/a><\/noindex><\/p>\n

Bedrijven zijn bijvoorbeeld een verzameling gedistribueerde systemen die gezamenlijk bijdragen aan het bereiken van een bepaald doel. We hebben dit feit decennialang genegeerd, in de hoop op integratie, door bestanden via FTP over te dragen of gebruik te maken van bedrijfsintegratietools, terwijl we ons concentreerden op onze persoonlijke, afgescheiden doelen. Maar met de komst van diensten is alles veranderd. Diensten hebben ons geholpen om verder te kijken en de wereld van onderling afhankelijke programma's die samen werken te zien. Om echter succesvol te zijn, is het belangrijk om twee fundamenteel verschillende werelden te begrijpen en te ontwerpen: de externe wereld, waarin we leven in een ecosysteem van andere diensten, en onze persoonlijke, interne wereld, waar we alleen heersen.<\/p>\n

\"Data
\n
\n Zo'n gedistribueerde wereld verschilt van de wereld waarin we zijn opgegroeid en waaraan we gewend zijn. De principes van traditionele monolithische architectuur zijn niet houdbaar. Daarom is het juiste begrip van dergelijke systemen meer dan het cre\u00ebren van een mooi schema op een whiteboard of een cool bewijs van concept. Het gaat erom dat zo'n systeem met succes lange tijd functioneert. Gelukkig bestaan diensten al een behoorlijke tijd, hoewel ze er verschillend uitzien. Lessen van SOA<\/a><\/noindex> blijven relevant, zelfs gekruid met Docker, Kubernetes en lichtelijk gehavend door hipsterbaarden. <\/p>\n

Dus, vandaag bekijken we hoe de regels zijn veranderd, waarom we onze benadering van diensten en de gegevens die ze onderling uitwisselen opnieuw moeten overdenken, en waarom we hiervoor een totaal andere set tools nodig hebben.<\/p>\n

Encapsulatie zal niet altijd je vriend zijn.<\/h3>\n

\n Microservices kunnen onafhankelijk van elkaar functioneren. Dit kenmerk is hun grootste waarde. Ditzelfde kenmerk stelt diensten in staat om te schalen en te groeien. Niet zozeer in de zin van schalen naar quadriljoenen gebruikers of petabytes aan data (hoewel ze daar ook kunnen helpen), maar in de zin van schalen vanuit een mensenperspectief, aangezien teams en organisaties voortdurend groeien.<\/p>\n

\"Data
\n
\nEchter, onafhankelijkheid is een tweesnijdend zwaard. Dit betekent dat een dienst op zichzelf eenvoudig en soepel kan draaien. Maar als binnen die dienst een functie wordt ge\u00efmplementeerd die een andere dienst vereist, moeten we uiteindelijk beide diensten bijna gelijktijdig aanpassen. In een monolith is dit eenvoudig, je maakt gewoon de wijziging en brengt deze uit, terwijl synchronisatie tussen onafhankelijke diensten meer problemen met zich meebrengt. Co\u00f6rdinatie tussen teams en releasecycli ondermijnt de flexibiliteit.<\/p>\n

\"Data
\n
\nIn een standaardbenadering worden hinderlijke cross-cutting wijzigingen vaak simpelweg vermeden door functionaliteit duidelijk te splitsen tussen diensten. Een enkele toegangspoort tot het systeem kan hier een goed voorbeeld van zijn. Dit heeft een duidelijk afgebakende rol die het onderscheidt van andere diensten. Dergelijke duidelijke scheiding betekent dat in de snel veranderende wereld van de eisen van omliggende diensten, de toegangspoort tot het systeem waarschijnlijk niet zal veranderen. Het functioneert binnen een strikt afgebakende context.<\/p>\n

\"Data
\n
\n Het probleem is dat bedrijfsservices in de echte wereld niet altijd een zuivere scheiding van rollen kunnen behouden. Zo werken deze diensten in grote mate met gegevens die afkomstig zijn van andere soortgelijke diensten. Als je je bezighoudt met online retail, wordt het verwerken van bestellingen, productcatalogi of informatie over gebruikers een vereiste voor veel van je diensten. Elke dienst heeft toegang tot deze gegevens nodig om te kunnen functioneren. <\/p>\n

\"Data
\nDe meeste bedrijfsservices maken gebruik van dezelfde gegevensstroom, waardoor hun werking onvermijdelijk met elkaar verweven is.<\/i><\/p>\n

Zo zijn we aan een belangrijk punt gekomen dat het waard is om over te praten. Terwijl diensten goed functioneren voor infrastructuurcomponenten die grotendeels afzonderlijk werken, zijn de meeste bedrijfsservices veel dichter met elkaar verweven.<\/p>\n

Dichotomie van gegevens<\/h3>\n

\n Dienstenori\u00ebntatiestrategie\u00ebn bestaan misschien al, maar er is nog steeds weinig informatie beschikbaar over hoe grote hoeveelheden gegevens tussen diensten kunnen worden uitgewisseld.<\/p>\n

Het kernprobleem is dat gegevens en diensten onlosmakelijk met elkaar verbonden zijn. Enerzijds roept encapsulatie ons op om gegevens te verbergen, zodat diensten van elkaar kunnen worden gescheiden en hun groei en verdere veranderingen kunnen vergemakkelijken. Aan de andere kant moeten we de mogelijkheid hebben om vrij te delen en te beschikken over gemeenschappelijke gegevens, net als over andere. Het gaat erom dat we onmiddellijk kunnen beginnen te werken, net zo vrij als in elk ander informatiesysteem.<\/p>\n

Echter, informatiesystemen hebben weinig te maken met encapsulatie. Sterker nog, ze zijn eerder het tegenovergestelde. Databases doen er alles aan om toegang te geven tot de gegevens die ze bevatten. Ze worden geleverd met een krachtige declaratieve interface die je in staat stelt om de gegevens aan te passen zoals je wilt. Deze functionaliteit is belangrijk in de onderzoeksfase, maar niet voor het beheren van de toenemende complexiteit van een voortdurend evoluerende dienst.<\/p>\n

\"Data
\n
\n En hier ontstaat de dilemma. Een contradictie. Een dichotomie. Informatiesystemen zijn gericht op het leveren van gegevens, terwijl diensten gericht zijn op het verbergen ervan.<\/p>\n

Deze twee krachten zijn fundamenteel. Ze vormen de basis van het grootste deel van ons werk, voortdurend strijdbaar voor superioriteit in de systemen die we cre\u00ebren.<\/p>\n

Naarmate de servicetechnologie\u00ebn groeien en evolueren, zien we verschillende manifestaties van de gevolgen van de datadichotomie. Ofwel groeit de interface van de service en biedt een steeds breder scala aan functies, waardoor het op een bijzondere zelfgemaakte database begint te lijken, of we worden geconfronteerd met teleurstelling en realiseren we een manier om massaal hele datasets van de ene service naar de andere te extraheren of te verplaatsen.<\/p>\n

\"Data
\n
\n De creatie van iets dat eruitziet als een bijzondere zelfgemaakte database leidt tot een aantal problemen. We gaan niet in detail treden over wat er gevaarlijk aan is, shared database<\/i>, laten we gewoon zeggen dat het aanzienlijke kostbare technische en operationele uitdagingen<\/a><\/noindex> voor een bedrijf dat het probeert te gebruiken.<\/p>\n

Erger nog, de hoeveelheden data vermenigvuldigen de problemen met de grenzen van diensten. Hoe meer gedeelde gegevens er binnen een service liggen, hoe moeilijker de interface wordt en hoe moeilijker het wordt om datasets samen te voegen die uit verschillende services komen.<\/p>\n

Een alternatieve benadering van het extraheren en verplaatsen van hele datasets heeft ook zijn problemen. Een gebruikelijke benadering van deze kwestie lijkt op een eenvoudige extractie en opslag van een dataset in zijn geheel, om het vervolgens lokaal op te slaan in elke consumentservice.<\/p>\n

\"Data
\n
\n Het probleem is dat verschillende services gegevens op verschillende manieren interpreteren. Deze gegevens zijn altijd beschikbaar. Ze worden lokaal gewijzigd en verwerkt. Vrij snel hebben ze niets meer gemeen met de gegevens in de bron.<\/p>\n

\"Data
\n Naarmate de kopie\u00ebn mutabeler worden, zullen de gegevens meer uit elkaar gaan lopen in de loop van de tijd.<\/i><\/p>\n

Wat nog erger is, zulke gegevens zijn moeilijk te corrigeren in retrospectief (MDM<\/a><\/noindex> dat kan hier echt bij helpen). In feite ontstaan enkele van de moeilijk op te lossen technische problemen waarmee bedrijven worden geconfronteerd door heterogene data die zich van applicatie naar applicatie vermenigvuldigen.<\/p>\n

Om een oplossing voor dit probleem met gedeelde data te vinden, moet anders worden nagedacht. Ze moeten objecten van de eerste klas worden in de architecturen die we bouwen. Pat Helland<\/a><\/noindex> noemt dergelijke gegevens 'extern', en dit is een zeer belangrijk kenmerk. We hebben encapsulatie nodig om de interne werking van de service niet prijs te geven, maar we moeten de services toegang geven tot gedeelde gegevens zodat ze hun werk goed kunnen uitvoeren.<\/p>\n

\"Data
\n
\n Het probleem is dat geen van de benaderingen vandaag de dag nog actueel is, omdat geen van de service-interface, berichtenuitwisseling of Shared Database een goede oplossing biedt voor het werken met externe gegevens. Service-interfaces zijn niet goed geschikt voor gegevensuitwisseling op enige schaal. Berichtenuitwisselingen verplaatsen gegevens, maar houden hun geschiedenis niet bij, waardoor gegevens in de loop van de tijd beschadigd raken. Shared Databases zijn te gefocust op \u00e9\u00e9n punt, wat de voortgang remt. We komen onvermijdelijk vast te zitten in een cyclus van gegevensongeschiktheid:<\/p>\n

\"Data
\n Cyclus van gegevensongeschiktheid<\/i><\/p>\n

Stromen: een gedecentraliseerde benadering van gegevens en services<\/h3>\n

\n Ideaal gezien moeten we de manier waarop services met gedeelde gegevens werken heroverwegen. Momenteel wordt elke benadering geconfronteerd met de hierboven genoemde dichotomie, aangezien er geen enkele magische oplossing is die overvloedig kan worden gestrooid om het te laten verdwijnen. Echter, we kunnen het probleem heroverwegen en tot een compromis komen.<\/p>\n

Dit compromis houdt een zekere mate van centralisatie in. We kunnen gebruik maken van een mechanisme voor gedistribueerde logboeken, omdat dit betrouwbare en schaalbare stromen biedt. Nu is het nodig dat de services zich kunnen aansluiten en met deze gedeelde stromen kunnen werken, maar we willen complexe gecentraliseerde God Services, die deze verwerking uitvoeren, vermijden. Daarom is de beste optie om streamverwerking in elke serviceconsument te integreren. Zo kunnen services datasets uit verschillende bronnen combineren en ermee werken zoals ze dat nodig hebben.<\/p>\n

Een van de manieren om een dergelijke benadering te bereiken, is door gebruik te maken van een streamingplatform. Er zijn veel opties, maar vandaag bekijken we specifiek Kafka, omdat het gebruik van zijn Stateful Stream Processing ons in staat stelt om het gepresenteerde probleem effectief op te lossen.<\/p>\n

\"Data
\n
\n Het gebruik van een mechanisme voor gedistribueerde logging stelt ons in staat om het pad te volgen, en berichtenuitwisseling te gebruiken om te werken met evenementgerichte architectuur<\/a><\/noindex>. Men denkt dat deze benadering betere schaalbaarheid en splitsing biedt dan het 'verzoek-antwoorden'-mechanisme, omdat het de controle over de stroom aan de ontvanger geeft, niet aan de verzender. Maar voor alles in het leven moet je betalen, en hiervoor heb je een broker nodig. Maar voor grote systemen is deze compromis het waard (wat je niet over je gemiddelde webapplicaties kunt zeggen).<\/p>\n

Als de gedistribueerde logging door een broker wordt afgehandeld en niet door een traditioneel berichtensysteem, kunt u gebruikmaken van aanvullende functies. Vervoer kan bijna net zo goed lineair worden geschaald als een gedistribueerd bestandssysteem. Gegevens kunnen lang genoeg in logs worden opgeslagen, zodat we niet alleen berichtenuitwisseling krijgen, maar ook een opslag van informatie. Schaalbare opslag zonder angst voor een wijzigbare gezamenlijke toestand.<\/p>\n

U kunt dan een stateful stream processing-mechanisme gebruiken om declaratieve database-tools toe te voegen aan consumentservices. Dit is een zeer belangrijk idee. Terwijl gegevens in gedeelde streams worden opgeslagen, waartoe alle services toegang hebben, zijn de samenvoegingen en verwerkingen die de service uitvoert priv\u00e9. Ze zijn ge\u00efsoleerd binnen een strikt afgebakende context.<\/p>\n

\"Data
\n Verbreek de gegevensdichotomie door de immutabele toestandstroom op te splitsen. Voeg deze functie vervolgens toe aan elke service met behulp van Stateful Stream Processing.<\/i><\/p>\n

Zo heeft uw service, als deze met bestellingen, productcatalogi en voorraad moet werken, volledige toegang: alleen u beslist welke gegevens moeten worden samengevoegd, waar ze moeten worden verwerkt en hoe ze in de loop van de tijd moeten veranderen. Hoewel de gegevens gemeenschappelijk zijn, is het werken ermee volledig gedecentraliseerd. Het gebeurt binnen elke service, in een wereld waar alles volgens uw regels gaat.<\/p>\n

\"Data
\nDeel gegevens op een manier die hun integriteit niet schaadt. Encapuleer de functie, niet de bron, in elke service die deze nodig heeft.<\/i><\/p>\n

Het komt voor dat gegevens in bulk moeten worden verplaatst. Soms heeft de service een lokale historische set gegevens nodig in de gekozen database-engine. Het punt is dat je kunt garanderen dat een kopie, indien nodig, kan worden hersteld vanuit de bron door gebruik te maken van de distributielogmechanisme. De connectors in Kafka presteren uitstekend voor deze taak.<\/p>\n

Dus de benadering die we vandaag hebben besproken, heeft verschillende voordelen:<\/p>\n