Hej alle!
Jeg begyndte at oversætte en lille bog:
«",
forfatter: Jakub Korab, udgiver: O'Reilly Media, Inc., udgivelsesdato: juni 2017, ISBN: 9781492049296.
Fra indledningen til bogen:
«... Denne bog vil lære dig, hvordan du tænker på mæglermeddelelsessystemer, ved at sammenligne og kontrastere to populære mæglerteknologier: Apache ActiveMQ og Apache Kafka. Det vil skitsere de use cases og udviklingsincitamenter, der fik deres udviklere til at tage meget forskellige tilgange til det samme område - meddelelser mellem systemer med en mellemliggende mægler. Vi vil se på disse teknologier fra bunden og fremhæve virkningen af forskellige designvalg undervejs. Du får en dyb forståelse af begge produkter, en forståelse af, hvordan de bør og ikke bør bruges, og en forståelse af, hvad du skal kigge efter, når du overvejer andre meddelelsesteknologier i fremtiden ... "
Dele oversat indtil videre:
Jeg vil poste færdige kapitler, efterhånden som de bliver oversat.
KAPITEL 1
Indledning
System-til-system-meddelelser er et af de mindst forståede områder inden for IT. Som udvikler eller arkitekt kan du være meget fortrolig med forskellige rammer og databaser. Det er dog sandsynligt, at du kun har et forbigående kendskab til, hvordan mæglerbaserede meddelelsesteknologier fungerer. Hvis du har det sådan, skal du ikke bekymre dig, du er i godt selskab.
Folk har typisk meget begrænset kontakt med meddelelsesinfrastrukturen. De forbinder ofte til et system, der er oprettet for længe siden, eller downloader en distribution fra internettet, installerer det i PROM og begynder at skrive kode til det. Efter at have kørt infrastrukturen i PROM, kan resultaterne blandes: beskeder går tabt på grund af fejl, afsendelse fungerer ikke som forventet, eller mæglere "hænger" dine producenter eller sender ikke beskeder til dine forbrugere.
Lyder det bekendt?
Et almindeligt scenarie er, hvor din meddelelseskode fungerer godt for tiden. Indtil det holder op med at virke. Denne periode luller ens vagt ind i en falsk følelse af sikkerhed, hvilket fører til mere kode baseret på falske overbevisninger om teknologiens grundlæggende adfærd. Når tingene begynder at gå galt, står du over for en ubekvem sandhed: at du ikke rigtig har forstået produktets underliggende adfærd eller de afvejninger, forfatterne har valgt, såsom ydeevne versus pålidelighed, eller transaktionalitet versus horisontal skalerbarhed .
Uden en dyb forståelse af, hvordan mæglere arbejder, kommer folk med tilsyneladende rimelige udsagn om deres meddelelsessystemer, såsom:
- Systemet vil aldrig miste beskeder
- Beskeder vil blive behandlet sekventielt
- Tilføjelse af forbrugere vil gøre systemet hurtigere
- Beskeder vil kun blive leveret én gang
Desværre er nogle af disse udsagn baseret på antagelser, der kun gælder under visse omstændigheder, mens andre simpelthen er forkerte.
Denne bog vil lære dig, hvordan du tænker på mæglerbaserede meddelelsessystemer, ved at sammenligne og sammenligne to populære mæglerteknologier: Apache ActiveMQ og Apache Kafka. Det vil skitsere de use cases og udviklingsincitamenter, der fik deres udviklere til at tage meget forskellige tilgange til det samme område - meddelelser mellem systemer med en mellemliggende mægler. Vi vil se på disse teknologier fra bunden og fremhæve virkningen af forskellige designvalg undervejs. Du får en dyb forståelse af begge produkter, en forståelse af, hvordan de bør og ikke bør bruges, og en forståelse af, hvad du skal kigge efter, når du overvejer andre meddelelsesteknologier i fremtiden.
Før vi begynder, lad os gennemgå det grundlæggende.
Hvad er et meddelelsessystem, og hvorfor er det nødvendigt?
For at to applikationer kan kommunikere med hinanden, skal de først definere en grænseflade. At definere denne grænseflade involverer valg af en transport eller protokol, såsom HTTP, MQTT eller SMTP, og forhandling af meddelelsesformaterne, der vil blive udvekslet mellem systemerne. Dette kan være en streng proces, såsom at definere et XML-skema med krav til omkostningskrav til meddelelsesnyttelast, eller det kan være meget mindre formelt, såsom en aftale mellem to udviklere om, at en del af HTTP-anmodningen vil indeholde klient-id'et.
Så længe meddelelsernes format og den rækkefølge, de sendes i, er konsistente mellem systemerne, kan de kommunikere med hinanden uden at bekymre sig om det andet systems implementering. Det interne i disse systemer, såsom det anvendte programmeringssprog eller ramme, kan ændre sig over tid. Så længe selve kontrakten opretholdes, kan samspillet fortsætte uden ændringer fra den anden side. De to systemer er effektivt afkoblet (adskilt) af denne grænseflade.
Beskedsystemer involverer typisk et mellemled mellem to systemer, der interagerer for yderligere at afkoble (adskille) afsenderen fra modtageren eller modtagerne. I dette tilfælde giver beskedsystemet afsenderen mulighed for at sende en besked uden at vide, hvor modtageren er, om han er aktiv, eller hvor mange tilfælde der er.
Lad os se på et par analogier for den slags problemer, som et meddelelsessystem løser, og introducere nogle grundlæggende udtryk.
Punkt til punkt
Alexandra går på posthuset for at sende Adam en pakke. Hun går hen til vinduet og rækker medarbejderen pakken. Medarbejderen henter pakken og giver Alexandra en kvittering. Adam behøver ikke at være hjemme, når pakken sendes. Alexandra er overbevist om, at pakken vil blive leveret til Adam på et tidspunkt i fremtiden og kan fortsætte sin virksomhed. Senere på et tidspunkt modtager Adam en pakke.
Dette er et eksempel på en meddelelsesmodel punkt til punkt. Posthuset her fungerer som en pakkefordelingsmekanisme, der sikrer, at hver pakke bliver leveret én gang. Brug af et posthus adskiller handlingen med at sende en pakke fra leveringen af pakken.
I klassiske beskedsystemer implementeres punkt-til-punkt-modellen igennem kø. Køen fungerer som en FIFO (først ind, først ud) buffer, der kan abonneres på af en eller flere forbrugere. Hver besked leveres kun til en af de abonnerede forbrugere. Køer forsøger typisk at fordele beskeder retfærdigt blandt forbrugerne. Kun én forbruger vil modtage denne besked.
Udtrykket "holdbar" anvendes på køer. Pålidelighed er en tjenesteegenskab, der sikrer, at meddelelsessystemet vil fortsætte meddelelser i fravær af aktive abonnenter, indtil en forbruger abonnerer på køen for levering af meddelelser.
Pålidelighed forveksles ofte med udholdenhed og selvom de to udtryk bruges i flæng, tjener de forskellige funktioner. Vedholdenhed afgør, om meddelelsessystemet skriver en meddelelse til en form for lager mellem at modtage den og sende den til forbrugeren. Beskeder, der sendes til køen, kan være vedvarende eller ikke.
Punkt-til-punkt-meddelelser bruges, når brugssagen kræver en engangshandling på meddelelsen. Eksempler omfatter indbetaling af penge på en konto eller fuldførelse af en leveringsordre. Vi vil diskutere senere, hvorfor beskedsystemet i sig selv ikke er i stand til at levere engangslevering, og hvorfor køer i bedste fald kan give leveringsgaranti mindst en gang.
Udgiver-abonnent
Gabriella ringer til konferencenummeret. Mens hun er forbundet til konferencen, hører hun alt, hvad taleren siger, sammen med resten af opkaldsdeltagerne. Når hun tuner ud, går hun glip af, hvad der bliver sagt. Når hun har forbindelse igen, fortsætter hun med at høre, hvad der bliver sagt.
Dette er et eksempel på en meddelelsesmodel udgive-abonnere. Konferenceopkald fungerer som en udsendelsesmekanisme. Den person, der taler, er ligeglad med, hvor mange personer, der i øjeblikket er i samtalen - systemet sikrer, at alle, der er tilsluttet, vil høre, hvad der bliver sagt.
I klassiske meddelelsessystemer implementeres udgiv-abonner meddelelsesmodellen igennem toppe. Topic giver den samme udsendelsesmetode som konferencemekanismen. Når en besked sendes til et emne, distribueres den for alle abonnerede brugere.
Emner er normalt upålidelig (ikke-holdbar). Ligesom en lytter, der ikke kan høre, hvad der bliver sagt på et konferenceopkald, når lytteren afbryder forbindelsen, går emneabonnenter glip af alle beskeder, der sendes, mens de er offline. Af denne grund kan vi sige, at emner giver en leveringsgaranti ikke mere end én gang for enhver forbruger.
Udgiv-abonner-beskeder bruges typisk, når meddelelserne er af informativ karakter, og tabet af én meddelelse ikke er særlig væsentligt. For eksempel kan et emne transmittere temperaturaflæsninger fra en gruppe sensorer en gang i sekundet. Et system, der er interesseret i den aktuelle temperatur, og som abonnerer på et emne, vil ikke bekymre sig, hvis det går glip af en besked – et andet vil ankomme i den nærmeste fremtid.
Hybride modeller
Butikkens hjemmeside placerer ordrebeskeder i en "beskedkø". Hovedforbrugeren af disse beskeder er det udøvende system. Derudover bør revisionssystemet have kopier af disse ordremeddelelser til efterfølgende sporing. Begge systemer kan ikke tillade beskeder at passere igennem, selvom systemerne selv er utilgængelige i et stykke tid. Hjemmesiden bør ikke være opmærksom på andre systemer.
Brugstilfælde kræver ofte en kombination af udgiv-abonner og punkt-til-punkt-meddelelsesmodeller, såsom når flere systemer kræver en kopi af en besked, og både pålidelighed og vedholdenhed er påkrævet for at forhindre tab af beskeder.
Disse sager kræver en destination (en generel betegnelse for køer og emner), der distribuerer beskeder grundlæggende som et emne, således at hver besked sendes til et separat system, der er interesseret i disse beskeder, men også hvor hvert system kan definere flere forbrugere, der modtager indgående beskeder, som mere ligner en kø. Læsetypen i dette tilfælde er én gang for hver interessent. Disse hybriddestinationer kræver ofte holdbarhed, så hvis en forbruger går offline, modtages beskeder, der sendes på det tidspunkt, efter at forbrugeren genopretter forbindelsen.
Hybridmodeller er ikke nye og kan bruges i de fleste meddelelsessystemer, inklusive både ActiveMQ (via virtuelle eller sammensatte destinationer, der kombinerer emner og køer) og Kafka (implicit som en grundlæggende egenskab ved dets destinationsdesign).
Nu hvor vi har noget grundlæggende terminologi og en forståelse af, hvad vi kunne bruge et meddelelsessystem til, lad os komme ned til detaljerne.
Oversættelse udført:
Følgende oversatte del:
Fortsættes ...
Kilde: www.habr.com