En grundig introduktion til distribuerede systemer

Hvad er et distribueret system, og hvorfor er det så kompliceret?

En bjørn, der overvejer distribuerede systemer

Indholdsfortegnelse

Introduktion

  1. Hvad er et distribueret system?
  2. Hvorfor distribuere et system?
  3. Eksempel på skalering af database
  4. Decentral vs Distribueret

Distribuerede systemkategorier

  1. Distribuerede datalagre
  2. Distribueret computere
  3. Distribuerede filsystemer
  4. Distribueret besked
  5. Distribuerede applikationer
  6. Distribuerede Ledgers

Resumé

Introduktion

Med den stadigt voksende teknologiske ekspansion i verden bliver distribuerede systemer mere og mere udbredte. De er et stort og komplekst studieretning inden for datalogi.

Denne artikel har til formål at introducere dig til distribuerede systemer på en grundlæggende måde, der viser dig et glimt af de forskellige kategorier af sådanne systemer, mens du ikke dykker dybt ned i detaljerne.

Hvad er et distribueret system?

Et distribueret system i sin mest enkleste definition er en gruppe computere, der arbejder sammen for at fremstå som en enkelt computer for slutbrugeren.

Disse maskiner har en delt tilstand, fungerer samtidigt og kan mislykkes uafhængigt uden at påvirke hele systemets oppetid.

Jeg foreslår, at vi trinvist arbejder gennem et eksempel på distribution af et system, så du kan få en bedre fornemmelse af det hele:

En traditionel stak

Lad os gå med en database! Traditionelle databaser gemmes på filsystemet på en enkelt maskine, hver gang du vil hente / indsætte oplysninger i den - du taler direkte til den maskine.

For at vi kan distribuere dette databasesystem, er vi nødt til at have denne database kørt på flere maskiner på samme tid. Brugeren skal være i stand til at tale med hvilken maskine han vælger og ikke skal være i stand til at fortælle, at han ikke taler til en enkelt maskine - hvis han indsætter en post i node # 1, skal node 3 være i stand til at returnere denne post.

En arkitektur, der kan betragtes som distribueret

Hvorfor distribuere et system?

Systemer distribueres altid efter behov. Sandheden i sagen er - at styre distribuerede systemer er et komplekst emne, der er fyldt med faldgruber og landminer. Det er en hovedpine at distribuere, vedligeholde og fejle distribuerede systemer, så hvorfor gå der overhovedet?

Hvad et distribueret system giver dig mulighed for er at skalere vandret. Når vi går tilbage til vores tidligere eksempel på den enkelte databaseserver, ville den eneste måde at håndtere mere trafik være at opgradere den hardware, databasen kører på. Dette kaldes skalering lodret.

Skalering lodret er alt godt og godt, mens du kan, men efter et vist punkt vil du se, at selv den bedste hardware ikke er tilstrækkelig til nok trafik, for ikke at nævne upraktisk at være vært.

Skalering vandret betyder simpelthen at tilføje flere computere i stedet for at opgradere hardware til en enkelt.

Horisontal skalering bliver meget billigere efter en bestemt tærskel

Det er væsentligt billigere end lodret skalering efter en bestemt tærskel, men det er ikke dets hovedsak for præference.

Lodret skalering kan kun støde din ydelse op til den nyeste hardwarefunktioner. Disse kapaciteter viser sig at være utilstrækkelige for teknologiske virksomheder med moderat til stor arbejdsbelastning.

Den bedste ting ved vandret skalering er, at du ikke har noget loft til, hvor meget du kan skalere - hver gang ydeevnen forringes, tilføjer du blot en anden maskine, op til uendeligt potentielt.

Nem skalering er ikke den eneste fordel, du får ved distribuerede systemer. Fejltolerance og lav latenstid er også lige så vigtige.

Fejltolerance - en klynge på ti maskiner på tværs af to datacentre er i sagens natur mere fejltolerant end en enkelt maskine. Selv hvis et datacenter tænder, fungerer din applikation stadig.

Lav latens - Tiden for en netværkspakke til at rejse verden er fysisk afgrænset af lysets hastighed. For eksempel er den kortest mulige tid for en forespørgsels rundtur (dvs. gå frem og tilbage) i et fiberoptisk kabel mellem New York og Sydney 160 ms. Distribuerede systemer giver dig mulighed for at have en knude i begge byer, så trafikken kan ramme den node, der er tættest på den.

For at et distribueret system skal fungere, skal du dog, at softwaren, der kører på disse maskiner, er specielt designet til at køre på flere computere på samme tid og håndtere de problemer, der følger med det. Dette viser sig at være ingen let bedrift.

Skalering af vores database

Forestil dig, at vores webapplikation blev sindssygt populær. Forestil dig også, at vores database begyndte at få dobbelt så mange forespørgsler pr. Sekund, som den kan håndtere. Din ansøgning vil straks begynde at falde i ydeevne, og dette vil blive bemærket af dine brugere.

Lad os arbejde sammen og lave vores databaseskala for at imødekomme vores høje krav.

I en typisk webapplikation læser du normalt information meget hyppigere, end du indsætter nye oplysninger eller ændrer gamle.

Der er en måde at øge læsepræstation på, og det er den såkaldte Master-Slave Replication strategi. Her opretter du to nye databaseservere, der synkroniseres med den vigtigste. Fangsten er, at du kun kan læse fra disse nye tilfælde.

Hver gang du indsætter eller ændrer information - snakker du med hoveddatabasen. Det til gengæld informerer slaverne asynkront om ændringen og de redder det også.

Tillykke, du kan nu udføre 3x så meget læste forespørgsler! Er det ikke godt?

faldgrube

Gotcha! Vi mistede straks C i vores relationelle databases ACID-garantier, der står for Konsistens.

Ser du, der findes nu en mulighed, hvor vi indsætter en ny post i databasen, straks derefter udsender en læst forespørgsel for den og får intet tilbage, som om den ikke eksisterede!

Forplantning af den nye information fra mesteren til slaven sker ikke øjeblikkeligt. Der findes faktisk et tidsvindue, hvor du kan hente uaktuelle oplysninger. Hvis dette ikke var tilfældet, ville din skriveydelse lide, da det ville være nødt til synkront at vente på, at dataene blev udbredt.

Distribuerede systemer leveres med en håndfuld afvejninger. Dette særlige emne er et, du bliver nødt til at leve med, hvis du vil skalere tilstrækkeligt.

Fortsætter med at skalere

Ved hjælp af slavedatabase-tilgangen kan vi horisontalt skalere vores læstrafik op til en vis grad. Det er fantastisk, men vi har ramt en mur med hensyn til vores skrivetrafik - det er stadig alt sammen på en server!

Vi har ikke mange muligheder her. Vi har simpelthen brug for at opdele vores skrivetrafik i flere servere, da en ikke er i stand til at håndtere den.

En måde er at gå med en multi-master replikationsstrategi. Der i stedet for slaver, som du kun kan læse fra, har du flere masternoder, der understøtter læser og skriver. Desværre bliver dette hurtigt kompliceret, da du nu har mulighed for at oprette konflikter (f.eks. Indsætte to poster med samme ID).

Lad os gå med en anden teknik kaldet sharding (også kaldet partitionering).

Når du klipper, deles du din server i flere mindre servere, kaldet skår. Disse skår alle har forskellige poster - du opretter en regel om, hvilken slags poster der går til hvilken skår. Det er meget vigtigt at skabe reglen således, at dataene spreder sig på en ensartet måde.

En mulig tilgang til dette er at definere intervaller i henhold til nogle oplysninger om en post (f.eks. Brugere med navn A-D).

Denne afskærmningsnøgle skal vælges meget omhyggeligt, da belastningen ikke altid er ens baseret på vilkårlige kolonner. (f.eks. flere mennesker har et navn, der starter med C snarere end Z). En enkelt skær, der modtager flere anmodninger end andre, kaldes et hot spot og skal undgås. Når splittet er opdelt, bliver re-sharding data utroligt dyre og kan forårsage betydelig nedetid, som tilfældet var med FourSquares berygtede 11 timers driftsstop.

For at holde vores eksempel enkelt skal du antage, at vores klient (Rails-appen) ved, hvilken database, der skal bruges til hver post. Det er også værd at bemærke, at der er mange strategier til afskærmning, og dette er et simpelt eksempel for at illustrere konceptet.

Vi har vundet ret meget lige nu - vi kan øge vores skrivetrafik N gange, hvor N er antallet af skår. Dette giver os næsten ingen grænse - forestil os, hvor fint kornet vi kan få med denne opdeling.

faldgrube

Alt inden for Software Engineering er mere eller mindre en afvejning, og dette er ingen undtagelse. Afskærmning er ingen enkel bedrift og undgås bedst, indtil det virkelig er nødvendigt.

Vi har nu stillet forespørgsler ved hjælp af andre nøgler end den partitionerede nøgle, som er utrolig ineffektiv (de er nødt til at gå gennem alle skærene). SQL JOIN-forespørgsler er endnu værre, og komplekse bliver praktisk talt ubrugelige.

Decentral vs Distribueret

Inden vi går videre, vil jeg gerne skelne mellem de to udtryk.

Selvom ordene lyder ens og kan konkluderes at betyde det samme logisk, har deres forskel en betydelig teknologisk og politisk betydning.

Decentraliseret distribueres stadig i teknisk forstand, men hele de decentrale systemer ejes ikke af én aktør. Ingen virksomheder kan eje et decentraliseret system, ellers ville det ikke være decentraliseret mere.

Det betyder, at de fleste systemer, vi vil gå over i dag, kan betragtes som distribuerede centraliserede systemer - og det er, hvad de er gjort til at være.

Hvis du tænker over det - er det sværere at oprette et decentraliseret system, for da er du nødt til at håndtere sagen, hvor nogle af deltagerne er ondsindede. Dette er ikke tilfældet med normale distribuerede systemer, da du ved, at du ejer alle noder.

Bemærk: Denne definition er drøftet meget og kan forveksles med andre (peer-to-peer, fødereret). I den tidlige litteratur er det også blevet defineret forskelligt. Uanset hvad jeg gav dig som en definition er, hvad jeg mener er det mest udbredte nu, da blockchain og cryptocurrencies populariserede udtrykket.

Distribuerede systemkategorier

Vi vil nu gennemgå et par distribuerede systemkategorier og liste deres største offentligt kendte produktionsanvendelse. Husk, at de fleste af disse viste tal er forældede og sandsynligvis er betydeligt større fra det tidspunkt, du læser dette.

Distribuerede datalagre

Distribuerede databutikker er mest brugt og anerkendt som Distribuerede databaser. De fleste distribuerede databaser er NoSQL ikke-relationelle databaser, begrænset til semantik af nøgleværdier. De giver utrolig ydeevne og skalerbarhed på bekostning af konsistens eller tilgængelighed.

Kendt skala - Apple er kendt for at bruge 75.000 Apache Cassandra-knudepunkter, der lagrer over 10 petabyte med data, tilbage i 2015

Vi kan ikke gå ind i diskussioner om distribuerede datalagre uden først at indføre CAP-sætningen.

CAP-sætning

Påvist langt tilbage i 2002 siger CAP-sætningen, at en distribueret datalager ikke samtidig kan være konsistent, tilgængelig og partitionstolerant.

Vælg 2 ud af 3 (men ikke sammenhæng og tilgængelighed)

Nogle hurtige definitioner:

  • Konsistens - Hvad du læser og skriver i rækkefølge er hvad der forventes (husk gotcha med databasereplikationen for et par afsnit siden?)
  • Tilgængelighed - hele systemet dør ikke - hver knap, der ikke svigter, giver altid et svar.
  • Partition Tolerant - Systemet fortsætter med at fungere og opretholde dets garantier for konsistens / tilgængelighed på trods af netværkspartitioner

I virkeligheden skal partitionstolerance være en given for enhver distribueret datalager. Som nævnt mange steder, hvoraf den ene er den store artikel, kan du ikke have konsistens og tilgængelighed uden partitionstolerance.

Tænk over det: hvis du har to noder, der accepterer information og deres forbindelse dør - hvordan vil de begge være tilgængelige og samtidig give dig konsistens? De har ingen måde at vide, hvad den anden knude gør, og som sådan kan de enten blive offline (ikke tilgængelige) eller arbejde med uaktuelle oplysninger (inkonsekvente).

Hvad gør vi?

I sidste ende skal du vælge, om du vil have, at dit system skal være stærkt konsistent eller meget tilgængeligt under en netværkspartition.

Praksis viser, at de fleste applikationer værdsætter tilgængelighed mere. Du har ikke nødvendigvis altid brug for stærk konsistens. Selv da er denne afvejning ikke nødvendigvis, fordi du har brug for 100% tilgængelighedsgarantien, men snarere fordi netværkets latenstid kan være et problem, når du skal synkronisere maskiner for at opnå stærk konsistens. Disse og flere faktorer gør, at applikationer typisk vælger løsninger, der tilbyder høj tilgængelighed.

Sådanne databaser afregnes med den svageste konsistensmodel - eventuel konsistens (stærk vs eventuel konsistensforklaring). Denne model garanterer, at hvis der ikke foretages nye opdateringer til en given vare, i sidste ende vil alle adganger til den pågældende vare returnere den seneste opdaterede værdi.

Disse systemer indeholder BASE-egenskaber (i modsætning til traditionelle databasers ACID)

  • Grundlæggende tilgængelig - Systemet returnerer altid et svar
  • Blød tilstand - Systemet kan ændre sig over tid, selv i tider uden input (på grund af eventuel konsistens)
  • Eventuel konsistens - I mangel af input spredes dataene til hver knude før eller senere - hvilket bliver konsistente

Eksempler på sådanne tilgængelige distribuerede databaser - Cassandra, Riak, Voldemort

Der er selvfølgelig andre datalagre, der foretrækker stærkere konsistens - HBase, Couchbase, Redis, Zookeeper

CAP-sætningen er værdig til flere artikler på egen hånd - nogle angående, hvordan du kan finjustere et systems CAP-egenskaber afhængigt af, hvordan klienten opfører sig, og andre om, hvordan det ikke forstås korrekt.

Cassandra

Cassandra er som nævnt ovenfor en distribueret No-SQL-database, der foretrækker AP-egenskaberne ud af CAP, hvor der tages stilling til eventuel konsistens. Jeg må indrømme, at dette kan være lidt vildledende, da Cassandra er meget konfigurerbar - du kan få det til at give en stærk konsistens på bekostning af tilgængeligheden, men det er ikke dets almindelige brugssag.

Cassandra bruger konsekvent hashing for at bestemme, hvilke noder fra din klynge, der skal administrere de data, du videregiver. Du indstiller en replikationsfaktor, der dybest set angiver, hvor mange noder du vil replikere dine data.

Prøveskrivning

Når du læser, læser du kun fra disse noder.

Cassandra er massivt skalerbar og giver absurd høj skrivegennemstrømning.

Eventuelt partisk diagram, der viser skriv pr. Sekund benchmarks. Taget herfra.

Selvom dette diagram muligvis er partisk, og det ser ud til, at det sammenligner Cassandra med databaser, der er indstillet til at give stærk konsistens (ellers kan jeg ikke se, hvorfor MongoDB ville tabe ydelsen, når den blev opgraderet fra 4 til 8 noder), dette skal stadig vise, hvad et korrekt sæt op Cassandra klynge er i stand til.

Uanset hvad angår handel med distribuerede systemer, der muliggør vandret skalering og utroligt høj gennemstrømning, leverer Cassandra ikke nogle grundlæggende funktioner i ACID-databaser - nemlig transaktioner.

Konsensus

Databasetransaktioner er vanskelige at implementere i distribuerede systemer, da de kræver, at hver node er enige om den rigtige handling til at udføre (afbryde eller begå). Dette kaldes konsensus, og det er et grundlæggende problem i distribuerede systemer.

Det er let at nå frem til den type aftale, der er nødvendig for problemet med "transaktionskommission", hvis de deltagende processer og netværket er helt pålidelige. Imidlertid er virkelige systemer underlagt en række mulige fejl, såsom procesnedbrud, netværkspartitionering og mistede, forvrængede eller duplikerede meddelelser.

Dette er et problem - det har vist sig umuligt at garantere, at der opnås en korrekt konsensus inden for en afgrænset tidsramme på et ikke-pålideligt netværk.

I praksis er der dog algoritmer, der når enighed om et ikke-pålideligt netværk ret hurtigt. Cassandra leverer faktisk letvægtstransaktioner gennem brug af Paxos-algoritmen til distribueret konsensus.

Distribueret computere

Distribueret computing er nøglen til tilstrømningen af ​​Big Data-behandling, vi har set i de senere år. Det er teknikken til at opdele en enorm opgave (f.eks. Samlet 100 milliarder poster), som ingen enkelt computer er i stand til praktisk at udføre på egen hånd i mange mindre opgaver, som hver kan passe ind i en enkelt varemaskine. Du opdeler din enorme opgave i mange mindre, lader dem udføre på mange maskiner parallelt, samle dataene passende, og du har løst dit oprindelige problem. Denne tilgang giver dig igen mulighed for at skalere vandret - når du har en større opgave, skal du blot inkludere flere noder i beregningen.

Kendt skala - Folding @ Home havde 160k aktive maskiner i 2012

En tidlig innovatør i dette rum var Google, som ved hjælp af deres store datamængder måtte opfinde et nyt paradigme til distribueret beregning - MapReduce. De udgav et papir om det i 2004, og open source-communityet oprettede senere Apache Hadoop baseret på det.

MapReduce

MapReduce kan simpelthen defineres som to trin - kortlægge dataene og reducere dem til noget meningsfuldt.

Lad os komme til det med et eksempel igen:

Lad os sige, at vi er mellemstore, og vi lagrede vores enorme information i en sekundær distribueret database til lagerformål. Vi vil hente data, der repræsenterer antallet af klapper, der udstedes hver dag i hele april 2017 (for et år siden).

Dette eksempel holdes så kort, klart og enkelt som muligt, men forestil dig, at vi arbejder med masser af data (f.eks. At analysere milliarder af klap). Vi lagrer naturligvis ikke alle disse oplysninger på en maskine, og vi analyserer ikke alt dette kun med en maskine. Vi forespørger heller ikke produktionsdatabasen, men snarere en "lager" -database, der er bygget specifikt til offline-job med lav prioritet.

Hvert kortjob er en separat knude, der transformerer så mange data, som det kan. Hvert job gennemgår alle dataene i den givne lagringsnode og kortlægger dem til en simpel tuple af dato og nummer et. Derefter udføres tre mellemliggende trin (som ingen snakker om) - Shuffle, Sort and Partition. De arrangerer dybest set yderligere dataene og sletter dem til det rette reducerende job. Da vi har med store data at gøre, har vi hver Reducer job adskilt til kun at arbejde på en enkelt dato.

Dette er et godt paradigme og overraskende giver dig mulighed for at gøre meget med det - du kan f.eks. Kæde flere MapReduce-job.

Bedre teknikker

MapReduce er noget arv i dag og bringer nogle problemer med det. Fordi det fungerer i batches (job), opstår der et problem, hvis dit job mislykkes - du skal genstarte det hele. Et 2-timers job, der svigter, kan virkelig bremse hele din databehandlingsrørledning, og du vil ikke have det i det mindste, især i spidsbelastningen.

Et andet problem er den tid, du venter, indtil du modtager resultater. I analysesystemer i realtid (som alle har big data og dermed bruger distribueret computing) er det vigtigt, at dine seneste knuste data skal være så friske som muligt og bestemt ikke fra et par timer siden.

Som sådan er der fremkommet andre arkitekturer, der vedrører disse problemer. Nemlig Lambda Architecture (blanding af batchbehandling og streambehandling) og Kappa Architecture (kun streambehandling). Disse fremskridt på området har bragt nye værktøjer, der gør dem i stand - Kafka Streams, Apache Spark, Apache Storm, Apache Samza.

Distribuerede filsystemer

Distribuerede filsystemer kan betragtes som distribuerede datalagre. De er de samme ting som et koncept - lagring og adgang til en stor mængde data på tværs af en klynge af maskiner, der alle vises som en. De går typisk hånd i hånd med Distribueret computere.

Kendt skala - Yahoo er kendt for at køre HDFS på over 42.000 knudepunkter til opbevaring af 600 petabyte med data, tilbage i 2011

Wikipedia definerer forskellen, at distribuerede filsystemer tillader adgang til filer ved hjælp af de samme grænseflader og semantik som lokale filer, ikke gennem et brugerdefineret API som Cassandra Query Language (CQL).

HDFS

Hadoop Distribueret filsystem (HDFS) er det distribuerede filsystem, der bruges til distribueret computing via Hadoop-rammen. Med en udbredt vedtagelse bruges det til at gemme og replikere store filer (GB eller TB i størrelse) på tværs af mange maskiner.

Dens arkitektur består hovedsageligt af NameNodes og DataNodes. Navnekoder er ansvarlige for at opbevare metadata om klyngen, ligesom hvilken knude der indeholder hvilke filblokke. De fungerer som koordinatorer for netværket ved at finde ud af, hvor det bedst er at gemme og replikere filer, spore systemets sundhed. DataNodes gemmer simpelthen filer og udfører kommandoer som at replikere en fil, skrive en ny og andre.

Det er ikke overraskende, at HDFS bruges bedst sammen med Hadoop til beregning, da det giver datakendskab til beregningsjobberne. Nævnte job løb derefter på de noder, der lagrer dataene. Dette udnytter datalokaliteten - optimerer beregningerne og reducerer mængden af ​​trafik over netværket.

IPFS

Interplanetary File System (IPFS) er en spændende ny peer-to-peer-protokol / netværk til et distribueret filsystem. Udnytter Blockchain-teknologien og kan prale af en fuldstændig decentral arkitektur uden nogen enkelt ejer eller et mislykket punkt.

IPFS tilbyder et navnesystem (svarende til DNS) kaldet IPNS og giver brugerne let adgang til oplysninger. Det gemmer fil via historisk versionering, svarende til hvordan Git gør. Dette giver mulighed for at få adgang til alle filens tidligere tilstande.

Det er stadig under tung udvikling (v0.4 i skrivende stund), men har allerede set projekter interesseret i at bygge over det (FileCoin).

Distribueret besked

Meddelelsessystemer er et centralt sted til opbevaring og udbredelse af meddelelser / begivenheder i dit overordnede system. De giver dig mulighed for at afkoble din applikationslogik fra at tale direkte med dine andre systemer.

Kendt skala - LinkedIns Kafka-klynge behandlede 1 billion billioner beskeder om dagen med toppe på 4,5 millioner meddelelser pr. Sekund.

Kort sagt, en meddelelsesplatform fungerer på følgende måde:

Der sendes en meddelelse fra applikationen, der potentielt opretter den (kaldet en producent), går ind på platformen og læses af potentielt flere applikationer, der er interesseret i den (kaldes forbrugere).

Hvis du har brug for at gemme en bestemt begivenhed et par steder (f.eks. Oprettelse af brugere til database, lager, e-mail-sendetjeneste og hvad du ellers kan komme på) er en meddelelsesplatform den reneste måde at sprede denne meddelelse på.

Forbrugerne kan enten trække information ud af mæglerne (pull model) eller få mæglerne til at skubbe information direkte ind i forbrugerne (push model).

Der er et par populære top-notch-meddelelsesplatforme:

RabbitMQ - Meddelelsesmægler, der giver dig en mere detaljeret kontrol af meddelelsesbaner via routeregler og andre let konfigurerbare indstillinger. Kan kaldes en smart mægler, da den har en masse logik i sig og holder nøje styr på meddelelser, der passerer gennem den. Giver indstillinger for både AP og CP fra CAP. Bruger en push-model til at give forbrugerne besked.

Kafka - Meddelelsesmægler (og all out platform), som er lidt lavere niveau, da den ikke holder styr på, hvilke meddelelser der er læst og ikke muliggør kompleks routinglogik. Dette hjælper det med at opnå enestående ydelse. Efter min mening er dette det største udsigt i dette rum med aktiv udvikling fra open source-samfundet og støtte fra Confluent-teamet. Kafka har uden tvivl den mest udbredte anvendelse fra topteknologiske virksomheder. Jeg skrev en grundig introduktion til dette, hvor jeg går i detaljer om al dets godhed.

Apache ActiveMQ - Den ældste af flokken, der stammer fra 2004. Bruger JMS API, hvilket betyder, at den er rettet mod Java EE-applikationer. Det blev omskrevet som ActiveMQ Artemis, som giver enestående ydeevne på niveau med Kafka.

Amazon SQS - En meddelelsestjeneste leveret af AWS. Lader dig hurtigt integrere den med eksisterende applikationer og eliminerer behovet for at håndtere din egen infrastruktur, hvilket kan være en stor fordel, da systemer som Kafka er notorisk vanskelige at installere. Amazon tilbyder også to lignende tjenester - SNS og MQ, hvoraf sidstnævnte grundlæggende er ActiveMQ, men administreres af Amazon.

Distribuerede applikationer

Hvis du ruller 5 Rails-servere bag en enkelt belastningsbalancer, der alle er forbundet til en database, kan du kalde det for et distribueret program? Husk min definition ovenfra:

Et distribueret system er en gruppe computere, der arbejder sammen, så de vises som en enkelt computer for slutbrugeren. Disse maskiner har en delt tilstand, fungerer samtidigt og kan mislykkes uafhængigt uden at påvirke hele systemets oppetid.

Hvis du regner databasen som en delt tilstand, kan du argumentere for, at dette kan klassificeres som et distribueret system - men du har forkert, da du har savnet "arbejder sammen" -delen af ​​definitionen.

Et system distribueres kun, hvis knudepunkter kommunikerer med hinanden for at koordinere deres handlinger.

Derfor kan noget som en applikation, der kører sin back-end-kode på et peer-to-peer-netværk, bedre klassificeres som en distribueret applikation. Uanset hvad er dette unødvendigt klassificering, der ikke tjener noget formål, men illustrerer, hvordan nøjeregnede vi er ved at gruppere ting sammen.

Kendt skala - BitTorrent-sverm på 193.000 knudepunkter til en episode af Game of Thrones, april, 2014

Erlang virtuel maskine

Erlang er et funktionelt sprog, der har stor semantik for samtidighed, distribution og fejltolerance. Erlang Virtual Machine selv håndterer distributionen af ​​en Erlang-applikation.

Dens model fungerer ved at have mange isolerede letvægtsprocesser, alle med evnen til at tale med hinanden via et indbygget system til meddelelsesoverførsel. Dette kaldes skuespillermodellen, og Erlang OTP-biblioteker kan betragtes som en distribueret skuespillerramme (langs Akka's linjer for JVM).

Modellen er det, der hjælper den med at opnå stor samtidighed snarere blot - processerne er spredt over de tilgængelige kerner i systemet, der kører dem. Da dette ikke kan skelnes fra en netværksindstilling (bortset fra muligheden for at slippe meddelelser), kan Erlangs VM oprette forbindelse til andre Erlang VM'er, der kører i det samme datacenter eller endda på et andet kontinent. Denne sverm af virtuelle maskiner kører en enkelt applikation og håndterer maskinfejl via overtagelse (en anden knude bliver planlagt til at køre).

Faktisk blev det distribuerede lag af sproget tilføjet for at give fejltolerance. Software, der kører på en enkelt maskine, risikerer altid, at den ene maskine dør og tager din ansøgning offline. Software, der kører på mange noder, muliggør lettere håndtering af hardwarefejl, forudsat at applikationen blev bygget med det i tankerne.

BitTorrent

BitTorrent er en af ​​de mest anvendte protokoller til overførsel af store filer over nettet via torrents. Hovedideen er at lette filoverførsel mellem forskellige peers i netværket uden at skulle gå gennem en hovedserver.

Ved hjælp af en BitTorrent-klient opretter du forbindelse til flere computere over hele verden for at downloade en fil. Når du åbner en .torrent-fil, opretter du forbindelse til en såkaldt tracker, som er en maskine, der fungerer som en koordinator. Det hjælper med peer-opdagelse og viser de noder i det netværk, der har den ønskede fil.

et eksempel netværk

Du har forestillingerne om to typer brugere, en igler og en seeder. En igler er den bruger, der downloader en fil, og en seeder er den bruger, der uploader nævnte fil.

Det sjove ved peer-to-peer-netværk er, at du som almindelig bruger har evnen til at deltage og bidrage til netværket.

BitTorrent og dets forløbere (Gnutella, Napster) giver dig mulighed for frivilligt at være vært for filer og uploade til andre brugere, der ønsker dem. Årsagen til, at BitTorrent er så populær, er, at det var den første af sin art, der gav incitamenter til at bidrage til netværket. Freeriding, hvor en bruger kun ville downloade filer, var et problem med de foregående fildelingsprotokoller.

BitTorrent løst freeriding i et omfang ved at få seeders til at uploade mere til dem, der giver de bedste download-priser. Det fungerer ved at tilskynde dig til at uploade, mens du downloader en fil. Desværre, efter at du er færdig, gør ingenting dig til at forblive aktiv i netværket. Dette medfører en mangel på seeders i netværket, der har den fulde fil, og da protokollen er meget afhængig af sådanne brugere, kom løsninger som private trackers ud i livet. Private trackere kræver, at du er medlem af et samfund (ofte kun inviteret) for at deltage i det distribuerede netværk.

Efter fremskridt i marken blev sporingsløse torrenter opfundet. Dette var en opgradering til BitTorrent-protokollen, der ikke var afhængig af centraliserede trackere til at samle metadata og finde peers, men i stedet bruge nye algoritmer. Et sådant eksempel er Kademlia (Mainline DHT), en distribueret hash-tabel (DHT), som giver dig mulighed for at finde kammerater gennem andre kammerater. Faktisk udfører hver bruger en tracker-opgaver.

Distribuerede Ledgers

En distribueret hovedbok kan betragtes som en uforanderlig, kun vedhæftet database, der replikeres, synkroniseres og deles på tværs af alle noder i det distribuerede netværk.

Kendt skala - Ethereum Network havde et højdepunkt på 1,3 millioner transaktioner om dagen den 4. januar 2018.

De udnytter begivenhedsudnyttelsesmønsteret, så du kan genopbygge hovedbogens tilstand når som helst i dens historie.

Blockchain

Blockchain er den aktuelle underliggende teknologi, der bruges til distribuerede hovedbøger og markerede faktisk deres start. Denne seneste og største innovation i det distribuerede rum muliggjorde oprettelsen af ​​den første nogensinde virkelig distribuerede betalingsprotokol - Bitcoin.

Blockchain er en distribueret hovedbog med en ordnet liste over alle transaktioner, der nogensinde har fundet sted i sit netværk. Transaktioner grupperes og gemmes i blokke. Hele blockchain er i det væsentlige en linket liste over blokke (deraf navnet). Nævnte blokke er beregningsmæssigt dyre at oprette og er tæt knyttet til hinanden gennem kryptografi.

Enkelt sagt indeholder hver blok en speciel hash (der starter med X mængde nuller) af den aktuelle bloks indhold (i form af et Merkle-træ) plus den forrige blocks hash. Denne hash kræver en masse CPU-strøm, der skal produceres, fordi den eneste måde at komme på det på er gennem brute-force.

Forenklet blockchain

Minearbejdere er de knudepunkter, der prøver at beregne hash (via bruteforce). Gruvearbejdere konkurrerer alle sammen med hinanden om, hvem der kan komme med en tilfældig streng (kaldet en nonce), der, når den kombineres med indholdet, producerer den førnævnte hash. Når nogen først har fundet den rigtige mangel - sender han den til hele netværket. Nævnte streng verificeres derefter af hver knude alene og accepteres i deres kæde.

Dette omsættes til et system, hvor det er absurd kostbart at ændre blockchain og absurd let at verificere, at det ikke er manipuleret.

Det er dyrt at ændre en blok indhold, fordi det ville producere en anden hash. Husk, at hver efterfølgende blok 's hash er afhængig af den. Hvis du skulle ændre en transaktion i den første blok på billedet ovenfor - ville du ændre Merkle Root. Dette vil igen ændre blokens hash (sandsynligvis uden de nødvendige førende nuller) - det ville ændre blok # 2's hash og så videre og så videre. Dette betyder, at du bliver nødt til at brute-force en ny nonce for hver blok efter den, du lige har ændret.

Netværket stoler og replikerer altid den længste gyldige kæde. For at snyde systemet og til sidst producere en længere kæde, har du brug for mere end 50% af den samlede CPU-strøm, der bruges af alle noder.

Blockchain kan betragtes som en distribueret mekanisme for fremvoksende konsensus. Konsensus opnås ikke eksplicit - der er ikke noget valg eller et fast tidspunkt, hvor konsensus finder sted. I stedet er konsensus et fremvoksende produkt af den asynkrone interaktion mellem tusinder af uafhængige knudepunkter, alt efter protokolregler.

Denne hidtil uset innovation er for nylig blevet et boom i tech-rummet, hvor folk forudsiger, at det vil markere oprettelsen af ​​Web 3.0. Det er bestemt det mest spændende rum i software-engineering-verdenen lige nu, fyldt med ekstremt udfordrende og interessante problemer, der venter på at blive løst.

Bitcoin

Hvad tidligere distribuerede betalingsprotokoller manglede, var en måde at praktisk forhindre dobbeltforbrugsproblemet i realtid på en distribueret måde. Forskning har frembragt interessante forslag [1], men Bitcoin var den første til at implementere en praktisk løsning med klare fordele i forhold til andre.

Problemet med dobbeltudgifter siger, at en skuespiller (f.eks. Bob) ikke kan bruge sin eneste ressource to steder. Hvis Bob har $ 1, skal han ikke være i stand til at give det til både Alice og Zack - det er kun et aktiv, det kan ikke duplikeres. Det viser sig, at det virkelig er svært at virkelig opnå denne garanti i et distribueret system. Der er nogle interessante afhjælpningsmetoder, der foregår med blockchain, men de løser ikke problemet på en praktisk måde.

Dobbeltforbrug løses let af Bitcoin, da der kun tilføjes en blok til kæden ad gangen. Dobbeltudgifter er umulige inden for en enkelt blok, derfor selv hvis to blokke oprettes på samme tid - vil kun en komme til at være i den eventuelle længste kæde.

Bitcoin er afhængig af vanskeligheden ved at akkumulere CPU-strøm.

Mens en angriber i et afstemningssystem kun behøver at tilføje noder til netværket (hvilket er let, da fri adgang til netværket er et designmål), står en angriber i et CPU-magtbaseret skema over for en fysisk begrænsning: at få adgang til mere og mere kraftfuld hardware.

Dette er også grunden til, at ondsindede noder er nødt til at kontrollere over 50% af netværkets computerkraft for faktisk at udføre et vellykket angreb. Mindre end det, og resten af ​​netværket vil skabe en længere blockchain hurtigere.

Ethereum

Ethereum kan betragtes som en programmerbar blockchain-baseret softwareplatform. Det har sin egen cryptocurrency (Ether), der brændstof for installationen af ​​smarte kontrakter på dens blockchain.

Smarte kontrakter er et stykke kode, der er gemt som en enkelt transaktion i Ethereum blockchain. For at køre koden skal du kun udstede en transaktion med en smart kontrakt som destination. Dette gør til gengæld, at minearbejdsnoder udfører koden, og uanset hvilke ændringer den pådrager sig. Koden udføres i Ethereum Virtual Machine.

Soliditet, Ethereums oprindelige programmeringssprog, er det, der bruges til at skrive smarte kontrakter. Det er et turing-komplet programmeringssprog, der direkte griber sammen med Ethereum blockchain, så du kan forespørge tilstand som balancer eller andre smarte kontraktresultater. For at forhindre uendelige sløjfer kræver kørsel af koden en vis mængde Ether for at forhindre uendelige sløjfer.

Da blockchain kan fortolkes som en række tilstandsændringer, er der blevet bygget en masse distribuerede applikationer (DApps) oven på Ethereum og lignende platforme.

Yderligere brug af distribuerede hovedbøger

Bevis for eksistens - En tjeneste til anonymt og sikkert at gemme bevis for, at et bestemt digitalt dokument eksisterede på et tidspunkt. Nyttigt til at sikre dokumentintegritet, ejerskab og tidsstempel.

Decentraliserede autonome organisationer (DAO) - organisationer, der bruger blockchain som et middel til at nå enighed om organisationens forbedringsforslag. Eksempler er Dash's styringssystem, SmartCash-projektet

Decentral autentificering - Gem din identitet på blockchain, så du kan bruge single sign-on (SSO) overalt. Sovrin, Civic

Og mange, mange flere. Den distribuerede hovedboksteknologi åbnede virkelig uendelige muligheder. Nogle bliver sandsynligvis opfundet, når vi taler!

Resumé

I den korte rækkevidde af denne artikel lykkedes det os at definere, hvad et distribueret system er, hvorfor du ville bruge et og gå lidt over hver kategori. Nogle vigtige ting at huske er:

  • Distribuerede systemer er komplekse
  • De vælges efter nødvendighed af skala og pris
  • De er sværere at arbejde med
  • CAP-sætning - Afvejning af konsistens / tilgængelighed
  • De har 6 kategorier - datalagre, computing, filsystemer, meddelelsessystemer, hovedbøger, applikationer

For at være ærlig har vi næppe rørt overfladen på distribuerede systemer. Jeg havde ikke chancen for grundigt at tackle og forklare kerneproblemer som konsensus, replikationsstrategier, begivenhedsbestilling & tid, fejlagtolerance, udsendelse af en meddelelse på tværs af netværket og andre.

Advarsel

Lad mig forlade dig med en afsked advarsel:

Du skal afvige fra distribuerede systemer så meget som du kan. Kompleksitetsomkostningen, de har med sig selv, er ikke umagen værd, hvis du kan undgå problemet ved enten at løse det på en anden måde eller en anden out-of-the-box-løsning.

[1]
Bekæmpelse af dobbeltforbrug ved hjælp af kooperative P2P-systemer, 25.-27. Juni 2007 - en foreslået løsning, hvor hver 'mønt' kan udløbe og tildeles et vidne (validator) til det, der bruges.

Bitgold, december 2005 - En oversigt på højt niveau af en protokol, der ligner meget Bitcoin. Det siges, at dette er forløberen for Bitcoin.

Yderligere distribuerede systemlæsning:

Designing Data-Intensive Applications, Martin Kleppmann - En fantastisk bog, der går over alt i distribuerede systemer og mere.

Cloud Computing Specialization, University of Illinois, Coursera - En lang række kurser (6), der går over distribuerede systemkoncepter, applikationer

Jepsen - Blog, der forklarer en masse distribuerede teknologier (ElasticSearch, Redis, MongoDB osv.)

Tak for at du tog dig tid til at læse denne lange (~ 5600 ord) artikel!

Hvis du ved en chance fandt denne informative eller troede, at den gav dig værdi, skal du sørge for at give det så mange klapper, du mener, det fortjener, og overvej at dele med en ven, der kunne bruge en introduktion til dette vidunderlige studieretning.

~ Stanislav Kozlovski

Opdatering

Jeg arbejder i øjeblikket hos Confluent. Confluent er et Big Data-selskab grundlagt af skaberne af Apache Kafka selv! Jeg er meget taknemmelig for den mulighed, de har givet mig - jeg arbejder i øjeblikket på selve Kafka, hvilket er meget fantastisk! Vi hos Confluent hjælper med at forme hele open-source Kafka-økosystemet, inklusive et nyt administreret Kafka-as-a-service-cloud-tilbud.

Vi ansætter en række stillinger (især SRE / Software Engineers) i Europa og USA! Hvis du er interesseret i at arbejde på Kafka selv, på udkig efter nye muligheder eller bare være nysgerrig - sørg for at sende mig besked på Twitter, så deler jeg alle de store frynsegoder, der kommer fra at arbejde i et firma i bugten.