Dag Allemaal! We hebben geweldig nieuws, OTUS lanceert de cursus in juni weer , in verband waarmee wij traditioneel nuttig materiaal met u delen.
Als je dit hele microservices-gedoe zonder enige context bent tegengekomen, zou het je vergeven zijn als je denkt dat het een beetje vreemd is. Het opsplitsen van een applicatie in fragmenten die door een netwerk zijn verbonden, betekent noodzakelijkerwijs het toevoegen van complexe fouttolerantiemodi aan het resulterende gedistribueerde systeem.
Hoewel deze aanpak inhoudt dat het in veel onafhankelijke services wordt opgesplitst, is het einddoel veel meer dan alleen het laten draaien van die services op verschillende machines. We hebben het hier over de interactie met de buitenwereld, die in essentie ook gedistribueerd is. Niet in technische zin, maar eerder in de zin van een ecosysteem dat bestaat uit veel mensen, teams, programma's, en elk van deze onderdelen moet op de een of andere manier zijn werk doen.
Bedrijven zijn bijvoorbeeld een verzameling gedistribueerde systemen die gezamenlijk bijdragen aan het bereiken van een bepaald doel. We hebben dit feit tientallen jaren genegeerd en geprobeerd eenwording te bereiken door bestanden te FTP-en of bedrijfsintegratietools te gebruiken, terwijl we ons op onze eigen geïsoleerde doelen concentreerden. Maar met de komst van diensten veranderde alles. Diensten hebben ons geholpen verder te kijken dan de horizon en een wereld van onderling afhankelijke programma's te zien die samenwerken. Om succesvol te kunnen werken is het echter noodzakelijk om twee fundamenteel verschillende werelden te herkennen en te ontwerpen: de externe wereld, waar we leven in een ecosysteem van vele andere diensten, en onze persoonlijke, interne wereld, waar we alleen regeren.
Deze gedistribueerde wereld is anders dan de wereld waarin we zijn opgegroeid en waaraan we gewend zijn. De principes van het construeren van traditionele monolithische architectuur zijn niet bestand tegen kritiek. Om deze systemen goed te krijgen gaat het dus om meer dan het maken van een cool whiteboarddiagram of een cool proof of concept. Het gaat erom ervoor te zorgen dat een dergelijk systeem gedurende een lange periode succesvol functioneert. Gelukkig bestaan de diensten al een tijdje, al zien ze er anders uit. zijn nog steeds relevant, zelfs gekruid met Docker, Kubernetes en ietwat armoedige hipsterbaarden.
Dus vandaag zullen we kijken naar hoe de regels zijn veranderd, waarom we de manier waarop we diensten benaderen en de gegevens die ze aan elkaar doorgeven, moeten heroverwegen, en waarom we daarvoor compleet andere tools nodig hebben.
Inkapseling zal niet altijd je vriend zijn
Microservices kunnen onafhankelijk van elkaar opereren. Het is deze eigenschap die hen de grootste waarde geeft. Dankzij dezelfde eigenschap kunnen services worden geschaald en gegroeid. Niet zozeer in de zin van opschalen naar miljarden gebruikers of petabytes aan data (hoewel die daar ook kunnen helpen), maar in de zin van opschalen in termen van mensen terwijl teams en organisaties voortdurend groeien.
Onafhankelijkheid is echter een tweesnijdend zwaard. Dat wil zeggen dat de service zelf gemakkelijk en natuurlijk kan werken. Maar als binnen een dienst een functie wordt geïmplementeerd die het gebruik van een andere dienst vereist, dan moeten we uiteindelijk vrijwel gelijktijdig wijzigingen aanbrengen in beide diensten. In een monoliet is dit eenvoudig te doen, u brengt gewoon een wijziging aan en stuurt deze naar de release, maar in het geval van het synchroniseren van onafhankelijke services zullen er meer problemen zijn. Coördinatie tussen teams en releasecycli vernietigt de wendbaarheid.
Als onderdeel van de standaardaanpak proberen ze eenvoudigweg vervelende end-to-end-wijzigingen te vermijden, waarbij de functionaliteit duidelijk tussen services wordt verdeeld. Single sign-on-service kan hier een goed voorbeeld van zijn. Het heeft een duidelijk omschreven rol die het onderscheidt van andere diensten. Deze duidelijke scheiding betekent dat in een wereld met snel veranderende eisen aan de diensten eromheen het onwaarschijnlijk is dat de single sign-on-dienst zal veranderen. Het bestaat binnen een strikt beperkte context.
Het probleem is dat de zakelijke dienstverlening in de echte wereld niet altijd dezelfde zuivere scheiding van rollen kan handhaven. Dezelfde zakelijke diensten werken bijvoorbeeld in grotere mate met gegevens afkomstig van andere soortgelijke diensten. Als u zich bezighoudt met online detailhandel, wordt het verwerken van de orderstroom, productcatalogus of gebruikersinformatie een vereiste voor veel van uw diensten. Elk van de services heeft toegang tot deze gegevens nodig om te kunnen functioneren.
De meeste zakelijke diensten delen dezelfde datastroom, waardoor hun werk steevast met elkaar verweven is.
Zo komen we bij een belangrijk punt dat de moeite waard is om over te praten. Hoewel diensten goed werken voor infrastructuurcomponenten die grotendeels geïsoleerd opereren, zijn de meeste zakelijke diensten uiteindelijk veel nauwer met elkaar verweven.
Dichotomie van gegevens
Servicegerichte benaderingen bestaan misschien al, maar het ontbreekt hen nog steeds aan inzicht in de manier waarop grote hoeveelheden gegevens tussen services kunnen worden gedeeld.
Het grootste probleem is dat data en diensten onlosmakelijk met elkaar verbonden zijn. Aan de ene kant moedigt inkapseling ons aan om gegevens te verbergen, zodat diensten van elkaar kunnen worden gescheiden en hun groei en verdere veranderingen kunnen worden vergemakkelijkt. Aan de andere kant moeten we gedeelde data vrijelijk kunnen verdelen en veroveren, net als alle andere data. Het gaat erom dat u onmiddellijk aan de slag kunt, net zo vrij als in elk ander informatiesysteem.
Informatiesystemen hebben echter weinig te maken met inkapseling. In feite is het precies het tegenovergestelde. Databases doen er alles aan om toegang te bieden tot de gegevens die zij opslaan. Ze worden geleverd met een krachtige declaratieve interface waarmee u de gegevens naar behoefte kunt wijzigen. Dergelijke functionaliteit is belangrijk in de voorbereidende onderzoeksfase, maar niet voor het beheren van de groeiende complexiteit van een voortdurend evoluerende dienst.
En hier ontstaat een dilemma. Tegenspraak. Dichotomie. Informatiesystemen gaan immers over het verstrekken van gegevens, en diensten over het verstoppen.
Deze twee krachten zijn van fundamenteel belang. Ze vormen de basis voor een groot deel van ons werk, waarbij we voortdurend strijden voor uitmuntendheid in de systemen die we bouwen.
Naarmate servicesystemen groeien en evolueren, zien we op veel manieren de gevolgen van datadichotomie. Ofwel zal de service-interface groeien en een steeds breder scala aan functionaliteit bieden en op een zeer fraaie database van eigen bodem gaan lijken, ofwel zullen we gefrustreerd raken en een manier implementeren om grote hoeveelheden gegevens van service naar service op te halen of te verplaatsen.
Op zijn beurt zal het creëren van iets dat lijkt op een mooie database van eigen bodem tot een hele reeks problemen leiden. We zullen niet in details treden over waarom het gevaarlijk is gedeelde database, laten we zeggen dat het aanzienlijke kostbare technische en operationele kosten met zich meebrengt voor het bedrijf dat het probeert te gebruiken.
Wat nog erger is, is dat datavolumes servicegrensproblemen vergroten. Hoe meer gedeelde data binnen een dienst liggen, hoe complexer de interface zal worden en hoe moeilijker het zal zijn om datasets afkomstig van verschillende diensten te combineren.
De alternatieve benadering van het extraheren en verplaatsen van volledige datasets kent ook zijn problemen. Een gebruikelijke benadering van deze vraag lijkt erop dat eenvoudigweg de volledige dataset wordt opgehaald en opgeslagen, en deze vervolgens lokaal wordt opgeslagen in elke verbruikende service.
Het probleem is dat verschillende diensten de gegevens die zij consumeren verschillend interpreteren. Deze gegevens zijn altijd bij de hand. Ze worden lokaal aangepast en verwerkt. Al snel hebben ze niets meer gemeen met de gegevens in de bron.
Hoe veranderlijker de kopieën, hoe meer de gegevens in de loop van de tijd zullen variëren.
Tot overmaat van ramp zijn dergelijke gegevens achteraf moeilijk te corrigeren ( Dit is waar het echt te hulp kan komen). Sommige van de hardnekkige technologische problemen waarmee bedrijven worden geconfronteerd, komen voort uit de ongelijksoortige gegevens die zich van toepassing tot toepassing vermenigvuldigen.
Om een oplossing voor dit probleem te vinden, moeten we anders gaan nadenken over gedeelde data. Ze moeten eersteklas objecten worden in de architecturen die we bouwen. noemt dergelijke gegevens “extern”, en dit is een zeer belangrijk kenmerk. We hebben inkapseling nodig zodat we de interne werking van een dienst niet blootleggen, maar we moeten het voor diensten gemakkelijk maken om toegang te krijgen tot gedeelde gegevens, zodat ze hun werk correct kunnen doen.
Het probleem is dat geen van beide benaderingen vandaag de dag relevant is, omdat noch de service-interfaces, noch de berichtenuitwisseling, noch de gedeelde database een goede oplossing bieden voor het werken met externe gegevens. Service-interfaces zijn slecht geschikt voor gegevensuitwisseling op welke schaal dan ook. Berichten verplaatsen gegevens, maar slaan de geschiedenis ervan niet op, waardoor gegevens na verloop van tijd beschadigd raken. Gedeelde databases concentreren zich te veel op één punt, wat de voortgang belemmert. We komen onvermijdelijk vast te zitten in een cyclus van datafouten:
Cyclus van gegevensfouten
Streams: een gedecentraliseerde benadering van data en diensten
Idealiter moeten we de manier veranderen waarop services met gedeelde gegevens werken. Op dit punt worden beide benaderingen geconfronteerd met de bovengenoemde dichotomie, omdat er geen magisch stof is dat erop kan worden gestrooid om het te laten verdwijnen. We kunnen het probleem echter heroverwegen en tot een compromis komen.
Dit compromis impliceert een zekere mate van centralisatie. We kunnen het gedistribueerde logboekmechanisme gebruiken omdat het betrouwbare, schaalbare streams biedt. We willen nu dat diensten zich kunnen aansluiten bij en kunnen opereren op deze gedeelde threads, maar we willen complexe gecentraliseerde God Services vermijden die deze verwerking uitvoeren. Daarom is de beste optie om streamverwerking in elke consumentenservice in te bouwen. Op deze manier kunnen diensten datasets uit verschillende bronnen combineren en ermee werken op de manier die zij nodig hebben.
Eén manier om deze aanpak te bereiken is door het gebruik van een streamingplatform. Er zijn veel opties, maar vandaag zullen we naar Kafka kijken, omdat het gebruik van zijn Stateful Stream Processing ons in staat stelt het gepresenteerde probleem effectief op te lossen.
Door een gedistribueerd logboekregistratiemechanisme te gebruiken, kunnen we het platgetreden pad volgen en berichten gebruiken om mee te werken . Er wordt aangenomen dat deze aanpak een betere schaling en verdeling biedt dan het verzoek-antwoordmechanisme, omdat het de controle over de stroom aan de ontvanger geeft in plaats van aan de afzender. Voor alles in dit leven moet je echter betalen, en hier heb je een makelaar nodig. Maar voor grote systemen is de afweging de moeite waard (wat misschien niet het geval is voor de gemiddelde webapplicatie).
Als een makelaar verantwoordelijk is voor gedistribueerde logboekregistratie in plaats van een traditioneel berichtensysteem, kunt u profiteren van extra functies. Het transport kan bijna net zo goed lineair worden geschaald als een gedistribueerd bestandssysteem. Gegevens kunnen geruime tijd in logs worden opgeslagen, dus we krijgen niet alleen berichtenuitwisseling, maar ook informatieopslag. Schaalbare opslag zonder de angst voor een veranderlijke gedeelde status.
Vervolgens kunt u stateful stream-verwerking gebruiken om declaratieve databasetools toe te voegen aan de consumerende services. Dit is een heel belangrijk idee. Hoewel de gegevens worden opgeslagen in gedeelde stromen waartoe alle services toegang hebben, is de aggregatie en verwerking die de service uitvoert privé. Ze bevinden zich geïsoleerd binnen een strikt beperkte context.
Elimineer de dichotomie van gegevens door de onveranderlijke statusstroom te scheiden. Voeg deze functionaliteit vervolgens toe aan elke service met behulp van Stateful Stream Processing.
Als uw dienst dus moet werken met bestellingen, een productcatalogus of een magazijn, heeft deze volledige toegang: alleen u beslist welke gegevens u wilt combineren, waar u deze wilt verwerken en hoe deze in de loop van de tijd moeten veranderen. Ondanks dat de data gedeeld worden, wordt er volledig decentraal mee gewerkt. Het wordt binnen elke dienst geproduceerd, in een wereld waar alles volgens jouw regels verloopt.
Deel gegevens zonder de integriteit ervan in gevaar te brengen. Verpak de functie, en niet de bron, in elke dienst die deze nodig heeft.
Het komt voor dat data massaal verplaatst moeten worden. Soms vereist een service een lokale historische dataset in de geselecteerde database-engine. De truc is dat je kunt garanderen dat, indien nodig, een kopie van de bron kan worden hersteld door toegang te krijgen tot het gedistribueerde logboekregistratiemechanisme. Connectors in Kafka doen dit uitstekend.
De vandaag besproken aanpak heeft dus verschillende voordelen:
- Gegevens worden gebruikt in de vorm van gemeenschappelijke stromen, die lange tijd in logs kunnen worden opgeslagen, en het mechanisme voor het werken met gemeenschappelijke gegevens is in elke individuele context ingebed, waardoor services gemakkelijk en snel kunnen werken. Op deze manier kan de dichotomie van de gegevens in evenwicht worden gebracht.
- Gegevens afkomstig van verschillende diensten kunnen eenvoudig worden gecombineerd tot sets. Dit vereenvoudigt de interactie met gedeelde gegevens en elimineert de noodzaak om lokale datasets in de database te onderhouden.
- Stateful Stream Processing slaat alleen gegevens op in de cache, en de bron van de waarheid blijven de algemene logboeken, dus het probleem van gegevenscorruptie in de loop van de tijd is niet zo acuut.
- In de kern zijn diensten datagedreven, wat betekent dat diensten, ondanks de steeds groter wordende datavolumes, nog steeds snel kunnen reageren op zakelijke gebeurtenissen.
- Schaalbaarheidsproblemen liggen bij de makelaar, niet bij de services. Dit vermindert de complexiteit van schrijfservices aanzienlijk, omdat u niet hoeft na te denken over schaalbaarheid.
- Voor het toevoegen van nieuwe services is het niet nodig om de oude te wijzigen, waardoor het aansluiten van nieuwe services eenvoudiger wordt.
Zoals je kunt zien, is dit meer dan alleen RUST. Wij hebben een set tools gekregen waarmee je decentraal met gedeelde data kunt werken.
Niet alle aspecten kwamen aan bod in het artikel van vandaag. We moeten nog uitzoeken hoe we een evenwicht kunnen vinden tussen het verzoek-antwoord-paradigma en het gebeurtenisgestuurde paradigma. Maar we zullen dit de volgende keer behandelen. Er zijn onderwerpen die je beter moet leren kennen, bijvoorbeeld waarom Stateful Stream Processing zo goed is. We zullen hierover praten in het derde artikel. En er zijn nog andere krachtige constructies waarvan we kunnen profiteren als we ze gebruiken, bijvoorbeeld: . Het is een game changer voor gedistribueerde bedrijfssystemen omdat het transactionele garanties biedt in een schaalbare vorm. Dit zal in het vierde artikel worden besproken. Ten slotte zullen we de implementatiedetails van deze principes moeten bespreken.
Maar onthoud voor nu dit: de dichotomie van data is een kracht waarmee we te maken krijgen bij het bouwen van zakelijke diensten. En dit moeten we onthouden. De truc is om alles op zijn kop te zetten en gedeelde data als eersteklas objecten te gaan behandelen. Stateful Stream Processing biedt hiervoor een uniek compromis. Het vermijdt gecentraliseerde ‘Godscomponenten’ die de vooruitgang tegenhouden. Bovendien garandeert het de flexibiliteit, schaalbaarheid en veerkracht van datastreamingpijplijnen en voegt het deze toe aan elke dienst. Daarom kunnen we ons concentreren op de algemene bewustzijnsstroom waarmee elke dienst verbinding kan maken en met zijn gegevens kan werken. Dit maakt diensten schaalbaarder, uitwisselbaarder en autonomer. Ze zullen er dus niet alleen goed uitzien op whiteboards en hypothesetests, maar ze zullen ook tientallen jaren blijven werken en evolueren.
Bron: www.habr.com