Hi almal! Ons het goeie nuus, OTUS stel die kursus weer in Junie bekend , in verband waarmee ons tradisioneel nuttige materiaal met jou deel.
As jy hierdie hele mikrodienste-ding sonder enige konteks teëgekom het, sal jy vergewe word as jy dink dit is 'n bietjie vreemd. Om 'n toepassing in fragmente te verdeel wat deur 'n netwerk verbind is, beteken noodwendig dat komplekse fouttoleransiemodusse by die resulterende verspreide stelsel moet word.
Alhoewel hierdie benadering behels dat dit in baie onafhanklike dienste afgebreek word, is die einddoel veel meer as om net daardie dienste op verskillende masjiene te laat loop. Ons praat hier van interaksie met die buitewêreld, wat ook in sy wese versprei is. Nie in die tegniese sin nie, maar eerder in die sin van 'n ekosisteem wat bestaan uit baie mense, spanne, programme, en elkeen van hierdie dele moet op een of ander manier sy werk doen.
Maatskappye is byvoorbeeld 'n versameling verspreide stelsels wat gesamentlik bydra tot die bereiking van een of ander doelwit. Ons het hierdie feit al dekades lank geïgnoreer, probeer om eenwording te bewerkstellig deur FTP-lêers of die gebruik van ondernemingsintegrasie-instrumente terwyl ons op ons eie geïsoleerde doelwitte fokus. Maar met die koms van dienste het alles verander. Dienste het ons gehelp om verby die horison te kyk en 'n wêreld van interafhanklike programme te sien wat saamwerk. Om suksesvol te kan werk, is dit egter nodig om twee fundamenteel verskillende wêrelde te herken en te ontwerp: die eksterne wêreld, waar ons in 'n ekosisteem van baie ander dienste leef, en ons persoonlike, interne wêreld, waar ons alleen regeer.
Hierdie verspreide wêreld is anders as die een waarin ons grootgeword het en waaraan ons gewoond is. Die beginsels van die konstruksie van tradisionele monolitiese argitektuur weerstaan nie kritiek nie. Om hierdie stelsels reg te kry, gaan dus oor meer as om 'n koel witborddiagram of 'n koel bewys van konsep te skep. Die punt is om te verseker dat so 'n stelsel oor 'n lang tydperk suksesvol funksioneer. Gelukkig bestaan die dienste al 'n geruime tyd, hoewel dit anders lyk. is steeds relevant, selfs gekruid met Docker, Kubernetes en effens armoedige hipster-baarde.
Ons sal dus vandag kyk hoe die reëls verander het, hoekom ons moet heroorweeg oor die manier waarop ons dienste benader en die data wat hulle aan mekaar deurgee, en hoekom ons heeltemal ander gereedskap sal benodig om dit te doen.
Encapsulation sal nie altyd jou vriend wees nie
Mikrodienste kan onafhanklik van mekaar funksioneer. Dit is hierdie eiendom wat hulle die grootste waarde gee. Hierdie selfde eiendom laat dienste toe om te skaal en te groei. Nie soseer in die sin van skaal na kwadrilljoene gebruikers of petagrepe data nie (hoewel dit ook daar kan help), maar in die sin van skaal in terme van mense soos spanne en organisasies voortdurend groei.
Onafhanklikheid is egter 'n tweesnydende swaard. Dit wil sê, die diens self kan maklik en natuurlik loop. Maar as 'n funksie binne 'n diens geïmplementeer word wat vereis dat 'n ander diens gebruik word, dan moet ons uiteindelik amper gelyktydig veranderinge aan beide dienste aanbring. In 'n monoliet is dit maklik om te doen, jy maak net 'n verandering en stuur dit na vrystelling, maar in die geval van die sinchronisering van onafhanklike dienste sal daar meer probleme wees. Koördinasie tussen spanne en vrystellingsiklusse vernietig ratsheid.
As deel van die standaardbenadering probeer hulle eenvoudig irriterende end-tot-end veranderinge vermy, wat funksionaliteit duidelik tussen dienste verdeel. Enkelaanmelding-diens kan hier 'n goeie voorbeeld wees. Dit het 'n duidelik gedefinieerde rol wat dit van ander dienste onderskei. Hierdie duidelike skeiding beteken dat in 'n wêreld van vinnig veranderende eise aan die dienste rondom dit, die enkelaanmelding-diens waarskynlik nie sal verander nie. Dit bestaan binne 'n streng beperkte konteks.
Die probleem is dat besigheidsdienste in die werklike wêreld nie die hele tyd dieselfde suiwer skeiding van rolle kan handhaaf nie. Dieselfde besigheidsdienste werk byvoorbeeld in 'n groter mate met data wat van ander soortgelyke dienste af kom. As jy by aanlynkleinhandel betrokke is, sal die verwerking van bestellingvloei, produkkatalogus of gebruikersinligting 'n vereiste word vir baie van jou dienste. Elkeen van die dienste sal toegang tot hierdie data nodig hê om te funksioneer.
Die meeste sakedienste deel dieselfde datastroom, so hul werk is altyd verweef.
So kom ons by 'n belangrike punt wat die moeite werd is om oor te praat. Terwyl dienste goed werk vir infrastruktuurkomponente wat grootliks in isolasie funksioneer, is die meeste besigheidsdienste uiteindelik baie nouer verweef.
Data digotomie
Diensgeoriënteerde benaderings bestaan dalk reeds, maar hulle het steeds nie insig in hoe om groot hoeveelhede data tussen dienste te deel nie.
Die grootste probleem is dat data en dienste onafskeidbaar is. Aan die een kant moedig enkapsulering ons aan om data weg te steek sodat dienste van mekaar geskei kan word en hul groei en verdere veranderinge fasiliteer. Aan die ander kant moet ons gedeelde data vrylik kan verdeel en verower, net soos enige ander data. Die punt is om dadelik te kan begin werk, so vrylik soos in enige ander inligtingstelsel.
Inligtingstelsels het egter min met inkapseling te doen. Trouens, dit is heeltemal die teenoorgestelde. Databasisse doen alles wat hulle kan om toegang te bied tot die data wat hulle stoor. Hulle kom met 'n kragtige verklarende koppelvlak waarmee u die data kan verander soos u nodig het. Sulke funksionaliteit is belangrik in die voorlopige navorsingstadium, maar nie vir die bestuur van die groeiende kompleksiteit van 'n voortdurend ontwikkelende diens nie.
En hier ontstaan 'n dilemma. Teenstrydigheid. Dichotomie. Inligtingstelsels gaan immers oor die verskaffing van data, en dienste gaan oor wegkruip.
Hierdie twee kragte is fundamenteel. Hulle ondersteun baie van ons werk en veg voortdurend vir uitnemendheid in die stelsels wat ons bou.
Soos diensstelsels groei en ontwikkel, sien ons die gevolge van data-dichotomie op baie maniere. Óf die dienskoppelvlak sal groei, 'n steeds groter verskeidenheid van funksionaliteit bied en begin lyk soos 'n baie spoggerige tuisgemaakte databasis, óf ons sal gefrustreerd raak en een of ander manier implementeer om hele stelle data van diens na diens te herwin of te skuif.
Op sy beurt sal die skep van iets wat lyk soos 'n fancy tuisgemaakte databasis tot 'n hele reeks probleme lei. Ons gaan nie in besonderhede oor hoekom dit gevaarlik is nie gedeelde databasis, laat ons net sê dit verteenwoordig aansienlike duur ingenieurswese en operasionele vir die maatskappy wat dit probeer gebruik.
Wat erger is, is dat datavolumes diensgrensprobleme vergroot. Hoe meer gedeelde data binne 'n diens lê, hoe meer kompleks sal die koppelvlak word en hoe moeiliker sal dit wees om datastelle wat van verskillende dienste af kom, te kombineer.
Die alternatiewe benadering om hele datastelle te onttrek en te verskuif het ook sy probleme. 'n Algemene benadering tot hierdie vraag lyk soos om die hele datastel bloot te herwin en te stoor, en dit dan plaaslik in elke verbruikende diens te stoor.
Die probleem is dat verskillende dienste die data wat hulle verbruik verskillend interpreteer. Hierdie data is altyd byderhand. Hulle word plaaslik aangepas en verwerk. Hulle hou redelik vinnig op om iets in gemeen te hê met die data in die bron.
Hoe meer veranderlik die kopieë is, hoe meer sal die data oor tyd verskil.
Om sake te vererger, is sulke data moeilik om in retrospek reg te stel ( Dit is waar dit regtig tot die redding kan kom). Trouens, sommige van die onoplosbare tegnologieprobleme waarmee besighede te kampe het, spruit voort uit die uiteenlopende data wat van toepassing tot toepassing vermenigvuldig.
Om 'n oplossing vir hierdie probleem te vind, moet ons anders dink oor gedeelde data. Hulle moet eersteklas voorwerpe word in die argitekture wat ons bou. noem sulke data "ekstern", en dit is 'n baie belangrike kenmerk. Ons het inkapseling nodig sodat ons nie die innerlike werking van 'n diens blootlê nie, maar ons moet dit vir dienste maklik maak om toegang tot gedeelde data te verkry sodat hulle hul werk korrek kan doen.
Die probleem is dat geen benadering vandag relevant is nie, aangesien nóg die dienskoppelvlakke, nóg die boodskappe, nóg die Gedeelde Databasis 'n goeie oplossing bied om met eksterne data te werk. Dienskoppelvlakke is swak geskik vir data-uitruiling op enige skaal. Boodskappe skuif data, maar stoor nie die geskiedenis daarvan nie, dus word data mettertyd beskadig. Gedeelde databasisse fokus te veel op een punt, wat vordering terughou. Ons sit onvermydelik vas in 'n siklus van datamislukking:
Siklus van data mislukking
Strome: 'n gedesentraliseerde benadering tot data en dienste
Ideaal gesproke moet ons die manier waarop dienste met gedeelde data werk, verander. Op hierdie stadium staar enige van die benaderings die voorgenoemde tweespalt in die gesig, aangesien daar geen towerstof is wat daarop gestrooi kan word om dit te laat verdwyn nie. Ons kan egter die probleem heroorweeg en 'n kompromie bereik.
Hierdie kompromie behels 'n sekere mate van sentralisasie. Ons kan die verspreide logmeganisme gebruik omdat dit betroubare, skaalbare strome bied. Ons wil nou hê dat dienste kan aansluit en op hierdie gedeelde drade kan werk, maar ons wil komplekse gesentraliseerde Godsdienste vermy wat hierdie verwerking doen. Daarom is die beste opsie om stroomverwerking in elke verbruikersdiens in te bou. Op hierdie manier sal dienste datastelle van verskillende bronne kan kombineer en daarmee saamwerk soos hulle nodig het.
Een manier om hierdie benadering te bereik, is deur die gebruik van 'n stroomplatform. Daar is baie opsies, maar vandag sal ons na Kafka kyk, aangesien die gebruik van sy Stateful Stream Processing ons in staat stel om die probleem wat aangebied word effektief op te los.
Die gebruik van 'n verspreide logmeganisme stel ons in staat om die goed getrapte pad te volg en boodskappe te gebruik om mee te werk . Hierdie benadering word beskou as 'n beter skaal en partisionering as die versoek-reaksie meganisme, want dit gee beheer van die vloei aan die ontvanger eerder as die sender. Vir alles in hierdie lewe moet jy egter betaal, en hier het jy 'n makelaar nodig. Maar vir groot stelsels is die afruil die moeite werd (wat dalk nie die geval is vir jou gemiddelde webtoepassing nie).
As 'n makelaar verantwoordelik is vir verspreide aanteken eerder as 'n tradisionele boodskapstelsel, kan jy voordeel trek uit bykomende funksies. Die vervoer kan lineêr skaal amper net so goed as 'n verspreide lêerstelsel. Data kan nogal lank in logs gestoor word, so ons kry nie net boodskapuitruiling nie, maar ook inligtingstoor. Skaalbare berging sonder die vrees vir veranderlike gedeelde toestand.
U kan dan statige stroomverwerking gebruik om verklarende databasisnutsmiddels by verbruikende dienste te voeg. Dit is 'n baie belangrike idee. Terwyl die data in gedeelde strome gestoor word waartoe alle dienste toegang het, is die samevoeging en verwerking wat die diens doen privaat. Hulle bevind hulself binne 'n streng beperkte konteks geïsoleer.
Elimineer data-dichotomie deur die onveranderlike toestandstroom te skei. Voeg dan hierdie funksionaliteit by elke diens met behulp van Stateful Stream Processing.
Dus, as jou diens met bestellings, 'n produkkatalogus, 'n pakhuis moet werk, sal dit volle toegang hê: net jy sal besluit watter data om te kombineer, waar om dit te verwerk en hoe dit oor tyd moet verander. Ten spyte van die feit dat die data gedeel word, is die werk daarmee heeltemal gedesentraliseerd. Dit word binne elke diens vervaardig, in 'n wêreld waar alles volgens jou reëls verloop.
Deel data sonder om die integriteit daarvan in te boet. Pak die funksie in, nie die bron nie, in elke diens wat dit benodig.
Dit gebeur dat data massaal verskuif moet word. Soms vereis 'n diens 'n plaaslike historiese datastel in die geselekteerde databasisenjin. Die truuk is dat jy kan waarborg dat, indien nodig, 'n kopie van die bron af herstel kan word deur toegang te verkry tot die verspreide logmeganisme. Connectors in Kafka doen 'n goeie werk hiervan.
Dus, die benadering wat vandag bespreek word, het verskeie voordele:
- Data word gebruik in die vorm van algemene strome, wat vir 'n lang tyd in logs gestoor kan word, en die meganisme om met algemene data te werk is in elke individuele konteks vasgestel, wat dienste maklik en vinnig laat werk. Sodoende kan die tweespalt van die data gebalanseer word.
- Data afkomstig van verskillende dienste kan maklik in stelle gekombineer word. Dit vergemaklik interaksie met gedeelde data en elimineer die behoefte om plaaslike datastelle in die databasis te onderhou.
- Stateful Stream Processing kas slegs data, en die bron van waarheid bly die algemene logboeke, so die probleem van datakorrupsie met verloop van tyd is nie so akuut nie.
- In hul kern is dienste data-gedrewe, wat beteken dat ten spyte van die steeds toenemende volumes data, dienste steeds vinnig op besigheidsgebeure kan reageer.
- Skaalbaarheidskwessies val op die makelaar, nie die dienste nie. Dit verminder die kompleksiteit van skryfdienste aansienlik, aangesien dit nie nodig is om aan skaalbaarheid te dink nie.
- Om nuwe dienste by te voeg, hoef nie ou dienste te verander nie, dus word nuwe dienste makliker om te koppel.
Soos jy kan sien, is dit meer as net RUS. Ons het 'n stel nutsmiddels ontvang waarmee u op 'n gedesentraliseerde wyse met gedeelde data kan werk.
Nie alle aspekte is in vandag se artikel gedek nie. Ons moet nog uitvind hoe om te balanseer tussen die versoek-reaksie-paradigma en die gebeurtenis-gedrewe paradigma. Maar ons sal dit volgende keer hanteer. Daar is onderwerpe wat jy beter moet leer ken, byvoorbeeld hoekom Stateful Stream Processing so goed is. Ons sal hieroor praat in die derde artikel. En daar is ander kragtige konstrukte waaruit ons kan voordeel trek as ons dit gebruik, byvoorbeeld, . Dit is 'n spelwisselaar vir verspreide besigheidstelsels omdat dit transaksionele waarborge vir in 'n skaalbare vorm. Dit sal in die vierde artikel bespreek word. Laastens sal ons die implementeringsbesonderhede van hierdie beginsels moet deurgaan.
Maar vir eers, onthou net dit: die data-dichotomie is 'n krag wat ons in die gesig staar wanneer ons besigheidsdienste bou. En ons moet dit onthou. Die kuns is om alles op sy kop te keer en gedeelde data as eersteklas-objekte te begin hanteer. Stateful Stream Processing bied 'n unieke kompromie hiervoor. Dit vermy gesentraliseerde "God-komponente" wat vordering terughou. Boonop verseker dit die behendigheid, skaalbaarheid en veerkragtigheid van datastroompyplyne en voeg dit by elke diens. Daarom kan ons fokus op die algemene stroom van bewussyn waaraan enige diens kan koppel en met sy data kan werk. Dit maak dienste meer skaalbaar, uitruilbaar en outonoom. Hulle sal dus nie net goed lyk op witborde en hipotesetoetse nie, maar hulle sal ook vir dekades werk en ontwikkel.
Bron: will.com