Hei!
Jeg begynte å oversette en liten bok:
«",
forfatter: Jakub Korab, utgiver: O'Reilly Media, Inc., publiseringsdato: juni 2017, ISBN: 9781492049296.
Fra introduksjonen til boken:
" ... Denne boken vil lære deg hvordan du tenker på meglermeldingssystemer, sammenligne og kontrastere to populære meglerteknologier: Apache ActiveMQ og Apache Kafka. Den vil skissere brukstilfellene og utviklingsinsentivene som førte til at utviklerne deres tok svært forskjellige tilnærminger til det samme området – meldinger mellom systemer med en mellommegler. Vi skal se på disse teknologiene fra grunnen av og fremheve virkningen av ulike designvalg underveis. Du vil få en dyp forståelse av begge produktene, en forståelse av hvordan de bør og ikke bør brukes, og en forståelse av hva du bør se etter når du vurderer andre meldingsteknologier i fremtiden ... "
Deler som er oversatt så langt:
Jeg vil legge ut ferdige kapitler etter hvert som de blir oversatt.
KAPITTEL 1
Innledning
System-til-system-meldinger er et av de minst forståtte områdene innen IT. Som utvikler eller arkitekt kan du være godt kjent med ulike rammeverk og databaser. Imidlertid er det sannsynlig at du bare har en forbigående kjennskap til hvordan meglerbaserte meldingsteknologier fungerer. Hvis du føler det slik, ikke bekymre deg, du er i godt selskap.
Folk har vanligvis svært begrenset kontakt med meldingsinfrastrukturen. De kobler seg ofte til et system som er opprettet for lenge siden, eller laster ned en distribusjon fra Internett, installerer det i PROM og begynner å skrive kode for det. Etter å ha kjørt infrastrukturen i PROM, kan resultatene blandes: meldinger går tapt på grunn av feil, sending fungerer ikke som forventet, eller meglere "henger" produsentene dine eller sender ikke meldinger til forbrukerne.
Høres kjent ut?
Et vanlig scenario er at meldingskoden din fungerer utmerket foreløpig. Helt til det slutter å virke. Denne perioden luller ens vakt inn i en falsk følelse av trygghet, noe som fører til mer kode basert på falske oppfatninger om teknologiens grunnleggende oppførsel. Når ting begynner å gå galt, står du overfor en ubeleilig sannhet: at du egentlig ikke har forstått den underliggende oppførselen til produktet eller avveiningene som er valgt av forfatterne, for eksempel ytelse versus pålitelighet, eller transaksjonalitet versus horisontal skalerbarhet .
Uten en dyp forståelse av hvordan meglere fungerer, kommer folk med tilsynelatende rimelige uttalelser om meldingssystemene deres, for eksempel:
- Systemet vil aldri miste meldinger
- Meldinger vil bli behandlet sekvensielt
- Å legge til forbrukere vil gjøre systemet raskere
- Meldinger vil kun bli levert én gang
Dessverre er noen av disse utsagnene basert på antakelser som bare gjelder under visse omstendigheter, mens andre rett og slett er feil.
Denne boken vil lære deg hvordan du tenker på meglerbaserte meldingssystemer, ved å sammenligne og kontrastere to populære meglerteknologier: Apache ActiveMQ og Apache Kafka. Den vil skissere brukstilfellene og utviklingsinsentivene som førte til at utviklerne deres tok svært forskjellige tilnærminger til det samme området – meldinger mellom systemer med en mellommegler. Vi skal se på disse teknologiene fra grunnen av og fremheve virkningen av ulike designvalg underveis. Du vil få en dyp forståelse av begge produktene, en forståelse av hvordan de bør og ikke bør brukes, og en forståelse av hva du bør se etter når du vurderer andre meldingsteknologier i fremtiden.
Før vi begynner, la oss gå gjennom det grunnleggende.
Hva er et meldingssystem og hvorfor er det nødvendig?
For at to applikasjoner skal kommunisere med hverandre, må de først definere et grensesnitt. Å definere dette grensesnittet innebærer å velge en transport eller protokoll, for eksempel HTTP, MQTT eller SMTP, og forhandle meldingsformatene som skal utveksles mellom systemene. Dette kan være en streng prosess, for eksempel å definere et XML-skjema med meldingsnyttelastkostnadskrav, eller det kan være mye mindre formell, for eksempel en avtale mellom to utviklere om at en del av HTTP-forespørselen vil inneholde klientidentifikatoren .
Så lenge formatet på meldinger og rekkefølgen de sendes er konsistente mellom systemene, kan de kommunisere med hverandre uten å bekymre seg for det andre systemets implementering. Det interne i disse systemene, for eksempel programmeringsspråket eller rammeverket som brukes, kan endres over tid. Så lenge selve kontrakten opprettholdes, kan samhandlingen fortsette uten endringer fra den andre siden. De to systemene er effektivt frakoblet (separert) av dette grensesnittet.
Meldingssystemer involverer typisk et mellomledd mellom to systemer som samhandler for ytterligere å frakoble (separere) avsenderen fra mottakeren eller mottakerne. I dette tilfellet lar meldingssystemet avsenderen sende en melding uten å vite hvor mottakeren er, om han er aktiv eller hvor mange forekomster det er.
La oss se på et par analogier for hva slags problemer et meldingssystem løser og introdusere noen grunnleggende termer.
Punkt til punkt
Alexandra går til postkontoret for å sende Adam en pakke. Hun går bort til vinduet og gir den ansatte pakken. Den ansatte henter pakken og gir Alexandra en kvittering. Adam trenger ikke være hjemme når pakken sendes. Alexandra er sikker på at pakken vil bli levert til Adam på et tidspunkt i fremtiden og kan fortsette å jobbe med henne. Senere på et tidspunkt mottar Adam en pakke.
Dette er et eksempel på en meldingsmodell punkt til punkt. Postkontoret her fungerer som en pakkedistribusjonsmekanisme, og sørger for at hver pakke blir levert én gang. Å bruke et postkontor skiller handlingen med å sende en pakke fra leveringen av pakken.
I klassiske meldingssystemer implementeres punkt-til-punkt-modellen gjennom køen. Køen fungerer som en FIFO (først inn, først ut) buffer som kan abonneres på av en eller flere forbrukere. Hver melding leveres kun til en av de abonnerte forbrukerne. Køer prøver vanligvis å distribuere meldinger rettferdig blant forbrukere. Bare én forbruker vil motta denne meldingen.
Begrepet "holdbar" brukes på køer. Pålitelighet er en tjenesteegenskap som sikrer at meldingssystemet vil vedvare meldinger i fravær av aktive abonnenter inntil en forbruker abonnerer på køen for meldingslevering.
Pålitelighet forveksles ofte med standhaftighet og selv om de to begrepene brukes om hverandre, tjener de forskjellige funksjoner. Persistens avgjør om meldingssystemet skriver en melding til en slags lagring mellom mottak og sending til forbrukeren. Meldinger som sendes til køen kan være vedvarende eller ikke.
Punkt-til-punkt-meldinger brukes når brukssaken krever en engangshandling på meldingen. Eksempler inkluderer å sette inn penger på en konto eller fullføre en leveringsordre. Vi vil diskutere senere hvorfor meldingssystemet alene ikke er i stand til å gi engangslevering og hvorfor køer i beste fall kan gi leveringsgaranti i hvert fall en gang.
Utgiver-abonnent
Gabriella slår konferansenummeret. Mens hun er koblet til konferansen, hører hun alt taleren sier, sammen med resten av samtaledeltakerne. Når hun stiller av går hun glipp av det som blir sagt. Når hun kobles til igjen, fortsetter hun å høre hva som blir sagt.
Dette er et eksempel på en meldingsmodell publisere-abonnere. Konferansesamtaler fungerer som en kringkastingsmekanisme. Personen som snakker bryr seg ikke om hvor mange som er i samtalen for øyeblikket - systemet sørger for at alle som er tilkoblet, vil høre hva som blir sagt.
I klassiske meldingssystemer implementeres meldingsmodellen publiser-abonner gjennom topper. Topic gir samme kringkastingsmetode som konferansemekanismen. Når en melding sendes til et emne, blir den distribuert for alle abonnenter.
Emner er vanligvis upålitelig (ikke-holdbar). Akkurat som en lytter som ikke kan høre hva som blir sagt på en konferansesamtale når lytteren kobler fra, savner emneabonnenter alle meldinger som sendes mens de er offline. Av denne grunn kan vi si at emner gir en leveringsgaranti ikke mer enn én gang for hver forbruker.
Publiser-abonner meldinger brukes vanligvis når meldingene er informative og tapet av én melding ikke er spesielt betydelig. For eksempel kan et emne overføre temperaturavlesninger fra en gruppe sensorer én gang per sekund. Et system som er interessert i den aktuelle temperaturen og som abonnerer på et emne, vil ikke bekymre seg om det går glipp av en melding – et annet kommer i nær fremtid.
hybridmodeller
Nettsiden til butikken legger bestillingsmeldinger i en «meldingskø». Hovedforbrukeren av disse meldingene er det utøvende systemet. I tillegg bør revisjonssystemet ha kopier av disse ordremeldingene for etterfølgende sporing. Begge systemene kan ikke la meldinger passere, selv om systemene i seg selv er utilgjengelige på en stund. Nettstedet skal ikke være oppmerksom på andre systemer.
Brukstilfeller krever ofte en kombinasjon av publiser-abonner og punkt-til-punkt meldingsmodeller, for eksempel når flere systemer krever en kopi av en melding og både pålitelighet og utholdenhet er nødvendig for å forhindre tap av meldinger.
Disse tilfellene krever en destinasjon (en generell betegnelse for køer og emner) som distribuerer meldinger i utgangspunktet som et emne, slik at hver melding sendes til et eget system som er interessert i disse meldingene, men også der hvert system kan definere flere forbrukere som mottar innkommende meldinger. meldinger, som er mer som en kø. Lesetypen i dette tilfellet er én gang for hver interessent. Disse hybriddestinasjonene krever ofte holdbarhet, slik at hvis en forbruker går offline, mottas meldinger som sendes på det tidspunktet etter at forbrukeren kobler til igjen.
Hybridmodeller er ikke nye og kan brukes i de fleste meldingssystemer, inkludert både ActiveMQ (via virtuelle eller sammensatte destinasjoner som kombinerer emner og køer) og Kafka (implisitt, som en grunnleggende egenskap ved destinasjonsdesignet).
Nå som vi har litt grunnleggende terminologi og en forståelse av hva vi kan bruke et meldingssystem til, la oss gå ned til detaljene.
Oversettelse utført:
Følgende oversatte del:
To be continued ...
Kilde: www.habr.com