Förståelse av meddelandebrokers. Studera mekaniken för meddelandeutbyte med ActiveMQ och Kafka. Kapitel 1

Hej alla!

Har börjat översätta en liten bok:
«Förståelse för meddelandebrokers«,
författare: Jakub Korab, förlag: O’Reilly Media, Inc., utgivningsdatum: juni 2017, ISBN: 9781492049296.

Från inledningen till boken:
«… Denna bok lär dig att tänka kring system för meddelandeutbyte med brokers, genom att jämföra och kontrastera två populära brokerteknologier: Apache ActiveMQ och Apache Kafka. Här kommer exempel på användning och utvecklingsincitament som förde till att deras utvecklare använde helt olika angreppssätt inom samma område - meddelandeutbyte mellan system med en mellanhand broker. Vi kommer att granska dessa teknologier från grunden och lyfta fram påverkan av olika designalternativ på denna väg. Du kommer att få en djup förståelse för båda produkterna, insikt om hur de bör och inte bör användas, och kunskap om vad du bör tänka på när du överväger andra meddelandeutbyte teknologier i framtiden. …»

Översatta delar hittills:
Kapitel 1. Inledning
Kapitel 3. Kafka

Jag kommer att publicera färdiga kapitel i takt med översättningen.

KAPITEL 1

Introduktion

Meddelandeutbyte mellan system är ett av de minst förstådda områdena inom IT. Som utvecklare eller arkitekt kan du vara väl förtrogen med olika ramverk och databaser. Men det är helt möjligt att du har bara en ytlig förståelse för hur broker-baserade meddelandeteknologier fungerar. Om du känner igen dig i detta, oroa dig inte, du är i gott sällskap.

Människor interagerar vanligtvis med meddelandeinfrastruktur på ett mycket begränsat sätt. Ofta ansluter de till ett system som skapades för länge sedan, eller laddar ner en distribution från nätet, installerar den i produktion och börjar skriva kod för den. När infrastrukturen sätts i produktion kan resultaten vara oklara: meddelande förloras vid fel, meddelandeutskick fungerar inte som du förväntade dig, eller brokers "hängde" dina producenter eller skickar inte meddelanden till dina konsumenter.

Känns det bekant?

Ett vanligt scenario är att din meddelandeutbyteskod fungerar bra, tills den plötsligt slutar fungera. Denna period av framgång skapar en falsk känsla av säkerhet, vilket leder till mer kod baserad på missuppfattningar om teknikens grundläggande beteende. När något börjar gå fel konfronteras du med den obekväma sanningen: att du faktiskt inte förstod produktens grundläggande beteende eller de kompromisser som gjordes av författarna, till exempel prestanda kontra tillförlitlighet, eller transaktionalitet kontra horisontell skalbarhet.

Utan en djup förståelse för hur mäklare fungerar, gör människor, till synes, rimliga påståenden om sina meddelandeutbyten, såsom:

• Systemet kommer aldrig att förlora meddelanden
• Meddelanden kommer att behandlas i ordning
• Att lägga till konsumenter kommer att göra systemet snabbare
• Meddelanden kommer att levereras endast en gång

Tyvärr baseras vissa av dessa påståenden på antaganden som endast gäller under vissa omständigheter, medan andra är helt enkelt felaktiga.

Denna bok kommer att lära dig att resonera kring mäklardrivna meddelandeutbyten genom att jämföra och kontrastera två populära mäklarteknologier: Apache ActiveMQ och Apache Kafka. Här presenteras användningsfall och utvecklingsincitament som lett till att deras utvecklare använde helt olika angreppssätt inom samma område – meddelandeutbyte mellan system med en mellanliggande mäklare. Vi kommer att utforska dessa teknologier från grunden och belysa hur olika designalternativ påverkar dem på denna resa. Du får en djup förståelse för båda produkterna, insikt om hur de bör och inte bör användas, samt vad du ska tänka på när du överväger andra meddelandeteknologier i framtiden.

Innan vi börjar, låt oss gå igenom grunderna.

Vad är ett meddelandeutbydessystem och varför behövs det?

För att två applikationer ska kunna kommunicera med varandra måste de först definiera ett gränssnitt. Definitionen av detta gränssnitt involverar att välja transport eller protokoll, som HTTP, MQTT eller SMTP, och att komma överens om meddelandeformaten som systemen kommer att utbyta. Detta kan vara en strikt process, såsom att definiera ett XML-schema med krav på nyttolastspecifikationer (payload) för meddelandet, eller det kan vara mycket mindre formellt, som ett avtal mellan två utvecklare om att en viss del av HTTP-förfrågan kommer att innehålla klientens ID.

Så länge meddelandeformatet och ordningen för att skicka dem mellan systemen är överenskomna, kommer de att kunna interagera med varandra utan att behöva bry sig om implementationen av det andra systemet. Insidan av dessa system, såsom programmeringsspråket eller den använda ramverket, kan förändras över tid. Så länge kontraktet som helhet upprätthålls kan interaktionen fortsätta utan förändringar från den andra sidan. Dessa två system är effektivt isolerade (separatorer) av detta gränssnitt.

Meddelandesystem involverar vanligtvis en mellanhand mellan två system som kommunicerar, vilket ytterligare isolerar avsändaren från mottagaren eller mottagarna. Genom detta möjliggör meddelandesystemet för avsändaren att skicka ett meddelande utan att behöva veta var mottagaren befinner sig, om de är aktiva eller hur många instanser av dem som finns.

Låt oss betrakta ett par analogier för de olika problem som ett meddelandesystem löser och introducera några grundläggande termer.

Point-to-Point

Alexandra går till postkontoret för att skicka ett paket till Adam. Hon går fram till disken och överlämnar paketet till medarbetaren. Medarbetaren tar emot paketet och ger Alexandra en kvittens. Adam behöver inte vara hemma vid tidpunkten för paketets sändning. Alexandra är säker på att paketet kommer att levereras till Adam vid något tillfälle i framtiden och kan fortsätta med sina sysslor. Senare, vid något tillfälle, får Adam paketet.

Detta är ett exempel på en meddelandeutbytesmodell punkt-till-punkt. Postkontoret fungerar här som en distributionsmekanism för paket och säkerställer att varje paket levereras en gång. Användningen av postkontoret separerar akt av sändningen av paketet från leveransen av paketet.
I klassiska meddelandesystem implementeras modellen "punkt-till-punkt" genom ordning. En kö fungerar som en FIFO-buffert (först in, först ut), som kan prenumereras av en eller flera konsumenter. Varje meddelande levereras endast till en av de prenumererade konsumenterna. Köer försöker vanligtvis rättvist fördela meddelanden mellan konsumenterna. Endast en konsument får detta meddelande.

Till köer tillämpas termen "pålitliga" ("durable"). Pålitlighet — detta är en egenskap hos tjänsten som garanterar att meddelandesystemet kommer att spara meddelanden när det inte finns några aktiva prenumeranter, fram till dess att konsumenten prenumererar på kön för att ta emot meddelanden.

Pålitlighet blandas ofta ihop med persistens och, även om dessa två termer är utbytbara, utför de olika funktioner. Persistens definierar om meddelandet sparas av meddelandesystemet i något slags lagring mellan mottagandet och leveransen till konsumenten. Meddelanden som skickas till en kö kan vara eller inte vara persistenta.
Meddelandetypen "Punkt-till-punkt" används när användningsfallet kräver en engångshandling med meddelandet. Ett exempel kan vara att sätta in medel på ett konto eller lägga en beställning för leverans. Vi kommer att diskutera senare varför meddelandesystemet i sig inte kan säkerställa en engångsleverans och varför köer i bästa fall kan garantera att meddelandet levereras åtminstone en gång.

Publicerare-Prenumerant

Gabriella ringer konferensnumret. Så länge hon är ansluten till konferensen hör hon allt vad talaren säger tillsammans med de andra deltagarna i samtalet. När hon kopplar bort missar hon det som sägs. Vid återanslutning fortsätter hon att höra vad som sägs.

Detta är ett exempel på en meddelandeutbytesmodell publikation-prenumeration. Konferenssamtal fungerar som en sändningsmekanism. Den talande personen bryr sig inte om hur många människor som för närvarande har anslutit sig till samtalet — systemet garanterar att alla som är anslutna just nu hör vad som sägs.
I klassiska meddelandesystem implementeras meddelandemodellen "publikation-prenumeration" genom ämnenÄmnet tillhandahåller samma sätt att sända som konferenssamtalsmekanismen. När ett meddelande skickas till ämnet fördelas det till alla prenumererande användare..

Ämnen är vanligtvis opålitliga (nondurable). Precis som en lyssnare som inte hör vad som sägs under konferenssamtalet när lyssnaren kopplar bort sig, missar prenumeranter på ämnet alla meddelanden som skickas vid den tidpunkt de är offline. Av denna anledning kan man säga att ämnen ger leveransgaranti högst en gång för varje konsument.

Meddelandetypen "publicera-prenumerera" används vanligtvis när meddelandena är informativa och förlusten av ett meddelande inte är av stor betydelse. Till exempel kan ett ämne skicka temperaturavläsningar från en grupp sensorer en gång per sekund. Ett system som är intresserat av den aktuella temperaturen och prenumererar på ämnet kommer inte att oroa sig för att misslyckas med att ta emot ett meddelande - ett annat kommer att komma snart.

Hybridmodeller

En webbplats för en butik placerar meddelanden om beställningar i en "meddelandekö". Den primära konsumenten av dessa meddelanden är exekveringssystemet. Dessutom måste revisionssystemet ha kopior av dessa beställningsmeddelanden för framtida spårning. Båda systemen får inte missa meddelanden, även om själva systemen är otillgängliga under en tid. Webbplatsen ska inte behöva veta om andra system.

Användningsfall kräver ofta kombinationen av meddelandeutbytena "publicera-prenumerera" och "punkt-till-punkt", till exempel när flera system behöver en kopia av meddelandet och som kräver både tillförlitlighet och beständighet för att förhindra förlust av meddelanden.

I dessa fall krävs en mottagare (destination) (ett gemensamt begrepp för köer och ämnen) som distribuerar meddelanden i huvudsak som ett ämne, så att varje meddelande skickas till ett separat system som är intresserad av dessa meddelanden, men som också kan ha flera konsumenter som mottar de inkommande meddelandena, vilket mer liknar en kö. Läsningstypen i detta fall är en gång för varje intresserad part.Dessa hybrida adresser kräver ofta pålitlighet, så om konsumenten kopplar ner, tas meddelandena som skickas under den tiden emot efter att konsumenten återanslutit.

Hybrida modeller är inte nya och kan tillämpas i de flesta meddelandesystem, inklusive både ActiveMQ (genom virtuella eller sammansatta adresser som kombinerar ämnen och köer) och Kafka (implicit, som en grundläggande egenskap i designen av dess adresser).

Nu när vi har lite grundläggande terminologi och förståelse för vad ett meddelandesystem kan vara bra för, låt oss gå vidare till detaljerna.

Översättning utförd av: tele.gg/middle_java

Nästa översatta del: Kapitel 3. Kafka

Fortsättning följer…

Källa: habr.com